6. Бизнес-процессы могут измениться к моменту начала внедрения.
Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.
В результате получается документ, качество которого не соответствует потребностям проекта. Несмотря на это у Исполнителя не возникает проблем с закрытием этапа по указанным выше причинам.
2.2. Техническое задание на проект
Техническое задание — это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? Дело в том, что аппетит зачастую приходит во время еды, требования Заказчика в процессе внедрения обычно начинают расти, и одна из задач консультантов Исполнителя — держать Заказчика в рамках.
Принимается этот документ почти так же, как принимается описание бизнес-процессов. Не исключено, что Заказчик заставит Исполнителя включить в задание еще пару пунктов, которые неявно упоминались в договоре. Специалисты Заказчика довольны — им удалось настоять на своем. Исполнитель доволен — этап закрыт.
Не будем забывать, что ТЗ готовится на основании предыдущего документа, качество которого, как мы выяснили, зачастую неудовлетворительное. Неудивительно, что все недостатки описания бизнес-процессов находят свое отражение и здесь.
2.3. Настройка системы, описание доработок
Настройка системы требует грамотного консультанта. Это уже технология, и ясно, за что платятся деньги — у Заказчика нет специалиста, который сможет это сделать. Описание доработок — документ еще более сложный. Консультант, хорошо знающий систему, определяет, что из описанного в техническом задании системе по силам, а что потребует написания дополнительных программ.
Оба документа готовятся на основании предыдущих документов, качество которых не соответствует потребностям проекта. Именно поэтому на этапе внедрения часто требуется срочно перенастраивать систему и делать другие доработки, а программы, написанные заранее, остаются невостребованными.
Но у Заказчика нет специалистов, способных оценить качество этих документов, следовательно, никаких проблем с приемкой этапа не возникает.
2.4. Доработка системы
Этап доработки системы для Исполнителя может себя окупить. Важно, чтобы все написанные программы соответствовали описанию и прошли тесты. В результате получается система, выдержавшая тесты, придуманные Исполнителем.
2.5. Обучение (свет в конце тоннеля)
Этап может принести большую пользу Заказчику в смысле контроля за подготовкой проекта. Для этого обучение пользователей должно проводиться на настроенной системе, в которой выполнены доработки.
Пользователи начинают бунтовать. У пользователя много причин для бунта. Его устраивала та система, в которой он работал раньше. Новая система кажется ему сложной, и у него есть шанс обратить внимание разработчиков на недостатки (как ему кажется) интерфейсов и необходимость оптимизации каких-либо функций.
Требования пользователя не всегда разумны (а значит, не всегда их надо выполнять). Однако в процессе обучения часто всплывают на поверхность действительные недостатки проекта, которые ранее не были очевидны.
Этот момент Заказчик может использовать для того, чтобы заставить Исполнителя внести изменения в уже подписанные документы. Но чтобы использовать этот этап в своих интересах, у Заказчика должна быть грамотная проектная команда, мотивированная на результаты проекта.
2.6. Зачем такой длительный предпроект?
"Позвольте, мамаша! На станции,
Согласно багажной квитанции,
От вас был получен багаж:
Диван, чемодан, саквояж,
Корзина, картина, картонка
И маленькая собачонка.
Однако во время пути
Собака могла подрасти!"
Устав проекта, ТЗ, описание БП, настройки системы, доработка системы. Зачем так много документации? Для стабильности. Исполнитель должен гарантировать сроки и качество при любых условиях. Например, если уволится ведущий специалист, на его место придет другой, прочтет документацию, быстро разберется и продолжит проект.
Увы, длительные предпроектные работы служат и другой цели Исполнителя — получить большую часть денежных средств из бюджета проекта до начала самого сложного заключительного этапа — внедрения системы.
Когда будет выполнено все, кроме последнего этапа, нет гарантий, что полученная система сможет быть внедрена. Для Исполнителя важно, что почти все деньги получены. Если последний этап выполнить не удается, то для Исполнителя в этом нет ничего страшного. Риски незначительны. Он рискует:
< Неполученным остатком денег из бюджета проекта.
< Своей репутацией.
< Невыполнением обязательств по договору.
Для получения небольшой части оставшихся денег Исполнителю надо затратить солидные ресурсы и подключить квалифицированных специалистов, то есть внедрение для Исполнителя нерентабельно. Риск потери репутации отсутствует — мы ввели такое допущение (почему, объясняется в разделе «Итоги не для всех»). Невыполнение обязательств по договору — тоже риск несущественный. Договор готовил Исполнитель и заранее продумал наличие в договоре лазеек для сложившейся ситуации.
Получается, что на всех этапах Исполнитель имеет только одну задачу — задобрить комиссию Заказчика и убедить ее в том, что все идет как надо. Все выпускаемые им документы служат именно этой цели. Все предпроектные документы подписаны Заказчиком. С юридической точки зрения Заказчик получил то, что заказывал.
2.7. Внедрение
Последний этап обычно очень сложен. Прежде всего из-за низкого качества выполнения задач предпроекта. Но есть и другая причина.
До момента старта система существует на предприятии в виде идей и лозунгов в умах персонала. Менеджеры нижнего звена порой не подозревают, что многое изменится, тогда как внедрение зачастую в корне меняет процессы управления. Это производит колоссальный эффект. Именно тогда представления о том, как и что должна уметь система, радикально меняются и доходят до руководства Заказчика. И тут возникает потребность надавить на Исполнителя и заставить его сделать то, что нужно. Но надавить уже нечем.
Почти все деньги, выделенные на проект, потрачены. В суд подать нельзя, все документы свидетельствуют о том, что Заказчик получил то, что заказывал. Раздувая скандал в надежде пошатнуть репутацию Исполнителя, Заказчик рискует своей. Поэтому, несмотря на высокий процент проваленных проектов, Заказчик очень редко подает в суд на Исполнителя.
Дальше сценарии бывают разные. Если Заказчик располагает ресурсами или инструментами давления на Исполнителя, то конфликт улаживается. Проект удается внедрить — пусть с большим опозданием и зачастую с увеличением бюджета.
Часто Заказчик, не видя никакого результата, не готов к дополнительным затратам. И получается проект без заключительного пресс-релиза о результатах внедрения. Таких большинство.
2.8. Итоги не для всех
С точки зрения Исполнителя технология хороша. При достаточной раскрутке компании она позволяет получать деньги, почти не отвечая за результат. Чтобы сделать себе имя, достаточно одного удачного проекта, который берется за основу рекламной кампании.
Технологию можно и усовершенствовать. Стоимость этапов определяется как время работы, умноженное на ставку специалиста. Если поднять внешнюю ставку консультанта и уменьшить ставку программиста, то можно будет оценить начальные этапы еще дороже, а заключительные, наоборот, дешевле. И тогда до начала внедрения можно будет получить порядка 90% всей суммы. Эта идея была реализована довольно давно, хотя большинство специалистов до сих пор не отдает себе отчет в том, почему ставки программистов и консультантов отличаются на 20—60% (раз таковы ставки, значит, зарплаты программистов тоже должны быть меньше — такой вывод для себя делают менеджеры).