[ Оглавление ] [ Список сокращений ] [ Библиография ]

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

Лучшей материальной моделью кошки является другая, 
а желательно, та же самая кошка

Норберт Винер

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

Вопросами унификации и стандартизации элементов управленческой деятельности в бывшем СССР занимались ряд организаций: Научно-исследовательский институт труда (в области организации труда и социальной сфере); Всесоюзный научно-исследовательский институт проблем организации и управления (в области организации и автоматизации управления производственными объединениями); Академия народного хозяйства СССР (в области подготовки, обоснования и принятия управленческих решений); Государственная академия управления (в области теории управления). Большой вклад в стандартизацию элементов управленческой деятельности внесли Гличев А.В., Круглов М.И., Слезингер Г.Э., Нагорская М.Н., Чайка И.М., Гапич С.П., Степных Ю.В., Свиткин М.З. и др. (Смирнов, 1998).

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

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

В США существует более 500 правил и стандартов, регламентирующих качество приготовления пиццы. Если вы произвели пиццу, но не вписались в один из 500 стандартов, ваша продукция изымается, а лавочка закрывается. Поэтому, прежде всего вам необходимо знать эти правила. И это - не происки бюрократизма. Существует множество ведомств и организаций (чаще общественных, чем государственных), которые пекутся о том, чтобы население не отравили. В организациях существует иная «кухня», к технологическим процессам которой должны предъявляться не менее строгие требования. Базовым технологическим процессом в организациях является моделирование бизнес-процессов. Как же могут быть регламентированы правила моделирования бизнес-процессов организации?

Разработка модели БП организации представляет собой сложную задачу, решение которой требует применения специальных методик и инструментов. В последнее время значительно вырос интерес к CASE (Computer-Aided Software/System Engineering) - технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки модели. Известными примерами таких CASE-средств являются: ERwin (Computer Assosiates), S-Designer (Sybase), Rational Rose (Rational Software), ARIS (Scheer AG) ORACLE Designer (Oracle Corporation) и др. Поэтому носителями стандартов РБП часто являются сами CASE-средства. Одним из достоинств многих CASE-средств является возможность в наглядной форме строить визуальные модели БП. Последние при всей сложности организации обеспечивают ясность представления выбранных архитектурных решений и понимания разрабатываемой модели во всей ее полноте, что способствует наладке плодотворное взаимодействия между заказчиками, пользователями и командой разработчиков модели БП.

Таким образом, разработчики моделей БП пришли к выводу, что простейшим способом стандартизации такой работы является введение в обращение правил графического изображения БП и интерпретации этих графических изображений. Эти правила, естественно, должны признаваться тем или иным авторитетным сообществом. Такой способ стал наиболее эффективным с появлением первых программных инструментов, автоматизирующих деятельность команд модельеров, объединяющих усилия в рамках одного проекта. Реализаций рассматриваемого способа довольно много, и они в основном ассоциированы с конкретным CASE-средством. Однако, уже сейчас можно говорить о некоторых исторически подтвержденных мета-тенденциях, которые ставят под сомнение эффективность существующих инструментов. В частности, речь может вестись об адекватности инструментов рекомендациям универсальной Модели Взаимодействия Открытых Систем (МВОС).

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

Отсюда и мнение автора о том, что любой сравнительный анализ инструментов проектирования и управления проектами должен изначально вызывать здоровое сомнение, если он, конечно, не являлся плодом усилий солидной группы авторитетных экспертов. Возможно, это распространяется и на следующее заявление J … До уровня методологии проектирования организационных процессов, реализованной в нескольких популярных программных продуктах, «дорос», пожалуй, лишь один подход к проектированию, называемый методологией структурного анализа и проектирования (Structured Analysis and Design Technique или сокращенно – SADT) в наиболее популярной версии Федерального стандарта США – IDEF0 (National Institute of Standards and Technology, 1993; Марка, МакГоуэн, 1993). Попытку обосновать это заявление автор предпримет чуть позже.

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

Условно стандарты проектирования, разрабатываемые в рамках описанных подходов, назовем «узкие, но глубокие» и «широкие, но мелкие». Например, стандарт IDEF0 «заставляет» нас представлять функциональную (или процессную) модель предприятия в виде иерархической структуры. Совместно со стандартами IDEF2,3 (Маклаков, 1999) обеспечивая достаточную глубину проектной проработки, он «загоняет» проектировщика в рамки листового формата А4. Очевидно, не всем это нравится. Поэтому, разработчики инструментария по-разному пытаются решать такие проблемы. Так, попытки расширить возможности инструмента и придать ему свойства инструмента «сквозной» разработки сводятся, с одной стороны, к ограничению множества отношений и объектов, которые можно описывать с его использованием, и придание стандартным процессам более выразительной формы (STORM2000). С другой – к расширению множества отношений и объектов, но и к разделению труда, когда создаваемый инструмент не обеспечивает всей глубины проектного процесса и снабжается необходимыми интерфейсами для использования продуктов других популярных разработчиков (ARIS).

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

Принципы МВОС не являются чем-то новым. Здесь имеется в виду не только известный факт, что взгляд на архитектуру открытых систем является расширением общеизвестного представления об архитектуре ЭВМ по Г. Майерсу (Майерс, 1985), а соответствие этих принципов общей философской концепции устройства информационного мира, элементами которого являются не только сети и компьютеры, но и живые существа. Поэтому МВОС как термин некорректно ассоциировать исключительно с такими организациями как МОС и МККТТ^[2].

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

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

