Е. Всяких - Практика и проблематика моделирования бизнес-процессов
♦ IDEF9 (Business Constraint Discovery) – стандарт описания бизнес-ограничений, используется при определении и анализе ограничений, в которых действует организация.
♦ IDEF14 (Network Design) – стандарт проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.
Глава 3
Как проектировать архитектуру модели бизнес-процессов организации: методические рекомендации и подходы по разработке
Общий подход к проектированию
Очевидно, что заказчика интересуют в первую очередь потребительские качества модели – что может и что дает модель, и в гораздо меньшей степени – как это реализовано. На наш взгляд, это может быть оправдано далеко не во всех ситуациях. Заказчик должен понимать и задавать общие контуры проектных решений, поскольку именно в них кроятся возможности и проблемы использования и развития модели.
Существует ряд ключевых методологических моментов при проектировании модели бизнес-архитектуры, которые могут быть интуитивно понятны (либо объяснены) заказчику, имеющему самые общие представления о моделировании, и контроль которых на начальных стадиях проекта позволит избежать в дальнейшем ошибок и разочарований в получаемых результатах.
Несомненно, подходы к проектированию бизнес-архитектуры определяются целевыми задачами, которые ставятся соответствующим заказчиком, и имеют свою специфику. Таких целей может существовать много не только в рамках охватываемого поля заказчиков (как организации), но и внутри самого заказчика. Вместе с тем можно выделить ряд общих моментов, которые так или иначе должны быть реализованы.
Одним из таких обязательных условий для успешности проекта является поддержка возможности наблюдения и анализа объекта изучения с различных точек зрения. Помимо того что «потребительские» качества модели очень сильно зависят от того, насколько полно отражены интересующие свойства бизнес-процесса для конкретной группы пользователей, в общеметодологическом плане выстраивание целостной картины невозможно в рамках одностороннего рассмотрения.
Вторым значимым моментом является синтез (интеграция) моделей локальных компонент в единую модель бизнес-архитектуры с возможностью различных вариантов ее представления, исходя из постановок задач. Многогранность «синтетических» моделей определяет качество и универсальность использования разработанной архитектуры бизнес-процессов.
Основное внимание при разработке бизнес-архитектуры должно уделяться картине в целом, поэтому рекомендуется начать с построения высокоуровневых моделей бизнес-процессов предприятия. Выскоуровневые модели, включенные в бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Из 10–20 основных процессов в первую очередь необходимо сосредоточиться на тех процессах, которые будут подвергнуты изменениям.
Основные шаги, которые требуется выполнить для построения высокоуровневых моделей, следующие.
1. Идентификация критически важных для предприятия процессов (обычно не более восьми). Чаще всего это те ключевые процессы, которые:
♦ максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции;
♦ открывают новые возможности;
♦ в настоящее время выполняются плохо и являются источниками неудовлетворенности клиентов, имеют возможности для оптимизации затрат.
2. Прослеживание связи между этими процессами и бизнес-стратегией, движущими силами и критически важными факторами успеха.
3. Построение модели высокого уровня для ключевых бизнес-процессов.
4. Определение для каждого шага процесса ответственных за выполнение шага. Это могут быть как внешние организации, так и подразделения компании.
5. Идентифицирование и документирование основных категорий информационных объектов.
Построение таких моделей и понимание их связей с ключевыми факторами позволяет понять в целом деятельность организации. Последующее углубление в тщательно отобранные ключевые процессы и информационные потоки возможно с использованием основных инструментов, таких как:
♦ декомпозиция функций/процессов;
♦ анализ бизнес-событий.
Декомпозиция бизнес-процессов позволяет преодолеть сложность описываемой предметной области, представить объекты модели верхнего уровня в виде другой модели, раскрывающей то или иное внутреннее содержание данного объекта. Основные вопросы, на которые необходимо ответить при осуществлении декомпозиции бизнес-процессов:
1) каковы основные функции организации?
2) какие функции не несут в себе ценности?
3) какие функции пересекаются с другими бизнес-функциями?
Посредством декомпозиции и анализа бизнес-процессов должны быть получены следующие результаты:
♦ основные подпроцессы выбранных ключевых процессов (критически важных для бизнеса);
♦ границы основных организационных единиц;
♦ вклад каждой функции в цепочку создания добавочной стоимости;
♦ пересечения и излишние функции/процессы;
♦ возможные требования к прикладным системам и информации.
Анализ бизнес-событий позволяет понять, как инициируются бизнес-события и какие связанные с ними процессы происходят в цепочке создания добавочной стоимости предприятия. При этом берется конкретное событие, документируется текущий процесс его обработки и оцениваются возможности по его совершенствованию. Основные вопросы, на которые необходимо ответить при таком анализе:
1) кто является инициатором бизнес-события?
2) кто является основными участниками события?
3) как событие обрабатывается в рамках «расширенного» предприятия (партнеры и прочее)?
4) возможны ли инновации, которые связаны с событием и требуются бизнесом?
Посредством анализа бизнес-событий должны быть получены следующие результаты:
♦ основные инициаторы и участники бизнес-событий;
♦ партнеры;
♦ критически важные результаты, создающиеся и используемые позже в процессе обработки события;
♦ возможные новые формы ведения бизнеса.
Для построения в дальнейшем технологической архитектуры необходимо понимание того, где выполняются функции и процессы, а для построения архитектуры информации и архитектуры прикладных систем необходимо понимание ключевых внутренних и внешних точек интеграции, основных информационных потоков между участниками бизнес-процессов. Поэтому важно рассмотреть еще два аспекта:
♦ моделирование местоположений выполнения функций/процессов;
♦ модель интеграции функций/процессов.
Модель местоположений обеспечивает логистический взгляд на функции, выполняемые организацией, и идентифицирует в географическом плане то место, где они выполняются. Основные вопросы, на которые необходимо ответить при моделировании местоположений:
1) где выполняются основные функции?
2) какие функции связаны между собой?
3) существуют ли возможности по консолидации и рационализации? В результате мы должны получить:
♦ распределение функций по местоположениям;
♦ связи между бизнес-функциями;
♦ возможные требования к технологической архитектуре и архитектуре прикладных систем;
♦ возможные требования к организационным изменениям.
Модель интеграции отражает высокоуровневые требования к интерфейсам между процессами и бизнес-событиями, требования к информации для новых бизнес-процессов, временные требования.
Результатами ее построения являются:
♦ ключевые внутренние и внешние точки интеграции;
♦ критичные информационные потоки между различными точками соединения моделей бизнес-событий;
♦ возможные требования к технологической архитектуре, архитектуре приложений и информации;
♦ возможные требования к организационным изменениям.
Основополагающим требованием при построении модели бизнес-архитектуры является обеспечение ее адекватности, то есть достижение разумного баланса между детальностью и потребительскими качествами модели.
В условиях, когда определены (заданы) цели моделирования, то есть получены ответы на вопрос «для чего нужна модель», когда отобраны ключевые процессы для моделирования, следующим входным условием для старта проектирования является согласование между заказчиком и исполнителем понимания по вопросам, определяющим границы моделирования, а именно:
