Переход на новое программное обеспечение — стратегический шаг для бизнеса. В теории все просто: подобрали IT-решение, купили, изучили и начали пользоваться новой системой вместо старой. На практике компании сталкиваются со множеством подводных камней, которые могут тормозить или вовсе парализовать работу команды. Избежать сложностей можно: перед покупкой ПО важно проводить пилотный проект запуска системы.
За 4 года компания Omnidata провела ряд пилотов на рынках food, fashion и DIY ритейла. Из последних — с Lamoda, «Магнитом» и «Самокатом». За это время мы выявили «формулу» успешного пилотирования SaaS-продуктов («облачных» решений) для бизнеса и хотим ей поделиться.
Почему нельзя покупать систему без пилота, зачем нужна системность и как бизнесу избежать лишних трат — расскажем в материале.
Бонус — чек-лист успешного пилота!
Зачем бизнесу пилотировать IT-решение по подписке
Пилотный запуск проекта — «тест-драйв» программного решения перед его покупкой на реальных задачах бизнеса. Если вендор не предлагает провести пилот решения, а сразу склоняет к его приобретению, то стоит задуматься. Есть риск потратить финансы, время и человеческие ресурсы на ПО, которое в итоге разочарует.
Без пилота компания может столкнуться со следующими ситуациями:
1. Продукт не подходит под специфику бизнеса.
Самая очевидная проблема — система не оптимизирует процессы и не решает задачи, ради которых совершалась покупка. Перед выбором софта компании нужно оценить бизнес-процессы и определить цели внедрения нового продукта. Затем сформировать запрос и свои ожидания вендору до внедрения решения. На этапе пилота ответственный поставщик ПО проводит обследование бизнеса и оценивает, насколько решение подходит компании.
2. Решение оказалось некачественным или неполноценным.
На презентации вам показывали красивые картинки и графики, уходящие в космос, но на деле стало ясно, что решение сыровато, движок работает с ошибками, а система тормозит. Вы в ловушке — документы подписаны, продукт оплачен и установлен на каждом компьютере в офисе.
Часто поставщики софта включают в продукт дополнительные конструкторские решения. Например, ERP-систему (Enterprise Resource Planning) по управлению и планированию ресурсами предприятия или PIM-систему (Product Information Management) для работы с большими массивами данных о товарах. Это удобно — покупаешь один продукт, получаешь сразу несколько. Бывает наоборот — поставщик заявлял, что решение содержит все необходимые модули, а по факту они в доработке. Ожидания клиента не оправдались.
3. Сотрудникам неудобно работать в новой системе.
После внедрения решения сотрудники начали ворчать, что раньше было лучше. Команде неудобно работать в новой системе, даже если она значительно облегчает их рабочий процесс. Если вендор заинтересован в клиенте, то на этапе пилота он прислушается к комментариям команды и доработает продукт до его внедрения.
Например, во время проведения пилота с Lamoda, команде ритейлера показался неудобным интерфейс системы Omnidata.PLM. После завершения пилота разработчики изменили его по замечаниям сотрудников компании и адаптировали под специфику их работы.
4. Неквалифицированная техподдержка продукта.
От скорости ответа саппорта и качества решения возникающих вопросов зависит не только комфорт сотрудников, но и ежедневная работа компании. Плохо, если добиваться внимания на том конце провода приходится долго, а решение проблемы затягивается на недели. Плохо, если служба поддержки отправляет читать методички, потому что не может квалифицированно ответить на вопросы. Хорошо, что можно провести пилотный запуск и узнать об этом до внедрения решения.
Во время пилотов наших продуктов мы используем оптимальный по скорости канал коммуникации с клиентом — Telegram. Создаем группу в мессенджере, добавляем туда сотрудников, участвующих в пилоте. Уведомления приходят моментально, переписка не теряется, можно отправлять текстовые и голосовые сообщения, файлы и скриншоты.
4. У поставщика IT-решения не хватает мощностей.
Не все разработчики ориентированы на крупные компании, ряд из них может обслуживать только малый и средний бизнес. Но амбиции толкают их замахнуться на большой проект с продуктом, который не рассчитан на нужный объем данных. В случае внедрения такого решения бизнес теряет деньги: работа тормозится, клиенты жалуются, выручка падает. В результате компания подает заявление в суд на вендора с требованием компенсировать убытки за некачественное оказание услуг.
Итак, запуск пилотного проекта обезопасит компанию от ненужных трат, позволит протестировать функционал на реальных процессах и покажет:
- решит ли софт бизнес-задачи компании;
- насколько качественно работает ПО и служба его техподдержки;
- удобно ли сотрудникам работать в системе;
- хватает ли вендору мощностей на обслуживание компании.
Как мы проводим пилоты, и почему они дают результат
За 4 года работы мы сформировали эффективный алгоритм проведения пилотов. Он складывается из пяти обязательных шагов, регламента по количеству персонала и времени на внедрение стека. Системность позволяет клиенту отслеживать процесс пилота, бюджет на его проведение и рассчитывать сроки, в течение которых сотрудники будут заняты проектом.
1 шаг. Обсуждаем бизнес-цели компании и предлагаем IT-решение
На первой онлайн-встрече с клиентом мы анализируем ключевые аспекты бизнеса, а затем предлагаем подходящее под запрос программное решение.
2 шаг. Проводим экспресс-обследование бизнеса
Анализируем бизнес-процессы, чтобы адаптировать решение под потребности клиента. После этого готовим бизнес-функциональные требования: показываем потенциальному клиенту, как можно оптимизировать процессы, и где у компании «слабые точки».
3 шаг. Выбираем процесс для проведения пилота
Для пилота выбираем один неключевой бизнес-процесс, который не влияет на экономическую эффективность компании. Так мы обезопасим клиента от возможных проблем: если во время пилота что-то пойдет не по плану, бизнес не пострадает.
4 шаг. Подписываем документы и запускаем проект
Для проведения пилота подписываем 3 обязательных документа — договор на проведение пилота, договор о неразглашении информации (NDA) и технические спецификации и требования.
5 шаг. Анализируем результаты и составляем протокол опытной эксплуатации
После завершения пилота оцениваем результаты и показываем клиенту, решает ли система поставленные задачи, повышает ли эффективность процесса. Например, оптимизирует работу и сокращает ресурсы (время, количество персонала). Аналитики Omnidata не только фиксируют результаты для клиента, но и выясняют, как нужно доработать систему, чтобы сделать ее полезной для компании и комфортной для сотрудников.
Успех пилота во многом зависит от людей. По нашему опыту, пилоты проходят качественно и продуктивно, если обе стороны выделяют отдельные команды для проекта.
Со стороны Omnidata команда состоит из аналитиков, персонального разработчика для внедрения дополнений и директора по продукту. Команда формируется под каждый пилот отдельно и занимается только одним клиентом. Так сотрудники глубоко погружены в процесс, отслеживают текущие статусы по задачам и могут оперативно реагировать на запросы клиента.
Со стороны клиента просим выделить для проекта от 2 до 5 сотрудников. Чем больше команда, тем быстрее пройдет пилот, поскольку объем задач по тестированию продукта распределится между всеми ее членами. В среднем каждый сотрудник со стороны клиента тратит на проект около 1 часа в день.
Пилот длится от 2 до 4 недель, в редких случаях — дольше. Месяца достаточно на тестирование продукта клиентом и оценку его пользы для компании. Но бывают исключения: пилот с Lamoda длился 3 месяца из-за большой загруженности команды ритейлера. Параллельно с пилотом сотрудники разрабатывали первую коллекцию одежды, обуви и аксессуаров под собственными брендами компании.
Чек-лист успешного пилота
- Используйте измеримые KPI для оценки эффективности проекта. Перед запуском нужно определить KPI (ключевые показатели эффективности) для пилотируемого бизнес-процесса. Желательно выбрать количественные метрики, их легче отследить. После завершения проекта сравните ожидаемые KPI с реальными.
- Отнеситесь к проекту серьезно. Финансовых и временных затрат на проведение пилота не избежать. Поставщики IT-решений запускают такие проекты на коммерческой основе, а к участию привлекают команду сотрудников со стороны клиента. Нужно отнестись к пилоту, как к реальному проекту, тогда работа пройдет продуктивно, а результат порадует.
- Подключите сотрудников и убедите их в необходимости перемен. Во время пилота сотрудники компании тестируют систему, учатся и привыкают к ней. Некоторые вендоры адаптируют решение под потребности бизнеса. Поэтому важно, чтобы в группу вошли представители всех отделов, которые будут использовать систему после ее внедрения, включая внештатных сотрудников. Иногда людей нужно убедить в необходимости запуска нового решения и скорректировать процессы их работы исходя из новых условий.
- Убедитесь, что ПК не подведут. Впечатление от новой системы могут испортить технические сложности — компьютеры не «тянут» софт. Программисты со стороны поставщика IT-решения подскажут, какие технические требования нужны для реализации проекта. И получится ли, например, конструктору одновременно работать в PLM и CAD-системе (Computer-Aided Design).
- Не останавливайтесь после завершения пилота. Между пилотным проектом и внедрением (если компания решила перейти к полноценному использованию системы) есть временной промежуток. В этот момент подводятся результаты, формируются закрывающие документы, согласуется бюджет. Важно не останавливаться и стимулировать сотрудников продолжать пользоваться продуктом. Пауза может ослабить общее впечатление команды от нового решения, охладить энтузиазм. А значит возвращаться к работе в новой системе после ее внедрения будет сложнее.