Система учёта должна быть локальной
Я пришёл к выводу, что в цепочке поставок большинству компаний следует прекратить приобретать обширные системы учёта и начать создавать их локально. Речь идёт о программном обеспечении, которое регистрирует заказы, поступления, перемещения запасов, счёта-фактуры, утверждения и сопровождающие канцелярские операции обычной деятельности. Эти системы критически важны, но их ценность ограничена. Это реестры с рабочими процессами. Рынок по-прежнему оценивает их, демонстрирует и регулирует так, как если бы они были самоценными сокровищами компании. Эта ошибка стала очень дорогой.
В книге Введение в цепочку поставок, особенно в главах 5 и 6, я провёл грань между программным обеспечением, которое ведёт бумажный след, и программным обеспечением, которое принимает решения. Это различие имеет значение. Как только мы рассматриваем систему учёта без обычного спектакля, большая часть мистики исчезает. Система учёта должна быть надёжной, поддающейся аудиту и довольно скучной. Она не должна притворяться способной думать. Она должна запоминать факты, обеспечивать выполнение нескольких рабочих процессов и не мешать работе.
Скрытый налог пакетных регистров
Система учёта быстро достигает коммерческой зрелости. Как только она способна надёжно обрабатывать закупки, продажи, учет запасов, выставление счетов и несколько смежных рабочих процессов, дополнительная ценность расширения становится незначительной. Поставщики прекрасно это понимают. Их ответ оставался неизменным на протяжении десятилетий: добавить еще одну сущность, еще один экран, еще один модуль, еще одну страницу настроек. Продавать следующий инкремент установленной базе. Со временем продукт превращается в конгломерат бесчисленных запросов клиентов, многие из которых разумны по отдельности, а в совокупности абсурдны. Результатом является функциональный мастодонт, сложность которого продолжает расти, хотя основная задача практически не изменилась.
Академическая литература на протяжении многих лет описывает эту проблему более сдержанным языком. Стронг и Волков отмечали, что пакетные корпоративные системы разработаны для универсальных, а не для конкретных требований, и поэтому обычно не соответствуют нуждам конкретной организации. Более недавнее исследование кастомизации ERP делает этот компромисс явным: настройка может улучшить функциональность и удовлетворённость пользователей, но при этом увеличивает затраты на внедрение, сложность и расходы на последующие обновления. Обзор ERP-недостатков 2025 года приводит столь же трезвый вывод: уровень неудач внедрения остаётся высоким, несоответствие между стандартизированными процессами и локальными рабочими процессами сохраняется, и ни одна широко распространённая отрасль не выработала практику, которая могла бы чисто решить эти несоответствия.
Этот налог не ограничивается лишь лицензионными сборами. Бенчмарк ERP Panorama 2025 сообщает о медианной стоимости проекта в 450000 долларов США и медианной длительности девять месяцев. Среди проектов, которые превысили бюджет, самой частой причиной была неожиданная необходимость в дополнительной технологии. Среди проектов, выполненных с опозданием, главной проблемой оказались вопросы с данными. В том же отчёте отмечается, что многие внедрения ERP до сих пор не устраняют организационные силосы. Это закономерность, которую я наблюдаю вновь и вновь: комплекс не устраняет сложность, а перераспределяет её в области интеграции, миграции, управления и сложных обходных решений.
Основные модели данных рассказывают ту же историю. Документация Microsoft по Dynamics объясняет, что простое бизнес-понятие, такое как клиент, может быть разбросано по нескольким нормализованным таблицам, именно поэтому сущности данных существуют в виде денормализованных абстракций. Документация Oracle JD Edwards демонстрирует длинные каталоги таблиц, сгруппированных по типу и модулю. ERPRef, сторонний каталог схем, перечисляет 1687 таблиц для SAP Business One 9.0 и 5097 для JD Edwards 9.20; в том же каталоге таблица счетов-фактур в SAP Business One 9.3 представлена с 424 столбцами. Конкретная компания использует лишь малую часть этого обилия, но всё равно оплачивает его по части прав доступа, сопоставлений, интеграций, обучения и обновлений.
Существует второй налог, и он часто оказывается более разрушительным. Подход, основанный на внимании к деятельности фирмы, по Уильяму Оказио, исходит из простого наблюдения: то, чем занимаются компании, зависит от того, как направляется внимание руководства. Обширная система учёта потребляет это внимание так же неумолимо, как и денежные средства. Годы, потраченные на внедрения, очистки, миграции, редизайны, дополнительные модули и обновления, — это годы, когда высшее руководство поглощено механизмами канцелярской инфраструктуры. Я уже утверждал в другом месте, что когда записи и отчёты поглощают основную часть бюджета на программное обеспечение, они также поглощают почти всё внимание руководства, оставляя мало места для софта, который действительно мог бы улучшить принятие решений.
Почему индивидуальные решения перестали быть сложными
Удивительно, что технические аргументы в пользу специализированных систем учёта уже давно перестали выглядеть экзотично. За PostgreSQL стоит почти сорок лет активной разработки, и он соответствует стандарту ACID с 2001 года. ASP.NET Core бесплатен, имеет открытый исходный код и работает на разных платформах. Entity Framework Core поддерживает отслеживание изменений, обновления и миграции схем в нескольких базах данных. Django поставляется с встроенной защитой от распространённых веб-атак. Когда инфраструктура для транзакционного программного обеспечения достигла такой зрелости, создание узкого внутреннего реестра уже не является актом храбрости.
В документации Django есть даже поучительная деталь. Его автоматический административный интерфейс рекомендуется для внутреннего инструмента управления организацией, а не для публичного интерфейса. Это небольшое замечание охватывает всю суть вопроса. Отрасль так стандартизировала бэк-офисные основы CRUD-программ, что основные фреймворки теперь поставляются с этим из коробки. Остаётся сложным не само техническое обеспечение, а определение того, какие сущности, состояния и рабочие процессы действительно важны для вашей компании, а какие присутствуют лишь потому, что какой-то поставщик потратил двадцать лет на сбор особенностей определённого сегмента рынка.
Вот где индивидуальные решения однозначно побеждают. Преимущество заключается не в виртуозности кода, а в семантической точности. Сущности могут соответствовать тому, как компания действительно функционирует: её иерархии продуктов, исключения в закупках, статусы поступлений, правила утверждения, причины возвратов, контроль качества, а также странные, но полезные различия, которые не должны быть понятны универсальному пакету. Небольшой локальный код остаётся понятным. Более того, компания сохраняет контроль над операционными знаниями, воплощёнными в этом коде. Программное обеспечение отражает бизнес; бизнес больше не вынужден наследовать компромиссы, накопленные на протяжении всей истории клиентской базы поставщика.
Что изменили агенты кодирования
То, что изменилось в 2025 году, — это не база данных, не браузер и не веб-стек. Изменилось то, насколько снизились затраты на производство кода. В январе 2025 года Anthropic сообщил о 49-процентном результате по тесту SWE-bench Verified для обновлённого агента Claude 3.5 Sonnet. К августу Claude Opus 4.1 достиг 74,5 процента. Команда SWE-bench позже отметила, что мини-SWE-агент достиг 65 процентов по тому же проверяемому набору в минимальной установке. OpenAI, со своей стороны, выпустила Codex как облачного программного агента, способного одновременно выполнять множество задач, запускать тесты и анализаторы кода в изолированных средах и предлагать изменения для проверки; в отдельном внутреннем эксперименте OpenAI сообщила, что Codex написал кодовую базу в миллион строк, затратив примерно одну десятую времени, которое потребовалось бы на ручное кодирование.
Это не означает, что агенты ускоряют работу каждого инженера на каждой кодовой базе. Рандомизированное исследование METR, проведённое на опытных разработчиках с открытым исходным кодом, показало, что инструменты ИИ начала 2025 года замедлили их работу на 19 процентов, когда они работали над собственными репозиториями. Я воспринимаю этот результат всерьёз. Однако он не описывает ту же проблему. Поддержание зрелой публичной кодовой базы с высокими стандартами и годами неявного контекста — это не то же самое, что разработка рабочего процесса приемки, портала для поставщиков, бэк-офиса для корректировки запасов или экрана возвратов для внутренней команды. В последних случаях требования локальны, критерии приёма конкретны, а архитектура обыденна. Отдельное исследование временных горизонтов от METR также сообщает, что продолжительность задач, которые агенты могут выполнить с надёжностью в 50 процентов, удваивается примерно каждые семь месяцев. Именно такая тенденция имеет значение, когда работа узкая и хорошо определена.
Вот почему даже обычный производитель, дистрибьютор или ритейлер теперь может разумно владеть значительно большей частью своего транзакционного программного обеспечения, чем раньше. Такая компания не обязана превращаться в поставщика программного обеспечения. Ей необходим владелец процесса, разбирающийся в бизнесе, технически грамотный руководитель, небольшая кодовая база, набор тестов и дисциплина, чтобы сохранять узкий охват задач. Агенты кодирования сокращают объём ручного программирования для рутинных частей, которые, как оказалось, составляют большую часть систем учёта. Тем временем зрелый стек с открытым исходным кодом берёт на себя остальное. Это сочетание мощно именно потому, что системы учёта не кажутся гламурными. Это в основном формы, таблицы, проверки, разрешения, рабочие процессы и интеграции. Именно там инструменты являются самыми сильными.
Я бы всё же оставил за бортом те области, где основная ценность поставщика заключается в своевременном обновлении в соответствии с законодательными изменениями. Это реальные исключения. Вне их, особенно в цепочке поставок, по умолчанию ситуация должна быть обратной. Для процессов закупки, приёма, возвратов, контроля качества, сотрудничества с поставщиками, управления мастер-данными и аналогичных транзакционных областей обширное пакетное программное обеспечение стало дорогостоящим способом добиться посредственного соответствия. Альтернативное индивидуальное решение теперь доступно не только технологическим компаниям. Оно доступно обычным фирмам, если они готовы владеть скромным объёмом кода и противостоять искушению превратить эту кодовую базу в грандиозную платформу.
Дело уже не носит сентиментальный характер и не выглядит футуристичным. Обширные пакетные регистры по своей конструкции универсальны, по привычке не соответствуют требованиям и сопряжены с инфляцией как стоимости, так и внимания. Инструменты для создания узких замен зрелы уже много лет. Агенты кодирования теперь устранили последнюю проблему, которая раньше останавливала многие компании, а именно огромное количество рутинного программирования. Для систем учёта в цепочке поставок бремя доказательства перевесило. Компания должна начать с вопроса: почему эту систему следует покупать вообще.
