Преамбула.

Если вас позвали работать в компанию, то почти всегда это означает одно: там есть работа, и что-то уже идёт не так.

Введение. Почему цепочки поставок ломаются

За всё время работы мне редко встречались проекты, где цепочка поставок изначально была выстроена устойчиво. Неважно, крупная это компания или средняя — проблемы всё равно появляются.

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

Физически цепочка может работать нормально: склад грузит, машины ездят, люди на местах делают свою работу. И при этом управляемости — ноль. Самое интересное начинается, когда в процессе появляется человек, который реально хочет отвечать за результат. Не просто «нажимать две кнопки», а думать. Его первый вопрос почти всегда одинаковый: «Алекс, а сколько товара нам заказывать в следующем месяце?»

Вопрос кажется простым, но на практике он держится на трёх вещах:

  • Первая — остатки. Зачастую бизнес начинает поиск проблем со склада, но чаще всего именно он справляется лучше всех: людей хватает, простоя нет.

  • Вторая — отгрузки. В современном мире сложно представить себе регион со слабой логистикой (такие есть, но это скорее исключения). Поэтому после проверки тут тоже все отлично: товар едет, контрагенты работают, логистика не разваливается.

  • Третья — отчёты. То есть способность ИТ-систем собрать данные из разных источников, сопоставить их и дать человеку понятный ответ.

И именно на третьем пункте в 90% случаев начинаются проблемы. Бизнес фактически не имеет возможности управлять процессом. Решения по планированию товародвижения начинают приниматься либо на ощущениях, либо не принимаются вовсе. Управление подменяется реакцией: не «что делать дальше», а «что делать прямо сейчас».
Со временем это приводит к простой вещи: планирование исчезает как класс. Остаётся только тушение пожаров.

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

Что такое устойчивость цепочки поставок на практике

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

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

Из практики: в одном из проектов на склад одновременно пришла крупная партия контейнеров, и бизнесу срочно понадобилось передать часть операций с товаром подрядчику, чтобы успеть к распродаже. Для того чтобы передать операции и корректно отобразить их в учетных системах, было необходимо реализовать обмен с внешним сервисом. Технический архитектор предлагал делать всё «как правильно» — через полноценную интеграцию с описанием, тестами и тд. Это решение 100% верное с точки зрения архитектуры, но к сожалению оно не укладывалось во временные рамки бизнеса. В итоге, я принял решение взять на себя ответственность и пойти по временному пути. Мы реализовали данный обмен не идеально, а так, как было лучше для бизнеса в конкретный момент (ручной труд, выгрузки на коленке и поддержка ручных операций со стороны архитектора ИТ и администратора склада). Это решение было осознанным компромиссом. Я понимал, что архитектурно оно временное, но также понимал риски и границы, за которые мы не выходим. Это позволило сохранить управляемость процесса и выиграть время. Ключевым было то, что система позволила по��ти на такой шаг без её полного слома. Именно поэтому позже нормальная интеграция была сделана без пересборки всего процесса.

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

Роль ИТ-архитектуры в цепочке поставок

Когда говорят об ИТ-архитектуре в цепочке поставок, чаще всего начинают обсуждать конкретные системы. ERP, WMS, TMS — список таких систем всем знаком. Но на практике архитектура — это не набор программ, а договорённость о том, кто за что отвечает и где проходит граница ответственности.

Когда мы выбрали системы с которыми будем работать, то должны понимать, что нужно назначить мастер-системы под различные операции. Сами по себе ни одна из этих систем не «главнее» других. Важно, чтобы они корректно общались между собой и каждая делала своё дело: когда складские операции начинают жить в ERP системе, а планирование — в складской, то архитектура перестаёт быть управляемой. Именно поэтому в устойчивой архитектуре у каждой системы есть свои администраторы и суперпользователи — люди, которые знают систему глубоко и способны вести пользователей за руку, а не просто пересылать заявки дальше. Если архитектура не объяснима бизнесу, для бизнеса её просто не существует.

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

Больше всего проблем создают интеграции, в которых данные изначально не равны друг другу. С ERP обычно всё предсказуемо: объёмы большие, структура понятная — вопрос скорее в аналитике. А вот когда начинается обмен между узкоспециализированными самописными сервисами и нетиповыми системами, стоит остановиться и честно спросить себя: а этот обмен нам действительно нужен? Лучше потратить лишний месяц в начале проекта, чем потом годами догонять собственную систему.

