Примечание редактора: этот пост в блоге написан Грегом Литтлом, старшим советником в Palantir, совместно с Аароном Джаффе, старшим вице-президентом в Palantir.
За более чем 10 лет внедрения систем планирования ресурсов предприятия (ERP) я помню один проект, на котором финансовый директор заставил всех замолчать. Было 11:30 вечера во время имитации перехода на новую систему. Люди были измотаны ручным исправлением проблем с сопоставлением данных, которые «должны были» быть автоматизированы. Финансовый директор поднял глаза, потер лицо и сказал: «Скажите мне еще раз, почему мы меняем всё, что делаем, только ради того, чтобы эта система была довольна?»
Это был справедливый вопрос. С самого первого ERP-проекта, над которым я работал, ожидание было неизменным: подстраивайте свои процессы под стандарты, определенные ядром ERP. Сохраняйте ядро в первозданном виде. Никогда не вносите изменения в базовое программное обеспечение. Следуйте процессу в точности так, как он был предоставлен. Не отклоняйтесь. Не меняйте ничего, что может поставить под угрозу возможность обновления или привести к задержкам, перерасходу средств или хрупкости системы. И, справедливости ради, для этого были веские причины.
Ядро ERP было спроектировано так, чтобы быть стандартизированным, стабильным и надежным. Оно стало основой для финансов, HR, закупок и цепочек поставок — местом, где живут комплаенс и подотчетность. ERP рассматривала каждый бизнес-процесс как нечто, что можно стандартизировать для любой организации в рамках единой структуры. Если ядро ERP дает сбой, рушится всё.
Но в какой-то момент защита этого ядра стала означать принесение в жертву гораздо более важных вещей: идентичности организации, ее дифференцированных процессов и способов, которыми она действительно создает ценность. Более глубокая проблема заключается в том, что традиционное корпоративное программное обеспечение было построено на жесткой логике, которая относится к каждой организации так, будто они все одинаковые. Традиционный подход ERP решал задачу стандартизации, но при этом подавлял уникальность. Именно в этой уникальности — будь то отличительная бизнес-модель, преимущество в цепочке поставок или реальность миссии — заключается конкурентное преимущество. Уникальность — это не ошибка, которую программное обеспечение должно стирать; это функция, которая позволяет вам быть впереди. Когда программное обеспечение диктует жесткую структуру, различия становятся слабостью. Когда программное обеспечение адаптируется к гибкости организации, различия становятся силой.
Это осознание ударило еще сильнее, когда я читал одну из любимых книг моей дочери — «Смешанный хамелеон» Эрика Карла. В этой истории хамелеон постоянно пытается стать кем-то другим — фламинго, слоном, жирафом, тюленем — в надежде, что каждая новая форма сделает его лучше. Но чем больше он пытается быть всем остальным, тем больше теряет свою идентичность. К концу он настолько запутывается, что даже не может поймать муху, чтобы поесть. Я наблюдал, как организации делают то же самое во имя «стандартного фундамента», настолько сильно изгибаясь, чтобы соответствовать структуре, продиктованной ERP, что теряют то, что когда-то делало их эффективными.
Старая поговорка — бизнес должен адаптироваться к программному обеспечению — имела смысл, когда код, масштаб данных и инфраструктура были барьерами. Жесткое программное обеспечение в сочетании с последовательным внедрением через консультантов и системных интеграторов было руководством к действию для обеспечения успешной цифровизации. Но мы больше не живем в том мире. Сегодня надежность и адаптивность больше не конкурируют друг с другом; они могут сосуществовать — организации могут быстро и гибко развивать возможности, обеспечивая при этом стабильность.
Чтобы внести ясность, существует огромная ценность в стандартных процессах, которые поставщики ERP совершенствовали десятилетиями. Эти «лучшие практики» не были изобретены в вакууме — они были сформированы тысячами внедрений, нормативными требованиями и уроками, извлеченными с трудом в разных отраслях. На самом деле, в подавляющем большинстве случаев следование стандартизированному процессу — это правильный шаг. Это приносит дисциплину, последовательность, проверяемость и финансовую целостность. Но ни один поставщик ERP не может предвидеть точный способ, которым каждая организация создает ценность. У каждого бизнеса есть несколько процессов, где его уникальность является преимуществом. Эти области никогда не должны принудительно приводиться к единообразию только потому, что система не может адаптироваться. В прошлом у организаций не было выбора; сегодня, благодаря адаптивной архитектуре, он наконец появился.
Palantir предоставляет новую техническую модель, которая делает это возможным. Вместо настройки ядра ERP, поверх него располагается уровень интероперабельности, соединяющий устаревшие и современные системы. Общая онтология определяет смысл предприятия — его концепции, связи, бизнес-логику, события и границы безопасности — так, что когда ERP называет что-то «материалом», а система цепочки поставок называет это «позицией», а складская система называет это «складским номером», архитектура понимает, что они относятся к одному и тому же. Онтология становится Розеттским камнем корпоративных систем, гарантируя, что ERP не обязательно должна быть единственным источником смысла, чтобы оставаться единственным источником записи.
Основная система онтологии обеспечивает уровень адаптивности и расширения, где живут бизнес-логика, рабочие процессы, автоматизация и пользовательский опыт. Именно здесь работают агентный ИИ и инженеры-люди — создавая приложения, обновляя модели данных, разрешая противоречия и автоматизируя целые цепочки работ — всё это поверх общего уровня безопасности и управления. Это расширяет данные в ядре ERP до сред, в которых работает организация — сборочная линия, автопарк, поле боя — обеспечивая двустороннее использование в реальном времени на любом форм-факторе в момент необходимости. Поскольку эта система гибкости находится вне ядра ERP, организации могут чисто мигрировать на новейшую ERP, сохраняя при этом процессы, которые делают их уникальными. Это также первая архитектура, где миграция данных является упражнением, управляемым программным обеспечением и онтологией. Вместо армий консультантов по бизнес-процессам, вручную сопоставляющих поля, разрешающих дубликаты и очищающих данные в течение многих лет, агентные системы могут согласовывать структуры, устранять расхождения, тестировать транзакции и проверять результаты непрерывно по мере работы бизнеса. В этой модели миграция — это не разовая травма, она становится живой, итеративной возможностью.
Именно поэтому традиционная модель системной интеграции разваливается. Она не была создана для этого мира. Она была создана для времени, когда системы были жесткими и менялись медленно. Сложность управлялась за счет использования рабочей силы для проектирования, создания и запуска сериализованных процессов. Результат был предсказуем: подавляющее большинство бюджетов ERP-программ уходило на оплату труда (консалтинг). Программное обеспечение было наименьшей частью структуры затрат. И слишком часто после всей этой работы организации получали не трансформацию, а перевод. Та же самая сложность не управлялась, она просто была переупакована.
Основная проблема заключалась не в том, что консультанты были плохими специалистами. Проблема была в самой модели, основанной на почасовой оплате за ручную интеграцию систем. Она была оптимизирована под количество сотрудников, а не под результат. Она решала проблемы архитектуры вчерашнего дня, вместо того чтобы открывать возможности сегодняшнего. Этот мир ушел в прошлое. Современные предприятия не могут позволить себе многолетние внедрения и операционные модели, ориентированные на консультантов, когда подходы, ориентированные на программное обеспечение, позволяют переносить, интегрировать и адаптировать системы для достижения лучших, более быстрых и дешевых результатов.
Ничто не обнажило ограничения модели, ориентированной на ручной труд, более четко, чем миграция данных. Интеграторы выставляли счета за тысячи часов работы по ручному сопоставлению и очистке данных — работу, которую современный ИИ теперь может выполнять за считанные минуты с большей точностью и возможностью отслеживания. Миграция раньше была барьером на пути к модернизации — той частью программы, которой все боялись. Но когда сама миграция становится автоматизированной, все уравнение меняется.
Разница между «до» и «после» разительна. Раньше сотруднику отдела закупок приходилось работать с несколькими системами и многократно вводить одни и те же данные только для того, чтобы инициировать простую покупку. Люди становились «смотрителями» ERP. Теперь сотрудник просто говорит: «Закупи 200 запасных частей по этому контракту, используя эту статью расходов», и система автоматически проверяет финансирование, создает документы, направляет их на утверждение и отмечает исключения. Никаких экранов. Никаких кодов. Никакой переписки по электронной почте. Часто даже не требуется вход в систему. Такая же трансформация происходит при оформлении новых сотрудников в HR, в логистике, при закрытии финансового периода и в любой бизнес-функции, которая раньше была вынуждена подстраиваться под жесткую систему. Более глубокий смысл заключается в том, что уникальность и адаптивность не создают хаос. Чистое ядро ERP — это фундамент; оно должно оставаться стабильным, стандартизированным и надежным. Но поверх этого фундамента общая онтология, надежная безопасность и уровень адаптивности гарантируют, что агенты и операторы-люди работают с одними и теми же данными, даже когда рабочие процессы меняются и развиваются. Это структурированная адаптивность, а не анархия.
Поработав над более чем 15 крупными внедрениями корпоративного программного обеспечения, я пришел к выводу, что старую поговорку пора переписать. Вопрос больше не в том, может ли бизнес адаптироваться к программному обеспечению, а в том, способно ли программное обеспечение адаптироваться к бизнесу. Это различие имеет значение, потому что гибкость — это одновременно и кошмар, и амбиция любого технического директора. Полная кастомизация — это ловушка: она нарушает обновления, увеличивает технический долг и меняет одну форму жесткости на другую. Правильная модель — это не кастом, а гибкость. Вы покупаете платформу ради того, что она делает лучше всего — стабильности, соответствия требованиям, финансовой целостности, — и строите поверх нее то, что делает вашу организацию уникальной. Ядро ERP никогда не меняется. Меняется уровень над ним: рабочие процессы, семантические и кинетические модели, пользовательский опыт. Это та архитектура, которая позволяет предприятиям развиваться, не начиная все с нуля.
В эпоху агентного ИИ доминировать в следующем десятилетии будут те организации, которые адаптируют свое программное обеспечение так же быстро, как меняется мир. Это не технологический выбор, а стратегический. Он определяет, продолжите ли вы менять свою форму, как хамелеон из книги моей дочери, или наконец создадите системы, достаточно уверенные в себе, чтобы отражать то, кем вы являетесь на самом деле.
Хамелеоны выживают, сливаясь с окружением. Предприятия побеждают, выделяясь. Содержите ядро ERP в чистоте. Расширяйте его с помощью адаптивности. Мигрируйте быстрее благодаря автоматизации. Обеспечивайте взаимодействие везде через онтологию. И заставьте программное обеспечение адаптироваться к вам, а не наоборот. Это означает полное изменение уравнения. Перестаньте вносить все в свою ERP в надежде получить обратно то, что вам нужно. Вместо этого сначала извлекайте из своих данных все, что вам нужно, а затем вносите в ERP только то, что финансовый отдел, аудитор или регулятор отказываются принимать в любом другом виде. ERP становится тем, чем она всегда должна была быть: системой учета для подотчетности, а не системой ограничений для операционной деятельности.
