Своя система управления закупками: предпроектное обследование и техническое задание

Эксперт компании «Фогсофт» Сергей Юров

По данным различных исследований только четверть IT проектов завершается в срок и в рамках первоначального бюджета. Остальные либо существенно превышают бюджет или сроки либо не завершаются никогда. В большинстве случаев одной из причин провала проекта является некачественное техническое задание или отсутствие такового. Как правильно разработать ТЗ для корпоративной системы закупок и какие существуют подводные камни мы расскажем в сегодняшнем обзоре.

Как подготовить хорошее техническое задание на разработку, если  нет четкого видения необходимого функционала для системы управления закупками?

Подготовка  технического задания для корпоративной системы закупок или даже просто списка технических требований —  задача не простая. Для ее решения нужно и понимать бизнес-процессы автоматизируемого предприятия, проблемы и задачи, стоящие перед руководством,  и находиться в курсе последних тенденций рынка информационных технологий. Это большая удача, если предприятие без привлечения внешних специалистов, может определиться с оптимальной начинкой корпоративной системы.

В большинстве случаев основным консультантом и помощником в описании проблем и путей их решения становится разработчик, который  должен подробно разъяснить клиенту, каким образом, используя наиболее эффективные современные инструменты,  прийти из точки А (когда у заказчика есть проблема), в точку Б (когда у него есть стабильно работающий инструмент, решающий его проблемы). А также дать рекомендации: что делать стоит, чего делать не стоит, и сколько это будет в итоге стоить.

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

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

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

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

Идеи и пожелания по улучшению проекта обычно возникают сразу, когда вы начнете использовать программный продукт в тестовых или промышленных целях. Системы управления закупками слишком сложны, чтобы учесть все тонкости бизнес-процессов в их взаимосвязи с автоматизацией. Пожелания клиента позволяют улучшить систему уже на стадии разработки, снизить затраты на ее внедрение. Не все идеи могут быть учтены немедленно. Если предложений поступает слишком много или у заказчика появляется новое видение, требующее кардинальных изменений, возникает риск превышения бюджета и срыва сроков проекта. В таких случаях мы рекомендуем завершить текущий проект, а затем внести необходимые изменения в рамках отдельного договора.

Мы самостоятельно разработали технические требования для нашей будущей корпоративной ЭТП и сейчас ищем разработчика, который возьмется за реализацию нашего проекта. Каковы, на ваш взгляд, должны быть дополнительные критерии отбора разработчика, если цена имеет немаловажное значение? 

Критерии просты: наличие у разработчика опыта реализации подобных проектов или коробочного решения, максимально соответствующего вашим задачам. На практике это происходит примерно так: разработчик берет список ваших технических требований и сравнивает с функционалом имеющихся коробочных решений.  Соответственно, чем больше сходств с коробкой, тем проект будет дешевле для вас.

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