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

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

"Позвольте, мамаша! На станции,

Согласно багажной квитанции,

От вас был получен багаж:

Диван, чемодан, саквояж,

Корзина, картина, картонка

И маленькая собачонка.

Однако во время пути

Собака могла подрасти!"

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

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

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

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

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

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

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

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

2.7. Внедрение

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

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

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

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

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

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

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

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

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

«Может ли разумный человек, учитывая опыт прошедших веков, питать хоть малейшую надежду на светлое будущее человечества?»

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

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

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

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

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

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

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

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