СИЛИЧ В А СИЛИЧ М П СИСТEМНЫE ТEХНОЛОГИИ ПРОEКТИРОВАНИЯ БИЗНEС-ПРОЦEССОВ УЧEБНОE ПОСОБИE ТОМСК 2000 108 С 3

Различают постоянные атрибуты, значения которых не изменяются в ходе выполнения прецедента и переменные, которые определяют различные состояния объекта. Например, объект "Заказ" может иметь переменный атрибут, указывающий, находится ли заказ в стадии изготовления товара, отправки товара или он уже выполнен.
Описание поведения объекта заключается в выявлении всех его обязательств, т.е. всех взаимодействий объекта с другими объектами и субъектами в ходе выполнения прецедента. В [3] описан алгоритм выявления всех обязательств объекта из диаграмм взаимодействия. Поясним суть алгоритма. Как правило, объект фигурирует в нескольких диаграммах взаимодействия, описывающих различные прецеденты или экземпляры прецедентов. Из всех диаграмм, где фигурирует описываемый объект, вычленяются все обязательства объекта (взаимодействия) и объединяются (см. рис.3.7). В результате получается описание всех ролей объекта во всех прецедентах.

Все требования к объекту, состоящие их описания состояний объекта и описания поведения, собираются в документ, называемый спецификацией объекта.

3.3. IDEF - методология моделирования

IDEF-методология была разработана задолго до появления технологии реинжиниринга бизнес-процессов. С середины 70-х годов правительство и военные ведомства США финансировали многочисленные проекты, ориентированные на разработку методов описания и моделирования сложных систем. Одним из них явился проект ICAM (Integrated Computer-Aided Manufacturing), предложенный ВВС США, цель которого состояла в разработке подходов, обеспечивающих повышение эффективности производства благодаря систематическому внедрению компьютерных технологий. В соответствии с проектом ICAM было разработано семейство методологий IDEF (ICAM DEFinition), которое состоит из трех самостоятельных методологий моделирования различных аспектов функционирования производственной среды или системы [10]:
* IDEF0 - методология создания функциональной модели производственной системы (основана на методе SADT Росса);
* IDEF1 - методология создания информационной модели производственной системы (основана на реляционной теории Кодла и использовании ER-диаграмм Чена);
* IDEF2 - методология создания динамической модели производственной системы.
Позднее на базе методологии IDEF1 было создано ее расширение - методология семантического моделирования данных IDEF1X.
IDEF-методологии получили очень широкое распространение, т.к. были направлены на проектирование не только систем программного обеспечения, но и систем более общего назначения. Этому способствовала и автоматизация - создание CASE-продуктов, поддерживающих IDEF, благодаря которым данная методология стала доступной и простой в употреблении.
Рассмотрим основные элементы методологий IDEF0 и IDEF1X, а также возможности их применения для реинжиниринга бизнес-процессов.

3.3.1. Методология IDEF0

Методология IDEF0 является одной из самых известных и широко используемых методологий проектирования. Системные аналитики всего мира используют для решения широкого спектра проблем, включая разработку программного обеспечения, бизнес-анализ, проектирование, планирование и управление производственными системами, управление финансами и материально-техническими ресурсами, обучение персонала и т.д. [10].
Методология IDEF0 базируется на методе SADT (Structured Analysis and Design Technique) Росса, предназначенном для структурированного представления функций системы и анализа системных требований. При создании новых систем IDEF0 может вначале применяться для определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем IDEF0 может использоваться для анализа функций и механизмов их исполнения.
Модель SADT использует как естественный, так и графический языки для передачи информации о конкретной системе. Модель состоит из диаграмм и фрагментов текста. На диаграммах все функции системы и их взаимодействия представлены как блоки (функции) и дуги (отношения).
Основной конструкцией модели является функциональный блок, представляющий собой некоторый процесс или, в терминологии SADT, "активность". Выделяются также наборы различных объектов ("предметов"), связанных с активностями в четырех возможных отношениях - "Вход", "Выход", "Управление" и "Механизм":
- "Входы" отображают объекты, которые функциональный блок преобразует в "Выходы" (например, входную информацию в выходную);
- "Управление" определяет, когда и как это преобразование может или должно произойти;
- "Механизм" (человек, оборудование, автоматизированная система) непосредственно осуществляет преобразование.
Каждое из этих отношений изображается дугой, связанной с определенной стороной блока: левая сторона блока предназначена для входов, верхняя - для управления, правая - для выходов, нижняя - для механизма. Диаграмма функционального блока с входящими и выходящими дугами приведена на рис. 3.8.

Каждый функциональный блок может быть декомпозирован, т.е. представлен в виде совокупности других взаимосвязанных функциональных блоков, которые детально описывают исходный блок. Таким образом, модель SADT состоит из набора иерархически связанных диаграмм (см. рис. 3.9). Каждая диаграмма обычно содержит 3 - 5 блоков, размещаемых по "ступенчатой" схеме в соответствии с их доминированием, которое понимается как влияние, оказываемое одним блоком на другие.
Построение модели начинается с представления всей системы в виде простейшей компоненты - одного блока и дуг, изображающих интерфейсы с внешним окружением. Например, на рис 3.9 блок на диаграмме верхнего уровня имеет 4 внешних дуги - I1, I2, C1, O1. Для обозначения внешних дуг используются буквы: I (Input - вход), C (Control - управление), O (Output - выход) и M (Mechanism - механизм).

Затем блок, который представляет систему в целом, детализируется на другой диаграмме с помощью нескольких блоков-подмодулей, соединенных интерфейсными дугами. Каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления.
Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера узлов. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме АО.
Дуги связывают различные функциональные блоки вместе и отображают взаимодействие и взаимное влияние блоков. Взаимовлияние может выражаться либо в передаче выхода одного блока на вход другого для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что должна делать другая активность. Дуги могут отображать и отношения обратной связи. Дуги с одним свободным концом имеют источник или получатель вне диаграммы (I1, I2, C1, O1 на рис. 3.9). Они должны соответствовать дугам на исходной диаграмме.
Нужно подчеркнуть, что дуги - это не потоки и не последовательности. Они представляют собой ограничения на работу блока в том смысле, что функция не может быть выполнена, пока не станут доступными данные или объекты, соответствующие входящим дугам. Таким образом, ни последовательность выполнения функций, ни время не указаны явно на SADT-диаграммах.
Дуги могут разветвляться и соединяться различным образом. Каждая из ветвей может представлять один и тот же объект или различные объекты одного и того же типа. Метки указывают назначение дуг.
Перейдем к рассмотрению вопросов применения методологии IDEF0 в технологии реинжиниринга.
Данная методология может быть использована для описания потоков событий прецедентов бизнес-системы. Каждый шаг прецедента (событие) может быть представлен как функциональный блок SADT-диаграммы. При этом объекты, участвующие в выполнении прецедента, представляются как входные и выходные дуги функциональных блоков. Так, интерфейсные и управляющие объекты представляются как дуги механизма, т.к. представляют собой людей, непосредственно осуществляющих выполнение преобразования (события). Объекты-сущности могут представлять входные дуги (если они являются предметом преобразований) или выходные дуги (если они являются результатом преобразований) или дуги управления (если они определяют условия преобразования) или дуги механизма (если они являются инструментом преобразований). Таким образом, с помощью SADT-диаграммы можно представить диаграмму взаимодействия объектов в ходе выполнения потока событий прецедента.
Рассмотрим, как можно представить в виде SADT-диаграммы описание прецедента "Продажа заказного продукта" (см. п. 3.2).
На исходной диаграмме верхнего уровня А-0 прецедент представляется в виде одного блока и дуг, изображающих его взаимодействие с внешним окружением (см. рис. 3.10).

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

