Архитектура предприятия.-7

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

Рис. 3.30. Карта знаний, ориентированная на организационную единицу

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

172 Глава 3. Методология ARIS для построения архитектуры…

Создание и применение знаний в бизнес-процессах компании моделируется с помощью типов моделей, используемых для представления бизнес-процессов (eEPC, eEPC с потоком материалов, «Офисный процесс», «Промышленный процесс», PCD, PCD с потоком материалов). Типы объектов «Категория знаний» и «Документированные знания» доступны в указанных диаграммах. Можно определить, какой тип знаний необходим для выполнения функции, и отметить, какие знания создаются и/или документируются, когда функция выполняется. Этот тип представления позволяет изучать бизнес-процессы в терминах обработки знаний. Например, может быть обнаружен пробел в необходимых знаниях и определен уровень повышения квалификации, требуемый при выполнении отдельной функции. Пример обработки знаний в модели eEPC показан на рис. 3.31.

3.8.Сравнительный анализ методологий ARIS и IDEF1

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

•целей проекта;

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

•возможностей CASE-систем по описанию процессов с учетом требований к разрабатываемой системе.

1 При написании параграфа 3.8 использованы материалы В. Репина [26].

Сравнительный анализ возможностей нотаций ARIS и IDEF приводится в табл. 3.2.

Одним из важнейших аспектов описания моделей бизнес-про- цессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, регламентирующих выполнение процедуры, и последовательности выполнения процедур во времени (запускающих событий). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления — стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих воздействий (например, документов и информации), полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель WorkFlow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться «за кадром» на 30–90 % (рис. 3.32).

На рис. 3.32 функция 4 является контрольной и служит для проверки результатов выполнения работы, исполняемой функциями 2 и 3. Но данная модель не отвечает на следующие вопросы:

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

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