Обновление всего каждый день

Joannes Vermorel

Практика управления цепями поставок Lokad заключается в обновлении всех конвейеров данных, включая прогнозы, как минимум один раз в день, даже при работе с ежемесячными или ежеквартальными расчетами. Для многих практиков такая практика может показаться контринтуитивной. Почему обновлять квартальные прогнозы чаще одного раза в квартал? Что насчет численных нестабильностей? Что насчет возникающего трения? Это противоречит большинству установленных практик управления цепями поставок, особенно тех компаний, у которых есть процесс S&OP. Однако десятилетний опыт показал, что несоблюдение этой практики “обновления всего” является рецептом для бесконечного потока проблем в производстве. В основе этой проблемы должен быть фронтальный подход - в глубину - через версионированный бесстейтовый дизайн программного обеспечения, отвечающего за предиктивную оптимизацию цепи поставок. Этот вопрос будет рассмотрен более подробно далее, но давайте начнем с более пристального рассмотрения самой проблемы.

В мире прикладного программного обеспечения, проблемы / сбои / ошибки / проблемы возникают постоянно. Это особенно верно для цепей поставок, где прикладной ландшафт неизменно представляет собой некоторую хаотичную коллекцию программных компонентов (ERP, EDI, MRP, WMS, OMS, электронная коммерция и т. д.), объединенных на протяжении десятилетий деятельности: каждое приложение является потенциальным источником проблем, поскольку оно взаимодействует с множеством других приложений¹. Каждое изменение, внесенное в любое из этих приложений, может привести к поломке чего-то в другом месте, то есть не только к поломке самого приложения. Однако все компании не равны, когда дело доходит до управления своим прикладным ландшафтом, и даже самые успешно управляемые компании получают более одного “сбоя” в программно-управляемой цепи поставок в день при числе сотрудников более 1000.

Таким образом, крупные компании сталкиваются с бесконечным потоком проблем с программным обеспечением, которые требуют решения. Ответственность за устранение таких проблем может лежать на отделе информационных технологий, стороннем поставщике, операционной команде, поставщике и т. д. Однако, после того, как любая из этих проблем “предположительно” решена, требуется от 5 до 10 раундов², чтобы убедиться, что проблема действительно устранена. Фактически, большинство проблем являются крайними случаями, которые могут или не могут проявляться в каждый момент времени. Таким образом, хотя проблема может казаться решенной, потому что она исчезла после применения какого-то исправления, это может быть не так. Цепочки поставок - это сложные системы, включающие множество взаимозависимых элементов, некоторые из которых даже не находятся полностью под контролем компании (например, EDI с поставщиками). Люди регулярно не могут обеспечить окончательное исправление не потому, что они ленивы или не компетентны, а просто из-за неизбежной окружающей сложности.

В результате, если после производственного инцидента ежедневно запускается поток данных, требуется от 5 до 10 дней, чтобы вернуть его к стабильности. Если поток данных запускается ежемесячно, этот же процесс разрешения занимает от 5 до 10 месяцев. Важно количество раундов, а не время на часах. Для положительной оценки устранения крайнего случая требуется несколько раундов. Как анекдотическое доказательство, в Lokad у нас была ошибка планирования заданий, связанная с изменением времени, которую удалось исправить только через два года, именно потому, что условия, вызывающие проблему, были настолько редкими - дважды в год для каждого часового пояса. Однако, хотя некоторые проблемы, такие как изменения времени, являются нечастыми, большинство проблем могут быть воспроизведены “по желанию”, просто увеличивая частоту “раундов”.

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

В Lokad мы выбрали ежедневное обновление (или даже чаще) исключительно по необходимости более десяти лет назад. С тех пор мы так и не нашли другого способа обеспечить достойное качество обслуживания с точки зрения цепочки поставок. Вероятно, таких способов нет. Предсказательная аналитика сложна и, следовательно, подвержена “ошибкам” всех видов. Ежедневное обновление гарантирует, что проблемы будут незамедлительно устранены, а не будут вечно оставаться в лимбе³. В этом отношении наши результаты далеки от оригинальных. Netflix стал пионером целого направления хаос-инжиниринга похожим образом мышления: чтобы создать надежную систему, необходимо применять стресс; без стресса устойчивость никогда не станет частью инженерного мышления. Большинство серьезных компаний по разработке программного обеспечения - в частности GAFAM - приняли еще более строгие варианты этого подхода.

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

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

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

Ежедневное обновление всех конвейеров данных может показаться расточительным с точки зрения вычислительных ресурсов. Однако, учитывая современное вычислительное оборудование и правильно разработанное программное обеспечение, эта стоимость невелика, даже если учитывать сложные методы, такие как вероятностное прогнозирование⁶. Более того, цепочки поставок регулярно сталкиваются с исключительными условиями, требующими немедленной коррекции в масштабе всей системы. Если компания не может обновить все свои показатели цепочки поставок менее чем за 60 минут, потому что она должна это сделать, то чрезвычайные ситуации гарантированно останутся без решения время от времени, нанося ущерб на практике. Применяется правило 5-10 раундов - ранее обсуждавшееся: после обнаружения исправления требуется несколько запусков - возможно, с разными настройками - чтобы быть уверенным, что это чрезвычайное исправление работает. Таким образом, если конвейер данных слишком дорог для запуска “по желанию”, производство будет использоваться в качестве полигона испытаний, и наступит хаос.

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

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

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

Lokad был разработан в соответствии с этими принципами. Мы поддерживаем ежедневное обновление всего. Наши пайплайны данных являются безсостоятельными и версионированными - как логика, так и данные. А как насчет вашей компании?