UCLA начал досудебные переговоры с Oracle на фоне затянувшейся почти на шесть лет финансовой трансформации. История про UCLA и Oracle важна не только университетам: это наглядный разбор того, как большой SaaS-проект на сотни миллионов может упереться не в код, а в поддержку вендора, лицензии и банальный вопрос, продолжать ли вообще вместе.
По данным The Register, в повестке комитета по комплаенсу и аудиту регентов Калифорнийского университета появился пункт о предлагаемом урегулировании с Oracle America по предполагаемому нарушению контракта. В самом UCLA публично детали не раскрывают и ограничиваются формулировкой о том, что университет оценивает «наиболее эффективный путь вперед» для модернизации финансовых систем. Oracle на момент публикации комментарий не дала.
Если перевести этот осторожный язык с корпоративного на нормальный, сигнал читается довольно прямо: проект Ascend 2.0, который должен был перевести финансы, закупки и исследовательское администрирование UCLA на Oracle Cloud SaaS, зашел в тяжелую фазу. И речь уже не о типичной пробуксовке внедрения, а о предсудебном споре с одним из ключевых поставщиков. Для любой крупной организации это худший сценарий из тех, что обычно не рисуют на красивых слайдах в начале цифровой трансформации.
Сам проект стартовал в апреле 2018 года и изначально должен был завершиться в июле 2020-го. Его задача выглядела предсказуемо для ERP-класса: заменить старые финансовые системы, перенести процессы в Oracle Cloud SaaS и заодно доработать интеграции со всеми связанными платформами. Один из модулей, закупочный BruinBuy Plus, все же ввели в эксплуатацию в январе 2024 года. Но основной запуск Oracle Financials с 2 августа 2024 года поставлен на паузу и с тех пор проходит переоценку. То есть университет успел дойти до болезненной стадии, когда часть новой архитектуры уже живет, а ключевое ядро по-прежнему не взлетело.
Шесть лет задержки и спор о вендоре
Самый показательный фрагмент в этой истории не про громкие формулировки, а про скучные управленческие документы. В отчете, который в марте прошлого года представили комитету по финансам и капитальной стратегии регентов, среди главных проблем проекта отдельно указали недостаточную отзывчивость Oracle, особенно по вопросам стоимости лицензий и поддержки. Для CIO, руководителей ERP-программ и продактов это знакомый красный флаг: когда внедрение уже буксует, а поставщик при этом медленно отвечает на вопросы по лицензированию и саппорту, проблема почти всегда выходит за рамки чисто технической.
Там же зафиксированы и цифры, которые делают картину еще менее академической. Согласно этому документу, первоначальный бюджет проекта в 120 млн долларов был пересмотрен вниз до 98,9 млн, а на тот момент потрачено было 13,5 млн долларов. Но параллельно университетская газета Daily Bruin со ссылкой на презентацию квартального town hall по Ascend 2.0 в мае 2024 года писала уже о совсем другом масштабе: общая стоимость оценивалась примерно в 286 млн долларов, из которых около 213 млн уже израсходованы. Эти оценки не совпадают между собой, и именно это отдельно настораживает. Когда вокруг трансформации гуляют разные бюджеты и разные точки отсчета, значит у проекта проблемы не только с поставкой, но и с прозрачностью управления.
Внутри UCLA сомнения, похоже, давно вышли на уровень стратегического выбора. В материалах по проекту прямо упоминался план определить, стоит ли продолжать работу с текущим поставщиком или пора смотреть альтернативы. Иными словами, вопрос уже не в том, как быстрее завершить внедрение, а в том, жизнеспособна ли вообще текущая связка заказчик плюс вендор. Для SaaS-рынка это неприятная, но важная развилка: подписка сама по себе не отменяет старые риски ERP, а иногда даже добавляет новые, потому что клиент сильнее зависит от темпа, коммерческой политики и поддержки облачного поставщика.
Отдельный слой контекста связан с тем, что UCLA, по данным Daily Bruin, до сих пор опирается на унаследованные финансовые системы, созданные еще в 1980-х, когда операционный бюджет университета составлял лишь 7 процентов от нынешнего уровня. В одном из комментариев такую платформу описали как «древний реликт» на мейнфрейме. Это хороший пример вечной ловушки enterprise-ИТ: старую систему все ругают, но она хотя бы работает; новую все хотят, но переход на нее может превратиться в многолетний и очень дорогой управленческий кризис. Поэтому спор UCLA и Oracle читается не как локальная университетская драма, а как предупреждение любому крупному заказчику, который думает, что переезд в облачный ERP-контур сам по себе решает проблему технологического долга.
Что из этого следует для рынка
Для разработчиков и архитекторов здесь важен не только юридический сюжет. Такие кейсы показывают, что в крупных трансформациях интеграции, данные, контрактные условия и операционная модель поддержки живут в одной связке. Если закупочный модуль уже запущен, а финансовое ядро заморожено, команда получает гибридный ландшафт с повышенной сложностью: часть процессов идет через новый стек, часть остается в старом мире, а между ними надо сохранять консистентность данных и управляемость процессов. Это дорого, нервно и редко выглядит как история про «немного сдвинули дедлайн».
Для бизнеса урок еще жестче. При выборе SaaS-платформы недостаточно смотреть на демо, роадмап и бренд поставщика. Нужно заранее проверять, как устроены эскалации, кто отвечает за спорные вопросы по лицензиям, насколько быстро вендор реально реагирует в кризисной фазе и что произойдет, если проект придется разворачивать, замораживать или частично пересобирать. История UCLA и Oracle напоминает: в больших ERP-внедрениях договор и операционная дисциплина порой важнее презентаций про cloud-first.
Теперь главный вопрос в том, чем закончится эта переоценка: мировым соглашением, продолжением работы с Oracle или новым разворотом всей программы. Для рынка сигнал уже прозвучал. Даже у организации масштаба UCLA переход на облачную ERP-платформу может превратиться из модернизации в спор о контракте, поддержке и доверии к вендору. А это значит, что в следующих крупных тендерах заказчики будут внимательнее смотреть не только на функциональность продукта, но и на то, как поставщик ведет себя в момент, когда красивый проектный план перестает быть красивым.