Бизнес процесс ис это

С.Д.Паронджанов, Компания Аргуссофт

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

2. Основные составляющие методологии

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

Предлагаемая методология строится на основе итерационной спиральной модели жизненного цикла ИС. Принципиальной особенностью этой методологии является то, что охватывая все этапы жизненного цикла ИС, она делает основной упор на поддержку начальных этапов создания корпоративных ИС, главной задачей которых является формирование требований к ИС, точно отвечающих целям и задачам организации. В соответствии с подходом информационного инжиниринга, который Джеймс Мартин определяет как «применение взаимосвязанного набора формальных технологий (моделей) для планирования, анализа, проектирования и создания информационных систем на уровне корпораций или отдельных ее частей . «, процесс создания ИС строится как процесс построения и развития моделей. Реализация методологии базируется на применении комплекса согласованных между собой инструментальных средств, обеспечивающих высокий уровень автоматизации всех процессов, выполняемых в соответствии с методологией на протяжении ЖЦ ИС.

3. Итерационная спиральная модель жизненного цикла ИС.

Рис. 1. Жизненный цикл ИС

• Современные средства CASE, 4GL, СУБД и др. предоставляют возможности быстрого проектирования, прототипирования, разработки и тестирования приложений и баз данных на основе построенных моделей.
• Методология предполагает активное участие заказчиков на всех этапах создания ИС, поскольку модели, создаваемые на каждом этапе, понятны и разработчику и заказчику.

4. Комплекс развивающихся систем согласованных моделей

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

Это фундаментальное положение методологии позволяет абсолютно объективно подойти к выработке требований и проектированию информационной системы. Создается система моделей описания требований к ИС, которая затем преобразуется в систему моделей, описывающих проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция. На рис.2 представлен комплекс развивающихся систем согласованных моделей (КРССМ), который показывает состав и последовательность развития систем моделей, создаваемых в процессе построения ИС.
Развитие и преобразования моделей происходит в соответствии со схемой преобразования моделей, представленной на рис.3, обеспечивающей полноту и согласованность на каждом уровне преобразования моделей, что обеспечивает корректное формирование и реализацию всех требований к ИС. Архитектурные рамки для развития систем согласованных моделей, определяемые схемой преобразования моделей, основаны на модели Закмана.

5. Методология анализа ИС на основе бизнес-процессов

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

Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС. И это не случайность. Как правило, заказчики не могут правильно и точно сформулировать требования к ИС. Более того, они зачастую не могут точно определить основные цели и задачи своей организации.

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

Стратегическая система моделей организации.

списки документов
списки объектов

структурная модель организации

перечень структурных подразделений и внешних организаций

список работ во времени

список целей и задач организации
критерии и правила выполнения бизнес-процессов

информационная модель организации (концептуальная модель)

структурные модели подразделений, роли персонала

логическая модель сетей подразделений организации и внешних связей

временная модель выполнения бизнес-процессов и бизнес-функций

критерии выполнения бизнес-функций; бизнес-правила

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

требования к регламенту и интерфейсу пользователей

требования к сетевой архитектуре системы

требования к временным характеристикам функции

требования к регламенту работы ИС

Рис. 3. Схема преобразования моделей

Укрупненная система моделей организации.

Детальная система моделей организации.

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

Система моделей описания требований к ИС

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

6. Методология проектирования от данных

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

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

7. Комплекс согласованных инструментальных средств

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

8. Заключение

Для создания корпоративной информационной системы, отвечающей целям и задачам организации нужна специальная методология, которая бы во-первых, помогла сформировать требования к ИС, отвечающие целям и задачам организации, и во-вторых, спроектировать и разработать систему, отвечающую этим требованиям, с учетом их изменений в процессе разработки. Наличие такой методологии является решающим фактором успеха при создании корпоративных ИС. В статье предложена методология, обеспечивающая создание корпоративных ИС, отвечающих целям и задачам организации, предъявляемым к ним требованиям по автоматизации деловых процессов, и обеспечивающая выполнение основных требований к процессу разработки (по срокам, качеству и т.д).
При создании корпоративных информационных систем необходимым слагаемым успеха помимо методологии, является также и комплекс согласованных инструментальных средств, поддерживающий эту методологию и обеспечивающий автоматизацию процессов, выполняемых на всех этапах ЖЦ создания ИС. Эти средства должны поддерживать быстрое построение корпоративных ИС, отвечающих целям и задачам организации и удовлетворяющих основным требованиям (открытости, переносимости и масштабируемости и т.д.), а также обеспечивать поддержку процессов управления проектом. Такой набор согласованных инструментальных средств, поддерживающих предлагаемую методологию, и приведен в докладе.
Предложенная методология обеспечивает снижение сложности процесса создания ИС. Заложенные в методологию и поддержанные инструментальными средствами принципы, (разработка на основе моделей, проектирование от данных, повторное использование спецификаций и др.) упрощают разработку и обеспечивают возможность быстрого внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития.

