Вся история реинжиниринга, кажется, подтверждает старую формулу о том, что универсальных решений в этой области не существует. Но так ли она безусловна?

На протяжении уже более десяти лет идея реинжиниринга бизнес-процессов является скорее броским маркетинговым лозунгом, чем методологически поддержанным направлением консалтинговой деятельности. Основополагающие работы, посвященные реинжинирингу бизнес-процессов, акцентируют внимание на технологиях обсуждения, этапах и методах принятия решений, принципах проведения изменений, а собственно методов реинжиниринга касаются чрезвычайно деликатно. И поскольку канонические методы реинжиниринга так и не сложились, само это понятие в значительной степени размылось. Реинженирингом называют любое, даже локальное изменение бизнес-процессов. К реинжинирингу стали относить также адаптацию процессов компании под типовые платформенные решения при внедрении корпоративных систем управления — SAP R/3, BAAN и др. А методология реинжиниринга консалтинговой компании по-прежнему остается лишь обобщенным опытом ее консультантов.

Причину такого положения один из основоположников концепции реинжиниринга Том Давенпорт видит в том, что в этой области «универсальных решений не существует» [1]. Вся история реинжиниринга, кажется, подтверждает эту формулу, но так ли она безусловна? В течение последних лет компания IBS выполнила для заказчиков из различных отраслей серию проектов по оптимизации бизнес-процессов (мы предпочитаем именно этот термин, полагая его более формализуемым, чем «реинжениринг»). И те решения, которые в первых проектах разрабатывались как уникальные, в последующих применялись уже как типовые.

Описанию этих решений и посвящена данная статья. А судить о том, перерос ли обобщенный опыт этих проектов в нечто большее (например, в методологию реинжиниринга), мы предоставляем нашим читателям.

Критерии и результаты

Начнем с того, что пытаться решить задачу оптимизации чего-либо (бизнес-процессов в том числе) невозможно, не имея по крайней мере критериев.

Следуя заявленной формуле оптимального бизнес-процесса, для построения критериев оптимизации необходимо сформулировать бизнес-цели предприятия и разработать количественные способы оценки степени их достижения. Наиболее подходящим инструментом для решения этой задачи нам представляется методика сбалансированных показателей (Balanced Scorecard).

Данная методика предполагает формирование дерева целей компании в терминах бизнес-целей, критических факторов успеха, ключевых показателей деятельности и мероприятий (действий). Построенное таким образом дерево целей обеспечивает возможность координации различных уровней управления компанией (стратегического, тактического и оперативного) на основе использования согласованной системы ключевых показателей деятельности. Общая модель этих взаимосвязей приведена на рис. 1.

Рис. 1. Взаимосвязь КПД с различными уровнями управления

Таким образом, мы приходим к пониманию оптимального бизнес-процесса как процесса, обеспечивающего достижение целевых значений КПД компании. Формальные ориентиры (ограничения) процессов — такие, как время исполнения, используемые ресурсы, качество результата и т. д. — должны определяться на основе целевых значений КПД. Процедуры же получения фактических значений измерителей, используемых для вычисления значений КПД и формирования отчетов, должны быть встроены в бизнес-процессы и привязаны к их конкретным шагам (функциям).

Пример №1

Одним из важных показателей, характеризующих эффективность деятельности телекоммуникационной компании по продаже ее услуг, является количество отказов клиентов от подписания подготовленного контракта. Достижение заданного целевого значения этого показателя является критерием оптимальности (возможно, не единственным) бизнес-процесса «Продажа услуги», а его фактическое значение определяется в ходе подготовки и подписания конкретных контрактов, то есть при реализации данного бизнес-процесса.

