11 причин провала проекта по внедрению 1С

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

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

И теперь готовы выяснить, что можно сделать с вашей стороны, чтобы внедрение 1С стало точкой роста, а не головной болью.

Все описанные проблемы являются реальными, и основаны на нашей многолетней практике и опыте общения с коллегами.

Приступим:

1. Отличие реальных целей и декларируемых, изменение целей в ходе проекта

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

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

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

Варианты решения:

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

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

2. Собственник не вовлечён, а менеджмент не имеет полномочий

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

Например, в компании есть генеральный, коммерческий и финансовый директор. Генеральный назначает последних ответственными за проект.

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

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

Варианты решения:

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

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

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

*Здесь и далее: РПЗ – руководитель проекта со стороны заказчика.

3. РПЗ отсутствует или у него нет фактической власти

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

Иногда РПЗ пробуют назначить главного бухгалтера, мы ведь 1С внедряем? Так пусть бухгалтерия и занимается. Главбух может быть РПЗ, но только в том случае, если он «правая рука директора», его уважают все подразделения и все руководители. 

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

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

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

4. Нет времени на проект у РПЗ и/или сотрудников

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

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

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

Варианты решения:

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

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

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

5. Сотрудники устраивают жёсткий саботаж (а собственник не вовлечён)

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

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

А) Осознанное сопротивление. Такое может случиться из-за страхов и переживаний:

• Страх, что благодаря новой системе руководство узнает о каких-то серых схемах. Например, старая система давала сотрудникам возможность получать выгоду. Это может быть мошенничество или хищение в чистом виде. Или эксплуатация уязвимости системы для повышения собственных показателей. Например, когда менеджер по продажам даёт всем клиентам скидку, которую можно применять лишь в редких случаях. Его продажи растут (как и доход), но за счёт существенного снижения маржи компании.

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

Б) Неосознанное сопротивление сотрудников. Здесь более глубокая причина, которая находится на уровне особенностей психики. Дело в том, что наш мозг не хочет учиться новому. Это сложно, это требует энергозатрат. Нужно строить новые нейронные связи и разрушать старые. А делать как раньше – куда легче и приятнее.

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

Решение: 

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

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

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

6. Переход с очень удобной, «сделанной под себя», системы

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

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

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

И изначально процесс идёт хорошо – обследование бизнес-процессов, моделирование. Это интересно и пока не описано. Но чем ближе к цели, тем больше становится ясно: «Мы не можем работать без этого АРМа (автоматизированного рабочего места)». Типовая 1С так работает? Да не может быть, это нелогично, мы так не сможем. Слишком много документов, у нас раньше было всё одной кнопкой.

Допиливаем, допиливаем и получаем… старую систему на новой платформе. Потому что чётко не определили цель: сделать удобное, а не типовое решение. А значит, в основе лежала проблема из пункта 1. Кстати, типовая 1С конфигурация – тоже удобна. Только нужно научиться в ней работать.

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

Решение: докапываться до истинных целей, собирать много данных. Заказчик точно должен понять для себя, что у него 2 пути:

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

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

7. Потеря интереса к проекту в организации (смена приоритетов)

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

1. Статус-встречи постоянно переносят или вовсе отменяются. 

2. Ответственные лица постоянно заняты в командировках, на других проектах.

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

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

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

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

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

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

8. Смена управленческой команды 

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

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

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

Решение:

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

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

9. Выбор неправильной архитектуры/продукта 

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

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

Также есть ситуации, когда нужен выбор – работать всей компанией в единой 1С базе, например, 1С:ERP, или в нескольких продуктах с настроенными обменами: 1С:ERP + 1С:Бухгалтерия предприятия + 1С:ЗУП. Такой выбор нужно обосновывать и принимать взвешенно, с учётом рекомендаций опытного партнёра.

Решение: 

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

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

10. Проблемы с данными (справочниками, остатками) при переходе

Проблема чисто технического характера. Обычно выглядит так:

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

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

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

Исполнитель при всём желании не может этого сделать, потому что:

• Он не знает специфику номенклатуры заказчика.

• Не ему в будущем с этой номенклатурой работать.

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

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

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

Решение:

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

Вместо заключения

11 причина – неправильный выбор подрядчика. Хотя в самом начале мы и сделали дисклеймер, что в статье пишем только о рисках на стороне заказчика, но совсем не затронуть вторую сторону было бы неверно. За этой причиной спрятано множество проблем, которые могут возникнуть, потому что подрядчик не может или не хочет делать проект; не имеет релевантного опыта и команды, или заказчик и исполнитель просто не подходят друг другу, раздражают друг друга. 

Первые пять причин – наиболее распространённые. Остальные встречаются реже, и, как правило, вытекают из первой пятёрки.

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

Мы работаем над тем, чтобы все проекты были успешными, приносили бизнесу пользу. Поэтому мы подготовили для вас специальный чек-лист контроля наличия проблем во внедрении.