6 уроков, которые мы извлекли из удаленного запуска WMS-системы

У наших проектов широкая география: Россия, Европа и США. И большинство внедрений WMS мы реализовывали, используя гибридную модель – удалёнку и очное присутствие. И давно понимаем простую истину: рабочее место там, где ноутбук. В прошлом году мы в этом ещё раз убедились, успешно реализовав проект полностью в дистанционном формате. И вот как это было.

Меня зовут Андрей Чмырев, я руковожу направлением Manhattan SCALE департамента «Логистика» в «КОРУС Консалтинг». В марте 2020 года мы должны были завершить проект для самой динамично развивающейся розничной сети продуктов питания в Украине, которая работает в формате дискаунтера. Ещё 10 лет назад мы внедрили WMS-систему Manhattan SCALE, клиент успешно использовал решение, но за долгое время процессы сильно поменялись – поэтому фактически новый проект стал «перевнедрением». По мере приближения даты запуска стало понятно, что мы не вписываемся в сроки: уже вступали в силу ограничения на перемещение людей между государствами, появились операционные ограничения у ритейлера, персонал, работающий на складе, несколько месяцев находился в режиме самоизоляции.

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

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

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

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

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

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

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

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

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

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

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

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

В удаленных запусках очень важна слаженность команды ИТ и бизнеса. И руководить этой командой должен один менеджер, который несет ответственность за общий успех.

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

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

Кросс-функциональные команды – основа эффективности проекта, и руководить ими должен человек, который видит картину целиком.

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

Снизить количество итераций тестирования можно несколькими способами. Основной – полноценная выверка сценариев клиентом до начала разработки. Альтернативный – использование автоматизированных или полуавтоматизированных систем тестирования для ускорения каждого цикла, как например, SOAP UI. Наиболее предпочтительный вариант – комбинация обоих способов. Альтернативный дороже, но позволяет быстрее проработать недочёты основного.

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

• Закрепляйте документально, проговаривайте очевидные вещи и моделируйте возможные сценарии развития событий. Тщательная подготовка к битве – уже 50% успеха.
• Снижайте барьеры коммуникации. Каждому участнику должно быть удобно, просто и понятно. Информация не должна теряться, позаботьтесь о быстром доступе ко всем данным.
  
• Обсуждайте с партнёром ожидания: на какие показатели ориентироваться и что считать успехом проекта, какие результаты вы хотите получить. В течение запуска отслеживайте прогресс внедрения.
  
• Не пренебрегайте дополнительными ИТ-инструментами, например, для мониторинга нагрузки инфраструктуры. Это поможет вам вовремя «ловить» причины инцидентов и решать их в моменте.