Рассмотрим возможные результаты, которые следует иметь в виду, начиная проект оптимизации бизнес-процессов.

  1. Оптимизация бизнес-процессов обычно начинается с анализа их текущего состояния в компании и попытки их реструктуризации, то есть с изменения состава и порядка выполнения функций и их исполнителей. Этот этап, безусловно, необходим, хотя бы потому, что в ходе его выполнения, возможно впервые, в компании появляется формализованное описание бизнес-процессов — пусть и в состоянии «как есть» или лишь немного улучшенных.

    Но поскольку существенных улучшений на этом пути обычно достичь не удается, приходится искать более радикальные решения в области организации бизнеса или в сфере его управления.

  2. Изменение структуры бизнес-процессов может привести и, как правило, приводит к изменениям в организационной структуре. В простых случаях они выражаются в передаче определенных функций и соответствующего персонала из одного подразделения в другое. В более сложных случаях отдельные подразделения или вакансии могут быть упразднены или, наоборот, созданы. В радикальных ситуациях сама возможность что-либо усовершенствовать в бизнес-процессах может оказаться связанной с необходимостью коренной перестройки организационной структуры компании.

    Подчеркнем: здесь трансформируется традиционная для реинжиниринга причинно-следственная связь. Необходимость изменения бизнес-процесса (но не сами изменения) приводит к изменениям в организационной структуре, а уже они порождают новую структуру бизнес-процесса. Некоторые такие решения, связанные с переходом на матричную организационную структуру компании, мы рассмотрим.

  3. Существенные изменения как в структуре бизнес-процессов, так и в организационной структуре затронут интересы очень многих людей в компании. А это значит, что их осуществление не будет простым и управление изменениями в компании, скорее всего, потребует применения специальных организационных форм. В качестве таких форм мы рассматриваем программы совершенствования системы управления компании.

Возможное содержание этих программ и методы управления ими также являются, на наш взгляд, предметом проекта оптимизации.

Реструктуризация бизнес-процессов

Первой важной задачей реструктуризации (или формализации) бизнес-процессов является определение функций, входящих в их состав.

В бизнес-процесс включаются только те функции, которые выполняются при создании требуемого конечного результата. Однако на практике определение границы бизнес-процесса с необходимой степенью детализации является сложной задачей, поскольку обычно деятельность компании представляет собой сложный набор взаимосвязанных, в том числе технологических, процессов, которые могут пересекаться и/или дополнять друг друга. Для этого, помимо традиционных методов интервью и моделирования, могут проводиться «мозговые штурмы» для выработки согласованной точки зрения всех заинтересованных сторон.

После того как границы бизнес-процесса установлены, формируется его организационно-функциональная структура — определяются исполнители функций, включенных в состав бизнес-процесса, а сами функции выстраиваются в правильной логической последовательности. Улучшения, которые обычно могут быть достигнуты на этом этапе, заключаются в сокращении числа исполнителей и согласований, минимизации количества точек входа в процесс, уменьшении стоимости процесса и т. д.

К наиболее болезненным проблемам управления бизнес-процессами относится отсутствие единого центра ответственности за процесс. Поэтому важным результатом формализации бизнес-процесса является определение его владельца.

Зачастую изменение структуры оптимизируемого бизнес-процесса приходится выполнять дважды. В первый раз — в рамках существующей модели управления, а затем — когда уже построенное формализованное описание структуры бизнес-процесса адаптируется к изменению модели управления.

Результатом реструктуризации является описание бизнес-процессов, документированное, как правило, с использованием специализированных программных пакетов (ARIS Toolset, BPWin и др.) и размещаемое в репозитарии (электронной библиотеке), а также организационно-распорядительные документы, регламентирующие применение и актуализацию описаний бизнес-процессов. Репозитарий может использоваться также для автоматизированного обновления организационно-методических документов компании (Положения о подразделениях, Должностные инструкции и т. д.).

Особый интерес представляют возможности формализации структуры бизнес-процессов на основании референтных отраслевых моделей. Наличие процессных отраслевых моделей бизнеса позволило бы существенно упростить задачу оптимизации бизнес-процессов, сведя ее к адаптации референтной модели. К сожалению, даже в такой «продвинутой» отрасли, как отрасль связи, референтные модели не являются процессными (см. пример № 2). Но даже и в этом случае их использование значительно облегчает работу по оптимизации бизнес-процессов, поскольку обеспечивает единый отраслевой словарь функций и дает их систематизированное представление.

