<img height=\"1\" width=\"1\" style=\"display:none\" src=\"https://www.facebook.com/tr?id=445424938985795&ev=PageView&noscript=1\" />
 
 
 

 

 
 
 
 

7 причин неудачного внедрения информационных систем

 

  

Автор статьи - Александр Гладкий, архитектор PLM-решений IDEAL PLM

 

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

 

1. Отсутствие функционального заказчика проекта

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

«Что там? ИТ-проект? Ну пусть ИТ-служба занимается!»

В этом случае есть риск, что проект может превратиться в принудительную информатизацию подразделений:

  • ИТ-служба не может самостоятельно сформулировать требования и собирает на бесконечные совещания будущих пользователей;
  • Последние не заинтересованы в изменениях и требования сводятся к «сделайте так, как у нас сейчас» и «автоматизируйте мне вот такой отчет».

 

Как снизить риск подобного исхода?

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

 

2. Отсутствие поддержки руководства высшего и среднего звена

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

Руководители среднего звена – это начальники отделов. Почему их поддержка также очень важна? Враждебно настроенный начальник отдела может устроить локальный саботаж проекта в своем подразделении:

  • Подчиненные в большинстве случаев берут пример со своего руководителя и также сторонятся проекта (в крайних случаях имеют от начальника прямой запрет на работу по проекту в основное рабочее время);
  • Для обоснования своего саботажа перед руководством начальники отделов могут применять тактику «вам что важнее – гособоронзаказ или игры с компьютерами?» (возможны разные вариации). 

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

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

 

Как снизить риск подобного исхода?

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

 

3. Плохая оценка рамок проекта или некачественная постановка задачи 

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

«У нас проблема с комплектацией на производстве! Давайте запустим ERP проект!»

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

 

Как этого избежать?

  • Проводить комплексное обследование процессов предприятия до начала проекта. Кроме процессов, которые предполагаются к улучшению, обязательно нужно затрагивать смежные процессы поставщиков и потребителей данных. Например, при обследовании предприятия с целью улучшения процессов КТПП, я стараюсь посетить следующие службы: продажи и маркетинг, КБ, технологические подразделения, закупки, ПЭО и отдел планирования производства, собственно производство, сервис и отдел контроля качества. Это позволяет определить наиболее полный перечень проблем предприятия;
  • По завершению обследования провести анализ всех проблем, определить их зависимость друг от друга и очередность решения;
  • Подобрать для проблем соответствующие методы улучшения процессов предприятия;
  • Сформулировать показатели эффективности проекта, которые покажут реальный успех проекта;
  • Защитить получившееся решение у функционального заказчика, заручиться поддержкой высшего руководства.

 

4. Неготовность к изменениям

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

  • Ввод новых бизнес-процессов или задач, изменение или исключение существующих;
  • Связанное с этим изменение оргструктуры и распределение новых функциональных обязанностей;
  • Изменение порядка взаимодействия с контрагентами; 

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

 

Как избежать?

  • Готового рецепта тут нет, пока высшее руководство не будет готово к изменениям, они не начнутся. Следовательно, надо работать с топ-менеджментом, обосновывать необходимость изменений потенциальными выгодами для предприятия.

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

 

5. Потеря фокуса

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

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

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

 

Как избежать?

  • Обозначить в начале проекта показатели эффективности. Показатели эффективности могут выражаться не только в виде экономической выгоды.

Примечание: о разработке показателей эффективности для проекта выйдет отдельная статья; 

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

 

6. Перегрузка исполнителя

Ясно как день, что даже самые талантливые специалисты имеют предел. Когда у компании-внедренца (или ИТ-службы) количество параллельных проектов превышает возможности по их реализации, то где-нибудь будет провал.

 

Как избежать?

  • Не затягивать проекты;
  • Не Затягивать Проекты!
  • Использовать стандартный функционал и процессы информационных систем (если стандартный функционал не покрывает большую часть потребностей заказчика, то, скорее всего, выбрано решение, не соответствующее поставленным задачам);
  • Заранее информировать продажи о имеющихся окнах в расписании.

 

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

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

 

 

Отсутствие процесса изменений может привести к тому, что главные документы, определяющие содержание проекта (ТЗ и план-график), перестают соответствовать потребностям заказчика, например:

  • В ходе проекта выяснилось, что какие-то работы или функционал уже не нужны, но «Плюшкины» со стороны заказчика все равно просят сделать «чтоб было». Эту трудоемкость можно было бы потратить на какие-то другие работы, неучтенные в ТЗ;
  • Перегибы со стороны исполнителя также случаются: выстраданное и подписанное всеми согласующими ТЗ превращается в монолит, изменить который можно только при удачном расположении звезд. Исполнитель реализует его буква в букву и отказывается вносить в него любые новые требования (обычно ситуация усложняется договором типа «фиксированная цена»);
  • В обоих случаях результатом будет формальное исполнение сторонами требований уже «мертвого» (неактуального) документа, о каких выгодах тут может идти речь?

 

Как избежать?

  • В самом начале согласовать процедуру изменения проекта, которая позволит заказчику вносить новые требования, а исполнителю рассчитывать на соответствующее вознаграждение при изменении содержания даже при наличии договора типа «фиксированная цена»; 

Заключение

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

 

Подписаться на новости

 
Заказать звонок

Мы позвоним
в рабочее время

Позвоните мне
Нажимая на кнопку "Заказать звонок", вы даете согласие c Политикой обработки персональных данных
Спасибо,

Спасибо! Заявку получили, сейчас позвоним.

Подождите,

Ваша заявка обрабатывается!

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

Подробнее о cookies можно прочитать здесь