Результат гарантирован. Как застраховать проект автоматизации от ошибок
|
|
Источник: Financional Director
Автор: Мария Венедиктова
|
| |
Проблема
Есть неутешительная статистика - более 60 процентов всех проектов автоматизации заканчиваются неудачей. Довольно невысокий процент успеха, особенно, если учесть, что речь идет о серьезных инвестициях насчитывающих, зачастую, десятки миллионов рублей. Как можно подстраховаться, чтобы быть уверенным в успехе внедрения информационной системы?
Решение
Как и с любыми инвестициями – полностью исключить риск провала проекта автоматизации невозможно. Но, можно многократно повысить свои шансы на успех, для этого достаточно правильно составить договор на внедрение информационной системы. На практике, большинство проблем возникает из-за небрежного отношения к этапу переговоров и оформления обязательств сторон.
Не секрет, что идеальных проектов автоматизации не бывает. Не смотря на то, что разнообразие претензий компаний к консультантам и наоборот поражает воображение, причин лежащих в основе неудач всего две:
- ошибки, допущенные при составлении договора;
- ошибки, связанные непосредственно с выполнением работ и управлением проектом.
Причем, наиболее тупиковые проблемы лежат в плоскости именно договорных отношений. Казалось бы, в выполнении работ и управлении проектом должно быть больше трудностей – требуются высококвалифицированные и зачастую узкоспециализированные специалисты, управление проектом сложная дисциплина и требует специальных знаний и навыков от рабочих групп не только исполнителя, но и заказчика. И что может быть сложного в составлении грамотного договора на автоматизацию? У компаний-внедренцев, как правило, есть выверенные типовые договора, положения которых отражают специфику предмета – поставки, адаптации, внедрения информационных технологий, у компаний-заказчиков – грамотные юристы, способные защитить интересы компании.
Тем не менее, проекты заходят в тупик не потому, что превышаются сроки и бюджет проекта, ощущается нехватка ресурсов, снижается качество выполнения работ. Все эти неприятности из области управления проектом и как справляться с ними менеджеры хорошо знают. В настоящий тупик проект может завести плохо составленный договор, который с юридической точки зрения идеален – есть предмет и стоимость договора, условия взаиморасчетов, прочие необходимые положения. Тем не менее он лишен главного – договор не обеспечивает однозначной трактовки предмета и обязательств. Если компания и автоматизатор не договорятся «на берегу» и не зафиксируют в договорных отношениях предмет сотрудничества в понятной всем терминологии и в необходимых деталях, проблемы, которые могут привести стороны к неразрешимому конфликту, а проект к остановке, неизбежны.
От компаний компаний-заказчиков можно услышать следующие претензии, которые свидетельствуют об ошибках, допущенных в договоре:
- «нам это не нравится, мы совсем не это заказывали»;
- «почему отсутствует нужная нам функциональность? Мы думали, что она тоже входит в стоимость»;
- «нам нужно, чтобы система была полностью адаптирована под наши потребности»;
- «за эти деньги мы рассчитывали получить систему «под ключ»».
У компаний-внедренцев с ответами на выдвигаемые претензии, как правило, проблем не возникает. Услышать чаще всего можно примерно следующее:
- ваши претензии не конкретны, «нравится – не нравится» не является критерием приемки работ. Найдите компетентных специалистов, чтобы они сформулировали конкретные замечания;
- по договоренности с вами мы внедряем стандартную функциональность, все доработки мы готовы произвести за отдельные деньги;
- мы не можем удовлетворять потребности каждого конкретного пользователя;
- у вас некорректные представления о внедрении «под ключ». Мы не можем работать за вас.
Мнение коллеги
Николай Рыбаков, директор по экономике и финансам ОАО «Сибирьтелеком»
«Одна из основных причин возникновения претензий между компаниями и автоматизаторами - несоответствие взаимных ожиданий. Это происходит из-за недостаточной проработки документов на стадии инициирования проекта: договора, технических требований, устава проекта. Зачастую желание быстрее начать проект приводит к тому, что в результате невнимательного отношения к договору остаются нерешенными вопросы четкой фиксации объёма работ. Так, например, в одном из проектов уже на этапе реализации выяснилось, что автоматизатор не готов создать подсистему отчётов (в рамках технологической системы) на которую рассчитывала компания. Неясные и абстрактные требования уместились в договоре всего на одной строке
Неясное определение зон ответственности также приводит к непониманию и непродуктивному сотрудничеству. К примеру, бывает, что в договоре условия прописываются таким образом: «Заказчик обязан предоставить любую необходимую информацию» или «Исполнитель осуществляет консультационную поддержку процесса». Приведенные примеры затрудняют взаимодействие компаний и автоматизаторов и существенно осложняют их совместную деятельность».
КАК ДОСТИЧЬ ИДЕАЛА
Для того, чтобы договор автоматизации действительно был адекватен проекту, все его условия требуют тщательной предварительной проработки. В общем случае необходимо:
- создать глоссарий терминов, который обеспечит однозначное толкование всех положений договора. Этот глоссарий после согласования сторонами необходимо включить в договор;
- определить полный перечень объектов автоматизации и исчерпывающе определить функциональные рамки проекта, т.е. перечень функций компании-заказчика, подлежащих автоматизации в ходе выполнения проекта (пример определения функциональных рамок проекта см. таблицу 1);
- разработать состав этапов проекта с учетом необходимых сроков выполнения и, как следствие, ожидаемых сроков получения значимых результатов; объемов работ по внедрению; состава, структуры и наличия необходимых для выполнения каждого этапа ресурсов;
- сформулировать все необходимые положения по условиям выполнения работ, по порядку и критериям сдачи и приемки результатов работ (пример приведен в таблице 2). Также необходимо составить бюджет проекта и график платежей.
- создать положения по организации работ на проекте и определить необходимые условия достижения целей проекта в пределах заданных временных и стоимостных рамок проекта.
Универсального договора, который бы избавил компанию от головной боли, конечно, не существует. В любом случае необходимо учитывать специфику проекта и не забывать включать в договор пункт об обязательном подписании устава проекта. Этот документ должен быть неотъемлемой частью договора и включать описание всех процедур взаимодействия компаний заказчика и автоматизатора, а также любых положений, обусловленных спецификой проекта, которые нецелесообразно включать в договор.
Совет консультанта
Дмитрий Школьников, заместитель директора по развитию компании «Что делать Консалт»
Говоря о проблемах, возникающих в ходе выполнения проектов по автоматизации нельзя не упомянуть о таком важном моменте, как завершение внедрения и переход к сопровождению. Здесь возможны две крайности. Первая – непомерное затягивание внедрения. Обычно такая ситуация возникает, когда календарный план и техническое задание составлены нечетко, отсутствуют жесткие контрольные сроки, знаковые события и критерии выполнения. Де-факто продукт давно перешел в режим сопровождения, но формально это называется внедрением. Вторая крайность – проведение внедрения под видом сопровождения. В этом случае, формально внедренческие работы завершаются, но специалист, назначенный для сопровождения, выполняет задачи по внедрению системы.
Порочность обоих подходов понятна без объемных комментариев. Она ведет к несоразмерным затратам заказчика, несбалансированности и «лоскутности» получающейся в результате информационной системы. Какое может быть средство от такого исхода проекта? Прежде всего, должен быть четко описан сам проект. Далее, необходимо столь же четко сформулировать критерии завершения проекта и перехода к сопровождению. Также необходимо определить сроки, периодичность, объем и, главное, содержание работ по сопровождению. Возможно, окажется, что значительную долю работ сможет выполнять служба информационных технологий самого заказчика.
РАБОТА НАД ОШИБКАМИ
К сожалению, слишком часто о необходимости указать то или иное условие вспоминают слишком поздно, когда конфликт между внедренцами и заказчиком в полном разгаре. Самым радикальным решением подобной проблемы будет – полный разрыв взаимоотношений, расторжение договора. Но, это означает колоссальные убытки, необходимость искать другого подрядчика и начинать все заново. На подобное компании отваживаются редко.
Есть и другой выход. Компании заказчику необходимо либо собственными силами, либо с привлечением консультантов провести экспертизу ситуации, сложившейся на проекте. Для этого придется напрячься и собрать значительный объем информации из следующих основных источников: договор на создание информационной системы, дополнительные соглашения; документация, определяющая рамки проекта (техническое задание, календарный план, функциональные задания; отчетная документация по проекту и т.д.) Собранные сведения необходимо будет проанализировать на предмет соответствия:
- положений договоров требованиям, сформированных на предпроектной стадии. Желательно найти письменные свидетельства своих требований. Это могут быть протоколы рабочих встреч, переписка, в том числе по электронной почте и т.д.;
- договорных условий документам, характеризующим исполнение проекта на всех его стадиях;
- результатов работ требованиям технического задания;
- состава работ и сроков их выполнения положениям календарного плана;
- стоимости оплаченных работ затраченным ресурсам Исполнителя;
- качества результатов работ и отчетной документации договорным условиям, а также российской и мировой практике реализации аналогичных проектов;
- требований заказчика к системе объективным потребностям бизнеса.
ПРИМЕР
При проведении экспертизы результативности проекта автоматизации для одного из российских холдингов были получены следующие частные результаты (ниже приведен фрагмент результатов анализа договорной документации).
Состав работ по договорам определен слишком глобально – по этапам и не детализирован по работам. Например, этап «Разработка и детализация бюджетной структуры», оцененный в ____ рублей, не детализирован по работам, из которых состоит выполнение данного этапа.
В ряде договоров (например, № №___) ожидаемые результаты работ не увязаны с составом работ, что приводит к невозможности контроля эффективности и результативности выполненных работ.
В договорах не указаны объекты выполняемых работ. Например, к договору № ___ открыто два Дополнительных соглашения (№№ 2 и 3) с абсолютно идентичными ожидаемыми результатами и составом работ по разработке сайта. В договоре не указано, разработка сайта какой тематики является предметом настоящего договора, также этой информации нет в текстах дополнительных соглашений. По тексту договора невозможно определить, чем вызвано подписание двух идентичных дополнительных соглашений с разной стоимостью – необходимостью дополнительного финансирования работ по разработке одного сайта, либо началом работ по разработке сайта другой тематики.
В договорах 200_ года явно не указывается, что основным ожидаемым результатом работ должна явиться автоматизированная информационная система. Например, при анализе договора № __ выявлено, что в соответствии с Приложением 1 к договору результатами выполнения этапов работ должны явиться «Опытная эксплуатация автоматизированной системы», «Приобретенный и настроенный программный продукт», «Проведенные мероприятия по обучению персонала, разрешению конфликтов и доработке системы, разработке предложений по развитию системы». Более нигде по тексту договора не указано, что предметом договора является законченное автоматизированное решение. Такая ситуация изначально ставит под угрозу возможность удовлетворения интересов Заказчика.
Исполнитель не берет на себя ответственность за достижение конечного результата.
Основным результатом проведения экспертизы проекта будет являться полученная детализированная интегральная оценка состояния проекта, которая покажет уровень соответствия достигнутых результатов целям проекта, а также соотношение между его бюджетом и объемом выполненных работ. На ее основании можно будет принять обоснованное решение о мерах по выводу проекта из кризиса. В большинстве случаев наиболее правильным для обеих сторон решением будет перезаключение договора на новых условиях.
Таблица 1. Описание задач проекта и их функциональных рамок
Условия и ограничения реализации задач проекта |
Задачи проекта |
Функциональные рамки проекта. Виды работ |
Проектная документация |
Функциональные рамки разработки системы бюджетирования определены с учетом следующих ограничений:
- по видам деятельности
- по типам бюджетов
- по горизонтам бюджетирования
- по видам классификаторов
Система бюджетирования разрабатывается для следующих видов деятельности:
- Выполнение ___ работ и услуг
Система бюджетирования разрабатывается для следующих подразделений: _____
Горизонты бюджетного управления: год-квартал-месяц
Система бюджетирования ограничена следующими типами бюджетов:
- Бюджеты ___:
- Бюджет Доходов от реализации ___ услуг и работ
- Производственный Бюджет выполнения ___ услуг и работ
- Бюджет прямых затрат на выполнение _____ услуг и работ
- План запасов материалов и МБП производственного назначения
- План вакансий и ФЗП производственного персонала
- План закупок материалов и МБП производственного назначения
- План закупок оборудования, приборов и спецтехники производственного назначения
- План договоров на выполнение ___ услуг и работ
- Консолидированный Бюджет операционных доходов и расходов
- Бюджеты экспедиций
- Бюджет Доходов от реализации ___ услуг и работ
- Производственный Бюджет выполнения ____услуг и работ
- Бюджет прямых затрат на выполнение ____ и работ
- Бюджет операционных доходов и расходов
|
Разработка методик системы бюджетирования |
Разработка состава и структуры бюджетов |
- Документ «Состав и структура бюджетов и их взаимосвязь»
|
Разработка следующих методик бюджетного планирования:
- Методика расчета и консолидации показателей операционных бюджетов
- Методика сбора фактических данных об исполнении бюджетов
- Методика анализа отклонений, горизонтального, факторного анализа бюджетов
|
- Документ «Методика расчета и консолидации показателей операционных бюджетов»
- Документ «Методика сбора фактических данных об исполнении бюджетов»
Документ «Методика анализа отклонений, горизонтального, факторного анализа бюджетов» |
Разработка альбома бюджетных форм |
|
Разработка состава следующих классификаторов НСИ:
- Номенклатура ____ работ и услуг
- Виды деятельности
- Типы договоров на реализацию ___ работ и услуг
- Типы заявок на производство ___ работы и услуги
- Комплексы задач
- Виды ____ работ
- Типы ресурсов производственного назначения
- Технологические карты выполнения заявок на ____ работы и услуги
- Места хранения материалов и МБП производственного назначения
- Статьи и элементы затрат при производстве ____ работ и услуг
- Статьи прибылей и убытков
- Объекты типа 1
- Объекты типа 2
- Профессии и должности производственного персонала
|
- Документ «Состав классификаторов системы бюджетирования»
|
Разработка регламента реализации бюджетного документооборота |
Уровень ___:
- Разработка Бюджетного документооборота составления, контроля и корректировки бюджетов ___
Уровень ____:
- Разработка Бюджетного документооборота составления, контроля и корректировки бюджетов ___
|
- Документ «Описание бюджетного документооборота»
- Документ «Состав функциональных ролей, функциональные обязанности и полномочия участников бюджетного управления»
|
Разработка предложений по организационно-функциональной структуре подразделений участвующих в реализации бюджетного управления |
- Документ «Временное положение об организационно-функциональной структуре ____»
- Документ «Должностные инструкции по реализации процедур бюджетного управления»
|
Таблица 2. Ожидаемые результаты проекта и критерии их достижения
Наименование этапа |
Критерии начала этапа |
Ожидаемые результаты работы Исполнителя |
Критерии выполнения этапа |
Этап 1.4. Проведение работ по подготовке ОФС к работе в информационной системе бюджетного управления |
Детальный План работ по Этапу 1.4. утвержден Заказчиком |
Разработано положение о структуре подразделений участвующих в реализации бюджетного управления |
Акт приемки передачи документа «Временное положение об организационно-функциональной структуре _____» |
|
Документ «Состав функциональных ролей, функциональные обязанности и полномочия участников бюджетного управления» утвержден Заказчиком |
|
Документ «Временное положение об организационно-функциональной структуре _____» утвержден Заказчиком |
|
Документ «Состав функциональных ролей, функциональные обязанности и полномочия участников бюджетного управления» утвержден Заказчиком |
Разработаны временные должностные инструкции по реализации задач бюджетного управления |
Акт приемки передачи документа «Должностные инструкции по реализации процедур бюджетного управления» |
|
|
|
Документ «Должностные инструкции по реализации задач бюджетного управления» утвержден Заказчиком |
|
Документ «Временное положение об организационно-функциональной структуре _____» утвержден Заказчиком |
Проведены мероприятия по изменению ОФС подразделений участвующих в реализации бюджетного управления |
Состав рабочих мест по подразделениям утвержден Заказчиком |
|
Документ «Должностные инструкции по реализации процедур бюджетного управления» утвержден Заказчиком |
|
Планы обучения со списком сотрудников подписаны руководителями структурных подразделений |
|
Документ «Состав функциональных ролей, функциональные обязанности и полномочия участников бюджетного управления» утвержден Заказчиком |
Разработаны технологические инструкции по функциональным автоматизированным рабочим мест |
Акт приемки передачи документа «Технологические инструкции по реализации функций бюджетного управления в информационной системе» |
|
Документ «Состав и структура бюджетов и их взаимосвязь» утвержден Заказчиком |
|
Документ «Технологические инструкции по реализации функций бюджетного управления в информационной системе» утвержден Заказчиком |
Этап 1.5. Развертывание информационной системы бюджетного управления на рабочих местах и подготовка к вводу системы в опытную эксплуатацию |
Детальный План работ по Этапу 1.5. утвержден Заказчиком |
Оборудование рабочих мест техническими средствами и программным обеспечением |
Акт об оборудовании рабочих мест необходимыми техническими средствами подписан Заказчиком и Исполнителей |
|
Состав рабочих мест по подразделениям утвержден Заказчиком |
|
Акт об установке программного обеспечения подписан Заказчиком и Исполнителем |
|
Акт выполнения работ по Этапу 1.2. «Разработка и реализация технического решения формирования структурной модели бюджетов на базе PlanDesigner» |
Начальная загрузка данных и проверка соответствия осуществлены |
Протокол соответствия загруженных данных подписан Заказчиком |
Ваши претензии не конкретны, «нравится – не нравится» не является критерием приемки работ
Одна из основных причин возникновения претензий между компаниями и автоматизаторами - несоответствие взаимных ожиданий
КАК ГРАМОТНО СФОРМУЛИРОВАТЬ ТРЕБОВАНИЯ К ПРОЕКТУ, ЕСЛИ ОПЫТА ПОДОБНОЙ РАБОТЫ У СПЕЦИАЛИСТОВ КОМПАНИИ НЕ БЫЛО?
В такой ситуации самостоятельная проработка требований, действительно, не самая лучшая идея. Выходом может стать – привлечение консультантов для проведения исследования компаний и выявления задач, предстоящей автоматизации. Разумеется, это потребует дополнительных затрат, но и повысит вероятность эффективного внедрения информационной системы. Стоимость подобных работ колеблется в переделах 10- 15 процентов от стоимости самого проекта. Известны примеры, когда компании на этап исследования приглашали несколько консалтинговых компаний. Которые работали параллельно.