Разрыв процессов же возникает там, где инструкции расходятся с реальной работой. Пользователи не любят читать. Никто не любит читать. Я почти уверен, что никто уже не читает этот абзац, поэтому могу написать здесь «пупырка».

Но если без шуток, инструкции всё равно критичны — особенно когда они встроены прямо в ИТ-систему и работают как контекстный справочник, а не как файл, который никто никогда не открывает. В одном из проектов простое описание инструкций для администраторов WMS в итоге разрослось почти до двухсот страниц. Пользователям было сложно осилить эту инструкцию, но кто смог это сделать понимал работу склада от и до.

Типичные архитектурные ошибки

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

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

Альтернативой была полноценная TMS, но на старте внедрения её не выбрали. На старте для бизнеса причина выглядела рационально: готовое решение стоит больших денег, а зачем на старте нужны все его возможности — непонятно. Собственная разработка воспринималась как более дешёвая, потому что её стоимость была размазана во времени: небольшие доработки, отдельные задачи, редкие инциденты. Внедрение растянулось почти на три года.

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

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

Несмотря на все это, система продолжала жить. В неё было вложено слишком много времени, сил и нервов, чтобы в какой-то момент просто сказать: «Останавливаемся». И это, пожалуй, самый опасный момент в таких историях — когда решение уже всем очевидно, но принять его становится психологически невозможно.

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

Бизнес видит симптомы такой архитектуры раньше, чем понимает причину. Сроки разработки растут, качество решений падает, ИТ всё чаще требует детализированное ТЗ, а результат начинает соответствовать не смыслу задачи, а буквальному тексту документа. Это не означает, что детальные требования не нужны, но когда архитектура здорова, она позволяет обсуждать потребности, а не формулировки. Когда же архитектура перегружена, люди начинают прятаться за документы — и это почти всегда признак того, что система больше не выдерживает нагрузку.

Хорошая архитектура не предотвращает ошибки. Она делает их заметными и управляемыми. Плохая — просто откладывает момент, когда за них придётся платить.

Как архитектурные ошибки превращаются в системные проблемы

Архитектурные ошибки почти никогда не ломают бизнес сразу. Если бы ломали — их бы просто не принимали. Они начинают работать тихо. Сначала как удобство, потом как экономия (времени, денег, ресурсов. Нужное подчеркнуть). Потом эти решения превращаются в «давайте пока так оставим, а потом переделаем».

Скрытый текст

Проблема в том, что это «потом» обычно не наступает.

Самый популярный сценарий выглядит так: появляется временное решение, которое закрывает реальную боль бизнеса здесь и сейчас. Все выдыхают и процесс едет дальше. А через полгода оказывается, что именно это временное решение стало центральным узлом всей цепочки. И избавится от него так просто у вас больше не получится. Например, временная интеграция. Её делают быстро, без полной модели данных, без нормальных статусов, без обработки ошибок. Она работает, но только пока объёмы маленькие. Потом объёмы ра��тут, и эта интеграция начинает определять, как вообще можно двигать товар. Любое изменение теперь упирается в неё. Любая ошибка — в ручную сверку. Архитектура вроде бы есть, но фактически она держится на одном костыле.

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

Третий классический случай — отчёты из разряда «потом сделаем нормально». Сначала бизнесу достаточно цифры «примерно». Потом (видимо забыв, что это примерные цифры) по ним начинают принимать решения. Потом оказывается, что отчёт собирается три дня. Из пяти источников. Руками. Любая ошибка в исходных данных критична, и система в таком случае не даёт точки опоры.

Самое неприятное здесь то, что ИТ-архитектура в этот момент перестаёт быть инструментом. Она становится ограничением. Любой новый запрос бизнеса начинает звучать как угроза: «это сложно», «это рискованно», «это может всё сломать». ИТ начинает защищаться. Бизнес — давить. Диалог превращается в торг.

И именно в этот момент становится понятно, что проблема не в конкретной интеграции, не в отчёте и не в ручной операции. Проблема в том, что архитектура не держит нагрузку изменений. Она не рассчитана на то, что мир будет меняться. А в цепочке поставок он меняется всегда.

