Менеджмент
28 октября 2019Проваливается треть проектов! Что (и кто) мешает компаниям автоматизировать бизнес
До 30% проектов по автоматизации, в частности по внедрению ERP-систем, заканчиваются факапом. И причин тому может быть множество. Сергей Гинько, руководитель компании «Умный код», делится мнением - почему проваливаются проекты и что с этим делать.
- Напомню, что ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) - это информационная система, которая позволяет хранить и обрабатывать данные и упрощает выполнение многих типовых задач (например, выписывание накладных, актов, счетов, составление договоров и т.д.), а также избегать повторяющихся операций и дублирования одних и тех же обязанностей разными людьми.
В Беларуси ERP-системы используют уже несколько десятков лет, первыми их стали внедрять производство и торговля. Сегодня в какой-то степени элементы системы используют практически все.
Руководитель компании «Умный код»
Из практики могу сказать, что среднее время внедрения ERP обычно составляет около 18 месяцев. При этом, по нашей статистике, около 20-30% проектов по разным причинам так и не доходят до финала. Почему? Я расскажу о причинах, которые обычно мешают автоматизации - как со стороны клиента, так и со стороны исполнителя. А также поделюсь возможными вариантами решения этих проблем.
Что (и кто) мешает внедрению ERP
1. Сопротивление персонала. 99% сотрудников не хотят менять свои привычки: вот они привыкли делать так, и все! Чаще всего это касается сотрудников в возрасте, но далеко не только их. Люди работают с кусочком информации, не видят всей картины в целом и не понимают, что их данные нужны в том числе другим отделам для принятия решений. Ведь неполные и некорректные сведения ведут к ошибкам в работе всей компании.
Пример. В ходе внедрения ERP в одной из лизинговых компаний специалист отдела продаж заявил: «Зачем мне вносить куда-то там данные, я в экселе все посчитаю быстрее! А данные я всегда в блокнот вношу!» Отношение поменялось после получения первых результатов: когда люди увидели, что с новой системой можно проводить в разы больше сделок и получать больше денег. Если раньше делали договор в ворде, а расчет - в эксель, то сейчас было достаточно один раз внести данные о клиенте в систему, и она сама составляла договор и расчет.
А еще бывают случаи, когда сотрудники не хотят прозрачности там, где есть воровство. Например, в процессе внедрения в одной компании выяснилось, что на складе много лет подавались неверные данные. Учет велся «на бумажках», заказчику отгружали за кэш. А с внедрением ERP все стало прозрачно - все действия в любой момент можно отследить по камерам. Конечно, многим это не нравилось.
Что делать. Чтобы уменьшить сопротивление людей, прежде всего с ними нужно выстраивать коммуникацию:
-
Проводить предварительное обучение работе в системе
-
Вовлекать в проект экспертов, чтобы они могли объяснять цели и преимущества автоматизации для сотрудников. К примеру, для специалистов отделов продаж отличным аргументом будет - «это позволит тебе делать больше сделок и больше получать».
2. Затягивание, несвоевременное предоставление данных. К примеру, наш аналитик просит заказчика: «Распишите, как у вас происходит приемка товара на складе. И нам надо проверочный кейс, чтобы мы его прогнали по системе». А заказчик надолго «зависает». Почему? Оказывается, у него внутри большого отдела все делают приемку товара по-разному. Разброд в процессах, единого стандарта нет.
И такое встречается довольно часто, смотришь и думаешь: как вы вообще работаете?! А уж если отделения компании находятся в разных регионах - там вообще полная рассогласованность, что ведет к финансовым потерям в компании.
Что делать. Конечно, порядок нужно наводить еще до начала внедрения ERP. Затем все четко структурировать и описать все процессы компании - и только потом запускать процесс. Хаос «закидывать в систему» нельзя!
Для исполнителей совет один - прописать в договоре четкие сроки с ответственностью за их нарушение. В этом должен быть заинтересован и заказчик, и исполнитель.
3. У руководителя проекта со стороны заказчика нет полномочий/компетенций/мотивации. Задача руководителя проекта - помогать внедрять ERP внутри компании, собирать данные. Но если на эту роль назначить человека, у которого не будет реальных рычагов влияния, авторитета и нужных знаний, вся автоматизация может провалиться. Я помню случай, когда на эту роль назначили рядового менеджера по продажам… В другой компании руководителем проекта стал маркетолог. Так вот приходит он в отдел продаж запрашивать данные, а ему говорят: «Нам некогда этим сейчас заниматься, есть более важные вопросы, план горит!»
Еще вариант: у человека есть полномочия, компетенции и финансовая мотивация, но нет интереса! Не хочет он заниматься этой работой, не нравится она ему, а больше в компании поручить некому.
Пример: собственник решил провести автоматизацию компании и назначил на роль руководителя проекта финдиректора - по всем параметрам он подходил идеально. Но по характеру финдиректор - достаточно закрытый человек, а руководитель проекта должен постоянно взаимодействовать со всеми участниками. А если он не сможет найти контакта с людьми, то много шансов, что ничего не получится.
Еще пример: на роль руководителя проекта по автоматизации назначили начальника отдела продаж - типичного достигатора: «вижу цель - иду к ней!». А новая задача требует навыков администрирования: постоянно всех контролировать, пинать, спрашивать.
Что делать. По моему мнению, идеальный руководитель проекта со стороны заказчика - один из топ-менеджеров, например, директор по развитию, операционный или финансовый директор. Причем при выборе важно учесть и индивидуальные особенности человека. А если проект большой, лучше создать команду, которая будет заниматься только этим проектом - от 1 до 7 человек. И обязательно наделить руководителя проекта полномочиями и дать стимул. Мотивация должна быть обязательно! Проектный менеджер или проектная команда должны быть заинтересованы в успехе проекта материально помимо основной работы, то есть должно быть вознаграждение или KPI за каждый реализованный этап проекта.
4. Неучастие собственника. Если на переговорах нам говорят: «Мы вам платим деньги, но не хотим ни во что вмешиваться - делайте все сами!», мы уже понимаем - ничего не получится, от проекта лучше отказаться. Ведь часто сопротивление переменам в компании достигает такого уровня, что без активного участия собственника ничего не двигается.
Если собственник - не заинтересованное лицо, если он не дергает руководителя проекта и хочет быть просто наблюдателем - это гарантированный факап!
Что делать. Постараться убедить собственника или первое лицо компании, что его участие в проекте необходимо. Это его компания, и зажечь свою команду - его задача.
5. Некомпетентность подрядчика. Варианты: слабые разработчики, нехватка знаний аналитиков. И как итог - деньги заплачены, а желаемого результата так и не получили. У меня тоже есть такой опыт: когда я начинал работать в этой сфере, 2 или 3 проекта я так и не довел до финала. Почему? Не было средств нанять сильную команду, компетенции сотрудников были недостаточными для тех задач, которые перед нами стояли.
Что делать. Тщательно изучать те компании, с которыми собираетесь сотрудничать. Смотреть на реализованные проекты, просить рекомендации или отзывы от их клиентов. Еще вариант - предложить к реализации кейс, после решения которого будет понятно, справится команда или нет. Например, разработка механизма по продажам и закупкам внутри группы компаний, чтобы внутренние операции делались на автомате. Такая работа ведется от 2 недель до 1 месяца и оплачивается по договоренности - а бывает, что и бесплатно, но без передачи самого продукта.
6. Цели и задачи изначально были поставлены неправильно. Из моей практики: нам заказали автоматизацию производственной компании, где продажи ориентированы на сеть множества мелких дилеров. Часть работы уже была выполнена, когда в руководстве решили: нет, не будем работать с мелкими дилерами, это дорого и неудобно - лучше выбрать одного крупного! Чуть позже решили отказаться от дилеров и сделать в этом регионе свое производство. А в итоге стали развиваться через франшизу. Естественно, все эти задачи требуют разных процессов. Это остановка, пересмотр целей и удлинение проекта с 9 месяцев до 1,5 года.
Что делать. Согласовывать цели и задачи автоматизации с долгосрочной стратегией развития компании.
И еще несколько причин - не слишком критичных, но тоже влияющих на процесс автоматизации.
7. Уход или смена людей из команды - со стороны клиента или заказчика. По опыту я уже знаю, что замена человека в команде проекта (не важно, заказчика или исполнителя) - это дополнительные 2−3 месяца к длительности проекта. Они нужны для того, чтобы человек вошел в курс дела. Например, сейчас у нас уходит один из бизнес-аналитиков, на его место приходит другой - мы заранее предупредили клиентов о возможном увеличении сроков проектов.
Но смена руководителя проекта со стороны заказчика может привести к гораздо более серьезным последствиям. К примеру, мы делали автоматизацию на одном производстве, и в это время поменялся руководитель проекта. И все - проект стал! 9 месяцев мы не могли согласовать техзадание, начался пересмотр всей работы и в итоге - расторжение договора.
Что делать. Предусмотреть все ротации в коллективах невозможно. Вариант для клиента - перед началом автоматизации провести с занятыми в проекте сотрудниками обсуждение их важности во внедрении, узнать планы людей по работе в компании на этот срок. Возможно - подписать дополнительное соглашение на этот период.
8. Несовершенство законодательной базы. Мы до сих пор работаем с бумажным документооборотом - все эти ТТН и ТН. Все печатаем, и обязательно на бланках строгой отчетности, с синими печатями. Да, есть вариант с цифровым ключом - но не все программное обеспечение его поддерживает. В той же России многие компании пользуются стандартом обмена edi - он позволяет компаниям обмениваться с клиентами и поставщиками документами в электронном виде.
Что делать. Принять как данность:)
9. Зависимость от ключевых сотрудников. Представьте ситуацию: компания работает на самописном продукте. Есть кто-то, кто ее написал и отлично в ней разбирается - например, программист-разработчик внутри компании. Никакой техдокументации нет, по всем вопросам идут к этому человеку. Что на выходе? Полная зависимость компании от этого человека. Его не могут ни уволить, ни применить к нему какие-то дисциплинарные меры. Если завтра человек уйдет из компании или с ним что-то случится - работа станет, компания окажется парализованной. Как думаете, захочет этот сотрудник перейти на систему, в которой разбирается не только он? Скорее всего, он будет всячески этому препятствовать вплоть до саботажа.
Что делать. Если вы доверяете этому человеку и считаете, что в отношениях с ним все будет хорошо и дальше, то можно ничего не менять. Если есть сомнения, лучше просчитать варианты перехода на один из распространенных продуктов для автоматизации.
Подводя итог, отмечу главное: затеяли автоматизацию - ищите в команду сильных специалистов и надежных людей. А еще выстраивайте партнерские отношения с исполнителем и будьте активными - от этого зависит успех всего проекта.