Любое изменение, даже то, которое обещает большие выгоды, включает в себя беспокойства за то, что что-то может пойти не так. Слишком часто нет никаких практических путей доказать, что такое беспокойство либо очень просто разрешимое, либо оно слишком мало по сравнению с выгодами. Также, есть беспокойство из-за неизвестности, которую мы даже не можем себе даже представить. Даже выгоду бывает трудно перевести в то, сколько она добавит к цели.
Доказательство правильности концепции (Proof-of-concept = POC) является общим термином для обеспечения логического подтверждения того, что концепция работает. Теоретически, хорошее Дерево будущей действительности (ДБД) может обеспечить такое доказательство, но оно может быть недостаточно хорошим для устранения всех беспокойств, в особенности – опасения неизвестности.
Более надежным способом РОС является симуляция (моделирование). Тем не менее, это требует особой осторожности в использовании исходных предпосылок, являющихся справедливыми для реальности, в которой рассматривается концепция. Нетривиально проверять предпосылки в компьютерной симуляции, разработанной другими людьми. Первая категория предпосылок, которая должна быть тщательно проверена – это поведение в условиях неопределенности. Другим важным аспектом является определение реальных эффектов, которые не были включены в симуляцию. Например, большинство симуляций не учитывают таких поведенческих аспектов человека, как закон Паркинсона.
Самый надежный способ доказательства концепции – это запуск пилота. Пилот должен дать более полное представление о ценности и выявить негативные ветви и их влияние, обеспечивая возможность «обрезать» или уменьшить негативное воздействие.
Пилот доставляет значительные хлопоты. Внимание менеджмента уделяется больше обычного в таком проекте. Все пилоты нацелены на доказательство концепции. Это, на самом деле, указывает на самую первую задачу планирования пилота: определение концепции, которую необходимо доказать и ее выгоды, включая оценку снижения степени неопределенности благодаря пилоту.
Например, давайте рассмотрим случай выбора проекта в качестве пилота для доказательства концепции CCPM. Концепция направлена на то, чтобы завершать проекты вовремя, предпочтительно раньше реалистичных ожиданий. Концепция CCPM включает планирование Критической цепи, сокращение времени выполнения задач и размещения буферов в основном буфера проекта. При поэтапном использовании управления буфером как единственный механизм приоритетов – ключевой инсайт. Выбор конкретного проекта должен справляться с сомнением о том, что своевременная сдача проекта произошла либо вследствие особого внимания к нему, либо вследствие того, что хороший результат – это случайность.
Важно осознавать то, что пилоты необходимо осуществлять только когда есть глубокое убеждение в том, что концепция несет значительную ценность, но также может нанести ущерб.
Основными факторами при разработке правильного пилота являются:
- Быть способным значительно уменьшить потенциальный ущерб от полного внедрения концепции.
- Получение достоверной информации о ценности (результативности) полного внедрения.
- Требует незначительного особенного внимания менеджмента.
- Ограниченные инвестиции в пилот.
- Ограниченные хлопоты для всей организации. Влияние пилота на ежедневное управление и эффективность всей организации должно быть относительно низким.
Предложение по планированию пилота:
Определите априорные показатели эффективности и правила принятия решений, чтобы понять, внедрять ли концепцию после завершения пилота.
Беспокойство тут следующее: если показатели и правила для такого решения не определены до внедрения пилота, есть высокая вероятность того, что ни одно решение не будет принято. И, стало быть, ситуация, которая привела к пилоту (конфликт между уверенностью в результате и сомнениями из-за рисков) будет и дальше иметь место.
Ключевой случай для пилота при внедрения ТОС для дистрибуционной цепи. Масштаб полного внедрения, которое покрывает широкую географическую зону, много региональных складов и огромное количество розничных точек, требует отказа от ряда текущих правил и перехода к динамическим решениям ТОС, дается очень тяжело. Давайте просто констатируем обоснованные сомнения топ-менеджеров:
· Улучшенное наличие не приведет к значительному улучшению продаж.
- Например потому, что у клиентов есть разумная альтернатива.
- Или потому, что «короткие» позиции не являются хорошо продающимися.
· Полученный в результате уровень запасов может остаться достаточно высоким (или стать даже выше, чем сейчас) с негативным влиянием на денежный поток.
· Транспортные расходы могут возрасти.
· Могут возникнуть новые трудности в загрузке транспорта маленькими партиями большого количества SKU.
· Привыкание к новым модулям программного обеспечения и внедрение их на большом количестве участков займет много времени и вызовет проблемы в ежедневном управлении, тем самым нанеся вред результату компании в целом.
Эти сомнения вкупе с большой надеждой на достижение решающего конкурентного преимущества (значительно улучшенное наличие при более низком уровне запасов) приводят к необходимости реализовать пилот для доказательства концепции.
Как следует сконфигурировать такой пилот?
Есть несколько вариантов для рассмотрения:
- Начните с внедрения решения на центральном складе, но подождите с региональными складами.
- Сфокусируйтесь на 3-4 региональных складах.
- Выберите одну семью продуктов, включающую как быстрые, так и медленные позиции, покрывающие весь путь от центрального склада до нескольких, или даже всех регионов.
Вопрос определения характеристик хорошего пилота – это один из наиболее важных открытых вопросов во внедрениях ТОС. Я настоятельно рекомендую TOCICO пригласить несколько известных ТОС экспертов для публичного обсуждения на следующей ежегодной TOCICO конференции.
Я хотел бы выразить свою собственную точку зрения на вышеописанные характеристики пилота для дистрибуции.
Эффективность решений пополнения зависит от поддержания стабильного и гибкого потока согласно четкого набора приоритетов во всей цепи поставок. Отношения с поставщиками должны быть заново тщательно продуманы для поддержания максимально возможно частого и быстрого пополнения. Количество разных поставщиков создает не меньшие трудностей, чем те, которые создаются огромным количеством мелких торговых точек. Это часть всеобъемлющего внедрения для обеспечения роста через поставщиков и розницу.
Чего пилот не может себе позволить, так это вызвать разочарование своими результатами. Внедрение пилота только на центральном складе создает негативное восприятие того, что это только часть от полного конечного процесса. В регионах будут продолжать заказывать большое количество товара, основываясь на своем локальном восприятии цепи поставок, и заставляя центральный склад содержать высокие запасы. Это может легко вызвать разочарование результатами и «убиение» всего внедрения.
Фокусирование на нескольких регионах приводит к двум разным негативным последствиям. Одно из них следующее: до тех, пор пока центральный склад не может обеспечить быструю и надежную реакцию регионам, наличие в регионах становится сомнительным, что снова приводит к разочарованию. Суть второго опасения состоит в том, что регионы, участвующие в пилоте, могут требовать и получать особое внимание. Это может привести к хорошим результатам пилота, но вызвать большое сопротивление других частей организации из-за того, что им придется иметь дело с более жесткими условиями.
Таким образом, я отдаю предпочтение запуску пилотного проекта на одном семействе продуктов, включая это семейство продуктов на центральном складе и во всех регионах. Я не вижу острой необходимости идти в розницу в рамках пилота, особенно к тем, которые управляются другой организацией. Результат пилота – это некоторое снижение общих запасов на центральном складе плюс в регионах, и, при этом, обеспечение отличного наличия. Розница по-прежнему может продолжать заказывать партиями, но количество розничных продаж снизит негативное воздействие от этих партий. Опыт приведет к лучшему пониманию реального воздействия на транспортные затраты и на загрузку транспорта, даже если большинство грузовиков будут возить позиции, не являющиеся частью пилота.
Я надеюсь, что эта публикация поднимет вопросы конфигурирования и реализации пилотов ТОС для различных ТОС-приложений.
Перевод осуществлен компанией Apple Consulting®
Фото автора
вул. Велика Васильківська, 9/2,
бізнес-центр "Макулан", оф. 8,
01024, Україна, м. Київ
info@applecons.com.ua
2002-2024. Всі права захищені