Как сделать успешный ERP-проект 1
Статья опубликована в еженедельнике "Компьютерра" № 8 от 28.02.2006г.
Какой ERP-проект считать успешным? Который работает. Формулировка условная, но для обсуждения проблем затронутых в статье, ее достаточно. Эффективность работающей системы состоит из множества компонентов, из которых учитывают небольшую часть. Введем упрощение: если ERP работает, то работает эффективно.
Такой критерий успешности подходит для Заказчика. Для Исполнителя важен и финансовый результат затраченных усилий. Причина неопределенности будущего любого ERP-проекта - разные критерии успешности у Заказчика и у Исполнителя проекта.
Существует множество методик внедрения. Придумывали их компании интеграторы, то есть Исполнители. Они решали прежде всего свои задачи, а уж потом задачи клиента.
1. Как устроен ERP-проект
Мы готовы завязать оплату на результаты проекта, но только в случае, если на период проекта мы поставим на предприятии своего генерального директора.
Выдержка из презентации в рамках тендера на внедрение ERP.
Заказчик и Исполнитель заключают договор на внедрение ERP-системы. В соответствии с договором проект разбивается на этапы. Оплата работ распределяется по этапам, включая предоплату и завершающий платеж. В начале обследование, потом настройка системы и наконец внедрение. Методики предусматривают стандартный набор документов, который гарантирует правильность обследования. Готовится описание бизнес-процессов (БП), затем - техническое задание (ТЗ) на проект. Дальше Исполнитель настраивает систему, и создает документ "Описание настроек системы".
Затем реализуются доработки и проводится обучение персонала. Все действия можно разделить на четыре-пять этапов, каждый из которых продолжается от одного до полутора месяцев.
Последний и главный этап - внедрение. Это самая сложная часть, в которой и заключается суть проекта. Если внедрение прошло удачно - даже при отсутствии предыдущих этапов (что, в принципе, возможно - есть примеры), то проект будет успешным. Если предыдущие этапы успешно реализованы, а с последним не сложилось, то проект "завален", система не работает, а документация, составленная на первых этапах внедрения, никому уже не понадобится. Поэтому все этапы до внедрения называют предпроектными работами.
1.1. Со стороны заказчика
Руководство Заказчика принимает решение о начале проекта. Исполнитель еще не известен, и курировать проект начинает специалист Заказчика. Его называют - Куратором проекта. Он отвечает за формирование команды, которая подготовит проект, распланирует его и выберет исполнителя. Успех затеи во многом зависит от того, насколько удачно был выбран Куратор. Ведь проблемами большинства ERP-проектов являются:
- низкая квалификация Куратора в области информационных технологий;
- и/или недостаточная квалификация Куратора в области бизнеса Заказчика;
- и/или низкая ответственность Куратора за результаты проекта;
- и/или недостаточная мотивация Куратора на результаты проекта;
- и/или низкая зарплата Куратора.
Пытаясь снизить возможные издержки от неудачного выбора Куратора, Заказчик может совершить серьезную ошибку, доверив все Исполнителю. Зачастую это происходит на этапе выбора Куратора (когда Исполнитель еще неизвестен) и формулируется примерно так: "Мы найдем фирму, которая нам все сделает".
Порой Куратор выбирается до того, как принято окончательное решение о запуске ERP-проекта, и в его задачи, помимо прочего, входит поиск Исполнителя - для этого ни полномочий, ни ответственности не требуется. Дальше все идет по стандартному сценарию: к Заказчику приезжают специалисты фирмы интегратора, устраивают презентацию (главная цель которой - успокоить Заказчика и создать впечатление, что особых проблем с проектом не предвидится) и, если презентация прошла удачно, начинают обсуждать подписание договора. Договор готовит Исполнитель, так как для Заказчика договор не профильный и у него нет юристов, имеющих соответствующую квалификацию. Как следствие, в договоре отсутствуют требования к результату проекта, а есть только требования к процессу проекта (то есть по сути - требования Исполнителя).
В конечном счете Исполнителю доверяется и выполнять проект, и контролировать его выполнение. Иными словами, ему поручается следить за самим собой.
1.2. Взгляд со стороны исполнителя
Введем упрощение: невнедренный проект не влияет на репутацию Исполнителя. Это не совсем верно, но верно настолько, что мы можем это допустить.
С точки зрения Исполнителя очевидно следующее:
- Результат проекта неизвестен.
- Договор заключать надо так, чтобы получить прибыль.
- Чем больше денег будет получено до начала внедрения, тем лучше.
Исполнитель знает, что составить такие описания бизнес-процессов и другую документацию для проекта, которую подпишет комиссия Заказчика, нетрудно.
2. Выполнение проекта
- Да кто вас боится! - сказала Алиса ..... - Вы просто несчастные карты - и все!
Льюис Кэрролл.
2.1. Описание бизнес процессов
Заказчик принимает описание бизнес процессов (БП), указанных в договоре.
Главная цель Исполнителя - понравиться, и у него большое поле для маневра. В описании бизнес процессов важна детализация. Большинство бизнес процессов кроме основной ветки включают и другие, дополнительные, которые происходят реже, К примеру, в процессе производства (основная ветка) может обнаружиться брак, ошибка конструкции или на склад недопоставят материал, ценный специалист, без которого не запустить определенное оборудование, может заболеть и т. д. Без учета этих ситуаций описание бизнес-процессов будет неполным, его нельзя использовать для задач Заказчика (точнее, можно, до тех пор, пока не случится нештатная ситуация).
Исполнитель хотя бы часть дополнительных веток БП описывает. Но Заказчик не замечает, что некоторые ветки упущены. Это происходит по причинам, часть которых следствие ошибок, допущенных на этапе формирования проектной команды Заказчика:
- Специалистами Заказчика, ответственными за приемку работ, являются ИТ-специалисты, и их квалификации недостаточно для оценки качества документа.
- Ответственность своих специалистов оценивается Заказчиком неадекватно. То есть человек, принимающий основные решения по проекту общей стоимостью 500 тысяч долларов, может иметь зарплату 1 тысячу долларов.
- Ответственность за результат работы отодвинута во времени на длительный срок. Если описание БП плохое, это станет заметно через несколько месяцев.
- У специалистов заказчика есть другие сложные задачи, вне ERP проекта, ответственность по которым сиюминутная и дорогая.
- Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне.
- Бизнес-процессы могут измениться к моменту начала внедрения.
Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.
В результате качество документа, не соответствует потребностям проекта. Но у Исполнителя не возникает проблем с закрытием этапа.
2.2. Техническое задание на проект
Техническое задание - это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? Аппетит приходит во время еды: требования Заказчика в процессе внедрения обычно начинают расти, и задача консультантов Исполнителя - держать Заказчика в рамках.
Принимается этот документ так же, как принимается описание бизнес-процессов. Заказчик заставит Исполнителя включить в задание еще пару пунктов, которые неявно упоминались в договоре. Специалисты Заказчика довольны - им удалось настоять на своем. Исполнитель доволен - этап закрыт.
Но ТЗ готовится на основании предыдущего документа, качество которого, зачастую неудовлетворительное. Все недостатки описания бизнес-процессов находят свое отражение и здесь.
2.3. Настройка системы, описание разработки (программирования)
Настройка системы требует грамотного консультанта. Это уже технология, и ясно, за что платятся деньги - у Заказчика нет специалиста, который сможет это сделать. Описание доработок - документ еще более сложный. Консультант, знающий систему, определяет, что из технического задания системе по силам, а что потребует разработки дополнительных программ.
Оба документа готовятся на основании предыдущих документов, качество которых не соответствует потребностям проекта. Поэтому на этапе внедрения часто требуется срочно перенастраивать систему и программировать другие доработки, а программы, написанные заранее, остаются невостребованными.
Но у Заказчика нет специалистов, способных оценить качество этих документов, следовательно, никаких проблем с приемкой этапа не возникает.
2.4. Доработка системы
Этап доработки системы для Исполнителя может себя окупить. Важно, чтобы все написанные программы соответствовали описанию и прошли тесты. Получается система, выдержавшая тесты, придуманные Исполнителем.
2.5. Обучение (свет в конце тоннеля)
Этап может принести пользу Заказчику в смысле контроля за подготовкой ERP проекта. Для этого обучение пользователей должно проводиться на настроенной системе, в которой выполнены доработки.
Пользователи начинают бунтовать. У пользователя много причин для бунта. Его устраивала прежняя система. Новая система кажется ему сложной, и у него есть шанс обратить внимание разработчиков на недостатки (как ему кажется) интерфейсов и необходимость оптимизации каких-либо функций.
Требования пользователя не всегда разумны (а значит, не всегда их надо выполнять). Однако в процессе обучения всплывают на поверхность действительные недостатки проекта.
Этот момент Заказчик может использовать, чтобы заставить Исполнителя внести изменения в подписанные документы. Но чтобы использовать этот этап в своих интересах, у Заказчика должна быть грамотная проектная команда, мотивированная на результаты ERP проекта.
2.6. Зачем такой длительный предпроект?
Позвольте, мамаша! На станции,
Согласно багажной квитанции,
От вас был получен багаж:
Диван, чемодан, саквояж,
Корзина, картина, картонка
И маленькая собачонка.
Однако во время пути
Собака могла подрасти!
Самуил Маршак, "Багаж"
Устав проекта, ТЗ, описание БП, настройки системы, доработка системы. Зачем так много документации? Для стабильности. Исполнитель должен гарантировать сроки и качество при любых условиях. Например, если уволится ведущий специалист, на его место придет другой, прочтет документацию, быстро разберется и продолжит проект.
Увы, длительные предпроектные работы служат и другой цели Исполнителя - получить большую часть денежных средств из бюджета проекта до начала сложного заключительного этапа - внедрения системы.
Когда будет выполнено все, кроме последнего этапа, нет гарантий, что система сможет быть внедрена. Для Исполнителя важно, что почти все деньги получены. Если последний этап выполнить не удается, то для Исполнителя в этом нет плохого. Риски незначительны. Он рискует:
- остатком денег из бюджета проекта.
- репутацией.
- Невыполнением обязательств по договору.
Для получения оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно. Риск потери репутации отсутствует - мы ввели такое допущение (почему, объясняется в разделе "Итоги не для всех"). Невыполнение обязательств по договору - риск несущественный. Договор готовил Исполнитель и продумал наличие в договоре лазеек.
Получается, на всех этапах Исполнитель имеет одну задачу - задобрить комиссию Заказчика, убедить ее что все путем. Выпускаемые документы служат именно этой цели. Все предпроектные документы подписаны Заказчиком. С юридической точки зрения Заказчик получил то, что заказывал.
2.7. Внедрение
Последний этап очень сложен из-за низкого качества документов предпроекта. Но есть другая причина.
До старта система существует на предприятии в виде идей и лозунгов в умах персонала. Менеджеры нижнего и среднего звена не подозревают, что многое изменится, а внедрение в корне меняет процессы управления. Это производит колоссальный эффект. Представления о том, как и что должна уметь система, радикально меняются и доходят до руководства Заказчика. Возникает потребность надавить на Исполнителя и заставить его сделать то, что нужно. Но надавить нечем.
Почти все деньги, выделенные на проект, потрачены. В суд подать нельзя, документы свидетельствуют о том, что Заказчик получил то, что заказывал. Раздувая скандал в надежде пошатнуть репутацию Исполнителя, Заказчик рискует своей. Поэтому, несмотря на высокий процент проваленных проектов, Заказчик редко подает в суд на Исполнителя.
Дальше сценарии бывают разные. Если Заказчик располагает ресурсами или инструментами давления на Исполнителя, то конфликт улаживается. Проект удается внедрить - пусть с большим опозданием и зачастую с увеличением бюджета.
Часто Заказчик, не видя результата, не готов к дополнительным затратам. И получается проект без заключительного пресс-релиза о результатах внедрения. Таких большинство.
2.8. Итог для Интегратора
С точки зрения Интегратора технология хороша. При достаточной раскрутке компании позволяет получать деньги, не отвечая за результат. Чтобы сделать себе имя, достаточно одного удачного проекта, который берется за основу рекламной компании.
Технологию можно и усовершенствовать. Стоимость этапов определяется как время работы, умноженное на ставку специалиста. Если поднять внешнюю ставку консультанта и уменьшить ставку программиста, то можно оценить начальные этапы дороже, а заключительные, дешевле. тогда до начала внедрения можно получить порядка 90% суммы ERP проекта. Идея реализована давно, хотя большинство специалистов не отдает себе отчет, почему ставки программистов и консультантов отличаются на 20-60% (раз таковы ставки, значит, зарплаты программистов тоже должны быть меньше - такой вывод для себя делают менеджеры Интегратора).
В результате в сообществе ERP звание "программист" менее престижно, чем звание "консультант", несмотря на то, что первая профессия подразумевает более высокую квалификацию. Ситуация ставит дополнительное ограничение при внедрении. У интеграторов часто не хватает квалифицированных программистов, которые очень нужны на заключительных этапах.
3. Как застраховаться от произвола Исполнителя
Может ли разумный человек, учитывая опыт прошедших веков, питать хоть малейшую надежду на светлое будущее человечества?
Курт Воннегут, "Колыбель для кошки"
Указанные рекомендации могут быть использованы полностью или частично в зависимости от проекта.
3.1. Кому доверить подготовку проекта
Один из вариантов повлиять на качество предпроектных работ (описание бизнес-процессов, техническое задание) - заключать на них отдельные договора с Исполнителем. Если результатом проекта для компании является описание бизнес-процессов, она больше заботится о его качестве.
Полезно привлечь к описанию бизнес-процессов компанию, которая специализируется на реструктуризации бизнеса.
Есть риск, что Исполнитель посчитает, что описание не соответствует его стандартам, поэтому не может быть использовано в проекте. Позаботиться об этом надо заранее и заключить с Исполнителем договор, в котором указано, что определенную часть предпроектной подготовки будет выполнять другая, согласованная с Исполнителем компания.
3.2. Как подписывать предпроектную документацию
Часто на этапе внедрения в случае возникновения проблем Исполнитель заявляет "Вы сами это просили" и показывает предпроектную документацию, подписанную Заказчиком. Она же, в случае чего, будет показана и в суде. Как от этого застраховаться?
Если предварительный этап выполняется Исполнителем в рамках всего проекта внедрения, то Заказчик должен понимать, что не имеет гарантий качества документа (описание БП, ТЗ, описание настроек, описание доработок). Документ должен быть подписан Заказчиком так: "Квалификации наших специалистов не достаточно, чтобы оценить качество документа. В проекте мы рассчитываем на квалификацию специалистов Исполнителя, которые считают, что качество документа отвечает потребностям проекта на последующих этапах". Предварительно перед подписанием документа следует попросить Исполнителя написать официальное письмо Заказчику, в котором он должен указать, что считает документ качественным и удовлетворяющим нуждам проекта.
Такой подход позволит на этапе внедрения при отсутствии денежных рычагов давления на Исполнителя иметь рычаги юридические.
3.3. Планирование средств
При планировании бюджета проекта рекомендую зарезервировать дополнительные денежные средства в размере хотя бы половины стоимости договора, о которых Исполнитель знать не должен (если Исполнитель про них знает, он спланирует проект так, чтобы их получить). Эти деньги пойдут на покрытие расходов, связанных с несоответствием ТЗ и потребностей проекта.
3.4. Состав проектной группы
В проектную группу должны войти компетентные ИТ-специалисты и компетентные специалисты из бизнеса.
3.5. Мотивация внутренних специалистов на результат
На время проекта следует заключить с собственной проектной группой особое трудовое соглашение. Оно должно включать: освобождение проектной группы на это время от любой другой работы и ответственности; большую премию по результату внедрения проекта; большой штраф, обнуляющий премию, если ошибки проектной документации не позволят запустить проект в необходимом объеме.
3.6. Борьба с откатами
Зачастую Куратор проекта со стороны Заказчика получает откат от Исполнителя. Размер отката бывает разный - от 5 до 50% стоимости проекта. С этим можно бороться.
В случае успешного результата проекта Куратор должен получить премию в размере не менее 5% первоначальной стоимости проекта. Официальная премия всегда весомее отката. Куратор и другие специалисты Заказчика должны быть предупреждены, что находятся на особом контроле его службы экономической безопасности.
Статья опубликована в "Компьютерре" № 8 от 28.02.2006г. но на ее сайте нет иллюстраций.
С разрешения редации публикуем PDF с картинками:
Москва 2006г. Автор статьи: Мартынов Дмитрий - консультант ИГ "КИБОРГ". Автор илюстраций к статье ?? - художник Компьютерры.
|