Для блока 1 "Получить заказ клиента" входом является "информация о заказе", получаемая от клиента. Этому входу соответствует дуга I1, которая переносится с родительской диаграммы. Выходом является "заказ", содержащий: "описание продукта" (предается блоку "Выполнить заказ") и "адрес клиента" (передается блоку "Отправить заказ клиенту"). Механизмом является дуга M1 - "продавец", который обеспечивает исполнение блока.
Для блока 2 "Выполнить заказ" дуга "описание продукта" является управляющей, т.к. она предписывает, каким образом должно происходить выполнение заказа. Входом являются "материалы, детали", используемые при производстве продукта, а выходом - "готовый продукт" (передается блоку "Отправить заказ клиенту"). Кроме того, выходом является "информация о выполнении заказа", которая передается блоку "Получить оплату заказа" в качестве управляющего сигнала. Механизм блока представлен дугами "проектировщик" и "оборудование".
Для блока 3 "Получить оплату заказа" входом являются "деньги", получаемые от клиента. Этому входу соответствует дуга I3, которая переносится с родительской диаграммы. Выходом является "информация об оплате", которая передается блоку "Отправить заказ клиенту" в качестве управляющего сигнала. Механизмом является дуга M1 - "продавец", который обеспечивает исполнение блока.
Для блока 4 "Отправить заказ клиенту" входом является "готовый продукт", управляющим входом - "информация об оплате". Выходом является "доставленный продукт", который является выходом всего прецедента. Механизмом являются дуги "отправитель" и "транспорт".

3.3.2. Методология IDEF1Х