Например, в основе современных технологий управления психическими процессами персонала лежит широкий спектр описательных МВОС, располагающихся в диапазоне от модели иерархии нужд Маслоу (Maslow, 1954) до модели нейро-лингвистических уровней Бейтсона (Bateson, 1972, 79).

Бог не нуждается в объяснении, как устроен человек. Как и богу, в мирах технических систем и бизнес-операций, являющихся творениями человеческой мысли, профессионалам не требуются описательные модели для управления объектами этих миров. Поэтому, в задачах управления бизнесом и проектирования бизнес-систем, как правило, на этапе проектирования систем сразу используются предписывающие модели. Примерами таких приложений МВОС являлись:

1.    Финансовые пирамиды. Условно сервисными слоями этой МВОС являлись владельцы финансовых инструментов пирамиды, денежные средства которых были вложены в пирамиду примерно в одно время. Строгая регламентация правил поведения обеспечивала реальную открытость системы для самых разнообразных участников.

2.     Системы сетевого маркетинга. В целом аналогичная финансовым пирамидам МВОС, использующая вместо финансовых инструментов товары или товарные контракты.

3.    Виртуальные рынки. Ставшая печально знаменитой в 2000 г. «игра» StockGeneration.com, предложившая во всемирной паутине высокотехнологичную диверсифицированную версию МВОС для виртуального фондового рынка.

Развитие систем электронного бизнеса, телекоммуникационных систем и систем связи  подтолкнуло продолжение работ в области разработки стандартов для верхнего уровня эталонной МВОС.  Так в отрасли телекоммуникаций участниками ассоциации TeleMarket Forum была принята модель управления сетями телекоммуникаций (TMN-модель) как способ логического описания системы управления бизнесом провайдеров услуг. TMN-модель состоит из 5 уровней, которые традиционно для МВОС изображают в виде пирамиды (см. Рис. 3.1). Управление бизнесом наверху, второй уровень - управление услугами, третий уровень - управление сетью, четвертый - управление сетевыми элементами, а самый нижний уровень состоит из собственно сетевых элементов. Опять мы видим известную идею, которая заключается в том, что управляющие решения на каждом уровне отличаются, но взаимосвязаны. Например, детальная информация нужна на уровне управления сетевыми элементами, чтобы поддерживать работу такого сетевого элемента, как коммутатор, но только часть этой информации нужна на уровне управления сетью (например, информация об уровне загрузки коммутатора). Сверху вниз - каждый уровень накладывает требования на функционирование нижележащего уровня. Снизу вверх - каждый уровень обеспечивает ресурсы для вышележащего уровня. TeleMarket Forum ставит перед собой амбициозную задачу по разработке не только стандартных соглашений между нижними уровнями услуг TMN-модели, но и на верхнем уровне бизнес-приложений. Задача представляется сложной, но вполне осуществимой.

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

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

Естественно, общее признание пирамидальной архитектуры услуг как универсальной модели организационно-технических систем востребовало появление инструментов, поддерживающих проектирование систем различного назначения в соответствии с МВОС. Революционную роль в стандартизации процессов проектирования сыграла методология IDEF0 (National Institute of Standards and Technology, 1993), разработанная в 1981 году в рамках программы автоматизации промышленных предприятий ICAM (Integrated Computer Aided Manufacturing) и являющаяся версией развития стандарта SADT. В настоящее время IDEF0 – пожалуй, единственный общепризнанный стандарт, полностью соответствующий идеологии МВОС.

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

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

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

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

[1] В бывшем СССР с 1980 по 1985 гг. проводился эксперимент по опытному внедрению комплекса государственных стандартов “Управление производственным объединением и промышленным предприятием”, основные положения которого были представлены в ГОСТ 24525.0-80. Государственный стандарт носил рекомендательный характер для обеспечения мягкого регулирования сложившихся за многие десятилетия стереотипов функционирования элементов системы управления. Данный стандарт по программе-минимум должен был обратить внимание руководителей и специалистов в области управления на новые общие подходы к функционированию системы управления и наметить пути для его совершенствования. Программа-максимум предполагала проведение практической унификации управления производственным объединением и промышленным предприятием по предложенным стандартам. Программа-минимум была выполнена, а программа-максимум практически не реализована в силу определенной недоработки стандартов, отсутствия должной настойчивости и последовательности в реализации (Смирнов, 1998).

[2] В начале 1980 гг. Международная Организация по Стандартизации (МОС) и Международный Консультативный Комитет по Телеграфии и Телефонии (МККТТ) признали необходимость в создания модели сети, являющейся основной для соглашений между поставщиками систем и программных продуктов и провайдерами услуг. Ими же была разработана эталонная МВОС, которая описана в рекомендациях Х.200 (МККТТ) и ISO 7498 (ISO). Модель описывала правила и процедуры передачи данных между открытыми системами (компоненты и интерфейсы). В рамках той же идеи крупными поставщиками корпоративных сетей были разработаны другие архитектурные модели. Однако, при необходимости предоставить обучающую информацию пользователям они, как правило, ссылаются на свои продукты как на изделия для сети, соответствующие эталонной МВОС. Идеи, заложенные в модели, получили широкое международное признание. В различных странах и регионах созданы организации, которые проводят работы, связанные с созданием сетей, реализующих эту модель (например, Ассоциация европейских производителей компьютеров, OSIone, TMForum, комитеты POSIX в IEEE и др.). В настоящее время МВОС представляет согласованный набор международных стандартов для информационных технологий и функциональных устройств, которые специфицируют интерфейсы, службы и поддерживающие форматы, чтобы обеспечить интероперабельность (способность к взаимодействию с другими системами)  и мобильность приложений, данных и персонала.

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