Когда мы покупаем новый холодильник или, например, новую стиральную машину, то старую мы обычно выбрасываем. С внедрением в компании новых подходов и практик ситуация не такая. Обычно новые практики дополняют уже существующие. «Следующая большая вещь» ложится поверх предыдущей «большой вещи», под которой лежит еще несколько культурных слоев больших и не очень больших вещей. В этом сэндвиче описание бизнес-процессов занимает свое достойное место между техническим заданием на автоматизацию и требованиями пользователей.
Мне всегда казалось, что хорошее описание бизнес-процессов позволяет отказаться от такого артефакта как требования и существенно разгрузить то, что принято называть техническим заданием. К сожалению, этого зачастую не происходит. Если требования, по крайней мере, требования в понимании IEEE 830, еще как-то уживаются с техническим заданием в понимании ГОСТ 34.602 (их просто включат в соответствующий раздел ТЗ), то про описание бизнес-процессов нет упоминаний ни в одном из этих документов. Потому там где они существуют, существуют они сами по себе.
Уместным еще будет вспомнить про идею архитектуры предприятия (Enterprise architecture), включающую в себя бизнес архитектуру. Если не вдаваться в детали, то суть идеи заключается в том, чтоб разработать матрицу зависимости между подразделениями компании и процессами, в которых они участвуют. Т.е. речь идет не о бумаге, которую каждый проект или каждое подразделение пишет для себя, пишет, причем, каждый раз, когда возникает необходимость в том, чтоб «наконец как следует во всем разобраться», а о едином подходе в рамках всей компании. Говоря еще проще, мы запрещаем подразделениям и проектам заниматься описанием процессов в любимом текстовом редакторе, предоставляем единую модель и инструмент для создания и использования описания процессов, инструкций, руководств и прочих бумаг, регламентирующих деятельность сотрудников.
На мой взгляд, это направление развития бесславно капитулировало, так и не решив поставленных перед собою задач. BPM тусовка переключилась на моделирование этапов отдельного процесса, обсуждение BPMN и возможностей «исполнения» нарисованных в данной нотации процессов. Но, тем не менее, задача сокращения околопроцессных бумаг, согласованности зафиксированных в них утверждений и устранения разрыва между реальностью и моделью может быть решена. Пусть всего лишь в рамках отдельных активностей и проектов.
Надо просто выбросить лишнее.