Как пережить внедрение ERP: «ЮрСпектр» рассказывает, чему они научились

Этой весной компания «ЮрСпектр» начала внедрять ERP-систему — и первый день можно было сравнить с поездкой на падающем лифте. Представители компании «ЮрСпектр» и компании-разработчика «Инвенто» делились с «Про бизнес.» своими ошибками и выводами и готовились ко второму этапу запуска. Он прошел в начале лета. Исполнительный директор компании «ЮрСпектр» Андрей Яхновец рассказывает, что они предприняли, чтобы избежать ошибок, и какие выводы сделали.

— Новую CRM мы подключили на месяц позже, чем собирались: решили подготовиться лучше. Сотрудников, для которых мы запускали вторую часть, у нас в компании более 300 — они работают с постоянными клиентами, которые формируют 97% всего дохода. Поэтому цена ошибки на втором этапе была высокой, неудачный старт мог буквально «положить» бизнес. Но и мы, и разработчики уже слегка «прокачались», про это я говорил в прошлых материалах. И теперь внесли несколько крупных изменений.

1. Отказались от идеи внедрить «все и сразу». Мы сосредоточились на функциях, без которых просто нельзя работать. Для первоначального запуска выделили 4 основных сценария, которые обеспечивали работу с клиентом и своевременное поступление денег. Все остальное (а это было в основном аналитика и обеспечение второстепенных бизнес-процессов), мы отложили на потом.

В отношении интеграции CRM и онлайн-версии мы также реализовали самое-самое необходимое и решили посмотреть «как пойдет дальше».

2. Включили в команду 8 руководителей управлений, которые отвечают за работу с постоянными клиентами и доходы от них. Часть своего рабочего времени они участвовали в тестировании и оценке реализованных сценариев. Мы собирались 2-3 раза в неделю, слушали их отзывы, обсуждали, расставляли приоритеты и оперативно реагировали на их замечания, которые касались корректности работы функции, удобства и наглядности работы с ними. Приоритетное значение для нас, конечно, имела корректность работы. Удобство мы собирались «допиливать» после запуска.

3. «Выключили» некоторые показатели KPI. Переход на новую CRM оказался стрессом для сотрудников, которые годами работали в привычной системе. Им приходилось переучиваться, эффективность работы была под угрозой. Мы сконцентрировались на том, чтобы клиенты получали правовую информацию вовремя и в полном объеме, а также на том, чтобы «не уронить» поступление денег. Все остальные KPI и нормативы мы попросту убрали на время.

В последнюю пятницу перед запуском мы собрали всю команду внедрения для планирования первого дня работы по-новому.

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

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

Какие трудности обнаружились на этапе дальнейшего внедрения

1. Многие хотели видеть привычные функции в привычном интерфейсе «старой» CRM. Пришлось затратить много усилий, чтобы сотрудники начали понимать, что у новой системы своя логика и многие вещи нельзя реализовать точь-в-точь как в старой системе. Это приводило к разочарованиям.

2. Трудно было формулировать требования к системе. На выходе становилось понятно, что в одни и те же слова мы и разработчики зачастую вкладывали разный смысл.

3. Разные подразделения настаивали, чтобы именно их функциям присвоили наивысший приоритет в разработке. Появилось новое направление работы — оценка и расстановка приоритетов.

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

Для себя мы сделали ряд выводов.

Как пережить внедрение ERP

1. Не завышать ожиданий по функциональности. Лучше выделить 20-30% по-настоящему жизненно необходимых вещей и сконцентрироваться на их работоспособности.

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

Нужно сразу отказываться от идеи «реализовать все». Это позволяет сконцентрироваться на главном и сформировать адекватные ожидания у пользователей.

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

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

Правильная расстановка и реализация приоритетов невозможна без общения с разработчиками.

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

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

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

Самое лучшее — не фантазировать на тему реализации той или иной «кнопки», а пойти и спросить у конкретного пользователя, какую проблему он решает и как именно он хочет ее решить.

Чем большее участие конечный пользователь или его представители принимают в планировании и тестировании, тем меньше ошибок и выше их удовлетворенность. И тем меньше потом надо переделывать.

Другой аспект этой же проблемы — конечные пользователи должны располагать свободным временем на участие в планировании и тестировании новых функциональностей. А для этого могут понадобиться организационные решения на уровне руководства компании.

4. Детально прописывать запуск продукта для пользователей. Как известно, первое впечатление при знакомстве с человеком очень сложно изменить. То же самое можно сказать и про запуск проекта. Поэтому первый час, первый день и первая неделя должны быть детально спланированы. У пользователей важно сформировать адекватные ожидания от того, что они увидят и, что еще важнее, что они не увидят в новом проекте при запуске.

5. Наращивать свои компетенции в agile и в специфике разработки и тестирования ПО. Современная софтверная индустрия ушла далеко, многие традиционные компании (в том числе и мы) от них отстали. Это приводит к непониманию при реализации проектов. Понятия agile, scrum, sprint должны быть понятными и привычными для сотрудников, вовлеченных в такой проект. Айтишники не читают на эту тему лекций в ходе реализации проектов (возможно, зря), и поэтому важно учиться самим.

Без наращивания этих компетенций на нашей стороне реализация проектов будет оставаться разговором глухого со слепым.

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

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