Почему так велика доля проектов, не укладывающихся в сроки или бюджет? Корень зла кроется в господствующем представлении о том, что крупный ИТ-проект можно хорошо выполнить «с одной попытки», не учитывая постоянных изменений бизнес-процессов. Правильным я
Дискуссия о том, «кто виноват в удручающей статистике ИТ-проектов и что с этим делать» завершила 14-й CIO-форум, прошедший 20—21 сентября в Москве. Тема оказалась настолько актуальной, что отведенного на нее времени не хватило.
Действительно, проектов, не укладывающихся в сроки или бюджет, слишком много. Кроме того, итоги успешных в целом проектов нередко вызывают неудовлетворение — «приобретали ERP-систему, а получили приложение для ввода непонятных данных с неопределенными целями». Как заметил один из участников дискуссии, «проект стоимостью более миллиона долларов неуспешным не может быть в принципе», так как затрагивает слишком серьезные интересы.
У поставщиков своя правда — «заказчик всегда просит не то, чего хочет, а хочет не то, что ему на самом деле нужно». Конечно, крупные ИТ-проекты, по масштабу сопоставимые с внедрением ERP-системы, сопряжены со многими рисками. Но, похоже, обе стороны сходятся во мнении, что один из самых серьезных — риск, связанный с автоматизацией не до конца понятых или явно неоптимальных бизнес-процессов. Проекты стартуют при наличии неполных, не детализированных или противоречивых требований, причем больше всего проблем возникает с бизнес-требованиями верхнего уровня, то есть с описанием бизнес-процессов.
Конечно, можно провести всесторонний анализ бизнес-процессов до начала ИТ-проекта. Но, как свидетельствуют многочисленные эксперименты, так называемый «системный подход» к анализу бизнес-процессов оборачивается многомесячными усилиями, результатом которых являются сотни страниц бумажных диаграмм, устаревающих еще до завершения проекта. Поэтому поставщик вынужден начинать ИТ-проект, имея на руках размытые бизнес-требования, и, используя технологию, политику, материальные стимулы и даже психологическое воздействие, добиваться субъективной удовлетворенности заказчика в лице отдельных его представителей.
Вендоры предлагают другой рецепт: «не надо ничего изобретать, оптимальные бизнес-процессы уже реализованы в нашей системе». Конечно, в крайне запущенных ситуациях он может помочь. Но конкурентного преимущества вы таким способом не получите: не может быть преимуществом то, что доступно любому желающему. Схема основных бизнес-процессов компании — это ее управленческое «ноу-хау», и им не принято делиться.
У ряда заказчиков (и это явно прозвучало в ходе дискуссии) возникает соблазн разрубить этот узел противоречий одним ударом. В конце концов есть желаемый конечный результат — в идеале это просто увеличение нашей прибыли за счет либо снижения издержек, либо увеличения дохода: «Мы поставщику платим деньги — так пусть обеспечит!»
Не претендуя на объективность (автор принадлежит к лагерю поставщиков), замечу лишь одно: брать обязательства можно только в отношении того, что находится под твоим контролем. А успех проекта внедрения в конечном итоге зависит от того, будут ли пользователи работать с системой. И при желании причину чтобы не работать — так уж устроен человек — любой из нас находит без труда. Равно как и причину, чтобы все оставить как есть и ничего не менять. Поэтому естественной инерции необходимо противопоставить волю руководителя и материальную заинтересованность исполнителей. Но поставщику ведь не дают права издавать приказы, премировать или наказывать сотрудников заказчика. Значит, возможна ситуация, когда он сделал свою работу, но заказчик ее результатами не воспользовался. «Чтобы привести лошадь к воде, достаточно одного человека. Но даже сто человек не могут заставить ее пить».
Согласен: поставщик не всегда хорошо выполняет свою работу. Но разве можно с этим бороться, выдвигая заведомо нереалистичные требования? Ответственный поставщик не должен подписываться под тем, чего он не может гарантировать. Настаивая на подобной точке зрения, заказчик открывает доступ к сотрудничеству заведомо недобросовестным поставщикам.
Все сказанное выше не претендует на новизну. Хорошо известны и стандартные рецепты: заказчику — ответственно подходить к выбору поставщика, поставщику — осваивать науку управления требованиями, а тем и другим — учиться слушать друг друга. Но помогают они слабо.
По моему убеждению, корень зла — в широко распространенном заблуждении, что крупный ИТ-проект можно хорошо выполнить «с одной попытки». Сплошь и рядом в начале проекта требования проработаны плохо — это признают и заказчики, и поставщики. Бытует мнение, что проблему можно решить, если стремиться тщательнее подойти к определению требований и, в частности, к спецификации бизнес-процессов. Мнение это, однако, ошибочное.
Приемлемую схему бизнес-процесса невозможно разработать ни с первой, ни со второй попытки. Этот факт вытекает из опыта проектов реализации методики управления бизнес-процессами (Business Process Management, BPM). В литературе приводится такая статистическая оценка: чтобы специфицировать существующий процесс с достаточной точностью (то есть так, чтобы его можно было исполнить в соответствии с полученной схемой), команде, не имеющей опыта, требуется порядка десяти итераций, а тем, кто накопил необходимую компетенцию — около пяти. При этом каждая итерация состоит из цикла: моделирование, исполнение, анализ результатов.
Спрашивается, каковы шансы получить удовлетворительный результат, если типичный ИТ-проект планируется так, что требования к его результатам (включая верхний уровень — уровень схем бизнес-процессов) определяются один раз, вначале? Шансы невелики. Таким образом, удивляться надо не тому, что некоторые ИТ-проекты заканчиваются неудачей, а тому, что имеются успешные.
Какую пользу ИТ-проектам может принести BPM? Дело в том, что в методологию BPM изначально заложена идея непрерывно меняющихся бизнес-процессов. И то, что для традиционного проекта является тяжелым кризисом, а именно изменение схемы бизнес-процесса в середине проекта — для проекта BPM является происшествием не то что безболезненным, а желательным и даже необходимым. Если бизнес-процесс воспринимается как нечто жестко заданное, то это определенно не BPM-проект. Вы только тогда можете считать, что освоили BPM, когда вы научились безболезненно менять схему бизнес-процесса всякий раз, когда в этом возникает необходимость. А возникать она может по самым разным причинам: изменение условий ведения бизнеса «сверху», действия конкурентов, растущие требования клиентов, появление новых рынков и новых партнерских сетей, слияния и поглощения.
Приступая к крупному ИТ-проекту по традиционному шаблону, вы уподобляетесь стрелку, который пытается поразить цель с одного выстрела в условиях, когда видимость никудышняя, а объект непрерывно движется, умело маскируется, выбрасывает ложные цели. Разговоры о том, что надо ответственнее подходить к постановке задачи, равносильны предложению поставить на винтовку оптический прицел. Может быть, лучше взять автомат с магазином на сорок патронов? Он гарантирует поражение цели.
Таким автоматом для стрельбы по бизнес-целям является BPM. Хватит стрелять одиночными, переходите на стрельбу очередями!
Анатолий Белайчук — президент компании «Бизнес-Консоль», bell@b-k.ru