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

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

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

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

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

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

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

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

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

Почему это приводит к провалу: Каждое постепенное изменение увеличивает стоимость и сложность всех последующих изменений. Поскольку в компании предпочитают изменения, которые как можно меньше и постепеннее, постоянно не уделяется внимания «общей картине». В некотором роде, это похоже на проблему «трагедии общих ресурсов», когда индивидуальные интересы (отдельные подразделения компании) не совпадают с общими интересами всей компании. Проблема усугубляется тем, что негативные последствия обычно наблюдаются только спустя долгое время после внесения изменений. Хотя каждое изменение кажется выгодным, компания продолжает накапливать «технический долг», превращая краткосрочную прибыль в убытки со временем.

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

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

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

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

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

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