Британский город-миллионник обанкротился из-за смены софта?

Самая громкая новость недели в мире внедрения ERP-систем. Разбираем вместе с руководителем корпоративных практик ALP Group Александром Казенновым.

Что произошло?

Во вторник, 5 сентября, городской совет Бирмингема, второго по величине города Великобритании после Лондона, объявил себя банкротом. Все расходы, за исключением самых необходимых, были заморожены, а совет попросил финансовой помощи. Главная причина зияющей дыры в городском бюджете — проект по переводу системы цифрового управления финансами и персоналом с немецкого решения SAP на американский Oracle.

С подачи представителей городского совета, СМИ винят во всём как раз корпорацию Oracle: ИТ-проект под названием «Финансы и люди» затянулся на 5 лет, сроки постоянно сдвигались, а смета проекта раздулась с £20 млн почти до £100 млн.

Что интересно, сама Oracle считает проект большой победой. Основатель и CTO компании Ларри Эллисон (к слову, один из богатейших людей в мире по версии Forbes) упоминал городской совет Бирмингема в числе успешно осуществленных переездов с SAP.

При этом источник издания The Register сообщает, что ERP-система Oracle изначально не подходит для нужд местных органов власти и в большей степени рассчитана на производственные и торговые организации. Он также добавил, что система SAP, которую власти Бирмингема использовали годами, была очень сильно кастомизирована под требования городского совета. По его словам, реализовать аналогичные функции в системе Oracle — довольно трудновыполнимая задача.

Комментарий ALP Group

Что хочется сказать: большое «спасибо» СМИ за желтые заголовки. Я сильно сомневаюсь, что город-миллионник стал банкротом по вине Oracle. Посудите сами. Если в начале Oracle договорилась с властями Бирмингема о том, что за £20 млн будет выполнен переход с одного решения на другое, и при этом получила на вход качественно сформулированные требования, то она бы была обязана за £20 млн и закончить эти работы. Раз смета разрослась в 5 раз, значит, каждый раз у подрядчика были на это какие-то объективные причины и, более того, заказчик эти причины подтверждал.

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

Как правило, изменения сроков проекта или его бюджета происходят по причине изменений требований заказчика. И здесь возникает много вопросов к городскому совету Бирмингема. Зачем в принципе было что-то менять, если у совета уже было работающее решение? Раз кто-то пролоббировал необходимость миграции ERP, какую задачу он хотел этим решить? Возможно, власти хотели оптимизировать процесс городского управления и решили, что продукт Oracle подходит лучше? Но вот нам сообщают, что решение Oracle рассчитано, скорее, на торговые компании…

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

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

Не помогло, вероятно, и то, что с 2018 по 2023 год у городского совета Бирмингема сменилось четыре исполнительных руководителя — а как известно, новый руководитель — это почти всегда новые требования.

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