Разделение проектов на релизы

Этапы, вехи, релизы проекта

Любой более-менее длительный проект разделяют на блоки. Обычно эти блоки называют этапами. Это позволяет контролировать ход работ, но не всегда снижает риски успешного завершения проекта. Чтобы разделение работ на блоки помогало снижать риски, предпочитаю выдавать заказчику результат порциями, которые назваю "Релизами". Критически важно, чтобы заказчик начал пользоваться результатами труда в повседневной работе, а не просто протестировал нечто, вселяющее надежду, что все идет по плану. Есть мнение, что сложные проекты часто невозможно или очень дорого разделять на автономные блоки. Ниже несколько примеров из жизни, а также обоснование подхода, которое, надеюсь убедит отказаться от внедрений "под ключ" или "Большим взрывом".

Польза разделения проекта на самодостаточные релизы

Если вредрять проект "Под ключ", основной риск в том, что в "День Х", предоставленный результат будет сильно отличаться от ожиданий заказчика. Заканчиваются такие ситуации единообразно - заказчик ругает подрядчика за некомпетентность, подрядчик винит заказчика за подмену понятий, а себя за излишнюю мягкотелость. И ведь каждый перестраховался от такого исхода:

• Совместно написали огромные кипы детальных технических требований
• Продумали этапы, проводили регулярные демонстрации и тестирование с участием будущих пользователей
• Заранее обучили персонал новой системе

И все равно, что-то пошло не так. В итоге, сроки сорваны, бюджет нарушен (в ущерб ли заказчику, исполнителю или обоим - не суть). Как этого избежать?

Один из способов - использовать для управления проектом подходы PMBoK

Но моя рекомендация - делить на Релизы. Задача каждого релиза - получить основные выгоды, либо найти способ исключить / минимизировать основные риски. Для визуализации этого сделаем следующие предположения:

• Проект удалось разделить на пять релизов
• Стоимость каждого релиза составляет 20% общего бюджета
• Каждый релиз дает 80% оставшейся пользы
• Каждый релиз исключает 80% остающихся рисков

Такой проект можно представить следующей таблицей:

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

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

Примечательно, что стоимость рисков опять же вряд ли превысит 20% бюджета проекта, цель снова сложно не достигнуть.

Возвращаясь к предположению, что мы столь изобретательны, что удается за один релиз получить 80% пользы и исключить 80% рисков, тогда цели, скорее всего, для каждого следующего релиза будут пересматриваться, таблицу результативности сценария можно представить так:

Поскольку не всегда получается найти столь эффективные решения, рассмотрим более реалистичный сценарий, когда в каждом релизе удается добиться 20% пользы, исключить 20% рисков, разделить проект на 12 равных по стоимости частей, каждый релиз пересматривать цели:

То есть, разделяя проект на релизы можно не только до 100% увеличить шансы на успех, но и за те же деньги получить двое больше, чем пытаясь реализовать проект "под ключ". При этом уже с первого релиза компания начинает пользоваться плодами изменений.

Кейс "Роботизации производства рецептурных очков на заказ"

Крупная сеть магазинов оптики приобрела первый в России станок, роботизирующий обточку линз по индивидуальному рецепту клиента под форму выбранной им оправы. Сам по себе станок не помогает автоматизировать процесс настройки оборудования для обточки линз, но перед покупкой руководство компании видело работу таких станков в условиях глубокой интеграции с ERP. Без подобной интеграции эксплуатация станка обходится дороже, хотя и окупается в разумные сроки. После начала эксплуатации захотелось большего. Обратились к производителю, он разъяснил, что есть несколько сценариев интеграции, которые без него реализовать сложно, окупаются подобные инициативы, когда количество станков возрастает примерно до 6 штук - стоимость проекта была соизмерима с расходами на станок.

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

• ждать, когда бизнес вырастет до 6 станков (сейчас уже известно, что на это потребовалось бы более 10 лет)
• попробовать выполнить интеграцию своими силами