Пример № 2

В области предоставления телекоммуникационных услуг получили широкую известность модели, разработанные компаниями SAP, HP, a также ассоциацией TeleManagement Forum. Казалось бы, остается только выбрать модель и разработать тактику перехода из состояния «как есть» в состояние «как должно быть», определяемое референтной моделью. На самом деле все не так просто. Проиллюстрируем это на примере Telecom Operations Model — общеотраслевой рамочной модели процессов телекоммуникационной отрасли.

ТОМ предлагает универсальную (в смысле независимости от конкретной организации, технологии или содержания услуг) классификацию процессов, с одной стороны, по уровням управления, а с другой — по определенным областям деятельности, которые правильнее всего определить как функциональные (см. рис. 2).

В качестве «сквозных» процессов модель ТОМ рассматривает:

  • исполнение услуги (правильно и вовремя доставить то, что заказано);

    n обеспечение услуги (своевременное и оперативное разрешение проблем, обнаруженных в сети или клиентами, отслеживание, отчетность, управление и улучшение всех аспектов услуги, которые составляют понятие «качество обслуживания» и т. п.);

  • биллинг (своевременная и точная выписка счетов, компетентный и внимательный ответ на запросы по поводу оплаты, включая своевременную корректировку счетов и сбор платы).

При попытке наложения на эту модель реального бизнес-процесса «Продажа услуги» (см. рис. 3) выяснилось, что ни один блок ТОМ не вошел в этот бизнес-процесс как единое целое, что последовательность «появления» блоков в бизнес-процессе нелинейна и часть блоков, отнесенных к разделу «Исполнение», фактически невостребована.

Рис. 3. Модель верхнего уровня бизнес-процесса «Продажа услуги»
  • Этап Формализация требований клиента обеспечивается некоторыми (но не всеми) функциями блока Продажи.
  • Этап Получение и обработка заявки клиента реализуется определенным набором функций из блока Обработка заказа.
  • Этап Оценка технической возможности предоставления услуги поддерживается несколькими функциями блока Конфигурирование услуги.
  • Этап Определение стоимости работ и тарифов — часть функций блока Обработка заказа.
  • Этап Оформление контракта опять же связан с выполнением некоторых функций из блока Продажи.
  • Этап Установка и подключение услуги в наиболее общем случае обеспечивается целым комплексом функций из блоков Конфигурирование услуги, Строительство сети, Управление парком оборудования.

Таким образом, ТОМ не описывает бизнес-процессов телекоммуникационной компании и не предлагает никаких оптимальных бизнес-решений. Аналогичное утверждение справедливо и для других референтных моделей в этой отрасли, разработанных упомянутыми выше компаниями и ориентированных на внедрение их же программных продуктов.

Управление качеством исполнения бизнес-процессов

В условиях постоянно изменяющихся внутренних и внешних обстоятельств компании оптимизация бизнес-процессов не может быть одномоментным актом. Оптимизированный бизнес-процесс необходимо регулярно измерять и анализировать, чтобы быть уверенным в том, что он соответствует ожиданиям. А для этого в самих бизнес-процессах должны быть предусмотрены специальные механизмы. Сообразно с используемым нами подходом они основаны на применении измерителей и КПД.

Для каждого бизнес-процесса определяется перечень измерителей, значения которых должны фиксироваться в ходе его исполнения, и КПД, рассчитываемых на основании этих измерителей. Перечень должен включать все измерители и КПД, связанные с данным процессом (в том числе предназначенные для мониторинга деятельности компании в целом).

После того как структура бизнес-процесса сформирована, для каждого связанного с ним измерителя определяются моменты получения его значений, а для каждого КПД — моменты расчета. Для каждого измерителя определяется методика измерений (фиксация фактического значения, экспертная оценка, прогноз), а для каждого КПД — формула расчета на основании измерителей. Определяются также должностные лица, ответственные за предоставление и фиксацию этих данных.

