Журнал «Компьютерра» № 8 от 28 февраля 2006 года

ТЕХНОЛОГИИ: Как сделать успешный ERP-проект

Автор: Дмитрий Мартынов

Какой ERP-проект можно считать успешным? Тот, который работает. Формулировка условная, но для обсуждения проблем, затронутых в статье, ее достаточно. Эффективность работающей системы состоит из множества компонентов, из которых обычно учитывают лишь небольшую часть. Введем упрощение: если ERP работает, то работает эффективно (наоборот бывает невероятно редко).

Однако такой критерий успешности больше подходит для Заказчика. Для Исполнителя (приносим извинения за юридическую терминологию, но в данном случае точнее не скажешь. — Прим. ред.) еще важен и финансовый результат затраченных усилий. Главная причина неопределенности будущего любого ERP-проекта — разные критерии успешности у Заказчика и у Исполнителя проекта.

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

Заказчик и Исполнитель заключают договор на внедрение ERP-системы. В соответствии с договором проект разбивается на этапы. Оплата работ распределяется (более или менее равномерно) по этапам, включая предоплату и завершающий платеж. В начале обследование, потом настройка системы и наконец внедрение. Международные методики предусматривают стандартный набор документов, который гарантирует правильность обследования. Готовится описание бизнес-процессов (БП), затем — техническое задание (ТЗ) на проект. На следующем шаге Исполнитель настраивает систему. Методику описания регламентирует документ «Описание настроек системы».

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

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

1.1. Взгляд со стороны заказчика

Все начинается с того, что руководство Заказчика принимает решение о начале проекта. В этот момент Исполнитель обычно еще не известен, и курировать проект начинает собственный специалист Заказчика. Его так и называют — Куратором проекта. Он отвечает за формирование команды, которая подготовит проект, распланирует его и выберет исполнителя. Очевидно, что успех всей затеи во многом зависит от того, насколько удачно был выбран Куратор. Ведь проблемами большинства ERP-проектов являются:

< низкая квалификация Куратора в области информационных технологий;

< и/или недостаточная квалификация Куратора в области бизнеса Заказчика;

< и/или низкая ответственность Куратора за результаты проекта;

< и/или недостаточная мотивация Куратора на результаты проекта;

< и/или низкая зарплата Куратора.

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

Порой Куратор выбирается до того, как принято окончательное решение о запуске ERP-проекта, и в его задачи, помимо прочего, входит поиск Исполнителя — для этого ни полномочий, ни ответственности не требуется. А дальше все идет по стандартному сценарию: к Заказчику приезжают специалисты фирмы-интегратора, устраивают презентацию (главная цель которой — успокоить Заказчика и создать впечатление, что особых проблем с проектом не предвидится) и, если презентация прошла удачно, начинают обсуждать подписание договора. Договор готовит Исполнитель, так как для Заказчика договор не профильный и у него нет юристов, имеющих соответствующую квалификацию. Как следствие, в договоре отсутствуют требования к результату проекта, а есть только требования к процессу проекта (то есть по сути — требования Исполнителя).

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

1.2. Взгляд со стороны исполнителя

Введем упрощение. Будем считать, что невнедренный проект не влияет на репутацию Исполнителя. Это не совсем верно, но верно настолько, что мы можем это допустить.

С точки зрения Исполнителя очевидно следующее:

< Результат проекта неизвестен.

< Договор заключать надо так, чтобы получить прибыль.

< Чем больше денег будет получено до начала внедрения, тем лучше.

Исполнитель знает, что составить такие описания бизнес-процессов и другую требуемую для проекта документацию, которую подпишет комиссия Заказчика, в общем-то нетрудно.

2.1. Описание бизнес-процессов

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

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

Обычно Исполнитель хотя бы часть дополнительных веток БП описывает. Но часто Заказчик не замечает, что некоторые ветки были упущены. Это может происходить по нескольким причинам, часть которых является следствиями ошибок, допущенных на этапе формирования проектной команды Заказчика:

1. Специалистами Заказчика, ответственными за приемку работ, являются ИТ-специалисты, и их квалификации недостаточно для оценки качества документа.

2. Ответственность своих специалистов оценивается Заказчиком неадекватно. То есть человек, принимающий основные решения по проекту общей стоимостью 500 тысяч долларов, может иметь зарплату 1 тысячу долларов.

3. Ответственность за результат работы отодвинута во времени на длительный срок. Если описание БП будет неправильным, это станет заметно только через несколько месяцев.

4. У специалистов заказчика есть другие сложные задачи, вне данного проекта, ответственность по которым сиюминутная и дорогая.

5. Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне.

6. Бизнес-процессы могут измениться к моменту начала внедрения.

Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.

В результате получается документ, качество которого не соответствует потребностям проекта. Несмотря на это у Исполнителя не возникает проблем с закрытием этапа по указанным выше причинам.

2.2. Техническое задание на проект

Техническое задание — это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? Дело в том, что аппетит зачастую приходит во время еды, требования Заказчика в процессе внедрения обычно начинают расти, и одна из задач консультантов Исполнителя — держать Заказчика в рамках.

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

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

2.3. Настройка системы, описание доработок

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

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

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

2.4. Доработка системы

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

2.5. Обучение (свет в конце тоннеля)

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

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

