Когда система Lokad работает над проектами по количественной оптимизации цепей поставок, около 80% усилий уходит на
подготовку данных , также называемую
очисткой данных или
предварительной обработкой данных. Необходимость таких усилий часто понимают неправильно даже опытные профессионалы по цепям поставок. Наши наблюдения показывают, что проблемы с данными являются основной причиной неудач в оптимизации цепей поставок практически во всех сферах промышленности: от продуктов до запчастей для самолетов. Несмотря на то, что некоторые проблемы в цепях поставок имеют грандиозные масштабы, о большинстве из них известно крайне немногим. Изучение таких проблем очень важно для предотвращения повторных случаев.
Ошибки из-за данных
Проекты по оптимизации цепей поставок часто оказываются безуспешными. Клиенты Lokad рассказывают, что при оптимизации цепей поставок с помощью программных средств около 80% проектов заканчиваются неудачно в большинстве сфер. Некоторые поставщики даже признают, что неудачная реализация таких проектов является «нормой» для их клиентов. Парадокс современных цепей поставок заключается в том, что физическое перемещение запасов с одного континента на другой предполагает меньше рисков, чем перемещение данных о запасах с одного компьютера на другой, расположенный в 1 метре от первого.
Если что-то идет не так, то ни клиент, ни поставщик не стремятся рассказывать об этом. Таким образом, большинство данных о провальных проектах просто замалчиваются. Время от времени оптимизация проходит настолько неудачно, что это даже попадает в новости:
Эти провалы имеют различные причины, однако каждый раз проблема заключалась в информации, в результате чего принимались невероятно нерациональные решения , связанные с цепями поставок. Тем не менее, большинство провалов обычно не настолько грандиозны. Те, кто занимается цепями поставок, обычно скептически относятся к цифрам, которые выдает их новая и, предположительно, более эффективная система, и продолжают работать со старыми добрыми таблицами Excel , а через пару месяцев систему удаляют. Компания не испытывает значительных проблем, однако время и энергия работников тратятся напрасно, появляются альтернативные издержки .
Проблемы понимания данных
Коммерческие данные — вещь перспективная, но коварная. Их сложно понять, потому что, на первый взгляд, они не имеют большого значения. Опыт показывает, что это и есть одна из основных причин проблем с данными, которые так часто встречаются при работе с цепями поставок.
Рассмотрим простой пример: в таблице приводится список наименований и количество товаров, проданных за последние несколько лет, сгруппированные по дням. Такой истории продаж должно быть достаточно, чтобы понять, в какую сторону движется бизнес.
Однако этого не происходит по следующим причинам:
- В истории могут содержаться наборы , когда один товар представляет собой набор из различных изделий, поэтому показатели могут уменьшаться, тогда как компания развивается.
- В истории могут быть отражены возвраты , которые могут составлять большую часть всех продаж, поэтому может показаться, что компания развивается, хотя на самом деле она приходит в упадок, так как возвраты перемещаются быстрее.
- В истории могут присутствовать промоакции , когда компания жертвует прибылью ради ликвидации запасов, а созданный спрос не отражает реальный спрос на товар, который продается за полную цену.
Затем, когда мы говорим об
объеме проданного товара за день, сама дата подразумевает достаточно много разночтений . Под датой может подразумеваться следующее:
- Дата размещения заказа клиентом
- Дата предварительного подтверждения заказа клиентом
- Дата отгрузки товара клиенту
- Дата загрузки заказа в ERP
- Дата последнего изменения заказа в ERP
- Дата получения платежа от клиента
- И прочее, и прочее.
Все варианты могут считаться верными, но каждый из них имеет свои особенности. Однако очень часто все сводится к тому, что история продаж — это
просто история продаж. Когда речь идет о продажах, (практически) ничто не является
простым.
Кроме того, эффект различных факторов увеличивается в разы, когда они действуют в одном направлении. Нет ничего опаснее с точки зрения накопления избыточных запасов , чем избыточная погрешность , которая завышает продажи, в сочетании с понижающей погрешностью, которая занижает количество товара, получаемого компанией.
Как правило, аккуратное документирование данных подразумевает описание каждого столбца в каждой таблице, причем объем описания должен быть примерно равен странице. И все же даже в самых удачных случаях на начало проекта у нас есть всего 1 строчка описания для каждого столбца (на каждое поле данных).
Даже когда документация существует, она часто бессмысленна. Понятно, что столбец
OrderDate будет содержать даты. Также понятно, что столбец
StatusCode будет содержать краткий список кодов. Техническая документация часто уделяет внимание информационным технологиям в ущерб бизнесу. Это странно, так как именно бизнес-факторы важны для оптимизации.
В информатике есть поговорка:
мусор на входе — мусор на выходе . Если входные данные бессмысленны, то и результаты будут такими же. Таким образом, анализ данных и документирование всей информации — основная цель Lokad при проведении оптимизации цепей поставок. Большинство наших клиентов удивлены тем, что при анализе их систем, данных и процессов Lokad создает большое количество документов . Опыт показывает, что все эти документы очень полезны.
Индивидуальный подход
Очень часто при реализации проекта по количественной оптимизации цепей поставок у нас спрашивают:
«Можно ли проводить оптимизацию, если мы пользуемся системой XYZ?» Почти всегда можно просто сказать
да, однако полный ответ будет звучать так:
да, но для этого нужно что-то сделать. Перемещение данных — задача довольно простая: Протокол передачи данных FTP используется не одно десятилетие, и даже через простое интернет-соединение можно передать довольно много информации. Самой сложной задачей является извлечение максимальной пользы из обрабатываемых данных. Компании не всегда понимают, насколько универсальными являются их информационные системы на самом деле. Работникам компании системы, с которыми они работают, могут показаться довольно неповоротливыми, однако на практике это обычно не так.
Поставщики ПО соревнуются в универсальности своих систем уже много лет, и крайне редко можно найти системы, которые позволяют выполнять работу только одним способом . Большинство систем предлагают огромное количество методов достижения одного и того же результата. Как следствие, даже если данные извлекаются из одной программы, их подготовка может и будет различаться. На самом деле подготовка данных во многом зависит от рабочих процедур и процессов, принятых в компании, и одни и те же данные могут быть представлены в разных фирмах по-разному. Изначально расхождения могут показаться незначительными, однако с точки зрения оптимизации цепей поставок они часто становятся причиной значительных несоответствий между алгоритмами оптимизации и фактическими потребностями компании.
Стратегия — это данные
Преимущество компьютеров в том, что они делают то, что вы им говорите.
Недостаток компьютеров в том, что они делают то, что вы им говорите. Тед Нельсон
Большинство руководителей компаний оставляют реализацию бизнес-стратегий на совести трудового коллектива, даже если стратегия не выражена формально и даже нигде не записана. Количественная оптимизация не допускает скрытых целей : данные, которые выдает система, в точности соответствуют данным, которые были введены в систему. Как следствие, результаты работы систем оптимизации поначалу могут показаться неудовлетворительными: часть показателей будет точными, но другая часть при этом окажется абсолютно бессмысленной.
Точные цели компании редко указываются сразу. Очень часто необходимо получить первые результаты алгоритма оптимизации, чтобы понять, чего не хватает. Может получиться так, что:
- часть клиентов считаются особо важными , и им требуется более высокий уровень обслуживания
- часть товаров стремительно устаревают и несут в себе огромные риски, связанные с их хранением
- у некоторых поставщиков есть ограничения по MOQ для каждому артикулу (SKU) и для каждого заказа
- некоторые склады заполнены почти до предела, а потому заказы на пополнение запасов должны быть небольшими
- и так далее.
Для решения таких проблем требуются дополнительные данные, и компании понимают, что нужные данные можно найти только в файлах Excel , которые разбросаны по разным компьютерам в фирме. Сами по себе файлы Excel часто считаются не слишком-то важными, и их нередко архивируют в почтовых системах.
В результате подготовка требуется не только для данных об операциях, которые могут быть получены из ERP, но и для всех данных высшего уровня, которые определяют стратегию развития компании. Задача усложняется тем, что данные высшего уровня гораздо сложнее подготовить. В отличие от данных об операциях информацию этого типа редко синхронизируют в масштабах компании. При подготовке таких данных часто приходит осознание, что стратегия развития компании в некоторых ситуациях не имеет смысла.
Для подстройки алгоритма оптимизации под цели компании лучше всего пересчитать все значения и выразить их в евро или долларах (или в любой другой валюте). Дело не в том, что рассматривать ситуации удобнее с финансовой точки зрения, а в том, что только денежные показатели одинаково значимы во всех отделениях компании, причем от сотрудников не требуется совместной работы по данному вопросу. На практике принятие финансовой точки зрения может привести к определенным трениям в компании, если сотрудники привыкли работать с нефинансовыми показателями или, что еще хуже, вообще не привыкли иметь дело с какими бы то ни было показателями .
Документации много не бывает
Секрет хорошей подготовки данных — в качественной документации . Эта задача проста, но ее часто опускают как неактуальную или неважную. Опыт Lokad показывает, что она и актуальна, и очень важна.
Документация должна отвечать на вопрос
«Почему?» для всех источников данных и даже для всех полей данных. Документировать назначение данных крайне важно, чтобы их можно было правильно обработать. Когда документация существует, она часто всего лишь отражает названия полей данных.
Пример плохой документации
ORDERS.DATE: дата, привязанная к строке заказа.
Пример более удачной документации
ORDERS.DATE: дата, когда клиент выразил намерение приобрести товар; основной сигнал спроса. Эту дату можно сравнить с ORDERS.DELIVERYDATE для оценки времени между размещением заказа и доставкой с точки зрения клиента.
Документирование входящих данных не нужно рассматривать как элемент информационного обеспечения, это скорее коммерческий актив компании. Не важно, насколько хорошо мотивирован и отзывчив персонал информационного отдела, у них обычно нет знаний , необходимых для глубокого понимания коммерческих данных.
В результате, когда Lokad работает с новыми клиентскими проектами, мы с самого начала уделяем время документированию данных; как правило, это происходит поэтапно после каждого разговора с клиентами (которые предоставляют необходимые данные о своем бизнесе). Польза этого процесса поначалу незаметна, так как вначале проекта есть другие более важные вопросы. Со временем некоторые мелкие детали, касающиеся данных, забываются, и только письменная документация позволяет избежать возникновения одних и тех же проблем снова и снова.
