Когда что-то пошло не так: топ-10 причин провала проекта по автоматизации

Внедрение нового IT-решения – сложное мероприятие. На результат проекта по автоматизации влияет множество причин, и некоторые из них находятся «на стороне заказчика». Если вы знаете потенциальные проблемы заранее, то можете принимать меры для их устранения. Так вероятность успешного завершения проекта будет выше. О том, что может помешать внедрению нового IT-решения и как избежать негативных ситуаций, порталу Biz360.ru рассказал Алексей Бояршинов, руководитель компании «Корада».

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

А уже в ходе внедрения выяснилось, что это неудобно. И нужно совсем не так, а чтобы каждая кнопка была на конкретном месте, отчёты были «как раньше», рабочие места пользователей «как мы привыкли» и т.д. То есть нужен максимально привычный, удобный для сотрудника продукт. Типовое решение изначально выбрали, потому что хотели по минимуму тратить ресурсы на поддержку и обновление. Но удобства хочется всё же больше.

Заказчику иногда сложно определить конкретные цели, проще задекларировать: «всё улучшить», «всё посчитать», «всё оптимизировать». А нужны более конкретные цели, в которых он уверен.

Как решить эту проблему

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

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

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

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

Такое случается, если приходит новый менеджмент, либо если собственник/лицо, принимающее решение, не слишком доверяет своим подчинённым.

Как решить эту проблему

• Наделить ответственных за проект сотрудников (желательно руководитель проекта со стороны заказчика – РПЗ) необходимыми для принятия решений полномочиями. В том числе правом решать спорные ситуации между подразделениями. Хотя бы на время внедрения.
  
  

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

• Приостановить работу по проекту до появления в компании человека, которому можно доверить принятие решений.

Таким РПЗ может быть IT-директор, которому подчиняется только его отдел, а другие отделы не выполняют его распоряжения. И либо он остаётся в проекте, но и далее не может принимать решения. Либо он лишается статуса РПЗ, а нового РПЗ не назначают.

Другой пример РПЗ без власти – новый сотрудник, взятый специально под проект. У него есть время. Но он в компании новичок, у него не установлены неформальные отношения ни с рядовыми специалистами, ни с руководителями. Ему будет очень сложно управлять проектом со стороны заказчика. И понадобится безоговорочная поддержка высшего руководства.

Как решить эту проблему

• Если РПЗ не имеет власти в проекте и не может его продвигать – нужно поставить проект на паузу. Сформировать задачи, описать цели и ответственность РПЗ. Возможно, стоит делать это вместе с подрядчиком.
  
  

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

• Нанимая руководителя проектов или выбирая среди сотрудников компании того, кто будет отвечать за проект, обратите внимание на его управленческий опыт, волю, умение планировать работу и организовывать взаимодействие с другими отделами.

Для подрядчика внедрение IT-решения является его непосредственной работой, на которую он может тратить всё своё время. А вот у заказчика существуют и другие текущие задачи.

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

Специалисты также не могут 40 часов в неделю уделять проекту автоматизации. Во-первых, у них есть свои задачи. Во-вторых, заниматься проектными задачами весь день (пусть даже с перерывами) – это сложная интеллектуальная работа.

Как решить эту проблему

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

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

• Поставить проект на паузу. Это нежелательно: во время паузы команда исполнителя будет занята другим проектом. И не факт, что она сможет быстро вернуться к вам. Но это всё же возможно. Если времени совсем нет, например, из-за жаркого сезона продаж (если у компании сезонный бизнес), можно дождаться момента, когда наступит «затишье». Это будет лучше, чем работать урывками.

Саботаж может принимать разные формы. Но ключевым условием является отсутствие вовлечённости со стороны собственника/топ-менеджмента. Ведь только они обладают властью прекратить сопротивление персонала.

Формы и причины сопротивления со стороны сотрудников:

• осознанное сопротивление. Причина – в страхах и переживаниях персонала: благодаря автоматизации руководство узнает о неэффективности отдельных специалистов или «серых» схемах работы;
  
  

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

Как решить эту проблему

• В любом случае руководству необходимо быть вовлечённым. Если собственник/генеральный директор лично показывает важность внедрения новой системы, поддерживает тех, кто старается, и «сурово смотрит» на тех, кто недоволен, мотивация стараться резко увеличивается. Если директор во время запуска системы на Мальдивах, у сотрудников возникает мысль, что новый продукт не так уж и важен.
  
  

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

• Управлять изменениями: ухудшать условия для сопротивляющихся, улучшать для тех, кто не только использует новую систему, но и обучает других. Мотивировать сотрудников, подкреплять их уверенность, в том числе с помощью подрядчика. Планировать и организовывать обучение для тех, кому сложно, с учётом их реального опыта и знаний.

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

