Автор: Подхватилина Мария Владимировна, Руководитель отдела маркетинга и продаж, ООО «Институт типовых решений – производство» (ИТРП)
Данная статья будет полезна в первую очередь тем руководителям предприятий и их ИТ-служб, которые уже собрались начать внедрение комплексной автоматизированной системы на своем предприятии, но продолжают мучиться страхами, сомнениями, а также ощущениями того, что их постоянно пытаются обмануть.
Ситуация «тихой паники» стандартна и встречается практически в каждом первом готовящемся к старту проекте по автоматизации. Казалось бы, проект договора лежит на столе у руководителя предприятия, и вроде все понятно, однако продолжает преследовать подспудное ожидание подвоха, чувство недосказанности и неотвеченных вопросов.
Если такие ощущения понятны, а ситуация знакома, то эта статья для вас! В этой статье мы рассмотрим ряд вопросов, которые обычно встают перед заказчиком проекта автоматизации в процессе согласования договора.
1. Как учитывается время, затраченное исполнителем на консультации заказчика? В том числе, если они велись по телефону или иными способами.
Во-первых, стоит сразу выделить различные этапы проекта, т.к. на каждом этапе возможны разные варианты консультирования и подходы к учету стоимости таких услуг.
На этапе пусконаладочных работ и опытной эксплуатации специалисты компании-внедренца консультируют представителей заказчика и выполняют дополнительные доработки, исправляют ошибки. Все оплачиваемые работы, в том числе и консультации с использованием любых средств связи (за исключением исправления ошибок), учитываются в листах учета рабочего времени (по-простому ЛУРВах).
На этапе промышленной эксплуатации, когда работы по проекту закончены, заказчик заключает договор на абонентское обслуживание – техническую поддержку системы. Первые полгода после покупки программного продукта, как правило, это обслуживание бывает бесплатным, а далее оплачивается по цене, установленной разработчиком. Возможны также расширенные варианты сопровождения, включающие в себя фиксированное количество выездов исполнителя на предприятие в месяц в обязательном порядке или пакет каких-нибудь стандартизованных услуг. В целом ситуации бывают весьма разнообразные.
В рамках работ по технической поддержке решаются вопросы, возникающие у заказчика в процессе эксплуатации систем. Например, это могут быть ответы на вопросы по потенциальным ошибкам в программе (т.е. программа выдала неожиданные результаты, и заказчик не понимает, откуда они взялись) или, при возможности, анализ программных ошибок в предоставленной базе данных.
Если же заказчик просит совета по решению в системе неких специфических задач, то при выходе объема консультаций за разумные рамки (в стиле «вопрос – ответ») обычно заключается договор на консультационные услуги с оплатой на почасовой основе.
2. Где же предметная ответственность исполнителя за результат? Все-таки главная цель внедрения не «накатить» систему на бизнес, а получить ощутимый бизнес-результат. Может сложиться такая ситуация, при которой исполнитель навязал или предложил заказчику некоторое решение, но по завершении внедрения окажется, что цель предприятия не достигнута — остатки не верны, среднесуточные задания (ССЗ) не точны и т.д. К таким результатам приводит и некачественная реализация, и недостаточная продуманность на этапе функционального моделирования (ФМ). И что теперь делать? Кто виноват?
Бизнес-цели проекта и модель бизнес-процессов «Как будет» определяются на этапе ФМ и утверждаются заказчиком в спецификации требований. Формат определения этих бизнес-целей устанавливается заказчиком, однако и опытный подрядчик может предложить варианты форматов.
После определения целей исполнитель на этапе ФМ подбирает инструменты их достижения, методы доработки системы и применяемые модели. После чего данная методология передается на согласование заказчику.
Заказчик оценивает адекватность данных предложений на соответствие своим целям. Это делает именно заказчик, а не исполнитель. Поэтому нельзя говорить, что исполнитель навязывает решение, поскольку в нормальной схеме работы последнее слово всегда остается за заказчиком. Важно понимать, что согласование модели на стадии функционального моделирования – это важный и достаточно трудоемкий процесс.
В качестве вывода можно отметить, что за достижение целей отвечают в равной мере обе стороны – заказчик и исполнитель. При этом существует некоторое разделение ответственности:
• заказчик отвечает в первую очередь за адекватность (соответствие) принятых методик целям создания системы;
• исполнитель, со своей стороны, – за адекватность технической реализации системы утвержденным методикам.
Для того чтобы можно было определить, достигнуты цели внедрения системы или нет, эти цели должны быть измеримыми, критериальными.
Например, для цели: «Повышение скорости обработки заказа» вариантами измеримости будут:
• Количественная: «в 3 раза (сократить время обработки заказа до 5 мин)».
• Качественная (логическая): «Время обработки заказа сократилась».
Принцип обоюдной ответственности можно применить и к точности данных, выдаваемых системой, например, информации по остаткам и планам. Если остатки не точны – это значит, что пользователи неправильно ввели входящие остатки или их движения. Если ССЗ не точны в рамках принятых методических допущений, значит, не точны техпроцессы в части нормативно-справочной информации. Либо это ошибки в программе, которые устраняются по гарантии исполнителем.
На этапе опытной эксплуатации выявляются ошибки, допущенные сторонами:
• Со стороны заказчика выявляются новые требования к методикам, дополнительные пожелания пользователей. Все это доработки выполняются за счет заказчика
• Со стороны исполнителя выявляются программные ошибки и отклонения технической реализации от методик. Если это отклонение является нарушением технического задания (ТЗ) или явной программной ошибкой, то исправление таких отклонений осуществляется за счет исполнителя.
3. Что входит в программу испытаний? И если в ходе испытаний выяснится, что какая-то типовая функциональность дает не совсем ожидаемый эффект, действие которого не проговаривалось или не было раскрыто в ходе ФМ, кто понесет издержки по доработке?
В программу испытаний входит полная «прогонка» бизнес-процесса согласно модели принятой в ТЗ. При этом цель ФМ – выявить необходимость доработок. В процессе ФМ исполнитель в первую очередь формирует модель бизнес-процессов, а также демонстрирует типовой функционал и детально консультирует заказчика по возможностям реализации бизнес-процессов в этом функционале, дает рекомендации по доработкам. Заказчик анализирует результаты и принимает или не принимает предложенные доработки. На данном этапе фиксируется несоответствие типового функционала требованиям заказчика. За полноту анализа несоответствия несут ответственность обе стороны, и разделить формально эту ответственность (в т.ч. определить доли ответственности) невозможно.
4. По сути дела, на стадии функционального моделирования будет введен контрольный пример. Но что если он окажется неполным? Кто будет решать, кто неправ?
Программа и критерии приемки системы предварительно утверждаются заказчиком. Соответственно, именно у заказчика есть возможность не принять предложенную программу, если она не соответствует его критериям.
В качестве заключения стоит отметить, что проект автоматизации и внедрения комплексной системы управления предприятием всегда является общим детищем заказчика и исполнителя, за успешность которого несут ответственность обе стороны.
Представители заказчика, принимающие решение о старте проекта должны тщательно подойти сначала к выбору компании-внедренца, а затем к выполнению своей части работ по проекту – определению бизнес-требований к системе, утверждению перечня доработок типового решения, согласованию методик функционального моделирования и программы испытаний. Со своей стороны опытный исполнитель приложит максимум усилий к тому, чтобы вникнуть в специфику предприятия-заказчика, отразить в системе все требования, оказать максимальную консультативную поддержку специалистам предприятия в ходе тестирования и настройки системы.
И только в случае объединения усилий и ответственности, проект ждет успех.
Читать дальше →