Рисков делать интеграцию самостоятельно было великое множество, например:

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

В итоге, успех самостоятельной интеграции оценивали как слишком маловероятный. Но решить задачу очень хотелось. Как быть? 

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

• снизить себестоимость производства
• обеспечить стабильное, предсказуемое качество
• облегчить масштабирование бизнеса

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

1. снизить себестоимость за счет удешевления сканирования (сулило 20% экономии)
2. оцифровать основные параметры заказов, которые вносит в ERP розница
3. систематизировать справочник линз
4. систематизировать справочник оправ
5. снизить себестоимость за счет уменьшения трудозатрат инженера на настройки, уменьшив одновременно ошибки
6. выявить параметры, влияющие на настройки станка под заказ
7. повысить предсказуемость настроек сканка под заказ, формализовав алгоритмы настроек
8. автоматизировать формирование настроек
9. исключить человека из процесса настройки станка под заказ

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

Первый релиз: снижение себестоимости на 20%

Оказалось, что для реализации первого релиза практичнее всего пойти на жервы, которые только выглядели большими - более половины заказов, поступающих в производство, использовали оправы, находящиеся на складе в больших запасах. Сканер оправ позволял подключать к нему сканер штрих-кодов, однако заказ в производство приходил с бланком, на котором был только штрих-код заказа, у оправ на бланке не было штрих-кодов. Дорабатывать ERP в этот момент не стали, поручили складу отправлять в производство оправы с приложенными отдельно заводскими штрих-кодами. Если в производство поступал заказ из магазина или без штрих-кода оправы, его передавали инженерам, вытачивающим линзы на ручном оборудовании. Для инженеров была написана небольшая инструкция, описывающая новый бизнес-процесс, все были обучены проведенным изменениям. 

Через неделю подтвердилось, что трудозатраты на заказ сократились примерно на 20%. Начался сбор базы данных отсканированных оправ. Затраты на релиз составили несколько часов - это меньше 1% от общих затрат на проект.

Второй релиз: оцифровать основные параметры заказов, которые вносит в ERP розница 

Технически это было несколькими релизами:

• автоматизировать создание файлов для станка с контуром обточки линз, если в базе присутствует отканированная оправа
• автоматизировать внесение в файл для станка параметров заказа, которые вносит розница, не дожидаясь доработки ERP, контроль корректности на инженере производства (более 80% заказов заполнялись розницей так, что внесенные параметры можно было оцифровать, но остальные было надежнее доверить вносить инженерами вручную)
• доработать ERP, чтобы устранить ручной ввод основных параметров заказа инженером производства

Трудозатраты на каждый релиз исчислялись уже днями, а не часами, на снижение себестоимости влияли не существенно, но позволяли радикально снизить риски инициативы:

• после автоматизации создания файлов для станка не только снизились трудозатраты еще немного, но главное - появилась уверенность, что создаваемые нашей программой файлы читаются станком без проблем
• после автоматизации заполнения в файле параметров заказа немного снизилась вероятность ошибок, но самое важное - улучшилось понимание требований к доработкам ERP
• параметры, вносимые розницей в ERP, удалось вписать интерфейс и значительно повысить качество вносимой информации

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

Уже на этом этапе уверенность в успехе задачи возросла в разы.

Третий и последующие релизы 

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

Кейс "Роботизация склада поставщика автозапчастей"

Крупный поставщик автозапчастей с основным каналом продаж eCom B2B. Складская сеть включает несколько десятков складов, центральный склад обслуживает прямые поставки по своему региону и пополнение складов в других регионах, работая круглосуточно и выполняя около 10 000 комплектаций в сутки. Значительная часть заказов приходит от сервисных центров, обслуживающих вставший на ремонт грузовой транспорт. Для таких клиентов привлекательность поставщика в первую очередь определяется сроками поставки, так как простой грузового транспорта обходится владельцам в копеечку. Исследование рынка складского оборудования и особенности процессов склада и распределительного центра привело к роботизированному варианту, способного обеспечить хранение в стеллажах высотой до 10 метров и требуемую пропускную способность.