Благодарности

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

Источник: citforum.ru

Бизнес — процесс и его роль в системе информационного сервиса. Моделирование деловых процессов. Реинжиниринг бп, его назначение и роль в процессе создания ИС на предприятиях

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

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

Бизнес-процесс — это логически завершенный набор этапов работ,

поддерживающий деятельность предприятия и реализующий его политику,

направленную на достижение поставленных целей

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

Классы БП: процессы, обеспечивающие выпуск продукции, процессы планирования и управления, ресурсные процессы, процессы преобразования.

Бизнес-процессы информационной службы могут быть описаны с помощью модели ITSM (Information Technology Service Management). Ключевым понятием данной модели становится понятие информационного сервиса — услуги информационной системы, потребляемой подразделением компании. Очевидно, что подразделения потребляют не саму ИС, а сервисы, предоставляемые ею, и ключевой задачей правления ИС становится выявление стоимости каждого сервиса, а также выявление доли данного сервиса в структуре себестоимости в целом и его правильное и эффективное использование.

Именно на это направлены основные бизнес-процессы информационной службы:

— стратегическое развитие, включая анализ требований бизнеса, разработку корпоративных стандартов в области ИТ и т. д.;

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

— разработку и внедрение приложений, включая оценку рисков и управление проектами;

— непосредственную эксплуатацию информационных технологий.

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

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

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

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

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

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

Реинжиниринг (с 95-96 годов Хамер) — фундаментальное переосмысление и радикальное перепроектирование бизнес — процессов предприятия для достижения существенных улучшений в таких ключевых для современного бизнеса показателя результативности как затраты, качество, уровень обслуживания и оперативность.

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

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

на тактическом уровне — повышение качества принимаемых управленческих решений, позволяющих адаптировать управленческие функции к изменяющейся внешней среде;

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

Объектом реинжиниринга являются процессы компании. Компании подвергают реинжинирингу не свои отделы, а выполняемую персоналом этих отделов работу. Реинжиниринговые мероприятия начали проводиться примерно с 94 года в некоторых правительственных учреждениях и банках. Они были связаны с усовершенствованием ведения процессов.

Горизонтальное сжатие процессов — объединение в одну работу нескольких задач и операций.

Вертикальное сжатие — предоставление исполнителям право принимать самостоятельные решения

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

Каждый шаг в процессе управления выполняется там, где она целесообразна. Уменьшения числа контрольных процедур =>сокращение времени и стоимости управленческого процесса. Минимизируется число согласований. Выбирается уполномоченный менеджер для сложных процессов с точки зрения интеграции, который эту точку контакта поддерживает. Децентрализация с одновременной централизацией процессов.

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

Источник: infopedia.su

Бизнес-процессы и процессная интеграция

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

ИТ-поддержка процессной интеграции

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

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

Процессное управление и управление качеством

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

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

И все эти системы, ориентированные на различные методики: ISO 9000, Capability Maturity Model (CMM, CMMI), EFQM, 6sigma и т. д., основаны на процессном подходе к управлению. Но в сравнении с функциональным успех применения процессно-ориентированного подхода в значительной степени зависит от поддержки со стороны ИТ, которая наиболее полно проявляется при построении прикладных систем для управления явно определенными, формализованными бизнес-процессами. Средства, используемые для разработки таких систем, известны российским ИТ-специалистам вне контекста процессной интеграции и, как правило, по отдельности. Ввиду этого могут быть интересны особенности и тенденции развития средств, имеющих значение именно для процессной интеграции.

Поддержка бизнес-процессов

