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