Должны быть также сформированы процедуры анализа показателей и принятия решений о необходимости оптимизации того или иного бизнес-процесса. Эти процедуры обеспечивают обратную связь по результатам измерений КПД и становятся составной частью бизнес-процессов мониторинга, анализа и оптимизации.

Задачи ИТ-подразделения компании

На операционном уровне управление качеством исполнения бизнес-процессов должно поддерживаться ИТ-подразделением компании, на которое возлагается несколько задач, связанных с оптимизацией бизнес-процессов.

Прежде всего ИТ-подразделение отвечает за создание и актуализацию репозитария бизнес-процессов. Эта задача органично вписывается в структуру деятельности ИТ-подразделения, поскольку подобный репозитарий является источником анализа информационной системы, системы управления предприятием, а также отправной точкой для их развития. (В этом смысле деятельность по автоматизации — часть деятельности по оптимизации бизнес-процессов.)

Итак, репозитарий служит «чертежом» для принятия решений и оценки последствий по реструктуризации для владельцев бизнес-процессов. Взаимодействие последних с ИТ-специалистами при наличии такого инструмента становится наиболее плодотворным с точки зрения постановки задач и реализации проектов оптимизации бизнес-процессов.

Вторая важная задача ИТ-подразделения — создание решений в области ИТ-поддержки бизнес-процессов и дальнейшее сопровождение соответствующих информационных систем. Здесь речь может идти о специализированных технологических решениях, например о биллинговой системе в телекоммуникационных компаниях, об общекорпоративных решениях, таких как автоматизация управления документами или бизнес-процессами.

И наконец, применение в качестве инструмента оптимизации бизнес-процессов методологии Balance Scorecard, безусловно, требует собственной информационной поддержки. Основными источниками информации, содержащей фактические значения КПД, служат учетные автоматизированные системы компании (ERP, CRM, технологические системы, бухгалтерская система и т. д.). Необходимость анализа и контроля КПД предполагает получение отчетов, содержащих информацию о фактических значениях показателей и их отклонениях от целевых значений, в том числе в динамике за аналогичные периоды в прошлом. При этом руководство должно быть обеспечено информацией как в обобщенном виде, так и на требуемом уровне детальности, а также в различных разрезах. Это станет возможным при использовании многомерной модели данных, хранилищ данных и аналитических систем. Создание решений и дальнейшая эксплуатация соответствующих информационных систем также является задачей ИТ-подразделения.

Изменение функций ИТ-подразделения и его возможная реорганизация — важная, но далеко не единственная часть общего процесса изменений в компании, инициируемых необходимостью оптимизации бизнес-процессов. Рассмотрим эти изменения.

Изменения организационной структуры

Наиболее распространенный сегодня тип организационной структуры компании — иерархическая функциональная модель. Управление в компании, построенной по этому принципу, реализуется через систему менеджмента (административное управление) и далеко не всегда является эффективным, поскольку руководитель подразделения часто бывает вынужден нести ответственность за конечный результат процесса, имея лишь ограниченные рычаги влияния и только на отдельных его этапах. В такой ситуации естественно стремление линейных руководителей сконцентрировать в своих руках как можно больше полномочий и ответственности, чтобы увеличить возможности своего влияния на достижение конечного результата. Как следствие этого у подразделения появляются непрофильные задачи, что усложняет управление и оттягивает ресурсы подразделения. Кроме того, возникают «пограничные конфликты», ухудшающие климат в коллективе, порождающие конкуренцию подразделений и приводящие к серьезным затруднениям при реализации бизнес-процессов. В итоге ответственность за результат сосредоточивается у высшего руководства компании.

Проектный подход

Устранение этих недостатков и других негативных факторов, выявленных в ходе анализа бизнес-процессов компании, возможно при переходе к матричной организационной структуре и внедрении методов проектного управления. При этом «спорные» функции вместе с реализующими их специалистами передаются из зоны ответственности функционального руководителя в зону ответственности руководителя проекта.

Пример №3

