Динамическое моделирование предприятия: Подход Baan и референсные модели

Введение

Динамическое моделирование предприятия (DEM) — это подход к моделированию предприятия, разработанный компанией Baan и используемый для системы планирования ресурсов предприятия Baan, целью которого является согласование и внедрение системы в организационную структуру компании-пользователя. Согласно Koning (2008), компания Baan представила динамическое моделирование предприятия в 1996 году как "средство внедрения продукта Baan ERP". Моделирование было сосредоточено на методе моделирования бизнес-процессов на основе сетей Петри, к которому должны были быть привязаны функциональные модули приложения Baan. DEM также включает инструмент для построения диаграмм цепочек поставок, отображающих логистическую сеть компании, и диаграмм моделирования функций предприятия.

Обзор

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

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

Создание модели управления бизнесом

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

A business control model is constructed according to a set path. First, the scope of the business is defined. The scope includes scoping what to model and includes the definition of the agents and external business functions that relate to the business. Next, the scope is depicted to a model of the black box with al the agents and external business functions surrounding the black box. The next step is to define the process and information flows (request feedback flows) between the agents and external business functions to and from the black box of the business control model. Defining the request feedback flows enables the modeler to define what processes are inside the black box. After creating the main business functions within the business control model, the several business functions are detailed out. In case of a production business it is vital to define the customer order decoupling point, referring to the split in the physical process where processes are based on the customer order instead of forecasts. Service based businesses on the other hand do not have a physical goods flow and thus do not require a physical process model. It is however imaginable that the same type of process flow can be utilized to construct a business control model for a service based business, as a service can be interpreted as a product as well. In this way, a business control model can be constructed similarly for a service based business as for a physical goods production business, having intangible goods instead of tangible. Next to the low level physical production process, the high level business functions need to be defined as well. In most cases the higher level business functions relate to planning functions and other tactical and strategical business functions, followed by functions as sales and purchase. After high level detail definitions, the business functions are decomposed to lower level detail definitions to make the business control model alienable to the lower models within the reference model, for this practice, mainly the Business Process Model. In the Business Process Model the processes are elaborated until the lowest level of detail. Given this level of detail, the Baan software functionality is then projected on the processes, depicted in the Business Process Model.

Модель бизнес-процесса

Моделирование процессов в DEM, моделирование бизнес-процессов осуществляется с использованием строительных блоков сети Петри. DEM использует 4 конструктивных элемента:

Состояние: Элемент состояния представляет состояние токена задания и за ним следует активность, выполняющая токен задания из этого состояния. Активность обработки: Активность обработки – это активность, которая обрабатывает токен задания состояния, преобразуя состояние токена задания в другое состояние. Контрольная активность: Контрольная активность управляет ходом процесса, но не выполняет его. Подпроцесс: Подпроцесс представляет собой совокупность различных процессов, объединенных в единый элемент посредством управления сложностью. Эти 4 конструктивных элемента обеспечивают моделирование моделей DEM. Моделирование осуществляется в соответствии с набором ограничений моделирования, направляющих процесс моделирования для создания схожих моделей разными разработчиками. Контрольные активности существуют в различных структурах для определения различных возможных маршрутов потоков процесса. Используемые структуры для контрольных активностей:

OR-разветвление / XOR-разветвление: Эта структура создает 2 новых состояния из 1 состояния, сигнализируя о создании 2 токенов задания из 1 токена задания. Если новое состояние может быть достигнуто по обоим выходным токенам, то разветвление является OR, в противном случае разветвление является исключающим OR-разветвлением (XOR). Конструкция AND-соединения: Для активации контрольной активности требуются 2 токена задания, создавая 1 новый токен задания (следовательно, 1 новое состояние). OR-соединение / XOR-соединение: Для активации контрольной активности требуются 2 токена задания, создавая 1 новый токен задания. OR означает, что для создания выходного токена задания можно использовать один из двух входящих токенов задания или оба, XOR означает, что для создания выходного токена задания можно использовать только один из токенов.

Пример

Приведенный ниже пример демонстрирует моделирование концепции брака и развода с использованием строительных блоков сети Петри. Построенная модель сети Петри выражает переход от одинокого мужчины и женщины к состоянию супружеской пары через брак и обратно к одиноким людям через развод. Модель начинается с двух состояний: "мужчина" и "женщина". Через конструкцию "И" (для формирования пары необходимы и мужчина, и женщина) эти два состояния объединяются в рамках контрольной активности "образование пары", формируя новое состояние "пара". Затем состояние "пара" преобразуется посредством процессуальной активности "брак" в состояние "супружеская пара". Состояние "супружеская пара" затем преобразуется в состояние "разведенная пара" с помощью процессуальной активности "развод", в результате чего получается состояние "разведенная пара". Контрольная активность "распад пары" в конечном итоге разделяет состояние "разведенная пара" на состояния "мужчина" и "женщина".

Оценки

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