Оценка временных рисков при внедрении ERP-систем

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

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

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

Все же, по некоторым данным можно сказать, что менее 20% проектов заканчиваются вовремя и более 50% – превышают бюджет.

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

КРИТЕРИИ УСПЕХА И НЕУСПЕХА

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

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

Далее мы остановимся на рассмотрении причин, по которым время реализации ИТ-проекта может быть оценено неверно. Их и будем именовать "рисками".

ОТ КОГО ЗАВИСИТ УСПЕХ

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

Не получится, подобно пациенту стоматолога, прийти и, заплатив деньги, просто открыть рот, а остальное сделает доктор. Кстати, даже здесь от пациента требуется сделать несколько действий, не все делает врач.

Основываясь на опыте компании СофтПро, можем сказать, что среди украинских потребителей, с которыми она работала, по пальцам можно пересчитать тех, кто в должной мере осознает свою ответственность в успехе. Подход многих заказчиков сводится к правилу: "покажите мне меню, а я выберу понравившиеся мне блюда". Так не получится. Придется и в рецептуру блюд вникать, и понимать, почему именно это, а не другое. Вместе – и исполнителю, и заказчику. ERP-система строится на долгие годы, и стороны должны жить, как минимум, в мире и взаимопонимании.

ЧТО ЖЕ МЕШАЕТ УСПЕХУ И ЧТО С ЭТИМ ДЕЛАТЬ

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

Автоматизация в эпоху перемен. Эта ситуация возникает, когда внедрение системы проходит одновременно с перманентной реорганизацией самой компании. Например, в корпорации открываются/закрываются новые юридические лица или филиалы, меняются направления деятельности. Другой момент, если меняются процессы низкого уровня: правила документооборота, делопроизводства.

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

Плохая формализация задания. Один из самых важных этапов подготовки к проекту – формализация предмета автоматизации по принципу "как должно быть". Речь идет о составлении сторонами технического задания проекта (ТЗ). По нашему опыту, этот документ должен включать цели проекта и ожидаемые результаты от его внедрения.

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

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

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

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

Смена исполнителей. Пословица про "коней на переправе" хорошо описывает данную проблему. Уход ключевого исполнителя – с любой из сторон – крайне негативно отобразится на проекте.

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

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

Нестандартные технологии. Заказчик вправе требовать некоторый функционал от будущей системы, который отсутствует в ее прототипе. Приходится сталкиваться с пожеланиями вроде: "Хотим, чтобы в вашей ERP-системе было как в …", после чего называется система класса Project Management. Конечно, исполнитель ищет пути для подобного решения, но нужно помнить, что принципиально новые технологические возможности являются еще одним источником риска непрогнозируемого увеличения объемов работ.

Некомпетентность исполнителей. Как известно, "кадры решают все". К сожалению, риск этого фактора никогда не сводится к нулю, и лучше попытаться оценить его заранее. А относится он к обеим сторонам проекта.

Список можно продолжать, но остановимся на этом.

КОЛИЧЕСТВЕННАЯ ОЦЕНКА РИСКОВ

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

Сведем риски в таблицу, напротив каждого впишем два числа. В колонке "Значение"(ЗН) проставим число в диапазоне 0÷1. Это не что иное, как вероятность возникновения этого риска.

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

Интегральный риск проекта (ИРП) можно будет оценить по формуле:
n
ИРП = 1+∑(BK_i+ЗН_i)
i+1

где N – оцениваемое число рисков.

Пример такой оценки приведен в таблице.

Таблица. Пример оценки рисков

В этом примере срок реализации проекта необходимо увеличить в 1.65 раза. Ясно, что соответствующим образом должен быть скорректирован и бюджет проекта.

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

Получив этот результат, стороны (обязательно совместно) должны продумать меры по снижению полученных значений рисков. Возможно, в следующей итерации по определению оценки интегральное значение рисков будет более оптимистическим. Практика показывает, что после оценки рисков по этой методике и принятия мер по их снижению, экономия размеров бюджета проекта может составлять до 20%.

— Александр Айдаров, Юрий Витовский