Методология IDEF1X - один из подходов к семантическому моделированию данных, основанный на ER-концепции (концепции "Сущность - Отношение"). Данная методология позволяет формировать концептуальную схему представления данных, которая сводится к единому (интегрированному) определению данных в рамках одного предприятия (компании, системы и т.д.). Определение данных при этом не связано ни с каким конкретным использованием данных и не зависит от способа хранения данных и доступа к ним. Важнейшая цель такого представления заключается в непротиворечивой интерпретации данных и взаимосвязей между ними, что необходимо для интеграции и совместного использования данных [10].
Информационная модель, построенная с помощью IDEF1X- методологии, является дополнением функциональной IDEF0-модели и детализирует объекты, которыми манипулируют функции системы.
Компонентами IDEF1X-модели являются [10]:
* Сущности. Каждая сущность представляет собой множество реальных или абстрактных объектов (людей, мест, событий, состояний и т.д.), обладающих общими атрибутами или характеристиками. Отдельный элемент этого множества называется экземпляром сущности.
* Атрибуты. Сущность имеет один или несколько атрибутов, которые либо являются собственными для сущности, либо наследуется через отношение, связывающее ее с другой сущностью. Атрибуты однозначно идентифицируют каждый экземпляр сущности. Каждый атрибут имеет уникальное имя.
* Отношения. Отношение - это связь между сущностями. Отношение "родитель-потомок" ("один-ко-многим") - это связь, при которой каждый экземпляр одной сущности, называемой сущностью-родителем, ассоциирован с произвольным числом экземпляров другой сущности, называемой сущностью-потомком, а каждый экземпляр сущности-потомка ассоциирован только с одним экземпляром сущности-родителя. Имеются также еще два вида отношений - "отношение категоризации" ("один-к-одному") и неспецифическое отношение (многие-ко-многим").
IDEF1X-модель представляется в виде диаграммы. На рис. 3.12 представлена IDEF1X-диаграмма, основанная на [11]. На диаграмме сущности изображаются в виде прямоугольных поименованных блоков. Атрибуты изображаются в виде списка их имен внутри блока сущности. Отношение "родитель-потомок" изображается линией, соединяющей сущность-родитель с сущностью потомком, с точкой на конце линии у сущности-потомка. Каждому отношению дается имя, выражаемое глаголом.

Имя отношения всегда формируется с точки зрения сущности-родителя. Если соединить имя сущности-родителя, имя отношения и имя сущности-потомка, получится предложение. Например, на рис. 3.12 можно идентифицировать следующие предложения: "ИСПОЛНИТЕЛЬ отвечает за выполнение ОПЕРАЦИИ", "ОБЪЕКТ участвует в ОПЕРАЦИИ", "СОБЫТИЕ влияет на ОПЕРАЦИЮ".

Контрольные вопросы

1. Чем отличаются формальные и семантические модели, статические и динамические?
2. Что такое прецедент? Каковы его основные характеристики? Чем отличатся экземпляр и класс прецедента?
3. Что обозначают субъекты П-модели? Приведите примеры субъектов.
4. Что такое поток событий прецедента?
5. Охарактеризуйте 2 способа структурирования прецедентов.
6. Перечислите основные типовые классы объектов, используемые в О-модели
7. Перечислите основные виды отношений между объектами. Приведите примеры для каждого вида отношений.
8. Что отражается в диаграмме взаимодействия прецедента?
9. Как формируется описание состояния и описание поведения объекта?
10. Что отражает каждый из четырех видов входящих и выходящих дуг функционального блока SADT-диаграммы: "Входы", "Выходы", "Механизм"и "Управление"? Приведите примеры.
11. Как связаны блоки диаграмм разных уровней иерархии SADT-модели?
12. Что представляют собой и как отражаются в диаграмме основные компоненты IDEF1X-модели (сущности, атрибуты и отношения)? Приведите примеры компонент.

4. ТЕХНОЛОГИЯ РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ

4.1. Директива на проведение реинжиниринга

Технология - последовательность этапов реинжиниринга бизнеса, для каждого из которых определены состав работ, используемые процедуры, методики и инструментальные средства. Мы уже рассматривали коротко последовательность проведения реинжиниринга (см. п. 1.1). Рассмотрим более подробно содержание работ для каждого этапа реинжинирнга, начиная с составления директивы на проведение реинжиниринга.
Директива служит основанием для начала работ по реинжинирингу. Она должна быть составлена в терминах высокого уровня и выражать ожидания от реализации проекта. Директива должна объяснить ситуацию, в которой находится компания, и почему в этом положении нельзя оставаться. М. Хаммер называет директиву документом типа "аргументы для действий". Такой документ объясняет, почему бизнес должен быть реконструирован. Работники должны быть убеждены, что компания не может продолжать идти прежним курсом, если она хочет выжить и остаться конкурентоспособной.
Таким образом, основное назначение директивы - обеспечение мотивации к проведению реинжинирнга как для участников проекта, так и для всех сотрудников компании, затрагиваемых проектом.
Роль мотивации для разных групп сотрудников различна. Чрезвычайно важна мотивация высшего руководства, т.к. реинжиниринг всегда проводится "сверху - вниз", о чем уже упоминалось выше (п. 1.3). Руководство должно верить в необходимость реинжиниринга и быть абсолютно убеждено, что проект по реинжинирингу даст значительный результат. С другой стороны, руководство должно отдавать себе отчет в трудностях, неизбежных при построении новой компании и должно уметь идти на некоторый риск. Как сказал Дж. Карлсон, "нужно отважиться сделать прыжок" [3]. Руководитель, возглавляющий проект по реинжинирингу, должен уметь сопротивляться давлению упрямой старой компании и должен убедить сотрудников в том, что проект не только выполним, но и необходим для выживания компании.
Сотрудники компании должны понимать, почему проект приведен в действие, принимать свои новые задачи и быть готовыми к переменам. Относительно просто объяснить необходимость нового способа работы работникам нижнего уровня, но людям, исполняющим должности менеджеров, намного труднее понять, что новая компания может им предложить. Особое внимание рекомендуется уделять управляющим среднего звена, поскольку именно их деятельность в наибольшей степени будет изменена в результате реинжиниринга. Б.Виллох определяет 3 категории средних менеджеров [3]:
1. "Тигры" - это молодые карьеристы, которые хотя и участвуют с энтузиазмом в проекте по реинжинирингу, имеют тенденцию концентрироваться на своих собственных задачах в ущерб общим целям проекта.
2. "Ослы" - это старейшие сотрудники, достигнувшие целей своей карьеры, которые хотят спокойствия и стабильности в компании. Они могут серьезно навредить проекту.
3. "Акулы" - сотрудники, которые разработали процедуры и инструкции для управления операциями компании, они часто имеют реальную силу в компании и могут создать огромные проблемы путем саботирования реальных перемен.
В задачу руководителя проектом по реинжинирингу должно входить разъяснение задач реинжиниринга всем служащим компании, привлечение их на свою сторону и демонстрация преимуществ обновления бизнеса. Успеху этой деятельности способствует:
* Понятность целей реинжиниринга. Новые задачи компании должны быть четко сформулированы и понятны каждому сотруднику. Руководство и рядовые сотрудники должны понимать, как достичь стратегических целей.
* Широкие горизонты. Проекты, сформулированные в терминах роста и расширения, а не сокращения размеров и расходов, имеют больше шансов на успех, поскольку порождают больше энтузиазма и меньше сопротивления.
* Осязаемые результаты. Результаты работ по реинжинирингу должны быть конкретными. Работа по изменению компании должна фокусироваться на наиболее приоритетных целях, которые могли бы быть достигнуты примерно за год (этого времени обычно достаточно, чтобы создать первую версию реконструированных процессов). "Никогда не следует откусывать больше, чем можете прожевать".
* Самостоятельный бюджет проекта. Проект должен иметь свой собственный бюджет, особенно если планируется интенсивное использование ИТ. Часто ошибочно считают, что реинжиниринг возможен на условиях самофинансирования.
* Принцип первого руководителя. Проект должен выполняться под управлением руководства компании. Руководитель, возглавляющий проект по реинжинирнгу, должен иметь большой авторитет в компании и нести за него ответственность. Для успеха проекта очень важно твердое и умелое управление.
Все перечисленные аспекты должны быть учтены при составлении директивы на проведение реинжиниринга. Ее основное содержание:
1. Анализ ситуации: изменение окружения компании, ожидания клиентов, увеличение конкуренции, трудности бизнеса компании, риск, вызванный сохранением существующего положения
2. Цели реинжиниринга. Цели должны быть величественны, чтобы мотивировать сотрудников компании на радикальные изменения в работе. С другой стороны, цели и ожидаемые результаты должны быть реалистичны и конкретны.
3. Средства реализации проекта: бюджет, руководство, планируемые сроки проведения реинжиниринга, использование технологической поддержки, приблизительный объем работ.

4.2. Подготовительный этап

Любой проект по реинжинирингу должен начинаться с подготовительного этапа - создания системы управления проектом, на котором должны быть определены: участники проекта по реинжинирингу, их роли и обязанности; план проведения реинжиниринга (см. рис. 4.1).

Участники проекта по реинжинирингу, их роли и обязанности.
На рис. 4.2 приведена типовая организационная структура для участников проекта по реинжинирингу. М Хаммер и Дж. Чампи для среднего проекта выделяют следующих участников реинжиниринга компании [3]:
1. Лидер проекта - член высшего руководства компании, который возглавляет организацию и проведение реинжиниринга. Он берет на себя основную ответственность и риск, связанные с проектом. Его основная задача - формирования представления о будущей обновленной компании и обеспечение должной мотивации остальных сотрудников. Лидер служит источником энтузиазма для всех участников реинжиниринга, он создает в компании атмосферу, в которой каждый сотрудник сможет проявить готовность отказаться от старых правил работы.
Лидер проекта должен иметь достаточные полномочия для выполнения перечисленных задач. Очень важно, чтобы его личные качества соответствовали взятым на себя обязательствам: без сильного, агрессивного и высокопрофессионального руководства довольно сложно преодолеть сопротивление некоторых сотрудников компании происходящим изменениям.
2. Руководящий комитет (совет) наблюдателей - комитет, образованный из представителей высшего руководства компании. Как правило, в него входят владельцы процессов. Комитет возглавляется лидером проекта. Основная цель руководящего комитета - определение общей стратегии по реинжинирингу и контроль выполнения работ по проекту. В частности им определяются приоритеты проектов, а также решаются проблемы, требующие совместных усилий владельцев различных процессов, преодолеваются конфликтные ситуации. Руководящий комитет не является обязательным участником работ, в небольших компаниях его функции может выполнять лидер проекта.

3. Исполнительный директор (в [3] - "царь") - специалист компании, выполняющий функции оперативного руководителя всех работ по реинжинирингу в компании. Поскольку лидер не имеет возможности осуществлять повседневное оперативное управление проектом, он нуждается в помощнике, берущим на себя руководство штатом по реинжинирингу. Он подчиняется непосредственно лидеру проекта и выполняет две основные функции: во-первых, обеспечивает работу по каждому конкретному проекту; во-вторых, координирует работы по всем одновременно выполняемым проектам.
Исполнительный директор должен владеть современными методами проведения реинжиниринга, т.к. в его задачу входит адаптация и развитие методик и инструментариев поддержки реинжиниринга. Он также помогает владельцам процессов привлекать специалистов со стороны для формирования команды по реинжинирингу. Наконец, исполнительный директор организует взаимодействие владельцев процессов (обсуждения, инспекции и т.д.).
4. Владельцы процессов - менеджеры высшего звена, отвечающие за обновляемые процессы. Они назначаются лидером проекта.
Владелец процесса несет ответственность за обновляемый процесс, однако сам не выполняет реинжиниринг. Его задача состоит в привлечении квалифицированной команды процесса и обеспечении ей нормальных условий для работы над проектом. Владелец процесса участвует в процессе как наблюдатель, тренер и оппонент. Он также отвечает за мотивацию членов команды.
5. Команда по реинжинирингу - группа специалистов (сотрудники компании, а также эксперты и разработчики, привлеченные со стороны) для проведения реинжиниринга определенного процесса. Назначение членов команды сводится к распределению работ по исполнителям. Для выполнения проекта могут привлекаться следующие ресурсы и группы:
* Группа моделирования бизнеса - специалисты, которые непосредственно занимаются созданием моделей существующего бизнеса, выработкой решений по реконструкции бизнеса, созданием моделей нового бизнеса, анализом и оценкой моделей и т.д. Они должны хорошо разбираться в деятельности компании, ее положении в соответствующей отрасли, внутренней организации компании, структуре ее продукции.
* Эксперт по методу - специалист или группа специалистов, отвечающие за используемую методологию. Они должны быть экспертами по данному методу и оказывать команде помощь, необходимую для его применения в данном конкретном проекте. От этих специалистов требуется также понимание деятельности компании и степени компетентности остальных членов команды по реинжинирингу.
* Группа прототипирования - специалисты, создающие компьютерные прототипы для исследования принимаемых решений и моделей. При использовании современных интегрированных инструментальных средств прототипы могут создаваться и группой моделирования бизнеса и отдельная группа прототипирования не нужна.
* Группа документирования - специалисты, занимающиеся документированием моделей бизнеса, а также обсуждением и проверкой моделей с клиентами, менеджерами и служащими компании и т.д. Эта группа планирует обучение работников компании, клиентов, партнеров новым способам ведения бизнеса. От специалистов по документированию требуются специальные навыки по составлению ясных, понятных описаний и документов.
* Координатор (группа координации) - специалисты, отвечающие за повторное использование смоделированной инфраструктуры в нескольких местах (например, в нескольких филиалах). Координатор должен оценить потенциальные возможности повторного применения разработанных моделей не только в рамках разрабатываемых проектов, но и для будущих проектов. Т.о. координация и управление библиотекой повторного использования должны иметь межпроектный статус.
* Администратор проекта - специалист, отвечающий за выполнение текущих планов с учетом стоимости и сроков разработки. В больших проектах такой администратор просто необходим.
В приведенную организационную структуру системы управления проектом по реинжинирингу не были включены владельцы ресурсов - руководители подразделений компании и сторонних организаций, сотрудники которых привлекаются к участию в проекте. Дело в том, что владельцы ресурсов непосредственно не участвуют в проекте по ренжинирингу, они лишь заключают соглашения о передаче своих сотрудников под управление владельцев процессов на время проведения проекта.
Планирование проведения реинжиниринга
Несмотря на наличие типовой технологии проведения реинжиниринга, определяющей типовую последовательность этапов реинжиниринга (см. рис. 1.2), типовой набор методик и инструментальных средств, для каждого конкретного проекта приходится проводить адаптацию типовой технологии к особенностям проекта. Каждый проект предъявляет свои особые требования к используемым методам, срокам, ресурсам, объему работ и т.д. Проекты по реинжинирингу могут отличаться по следующим аспектам:
* размер реконструируемой компании и масштаб реинжиниринга (отдел, компания в целом, совокупность компаний в рамках отрасли);
* сложность инфраструктуры бизнеса (степень диверсификации компании, территориальная разбросанность и др.);
* опыт разработчиков как в области реинжиниринга в целом, так и в использовании конкретных методологий;
* готовность копании к реинжинирингу (степень поддержки со стороны руководства и сотрудников компании.
До начала разработки необходимо принять основополагающие решения по способу организации процесса реинжиниринга, учитывающие особенности проекта. Конкретный способ организации работ по реинжинирингу можно назвать прецедентом разработки. Таким образом, планирование работы над проектом по реинжинирингу представляет собой описание прецедента разработки. Основными аспектами этого плана (описания) являются:
* последовательность этапов реинжиниринга,
* содержание этапов, включая конкретные виды работ, используемые методики и перечень разрабатываемых документов,
* способы взаимодействия участников проекта по реинжинирингу.
Последовательность этапов. Состав этапов для любого проекта примерно одинаков и включает в себя кроме подготовительного этапа этапы визуализации, прямого, обратного инжиниринга и внедрения. Однако схема применения этапов, порядок их следования и организация работ могут существенно отличаться. Существует несколько типовых схем организации работ, разработанных для процессов создания информационных (автоматизированных) систем, однако эти схемы могут быть распространены и на проекты по реинжинирингу. Различают 3 основных схемы [1,12]:
1. Каскадная (водопадная) схема предполагает строгое линейное следование этапов анализа, проектирования, реализации, внедрения и эксплуатации системы по единому заранее разработанному плану. Такая схема, обладая определенными преимуществами (детерминированность, логичность, простота), имеет существенные недостатки, главный из которых заключается в том, что к моменту завершения работ система "устаревала" по причине изменения требований пользователей и внешних ограничений.
2. Спиральная схема заключается в том, что разработка проекта ведется как бы по спирали, на каждом витке которой создается законченная версия системы. Создание каждой версии при этом предполагает последовательное выполнение всех этапов от анализа до внедрения. Каждый виток спирали представляет собой, таким образом, законченный проектный цикл по типу каскадной схемы. Такой подход обеспечивает на каждом витке уточнение требований к системе, однако сроки разработки готового продукта по сравнению с каскадной схемой еще более удлиняются, а затраты существенно возрастают.
3. Макетная схема (Другие названия: схема быстрого прототипирования, возвратная схема). Последовательность этапов в данной схеме внешне выглядит как каскадная, однако содержание технологических этапов таково, что многие проектные решения в процессе разработки системы подвергаются многократным уточнениям и корректировкам, как это предусмотрено спиральной моделью. Такой компромисс достигается за счет следующих особенностей процесса разработки:
* создание на различных этапах разработки системы вместо законченных прототипов макетов, представленных хотя бы и на бумаге, и оперативно проверяемых и обсуждаемых со всеми заинтересованными сторонами (будущими пользователями, заказчиками и т.д.);
* на любом этапе по результатам обсуждений макетов при необходимости принимается решение о возврате на любой из предыдущих этапов с целью корректировки принятых решений;
* параллельное (хотя бы частично) выполнение этапов и отдельных работ в рамках каждого этапа.
Таким образом, общее время разработки при использовании технологии быстрого прототипирования существенно сокращается по сравнению со спиральной моделью, при этом качество конечного продукта не теряется, а, возможно, и улучшается.
На рис. 4.3 приведены связи между этапами, характерные для каждой из рассмотренных схем разработки.

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

С некоторым сдвигом относительно начала выполнения подготовительного этапа запускается этап визуализации. После выполнения некоторых начальных процедур по визуализации инициируется параллельное выполнение этапа обратного инжиниринга. Возможно несколько итераций между этими двумя этапами. После того, как сформирована адекватная картина существующего бизнеса, инициируется этап прямого инжиниринга. После нескольких итераций этап визуализации заканчивается, и его результатом оказывается спецификация целей. Прямой инжиниринг исходит из этих спецификаций и моделей существующего бизнеса. Как только закончены разработка и тестирование отдельных процессов (пилотных проектов) может начинаться их внедрение. С учетом возможного параллельного выполнения нескольких версий картина еще более усложняется.
Содержание этапов (виды работ, методики и перечень документов). Ниже, в п. 4.2 - 4.4 будут описаны типовые работы, выполняемые на различных этапах, и используемые при этом методики. В целях конкретизации этих работ, необходимо осуществить оценку предполагаемых к использованию методов и моделей. Для оценки могут быть привлечены лидер проекта, эксперт по инжинирингу, эксперты по методам, ведущие менеджеры компании. Основываясь на полученных оценках, следует принимать решения о том, какие методы и модели, в каком объеме будут использоваться в данном проекте. Следует адаптировать работы, предполагаемые методом, чтобы обеспечить оптимальное достижение конкретного результата.
Кроме того, необходимо заранее определить перечень промежуточных и окончательных документов, которые следует разработать. Можно сэкономить много времени и сил, если составить образцы выпускаемых документов. В образце указывается, какого рода информация должна содержаться в каждом разделе и с какой степенью подробности она должна быть изложена. Составление образцов способствует единообразию документации, что особенно важно в тех случаях, когда документы подготавливаются разными исполнителями.
Способы взаимодействия участников проекта. Основным средством взаимодействия участников проекта по реинжинирингу, призванным обеспечить должное качество результата работ по реинжинирингу, являются обсуждения. Обсуждения необходимы, во-первых, для взаимоконтроля участниками проекта принятых решений, а во-вторых, для координации принимаемых решений.
Различают формальные и неформальные обсуждения. Цель формального обсуждения состоит в принятии решения о возможности перехода к очередному этапу разработки. Обсуждения этого типа проводятся по достижении каждого этапа проекта, причем они проводятся в расширенном составе - с привлечением клиентов и заказчиков. Цель неформального обсуждения состоит в выявлении ошибок. Эти обсуждения могут проводиться в любое время разработки, например, по завершении какой-либо локальной работы для проверки ее результатов. В неформальных обсуждениях, как правило, число участников ограничено - несколько разработчиков и, возможно, представитель группы поддержки качества.
Рассмотрим 3 вида обсуждений [3]:
1. Совещание. Совещания нужны для того, чтобы убедиться в полноте и согласованности всех полученных к текущему моменту результатов. Формальное совещание проводится по окончании каждого этапа. На нем рассматривается общий результат и принимается решение о переходе к следующему этапу разработки. При проведении совещания проверяются итоговые документы этапа: оцениваются принятые решения, выявляются ошибки. В таком совещании кроме владельцев процессов и членов команд должно принимать участие высшее руководство, т.к. только им может быть принято решение о переходе к следующему этапу.
На неформальных совещаниях членами команды обсуждаются созданные макеты и промежуточные документы. По итогам обсуждения вносятся необходимые коррективы и намечаются пути дальнейшей работы.
2. Инспекция. Это наиболее мощный из всех методов оценки и контроля. Представляет собой формальную методику оценки, результаты которой должны быть зафиксированы письменно. При проведении инспекции выделяют следующие конкретные роли ее участников:
* Арбитр - председатель, который обеспечивает создание творческой и продуктивной атмосферы и направляет деятельность участников на выявление ошибок;
* Секретарь - фиксирует каждую обнаруженную ошибку, ее приоритет и степень серьезности;
* Инспектор - несет ответственность за критический разбор;
* Автор или проектировщик - дает необходимые пояснения.
Итогом инспекционного обсуждения должно быть решение, принимается ли обсуждавшийся документ без изменений, принимается с внесенными корректировками или его принятие откладывается до очередной инспекции с тем, чтобы документ был доработан и исправлены все выявленные ошибки.
Инспекционное совещание должно длиться не более двух часов, и число участников не должно превышать 8 человек.
3. Прогон. Это неформальный способ оценки, при котором проектировщик "проводит" одного или нескольких членов команды, участвующих в проекте, через разработанный сегмент модели. Члены команды делают замечания по стилю методам, возможным ошибкам, нарушению стандартов и т.д. Все ошибки, обнаруженные во время прогона, должны быть зафиксированы проектировщиком для дальнейшей проработки. Однако никаких формальных записей и протоколов не требуется: цель прогона - дать проектировщику информацию, необходимую для коррекции его работы. Прогон представляет собой хорошее упражнение с широким обменом информацией.
Все описанные виды обсуждений направлены на проверку моделей с точки зрения их полноты, избыточности, структуры, ясности и понятности, отслеживания версий документов, стандартов и т.д. Как именно осуществляется проверка, в значительной степени зависит от цели обсуждения.
Подготовительный этап заканчивается, когда определены участники проекта по реинжинирингу, их роли и обязанности, составлен план работ по проекту, включающий виды работ, сроки их исполнения, требуемые ресурсы, виды документации, способы и сроки обсуждений результатов работ.

4.3. Разработка образа будущей компании

Цель этого этапа - разработать образ будущей компании и сформулировать его в терминах спецификации целей компании.
Основное содержание этапа визуализации (рис. 4.5):
* Анализ положения дел: выявление требований и ожиданий клиентов компании; сравнение компании с другими предприятиями из ее окружения и оценка уровня компании; понимание существующего бизнеса;
* Формирование спецификации целей на основе анализа возможных стратегий развития компании.

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

Требования клиентов. Очевидно, что наибольший импульс на улучшение бизнеса исходит от клиентов компании. Следовательно, необходимо анализировать и количественно оценивать ожидания (настоящие и будущие) клиентов компании. Анализ лучше всего проводить при помощи опроса клиентов, спонтанных интервью или систематических исследований. Рекомендуется применять для выявления нужд и желаний потребителей методы маркетинговых исследований. Выявление потребности клиентов по расширению и улучшению продуктов и услуг позволяют выявить процессы, нуждающиеся в наиболее срочном улучшении.
Оценка уровня. Оценка уровня может рассматриваться как средство визуализации того, как будет функционировать новая компания. При оценке уровня осуществляется сравнение компании с лучшими фирмами-конкурентами. Следует сосредоточить свое внимание на компаниях, которые работают в той же отрасли, и на компаниях в других отраслях, использующих подобные процессы. Для сравнения выбираются компании, отвечающие следующим требованиям:
* являются признанными лидерами в своей области;
* имеют хорошую репутацию;
* полностью удовлетворяют нужды пользователей;
* производят товары хорошего качества.
Понимание существующего бизнеса. Для разработки образа новой компании необходимо понять, как выглядит существующая компания. В компании, где применялся бизнес-реинжиниринг, эта модель уже существует. Если нет, то ее следует создать. На этапе визуализации создается обобщенная модель бизнеса, при этом:
- идентифицируются основные бизнес-процессы,
- выделяются и описываются приоритетные процессы,
- определяются измеримые свойства процессов (метрики).
В дальнейшем, на этапе обратного инжиниринга будет построена более подробная модель существующего бизнеса. Как правило, выполняется одна или несколько итераций между этапами визуализации и обратного инжиниринга. Сначала на этапе визуализации создается обобщенная модель существующего бизнеса и формируется первая версия спецификации целей. Затем на этапе обратного инжиниринга создается подробная модель, описывающая состояние бизнес-процессов в деталях, и на ее основе уточняются первоначальные цели и т.д. Таким образом, визуализация новой компании и обратный инжиниринг - это параллельные работы: работа по визуализации начинается до и кончается после работы по обратному инжинирингу.
Работа по пониманию существующего бизнеса начинается с идентификации, т.е. вычленения основных бизнес-процессов. Нужно помнить, что процессы моделируют завершенные потоки событий и должны иметь измеримую ценность для клиента (покупателя). Как правило, процессы пересекают границы существующих организационных подразделений, пронизывают их. Может оказаться, что определенные процессы не связаны с внешним по отношению к компании клиентом (субъектом). Это внутренние процессы, поддерживающие инфраструктуру бизнеса. Субъектами для таких процессов могут выступать остальные части компании, взаимодействующие с этим процессом.
При создании модели существующего бизнеса целесообразно сконцентрировать внимание на наиболее важных процессах. Не следует слишком распылять силы, лучше сосредоточиться на тех процессах, которые являются жизненно важными. Можно предложить следующие критерии выбора процессов для реинжиниринга:
* процессы, оказывающие наибольшее влияние на клиентов, улучшение которых позволит полнее удовлетворить ожидания клиентов (выявляются на основе анализа требований клиентов);
* процессы, эффективность которых наиболее низка по сравнению с аналогичными процессами в компаниях-лидерах (выявляются при оценке уровня);
* процессы, реинжиниринг которых может дать скорейшие позитивные результаты (выявляются по грубым оценкам экспертов-специалистов компании).
Выявленные наиболее подходящие для реинжиниринга процессы следует распределить в порядке важности. В дальнейшем моделирование бизнес-процессов должно происходить в соответствии с присвоенными им рангами: сначала моделируются наиболее важные процессы, затем менее важные и т.д..
Для выделенных приоритетных процессов следует составить описание. Причем на этапе визуализации составляется содержательное описание высокого уровня. Не следует создавать излишне подробные описания, т.к. они предназначены для того, чтобы стимулировать дискуссию о будущей компании. Детали могут быть отложены до этапа обратного инжиниринга. Описание процесса должно включать описание клиентов, поставщиков и других партнеров, описание входов, действий и продукции процесса.
Для каждого бизнес-процесса необходимо определить измеримые свойства (метрики), относительно которых можно оценивать существующий процесс, а в дальнейшем - различные варианты реконструкции процесса. Кроме того, когда новые процессы будут созданы, эти метрики можно использовать для контроля эффективности проведенных изменений, чтобы показать, как улучшилось функционирование процессов. Как сказал Дж. Харрингтон: "Измерения - это ключ. Если вы не можете измерить, то не сможете контролировать. Если не сможете контролировать, то не сможете управлять. Если не сможете управлять, то не сможете улучшить" [3].
Выбор метрик зависит от конкретного процесса. Обычно присутствуют метрики времени, цены и качества. Очень важно включить метрики, отражающие степень удовлетворения клиента (пользователя).
Спецификация целей компании.
Работа по спецификации целей начинается с предложения возможных альтернативных сценариев процессов (стратегий их развития). Это наиболее сложная, слабо формализуемая и творческая работа. Часто она начинается с "мозгового штурма", в ходе которого команда по реинжинирингу набрасывает первоначальный набор возможных стратегий. Никакое новое предположение относительно изменения процесса не должно считаться слишком эксцентричным до его опробования. В конце концов, именно странные идеи дали начало фундаментально новаторским решениям.
В ходе генерации возможных вариантов процессов обдумывается возможность применения принципов реинжиниринга (см. п. 2.1). Например, решаются вопросы:
- можно ли несколько работ объединить в одну, выполняемую одним человеком или командой?
- можно ли передать полномочия по принятию решений исполнителям?
- можно ли некоторые шаги процесса выполнять параллельно?
- можно ли выделить несколько версий процесса?
- можно ли минимизировать согласования, проверки и управляющие воздействия в ходе выполнения процесса?
При поиске ответов на поставленные вопросы должна учитываться возможность использования новых информационных технологий, т.к. именно новые ИТ позволяют кардинально изменить правила работы компании.
В соответствии с предложенными стратегиями изменения процессов необходимо построить прототипы новых процессов (сценарии) и осуществить их проверку. Прототип должен содержать: высокоуровневое описание будущего процесса, возможные последствия (приблизительный прогноз как изменятся характеристики процесса), факторы успеха и факторы риска.
Для оценки эффективности предлагаемых стратегий развития могут быть использованы метрики, предложенные ранее для каждого процесса. Если критерий не имеет количественного измерения, можно использовать экспертные оценки, переводящие качественные значения (плохо, удовлетворительно, хорошо и т.д.) в количественные. По результатам оценки следует "отсеять" заведомо плохие альтернативы.
Результатом работ по визуализации является спецификация целей компании, которая представляет образ новой компании. Она должна содержать:
* названия и краткую характеристику бизнес-процесов, подлежащих реинжинирингу;
* измеримые цели для каждого процесса, которые должны быть достигнуты в результате реинжиниринга (цена, качество, время, удовлетворение пользователя);
* высокоуровневое описание будущих процессов;
* список факторов успеха и риска.

4.4. Обратный инжиниринг

На рис. 4.6 приведено основное содержание этапа обратного инжиниринга.
При разработке образа будущего создается первая грубая модель бизнес-процессов, которую предполагается улучшить в ходе реинжиниринга. Спецификация целей используется в качестве входа для обратного инжиниринга. Результатом этапа обратного инжиниринга является модель текущего состояния бизнеса, представленная П-моделью и О-моделью. Модель существующего бизнеса в дальнейшем используется как для уточнения спецификации целей, так и в качестве основы для выполнения прямого инжиниринга компании.
Некоторые авторы полагают, что создавать модель существующего бизнеса необязательно, т.к. реинжиниринг предполагает проектирование "с чистого листа". Однако большинство авторов высказываются в пользу создания модели существующего бизнеса, т.к. это позволит:
* понять недостатки существующего бизнеса и определить "узкие места", т.е. те области, в которых стоит проводить изменения;
* объяснить сотрудникам, чем плохи прежние процедуры работы и почему они должны быть изменены;
* измерить характеристики процессов, которые должны быть изменены, и установить новые измеримые цели.
Следует подчеркнуть, что обратный инжиниринг имеет самостоятельную ценность вне зависимости от реинжиниринга компании, т.к. позволяет получить адекватную картину текущего положения дел в компании.
П-модель существующего бизнеса. Создание П-модели для приоритетных прецедентов, выявленных на этапе визуализации, начинается с выявления и описания субъектов, а также интерфейса прецедентов с субъектами. На рис. 3.1 (см. п. 3.2) приведена модель взаимодействия типовых субъектов и прецедентов. Во многих компаниях можно выделить следующие типы субъектов: Клиент (Покупатель), моделирующий людей или компании, проявляющих интерес к покупке продуктов; Пользователь, моделирующий людей, для которых производится продукция; Партнер, моделирующий людей или компании, способствующих разработке и производству продукции.
Не следует слишком подробно описывать субъекты, необходимо сосредоточиться на описании их обязательств по отношению к прецедентам и на описании конкретных взаимодействий субъектов с прецедентами.
Далее каждый приоритетный прецедент модели должен быть полностью описан в виде потока событий/состояний (см. п. 3.2). Описав основной ход событий прецедента, следует описать важнейшие альтернативные или дополнительные потоки событий и исключения. В процессе этой работы следует обращать особое внимание на обстоятельства, которые могут привести к прерыванию основного хода событий и переключению на другую последовательность событий.
Возможно структурирование прецедентов с помощью отношений наследования или "являться частью" (см. п.3.2), однако при моделировании существующего бизнеса не следует тратить на это слишком много времени.
После того, как основные прецеденты описаны, следует провести обсуждения. Следует обсудить такие вопросы, как: "правильно ли описано взаимодействие с субъектами?", "Все ли важные альтернативные потоки событий описаны?" и т.д. Для выявления всех ошибок на раннем этапе необходимо присутствие на совещании представителей команды по реинжинирингу и сотрудников компании, выполняющих данный процесс.

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

Анализ результатов. После составления моделей существующего бизнеса для каждого из приоритетных прецедентов необходимо выполнить анализ полученных результатов. При этом команде по реинжинирингу следует выполнить следующие действия [3].
1. Измерить основные характеристики прецедентов с помощью метрик, предложенных на этапе визуализации. Например, для прецедента "Обработка заказов" можно определить следующие метрики: средняя стоимость обработки одного заказа; среднее время обработки заказа; процент отказов и т.д. Полученные данные измерений будут впоследствии сравниваться со значениями модифицированных прецедентов.
2. "Прогнать" прецеденты по шагам и классифицировать каждое действие прецедента, как "Увеличивающее потребительскую Ценность продукта" (УЦ) или "Не Увеличивающее Ценность продукта" (НУЦ). После проведения классификации для каждого НУЦ-действия определяется действительная его необходимость. Следует рассмотреть возможность устранения НУЦ-действий. Некоторые НУЦ-действия не могут быть удалены, например, если они предписаны законодательством. Следует также определить стоимость выполнения всех действий и возможность уменьшения стоимости УЦ-действий и тех НУЦ-действий, которые нельзя удалить.
Такие "прогоны" прецедентов дают хорошую почву для оптимизации процесса.
3. Идентифицировать проблемы и ограничения, связанные с существующими прецедентами, основываясь на значении метрик и результатах "прогона" прецедентов. Можно также провести опрос персонала для того, чтобы понять проблемы и получить предложения по их усовершенствованию. Следует исследовать краткосрочные рационализаторские предложения по простому улучшению существующих прецедентов. Важно, чтобы персонал видел, что уже на раннем этапе по обновлению происходит прогресс, что повышает его мотивацию.
4. Рассмотреть вопросы компьютерной поддержки. Следует проанализировать, как существующие информационные системы (ИС) оптимизируют работу, обсудить достоинства и недостатки их использования. Исследовать, существует ли возможность увеличить эффективность применения существующих ИС или требуется построение совершенно новой ИС. Необходимо определить приоритетные процессы в создании компьютерной поддержки.
5. Скорректировать цели реинжиниринга, выдвинутые на этапе визуализации. Необходимо уточнить требования к будущим радикальным изменениям процессов, например, скорректировать измеримые цели, которые должны быть достигнуты в результате реинжиниринга (цена, качество, время, удовлетворение пользователя).

4.5. Прямой инжиниринг

На рис. 4.7 приведено основное содержание этапа прямого инжиниринга.

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

Построение П-модели нового бизнеса.
На этом этапе исследуется влияние спецификации целей компании на П-модель существующего бизнеса.
Создание П-моделей нового бизнеса полезно проводить группой, в которую входят: участники команды по реиинжинирингу; участники тех частей бизнеса, которые описываются в П-модели; консультант по реинжинирингу, имеющий опыт в этой области. Однако ответственность лежит на руководстве команды по реинжинирингу.
Построение П-модели нового бизнеса для каждого прецедента начинается с определения и описания субъектов. Необходимо проверить, не меняется ли роль субъектов, участвующих в существующем бизнесе, при определении новых целей бизнеса. Возможно, некоторые субъекты станут не нужны. Например, компания может больше не нуждаться в поставщике какого-то либо компонента продукции, начав производить его самостоятельно. Могут появиться совершенно новые субъекты. Часто бывает, что субъект имеет в новом бизнесе совершенно другую роль: определенные задачи, которые раньше выполнял этот субъект, теперь выполняет компания и наоборот.
После описания субъектов, их роли в новом бизнесе и отношений с прецедентом, следует приступить к определению прецедентов и описанию их в виде потока событий. Осуществляется интерактивное рассмотрение различных возможных П-моделей в поисках той, которая наилучшим образом отражает новые цели. Обычно эта задача решается методом "мозгового штурма" и, если возможно, с использованием прототипов (макетов). Прецедентов не должно быть слишком много. Считается, что большинство компаний описывается с помощью 10-20 прецедентов [3]. Рассмотрим некоторые общие характеристики "хорошего" прецедента [3]:
1. Прецедент должен быть четко определен и прост для понимания.
2. Все шаги прецедента должны по возможности способствовать увеличению ценности продукта для клиента, т.е. являться УЦ-действиями. Следует сократить ненужные проверки и согласования
3. В выполнении экземпляра прецедента должно участвовать как можно меньше людей. Если прецедент достаточно мал, то желательно выполнять его одним человеком. Наличие такого человека уменьшает количество передач дела из рук в руки, при которых возникают задержки, за счет чего временные показатели ухудшаются.
4. Важно, чтобы интерфейс с клиентом был настолько простым, насколько это возможно.
5. Люди, реализующие задачи прецедента, должны обладать необходимыми полномочиями. Они не должны ждать решения руководства, если произойдет что-то непредусмотренное, решения должны приниматься ими самостоятельно.
6. Должен существовать простой способ адаптации прецедента к любым ограничениям бизнеса. Прецедент, точнее его класс, может существовать в нескольких вариантах. В зависимости от конкретных условий выполняется тот или иной вариант.
После начального определения прецедентов необходимо структурировать П-модель. В п.3.2 были описаны 2 способа структурирования прецедентов. Структурирование прецедентов с помощью отношения наследования рекомендуется использовать в том случае, когда два (или более) прецедентов имеют достаточно похожее поведение и большая часть потоков событий одинакова. Структурирование с помощью отношения "являться частью" используется, когда целесообразно выделить фрагмент потока событий в отдельный прецедент: например, если фрагмент встречается в нескольких прецедентах или он имеет периодичность, отличающуюся от периодичности основного потока, или он рассматривается, как очень важный.
Созданную П-модель нового бизнеса следует документировать и обсудить на ряде совещаний. При этом нужно провести измерения новых процессов с помощью метрик, предложенных на этапе визуализации, и сравнить с результатами измерений процессов существующего бизнеса.

Построение О-модели нового бизнеса.
Формирование О-модели начинается с выделения объектов, участвующих в выполнении прецедентов. Необходимо проанализировать ход событий прецедента. Предметам, которые обрабатываются в ходе прецедента (продукты, материалы, документы), ставятся в соответствие объекты-сущности. Исполнителями прецедента являются управляющие или интерфейсные объекты. Следует стремиться к тому, чтобы один ресурс (объект) мог выполнить как можно большую часть работы.
Для событий, представляющих собой взаимодействие с субъектами, следует выделить интерфейсный объект (или несколько). Этот объект обслуживает контакты с окружением и по возможности большую часть внутреннего потока событий. В идеале вся работа, связанная с прецедентом, должна выполняться одним ресурсом - интерфейсным объектом. Если это невозможно, то для выполнения внутреннего потока событий назначается управляющий объект (или несколько). Интерфейсный объект в этом случае играет роль буфера между бизнесом и его окружением.
Каждому выделенному объекту дается краткое описание, отражающее его роль в прецеденте. Описание дается в терминах атрибутов. Для унификации и структурирования описаний объектов могут быть введены отношения наследования или "являться частью" ("состоять из"). Структурирование О-моделей с помощью этих отношений рассматривалось в п. 3.2.2 При использовании отношения наследования вводится абстрактный объект, отражающий общие свойства нескольких объектов. Отношение "являться частью" используется, чтобы разбить крупный объект на несколько более мелких. Это позволяет не включать в описание крупного объекта детали, содержащиеся в описании его частей.
Описание взаимодействия между объектами, возникающих в ходе выполнения прецедента, возможно в двух вариантах:
- в виде статической диаграммы, в которой отражаются все отношения коммуникации и использования, устанавливаемые между объектами при выполнении прецедента;
- в виде динамической диаграммы взаимодействия, наложенной на поток событий прецедента.
Вопросы формирования диаграмм взаимодействия объектов рассматривались в п. 3.2.2.
В ходе документирования и обсуждения О-модели нового бизнеса нужно проверить, достигаются ли поставленные на этапе визуализации измеримые цели. Если нет - следует проанализировать причину неудачи и, возможно, вернуться к одному из предыдущих этапов.

Разработка новой оргструктуры.
Создание новой организационной структуры, соответствующей новым перепроектированным бизнес-процессам, осуществляется на основе О-модели нового бизнеса. Разработка оргструктуры включает:
* сопоставление интерфейсным и управляющим объектам О-модели нового бизнеса реальных исполнителей - сотрудников функциональных подразделений компании;
* организацию командной работы - создание новых организационных подразделений (команд процессов), а также описание структуры взаимодействия между владельцами процессов, владельцами ресурсов и операторам процессов;
* определение прав и обязанностей сотрудников компании в соответствии с новой структурой организационных отношений, создание новых должностных инструкций;
* создание систем мотивации и оценок, отражающих новые убеждения и ценности, установленные компанией.
Поскольку создание новой оргструктуры предполагает определение, как реальные объекты бизнеса (сотрудники компании) участвуют в выполнении новых бизнес-процессов, организационную структуру иногда называют реальной объектной моделью в отличие от О-модели бизнеса, которую называют идеальной объектной моделью. Реальная объектная модель (оргструктура) создается путем адаптации идеальной объектной модели к реальным условиям.
Для того, чтобы сопоставить интерфейсным и управляющим объектам О-модели нового бизнеса реальных исполнителей полезно сначала выделить для каждого объекта все его обязательства (ответственность) во всех прецедентах и всех экземплярах прецедента с разными альтернативными потоками событий. Процедура выявления всех обязательств объекта описана в п.3.2.2.
При назначении реальных объектов может оказаться, что одному объекту О-модели сопоставляется несколько реальных исполнителей, т.к. один работник не в состоянии выполнить все обязательства, либо, наоборот, обязательства нескольких объектов О-модели может выполнить один исполнитель. Кроме того, когда несколько экземпляров прецедента могут выполняться одновременно, необходимо решить, может ли один и тот же исполнитель участвовать во всех экземплярах прецедента, либо для каждого экземпляра назначается свой исполнитель. Дополнительные ограничения появляются, если бизнес является географически распределенным.

<< Пред. стр. 3 (из 5) След. >>

Список литературы по разделу