О чем волнуется заказчик перед стартом проекта автоматизации?

Автор: Подхватилина Мария Владимировна, Руководитель отдела маркетинга и продаж, ООО «Институт типовых решений – производство» (ИТРП)

Ситуация «тихой паники» стандартна и встречается практически в каждом первом готовящемся к старту проекте по автоматизации. Казалось бы, проект договора лежит на столе у руководителя предприятия, и вроде все понятно, однако продолжает преследовать подспудное ожидание подвоха, чувство недосказанности и неотвеченных вопросов.

В этой статье мы рассмотрим ряд вопросов, которые обычно встают перед заказчиком проекта автоматизации в процессе согласования договора.

1. Как учитывается время затраченное исполнителем на консультации заказчика? В том числе, если они велись по телефону или иными способами…

Во-первых, стоит сразу выделить различные этапы проекта, т.к. на каждом этапе возможны разные варианты консультирования и подходы к учету стоимости таких услуг.

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

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

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

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

2. Где же предметная ответственность исполнителя за результат? Может сложиться такая ситуация, при которой исполнитель навязал или предложил заказчику некоторое решение, но по завершении внедрения окажется, что цель предприятия не достигнута - остатки не верны, средне-суточные задания (ССЗ) не точны и т.д. К таким результатам приводит и некачественная реализация, и недостаточная продуманность на этапе функционального моделирования (ФМ).

Бизнес-цели проекта и модель бизнес-процессов «Как будет» определяются на этапе ФМ и утверждаются заказчиком в спецификации требований. После определения целей исполнитель на этапе ФМ подбирает инструменты их достижения, методы доработки системы и применяемые модели. После чего данная методология передается на согласование заказчику. И именно Заказчик оценивает адекватность данных предложений на соответствие своим целям!

На этапе опытной эксплуатации выявляются ошибки, допущенные сторонами:

• Со стороны заказчика выявляются новые требования к методикам, дополнительные пожелания пользователей. Все это доработки выполняются за счет заказчика

• Со стороны исполнителя выявляются программные ошибки и отклонения технической реализации от методик.

3. Что входит в программу испытаний? И если в ходе испытаний выяснится, что какая-то типовая функциональность дает не совсем ожидаемый эффект, действие которого не проговаривалось или не было раскрыто в ходе ФМ, кто понесет издержки по доработке?

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

4. По сути дела на стадии функционального моделирования будет введен контрольный пример. Но что если он окажется неполным? Кто будет решать, кто неправ?

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

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