После внимательного изучения роботизированного варианта, пришли к выводу, что 5% товара с высокой оборачиваемостью являются для системы узким горлышком, сильно повышающим стоимость решения, поэтому стоит предложенную технологию совместить с лифтами (типа Kardex), небольшим конвейером и стеллажами Put-to-light. Комбинированное решение можно схематично представить следующим образом:

Данная схема сразу отражает и крупные релизы реализации проекта:

• Релиз 1, окупаемость 1 год: 
  один лифт, один робот, стеллажи для оператора с системой Put-to-light, несколько стеллажей для робота
• Релиз 2, окупаемость 1.5-2 года: 
  второй лифт, дополнительные роботы и дополнительные стеллажи для роботов
• Релиз 3, окупаемость 3 года: 
  еще два лифта, получение ящиков от роботов через конвейер, дополнительные роботы и стеллажи для них
• Релиз 4, окупаемость 4-5 лет:
  быстрые разгрузчики/погрузчики для роботов, замена части мезонина на стеллажи для роботов, дополнительные роботы, достижение комплектации целевых 850 строк в час.

Данная схема проекта была разработана в результате анализа реальных операций распределительного центра за полгода. В LibreOffice были созданы упрощенные математические модели:

• лифтов, размещение товаров в них, комплектация и пополнение
• роботов, размещение товаров на стеллажах для роботов, логистика до мест комплектации, пополнение

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

Анализ логистических данных за полгода, особенностей лифтов, роботов и альтернативных технологий выявили следующие вопросы:

• какое количество лифтов оптимально 
  (были просчитаны конфигурации с 1, 2, 3, 6, 8, 12, 16, 24 лифтами)
• сколько лифтов оптимально обслуживать одним оператором 
  (рассматривались варианты 1, 2, 3, 4; чем меньше лифтов, тем больше оператор ждет лифт)
• какая ширина полки лифта оптимальна 
  (1250мм, 1650мм, 1850мм, 2450мм, 2850мм, 3050мм; чем шире полка, тем больше на ней SKU товаров, тем реже требуется перемещать полки, но больше километров за смену проходит оператор)
• какой вес оптимален для полки оптимален 
  (250кг, 500кг, 700кг, 1000кг; чем ниже вес, тем быстрее перемещаются полки, тем ниже стоимость лифта)
• как обеспечить максимальную производительность оператора
  (размер ячеек, подсвечивать ячейки или смотреть на экране, дублировать эраны по всей ширине лифта или размещать один сбоку, дублировать экран на ТСД с креплением на рукаве оператора, сканировать каждый товар или подтвержать завершение комплектации кнопкой, заказ перепроверять на упаковке)
• оптимальные размеры стеллажа Put-to-Light, количество и габариты ячеек в них
  (больше ячеек позволяет комплектовать больше заказов одновременно, что снижает частоту смены полок, но большая высота и ширина стеллажа снижает производительность оператора)
• дублировать ли товары на полках в разных комбинациях
• как оптимальнее распределить товары между лифтами, роботами и ручной комплектацией на мезонине
• как обеспечить достаточную безопастность оператора, если до установки разгрузо-погрузочных роботов HaiPort и конвейера использовать стеллажи, куда роботы Haipick складывают привезенные оператору ящики и забирают оттуда же обратно на хранение
• сколько роботов в итоге потребуется, чтобы обеспечить суммарную производительность около 850 строк в час
• какие товары оптимально обслуживать роботами и какую площадь хранения для стеллажей под роботы выделить с учетом, что почти 100% товаров проходят розничную комплектацию, отгрузки паллетами и коробами без вскрытия занимают менее 2%
• какой высоты роботы оптимально покупать 
  (7м стоят дешевле 10м, но на складе оплачиваются все 12м высоты)
