CASE: все только начинается...

Г.Калянов

Георгий Калянов
Журнал "Директор ИС", #03, 2001 год

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


СASE-среда для моделирования бизнеса

Отвечая на статью Фреда Хэпгуда "CASE: конец истории"? (см. Директор, сентябрь 2000), известный специалист Александр Вендров рассмотрел в ноябрьском выпуске журнала одну из основных областей применения CASE " проектирование больших и сложных программных систем (Директор, ноябрь 2000). Но поскольку под буквой S в этой аббревиатуре все чаще подразумевается System, а не Software, хотелось бы обсудить и другой класс систем, в которых находят применение CASE-средства, а именно организационно-управляющие системы.

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

В основе рассматриваемой деятельности лежит цикл реорганизации бизнес-процесса, включающий следующие основные этапы:

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

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

Фактически такой инструментарий должен обеспечивать:

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

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

  • статистический анализ;
  • линейное программирование и вычисление наиболее эффективных комбинаций ресурсов;
  • функционально-стоимостной анализ продуцируемых процессом товаров и/или услуг;
  • тестирование и верификация бизнес-процесса;
  • оценка качества бизнес-процесса на основе формализованных метрик;
  • динамическое моделирование поведения процесса и др.

Для целей анализа необходима следующая информация:

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

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

  • стандарты на язык описания бизнес-процессов;
  • стандарты на спецификации требований и спецификации проектирования бизнес-процессов;
  • стандарты на методики оценки полноты и состоятельности, а также методы и средства анализа процессов.

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

  • функциональность процесса должна быть отделена от задач и особенностей его реализации, то есть должны быть четко разграничены спецификации требований и спецификации проектирования, соответственно отвечающие на вопросы: "Что данный процесс делает?" и "Каким образом он это делает?";
  • при написании спецификации должен использоваться процессо-ориентированный язык описания, например построенный на базе диалектов диаграмм потоков данных или SADT-диаграмм;
  • спецификация должна быть интегрирована с системой, компонентом которой она является, посредством описания ее входов и выходов в терминах системных объектов;
  • спецификация должна быть интегрирована с внешним окружением, с которым система оперирует, соответственно должно быть специфицировано как само окружение, так и все его взаимодействия с системой;
  • спецификация должна быть читабельной и понятной пользователям " специалистам по созданию бизнес-процесса и, что особенно важно, специалистам функциональных подразделений, которые будут его исполнять в соответствии с заданными ролями и функциями;
  • спецификация должна быть управляемой, то есть иметь соответствующий размер и структуру;
  • спецификация должна допускать возможность ее дополнения, поскольку бизнес-процесс является развивающимся объектом и изменения в нем могут быть обусловлены изменениями в законодательстве, необходимостью получения дополнительной информации, применением информационных технологий и т. п.;
  • спецификация должна быть локализованной, описывающей функциональность всех тех и только тех задач, которые требуются для достижения целей бизнес-процесса.

Следует отметить, что подобные ориентированные на бизнес-процессы интегрированные CASE-среды до последнего времени практически не создавались. Традиционно использовались комбинации из CASE для ПО (расширенные в сторону фиксации специфичной для бизнес-процессов информации) и специализированных инструментов с ограниченной функциональностью, реализующих локальную задачу, например EasyABC (функционально-стоимостной анализ), INCOME Mobile, Design/CPN (динамическое моделирование) и др. В настоящий момент ситуация коренным образом изменилась, что связано со следующими основными причинами:

1) появлением сквозных формализованных методологий реорганизации, поддерживающих автоматизируемые этапы жизненного цикла бизнес-процесса (см., например, применяемую компанией ЛАНИТ методологию ТОП [1], технологию ДЭМОС [2], АБИ ARIS);

2) возрастанием спроса на услуги по управленческому консалтингу, обусловленным ростом сложности и неопределенности бизнеса и как следствие ростом численности консультантов (по оценкам Kennedy Information Group, среднегодовые темпы роста составляли примерно 13% за период с 1993 по 2000 год);

3) дефицитом высококвалифицированных специалистов, приведшим к острой необходимости автоматизации их труда (при этом речь уже идет не о рутинных операциях " рисовании моделей, выдаче отчетов по ее статике и динамике и т. п., а о целевой, аналитической деятельности консультанта).

Понятно, что трудозатраты на создание таких CASE-сред оцениваются в сотнях и тысячах человеко-лет, тем не менее ряд компаний уже объявили о старте подобных проектов, в числе которых проекты BFS " business framework system [3], BPR-tools [4], BPR-workbench [5].

Литература

1. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов // М.: СИНТЕГ, 2000.
2. Юдицкий С.А., Вукович И.Ю. Динамическое экспресс-моделирование организационных систем (информационная технология ДЭМОС). М.: ИПУ, 1998.
3. Holtham C. A groupware-based framework for learning organizations: the BFS project // IT Support in the Productive Workplace. Stanley Thornes in Association with Unicom, 1996.
4. Vacca J., Andrews D. BPR tools help you work smarter // BYTE, Oct. 1994.
5. The L. Now you can automate BPR // Datamation, March 1995.