О заказчике: производство, склады и логистика
Заказчик – дочерняя компания бразильской группы. На рынке России она работает уже 30 лет. Основная продукция – парфюмерия, в том числе спиртосодержащая, а также косметика, средства для ухода и макияжа.
Если говорить про производство, то это завод в России, которому уже порядка двадцати лет. Это современное предприятие с очень высокой степенью автоматизации. Я рассказывал коллегам, что у них используются даже специальные защитные элементы, чтобы волосы с бороды не попадали в продукцию. То есть требования к чистоте производства очень высокие, и само производство глубоко интегрировано с оборудованием.
До нашего проекта у них уже была MES-система, использовались автоматические весовые системы, которые контролировали параметры, формировался контроль качества. Это действительно высокопроизводительное производство: 19 автоматизированных производственных линий. Плюс есть контрактное производство, что также было важно для нашего проекта.
Кроме завода, есть развитая логистическая инфраструктура. Сырье, в том числе импортное, поступает на производство, перерабатывается и дальше отправляется на бранчи. При этом есть пять крупных распределительных складов – это большие складские комплексы, где не только хранение, но и сборка заказов.
Если говорить по цифрам, сборка доходила до 40 000 заказов в сутки. Это очень высокая интенсивность процессов, и это тоже накладывало серьезные требования на проект.
Цели проекта и достигнутые результаты
Теперь про цели и сам проект. Основная задача – разделение ИТ-ландшафта международной компании и российского филиала. В рамках блока 1С ключевая цель – автоматизация всех процессов: от интегрированного планирования и закупок до логистики, производства, сбыта и распределения продаж.
Чуть позже я расскажу про особенности, которые возникли из-за масштабной трансформации и повлияли на проект. В целом задачи были классические: анализ, проработка и реализация необходимого функционала.
По системам использовались решения на базе 1С: ERP, WMS, MES, LIMS. Также были внедрены ДО и ЕГАИС, которые стали частью единой системы.
Если говорить о результатах, промышленная эксплуатация была запущена в ноябре. Примерно за две недели стабилизировали процессы, и уже через полтора месяца вышли на уровень производительности, сопоставимый с тем, что был до запуска. Все процессы были выстроены, специалисты адаптировались, и удалось достичь показателей порядка 600–700 заказов в час – без остановки бизнеса и с сохранением прежнего объема.
Ключевые вызовы и сложности перехода
Самый интересный блок – это вызовы проекта. Естественно, все выстроить идеально не удалось. Про основные вещи – параллельный запуск, подготовку к запуску и выстраивание процессов – я расскажу отдельно, там будут специальные изображения.
Хочу отметить один момент – разработку и старт новых процессов. На первый взгляд это небольшой пункт, но на практике он оказывается сложным. Когда у вас идет автоматизация или трансформация бизнеса, сам бизнес не всегда до конца понимает, как должны выполняться те или иные задачи. И совместно выработать решение бывает непросто. С одной стороны, его нужно придумать так, чтобы бизнесу было удобно, эффективно, маржинально и быстро исполнять. С другой – оно должно корректно ложиться в систему.
Еще одна большая сложность – переход от разрозненных систем к единой. До этого использовалось иностранное ПО, и это не совсем «лоскутная автоматизация», но по сути – около 70 различных систем от разных вендоров. Причем это действительно разные вендоры, и нередко по пять–шесть систем выполняли схожие функции. Исторически так сложилось: функции развивались, дорабатывались, но в итоге начали дублировать друг друга.
При этом системы были относительно независимы. В каждой – своя нормативка. И когда вы запускаете большую систему, особенно на базе ядра 1С, это становится серьезным вопросом. Нормативку нужно приводить к единому виду – так, чтобы она была удобна и для планирования, и для закупок, и для производства, и для сбыта. И здесь возникает много сложных моментов, потому что практически невозможно принять решение, никого не затронув.
Отдельно – высокая степень автоматизации и интенсивность процессов. Процессы были выстроены так, что любой простой системы, по любой причине – обрыв связи, ошибка, неудачное обновление – мог остановить производство. А объемы серьезные: до 40 000 заказов в сутки. Если система встает, заказы начинают накапливаться, и потом этот объем не всегда удается быстро разобрать. Дальше я расскажу, как мы эти риски старались минимизировать. В итоге все эти сложности нам удалось преодолеть.
Масштаб проекта, команда и интеграционные потоки
Были и другие сложности. Пока мы разрабатывали шаблон решения и собирали данные, требования со стороны бизнеса продолжали меняться. И в уже оттестированные шаблоны – по нормативке или по процессам – приходилось добавлять новую атрибутику. Причем она могла влиять не на один процесс, а сразу на несколько.
Теперь немного цифр, чтобы было понятно масштабирование. В проекте участвовало около 200 ключевых пользователей, 65 исполнителей и порядка 500 пользователей в системе. Это, в целом, стандартный масштаб для подобных проектов.
Но важно другое. У нас было около 4 500 доработок – это большой объем кастомизации. И 72 двунаправленных интеграционных потока. Это не одна передача данных и не одна группа аналитики – это серьезные, крупные потоки данных между системами. Все это нужно было отладить так, чтобы весь комплекс систем работал как единое целое.
Если говорить о самой большой сложности, то это именно интеграция всех систем. Причем они запускались одновременно – фактически происходил единый «взрывной» запуск в одну работающую систему. И параллельно нужно было обучить пользователей, потому что не все могли быстро перестроиться на новые процессы.
Исходный IT-ландшафт и особенности систем
Теперь про исходный IT-ландшафт. Конкретные системы мы не раскрываем, но, например, было пять разных систем планирования. По сути они решали одни и те же задачи, но использовали разные данные – например, данные иностранных складов или только локальные. Соответственно, отличались и принципы работы.
Кроме того, было восемь ключевых систем завода. Склад работал в одной системе, производство – в своей, MES – в своей. Прямой взаимосвязи между ними не было. Они выполняли связанные функции, но не было единого понимания процесса.
Например, контроль качества входных материалов: материал мог поступить на склад, но если он не прошел контроль качества, его нельзя использовать в производстве. И это не всегда учитывалось. То же самое с производством: если полуфабрикат не выпущен или не прошел контроль качества, его нельзя использовать дальше. Если готовая продукция не прошла контроль, ее нельзя отгружать.
В старых системах такие ситуации могли проходить, а в рамках нашего подхода – уже нет.
Стратегия релизов и интеграция с интернет-магазином
Если говорить про сам проект. На изображении тот объем, который сделала наша компания. Первые два блока – это 1С. Я постарался показать масштаб интеграции и взаимодействия между системами.
Мы использовали релизный подход. Готовились к тому, чтобы условно в июле можно было запускаться. К этому моменту был подготовлен MVP-релиз по системам 1С, и в целом мы могли стартовать. Но возник важный момент.
Ниже блок, который изначально не планировался к реализации – складское хозяйство, которое находится на распределенных складах. Это сквозная система, через которую проходили все данные. Без ее автоматизации запустить весь комплекс было невозможно.
Понимание того, что нельзя атомарно запустить завод со всеми процессами, пришло уже тогда, когда мы начали детально отрисовывать будущие процессы и их взаимосвязи. Стало очевидно, что интегрироваться с существующей системой складов нецелесообразно. Гораздо правильнее сразу заменить ее на 1С:ERP и 1С:WMS и выстроить единый контур через склады. Это решение мы и реализовали.
В итоге второй релиз был запущен в ноябре. Причем запуск проходил одновременно с сайтом. Сейчас практически все покупают через интернет, и у заказчика есть свой сайт – можно посмотреть, он хорошо сделан, и компания в целом серьезно вкладывается и в производство, и в сопутствующие процессы.
Важно, что запуск сайта шел параллельно с внедрением, и между ними была плотная интеграция. Например, информация о наличии товаров на сайте синхронизировалась со складами в регионах. Если указано, что на складе есть 40 единиц товара, значит, они действительно есть.
Для этого была реализована частая синхронизация между ERP/WMS и сайтом – передавались актуальные остатки. Также было реализовано резервирование: если пользователь оформляет заказ, информация сразу передается на склад, и товар резервируется.
Что касается архитектуры, ядром выступала ERP-система. MES и WMS были связаны с внешними системами – это заводские системы, весовые комплексы, системы контроля качества. Также были интеграции с внешними сервисами: платежные системы, системы для работы с закупочной документацией.
Параллельно с этим запускался процесс разработки продукта. Отдельные системы формировали продукт, и через интеграцию с ERP мы получали технологическую подготовку – рецептуры, составы и так далее.
Отдельно стоит отметить систему хранилища данных – витрины и отчетность, которые позволяли выводить аналитику через дашборды и другие инструменты.
Подготовка к запуску: тестирование и обучение
На этапе подготовки к запуску пришлось очень серьезно вложиться в тестирование. Для таких масштабных систем стандартных подходов недостаточно.
В классических проектах – ERP, WMS, MES – обычно используются функциональное тестирование, регрессионное тестирование, а также сквозное тестирование, когда проверяется полный цикл: от планирования до сбыта или от закупки до расчетов.
Здесь, помимо этого, был очень большой объем интеграционного тестирования. Причем не только между системами внутри контура – например, ERP и WMS, – но и с внешними системами. Основной акцент был на интеграции между ERP и сайтом.
Мы проводили нагрузочное тестирование, проверяли систему под реальными объемами. Кроме того, использовали так называемые Golden Test. Это когда разворачивается продуктивное окружение, загружаются реальные данные, и проектная команда по заранее подготовленным документам моделирует первый рабочий день. Не реальные сотрудники, а именно команда проекта выполняет операции и смотрит, как система ведет себя в условиях, максимально приближенных к боевым. Это позволяет либо выявить ошибки на последнем этапе, либо убедиться, что система готова к промышленной эксплуатации.
Что касается обучения, использовался классический подход. Обучались ключевые пользователи – чтобы участвовать в тестировании, принимать результаты и помогать в дальнейшем развитии системы.
Конечные пользователи обучались как онлайн, так и на местах. Консультанты выезжали на склады и в подразделения и проводили обучение непосредственно на рабочих местах.
Отдельно хочу отметить гиперподдержку. Как бы ни были подготовлены инструкции – текстовые, видео, со скриншотами – пока пользователь сам не начинает работать в системе, вопросы все равно возникают. Поэтому первые полтора месяца после запуска мы обеспечивали плотную поддержку пользователей, решая задачи любого уровня прямо на местах совместно с заказчиком.
Цифры по инструкциям и тестам приведены на изображении, отдельно их комментировать не буду.
Выученные уроки: управление, ресурсы и требования
Теперь про выученные уроки.
Первое – объем проекта. Лет 15 назад меня учили, что нельзя запускать проект, если параллельно идет внедрение крупной ERP-системы или масштабная трансформация. В этом проекте это правило не сработало. Параллельно с нами шло еще шесть крупных проектов, с которыми нужно было интегрироваться – и по плану, и по результатам.
Возникали типовые ситуации: вы прорабатываете функциональную спецификацию, описываете, какими данными и в каких объемах будете интегрироваться с соседними блоками, а соседний блок еще не готов. Интегрироваться просто не с чем. Это приводило к потерям – и по времени, и по ресурсам.
Важно, что эти выученные уроки – это совместное мнение и наше, и заказчика. Мы с самого начала говорили: при таком объеме нельзя запускать все сразу без ущерба. Поэтому предлагали сосредоточиться на корневом функционале, а дополнительные доработки переносить на последующие релизы. После запуска специалисты поработают с типовой функциональностью 1С, поймут, что им действительно нужно, и уже тогда можно добавлять расширения. Но на практике заказчик часто хочет включить дополнительные требования и «бантики» уже в первый релиз.
Второй момент – ресурсы. Часто кажется, что достаточно выделить сотрудников бизнеса на проект частично. Но это не работает. Один из ключевых выводов заказчика – нужно заранее нанимать аналитиков, менеджеров и IT-специалистов, которые будут поддерживать систему. Причем не в середине проекта и не на этапе опытно-промышленной эксплуатации, а с самого начала.
У нас же часть специалистов, которые должны были принять систему и дальше ее поддерживать, начали нанимать уже ближе к запуску. В итоге мы не только обучали ключевых пользователей, но и параллельно глубоко погружали новых консультантов в систему.
Следующий урок – недостаточная формализация требований. Бизнес заказчика специфический, с большим количеством уникальных процессов, которых нет в классическом ритейле. Эти процессы нужно было описывать, структурировать и выстраивать.
При этом у заказчика не было большого опыта глобальных трансформаций такого масштаба. Поэтому часто процессы объяснялись через текущие системы: «Вот у нас сейчас так работает в SAP» – и дальше попытка воспроизвести это в 1С. Это неверный подход. Мы много работали вместе, чтобы описывать именно целевые бизнес-процессы, а не копировать старые системы.
И последнее – сроки тестирования. Один из главных выводов: нагрузочное тестирование нужно закладывать с самого начала проекта. Особенно для систем с большим количеством интеграций.
При этом не нужно пытаться протестировать абсолютно все или тратить ресурсы на второстепенные детали. Важно сосредоточиться на ключевом функционале – на том, что критично для бизнеса. Задача – обеспечить, чтобы система выдерживала нагрузку, пользователи могли работать, а запуск прошел стабильно.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