• как максимально сгладить нагрузку на склад без потери продаж, чтобы сократить число роботов
• ежегодные расходы на обслуживание лифтов, работа склада в условиях аварий лифтов, срок эксплуатации лифтов
• ежегодные расходы на обслуживание роботов, работа склада в условиях аварий роботизированного комплекса, срок эксплуатации аккумуляторов, роботов
• энергопотребление лифтов и роботов, обеспечение работы оборудования в условиях аварий питания складского комплекса
• работа решения в условиях аварий компьютерной сети (локальной и Интернет)
• комбинирование в решении технологий конвейеров, Put-to-light, Pick-by-voice, сортеров конвейерного типа и роботизированного, целесообраность использования AGV, AMR, AS/RS, AutoStore (в т.ч. минилодеры), роботы Pick-and-Place

Потенциально, выбранные для клиента роботы Haipick позволяют повысить эффективность работы оператора на 200-300% (то есть в 3-4 раза!), лифты же увеличивают производительность на 80-120% (то есть вдвое), но это если в среднем, по всему ассортименту. Размещая в лифтах не очень тяжелые, мелкие и не очень крупные товары лифты обходят роботов по производительности и особенно по цене "за строку". То есть даже на простых математических моделях в Excel-таблицах рассчитали, что заказчику достаточно 2х лифтов, чтобы вдвое снизить нагрузку на роботов (почти вдвое сократить бюджет решения, с предлагаемых 50 до 25-30 роботов). Варианты с 4 и 6 лифтами оправданы при увеличении числа операторов, обслуживающих роботов. Также расчеты показали, что часть товаров практичнее оставить для ручной комплектации на нескольких этажах мезонина, совмещая в функциях операторов на каждом этаже также комплектовщиков из ящиков, которые привозят роботы со своих стеллажей. Глубокие запасы, скорее всего, практичнее будет оставить на паллетном хранении, так как там можно обеспечить большую плотность хранения, чем в стеллажах для роботов при одновременно более низкой стоимости тары.

Созданная нами математическая модель показала, что поставщики, предлагающие роботов, не правы, сравнивая свое решение с десятками лифтов для достижения той же емкости хранения, так как наши расчеты для условий заказчика определили оптимальное количество лифтов в диапазоне 4-6 штук. Дальше производительность комплектации практически не растет, зато увеличивается стоимость хранения. Поскольку тара для роботов ограничена габаритами и весом, некоторые товары оптимальнее комплектовать вручную на мезонине, т.к. их одинаково дорого хранить как на стеллажах для роботов, так и внутри лифтов. Таким образом, товары категории C (маловостребованные) и негабаритные товары предварительно были определены под ручную сборку на мезонине.

Далее, для первого релиза были достигнуты договоренности с поставщиком лифтов в получении б/у оборудования в аренду или с выкупом за разумную сумму с возможностью дооснащения в будущем до необходимых параметров. Поставщик роботов предоставил свое оборудование бесплатно, в обмен на организацию демо-стенда, на который может приводить своих клиентов. За счет этого, основные расходы составляла интеграция нового оборудования в инфраструктуру заказчика.

Первый релиз: снижение рисков проекта

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

• разумное количество лифтов
• оптимальное количество ячеек Put-lo-light и размеры ящиков в них
• необходимое количество роботов и стеллажей для них
• оптимальная площадь мезонина с ручной комплектацией

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

Первый релиз был разделен на несколько промежуточных:

• релиз 1.1: 
  (оборудование по возможности из того, что есть в наличии заказчика, без оптимизации под производительность робота)
• • установка робота и нескольких стеллажей для консолидации предсобранных заказов
  • интеграция робота с WMS
  • установка стеллажа, на который робот будет складывать ящики для оператора (пока без Put-to-light)
  • установка стеллажей на мезонин для передачи роботу ящиков для консолидации предсобранных заказов для отгрузки
  • установка стеллажей для передачи отделу упаковки ящиков предсобранных заказов
• релиз 1.2:
• • установка лифта
  • интеграция с WMS
• релиз 1.3:
• • установка стеллажей Put-to-light
  • интеграция с WMS
