Три разрыва между видением и реальностью

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

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

В этом посте мне бы хотелось обратить внимание на разрывы, возникающие на стыке звеньев общей модели, а также "клей", используемый для устранения этих разрывов. Кстати, автор не исключает существования иных клеящих основ и с удовольствием ознакомится с таковыми :)

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

Разрыв между описанием процессов верхнего уровня и регламентированными процедурами. Как сделать так, чтобы отдельно взятые процедуры согласования документов, утверждения заявок, приема новых сотрудников и т.д. были согласованы друг с другом? Чтобы не создавались никому не нужные отчеты? Чтобы несколько подразделений не делали одну и ту же работу? Проблемы этого класса как правило решаются через формализацию информационных и материальных потоков: сквозь регламенты процедур должны проходить ровно те потоки, которые участвуют в описании бизнес-процессов верхнего уровня. Надо сказать, что эта работа исключительно трудоемка, и даже если она делается - часто полученные формализации потоков оказываются не совсем точными. Но даже с погрешностями это хорошая страховка от явных перекосов, когда персонал перегружен, а результаты труда не используются.

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