Обновлять всё каждый день

Joannes Vermorel

Практика Lokad в области управления цепями поставок заключается в том, чтобы обновлять все конвейеры извлечения данных — включая прогнозы — как минимум один раз в день, даже при работе с ежемесячными или ежеквартальными вычислениями. Для многих специалистов эта практика может показаться нелогичной. Почему обновлять ежеквартальные прогнозы больше одного раза в квартал? Как же быть с числовыми нестабильностями? Что насчёт возникающего трения? Это противоречит большинству устоявшихся практик цепей поставок, особенно в тех компаниях, где существует процесс S&OP. Тем не менее, десятилетний опыт научил нас, что несоблюдение принципа «обновлять всё» — рецепт для бесконечного потока производственных проблем. В основе проблемы лежит необходимость её глубокого и тщательного решения — посредством версионированного безсостояния программного обеспечения, отвечающего за цепь поставок посредством прогностической оптимизации.

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

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

Следовательно, если конвейер извлечения данных запускается ежедневно после производственного инцидента, для восстановления стабильности требуется от 5 до 10 дней. Если же конвейер запускается ежемесячно, тот же процесс устранения проблемы занимает от 5 до 10 месяцев. Важным является именно количество раундов, а не реальные часы. Чтобы окончательно подтвердить, что краевой случай устранён, необходимо провести несколько раундов. В качестве наглядного примера, в Lokad у нас была ошибка в планировщике заданий, связанная с переходом на новый час, которую исправляли два года, именно поскольку условия, вызывающие проблему, были настолько редкими — два раза в год для каждого часового пояса. И хотя некоторые проблемы, например, переходы времени, по своей природе встречаются редко, большинство можно воспроизвести «по желанию», просто увеличив частоту «раундов».

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

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

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

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

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

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

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

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

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

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