К настоящему времени, исходя из достигнутого уровня теоретических разработок, методик и программных инструментов, систем для поддержки/управления формализованными бизнес-процессами можно представить как совокупность приложений, поддерживающих бизнес-процессы организации, в рамках которых обрабатывается поток стандартизованных бизнес-объектов (договоров, счетов, заявок и т. д.). Причем логика этих процессов реализована вне приложений в интеграционном слое или платформе (такая платформа может быть реализована как отдельный продукт или в рамках сервера приложений и архитектуры; см. рис. 1).
Рис. 1 Архитектура ИСП для поддержки формализованных бизнес-процессов Поскольку бизнес-процесс — это совокупность шагов, выполняемых его участниками, то необходима некоторая исполнительная система, реализующая логику бизнес-процесса и организующая в соответствии с ней осуществление всех этапов бизнес-процесса.

Системы управления workflow, как оказалось, удачно подходят для этого, они позволяют отделить контроль и управление бизнес-процессом от приложений, реализующих его функции. Это, в частности, дает возможность изменять бизнес-процессы в соответствии с потребностями бизнеса (во многих случаях при этом сами приложения не изменяются!). Помимо системы управления workflow, в платформу процессной интеграции, как правило, входят система обработки сообщений класса MOM (Message-Oriented Middleware) и средства класса EAI (Enterprise Application Integration, интеграция приложений предприятия), дополняющие возможности системы workflow по интеграции приложений. Но прежде чем использовать интеграционную платформу, нужно явно определить бизнес-процессы, составить, проанализировать и оптимизировать их модели (планы, проекты).

Моделирование и анализ

В России для моделирования и анализа бизнес-процессов достаточно широко используются средства моделирования программных систем: Rational Rose, Designer/2000, Bpwin и т. д., однако наиболее эффективны методики и комплекты инструментов класса BPA (Business Process Analysis, анализ бизнес-процессов), которые специально для этого разработаны компаниями Popkin Software, IDS Scheer, Proforma, Meta Software и рядом других. Как правило, в таких комплектах предлагается четыре «взгляда» — процессы, функции (с целями), данные, организация — на моделирование и анализ бизнес-процессов, для каждого из которых поддерживается три уровня анализа — требования, спецификации, реализация, — см. рис. 2).

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

BPM: workflow полезно для здоровья бизнес-процессов

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

Подсистемы workflow с такими сценариями широко используются в документообороте. Отсюда и пренебрежительное отношение у части российских ИТ-специалистов к workflow в целом: «А что оно делает? Доставляет документ из пункта А в пункт Б. ». Работа с документами и их перемещение (docflow) присущи многим бизнес-процессам.

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

Поэтому автоматизация документооборота не эквивалента автоматизации бизнес-процессов. На российском рынке представлено немало продуктов для «автоматизации документооборота и бизнес-процессов». В какой мере это относится к бизнес-процессам? Вряд ли в полной.

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

В принципе функциональность систем workflow, соответствующих «эталонной модели workflow» организации Workflow Management Coalition, при правильном применении позволяет достаточно эффективно автоматизировать управление бизнес-процессами [2]. В последние годы многие системы workflow были расширены, чтобы максимально полно поддерживать цикл работ по совершенствованию бизнес-процессов.

Его образуют: описание и моделирование («как есть») — анализ — оптимизация («как должно быть») — автоматизация — анализ (выполнения автоматизированных бизнес-процессов) — оптимизация и перепроектирование (по результатам анализа выполнения и/или из-за изменений требований бизнеса). Расширенные таким образом системы workflow теперь определяются как системы класса BPM (Business Process Management, управление бизнес-процессами).

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

Возможности средств моделирования систем класса BPM и комплектов класса BPA частично пересекаются, но модели, построенные с их использованием, предназначены для разных лиц. Модели, полученные средствами класса BPA, — прежде всего для бизнес-аналитиков, а модели систем класса BPM — для разработчиков и непосредственного исполнения системами workflow.

К тому же модели, полученные средствами типа BPA, как правило, нужно детализировать для исполнения в конкретной системе BPM. Организациям, которые ставят задачу описать, проанализировать свои бизнес-процессы и повысить их эффективность посредством автоматизации, нужны и те и другие средства.

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

Сделать это можно с применением аппарата так называемых правил бизнеса. В современных системах workflow/BPM, как правило, используются механизмы» workflow на основе правил бизнеса. Широко применяется в системах BPM и механизм для инициирования, завершения и изменения хода исполнения бизнес-процессов.

