Пилотирование что это в бизнесе

Пилотный

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

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

Цель пилотного проекта – минимизация рисков, сокращение времени и затрат на разработку и запуск масштабного проекта.

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

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

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

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

Если пилотный эксперимент прошел успешно, т. если в результате обнаружились не только непредвиденные проблемы, но и неожиданные возможности (особенно связанные с разработкой, рынком или обслуживанием), то риск, связанный с изменением, не слишком высок.

Поделиться

Книга в подарокВнедрение совершенно нового подхода к логистике и управлению запасами может быть пугающе сложной задачей. Наши клиенты, как правило, не могут предвидеть все последствия перехода своей цепи поставок от выталкивания к вытягиванию. Перед тем как окунуться с головой, мы сначала предлагаем с помощью пилотного проекта («пилота») проверить концепцию в небольшом масштабе. Пилот снижает риск из-за уменьшения возможных последствий и создает возможности для получения согласия клиента. В этой статье обсуждается, что можно ожидать от пилотного проекта по внедрению решения Теории ограничений (ТОС) для пополнения запасов. Мы постараемся ответить на вопрос в заголовке и еще на несколько: «Может ли пилот помочь мне экстраполировать преимущества по увеличению продаж, которые разумно ожидать от полного внедрения? Как выбрать правильный набор из наших продуктов для пилота? Как долго должен длиться пилот?». Измерение увеличения продажОдна из главных причин, по которой нужно начинать с пилотного внедрения, это определение на сколько увеличатся продажи в результате полного внедрения решения для пополнения запасов. У нас есть такое эмпирическое правило: рост продаж, как правило, будет на порядок больше, чем измеренный дефицит. Например, если сегодня вы оцениваете дефицит в 3%, внедрение решения ТОС, как правило, увеличит продажи на 30%. Пилот будет работать с подмножеством продуктов клиента. После того как мы будем управлять этой группой наименований (SKU) в течение разумного количества времени, мы просто сравним изменение продаж этих продуктов с остальными товарами, которые продолжают управляться по старинке. Точно так же мы проследим за продуктами, которые продаются клиентам клиента. Предположим, продажи пилотных продуктов выросли в среднем на 19,1% за период тестирования, в то время как продажи остальной части продукции снизились на 4%. Поскольку разница между продуктами заключается только в способе пополнения, мы делаем вывод, что решение ТОС дает увеличение продаж примерно на 23,1%, по сравнению с традиционным подходом. График ниже показывает значение такого изменения для производителя, для которого доля сырья в продажах составляет 45%. Увеличение операционных затрат всего на 2% позволят при новом подходе изготовить на 23% больше продукта. Большая часть дополнительной продукции может быть изготовлена с помощью существующего персонала и оборудования. Наш пилот позволяет сделать вывод, что чистая прибыль должна увеличиться в 2,5 раза. Таблица 1Точно так же, если продуктом является сырье, мы измеряем его уровень доступности. Сколько времени пилотное сырье доступно для следующей стадии производственного процесса по сравнению с остальным сырьем? В большинстве случаев, разница будет гораздо меньше. Вторая измеряемая величина — продолжительность времени простоя для пилотных и остальных наименований. Помните, что потери в результате простоя производства из-за отсутствия сырья или компонентов огромны. Если даже часть завода останавливается, это может привести к потере продаж, пока сырье вновь не будет доступно. В любом случае, если ситуация с пилотными продуктами становится лучше, мы можем предсказать результаты полного внедрения системы вытягивающего пополнения. Знание, что мы можем ожидать, позволяет разумно оценить преимущества, которые система приносит клиентам с точки зрения увеличения продаж или продуктивности. Клиенты, таким образом, получат хорошее понимание одной из выгод, которые они получают от внедрения системы пополнения TOC. Какие продукты включить в пилотДа, это интересный вопрос. Мы хотим выполнить успешный пилотный проект. Это наша цель. Для того, чтобы достичь цели, мы должны убедиться, что ошибки сведены к минимуму. Что свести количество ошибок к минимуму, мы должны выбрать продукты, которые легко реализовать. Потому что если продукты простые, вероятность ошибки меньше. Хорошо. Мы также должны показать, что система может справиться со всеми проблемами, которые она будет испытывать во время полного внедрения. Чтобы выполнить это условие, нам надо выбрать продукты, которые трудно реализовать. Мы ведь ничего не докажем, если не будем решать сложные проблемы. Ой, у нас возник конфликт. Необходимые условия противоположны. Давайте построим Тучу конфликта. Мы верим в принцип ТOC, что каждой системе присуща внутренняя простота. Для определенности, мы не считаем, что конфликты — это норма. Конфликты не существуют в природе. Мы не позволим им существовать и в нашем бизнес-пространстве. Чтобы разорвать этот конфликт, мы сделаем такую инъекцию: решение ТОС для пополнения настолько хорошо протестировано и контролируемо, что любой его элемент может быть обработан без ошибок. Поэтому, даже если мы выберем сложные продукты, риск для клиента гораздо меньше, чем даже продолжить использовать их нынешний подход. Еще до того, как мы доберемся до точки запуска пилота, клиент соглашается, что есть проблемы и нежелательные эффекты в его бизнесе. Пилот — первый шаг к улучшению мира клиента. Теперь за дело. Мы можем и должны выбрать сложные продукты. Но даже когда мы сделаем это, мы по-прежнему должны помнить об обеих потребностях. Однако, при условии, что некоторые из продуктов достаточно сложные, чтобы мы могли доказать, что подход TOC может справиться с чем угодно, мы должны также выбрать продукты полегче. Если какие-либо простые или сложные продукты исключаются из тестовой группы, возможно, и не без оснований, клиент будет утверждать, что ассортимент их продукции слишком отличается от тестовой группы, что не позволит провести корреляцию. Тестовый набор продуктов должен быть достаточно большим, чтобы гарантировать, что примеры большей части продуктов клиента представлены в рамках пилота. Длительность пилотаНе важно, что пилот выжимает всю выгоду из включенных продуктов. 5 фокусирующих шагов ТОС и анализ Парето используются в качестве основных инструментов. Они гарантируют, что наиболее значительные результаты станут видны быстро. Шесть-восемь недель — среднее время пополнения, его достаточно, чтобы увидеть, как идет пилот. Добавьте еще три недели обучения, распределенные по всему пилоту, чтобы получить
согласие на полное внедрение. И если продукты обычно пополняется со склада завода или поставщика в течение 10 дней, три месяца — хороший срок для пилота. Добавьте больше времени, если уверенность в будущем очень важна. В любом случае, не вставайте на путь полного внедрения без четких результатов пилотного проекта. Пилот = ДоказательствоПилот имеет три цели. Во-первых, доказать противникам, что решение ТОС для пополнения позволяет:

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

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

Founder and CEO of IDEA, llc.

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

Вы ведь знаете, что такое пилотирование, правда?

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

Классическими плюсами пилотирования обычно являются:

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

А минусами соответственно:

• Затянутый процесс принятия решения
• Отложенное решение, влияющее порой на
• Удлиненный Time-to-market, если пилот находится на критическом пути.

Пилотирование Enterprise 2. 0 решений, collaboration software и социальных сетей, — тема отдельно стоящая и достаточно тонкая.

Чего вы хотите добиться при обычном пилотировании, и как вы его делаете?

Правильно, вы (если вы умная компания, на что я очень надеюсь) привлекаете к пилотированию лидеров и экспертов. Зачем? Конечно же, для того, чтобы они, освоив новую тему, инструмент, технологию или продукт, смогли быстро, достойно, авторитетно, доступно (добавьте нужное. ) принести это в коллектив, уменьшив риски сопротивления, неприятия в коллективе, увеличив скорость, простоту и качество внедрения.

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

Это же классика управления изменениями 😉

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

Коллектив, — тоже своего рода социальная сеть, просто об этом мало кто думает, и мало кто использует. Социальная сеть здесь означает люди и их связи, отношения (тут не имеется в виду социальная сеть в интернет типа Одноклассники или ВКонтакте).

Итак, в процессе традиционного пилотирования:

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

Вроде ничего такого. Как всегда. Как обычно.

Но как нужно пилотировать Enterprise 2. 0? Как пилотировать социальные сети? В чем их такая замечательная особенность?

Дело в том, что на 80-90% внедрение корпоративных соцсетей или Enterprise 2. 0 решений, — это не технология, а люди.

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

Но здесь есть одно большое НО! Пройдемся по списку результатов пилотирования еще раз:

• Метрики: Метрики соцсети начинают появляться, и становятся значимыми только тогда, когда сеть живет. Живет полной жизнью, и работают законы больших чисел. Это означает, что п.1) традиционной схемы перестает работать.
• Уроки: Уроки пилотирования социальной сети (если речь не идет о пилотировании технологии или технической части решения), — опасно или просто невозможно применять для коррекции планов массового внедрения или прогнозирования будущего. Причины те же. Малая, молодая сеть и большая, зрелая, — это две совершенно разных сети.
• Воздействие при внедрении: Принцип внедрения соцсети с точки зрения теории управления изменениями также отличен от классического. Для того, чтобы пропилотировать сеть (если уж вы такое собрались делать), вам нужно не с лидерами изменений работать. Вам нужно попытаться воссоздать сеть в соотношении 90-9-1 (известный закон соцсети, если будут вопросы, уточню), а это значит, что и принципы формирования команды пилотирования, взаимодействия ее членов, — все это совсем другое. Более того, промышленное расширение соцсети, — это рост по всем параметрам, это не перенос экспертизы участников пилотирования, что означает опять же невозможность делать прогнозирование будущего, и использовать результаты пилотирования для планирования внедрения.

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

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

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

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

Так что же делать?

Пилотирование можно и нужно делать в отношении инструмента (collaboration software, ПО, платформа): удобство использования, цена, функционал, TCO (total cost of ownership), простота и удобство интеграции с вашими корпоративными системами, возможности получения аналитической информации (метрики и проч. ), и так далее.

Но если вы собираетесь пилотировать, как будет работать или выглядеть ваша будущая корпоративная социальная сеть (полноценное Enterprise 2. 0 — решение), вы, скорее всего, совершаете ошибку, и просто потратите время и деньги впустую.

Социальную сеть не нужно пилотировать. Ей нужно дать жить и развиваться. Если вы все сделаете правильно, — то сеть вырастет до размеров полноценной, и вы будете получать преимущества, деньги и проч. А если сеть не разовьется, но вот вам и «пилотирование», — уроки на будущее, — что не надо делать, что нужно понять, извлечь, чтобы при промышленном внедрении, в следующий раз у вас что-то получилось.

Читайте, впитывайте, думайте, решайте.

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

И, как обычно, вы или (назначенный вами или кем-то там) менеджер проекта будете рисовать план. Цели там, задачи, сроки, ну как обычно.

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

Скорее всего, все будет как обычно, и вы попадете в статистику тех, про кого пишут «Their E2. 0 initiatives did not start from broad adoption (they were more pilot based)».

Ну ничего страшного. Если что, вы знаете, к кому обращаться.

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

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

Этапы ввода пилота в эксплуатацию

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

Этап подготовки включает:

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

Этап построения включает:

• настройку схемы сбора логов,
• подключение всех источников событий,
• модернизацию схемы сбора событий ИБ,
• использование каталога use-case в соответствии с заданием.

Этап запуска включает:

• работу с use-case, переданными в эксплуатацию;
• уведомления об инцидентах.

Для чего нужен SOC и какие особенности при выборе сервис-провайдеров учитывать?

Типовые ошибки при пилотировании и как их избежать

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

Слишком сложный сценарий для пилота

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

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

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

Неготовность проводить пилоты с несколькими провайдерами сразу

В рамках тендеров крупные заказчики обычно пилотируют двух-трех сервис-провайдеров. И иногда они сами не знают, как работать одновременно с несколькими участниками. У каждого участника может быть своя SIEM-система, и форматы данных между ними могут быть несовместимы.

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

Если у компании мало ресурсов, мы советуем не пилотировать несколько провайдеров. На выходе компания может получить огромное количество инцидентов и непонимание, как на них реагировать.

Задержки по времени из-за взаимодействий исполнителя с ИТ- и ИБ-командами заказчика

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

На этапе подготовки пилота мы разделяем источники событий по ответственным группам и всегда прописываем, кто является основным контактом на стороне заказчика и сервис-провайдера; с кем можно связаться, если основной контакт недоступен; на кого можно эскалировать, если у заказчика многоуровневая структура.

Инфраструктура заказчика оказывается не готова к внедрению SOC

Во время пилота могут выявляться различные недочеты. Например, у заказчика отображается большое число пользователей, потому что он забыл удалить из системы часть бывших сотрудников. С точки зрения ИБ это может представлять угрозу.

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

Нет команды реагирования

Заказчик может внедрить SOC, но не подготовить группу реагирования, которая будет устранять инциденты. Из-за этого работа SOC теряет смысл.

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

Риск-ориентированный подход при внедрении SOC

Наша методология внедрения сервиса SOC основана на риск-ориентированном подходе. Такой подход позволяет адекватно оценивать рентабельность вложений в ИБ. Если потенциальный финансовый ущерб компании от хакерской атаки составляет 100 000 ₽, а техническое средство защиты стоит 100 000 €, то вкладываться в него нет смысла и нужно искать другое решение.

Риск-ориентированный подход состоит из трех этапов.

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

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

Такой подход выявляет актуальные риски для вашей компании и оценивает потенциальные финансовые потери. Это позволяет определить наиболее эффективные меры минимизации рисков.

SOC Orange Business Services в России построен по принципам глобальной команды Orange Cyberdefense

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

Наш SOC организован в Москве и построен на базе SIEM IBM Qradar, которое обладает широкими возможностями по масштабированию и разделению данных разных систем на одной масштабируемой системе, что очень важно для нас как для MSSP-провайдера.

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

В портфеле Orange Business Services собственная база Threat Intelligence и AI/ML-системы для компании Lexsi (стала частью Orange Business Services в 2016 году) и SecBi (стартап, в который мы инвестировали на раннем этапе развития).

Узнайте о нашем CyberSOC

Книга в подарок

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

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

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

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

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

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

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

Вот основные факторы при разработке правильного пилота:

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

Предложение для планирования пилота:

Определение априори показателей выполнения и правил принятия решений, чтобы понять, стоит ли внедрять концепцию в полном объеме после завершения пилота.

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

• Улучшение наличия товара не приведет к значительному улучшению продаж:
  Например, поскольку клиенты всегда имеют разумные альтернативы.Или, потому что короткие позиции не являются ходовыми.
• Например, поскольку клиенты всегда имеют разумные альтернативы.
• Или, потому что короткие позиции не являются ходовыми.
• Новые уровни запасов, а также их влияние на денежные потоки, могут быть по-прежнему высокими, может быть, даже выше, чем сейчас.
• Транспортные расходы вырастут.
• Возникнут новые трудности при загрузке грузовиков очень малыми партиями товаров множества SKU.
• Привыкание к новым программным продуктам и их внедрение во многих местах займет много времени, вызывая проблемы в ежедневном управлении и тем самым нанося ущерб производительности.

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

Как следует выбирать такой пилот?

Есть несколько возможных вариантов для реализации:

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

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

Я хочу выразить свою собственную точку зрения на представленные выше варианты для пилотного проекта в цепи поставок.

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

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

Фокусировка внимания на ряде регионов вызывает две различных негативные ветви. Одна из них: до тех пор, пока центральный склад не может обеспечить быструю и надежную реакцию на запросы регионов, наличие товара в регионах находится под вопросом, что снова приводит к разочарованию. Другая отрицательная ветвь: регионы пилота могут потребовать и получить особое внимание. Это может привести к хорошим результатам пилота, но вызовет огромное сопротивление во всех других частях организации, потому что им придется работать в более жестких условиях.

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

Я надеюсь, что этот пост поднимет обсуждение проблем в основе планирования пилотных проектов в различных решениях ТОС.

Читайте, где удобно

Eli Schragenheim,
CEO of Elyakim Management Systems (1992) Ltd