• релиз 1.4:
• • тюнинг
  • расчет параметров системы для второго релиза

По завершении данного этапа проекта примерно для 5% заказов ожидалость двойное увеличение производительности, а также снижение толкучки комплектовщиков на мезонине в часы пик. Подавляющее число рисков оставалось позади - это ключевой результат перечисленных выше работ. Ожидаемая окупаемость релиза около 9-15 месяцев.

Второй релиз: повышение эффективности, повышение скорости комплектации срочных заказов

Данный релиз предполагал передачу новым участкам более 40% комплектаций. Предварительно предполагалось установить второй лифт и увеличить количество роботов до шести (пока пять работают, шестой заряжается). На стеллажах роботов предполагалось разместить не только ящики с предсобранными заказами, но и начать размещать товары, которые прежде собирались вручную на мезонине. По завершении предполагалось уточнить требования к третьему релизу.

Третий релиз: повышение эффективности

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

Четвертый релиз: повышение эффективности

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

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

Кейс "Цифровизация производства молочной продукции, кросс-докинг"

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

Производство роботизировано, но рецептура описана в файлах Excel, настройка оборудования происходит вручную, учет использования сырья оставляют желать лучшего, объемы и причины утилизации в значительной степени работают на доверии и с трудом поддаются анализу и оптимизации. Обслуживание продаж происходит в основном вручную, для полноценного перехода небольших поставщиков на самообслуживание через eCom, а более крупных на интеграции через EDI постоянно не хватает каких-то мелочей, хотя сулит сокращение ФОТ соответствующей группы в 3-4 раза. Склад, принимая машины из производства и от партнеров, выполняет лишнюю работу, переход на кросс-докинг оценочно даст сокращение ФОТ примерно втрое и в 3-5 раз позволит уменьшить арендуемые складские площади. Расчет маршрутов транспорта выполняется при поддержке специализированных решений, но требует интеграции с ERP и WMS, чтобы полноценно воспользоваться преимуществами кросс-докинга. Автоматизация ряда рутинных операций также сулит сокращения ФОТ соответствующих групп в офисе в 2-3 раза. Каждая задача по отдельности не выглядит сверхсложной, но одна завязана на другую, полноценно без которой не реализуется, клубок не распутывается уже пару лет.

Выявленные сложности:

• производство полностью работает на Excel (приемка, производство, отгрузка). Чтобы оцифровать производство, требуется оцифровать приход и учет сырья. Сейчас номенклатура учитывается в документоориентированной ERP, которую компания меняет на процессно ориентированную ERP, где планируется автоматизировать все процессы, а также создать цифрового двойника компании, чтобы видеть наглядно возможности для повышения эффективности.
• склад работает в WMS, интегрированной со старой ERP, переход на новую ERP совмещен с опасениями порчи продукции с малым сроком годности (3 дня для 50% товаров, лишь менее 10% товаров могут храниться более месяца)
• кросс-докинг нет смысла реализовывать до перехода на новую ERP
• увеличивать автоматизацию транспортной логистики не имеет смысла до смены ERP
• автоматизировать расчет производства невозможно до перевода производства на новую ERP
• при попытке начать переход на кросс-докинг в рамках прежней ERP высок риск забастовки сотрудников склада в связи с риском потери работы
• автоматизация процессов в офисе на старой системе нецелесообразна из-за дублирования расходов при переходе производства и склада на новую ERP

Одним из решений в таких ситуациях кажется запуск нового методом "Большого взрыва" в назначенный "час Х". Ни разу не видел, чтобы это срабатывало и мировой опыт показывает, что шансы на успех подобных инициатив в интервале 2-30% (PricewaterhouseCoopers 2004 и CHAOS Report 2020).

Чтобы прийти к намеченным целям без лишних потерь достаточно "есть слона по частям", выполняя проект следующими релизами:

