3. Ответственность за результат работы отодвинута во времени на длительный срок. Если описание БП будет неправильным, это станет заметно только через несколько месяцев.
4. У специалистов заказчика есть другие сложные задачи, вне данного проекта, ответственность по которым сиюминутная и дорогая.
5. Компетентные специалисты Заказчика не любят сбои в работе процесса, так как несут за них реальную ответственность. Если в описании БП такой сбой не будет описан, это произведет благоприятное впечатление на подсознательном уровне.
6. Бизнес-процессы могут измениться к моменту начала внедрения.
Если при правильной организации приемки работ с причинами 1, 2, 4, 5, 6 можно и нужно бороться, то причина 3 является неотъемлемой частью этапа описания БП.
В результате получается документ, качество которого не соответствует потребностям проекта. Несмотря на это у Исполнителя не возникает проблем с закрытием этапа по указанным выше причинам.
2.2. Техническое задание на проект
Техническое задание — это задание Заказчика Исполнителю. Не странно ли, что и его готовит Исполнитель? Дело в том, что аппетит зачастую приходит во время еды, требования Заказчика в процессе внедрения обычно начинают расти, и одна из задач консультантов Исполнителя — держать Заказчика в рамках.
Принимается этот документ почти так же, как принимается описание бизнес-процессов. Не исключено, что Заказчик заставит Исполнителя включить в задание еще пару пунктов, которые неявно упоминались в договоре. Специалисты Заказчика довольны — им удалось настоять на своем. Исполнитель доволен — этап закрыт.
Не будем забывать, что ТЗ готовится на основании предыдущего документа, качество которого, как мы выяснили, зачастую неудовлетворительное. Неудивительно, что все недостатки описания бизнес-процессов находят свое отражение и здесь.
2.3. Настройка системы, описание доработок
Настройка системы требует грамотного консультанта. Это уже технология, и ясно, за что платятся деньги — у Заказчика нет специалиста, который сможет это сделать. Описание доработок — документ еще более сложный. Консультант, хорошо знающий систему, определяет, что из описанного в техническом задании системе по силам, а что потребует написания дополнительных программ.
Оба документа готовятся на основании предыдущих документов, качество которых не соответствует потребностям проекта. Именно поэтому на этапе внедрения часто требуется срочно перенастраивать систему и делать другие доработки, а программы, написанные заранее, остаются невостребованными.
