Общее моделирование бизнеса

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

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

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

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

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

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

Концепция бизнес-инжиниринга основана на построении бизнес-модели компании. Эта модель состоит из следующих составляющих:

• • стратегическая модель;
• • организационно-функциональная модель;
• • модель бизнес-процессов;
• • количественная модель бизнес-процессов.

Бизнес-модель, построенная на основе концепции бизнес;

инжиниринга с определенной степенью детализации, приведена на рис. 19.

Рис. 19. Интегрированная бизнес-модель, построенная на основе концепции.

бизнес-инжиниринга [3].

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

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

Моделированию в бизнес-инжиниринге подвергаются структурированные объекты. Поэтому стратегия должна иметь определенную внутреннюю структуру. Для структурированного описания стратегий используются следующие учетные регистры:

• • регистры, фиксирующие в заданном формате результаты стратегического анализа (см. тему 3 настоящего пособия);
• • регистры, задающие в типовых разрезах стратегическую концепцию (см. тему 1): корпоративную стратегию; функциональные стратегии.

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

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

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

Модель организационной структуры включает (см. рис. 20):

Рис. 20. Основные компоненты модели организационной структуры [3].

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

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

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

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

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

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

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

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

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

Моделирование бизнес-процессов осуществляется разными способами. Более детально инструменты моделирования бизнеспроцессов будут проанализированы далее.

Следует отметить, что концепция бизнес-инжиниринга также поддерживается международной организацией по стандартизации ISO [11], которая в выработанных стандартах серии ISO 9000 предлагают документирование бизнес-процессов и закрепление их за исполнителями.

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

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

Рассмотрим моделирование процессов и реинжиниринг на примере концепции Архитектуры Интегрированных Информационных Систем (Architecture of Integrated Information Systems), АРИС [5, 6]. АРИС — это методология информационных систем. АРИС является более всеобъемлющей концепцией и включает в себя АБИ — концепцию Архитектуры Бизнес-Инжиниринга (АБИ). АБИ представляет собой четко сформулированную методологию проведения всего цикла работ по реформированию (совершенствованию) бизнеса: от формирования стратегических целей компании до подробнейшей спецификации проекта информационной системы.

Система (АРИС/ARIS) представляет собой комплекс средств анализа и моделирования деятельности предприятия, а также разработки автоматизированных информационных систем. В ее основу положена обширная методология, вобравшая в себя особенности различных методов моделирования. Разработчиком данной системы является германская фирма IDS, которая считается мировым лидером в области разработок инструментальных средств для анализа и реорганизации деловых процессов, а также хорошо известна в мире как консалтинговая фирма, занимающаяся реорганизацией бизнеса.

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

В АРИС важное место занимает базовая модель бизнес-процесса, от которой строятся более сложные модели: В АРИС описываются субъекты процесса и вес виды потоков, проистекающих в рамках бизнес-процесса.

Кратко опишем используемые модели бизнес-процессов (рис. 21):

Рис. 21. Модель бизнес-процесса, построенная на основе диаграммы

взаимодействия

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

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

Рис. 22. Функциональная модель бизнес-процесса

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

На рис. 23 представлена модель бизнес-процесса, отражающая поток выходов.

Рис. 23. Модель бизнес-процесса, отражающая поток выходов.

Приведенная на рис. 23 иллюстрация выходного потока не позволяет однозначно описать последовательность выполнения функций.

Рис. 24. Информационная модель бизнес-процесса.

На рис. 24 приведена информационная модель бизнес-процесса.

Поскольку поток данных активизируется функциями, связанными с информационными объектами, функциональный поток на рис. 24 просматривается (изделие — запасы — проверка заказа).

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

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

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

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

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

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

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

со о>

Рис. 25. ARIS-модсль бизнсс-процссса После того как события «Производственный план составлен» и «Заказ (поставщику) обработан» посредством соответствующих сообщений активизируется функция «Изготовление изделия». Затем происходит событие «Изделие выполнено». Таким образом, данный процесс завершается, и это событие посредством сообщений активизирует наступление последующих событий.

События, имеющие отношение к непрерывному бизнес-процессу, называются релевантными. Потоки функций, управляемые событиями, известны также под названием Event-driven Process Chain (ЕРС) — событийные диаграммы процесса.

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

Помимо уже описанных в простейших моделях бизнес-процессов видов потоков в АРИС-модели используются и другие. Далее приводится описание всех видов потоков.

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

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

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

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

Совокупность конкретных процессов составляет класс, или тип. Конкретные процессы являются экземплярами (элементами) этого класса. Классы «перенимают» характеристики своих элементов, хотя каждый из классов — это абстракция отдельных его экземпляров. Представление экземпляров называется 1-м уровнем описания; уровни типа называются 2-м уровнем описания. Таким образом, 1-и и 2-й уровни находятся в таком же отношении, как классы и экземпляры.

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

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

Вследствие большого разнообразия классов и их семантических взаимоотношений модели бизнес-процессов могут быть структурированы с высокой степенью детализации. Полученная при этом структура называется «Архитектурой интегрированных информационных систем» (AR1S).

Метамодель бизнес-процесса объединяет следующие классы:

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

Методология, используемая ARIS, представляет собой множество различных методологий, интегрированных в рамках системного подхода. Это позволяет говорить о единой архитектуре рассматриваемой методологии. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

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

Рис. 26. Взаимосвязь типов моделей, используемых ARIS.

ARIS поддерживает большое количество методов моделирования, используемых для построения этих моделей. Среди них такие известные методы, как диаграммы Чена, Unified Modeling Language (UML), Object Modeling Technique (OMT) и так далее.

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

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

• • Уровень определения требований. На данном уровне разрабатываются модели, описывающие то, что должна делать система: как она организована, какие деловые процессы в ней присутствуют, какие данные при этом используются;
• • Уровень проектной спецификации. Этот уровень соответствует концепции информационной системы, определяющей основные пути реализации предъявленных на втором этапе требований;
• • Уровень описания реализации. На данном этапе жизненного цикла создания информационных систем происходит преобразование спецификации в физическое описание конкретных программных и технических средств. Это заключительный этап проектирования систем, за которым следует этап физической реализации (программирования).

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

Графически такое разделение по уровням в ARIS выглядит следующим образом (см. рис. 27):

Рис. 27. Уровни представления моделей bARIS

Выделяется также фаза описания текущего состояния деятельности.

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