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

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

Вопрос первый: как учитывать время, затраченное исполнителем на консультации заказчику? Ведь консультации, например, могли быть даны по телефону или иными «заочными» способами.

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

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

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

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

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

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

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

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

За достижение целей в равной мере отвечают обе стороны – и заказчик и исполнитель. Заказчик отвечает в первую очередь за адекватность (соответствие) принятых методик целям создания системы, а исполнитель – за соответствие технической реализации системы утвержденным методикам.

Цели внедрения системы должны быть измеримы, критериальны. Например, для цели «повышение скорости обработки заказа» могут быть следующие варианты измеримости:

• количественная: «в 3 раза (сократить время обработки заказа до 5 мин)»;
• качественная (логическая): «Время обработки заказа сократилось».

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

Вопрос третий: что входит в программу испытаний? На чей счет отнести издержки на доработку типовых функций, если эффект их действия не был прописан на этапе функционального моделирования?

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

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

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

* * *

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

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

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

Только в случае объединения усилий и ответственности можно рассчитывать на успех проекта.