• Релиз 1: на складе начать переход на новую ERP и WMS без одновременного отказа от прежних WMS и ERP.
• • для этого придется обеспечить их интеграцию.
    Это деньги, но много меньшие возможных потерь при внедрении "Большим взрывом".
  • начать переход склада на новую WMS с товаров с самым большим сроком годности и малой маржинальностью.
    При любых проблемах это приведет лишь к возможным мизерным потерям из-за задержки отгрузки таких товаров.
    Зато позволит отладить интеграцию и постепенно обучить персонал работе с новой системой.
• Релиз 2: переход на кросс-докинг начать с предварительного размещения привезенной продукции с сортировкой по клиентам
  Это снизит плотность хранения, поэтому применять только для отдельных отгрузок, на которым и отладить интеграции, обучить персонал
• Релиз 3: на производстве оцифровку учета сырья, выпускаемой и утилизируемой продукции начать с части ассортимента, затрагивающей примерно 5% номенклатуры, что практически не повлияет на ФОТ производства.
  Отладить интеграцию с оборудованием для автоматизации настроек, вносить правки в настройки исключительно через ПО, фиксируя причины смены рецептов. Добившить прозрачных процессов, приступить к снижению трудозатрат и масштабированию оцифровки на весь ассортимент.
• Релиз 4: полуавтоматизированный расчет транспортных маршрутов перенести в новую ERP не дожидаясь запуска обновленных производства и склада
• Релиз 5: автоматизацию планирования производства выполнять последовательно для той же продукции, которая уже была переведена на производстве в новую ERP

Первый релиз: переход склада на новую WMS и ERP

Новая ERP содержит в себе WMS систему, задача которой обеспечить также кросс-докинг и сопровождение транспортной логистики. Соблазнительно оценив бюджет проекта, выдать подрядчику денег, получив через оговоренный срок новое замечательное решение. Однако, любые проблемы при запуске чреваты большими потерями для бизнеса в силу малого срока годности (около трех дней) большей части продукции. Поэтому для снижения рисков смены ERP был разработан следующий план:

• Релиз 1.1: приемка в новой системе товаров с большим сроком годности
• • ввод в новую ERP только небольшого маломаржинального ассортимента с большим сроком годности
  • интеграция старой и новой ERP
  • возможность принимать товар как через старую WMS, так и через новую ERP/WMS
• Релиз 1.2: размещение принятого товара на хранение с сортировкой по клиентам
• • расширение номенклатуры
  • размещение принятого товара с сортировкой по клиентам (часть функционала кросс-докинга)
• Релиз 1.3: кросс-докинг части ассортимента
• • расширение номенклатуры
  • использование кросс-докинга для отгрузок части ассортимента
• Релиз 1.4: отказ от прежней WMS
• • перевод всего ассортимента на новую ERP/WMS
  • работа офиса в прежней ERP с выполнением складских операций в новой ERP/WMS
  • перевод всех складских процессов на новую ERP/WMS
  • тюнинг

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

Второй релиз: переход на кросс-докинг

Предполагается, что функционал кросс-докинга уже частично готов за счет предыдущего этапа. План работ предполагается следующим:

• Релиз 2.1: кросс-докинг для части ассортимента и части маршрутов
• • при прибытии поставок синхронно с машинами на отгрузку, соответствующая часть ассортимента перегружается с машины на машину, задания на перегрузку формирует новая ERP
• Релиз 2.2: кросс-докинг и поставка Just-in-time
• • новая ERP управляет планированием прибытия как машин с производства, так и машин на доставку клиентам
  • новая ERP минимизирует использование склада, товар перегружается напрямую с машины на машину
• Релиз 2.3: минимизация склада
• • новая ERP управляет планированием всех поставок
  • сокращение складских площадей за счет кросс-докинга значительной части продукции
  • тюнинг

Третий релиз: оцифровка производства

Релиз может формироваться параллельно другим работам при наличии ресурса и заказчика и исполнителя. План работ:

• Релиз 3.1: оцифровка части сырья
• • под часть оборудования поступающее сырье вносится в новую ERP (сейчас в старую ERP вносят через сутки, первоисточники в Excel и на бумаге)
  • настроены рецепты (BoM, спецификации производства) данной продукции в новой ERP
  • часть оборудования интегрировано с новой ERP
• Релиз 3.2: оцифровка производства
• • расширен ассортимент
  • для оцифрованной части производства настройка возможно только через ERP с указанием мотивации корректировки рецептов
  • учет выпускаемой продукции (для оцифрованной части производства)
  • учет выбраковки
  • учет утилизации сырья
  • оцифровано планирование производства части ассортимента
• Релиз 3.3: оцифровка выпуска продукции
• • перевод всего ассортимента на выпуск через новую ERP
  • первоисточником выпуска продукции становится новая ERP
  • первоисточником выбраковки и утилизации продукции и сырья становится новая ERP
• Релиз 3.4: оцифровка планов производства
• • снижение потерь при производстве (предполагается наличие 10-15% избыточных потерь, поддающихся сокращению)
  • расчет загрузки всего производства автоматизирована
  • расчеты выполняются на основании плана продаж
• Релиз 3.5: интеграция с РЦ
• • планирование отгрузок производства на склад/РЦ автоматически согласовано с планом маршрутов клиентам с РЦ
  • тюнинг

Четвертый релиз: автоматизация транспортной логистики

По готовности склада и производства стартует повышение автоматизации формирования маршрутов доставки к клиентам. План работ:

• Релиз 4.1: автоматизация маршрутов поставки с производства
• • часть функционала пересекается с Релизом 2.2, но акцент на формировании плана отгрузок с производства
  • автоматизация создания части маршрутов
• Релиз 4.2: оцифровка планов поставок от партнеров
• • часть функционала пересекается с Релизом 2.3, но акцент на учете в планируемых маршрутах планов по поставкам от партнеров
  • расширение числа автоматически планируемых маршрутов новой ERP
• Релиз 4.3: оцифровать работу водителей
• • корректировки при проверке поставок клиентами
  • начало маршрута, конец маршрута, промежуточные точки
  • автоматизировать начисления водителям (доход за маршруты, оплата безнина по нормативам)
• Релиз 4.4: исключение человеческого фактора планирования маршрутов
• • все маршруты формируются ERP
  • корректировки возможны только с указанием причин
  • доработка алгоритмов при высокой доле ручных правок
  • тюнинг

Пятый релиз: автоматизация интеграций с клиентами и поставщиками

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

• Релиз 5.1: сократить в 2-3 раза ФОТ группы сопровождения мелких клиентов
• • более 90% заказов мелких клиентов формируется самостоятельно через Интернет-магазин
  • оплата и доплата моментально при доставке (QR, картой)
  • минимизировать работу водителей с наличными
• Релиз 5.2: сократить вдвое ФОТ группы сопровождения крупных и средних клиентов
• • более 90% заказов средних и крупных клиентов выполняется через EDI или eCom
  • портал с личным кабинетом для сверки, просмотра статуса заказов и отгрузок, оформление претензий, просмотр истории взаимодейтствия
• Релиз 5.3: интеграция с поставщиками
• • автоматическая загрузка приходов из EDI

Выводы

Наибольшие риски для проектов несет попытка перейти на новое решение "одним днем", заранее все обдумав и подготовив. Если считаете, что иначе невозможно - применяйте подходы PMBoK. Проверить, что Вы подготовились можно проанализировав описанные в проекте риски: их количество измеряется сотнями, на каждый есть минимум два сценария: 

• что будет делать команда во избежание срабатывания рисков
• сколько будет стоить каждый сработавший риск, вероятность срабатывания, сценарий действий

Обратите внимание, что число описанных рисков будет измеряться СОТНЯМИ!
При этом количество описанных рисков не гарантирует, что не пропущено значительное количество значимых.
Также, за время реализации проекта компания изменится и часть работы придется переделать - эти риски практически невозможно полноценно предусмотреть и описать.

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

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