Требования пользователя не всегда разумны (а значит, не всегда их надо выполнять). Однако в процессе обучения часто всплывают на поверхность действительные недостатки проекта, которые ранее не были очевидны.

Этот момент Заказчик может использовать для того, чтобы заставить Исполнителя внести изменения в уже подписанные документы. Но чтобы использовать этот этап в своих интересах, у Заказчика должна быть грамотная проектная команда, мотивированная на результаты проекта.

2.6. Зачем такой длительный предпроект?

Устав проекта, ТЗ, описание БП, настройки системы, доработка системы. Зачем так много документации? Для стабильности. Исполнитель должен гарантировать сроки и качество при любых условиях. Например, если уволится ведущий специалист, на его место придет другой, прочтет документацию, быстро разберется и продолжит проект.

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

Когда будет выполнено все, кроме последнего этапа, нет гарантий, что полученная система сможет быть внедрена. Для Исполнителя важно, что почти все деньги получены. Если последний этап выполнить не удается, то для Исполнителя в этом нет ничего страшного. Риски незначительны. Он рискует:

< Неполученным остатком денег из бюджета проекта.

< Своей репутацией.

< Невыполнением обязательств по договору.

Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно. Риск потери репутации отсутствует — мы ввели такое допущение (почему, объясняется в разделе «Итоги не для всех»). Невыполнение обязательств по договору — тоже риск несущественный. Договор готовил Исполнитель и заранее продумал наличие в договоре лазеек для сложившейся ситуации.

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

2.7. Внедрение

Последний этап обычно очень сложен. Прежде всего из-за низкого качества выполнения задач предпроекта. Но есть и другая причина.

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

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

Дальше сценарии бывают разные. Если Заказчик располагает ресурсами или инструментами давления на Исполнителя, то конфликт улаживается. Проект удается внедрить — пусть с большим опозданием и зачастую с увеличением бюджета.

Часто Заказчик, не видя никакого результата, не готов к дополнительным затратам. И получается проект без заключительного пресс-релиза о результатах внедрения. Таких большинство.

2.8. Итоги не для всех

С точки зрения Исполнителя технология хороша. При достаточной раскрутке компании она позволяет получать деньги, почти не отвечая за результат. Чтобы сделать себе имя, достаточно одного удачного проекта, который берется за основу рекламной кампании.

Технологию можно и усовершенствовать. Стоимость этапов определяется как время работы, умноженное на ставку специалиста. Если поднять внешнюю ставку консультанта и уменьшить ставку программиста, то можно будет оценить начальные этапы еще дороже, а заключительные, наоборот, дешевле. И тогда до начала внедрения можно будет получить порядка 90% всей суммы. Эта идея была реализована довольно давно, хотя большинство специалистов до сих пор не отдает себе отчет в том, почему ставки программистов и консультантов отличаются на 20—60% (раз таковы ставки, значит, зарплаты программистов тоже должны быть меньше — такой вывод для себя делают менеджеры).

В результате в сообществе ERP звание «программист» менее престижно, чем звание «консультант», несмотря на то что первая профессия изначально подразумевает более высокую квалификацию. Эта ситуация ставит дополнительное ограничение при внедрении. У интеграторов часто не хватает квалифицированных программистов, которые очень нужны на заключительных этапах.

Указанные здесь рекомендации могут быть использованы полностью или частично в зависимости от проекта.

3.1. Кому доверить подготовку проекта

Один из вариантов повлиять на качество предпроектных работ (описание бизнес-процессов, техническое задание) — это заключать на них отдельные договора с Исполнителем. Если результатом проекта для компании является описание бизнес-процессов, она обычно больше заботится о его качестве.

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

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

3.2. Как подписывать предпроектную документацию

Часто на этапе внедрения в случае возникновения проблем Исполнитель заявляет «Вы сами это просили» и показывает предпроектную документацию, подписанную Заказчиком. Она же, в случае чего, будет показана и в суде. Как от этого застраховаться?

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

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

3.3. Планирование средств

При планировании бюджета проекта рекомендую зарезервировать дополнительные денежные средства в размере хотя бы половины стоимости договора, о которых Исполнитель знать не должен (если Исполнитель про них знает, он спланирует проект так, чтобы их получить). Эти деньги пойдут на покрытие расходов, связанных с несоответствием ТЗ и потребностей проекта.

3.4. Состав внутренней проектной группы

В проектную группу должны войти компетентные ИТ-специалисты и компетентные специалисты из бизнеса.

3.5. Мотивация внутренних специалистов на результат

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

3.6. Борьба с откатами

Зачастую Куратор проекта со стороны Заказчика получает откат от Исполнителя. Размер отката бывает разный — от 5 до 50% стоимости проекта. С этим можно бороться.

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

На правах рекламы

Компания Koder Logic занимается разработкой и внедрением коммерческих учетных систем в торговых фирмах и промышленных предприятиях. Основное направление — внедрение системы Microsoft axapta. Ведущие специалисты компании работают с axapta с 2000 года. Также Koder Logic разрабатывает индивидуальные системы класса ERP.

Все специалисты компании имеют необходимые сертификаты. Однако при формировании команды мы смотрим прежде всего на опыт и достигнутые результаты в разрезе реального повышения эффективности бизнеса заказчика. Телефон: +7(495)723-26-71.