В целом необходимо отметить, что тестирование модели, подобно тестированию любой другой информационной системы, должно осуществляется в соответствии с хорошо зарекомендовавшими себя практиками и стандартами [17].
Обязательным этапом, предваряющим реализацию проектных решений построения модели бизнес-архитектуры, является разработка Соглашения о моделировании – свода единых правил моделирования.
Разработка Соглашения о моделировании
Соглашение о моделировании предназначено как для специалистов исполнителя, знающих принципы моделирования и интерфейс пользователя инструментальной системы, так и для сотрудников заказчика, проводящих экспертизу качества построенных моделей в рамках установленных границ проекта.
В рамках данного документа должны быть зафиксированы цели и задачи проекта, методические и технологические подходы по моделированию бизнес-процессов описываемой предметной области. Соглашение формирует единый язык общения внутри команды проекта и внутри организации заказчика при дальнейшем самостоятельном проектировании бизнес-процессов. Кроме того, позволяет настроить инструментальное средство моделирования для эффективной работы пользователей и последующей корректной генерации отчетов.
В рамках Соглашения целесообразно "зафиксировать" следующие основные вопросы проектирования модели.
♦ Концепция проекта. В данном разделе необходимо отобразить общую концепцию проекта, а именно указать цели и задачи проекта моделирования, используемые инструментальные средства поддержки, методологические подходы к построению бизнес-архитектуры, возможные ограничения при этом.
♦ Определение уровней моделирования. При определении уровней моделирования необходимо исходить из принципа разумной достаточности, то есть решение не должно быть слишком сложным по сравнению с самой решаемой задачей.
♦ Определение чувствительности моделей. В данном разделе уточняется, на что и каким образом будет реагировать создаваемая модель, то есть определяется набор входных параметров (параметров различий) модели и предлагаемый вариант реализации учета этих различий (чувствительности) моделей.
♦ Структура хранения моделей в базе данных. Элементы проекта, такие как модели и объекты (активности), желательно структурировать в определенные папки проекта в инструментальной среде.
При создании иерархии папок возможно использование нескольких критериев:
♦ согласно этапам проведения проекта;
♦ согласно процессно-ориентированной структуре;
♦ согласно функциональной структуре компании;
♦ согласно описываемым предметным областям;
♦ комбинации указанных выше критериев.
В данном разделе указываются выбранные критерии построения и непосредственно общая структура папок.
♦ Выбор моделей, используемых в проекте. Для обеспечения единой идеологии моделирования в рамках каждого проекта необходимо определиться с используемыми типами моделей. Выбор моделей напрямую зависит от целей проекта и ожидаемого результата, так как типы моделей представляют собой различные методы моделирования, они могут как дополнять друг друга, так и являться альтернативой друг другу.
♦ Спецификация типов объектов и используемых символов. Для обеспечения единой идеологии моделирования также необходимо определиться с используемыми типами объектов выбранных моделей. Данный выбор объектов осуществляется на основе поставленных целей моделирования и знаний таких основ, как:
– каждый тип объекта несет свое определенное значение в методологии и имеет специфические характеристики, определяющие конкретный объект данного типа;
– каждый тип объекта может использоваться в одном или нескольких типах моделей;
– каждый тип объекта может быть представлен одним или несколькими символами.
Также необходимо указать, на какие типы моделей могут быть детализированы те или иные типы объектов.
♦ Спецификация используемых типов связей. Типы связей определяют возможные взаимоотношения между объектами. В данном разделе необходимо указать, какие типы связей и между какими объектами будут использоваться в проекте.
Данный выбор типов связей осуществляется на основе поставленных целей моделирования и знаний таких основ, как:
– один и тот же тип связей между типами объектов может присутствовать в нескольких типах моделей;
– между двумя объектами может быть проведено несколько связей различного типа.
♦ Спецификация поддерживаемых типов атрибутов. Выбор типов атрибутов зависит от решаемых в рамках проекта задач, например для проекта по оптимизации продолжительности выполнения процессов необходимо задавать значения времени выполнения отдельных функций, а для других проектов этот атрибут использовать не имеет смысла. Участник проекта должен видеть только те атрибуты, которые он обязан задать, однако при этом некоторые из атрибутов могут быть необязательными, что и оговаривается в принимаемых Соглашениях о моделировании по проекту.
Выбор типов атрибутов основывается на знании того, что:
– каждый тип модели, объекта или связи обладает специфичным набором атрибутов;
– есть набор атрибутов, существующий у каждого типа модели, объекта или связи, например: Имя, Полное имя, Описание, Автор и др.;
– другие атрибуты могут существовать только для определенных типов модели, объекта или связи, например "Количество сотрудников" для объекта Подразделение.
♦ Определение соглашений по присвоению имен. В рамках проекта объекты зачастую идентифицируются при помощи их имен. Строгие правила присвоения имен объектам повышают целостность проекта, увеличивают удобство чтения моделей, облегчают поиск объектов в базе. Правила именования должны стать стандартом проекта и быть доведены до сведения каждого участника. Правила именования должны быть определены для каждого используемого типа объектов. Различают синтаксический и семантический аспекты задания правил именования.
Пример синтаксического аспекта наименования функции: "Проверка документов" – имя должно состоять из двух обязательных частей – отглагольного существительного, описывающего выполняемую функцию, и существительного, показывающего объект, над которым она выполняется.
Сам по себе синтаксический аспект именования не может гарантировать единства названий в проводимом проекте. Одно и то же действие может быть названо несколькими способами с использованием слов, близких по смыслу. Например, "Создать договор" и "Составить договор". Для решения данной проблемы целесообразно составить глоссарий терминов, которые должны быть использованы при задании имен объектам.
♦ Определение соглашений по графике. В данном разделе могут быть заданы правила взаимного расположения объектов на модели. Например, для иерархических моделей определяется, начиная с какого уровня иерархии происходит переход с горизонтального расположения объектов на вертикальное. Для моделей процессов определяется расположение графа – горизонтально или вертикально. Помимо этого, для удобства восприятия создаваемых моделей, возможно, потребуется установить ряд правил графического расположения определенных типов объектов и связей. Например:
– расположение последовательности событий и функций сверху вниз, то есть входящие стрелки в функцию должны быть расположены сверху, а исходящие стрелки из функции – снизу;
– потоки данных отображаются слева от функции, где входные документы (данные), обрабатываемые или используемые функцией, изображаются слева от функции входной стрелкой, а исходящие документы (данные), генерируемые функцией, изображаются слева от функции исходящей стрелкой;
– оргединицы и роли отображаются справа от функции.
Для повышения информативности модели определяется набор атрибутов объектов, значения которых выносятся непосредственно на графику моделей.
Например, в проектах, связанных с динамическим моделированием, статистика моделирования по каждой функции может быть представлена непосредственно на графике модели.
Кроме того, определяется ориентировочное количество объектов, которые должна содержать диаграмма, для того чтобы она легко читалась при ее распечатке на листе формата А4 или A3. Также определяется внешний вид элементов используемой нотации (цвет, форма, толщина линий, размеры объекта, формат и наклон текста).
♦ Определение правил целостности моделей. Под целостностью моделей понимается свойство моделей, означающее, что модели бизнес-процессов содержат полную и непротиворечивую информацию, необходимую для корректного отображения выбранной предметной области, и имеют заранее определенные вид и качество. Определяется набор параметров проверки целостности моделей с соответствующим каждому параметру методом оценки модели. Например, могут использоваться такие параметры, как:
1) адекватность модели – соответствие модели моделируемому объекту или процессу. Модель адекватна, если все ее элементы (объекты и связи) имеют прообраз в моделируемой предметной области. Если в модели отображены не все нужные объекты, а "лишних" элементов нет, то считаем, что модель адекватна, но не полна;
2) корректность модели – соответствие исполнения модели бизнес-процесса установленным для конкретной методологии или нотации семантическим и синтаксическим правилам. Модель корректна, если создана в соответствии с правилами оформления, установленными методологией моделирования и другими требованиями;
3) полнота модели – присутствие в модели всех необходимых объектов и связей предметной области (выделенного бизнес-процесса). Модель полна, если она содержит все допустимые заданной методологией элементы предметной области, которые должны быть отображены для достижения целей моделирования и т. д.
♦ Описание создаваемой документации (отчеты). В данном разделе стоит указать требуемый заказчиком состав отчетов, их форму и содержание, которые должны быть получены по результатам проекта.
♦ Определение методики управления базой данных. В данном разделе необходимо указать общие принципы централизованного управления базой данных (физическое размещение БД, поддержка версионности БД, периодичность архивации, принципы и периодичность объединения нескольких локальных баз в одну и т. д.) и организации доступа к ней групп различных пользователей.
Основные этапы по проектированию
После определения целей, задач и основных соглашений по моделированию дальнейшая последовательность шагов по проектированию моделей бизнес-процесса состоит в следующем.
1. Систематизация и нормализация входных параметров для формирования областей допустимых значений.
2. Проектирование компонент модели (организационной, информационной, функциональной, модели выходов) с учетом обеспечения формы реакции на входные условия:
а) классификация и кодирование;
б) детализация;
в) взаимосвязь с входными условиями.
3. Проектирование описательной процессной модели (модели управления).
4. Проектирование форм отчетов.
5. Проектирование интерактивной модели.
6. Проектирование имитационной модели.
7. Тестирование разработанной модели
Проектирование моделей "как должно быть" и GAP-анализ
Общая методология построения бизнес-моделей требует рассмотрения трех промежутков времени:
♦ текущего (модели "как есть");
♦ ближайшего будущего на среднесрочную перспективу (модели "как должно быть" – вариант 1);
♦ отдаленного будущего на долгосрочную перспективу (модели "как должно быть" – вариант 2).
Под среднесрочной перспективой компания Gartner рекомендует рассматривать временной горизонт от 9 до 18 месяцев, а под долгосрочной перспективой – в 30 месяцев. Такие сроки обусловлены влиянием глобального ускорения бизнес-процессов и постоянного развития информационных технологий.
Gartner рекомендует 15 % усилий и внимания уделять существующей сегодня в организации бизнес-архитектуре, 70 % – бизнес-архитектуре, которую предполагается реализовать в ближайшем будущем, и еще 15 % усилий – бизнес-архитектуре, как она видится в отдаленной перспективе.
Работы по моделированию текущих процессов, связанные с анализом и документированием текущей бизнес-архитектуры, имеют важное значение с точки зрения каталогизации существующих связей, но их ценность не очень велика с точки зрения обеспечения гибкости и динамичности организации. Наиболее ценно построение бизнес-архитектуры "завтрашнего дня", так как принятие правильных решений на уровне непосредственных ближайших шагов гораздо важнее, чем определение конечной цели.
Если говорить про распределение усилий на различных фазах построения бизнес-архитектуры, то 40 % всей усилий должны занимать управление и надзор над процессом создания, порядка 30 % усилий – собственно разработка моделей, решений и их документирование. И примерно по 15 % усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений и на проведении оценки и сравнительного анализа с лучшими мировыми практиками или доступными аналогами.
Как правило, построение модели бизнес-архитектуры преследует задачу оптимизации текущей деятельности организации. Для этого осуществляются поиск и отображение будущего оптимального состояния, которое определяется моделью "как должно быть".
Для формирования модели "бизнес-архитектуры" для состояния "как должно быть" может быть использована следующая типовая последовательность шагов.
1. Проведение мониторинга существующих тенденций в области деятельности организации и тенденций в области развития технологий, обеспечивающих поддержку ее деятельности.
2. Анализ движущих сил, которые влияют на организационно-технологическую структуру организации с точки зрения основных функций и бизнеса организации.
3. На основе этого анализа формулируются в самом общем виде требования к организационной, функциональной и технологической компонентам.
Данные шаги сопровождаются формированием (в случае отсутствия) методологической основы проектирования, а именно: принимаются общие для организации стандарты и понятия о том, что такое бизнес-архитектура предприятия, включая определение принципов, общих методов описания архитектуры и ее разделы, стандарты, конкретные продукты и технологии.
Результаты вышеперечисленных этапов являются основой для выполнения Gap-анализа, то есть выявления расхождений и различий между существующей и оптимизированной бизнес-архитектурой предприятия.
Gap-анализ является существенным элементом процесса создания бизнес-архитектуры предприятия. Он охватывает как бизнес-архитектуры предприятия в целом, так и ее отдельные домены. Этот анализ является критически важным с точки зрения определения ключевых шагов и необходимых изменений в направлении целевой архитектуры.
На этапе Gap-анализа осуществляются:
♦ идентификация и категорирование несоответствий между текущим и целевым состояниями;
♦ сбор и совместное обобщение требований к организационной, функциональной, информационной и технологическим компонентам модели бизнес-архитектуры;
♦ планирование мероприятий по переходу из текущего (состояние "как есть") в целевое (состояние "как должно быть").
Выявляемые в рамках Gap-анализа несоответствия могут быть связаны с вопросами культуры организации, структурными проблемами, функциональными или же процедурными вопросами [14].
Под структурными несоответствиями понимаются несоответствия между существующим и целевым состояниями, связанные с вопросами организационно-технологической инфраструктуры. Предметом анализа при выявлении такого рода несоответствий являются реализуемые принципы построения архитектуры и архитектура отдельных компонует бизнес-модели.
Функциональные несоответствия в бизнес-архитектуре связаны с потребностями по поддержке новых бизнес-процессов, которые необходимы для реализации новых бизнес-стратегий. Мероприятия по устранению данных несоответствий направлены на соответствующие изменения в соответствующих компонентах бизнес-архитектуры (бизнес-логике, организационной структуре, технологической структуре и т. д.).
Культурные несоответствия связаны с текущим уровнем навыков и компетенцией организационной структуры и требуемыми навыками, компетенциями организационной структуры, которые необходимы для целевого состояния.
В обобщенном виде процесс Gap-анализа предусматривает выполнение следующих шагов [4].
1. Идентификация различий между существующей и целевой бизнес-архитектурами.
2. Формирование перечня идентифицированных несоответствий с разбивкой по категориям (в том числе компонентам бизнес-архитектуры) и определение состава требуемых изменений.
3. Идентификация уже имеющихся возможностей организационно-технологической архитектуры, которые могут быть использованы для решения идентифицированных проблемных мест, и обновление списка несоответствий с учетом этого фактора.
4. Группировка идентифицированных несоответствий по типу их влияния на деятельность предприятия (уровень предприятия в целом, уровень нескольких подразделений и функций, уровень отдельного подразделения и функции, особые случаи).
Для категоризации несоответствий можно, в частности, использовать матрицу, показанную в табл. 4.
Могут существовать различные ситуации, связанные с количеством выявленных несоответствий между текущим и целевым состояниями. Одной из причин незначительного количества найденных несоответствий может быть недостаточный уровень детализации состояний. Обратная ситуация с "неожиданно" большим количеством различий может быть обусловлена избыточным уровнем детализации целевого состояния на отдаленную перспективу и "пропуском" промежуточных целевых состояний, через которые должен осуществляться переход.
Наиболее "естественной" выглядит такая ситуация, когда происходит постепенное наращивание общего количества выявленных несоответствий по мере повышения уровня детализации описаний состояний бизнес-архитектуры и поэтапного движения по временной шкале сравниваемых состояний.
Результаты Gap-анализа ложатся в основу Плана миграции (модернизация) организационно-технологической архитектуры предприятия по всем ключевым компонентам:
♦ информационным потокам;
♦ функциям;
♦ организационной структуре;
♦ ИТ и производственным технологиям и т. д.
На этом этапе осуществляются детализация постановок задач по проектам и мероприятиям, связанным с достижением целевого состояния бизнес-архитектуры предприятия, определение стратегии модернизации, в том числе в части выделения критичных (приоритетных) бизнес-процессов и технологий.