Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов

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

Вывод.Перед внесением изменений в систему подумайте о них и их воздействии и заручитесь участием всех заинтересованных сторон.

Концепция автоматизации BPM состоит в том, что технология BPM позволяет выделить бизнес-правила и компоненты бизнес-процессов приложения в свои собственные «слои». Смит и Фингар в книге о третьей волне BPM (Smith, Fingar) {68} считают, что система охватывает три широкие области, как показано на рис. 19.2:

1. Интеграция внешних систем (компонент EAI).

2. Автоматизация того, что они называют процессами (бизнес-правила и библиотеки процессов).

3. Сотрудничество с внешними контрагентами – клиентами, бизнес-партнерами, каналами дистрибуции, узлами-накопителями и биржами бизнес-информации.

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

Если бы мы смогли заглянуть в будущее, то довольно спорным оказалось бы мнение, что у старых систем приложений, которые хорошо служили крупным организациям, хотя и накладывали на них существенные ограничения, будет потенциал оставаться «только»:

• крупными хранилищами данных и библиотеками управления;

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

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

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

Результаты этого этапа таковы:

1. Общее описание решения.

2. Подробные бизнес-требования.

3. Окончательная доработка документации по выбору ПО.

4. Спецификации/технические условия на ПО.

5. Разработка/конфигурирование ПО.

6. Программы тестирования ПО и результаты.

7. Спецификации аппаратного обеспечения.

8. Наличие аппаратуры.

9. Программа испытаний аппаратуры и результаты.

10. Программа испытаний интеграции и результаты.

Существует два способа разработать автоматизированное решение BPM: традиционный подход по методу цикла разработки ПО (SDLC) (спецификация, разработка, тестирование) и итеративный метод быстрой разработки приложений (RAD). Эта глава отличается от других, поскольку дает лишь общее описание нескольких крупных шагов (рис. 19.3), которые необходимо принять во внимание при реализации автоматизированного решения BPM. Подробные пошаговые методики SDLC и RAD достаточно полно освещены в других публикациях и предметом этой книги не являются.

На этапе разработки важно довести объем и предполагаемую степень автоматизации до всех заинтересованных сторон. Важно также решить основные вопросы, которые возникают в случае автоматизации:

1. Я сохраню свою работу?

2. Какие новые навыки мне потребуются?

3. Как изменится моя работа?

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

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

Автоматизированное решение может состоять из одного или нескольких следующих компонентов:

1. Модуль (машина) рабочих потоков.

2. Модуль бизнес-правил.

3. Интеграция (интеграция приложений предприятия – EAI).

4. Интегрированная система управления документами.

5. Мониторинг бизнес-деятельности (BAM).

Остальные компоненты автоматизированного решения – инструмент моделирования и управления процессами, имитационное моделирование, учет затрат по типам деятельности и сбалансированной системы показателей. Эти компоненты больше ориентированы на моделирование и конфигурирование процессов, и в данной главе не рассматриваются. На рис. 19.4 показаны все компоненты.

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