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

См. часть 2 – программирование «в уме».

См. часть 3 – этика тестирования.

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

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

Каталог

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

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

Вернемся к нарезке моделей бизнес-процессов. Чем она будет мельче, тем лучше. Если нарезать слишком крупно, то критические вопросы, которые неминуемо возникнут, будут тормозить согласование моделей бизнес-процессов, снижая ритмичность выполнения проекта.

Конечно, мелкая нарезка моделей бизнес-процессов будет периодически вызывать справедливый вопрос у заказчика – «По отдельности все понятно, а как это будет работать вместе?». Это задачу должен закрывать функциональный архитектор. Опираясь на свои компетенции, опыт и видение концепции системы, объяснять, иногда очень скрупулезно, иногда ни по одному разу, как все будет работать.

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

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

Важно проговаривать формулировку требования в присутствии функционального заказчика и фиксировать инициатора, чтобы в дальнейшем не возникало вопросов – «Что это требование значит и кто его выдвинул?».

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

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

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

Структура модели

Теперь поговорим о структуре модели бизнес-процесса как проектного артефакта:

Границы. Как было сказано выше, бизнес-процессы будут нарезаны максимально детально. Следовательно мы получим много небольших документов. Поэтому важно быстро ориентироваться, что конкретная модель бизнес-процесса покрывает, а что нет.
Ключевые изменения. Если моделируемый бизнес-процесс в формате «as is» отличается от формата «to be» (раньше выполнялся за пределами системы, а теперь в системе; раньше каких-то шагов не было, а теперь есть и т.д.), то нужно указать эти отличия. Это поможет выявить точки, требующие повышенного внимания при обучении.
Схема бизнес-процесса. Так уж устроен человек, что большинству из нас читать текст с картинками проще, чем без них. Поэтом без визуального представления шагов бизнес-процесса никак не обойтись. На схеме помимо последовательности шагов, указываются функциональные роли и места выполнения. Не нужно углубляться в тяжелые нотации, в нюансах которых плохо разбирается среднестатистический функциональный заказчик. Например, хорошо себя показывает нотация мини-EPC. Из визуальных элементов в ней только элементы действия, элементы выбора и элементы смежных бизнес-процессов, что позволяет интуитивно ориентироваться в ней практически любому функциональному заказчику.
Шаги бизнес-процесса. Текстовое представление предыдущего раздела. Подробно описывается каждый элемент действия и элемент выбора. Указывается какие объекты системы используем, какие поля заполняем, какие команды выполняем. Все это делаем в терминологии максимально приближенной к системе.
Требования. Фиксируем требования, возникшие в ходе моделирования. Это могут быть требования как к в внедряемой системе, так и к внешней. Это могут быть требования, для реализации которых потребуется доработать систему, так и требования, которые реализуются уже имеющейся функциональностью системы.

А на это точно нужно тратить время?

В теории этап моделирования бизнес-процессов можно пропустить. Даже скажу больше – это позволит существенно сократить затраты интегратора. Но сработает это при следующих условиях:

Предметная область хорошо знакома проектной команде интегратора (например, команда из проекта в проект внедряет системы по регламентированному учету или производственному планированию)
У проектной команды интегратора высокие компетенции во внедряемой программном продукте (например, в 1С:ERP или 1С:УХ)
У проектной команды интегратора имеется успешный опыт внедрения программного продукта в конкретной отрасли (например, в ОПК или химической промышленности)

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

Мне встречались вполне успешные примеры такого подхода. Например, одна проектная команда внедряла только кадровый учет и расчет оплаты труда на программном продукте 1С:ЗУП, а другая проектная команда внедряла только регламентированный учет на программном продукте 1С:УПП в энергетике и машиностроении.

Но это идеальные условия, которые вряд ли могут соблюдаться на длительной дистанции. Что делать если рынок «интегратора» резко сменился на рынок «заказчика», и интегратору приходится не продавать то, что он умеет внедрять, а внедрять то, что он сумел продать (не соблюдаются условия про предметную область и опыт в отрасли)? Что делать если вендор выпускает новый флагманский программный продукт (не соблюдается условие про компетенции в программном продукте)?

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

Заключение

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

«Лишний» этап