Обязательными компонентами систем BPM являются подсистемы мониторинга и коррекции исполнения бизнес-процессов, включающие средства сбора и представления соответствующей статистики как с технической стороны, так и с точки зрения бизнеса. Например, о бизнес-процессе «сформировать документ» с точки зрения бизнеса интересна следующая информация: на каком шаге сейчас находится процесс создания документа, каково состояние документа, кто сейчас с ним работает. Технический же аспект включает время выполнения шагов процесса, продолжительность и причины периодов ожидания тех или иных событий или условий и т. д. В случае обнаружения отклонения течения процесса от эталонных условий система workflow/BPM либо пытается сама исправить положение, либо выдает сообщение пользователю или администратору (см. рис. 3).
Рис. 3. Схема коррекции развития процесса с помощью “двигателя” и монитора workflow На основе данных мониторинга бизнес-процессов выполняется, если это необходимо, их реорганизация. Эти данные могут быть агрегированы (для чего часто используются OLAP-средства) с целью получения ключевых показателей эффективности (KPI), на основе анализа которых могут приниматься серьезные решения вплоть до изменения всей совокупности бизнес-процессов предприятия. Развитие систем класса BPM продолжается, и наибольшее внимание сейчас уделяется обеспечению возможности использования Web-сервисов и в целом «погружению» этих систем в вычислительную среду и архитектуру, построенные на основе Web-сервисов (Service-Oriented Architecture, SOA).

Платформа процессной интеграции — это не только workflow/BPM

Система класса workflow/BMP является ядром платформы процессной интеграции, ее основным, но, как правило, не единственным компонентом. Участникам бизнес-процесса, людям и приложениям, совместно использующим различные данные, необходим стандартный механизм работы с этими данными, которого нет в системах workflow/BPM. Системы класса (Message-Oriented Middleware, MOM) могут быть таким механизмом.

Практически всегда в крупных проектах по автоматизации бизнес-процессов workflow и MOM дополняют друг друга. Привлекает все большее внимание применение в интеграционных платформах «общей шины предприятия» ESB (Enterprise Service Bus), основанной на использовании функциональности системы класса MOM и стандартов JMS (Java Message Service).

Кратко ее можно определить так: ESB = MOM+JMS+XML+WebServices+. (о концепции и основных особенностях ESB см. [3]). Функциональность ESB реализуется, как правило, «поверх» системы класса MOM в дополнительном к ней продукте.

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

Особенности применения процессной интеграции

В последние годы такие компании, как IBM, Oracle, BEA Systems, Microsoft, прилагают значительные усилия по развитию средств процессной интеграции в своих интеграционных платформах. Но, как отмечено в исследованиях аналитических фирм (Gartner и др.), большого успеха workflow/BPM добиваются небольшие специализированные компании. Организациям, которым интеграция приложений нужна для управления явно определенными бизнес-процессами, имеет смысл продумать возможность формирования платформы из доступных на рынке продуктов или воспользоваться платформой, уже сформированной компанией, действующей в качестве консультанта и интегратора в области BPM и EAI. Вообще-то услуги консультанта и интегратора при реализации интеграционного проекта весьма желательны, так как большинство современных интеграционных продуктов сложны, и, хотя поставщики осознают эту проблему и работают над ее решением, что отметила Gartner в своем прогнозе на 2004 год, радикального их упрощения в обозримом будущем ожидать не приходится.

Как перейти к процессному управлению

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

Эти варианты определяют и разные сценарии применения средств процессной интеграции. Во многих случаях информационную систему предприятия можно разделить на основную информационную систему и специализированные системы.

В варианте быстрого и полного перехода организации на процессно-ориентированное управление интеграция существующих приложений основной и специализированных систем в рамках бизнес-процессов благодаря применению платформы процессной интеграции вряд ли практична, так как потребует много времени, а приложения, скорее всего, станут непроизводительны. В этом случае имеет смысл заменить основную информационную систему — например, ERP-систему для промышленного предприятия или автоматизированную банковскую систему для банка — на новую, построенную на базе платформы процессной интеграции. Приложения дополнительных информационных систем можно связать, используя эту же платформу. По сути, такой сценарий построения информационной системы предприятия предлагает компания SAP AG, ERP-система которой основана на интеграционной платформе — сервере приложений SAP NetWeaver. По этому же пути идет и компания «Кворум», АБС NEXT которой построена на одноименной интеграционной платформе NEXT.

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

Источник: ecm-journal.ru