Конечные результаты проектов

Цель количественной оптимизации цепей поставок — создание выполнимых решений, например расчет объемов заказов на закупку. Ниже мы описываем конкретную форму и механизм реализации таких решений. Прояснение того, какие документы клиент получит по итогам проекта, является важным этапом количественной оптимизации. Кроме того, оптимизированные числовые показатели являются не единственным видом конечных данных. В конечные отчеты следует включать несколько видов конечных данных, например показатели мониторинга информации и ключевые показатели работы руководства (KPI). На практике конечные документы проектов по количественной оптимизации зависят от гибкости системы, которая используется непосредственно для реализации самого проекта. Тем не менее они выбираются по предназначению программы, то есть без учета используемой технологии.

Конечные документы в виде сценариев

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

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

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

За последнее десятилетие большую популярность приобрели приложения с интерфейсом WYSIWYG («что видишь, то и получишь») . Это привело к тому, что многие поставщики ПО для управления цепями поставок попробовали внедрить WYSIWYG в свои системы для планирования и оптимизации цепей поставок. Однако высокая сложность цепей поставок и потребность в программных инструментах в большинстве случаев приводят к провалу подобных систем. Мы по опыту знаем, что простые визуальные системы не могут надлежащим образом учесть сложные нелинейные факторы, связанные, например, с накладывающимися друг на друга ограничениями по минимальному объему заказа (MOQ). Возможности программирования необходимы, потому что в противном случае система не сможет учесть все задачи по управлению цепями поставок.

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

Панели управления для проверки качества данных

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

Заметить ошибки в числовых показателях достаточно легко: например, в файле CSV, экспортированном из ERP , указано, что в запасе есть 42 единицы товара АВС, тогда как веб-панель системы ERP показывает, что в запасе есть всего лишь 13 единиц этого товара. Очевидно, что показатели здесь должны быть одинаковые. Панели качества данных решают такие проблемы просто: полученные данные должны быть в пределах ожидаемого числового диапазона.

Семантические ошибки заметить гораздо сложнее. Большая часть работы во время подготовки данных заключается в поиске и устранении семантических ошибок. Например, поле stockinv в системе ERP может быть задокументировано как наличные запасы. Как следствие, сотрудники, отвечающие за цепи поставок, считают, что данный показатель не может быть отрицательным, потому что если такой товар есть на полках магазина, значит, показатель его количества должен быть положительным. Однако документация системы ERP может быть немного неточной, и данный параметр правильнее было бы назвать доступные запасы, потому что когда нужного товара нет в наличии и клиент размещает задолженный заказ, данный показатель может стать отрицательным, что говорит о том, что несколько единиц товара уже зарезервированы для определенного клиента. В данном примере описана семантическая ошибка: числовой показатель не является неправильным — проблема в его неточной интерпретации. На практике семантические неточности могут привести к множеству ошибок, которые, в свою очередь, приводят к дополнительным расходам в цепях поставок.

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

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

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

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

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

Панели приоритетных решений

Как мы уже видели, только решения, связанные с цепями поставок, можно оценить в количественном отношении. Неудивительно, что одним из ключевых конечных результатов по проектам количественной оптимизации цепей поставок являются панели управления, содержащие все решения, рассчитанные на основе всего потока данных. Такая панель управления может выглядеть, как простая таблица со списком всех товаров и соответствующими объемами, которые необходимо заказать на данный момент. При наличии ограничений по минимальному объему заказа (MOQ) — или любых других ограничений заказа — рассчитанный объем может быть равен нулю до тех пор, пока не будет выполнено соответствующее условие.

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

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

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

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

Прозрачный расчет результатов

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

Под белым ящиком понимается система, полностью прозрачная и понятная с точки зрения пользователей. При таком подходе подчеркивается, что ни одна технология не является прозрачной изначально. Прозрачность достигается специально, она является непосредственно частью проекта по оптимизации. Даже простая линейная регрессия может на практике давать неожиданные результаты. За исключением нескольких уникальных индивидуумов, люди не могут интуитивно представить, как должен выглядеть «ожидаемый» результат работы линейной модели, в которой используется 4 и более факторов. Решение задач в цепях поставок зачастую подразумевает использование десятков, если не сотен переменных. Таким образом, даже простые статистические модели de facto являются «черными ящиками» для сотрудников, занимающихся цепями поставок. При использовании алгоритмов машинного самообучения в соответствии с требованиями количественной оптимизации цепей поставок, пользователи еще меньше понимают, что происходит.

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

