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

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

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

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

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

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

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

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

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

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

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

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

Осуществление

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

Шаг 1. Обмен информацией

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

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

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

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

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

Шаг 2. Определение компонент BPM

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

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

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

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

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

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

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

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

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

Шаг 3. Решение повторно использовать, приобрести, создать или отдать в аутсорсинг

Следующее решение в проекте относится к подходу, который будет принят в отношении источника различных компонент ПО: сделать или купить. Ниже перечислены возможные варианты.

Повторно использовать имеющуюся систему

Основные достоинства:

• синергия и экономия на объемах;

• система известна и уже зарекомендовала себя.

Основной недостаток или проблема:

• система не отвечает всем сегодняшним требованиям или не обеспечивает достаточной гибкости для вероятных новых требований.

Купить готовый к применению стандартный продукт, который можно сконфигурировать

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

Основные достоинства:

• вероятность получить пригодный продукт или стартовый пункт;

• решение, которое отвечает конкретной ситуации в организации и на рынке;

• обеспечена поддержка продукта.

Основные недостатки или проблемы: