Одна голова хорошо, а две — лучше
Опубликовано в журнале "CIO" №12 от 20 декабря 2005 года


Кто должен писать ТЗ — клиент или исполнитель? Или этот документ должен быть плодом совместных усилий? Какие проблемы могут возникнуть у проектной команды, реализующей проект по ТЗ, созданному одной стороной? Напротив — какие плюсы у такого подхода? Всегда ли ТЗ, созданное клиентом и исполнителем вместе, — гарантия правильно выбранной стратегии и тактики?

Дмитрий Алтухов,
генеральный директор ОАО «Северсталь-инфоком»

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

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

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

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

Например, отчеты, генерируемые системой. Руководители бизнес-подразделений уже на самом начальном этапе нередко знают, какая информация и в каком виде нужна им в работе. Это могут быть, в частности, удобные и привычные формы в том же Excel. Однако при анализе системы, планируемой к внедрению, может оказаться, что стандартных отчетов недостаточно, а создание и модификация требуемых отчетов является сложной и дорогой задачей, требующей привлечения специалистов исполнителя после завершения внедрения.

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

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