Даже самые сложные рекомендации в цепях поставок можно сделать понятными для пользователей за счет простого разложения внутренних вычислений с помощью хорошо подобранных финансовых показателей. Такие показатели могут представлять собой экономические факторы , интуитивно соотносимые с самой рекомендацией. Например, вместо отображения простой таблицы с двумя столбцами, «товар» и «количество», которые необходимы для размещения заказа на закупку, следует добавить еще пару столбцов, данные которых должны помочь принять решение. В таких столбцах можно отобразить текущие запасы, общий спрос за последний месяц, ожидаемое время выполнения заказа, ожидаемые убытки в случае дефицита товара (если не размещать заказ), ожидаемые убытки из-за чрезмерно высокого уровня запасов (риск, связанный с предложенным объемом запаса) и т. д. Эти столбцы предназначены для того, чтобы сотрудники, отвечающие за цепи поставок, могли быстро проверить разумность предложенных объемов заказа. Благодаря таким таблицам сотрудники могут быстро проверить состоятельность рассчитанных показателей, а также обнаружить недочеты в системе, которые нужно будет исправить.

Расширение панелей управления для увеличения прозрачности вычислений — это практически искусство. Создать миллионы числовых показателей несложно, даже если использовать вычислительные ресурсы обычного смартфона. Ежедневное создание 10 показателей, которые чего-то стоят — очень сложная задача. Таким образом, необходимо в первую очередь выбрать около десяти ключевых показателей, которые смогут прояснить рассчитанные решения в цепях поставок. Создание хороших ключевых показателей требует значительных усилий: они не должны быть наивными определениями, которые часто приводят к ошибкам в цепях поставок. Например, даже такой простой показатель, как "закупочная цена единицы товара", может ввести пользователей в заблуждение, если поставщик предлагает скидки в зависимости от объема заказа, то есть если закупочная цена зависит от количества приобретаемого товара.

Стратегические панели

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

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

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

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

Инспекционные панели

Цепи поставок сложны и полны ошибок. Как следствие, процесс устранение ошибок из потока данных представляет собой пугающе сложную задачу. Однако поток данных является стержнем, на котором держатся проекты по количественной оптимизации цепей поставок. Ошибки обработки данных могут появляться где угодно в потоке данных. Самой распространенной проблемой является не использование неправильной формулы, а неоднозначная семантика . Например, в начале потока данных переменная stockinv отражает объем доступных запасов (где отрицательные значения вполне возможны), однако позже та же переменная интерпретируется как наличные запасы (такие значения могут быть только положительными). Разная интерпретация переменной stockinv может привести к большому числу ошибок, начиная с отказов системы (более очевидных и потому менее вредных) до незаметного и повсеместного искажения решений.

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

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

На практике на инспекционных панелях можно ввести код товара или единицы складского учета, по которому объединяются все данные, связанные с этим кодом. Если товары перемещаются по разным локациям, как например, в авиационной промышленности, то инспекционная панель обычно используется для восстановления траекторий их перемещений, так как товары могли перемешаться не только физически, но и по электронными системам. Собрав все данные в одном месте, специалист по цепям поставок может оценить состоятельность информации: можно ли определить, откуда едут доставляемые товары? Соответствует ли перемещение товаров официальной политике цепей поставок и т. д.? Инспекционные панели представляют собой инструмент «устранения ошибок», и они позволяют вывести на экран все связанные друг с другом данные, причем связанные не с точки зрения информационных технологий, но с точки зрения цепей поставок.


Инспекционные панели — это низкоуровневый аналог панелей качества данных. Они работают с полностью детализированными данными, тогда как панели качества данных обычно предназначены для данных более высокого уровня. Кроме того, инспекционные панели зачастую используются для обеспечения эффекта «белого ящика». Если рекомендации, рассчитанные системой, кажутся необоснованными, специалисты по цепям поставок должны внимательно проанализировать единицу складского учета или товар, чтобы определить, является ли решение состоятельным. Как правило, инспекционные панели создаются как раз для этого за счет включения множества промежуточных результатов, которые используются при расчетах конечных решений.