Организационная структура телекоммуникационных компаний обычно в той или иной степени ориентирована на операционную модель бизнеса услуг связи. Это выражается в том, что функциональные подразделения формируются по «горизонтальному» принципу в соответствии с уровнями управления операционной модели. Вместе с тем процессы носят сквозной характер и затрагивают все уровни модели.

В совокупности два этих факта приводят к тому, что для выполнения любого процесса требуется множество «передач управления» и согласований между подразделениями. Минимизировать эти издержки можно только путем концентрации ответственности за весь процесс в одних руках. А это диктует необходимость в создании специализированных — постоянных или временных — подразделений, ориентированных на исполнение конкретных процессов.

В соответствии с бизнес-процессами, построенными на основе операционной модели, проектные структуры должны формироваться по «вертикальному» принципу. Они создаются для выполнения конкретных работ, имеют детальный план работ, собственный бюджет и систему мотивации. В состав команды проекта включаются сотрудники функциональных подразделений и/или специалисты, привлекаемые на временной основе.

Применение проектного подхода приводит к матричной структуре компании, в которой функциональные подразделения «пересекаются» с проектными группами. Эта идея, как легко видеть, согласуется с операционной моделью телекоммуникационного бизнеса.

Изменения при переходе к матричной организационной структуре могут состоять не только в использовании временных коллективов, но и в создании новых постоянных структурных единиц в штатном расписании компании, таких, скажем, как Проектный офис или Служба управления проектами, выполняющих функции управления портфелем проектов, и в частности планирование ресурсов в масштабах компании в целом.

Продуктовый подход

Временные коллективы могут создаваться не только под проекты, но и под продукты компании. Необходимость этого возникает в связи с тем, что жизненный цикл продукта дольше жизненного цикла проекта и требуется долговременная ассоциация специалистов с продуктом.

Рис. 4. Жизненный цикл продукта

На рис. 4 показан жизненный цикл продукта и его этапы, которые могут выполняться в проектной форме (выделены цветом). Продуктовый подход реализуется путем матричной организации процессов создания, внедрения и сопровождения продуктов, при концентрации в составе продуктовой группы всех необходимых специалистов, введении системы рационального распределения и контроля ресурсов, мотивации сотрудников от результата, а также делегировании всех необходимых полномочий и ответственности руководителю продуктовой группы.

Продуктовую структуру компании можно выстроить двояко (см. рис. 5).

  • Вертикальный принцип предполагает ориентацию на продукт, предназначенный для внешнего или внутреннего заказчика. При таком подходе продуктовую группу должны в основном составлять специалисты, владеющие содержательной стороной сопровождения продукта. В группу включаются также специалисты технических служб, обеспечивающие поддержку продукта на платформенном уровне.
  • Горизонтальный принцип предполагает ориентацию на платформенные (программные, технологические или технические) продукты. При таком подходе продуктовую группу должны в основном составлять технические специалисты, дополненные специалистами, владеющими содержательной стороной.

Целью (причиной) образования продуктовой группы является необходимость обеспечить для успешного существования продукта долговременную (на протяжении всего жизненного цикла) ассоциацию с этим продуктом специалистов, отвечающих за его создание, эксплуатацию и развитие.

Естественным направлением эволюции продуктовой группы является ее стремление к оформлению в самостоятельное структурное подразделение компании или выделение в отдельную компанию холдинга (особенно, если продукт успешен). Но вновь возникающее подразделение кроссфункционально по своей сути, что ведет к противоречиям, связанным с его подчиненностью. По этой причине необходимо, чтобы процессы образования и эволюции продуктовых групп были хорошо структурированы и не носили стихийный характер.

Адаптация бизнес-процессов к модели управления

Переход на матричную модель может потребовать радикального изменения структуры бизнес-процессов. Даже если основные содержательные функции процессов останутся неизменными, в соответствии с выбранной моделью управления (административной, проектной или какой-либо иной) изменятся владельцы процессов и процедуры управления, встроенные в бизнес-процессы.

