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

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

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

Георгий Калянов — д. т. н., руководитель отдела бизнес-анализа компании ЛАНИТ. К нему можно обратиться по адресу: kalyanov@mail.lanit.ru

Отвечая на статью Фреда Хэпгуда «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].

Литература