При внедрении автоматизированной системы на любом предприятие существуют факторы, которые оказывают влияние на успех внедрения. Опыт компании 1С-Рарус, выполняющей более 30 средних и крупных проектов одновременно, порядка 50 проектов в год, позволяет сделать выводы об основных причинах возникновения проблемных ситуаций во время проектов. Статья посвящена рассмотрению этих причин и возможных способах их предупреждения.
К факторам, которые гарантировано приводят к неудачным внедрениям, следует отнести с лабое руководство проектом со стороны заказчика и отсутствие у него методологии для автоматизируемых участков. Рассмотрим их подробнее.
Слабое руководство проектом со стороны заказчика
Вопрос назначения руководителя проекта внедрения на многих предприятиях решается непросто. С одной стороны есть ключевые менеджеры, которым проект на самом деле нужен, но с другой – они сильно перегружены текущей работой, и не в состоянии выполнять функции руководителя проекта.
Часто бывают случаи, что руководителем проекта назначают нового сотрудника, недавно принятого на работу. Такому руководителю проекта очень трудно добиться оперативного принятия решений на этапе проектирования системы, а также заставить пользователей работать с системой на этапе внедрения. Несмотря на то, что формально рычаги воздействия у него есть (может, например, подготовить приказ, согласовать его с вышестоящим руководством и довести до сотрудников) – на самом деле складывается ситуация, что любое, даже самое мелкое решение принимается несколько дней. Это, конечно же, влечет за собой срыв сроков проекта.
Похожая ситуация наблюдается и в случае, когда руководителем проекта назначают уже работающего сотрудника, но не очень заинтересованного в самом проекте. Например, представителя ИТ службы заказчика.
Задача компании, внедряемой решение, состоит в том, чтобы до начала проекта снять с заказчиком все вопросы, связанные с руководством проекта.
Бывают случаи, когда несмотря на наши предостережения, заказчик назначает руководителем проекта человека не наделенного особыми полномочиями по проекту. В этом случае внедряющая компания участвует в проекте до окончания этапа предпроектных работ, по окончанию этапа, если риски оправдываются – приостанавливает проект до решения проблемы с руководством со стороны заказчика.
Рассмотрим это на примере проекта автоматизации крупной промышленной компании.
Переговоры о начале работ давали основание полагать, что проект будет успешным. Острую заинтересованность в успешности работ показал генеральный директор, а также основной заказчик системы – финансовый директор. Перед началом работ были оговорены с заказчиком возможные риски.
В день начала предпроектных работ был представлен руководитель проекта – бывший сотрудник большой известной консалтинговой компании с опытом выполнения подобных проектов. Следует отметить, что этот человек принят на работу в компанию всего несколько дней назад и не интегрирован в функциональную структуру заказчика.
Первые дни выполнения предпроектных работ прошли без срыва сроков, но как только приблизился этап согласования частей технической документации – ответственные сотрудники заказчика, как обычно, начали затягивать сроки, мотивируя это тем, что у них нет времени (заняты текущей деятельностью). Руководитель проекта со стороны заказчика пытался эту проблему решить исключительно бюрократичными методами – подписывал у руководства распоряжения о сроках завершения согласования. Сроки, конечно же, срывались, на что всегда находились аргументированные, с точки зрения исполнителя, пояснения.
Работа выполнялась только под давлением финансового директора, который добивался от исполнителей результата к концу текущего дня.
Результатом такой предпроектной работы стало превышение в 2 раза срока сдачи этапа и как следствие финансовые потери для внедряющей компании.
Продолжение проекта было возможно только при условии назначения руководителем проекта финансового директора, который способен оказывать реальное влияние на менеджеров среднего звена.
Отсутствие у Заказчика методологии для автоматизируемых участков
Чтобы проект был успешным заказчик должен понимать, зачем этот проект нужен, какие цели и каким образом он будет их достигать с точки зрения методологии учета (программное обеспечение вторично).
Часто задачу построения методологии, которая приводит к достижению целей, берут на себя консалтинговые компании – методология в результате предельно формализирована. Можно участвовать в проектах и когда нет формального документа, например, «методология управленческого учета», но главное – чтобы были люди в команде заказчика, которые понимают, как они должны работать (с точки зрения методологии).
На этапе переговоров выявить степень готовности методологической части (если она не формализирована) у заказчика очень сложно (редко какой руководитель признается, что не имеет понятия, как ведется управленческий учет). В этом случае, консультанты могут участвовать в проекте до окончания этапа предпроектных работ, а по окончанию этапа, если риски оправдываются – проект следует приостановить до решения проблемы методологии учета.
Рассмотрим это на примере проекта автоматизации сети торговых предприятий.
По результатам первичных переговоров было выяснено, что все торговые предприятия сети ведут учет по почти единой методологии бухгалтерского и налогового учета, лишь с небольшими отклонениями. Главный бухгалтер всего холдинга – профессиональный специалист и понимает, что ему нужно получить в результате внедрения проекта автоматизации.
Первые же дни работы специалистов внедряющей компании в разных торговых центрах показали, что учетная политика у них сильно отличается: одни работают по упрощенной схеме налогообложения, другие ведут лизинговую деятельность, существуют разные политики по учету НДС, учету ТМЦ на складах.
Опаснее всего для реализации проекта было то, что при демонстрации всех различий главный бухгалтер холдинга оперативно не реагировал на просьбы специалистов внедряющей компании привести методологии предприятий в соответствии с требованиями проекта, что в свою очередь удлиняло сроки. Главный бухгалтер на самом деле даже и не знал о таких отличиях учета на разных предприятиях холдинга, и нужно было время, чтобы принять решение, удовлетворяющее все торговые центры.
В результате у заказчика была создана методологическая группа, в которую вошли представители торговых центров и самого холдинга, ответственная за принятие решений по различию методологий.
После создания группы работа пошла быстрее, но эта ситуация не могла не отразиться на сроках выполнения предпроектных работ (и, на финансовых результатах проекта).
Работа по проекту в целом была доведена до конца, проект был выполнен, но с существенным (на несколько месяцев) сдвигом сроков.
По результатам этого проекта был сделан вывод, что на предпроектном этапе заказчик должен представить документ, подтверждающий единую учетную политику. Если же его нет –то следует порекомендовать заказчику составить такой документ самостоятельно, или обратиться в одну из консалтинговых компаний для получения помощи в его составлении.
Существуют и другие риски, не менее важные при выполнении проектов внедрения автоматизированных решений. К ним отнесем:
- согласование проектной документации;
- наличие работающей схемы управления изменениями;
- ответственность пользователей за обучение;
- ответственность пользователей за результаты опытной эксплуатации.
- Кратко остановимся на каждом из них.
Согласование проектной документации
Разработка системы выполняется в рамках согласованной обеими сторонами проектной документации. Нередко бывают случаи, что исполнители от заказчика не очень ответственно подходят к вопросу согласования проектной документации, полагая, что все документы можно будет согласовать уже на этапах внедрения системы. Такое отношение к согласованию проектной документации приводит при внедрении системы к большому количеству отклонений (дополнительных требований, не зафиксированных в проектной документации). Чтобы этого избежать, проводятся следующие предупредительные мероприятия.
На первом и последнем совещании управляющего комитета по этапу «предпроектные работы» руководитель проекта с внедряющей стороны объясняет, что означает согласование заказчиком проектной документации, и какой порядок действий будет в дальнейшем, если будут проходить отклонения от проектной документации.
В разделе подписей проектной документации вставляется формулировка «Подтверждаю корректность и полноту …» – для того, чтобы исполнители еще раз обратили на это внимание.
Подобного рода предупредительные мероприятия привели к тому, что эта проблема на проектах почти исчезла.
Наличие работающей схемы управления изменениями
Очень важным аспектом организации работы на проекте является управление потоком информации, т.е. вопросами и предложениями, возникающими как со стороны исполнителя, так и со стороны заказчика.
Вопросы пользователей системы не должны остаться без внимания и ответа, чтобы них не накапливался негатив против самого проекта внедрения. Для обеспечения такой возможности необходимо регистрировать каждое такое обращение.
Для предупреждения такого рода проблем, на этапе тестирования системы исполнители устанавливают у Заказчика конфигурацию (разработанную по технологии ITIL ), в которой любой пользователь может задать вопрос, зафиксировать ошибку, или высказать пожелание. В уставе проекта фиксируется порядок разбора такого рода информации от пользователей, а также регламентируются сроки реакции на эту информацию. Почти всегда в цепочке обработки этой информации присутствуют ответственные лица заказчика (спонсор проекта – согласовывает доработки в части финансов, ответственные за методологию – согласовывают функциональную часть доработок, группа тестирования – если такая есть – проверяет наличие ошибки). Конфигурация дает возможность в автоматическом режиме отслеживать сроки реакции на сообщения, и выносить вопросы на управляющий комитет проекта, в случае, если есть отклонения от оговоренных сроков.
Работа такого механизма, и в том числе задача руководителя проекта со стороны заказчика заключается в обеспечении формальной регистрации вопросов пользователей.
К тому же такой механизм регистрации обращений позволяет анализировать текущую ситуацию и избежать ошибок на следующих этапах.
Ответственность пользователей за обучение
Часто бывает так, что пользователи рассматривают обучение новой программе не как работу, а как ничем не обремененный отдых. Это приводит к очень низкой усвояемости материала.
Чтобы повысить результативность обучения проводятся следующие действия:
- после каждого занятия подписывается у пользователей отзыв о прохождении обучения;
- по результатам обучения проводится тестирование пользователей.
Задача руководителя проекта со стороны заказчика на этом этапе – обеспечить учет результатов тестирования в схеме мотивации сотрудников.
Ответственность пользователей за результаты опытной эксплуатации
Одним из важнейших факторов успешной реализации проекта является этап опытной эксплуатации системы. На этом этапе пользователи должны ввести в систему тестовые или реальные данные и получить прогнозируемый результат.
Часто бывают, что пользователи ограничиваются небольшим количеством простых операций, на основании чего делают вывод о работе системы. Но проблемы в работе системы проявляются как раз на сложных операциях и их взаимосвязях. Поэтому часто такое отношение к опытной эксплуатации приводит к тому, что на этапе начала эксплуатации системы в рабочем режиме возникает огромное количество вопросов, которые можно было бы закрыть при опытной эксплуатации. В такой ситуации возникает вопрос о переносе сроков начала работы пользователей с системой, что влечет за собой срыв сроков всего проекта.
Для предотвращения возникновения подобных проблем желательно предпринять следующие меры:
- руководителю проекта со стороны Заказчика и всему управляющему комитету детально разъясняется роль опытной эксплуатации в успехе проекта;
- разрабатывается программа опытной эксплуатации, в которой эксперты со стороны исполнителя обязательно должны увидеть отражение самых сложных операций заказчика.
.jpg)
.jpg)