Ручной тр��д как нормальное состояние системы

Ручной труд редко появляется из-за плохих людей или лени. Обычно он появляется в момент, когда бизнесу срочно нужен результат, а система не готова дать его автоматически.

На практике это выглядит так: бизнесу нужно — срочно, у ИТ есть ресурсы, но нет понимания или возможностей сделать решение правильно и быстро.

В этот момент автоматизация откладывается, и задача закрывается руками. Excel, выгрузки, скрипты, ручные проверки. Всё, что позволяет дотянуть до следующего дедлайна.

Если разложить это чуть формальнее, картина получается очень показательная:

  • бизнесу нужно + ИТ знает решение + есть ресурсы → появляется аккуратное решение

  • бизнесу нужно + есть ресурсы → работа руками

  • бизнесу нужно + ИТ знает решение → вечный бэклог

  • есть ресурсы + ИТ знает решение → задача просто отменяется

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

Как усиливают архитектуру, а не чинят последствия

Усиление архитектуры почти никогда не начинается с новых систем. Оно начинается с отказа от текущих иллюзий. Самой опасной из них — что «в целом всё работает, просто тут немного подправить».

Когда архитектуру начинают «чинить», обычно лечат симптомы. Медленные отчёты — добавим сервер. Ошибки в данных — усилим контроль. Ручной труд — наймём ещё людей. Всё это даёт краткосрочный эффект и почти всегда ухудшает ситуацию на дистанции.

Усиление работает иначе.

Первое, с чего обычно стоит начинать, — это чёткие границы ответственности систем, и ответственности внутри системы.

Если складская операция произошла в WMS — она не должна «дублироваться» в ERP как ещё одно событие. А ERP должна жить фактами, а не пытаться быть операционной системой. Как только одна система начинает делать работу другой, архитектура начинает расползаться.

Второй момент — работа с данными как с продуктом, а не как с побочным эффектом.

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

Скрытый текст

Вспоминается анекдот: админы делятся на 2 вида, те кто делают бэкапы и те, кто будет делать бэкапы

Третий элемент усиления — готовность к временному хаосу.

Звучит парадоксально, но сильная архитектура допускает неидеальные решения. Разница в том, что эти решения будут сразу помечены как временные: с ограниченным сроком жизни, понятными рисками и планом выхода. Это не заметание под ковер проблем, а четкое понимание, когда возникнет проблема из-за чего и как ее решить.


Из практики: если временное решение нельзя удалить без боли — это не временное решение. Это новая часть архитектуры, просто без документации и ответственности. А иногда и без управления.

Четвёртый момент — люди.

Архитектура держится не на диаграммах, а на тех, кто понимает, почему система устроена именно так. Суперпользователи, администраторы, технические владельцы — не формальные роли, а реальные люди с правом говорить «нет» на любое «хочу» или «надо». Если в системе нет человека, который может остановить плохое решение, значит архитектура уже начала проигрывать.

И наконец — масштабирование как обязательный сценарий, а не как «когда-нибудь потом». Если решение не проверялось на рост в 5–10 раз, его нельзя считать устойчивым. Не потому что оно обязательно сломается, а потому что в момент роста времени на размышления уже не будет.

В итоге усиление архитектуры — это про способность системы переживать изменения без паники, ручного героизма и бесконечных совещаний.

Вместо вывода

Цепочка поставок ломается не в момент сбоя. Она ломается раньше — в тот момент, когда бизнес перестаёт понимать, что происходит, а ИТ перестаёт уметь это объяснить.

Почти в каждом проекте, куда меня зовут, проблема формулируется одинаково: «Нам нужно быстрее», «нам нужно точнее», «нам нужен ещё один отчёт». Но если копнуть глубже, оказывается, что на самом деле бизнесу нужно не это. Ему нужно снова начать управлять процессом, а не реагировать на него.

Хорошая ИТ-архитектура не даёт волшебных ответов. Она не гарантирует, что ошибок не будет. Зато она гарантирует другое: если ошибка произошла, её можно увидеть, понять и исправить, не останавливая весь бизнес.

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

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

И хорошая новость в том, что это можно менять. Плохо — что чем дольше тянуть, тем дороже это будет стоить.