Для административной модели, учитывая обычно сквозной характер бизнес-процессов, управление ими реализуется через координацию действий вовлеченных в процесс подразделений. Для проектной модели управление бизнес-процессом осуществляется через управление расписанием и бюджетом проекта, командой, рисками, проблемами и т. д. Как правило, весь (или почти весь) процесс реализуется в рамках команды проекта и находится, таким образом, под непосредственным управлением руководителя проекта. Случаи же, когда процесс выходит за рамки команды проекта (например, в финансовую службу или службу логистики), регламентируются специальными инструкциями.

Переход на матричную модель должен сопровождаться созданием соответствующих организационно-распорядительных документов, составляющих стандарт управления проектами (продуктами) предприятия. К основным элементам стандарта относятся регламенты и положения (включая принципы учета трудозатрат и мотивации), процедуры выполнения проектов, ролевые инструкции персонала проекта и членов продуктовых групп, шаблоны управленческих документов. В соответствии с этими документами должна быть заново проведена реструктуризация бизнес-процессов и изменены соответствующие формализованные описания в репозитарии.

Совершенствование системы управления компании

Возвращаясь к методологии Balance Scorecard, напомним, что инструмент обратной связи, который используется при оптимизации бизнес-процессов, представлен на рис. 1 действиями (мероприятиями), обеспечивающими вывод КПД на уровень заданных целевых значений. Эти мероприятия должны рассматриваться не изолированно, а в контексте единого процесса совершенствования управления компании.

В общем случае задача совершенствования управления осуществляется на трех уровнях:

  • изменение бизнес-процессов;
  • изменение организационной структуры;
  • изменение (внедрение) ИТ.

Таким образом, речь должна идти об общекорпоративной программе, распадающейся на ряд целевых по областям управления и далее — по проектам (по уровням изменений). Структура программы приведена на рис. 6. Для каждого мероприятия определяется место в одном из проектов, составляющих Программу.

Опыт показывает, что изменение методов управления неизбежно нарушает сложившийся баланс интересов разных функциональных подразделений компании. Попытка изменения этого баланса в ту или иную сторону в приказном порядке, как правило, к успеху не приводит, поскольку незаинтересованные стороны имеют достаточно возможностей для сколь угодно долгого затягивания процесса.

Следовательно, функция осуществления реформ не может быть делегирована одному, даже профильному подразделению. Роль такого подразделения должна состоять прежде всего в общей организации и координации процесса, в согласовании позиций участвующих в нем сторон, но не в руководстве им.

В принятии решений необходимо равноправное участие всех затрагиваемых реорганизацией сторон, а организационная структура реализации реформы должна обеспечивать им участие на всех этапах работ и на всех уровнях этого процесса. Наиболее адекватной формой выполнения таких работ является применение методов проектного управления.

К теме организации работ по совершенствованию системы управления компании и особой роли ИТ-службы в этом процессе мы уже обращались [2, 3].

Заключение

Напоследок хотелось бы остановиться на ответственности консультанта за предлагаемое решение.

Безусловно, цель любого проекта оптимизации бизнес-процессов состоит не в теоретической разработке оптимальных процессов, а в повышении эффективности операционной деятельности компании.

Очевидно, консультанты могут обеспечить только методологическую поддержку мероприятий по переходу компании к новым бизнес-процессам и соответствующей им организационной структуре. Вся же практическая работа по проведению необходимых изменений должна осуществляться менеджментом самой компании. Консультант может выполнять только авторский надзор, планируя этапы внедрения новых процессов, ориентируясь на состояние дел в компании.

Складывается парадоксальная ситуация: консультант завершает свою работу с неизвестным для заказчика практическим результатом, поскольку не существует критериев, с помощью которых можно было бы оценить оптимальность предлагаемых решений до начала функционирования новых бизнес-процессов. Это — реалии консалтинговой практики, исходя из которых рынок выработал несколько простых правил, следование которым значительно снижает риски как заказчика, так и консультанта.

