ERP-ПРОБЛЕМЫ
Тот, кто хоть однажды брался за выполнение какого-нибудь проекта, на своем опыте знает, как трудно бывает выдержать его плановые характеристики: сроки, бюджет, объем работ. (Для примера можете вспомнить недавний ремонт своей квартиры - неужели вам не пришлось многократно добавлять денег и передвигать срок его окончания?) ERP-проект существенно масштабнее ремонта квартиры по всем перечисленным показателям, а потому удержаться в рамках еще труднее. Тем более что если не предусмотреть ряд ситуаций в начале проекта, то это может вылиться в серьезные проблемы при его завершении. Своим видением о том, где стоит "постелить соломку", с нами поделился Алексей Ананьин, генеральный директор Группы компаний "Борлас" - системного интегратора и самого крупного российского партнера Oracle, сертифицированного для выполнения проектов на базе Oracle E-Business Suite.
Первое - это отношение заказчика к ERP-проекту. Если клиент рассматривает его как проект по внедрению некоего программного обеспечения, то у мероприятия много шансов стать неуспешным. На самом деле это бизнес-проект, начиная который топ-менеджеры (спонсоры проекта), должны отчетливо представлять, зачем им это надо. Я не согласен с мнением некоторых коллег из других компаний, утверждающих, что сначала надо выстроить правильные бизнес-процессы на предприятии, а потом начинать ERP-проект. Сначала надо определиться с целями, а потом уже вместе с консультантами рассматривать разные варианты их достижения. В том числе и с помощью ERP-системы.
Второе - некоторые важные технологические аспекты внедрения ERP-системы, которые часто остаются за кадром в начале проекта. Такие, как создание интерфейсов с параллельно работающими системами, очистка и перенос данных, выверка и загрузка остатков на счетах, нормативно-справочной информации и пр. Этим вопросам, как правило, уделяется внимание уже в конце, когда надо запускать систему. А быстро это не получается. Срок запуска системы в эксплуатацию может уехать очень далеко, если недооценивается трудоемкость решения этих задач. А она может составлять 25-30% от общей трудоемкости проекта.
Что следует учитывать при составлении бюджета |
Если бы пришлось оценивать развертывание крупной ERP-системы с нуля (например, на только что отстроенном предприятии, где нет никаких сетей и компьютеров), то стоимость инфраструктуры была бы, по мнению специалистов компании "Борлас", примерно равна стоимости лицензий вместе со стоимостью консалтинга. Но в реальных проектах предприятие редко бывает "голым" - какая-то техника там стоит и сеть существует. Тогда, как правило, для приложений Oracle нужен только новый сервер. Или требуется модернизация сети в какой-то части. По опыту компании "Борлас", затраты на "железо" в таких случаях обычно не превышают трети стоимости проекта. Соотношение стоимости лицензий к стоимости сопутствующих услуг (консалтинг, обучение, внедрение, сопровождение) бывает разным: то стоимость лицензий превышает стоимость консалтинга, то получается в разы меньше. (Не секрет, что лицензируется у нас в стране не всегда все по правилам, иногда и по договоренности.) Работы по интеграции ERP-приложений с имеющимися на предприятии системами, по очистке и загрузке данных, по выверке нормативно-справочной информации и ее переносу в систему, по написанию дополнительных отчетов, по кастомизации системы - весьма трудоемки и нередко составляют 25-30% стоимости услуг. |
Многие консалтинговые компании, как и мы, решение перечисленных задач, как правило, изначально в контракте оговаривают, но ответственным за их решение является заказчик, поскольку он лучше консультантов понимает, что творится у него в хозяйстве, какие системы работают, где какие данные находятся, насколько они "чистые", т. е. он должен лучше представлять объем работ по этим направлениям. Роль консультанта в этой ситуации - помочь, обеспечить согласование с требованиями новой системы. И основой нормального решения этих задач является честность и ответственность обеих сторон. Если закрывать глаза на сложность предстоящего процесса, ставя себе целью не испугать заказчика, чтобы быстрее его втянуть в проект, - это может привести к серьезным проблемам.
Чтобы, к примеру, запустить систему с 1 января, вышеперечисленные работы надо начинать не 1 декабря и даже не 1 ноября, а как минимум за полгода. Иначе получится, что к моменту, когда нужно будет сдавать систему, выяснится, что нет отчетов, по которым можно сделать какие-то сверки. Систему запустили, все вроде работает, только понять невозможно, правильно это работает или нет.
Конечно, и заказчик, и мы заинтересованы, чтобы проект был сдан в срок, и вся обещанная функциональность системы была реализована, чтобы инициаторы проекта не потеряли авторитет перед высшим менеджментом или перед акционерами, одобрявшими начало проекта. Но ведь существуют и ресурсные ограничения. Иногда складывается патовая ситуация, но поскольку перенос запуска никому не интересен - ни нам, ни им, то приходится что-то предпринимать в экстренном порядке.
Сейчас, имея серьезный опыт ведения ERP-проектов, мы понимаем, что в этом вопросе нельзя лукавить. И репутацию потеряешь, и в сроки не уложишься. Ведь недооценивать работы - значит строить нереальные планы, и от этого мы же в конечном счете и пострадаем: наши люди будут дольше работать на проекте, и мы будем выполнять непредусмотренные работы бесплатно, поскольку заинтересованы нормально завершить проект, запустив систему. А ERP-проекты, как правило, выполняются как fixed price (с фиксированной ценой). Значит, чем больше времени работаем, тем больше наши потери.
Так что это палка о двух концах - если сначала слукавишь, то потом это может очень больно ударить.
Правильный подход очевиден - перечисленные работы с самого начала оговаривать и выделять в отдельное направление. И честно говорить клиенту, во что это может вылиться, какова их трудоемкость, какие нужны ресурсы , если он берется за их решение. А если у него нет необходимых специалистов, то нужно будет потратить дополнительные деньги, чтобы привлечь нас или другую компанию, которая выполнит эту работу.