Нееуклидов ужас (антипаттерн цепочки поставок)

learn menu
Автор: Жоанн Верморель, июнь 2015

Нееуклидов ужас вышел из глубин информационных систем компании. Слишком долгое внимание нееуклидовому ужасу может привести к постоянной потере рассудка.

Категория: организация

cartoon-non-euclidian-intro

Проблема: на протяжении многих лет компания создавала множество различных систем. Теперь у них есть ERP, WMS (система управления складом), CRM (управление взаимоотношениями с клиентами), куб BI (бизнес-аналитика), платформа электронной коммерции и т. д. Между внедрением всех этих систем также были разработаны внутренние компоненты для выполнения более специализированных задач. Сложность ИТ-ландшафта резко возросла за годы, поскольку каждое дополнительное приложение должно взаимодействовать со всеми другими приложениями, уже реализованными компанией. Все подразделения затронуты, но цепочка поставок, находящаяся между продажами, закупками, финансами и производством, страдает больше всего. Изменения затруднены, и почти все инициативы в области цепочки поставок не успевают соблюдать сроки. Никто уже не понимает, что происходит в системах компании.

Анекдотическое доказательство: Физическое перемещение из одного склада в другой, находящийся поблизости, может занять две недели. Однако, что касается программного обеспечения, фактическая миграция ИТ, необходимая для интеграции нового склада, займет более 6 месяцев.

Контекст: давным-давно каждое подразделение компании начало собственное программное решение. Интеграция была плохой, и наконец было решено, что будет создана ERP-система, чтобы “все они правили”. ERP-система была внедрена, но она не смогла удержаться на шагу с быстрым темпом изменений в программной индустрии. Что касается цепочки поставок, была создана система управления складом (WMS) для повышения производительности и надежности, и это действительно сработало относительно хорошо. Другие подразделения сделали аналогичные шаги, создав свои собственные приложения, специфичные для своей области, которые лучше подходили, чем исходная ERP. Однако бизнес меняется быстрее, чем когда-либо, и сегодня для более умных операций цепочки поставок требуется множество взаимодействий между всеми этими различными приложениями.

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

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

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

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

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

cartoon-non-euclidian-sacrifice

Пример: Контозо - национальный лидер электронной коммерции в Германии в определенном сегменте B2C. Компания начала свою деятельность в начале 2000-х годов, разрабатывая на тот момент индивидуальный интерфейс, который является “приложением”, позволяющим людям покупать онлайн. В первые годы компания решала практически все свои ИТ-потребности с помощью постоянно растущего интерфейса. Однако управление поставщиками и заказами было слишком сложной задачей для этого индивидуального приложения. В результате Контозо решила инвестировать в среднерыночную ERP-систему и переложить все задачи бэк-офиса на эту систему, включая основную часть начинающихся практик цепочки поставок. Некоторое время уровень запасов управлялся как в интерфейсе, так и в ERP, но такой подход оказался неудобным, и в конечном итоге Контозо успешно избавилась от излишних обязанностей интерфейса.

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

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

Подход оказался несколько запутанным, и хотя изначально планировалось развернуть приложение для поиска поставщиков в течение 3 месяцев, на его внедрение ушло целых 9 месяцев. Однако это оказалось оправданным вложением, поскольку мультипоставка привела к снижению средних закупочных цен на 15%, что является значительным стимулом для бизнеса.

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