Оптимизация рабочих процессов для ритейла — тема далеко не новая. Наличие у российского ритейлера комплексной отчетности или автоматизированной WMS (системы управления складом) сегодня уже не выглядит чем-то необычным. Ведь на данный момент главный показатель прогрессивного уровня фирмы, особенно в сфере услуг и продаж, — сочетание скорости предоставления услуги и ее качества. Оптимизация работы магазина позволяет добиться высокого уровня обслуживания и его максимальной эффективности.
Чтобы торговая точка продолжала развиваться и приносила прибыль, ритейлерам необходимо автоматизировать внутренние процессы. Какие именно — разберемся со специалистами «Клеверенс».
Никита Григорьев
Эксперт по мобильной автоматизации компании «Клеверенс»
Учет и распределение товаров
Почти половина всех усилий сотрудников магазинов уходит на получение, учет и распределение товаров, а также на обновление цен и пополнение запасов. Это отнимает много времени и сил, что не может не сказываться на общей скорости обслуживания.
ДМИТРИЙ ПОТАПЕНКО: Розничная сеть. Создание. Развитие
Чтобы сократить время, затрачиваемое на эти процессы, владельцам магазинов следует инвестировать средства в системы, которые автоматически и полуавтоматически выставляют товары на полки, обновляют цены и упрощают пополнение запасов. Кроме того, автоматизация товароучетных бизнес-процессов увеличивает пропускную способность магазинов и дает возможность отслеживать продукцию в разрезе характеристик, серий или сроков годности.
Управление складской логистикой
Для эффективной работы магазина также важны налаженная приемка товара , точное распределение и достоверный учет товаров на складе. Плюс э ти процессы должны быть оперативны. При ручном выполнении данных функций может существенно тормозиться работа всего предприятия. Кроме того, может возникнуть потребность в привлечении дополнительного персонала.
Ограниченная скорость работы не автоматизированного хранилища может также привести к финансовым потерям из-за простоя продукции.
Внедрение мобильных технологий учета поможет исключить риски возникновения этих и других проблем. Мобильная автоматизация позволяет повысить скорость инвентаризации, упростить резервирование товара и анализ его доступности на складах, улучшить контроль количества полученных и отправленных позиций и, вместе с тем, дать высокую производительность трудового процесса в целом. При этом не обязательно внедрять дорогостоящую WMS-систему.
На самом деле 90% компаний такой сложный аппаратный комплекс не нужен, да и поддержка сложной системы порой стоит несколько бюджетов на ее создание. Подробнее о том, что нужно большинству компаний по автоматизации мы обсуждали с Андреем Галактионовым – генеральным директором компании «Виант».
Процесс продаж
Скорость продаж и качество обслуживания — главный фактор, определяющий лояльность клиента.
По опыту клиентов компании «Клеверенс» возможность быстро совершить покупку оказывает значительное влияние на то, как клиенты видят ритейлера. Это подтверждает и исследование Epson — для 56% людей быстрая оплата и сокращение очереди имеют решающее значение для позитивного восприятия бренда.
Бизнес-процессы в рознице
«Никто не любит ждать. Сегодняшние покупатели все чаще ожидают, что обслуживание будет мгновенным. Качество продукта и отличный сервис — два основных параметра потребительского опыта. 85% потребителей отказываются от покупки, если им не нравится обслуживание. Ритейлеры просто не могут позволить себе игнорировать влияние длинных очередей как на доходы компании, так и на лояльность бренда» — Никита Григорьев, эксперт «Клеверенс».
Если место для кассового узла найти сложно, и к тому же есть желание сэкономить на дорогостоящем оборудовании, то решение от компании «Клеверенс» — «Магазин 15» с мобильной операцией «Продажа» — может серьёзно разгрузить кассы магазина. Решение позволяет полностью обслуживать покупателя в торговом зале, не заставляя идти на кассу для оплаты покупки.
Решение состоит из терминала сбора данных или смартфона с программой «Магазин 15» с подключенной по Bluetooth мобильной кассой и терминалом безналичных оплат. Имея в магазине такой комплект, консультант может во время диалога с покупателем на месте произвести расчет, выдать фискальный чек и учесть персональную скидку.
Качественное и простое в использовании оборудование и ПО может предложить компания «Клеверенс». Их продукция доступна и понятна для пользователя, настройка также очень проста. «Клеверенс» предоставляет множество вариантов оборудования и софта, которые подойдут конкретно вашему бизнесу. Компания вот уже 15 лет создаёт программы для автоматизации. Специалисты найдут оптимальный способ для решения бизнес-задач в розничной и оптовой торговле, производственных организациях, нефтедобывающих компаниях, а также в государственном секторе. Главная цель компании — упростить решение технических задач, снять максимум ограничений и предоставить в итоге наиболее укомплектованное и гибкое решение .
Источник: hussle.ru
Процессный подход на цыпочках, или как выстроить процессы в крупном ритейле
Привет! Меня зовут Александр Гумановский, и я строю архитектуру бизнес-процессов в компании Hoff Tech. Мы разрабатываем удобные решения для One Retail, а один из наших ключевых клиентов — сеть гипермаркетов мебели и товаров для дома Hoff.
Процессный подход последнее время набирает популярность, и о нем говорят едва ли не на каждом углу. В этом тексте речь пойдет не о преимуществах или недостатках концепции (таких статей уже много на Хабре). Я расскажу о реальном опыте внедрения подхода на примере Hoff Tech — со всеми трудностями и неудачами, но и, конечно, с успехами. Обо всем этом под катом.
Что такое процессный подход
Суть процессного подхода заключается в том, что функционирование организации рассматривается как цепочка взаимосвязанных процессов, необходимых для выпуска продукции, предоставления услуг, которые приносят ценность клиентам. Таким образом, в результате управления организацией оценка функциональных подразделений сама по себе теряет приоритет и происходит в связке с оценкой показателей самого бизнес-процесса.
Другими словами, каждое подразделение может по отдельности выкраивать рукава, пришивать пуговицы и так далее, а в итоге костюм не подходит потребителю, не «сидит». А вот оценка от результата — удобно сидящего костюма и довольного клиента — это тот показатель, что можно и нужно оценить в самом процессе и деятельности каждого его участника.
Управление бизнес-процессами имеет две составляющие:
Первая — это описание процессов, действия, преобразующие входы в результаты, которые в конечном итоге приносят ценность потребителям.
Вторая — то, как компания подходит к самому управлению процессами. Как планирует, разрабатывает, внедряет, мониторит показатели и оптимизирует процесс, а затем, на основе полученных данных, вновь планирует, разрабатываети внедряет. И так далее.
Постоянное совершенствование — важная часть процессного подхода.
Hoff Tech на старте внедрения процессного подхода
Я пришел в Hoff Tech полтора года назад, и к моему приходу сложилась интересная ситуация: уже было понимание важности процессов, были сильные подразделения аналитиков, и компания была сосредоточена именно на системном анализе.
Существовало огромное количество инструкций, памяток, и нередко они дублировали информацию или противоречили друг другу. Сами процессы были частично выделены, но чаще нет: была описана просто функциональность, без построения моделей процессов, не было единых цепочек. Проблема состояла в том, что каждый знает свою функциональность, но полной картины никто не видит, даже высокоуровнево.
Когда меня приглашали в Hoff Tech, задачей было устранить этот перекос и начать от разрозненных процессов и инструкций выстраивать единую процессную архитектуру с единым репозиторием, строить взаимосвязанные цепочки процессов и организовать единое управление процессами.
Компания начала преобразования, и мы идем по этому длинному пути на цыпочках, шаг за шагом, преодолевая сложности и периодически сталкиваясь с проблемами, но продолжаем медленно, но верно двигаться вперед.
Первые шаги и первые сложности
Поначалу основной задачей был пересмотр классификатора процессов. В компании уже был предварительно создан классификатор, но там смешались и процессы, и функции, не были определены владельцы и менеджеры.
Поэтому сначала вместе с подразделением бизнес-анализа мы начали делать единый костяк — классификатор процессов, определять владельцев процессов и распределять аналитиков, которые отвечают за тот или иной процесс. То есть при построении классификатора мы ориентировались на опыт и знания бизнес-аналитиков. Аналитики в Hoff Tech выделены под различные направления бизнеса и практически интегрированы в бизнес-подразделения. При этом у них налаженная коммуникация внутри департамента.
Со стороны отдела процессной архитектуры мы определили правила выделения процессов, выстраивали классификатор и контролировали рамки. Предполагалось, что всё это мы покажем стейкхолдерам и руководству бизнеса, и вместе с ними согласуем костяк.
Может возникнуть закономерный вопрос: почему на этапе разработки мы не привлекли бизнес, а положились только на ресурсы департамента бизнес-анализа? Но, как часто бывает, бизнес не был готов тратить время на определение и выделение процессов, так как «нужно делать клиентов счастливыми». Коллеги готовы участвовать в изменениях процессов уже операционного уровня, который сразу принесет эффект. Мы же только закладывали фундамент, без которого не получится построить и развивать процессную архитектуру.
Пересмотр стратегии
В результате мы отказались от идеи согласовывать классификатор с бизнесом, а потом приступать к моделированию процессов. Бизнес нацелен на проекты и готов смотреть, какие требуются процессы под конкретную цель компании, и не готов тратить время на огромную иерархическую модель (смотреть, все ли процессы выделены).
Так мы стали использовать другой подход:
- смотрели на существующие или запланированные проекты;
- определяли процессы, которые необходимы для реализации проекта из классификатора процессов или добавляли их туда, если они отсутствовали;
- определяли кроссфункциональные процессы и цепочку создания ценности;
- подтверждали у бизнеса выделенные процессы и их место в классификаторе.
Затем аналитики описывали эти процессы, автоматизировали их и согласовывали с бизнесом.
Это не классический подход к процессному управлению. Это как раз медленное последовательное внедрение «снизу», учитывая нужды бизнеса, существующую процессную зрелость компании и при этом не отказываясь от цели создать процессную архитектуру и внедрить процессное управление в компании. В нашем случае этот способ сработал.
Сейчас у нас выделено около 800 процессов. При этом мы больше сосредоточены на основных процессах, которые влияют на клиента, — это продажи, логистика и обслуживание.
Одна из сложностей, с которой мы сталкиваемся, в том, что многие проекты запущены раньше, чем мы начали работу с процессами. И складывается ситуация, когда разработка уже ведется, а процесс становится лишь вторичной составляющей.
Например, существует процесс в рамках системы обслуживания клиентов. Он содержит в себе несколько возможных веток развития — в зависимости от типа обслуживания. При его описании и автоматизации мы проработали только один тип обслуживания, а вторую ветку не разобрали, потому что заказчик был заинтересован только в своей части. Остальные смежные процессы и требования его не очень интересовали, да они и не были определены, так как мыслили функционально, а не процессно.
При этом, обладай мы полной картиной, решение получилось бы универсальным и, возможно, закрыло бы потребность других стейкхолдеров с меньшими трудозатратами. В итоге на выходе одну часть мы автоматизировали, а вторая так и осталась в ручной обработке.
И это ставит весь проект под вопрос: без полных требований по межпроцессному взаимодействию и запросов стейкхолдеров, без анализа требований на основе процесса — достиг ли проект своей цели полностью, правильно ли было принято решение, основанное на неполных данных?
В итоге мы описали и автоматизировали и вторую ветку, но если бы процесс описывался изначально, а не постфактум, мы могли бы сразу разработать единое архитектурное решение, и это было бы дешевле, чем несколько доработок, несколько разных дополнительных автоматизаций. Это вопрос полноты данных и неизбежности человеческого фактора.
Первые результаты внедрения процессного подхода
С другой стороны, есть удачный опыт, когда начали именно с модели процесса. Компания запускала новые продажи корпоративным клиентам. Было важно не только как заключается договор, как мы продаем, но и как организована работа, связанная с оплатой и контролем дебиторской задолженности.
Наша команда сформировала верхнеуровневый процесс жизненного цикла этого клиента, определила межпроцессное взаимодействие и обсудила все это с бизнесом. После обсуждения жизненный цикл немного скорректировался, мы подтвердили у бизнеса правильность выделения процессов, определили границы, показатели и приоритетность разработки процессов.
Позже, в соответствии с выделенным приоритетом, мы разработали детальные модели процесса. На основе первой модели разобрали, что не так, собрали вместе с бизнесом аналитику, а затем предоставили новую модель, новый дизайн процесса и вариант его автоматизации.
Может показаться, что это более долгий путь, чем описание и оптимизация уже разработанной в проекте автоматизации. Но в действительности сбор полной информации, уточнение требований, разработка «наживую» и последующие доработки, по нашему опыту, отнимают больше времени и ресурсов, чем полноценная разработка процесса и сбор требований с последующей поэтапной разработкой и запуском. То есть мы не ждем, когда все сразу автоматизируем, мы запускаемся поэтапно, но целевой процесс у нас есть, и есть понимание целевой архитектуры. И продажи по новой схеме уже идут.
Еще пример. У нас есть отдел бизнес-процессов маркетплейса. Бизнес пришел к ним с запросом решить текущие проблемы маркетплейса. Аналитики пошли следующим путем: сперва выстроили по маркетплейсу жизненный цикл товара — от заказа до продажи и доставки, на эту модель наложили проблемы и вместе с бизнесом начали анализировать причины проблем и точки их возникновения.
То есть первоначально была выстроена высокоуровневая модель, которая дала понимание взаимодействий по процессам и показала участки цепочек, на которых возникают проблемы. Это пример классического подхода: найти источник и причины проблемы, а потом ее устранить, а не «тушить пожары», думая, что таким образом устраняем проблему. В итоге, мы смогли повысить индекс качества поставщика на 10%, что изначально было целью проекта.
Но бывает и иначе. Например, возникает точечная проблема, но бизнес не готов ждать проработки, решение нужно сейчас. Случился «пожар», его нужно потушить и работать дальше. Это приводит к возникновению «заплаток», дополнительных контрольных действий, но причины инцидента не выяснены и не устранены, а это значит, что «пожар» может возникнуть вновь и компания опять потратит ресурсы на его «тушение». В таких случаях бизнес приходится убеждать выделить ресурсы на тщательное исследование проблемы, построение модели и исключение причин на уровне процесса.
Вот еще один пример разработки процессов, который дал положительный эффект. К нам обратился бизнес с просьбой описать приемку товара от поставщиков на внешних складах. В Hoff несколько таких складов в разных регионах. Они оснащены одинаковым оборудованием и используют единую IT-систему. Изначально в компании были памятки и инструкции по приему товара на складе, но они не давали полную взаимосвязанную картину последовательности выполнения и отклонений.
Была определена цель разработки процесса, бизнес-аналитик предварительно организовал рабочую группу, в которую вошли владелец процесса, менеджеры процесса и эксперты с различных складов и подразделений. Сначала провели сбор данных, интервью, после чего сделали предварительную модель. Выяснилось, что при одних и тех же инструкциях, оборудовании и IT-системах часть складов работают по-своему. Также обнаружили дублирующие артефакты, дополнительную ручную работу.
Процессный подход на цыпочках, или как выстроить процессы в крупном ритейле
Привет! Меня зовут Александр Гумановский, и я строю архитектуру бизнес-процессов в компании Hoff Tech. Мы разрабатываем удобные решения для One Retail, а один из наших ключевых клиентов — сеть гипермаркетов мебели и товаров для дома Hoff.
Процессный подход последнее время набирает популярность, и о нем говорят едва ли не на каждом углу. В этом тексте речь пойдет не о преимуществах или недостатках концепции. Я расскажу о реальном опыте внедрения подхода на примере Hoff Tech — со всеми трудностями и неудачами, но и, конечно, с успехами.
Что такое процессный подход
Суть процессного подхода заключается в том, что функционирование организации рассматривается как цепочка взаимосвязанных процессов, необходимых для выпуска продукции, предоставления услуг, которые приносят ценность клиентам. Таким образом, в результате управления организацией оценка функциональных подразделений сама по себе теряет приоритет и происходит в связке с оценкой показателей самого бизнес-процесса.
Другими словами, каждое подразделение может по отдельности выкраивать рукава, пришивать пуговицы и так далее, а в итоге костюм не подходит потребителю, не «сидит». А вот оценка от результата — удобно сидящего костюма и довольного клиента — это тот показатель, что можно и нужно оценить в самом процессе и деятельности каждого его участника.
Управление бизнес-процессами имеет две составляющие:
Первая — это описание процессов, действия, преобразующие входы в результаты, которые в конечном итоге приносят ценность потребителям.
Вторая — то, как компания подходит к самому управлению процессами. Как планирует, разрабатывает, внедряет, мониторит показатели и оптимизирует процесс, а затем, на основе полученных данных, вновь планирует, разрабатываети внедряет. И так далее.
Постоянное совершенствование — важная часть процессного подхода.
Hoff Tech на старте внедрения процессного подхода
Я пришел в Hoff Tech полтора года назад, и к моему приходу сложилась интересная ситуация: уже было понимание важности процессов, были сильные подразделения аналитиков, и компания была сосредоточена именно на системном анализе.
Существовало огромное количество инструкций, памяток, и нередко они дублировали информацию или противоречили друг другу. Сами процессы были частично выделены, но чаще нет: была описана просто функциональность, без построения моделей процессов, не было единых цепочек. Проблема состояла в том, что каждый знает свою функциональность, но полной картины никто не видит, даже высокоуровнево.
Когда меня приглашали в Hoff Tech, задачей было устранить этот перекос и начать от разрозненных процессов и инструкций выстраивать единую процессную архитектуру с единым репозиторием, строить взаимосвязанные цепочки процессов и организовать единое управление процессами.
Компания начала преобразования, и мы идем по этому длинному пути на цыпочках, шаг за шагом, преодолевая сложности и периодически сталкиваясь с проблемами, но продолжаем медленно, но верно двигаться вперед.
Первые шаги и первые сложности
Поначалу основной задачей был пересмотр классификатора процессов. В компании уже был предварительно создан классификатор, но там смешались и процессы, и функции, не были определены владельцы и менеджеры.
Поэтому сначала вместе с подразделением бизнес-анализа мы начали делать единый костяк — классификатор процессов, определять владельцев процессов и распределять аналитиков, которые отвечают за тот или иной процесс. То есть при построении классификатора мы ориентировались на опыт и знания бизнес-аналитиков. Аналитики в Hoff Tech выделены под различные направления бизнеса и практически интегрированы в бизнес-подразделения. При этом у них налаженная коммуникация внутри департамента.
Со стороны отдела процессной архитектуры мы определили правила выделения процессов, выстраивали классификатор и контролировали рамки. Предполагалось, что всё это мы покажем стейкхолдерам и руководству бизнеса, и вместе с ними согласуем костяк.
Может возникнуть закономерный вопрос: почему на этапе разработки мы не привлекли бизнес, а положились только на ресурсы департамента бизнес-анализа? Но, как часто бывает, бизнес не был готов тратить время на определение и выделение процессов, так как «нужно делать клиентов счастливыми». Коллеги готовы участвовать в изменениях процессов уже операционного уровня, который сразу принесет эффект. Мы же только закладывали фундамент, без которого не получится построить и развивать процессную архитектуру.
Пересмотр стратегии
В результате мы отказались от идеи согласовывать классификатор с бизнесом, а потом приступать к моделированию процессов. Бизнес нацелен на проекты и готов смотреть, какие требуются процессы под конкретную цель компании, и не готов тратить время на огромную иерархическую модель (смотреть, все ли процессы выделены).
Так мы стали использовать другой подход:
- смотрели на существующие или запланированные проекты;
- определяли процессы, которые необходимы для реализации проекта из классификатора процессов или добавляли их туда, если они отсутствовали;
- определяли кроссфункциональные процессы и цепочку создания ценности;
- подтверждали у бизнеса выделенные процессы и их место в классификаторе.
Затем аналитики описывали эти процессы, автоматизировали их и согласовывали с бизнесом.
Это не классический подход к процессному управлению. Это как раз медленное последовательное внедрение «снизу», учитывая нужды бизнеса, существующую процессную зрелость компании и при этом не отказываясь от цели создать процессную архитектуру и внедрить процессное управление в компании. В нашем случае этот способ сработал.
Сейчас у нас выделено около 800 процессов. При этом мы больше сосредоточены на основных процессах, которые влияют на клиента, — это продажи, логистика и обслуживание.
Одна из сложностей, с которой мы сталкиваемся, в том, что многие проекты запущены раньше, чем мы начали работу с процессами. И складывается ситуация, когда разработка уже ведется, а процесс становится лишь вторичной составляющей.
Например, существует процесс в рамках системы обслуживания клиентов. Он содержит в себе несколько возможных веток развития — в зависимости от типа обслуживания. При его описании и автоматизации мы проработали только один тип обслуживания, а вторую ветку не разобрали, потому что заказчик был заинтересован только в своей части. Остальные смежные процессы и требования его не очень интересовали, да они и не были определены, так как мыслили функционально, а не процессно.
При этом, обладай мы полной картиной, решение получилось бы универсальным и, возможно, закрыло бы потребность других стейкхолдеров с меньшими трудозатратами. В итоге на выходе одну часть мы автоматизировали, а вторая так и осталась в ручной обработке.
И это ставит весь проект под вопрос: без полных требований по межпроцессному взаимодействию и запросов стейкхолдеров, без анализа требований на основе процесса — достиг ли проект своей цели полностью, правильно ли было принято решение, основанное на неполных данных?
В итоге мы описали и автоматизировали и вторую ветку, но если бы процесс описывался изначально, а не постфактум, мы могли бы сразу разработать единое архитектурное решение, и это было бы дешевле, чем несколько доработок, несколько разных дополнительных автоматизаций. Это вопрос полноты данных и неизбежности человеческого фактора.
Первые результаты внедрения процессного подхода
С другой стороны, есть удачный опыт, когда начали именно с модели процесса. Компания запускала новые продажи корпоративным клиентам. Было важно не только как заключается договор, как мы продаем, но и как организована работа, связанная с оплатой и контролем дебиторской задолженности.
Наша команда сформировала верхнеуровневый процесс жизненного цикла этого клиента, определила межпроцессное взаимодействие и обсудила все это с бизнесом. После обсуждения жизненный цикл немного скорректировался, мы подтвердили у бизнеса правильность выделения процессов, определили границы, показатели и приоритетность разработки процессов.
Позже, в соответствии с выделенным приоритетом, мы разработали детальные модели процесса. На основе первой модели разобрали, что не так, собрали вместе с бизнесом аналитику, а затем предоставили новую модель, новый дизайн процесса и вариант его автоматизации.
Может показаться, что это более долгий путь, чем описание и оптимизация уже разработанной в проекте автоматизации. Но в действительности сбор полной информации, уточнение требований, разработка «наживую» и последующие доработки, по нашему опыту, отнимают больше времени и ресурсов, чем полноценная разработка процесса и сбор требований с последующей поэтапной разработкой и запуском. То есть мы не ждем, когда все сразу автоматизируем, мы запускаемся поэтапно, но целевой процесс у нас есть, и есть понимание целевой архитектуры. И продажи по новой схеме уже идут.
Еще пример. У нас есть отдел бизнес-процессов маркетплейса. Бизнес пришел к ним с запросом решить текущие проблемы маркетплейса. Аналитики пошли следующим путем: сперва выстроили по маркетплейсу жизненный цикл товара — от заказа до продажи и доставки, на эту модель наложили проблемы и вместе с бизнесом начали анализировать причины проблем и точки их возникновения.
То есть первоначально была выстроена высокоуровневая модель, которая дала понимание взаимодействий по процессам и показала участки цепочек, на которых возникают проблемы. Это пример классического подхода: найти источник и причины проблемы, а потом ее устранить, а не «тушить пожары», думая, что таким образом устраняем проблему. В итоге, мы смогли повысить индекс качества поставщика на 10%, что изначально было целью проекта.
Но бывает и иначе. Например, возникает точечная проблема, но бизнес не готов ждать проработки, решение нужно сейчас. Случился «пожар», его нужно потушить и работать дальше. Это приводит к возникновению «заплаток», дополнительных контрольных действий, но причины инцидента не выяснены и не устранены, а это значит, что «пожар» может возникнуть вновь и компания опять потратит ресурсы на его «тушение». В таких случаях бизнес приходится убеждать выделить ресурсы на тщательное исследование проблемы, построение модели и исключение причин на уровне процесса.
Вот еще один пример разработки процессов, который дал положительный эффект. К нам обратился бизнес с просьбой описать приемку товара от поставщиков на внешних складах. В Hoff несколько таких складов в разных регионах. Они оснащены одинаковым оборудованием и используют единую IT-систему. Изначально в компании были памятки и инструкции по приему товара на складе, но они не давали полную взаимосвязанную картину последовательности выполнения и отклонений.
Была определена цель разработки процесса, бизнес-аналитик предварительно организовал рабочую группу, в которую вошли владелец процесса, менеджеры процесса и эксперты с различных складов и подразделений. Сначала провели сбор данных, интервью, после чего сделали предварительную модель. Выяснилось, что при одних и тех же инструкциях, оборудовании и IT-системах часть складов работают по-своему. Также обнаружили дублирующие артефакты, дополнительную ручную работу.