И всё же компания решилась на внедрение типовой системы. Чтобы была регулярная поддержка и обновление, стандартизация, минимизация ошибок в коде. И изначально процесс идёт хорошо. Но чем ближе к цели, тем больше сомнений: как мы будем работать без этого АРМа (автоматизированного рабочего места), приходится заводить слишком много документов, мы не сможем работать в новой информационной системе…  

Допиливаем, допиливаем и… получаем старую систему на новой платформе. Потому что чётко не определили цель: сделать удобное, а не типовое решение.

Или вообще бывает так, что не дошли в ходе внедрения до финальной стадии. Например, РПЗ слабо отстаивал позицию, и сотрудники стали жёстко давить: «Если сделаете по-новому, мы вообще не будем работать. Верните всё, как раньше». Это уже полноценный саботаж из пункта 5.

Как решить эту проблему

Докапываться до истинных целей проекта по автоматизации. Стоит понять, что у вас есть два пути:

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

• отстаивать своё желание сделать по-новому: перед самим собой и своими сотрудниками. Привыкать, обучаться. Тогда проект будет успешно реализован. Привыкать будет болезненно, но через год работы новая информационная система станет такой же понятной и привычной, как была когда-то старая.

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

• статус-встречи постоянно переносят или вовсе отменяются;

• ответственные лица постоянно заняты в командировках или на других проектах;

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

Такое может происходить по нескольким причинам:

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

• Временная смена бизнес-целей. Например, крупная выставка продукции. Это важное событие, которое требует много времени на подготовку и само мероприятие. А после – на работу с полученными по результатам выставки заявками.

Как решить эту проблему

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

«1C:Управление нашей фирмой» – современное решение для автоматизации малого бизнеса. В одной программе CRM, продажи оптом, в розницу и через интернет, закупки, склад, персонал, финансы, бизнес-аналитика

Близкий к предыдущему пункт. Но если там менялись бизнес-цели компании, то здесь меняется отдельно взятый заинтересованный человек (или круг лиц). По причине ухода из компании или из-за перехода на другой проект.

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

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

Как решить эту проблему

• Если проект важен для компании и собственника бизнеса – нужно явно указать этот приоритет новым вышедшим руководителям. Познакомить их со всеми материалами по проекту: документами, планами, решениями. Или попросить сделать это предыдущую команду. Организовать общую встречу с подрядчиком, представить новую команду и подрядчика друг другу. Согласовать текущую точку проекта и планы с учётом смены команды. 
  
  

• Если при смене команды проект стал неактуальным, организовать встречу с подрядчиком, описать ему ситуацию и заморозить проект. Иногда почти без шанса на восстановление в будущем. Да, так тоже бывает. Такую ситуацию можно отнести в категорию непредвиденных обстоятельств. Здесь нужно полностью закрыть проект: принять завершённые фактически работы и то, что может быть использовано в будущем (документы, схемы, модели).

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

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

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

Как решить эту проблему

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

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

Подпишитесь и получайте раз в неделю рассылку с лучшими статьями о бизнесе

Рассказываем бизнес-истории, предупреждаем об изменениях в законодательстве, делимся опытом автоматизации

Подписываясь на рассылку, вы соглашаетесь с политикой персональных данных

Это проблема чисто технического характера. Обычно выглядит так. Сотрудники компании вели НСИ (нормативно-справочную информацию, справочники) в старой базе по своему усмотрению, просто указывая: «болт обыкновенный», «болт синий», «болт красный». Разные отделы и разные сотрудники имели доступ к справочникам. Если не могли найти в них нужную позицию – создавали новую. Обмен с сайтом также вёл к созданию новых позиций. Загрузка прайсов поставщиков – опять новые позиции. 

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

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

Поэтому именно человек или группа лиц со стороны заказчика должны сделать эту работу. Обычно кто-то из управленцев. Но задача нудная, долгая. Кажется не очень важной. И по этой причине постоянно откладывается. А когда наступает день загрузки базы, оказывается, что она не готова. И приходится загружать «мусорные» данные, как есть. И потом вручную уже в новой системе всё это чистить. Либо переносить сроки.

Из-за этого проекты редко не доходят до конца. Но позитивный эффект уменьшается.

Как решить эту проблему

• Разработать единую для всей компании структуру НСИ и утвердить её (возможно, с помощью исполнителя). Назначить сотрудника или сотрудников, ответственных за справочники. Прекратить доступ к базе «всех подряд» до создания новых элементов и папок. Получить у подрядчика формат, в котором он будет загружать данные в новую систему.
  
  

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

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

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

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».
biz360