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

позаказного производства на основе ERP/BPM методологий

В.П. Разбегин,
с.н.с., Valent@ipu.rssi.ru,

 А.В. Габалин,
н.с., Gabalina@bk.ru,
ИПУ РАН, г. Москва

1. Методология архитектурного моделирования

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

 

В рамках методологии Archimate архитектурная модель бизнеса, характеризующая его целевое, исходное или промежуточное состояние, может представляться  структурой 3x3 матрицы, в каждой клетке которой размещаются элементы одной из 9 категорий, по строкам расположены так называемые слои (бизнес-слой, слой приложений, технологический слой), по столбцам – пассивная, поведенческая и активная структуры (рис.1).

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

рис. 1. Система базовых понятий архитектурной модели бизнеса

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

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

По определению основной бизнес–процесс  связан непосредственно с созданием или добавлением стоимости, т.е. с созданием конечного продукта или услуги. Тогда цепочка добавления стоимости определяется как

совокупность основных бизнес – процессов.

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

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

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

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

рис. 2. Система бизнес-процессов в развитии

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

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

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

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

2. Особенности применения архитектурного подхода

Значительные резервы дальнейшего повышения эффективности и конкурентоспособности существуют пока в слабо  развитом направлении повышения уровня организации коллективной работы пользователей КИС,  оцениваемой  по критериям достижения общих целей компании.  В настоящее время актуальность теоретических и практических работ в этой области повышается в связи с проявившейся   тенденцией  создания и развития интегрированных КИС, построенных на базе комплекса взаимосвязанных с ERP и между собой методологий: CRM, SRM,  SCM, MES, ECM, CSRP, APS, BI, BPM,  PDM, PLM,  CAD, CAM, CAE, АСУ ТП и др.

В связи  этим имеет право на существование научно-практическая задача организации получения и эффективного использования коллективной компетенции по знанию, умению и владению ИКТ  корпоративных интегрированных информационных систем управления (КИИСУ), построенных на  основе комплекса ERP – ориентированных методологий.

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

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

Задача организации коллективного исполнения сквозного бизнес-процесса позаказного производства на основе ERP/BPM методологий предполагает междисциплинарность, конкурентность, асинхронность действий исполнителей, объединенных  в сетевую структуру.  В этой структуре исполнители осуществляют операции взаимодействия между собой и с прикладными компьютерными системами. С  такого рода операциями связывают следующие рабочие определения видов взаимодействия [4]:

·      Коммуникация (networking) – подразумевает операции коммуникации и обмена информацией для взаимной  выгоды.

·      Координированная коммуникация (Coordinated networking)  -  операции коммуникации и обмена информацией с  подстройкой деятельности для получения более эффективных результатов.

·      Кооперация (Cooperation) – кроме информационного обмена и подстройки деятельности также предполагает распределение ресурсов для достижения совместных целей. Достигается распределением работ между   участниками.

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

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

 - наличие общей цели;

 - выполнение предусловий:

ü  Участники согласны сотрудничать.

ü  Участники знают возможности каждого.

ü  Участники разделяют цель и общее видение во время процесса сотрудничества для достижения общей цели.

ü  Участники поддерживают частные понимания текущей проблемы, что предполагает обсуждение состояния  их прогресса (осведомленность о состоянии каждого участника);

-  выполнение базовых шагов процесса сотрудничества:

§  идентификация сторон и их общий сбор;

§  определение рамок сотрудничества и и желаемых результатов;

§  определение структуры  сотрудничества в терминах лидерства, ролей, ответственностей, владения, средств и процесса коммуникации, принятия решений, доступа к ресурсам, планирования и временных вех;

§  определение политик, т.е. управление конфликтами/разногласиями, подотчетностью, вознаграждением и признанием, владением создаваемыми активами;

§  определение мер, механизмов и процесса оценивания/измерения;

§  идентификация рисков и планирование измерения неопределенности;

§  фиксация согласия на сотрудничество;

§  сотрудничество требует «пространства сотрудничества», т.е. определенной среды для выполнения процесса сотрудничества, например, синхронный/ асинхронный, сосредоточенный/распределенный процесс и т.п.

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

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

Литература

1.  Nevis J.  James, Whitney E. DANIEL. Concurrent Design of Products & Processes, New York. McGraw Hill, 1989.

2.  Катерина Де Роза Планирование ресурсов, синхронизированное с покупателем (CSRP): Катерина Де Роза (компания SYMIX)/ URL: www.cfin.ru/vernikov/mrp/csrp.shtml.

3.  Коптелов А., Крохин В. Информационные системы в контроллинге бизнес-процессов //Byte, №10 (86), 2005.

4.  ECOLEAD Consortium (IP-507849). A reference Model for Colloborative Networks. Deliverables D5.2.3,2007.