Текст книги "Практика и проблематика моделирования бизнес-процессов"

Глава 3
Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке

Общий подход к проектированию

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

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

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

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

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

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

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

1. Идентификация критически важных для предприятия процессов (обычно не более восьми). Чаще всего это те ключевые процессы, которые:

♦ максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции;

♦ открывают новые возможности;

♦ в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов, имеют возможности для оптимизации затрат.

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

3. Построение модели высокого уровня для ключевых бизнес-процессов.

4. Определение для каждого шага процесса ответственных за выполнение шага. Это могут быть как внешние организации, так и подразделения компании.

5. Идентифицирование и документирование основных категорий информационных объектов.

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

♦ декомпозиция функций/процессов;

♦ анализ бизнес-событий.

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

1) каковы основные функции организации?

2) какие функции не несут в себе ценности?

3) какие функции пересекаются с другими бизнес-функциями?

Посредством декомпозиции и анализа бизнес-процессов должны быть получены следующие результаты:

♦ основные подпроцессы выбранных ключевых процессов (критически важных для бизнеса);

♦ границы основных организационных единиц;

♦ вклад каждой функции в цепочку создания добавочной стоимости;

♦ пересечения и излишние функции/процессы;

♦ возможные требования к прикладным системам и информации.

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

1) кто является инициатором бизнес-события?

2) кто является основными участниками события?

3) как событие обрабатывается в рамках «расширенного» предприятия (партнеры и прочее)?

4) возможны ли инновации, которые связаны с событием и требуются бизнесом?

Посредством анализа бизнес-событий должны быть получены следующие результаты:

♦ основные инициаторы и участники бизнес-событий;

♦ партнеры;

♦ критически важные результаты, создающиеся и используемые позже в процессе обработки события;

♦ возможные новые формы ведения бизнеса.

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

♦ моделирование местоположений выполнения функций/процессов;

♦ модель интеграции функций/процессов.

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

1) где выполняются основные функции?

2) какие функции связаны между собой?

3) существуют ли возможности по консолидации и рационализации? В результате мы должны получить:

♦ распределение функций по местоположениям;

♦ связи между бизнес-функциями;

♦ возможные требования к технологической архитектуре и архитектуре прикладных систем;

♦ возможные требования к организационным изменениям.

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

Результатами ее построения являются:

♦ ключевые внутренние и внешние точки интеграции;

♦ критичные информационные потоки между различными точками соединения моделей бизнес-событий;

♦ возможные требования к технологической архитектуре, архитектуре приложений и информации;

♦ возможные требования к организационным изменениям.

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

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

1) на что реагирует модель?

2) как реагирует модель?

Определение параметров вариативности модели и ее реализации

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

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

Ответ на вопрос «Лак реагирует модель?» предусматривает определение вариантов отклика элементов модели на изменение входных условий. Принципиально все варианты отклика основываются на различных сочетаниях изменений в составляющих общей модели:

♦ изменяется состав подпроцессов (функций, операций), входящих в модель;

♦ изменяется логическая последовательность исполнения подпроцессов (функций, операций), входящих в модель;

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

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

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

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

1. Прямое перечисление всех возможных входных ситуаций, формирование базы (набора) готовых моделей, каждая из которых в рамках прямого указания соответствует «своей» входной ситуации, – решение на основе прямого перебора (перечисления).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Применительно к «переборному» и «структурному» подходу построения модели можно определить следующие общие характерные последовательности шагов (табл. 2).

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

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

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

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

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

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

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

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

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