Для заказчиков:

  • выбирать только известных консультантов, имеющих опыт проведения аналогичных работ;
  • работать вместе с консультантами на всех этапах проекта;
  • обязать консультантов докладывать все, даже промежуточные результаты широкому кругу менеджеров и специалистов компании.

Для консультантов:

  • не становиться орудием для решения «внутриполитических» вопросов заказчика;
  • не обещать «быстрых» результатов;
  • не жалеть времени на дискуссии.
Литература
  1. Давенпорт Т. Реинжиниринг новой волны//Директор информационной службы. 2002. № 11
  2. Циперман Г. Н., Ципес Г. Л. Проектное управление для СЕО. Практические рекомендации//iBusiness, февраль 2001.
  3. Ципес Г. ИТ-проекты в портфелях и программах//Директор информационной службы. 2003. № 04.

Евгений Гельфанд — менеджер проектов, компания IBS, EGelfand@ibs.ru

Александр Савич — менеджер проектов, компания IBS, ASavich@ibs.ru

Григорий Циперман — директор департамента управленческого консультирования, ЗАО «ИКТ-Консалт», G_Tsip@ikt.msk.ru

Григорий Ципес — главный консультант IBS, gtsipes@ibs.ru


Бизнес-процесс
Это логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания в обозримом будущем конечного результата, имеющего ценность для клиента или для самой компании
Оптимальный бизнес-процесс
Обеспечивает достижение бизнес-целей предприятия, сформулированных в терминах количественных показателей, которые используются в качестве критериев оптимизации
Бизнес-цели
Определяются как приоритетные стратегические направления развития бизнеса компании, определяющие условия успешного ее существования на рынке в среднесрочной и долгосрочной перспективе
Критический фактор успеха (Critical Success Factor)
Соответствует заданной области деятельности компании, оказывающей определяющее влияние на то, будет ли достигнута конкретная бизнес-цель
Ключевой показатель деятельности (КПД, Кеу Performance Indicator)
Количественный индикатор, позволяющий измерять степень достижения успеха в конкретной области деятельности компании
Целевое значение ключевого показателя деятельности
Числовое значение КПД, фактическое достижение которого ассоциируется с успехом в соответствующей области деятельности на заданном временном периоде
Измеритель
Простой (обычно, учетный) показатель, значение которого используется для формирования одного или нескольких КПД
Действие
Соответствует конкретному мероприятию, которое необходимо реализовать для того, чтобы было достигнуто целевое значение соответствующего КПД
Владелец процесса
Лицо (или группа лиц), ответственное за ход и результат всего процесса в целом, имеющее право изменять, совершенствовать его и обеспечивающее его управляемость, производительность и адаптируемость.

Как уже отмечалось, в процессе реструктуризации может меняться состав выполняемых функций (ликвидируются избыточные или дублирующиеся, добавляются недостающие) и лица, отвечающие за их исполнение.

Матричная организационная структура
Предполагает формирование на базе постоянных функциональных подразделений временных коллективов, которые создаются под определенную цель или под проект для решения какой-то конкретной задачи и пользуются при этом определенной свободой в организации своей работы.
Административное управление
B компании реализуется через систему менеджмента, ключевым звеном которого являются менеджеры среднего звена — руководители подразделений, в непосредственном подчинении которых находятся сотрудники компании.
Управление проектами
Область менеджмента, охватывающая те сферы производственной деятельности компании, в которых создание продукта или услуги реализуется как уникальный комплекс взаимосвязанных целенаправленных мероприятий при определенных требованиях к срокам, бюджету и характеристикам ожидаемого результата.
Продуктовая группа
Организационно оформленная многофункциональная команда по разработке, внедрению и сопровождению продукта, создаваемая на все время его существования.
«Вертикальные» продукты
Продукты, создаваемые в рамках основной деятельности компании и предназначенные для внешнего (бизнес-продукт) или внутреннего (внутренний продукт) заказчика.
«Горизонтальные» продукты
Технологические решения, разрабатываемые в компании или предоставляемые сторонними организациями, обеспечивающие информационную поддержку бизнес-процессов компании