Главная

Статьи

Библиотека статей

Методология бизнес-инжиниринга

05.02.2002

Директор ИС, #01/2002

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

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

Некоторые события ушедшего года (диспут, развернувшийся в журнале «ДИС» после публикации статьи П. Сахарова в ноябрьском 2000 года выпуске, обсуждение с поставщиками инструментария РБП, участие в WWW-форумах, посвященных той же теме, и т. д.) стимулировали меня к изложению мнения, основанного на классических кибернетических посылках, часто игнорируемых участниками обсуждения.

Прежде всего, нельзя забывать, что инструмент применяется пользователем, потребности которого разнообразны и не всегда обоснованны, но служит он достижению целей конкретной методологии. Именно в этом контексте следует рассматривать фразу С. Бира: «Прилагательные ‘хороший’ или ‘плохой’ в большей мере относятся к пользователям, чем к используемой ими технике» (в кн: Бир С. Мозг фирмы. – М.: Радио и связь, 1993. 416 с.).

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

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

Задача управления изменениями в организации по многим причинам сопровождается «хаосом моделирования», выражающимся во множественности представлений организации руководством, персоналом и аналитиками. Одна из этих причин — разнообразие возможностей и их сочетаний, вносимых языком (нотациями) описания БП и самим инструментом РБП.

Управлять можно только той организацией, модель которой существует в системе управления ею. Это необходимое условие управляемости. Однако «хаос моделирования» объективно усиливается разработчиками и поставщиками инструментов, которые идут навстречу интересам пользователей, ориентированных на решение задач разного рода, тогда как РБП нуждается в специфической инструментальной поддержке.

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

Первое направление выражается в создании условий, снижающих степень свободы проектировщика и поддерживающих множество задач, выходящих за рамки РБП. Классическим примером такого подхода являются продукты, поддерживающие стандарты IDEF0-3 и обеспечивающие глубокую проработку проекта вплоть до генерации программного кода. Второе – охватывает лишь отдельные фрагменты проектного цикла и поставляет сервис для выражения «творческих» взглядов на проектирование БП. Например, ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания БП предлагается использовать 85 типов моделей, каждая из которых принадлежит тому или иному аспекту. Понятно, что CASE-инструменты весьма приблизительно позиционируются в границах этих подходов. Назовем их соответственно «узкий, но глубокий» и «широкий, но мелкий».

В первом, «узком, но глубоком» подходе попытки усилить возможности инструмента в направлении получения программного кода приводят к ограничению множества типов отношений и объектов, которые можно описывать с использованием инструмента (например, STORM2000, использующий нотацию UML при описании процессов высокого уровня с целью автоматической генерации ПО информационной системы). Плата за такой сервис — предопределенная системная архитектура программного кода.

Второй, «широкий, но мелкий» подход, подразумевающий расширение множества отношений и объектов, реализуем только при разделении труда, когда «неглубокий» инструмент снабжается необходимыми интерфейсами для использования продуктов других разработчиков. Так, ARIS приобретает полнофункциональные свойства только после закупки соответствующих интерфейсов (в частности, для формирования логической структуры баз данных и кодов приложений рекомендуется докупать интерфейс, например, с ERwin).

Другими словами, путем замены одних ограничений другими реализуется попытка устранить возможные противоречия и расширить область применения инструмента. Насколько удачными будут эти попытки, может показать только будущее. Однако можно определенно сказать, что наше стремление уменьшить разнообразие вступает в противоречие с «широкими, но мелкими» CASE-инструментами.

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

Кроме нотации, являющейся важнейшим метастандартом, поставляемым разработчиком CASE-инструмента, эффективными метастандартами как «фильтрами» разнообразия являются международные, национальные, ассоциативные и корпоративные стандарты. Например, методология взаимодействия открытых систем (ВОС) является метастандартом общей значимости. Большой организующей мощью обладают предметно-ориентированные метастандарты моделирования бизнес-процессов (например, стандарты ISA¹, APICS, TM Forum и др.). По мнению же автора, наиболее организующим фактором, снижающим разнообразие до минимально необходимого уровня, обладают некоторые концепции управления организациями. Например, методология концептуального проектирования, разработанная известным отечественным специалистом по автоматизации С. П. Никаноровым, демонстрирует существование инвариантов управления в виде абстракций, называемых «конструктами». Им же был предложен постулат, гласящий, что организация – это система процессов «рефлексии», моделируемая множеством процессов принятия решений. Отсюда следует, например, вывод (согласующийся с основным положением теории оптимального регулирования) о том, что базовым конструктом проектировщика БП должен являться рефлексивный контур, состоящий из следующих операций:

• анализ результата воздействия (например, поставки услуги/товара),
• моделирование объекта воздействия (например, потребителя услуги/товара),
• регулирование (например, разработки, производства и поставки услуги/товара).

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

Не всем известно, сколь значительно появляющиеся на страницах журналов варианты статей отличаются от своей изначальной версии. Это связано с необходимостью формулировать авторские мысли в такой форме, чтобы их не отсеял фильтр редакторских стандартов и взглядов экспертов. Чем строже фильтр, тем более отточенным будет текст. Чем больше у фильтра сбиты настройки, тем текст будет «мудренее» (при условии, что автор настойчив в достижении цели). Такова же роль CASE-инструмента как фильтра разнообразия.

Встречающаяся неудовлетворенность проектировщика CASE-инструментом часто объясняется неконтролируемым психическим фактором — неадекватным стремлением к свободе творчества. Рефлексия же пользователя, решающего не методологическую, а прикладную задачу, должна подчиняться выбору разработчиков инструмента, решающих задачу методологическую.

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

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

Проблема современного инструментария РБП обусловлена не только отсутствием «узкого и жесткого» инструмента, ориентированного на поддержку РБП, но и общей культурой потребителя CASE-инструментов, часто неспособного сформулировать формальные требования к инструментарию. Представленные в настоящей статье требования к инструментарию РБП являются, на взгляд автора, наиболее критичными. Однако и они, вероятно, нуждаются в доработке и дополнении.

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

1 В США в национальном масштабе задача разрабатывать стандарты автоматизации и интеграции для различных бизнес-процессов на предприятиях была поручена комитету ISA SP95 (Williams T. J. Enterprise Integration in the Process Industries – as Seen by the ISA SP95 committee. – West Lafayette, Purdue University, IN: World Batch Forum, 1998.- 46.).

Источник: www.bigspb.ru

Коротко о системе Е-МАСТЕР

Е-МАСТЕР® — система управления корпоративной информацией. Е-МАСТЕР® включает в себя возможности систем класса ECM (Enterprise Content Management). Система обеспечивает: Совместное создание и согласование документов Каждый документ может быть обсужден как при помощи прикрепленного к нему мини-форума, так и в главном форуме Разработанный документ может быть направлен на согласование по указанному маршруту Хранение документов любых форматов Хранение и передача документов в зашифрованном виде Встроенные системы восстановления после сбоев и резервного копирования Поиск документов Возможность поиска по ключевым словам и другим атрибутам документов (автор, дата создания…) Возможность поиска с помощью навигации по рубрикам Управляемый доступ к документам Возможность установки доступа к документам для различных категорий пользователей Возможность введения ограничений на работу с документами Функциональный интерфейс пользователя Веб-интерфейс, позволяющий просматривать карточки и скачивать файлы из системы хранения документов Удаленный доступ или работа пользователя из любой точки мира (при условии подключения к Интернету). Подробнее о Е-МАСТЕР >>

Система FLAMORY™

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

Версия для печати  |  Пользовательское соглашение