О том, как перейти с SAP на 1С, превысив бюджет в три раза

Поскольку я подписывал NDA, но не читал его, сразу скажу, что все совпадения случайны, персонажи вымышлены, и все это происходило в параллельной вселенной с сыном маминой подруги, назовем его Вася. Я с ним не знаком, просто слышал.

О чем идет речь? Есть очень крупный международный холдинг, где-то 60 с лишним стран, занимается производством цемента. Это крайне высокомаржинальный бизнес. В России тоже есть подразделения – там 2000 человек, несколько производственных площадок. Бизнес-процессы не очень эффективные, потому что денег много: можно особо не мелочиться, не экономить и все проблемы заливать деньгами.

Про ландшафт: я не стал рисовать схему AS-IS, потому что там более 100 различных, сильно связанных между собой систем. Все, что здесь перечислено, вряд ли каждый из вас знает, не говоря уже о том, чтобы внедрять это весь массив. Это в голову одного человека никогда не поместится.

И тут возникает 2022 год.

Геополитические риски и необходимость локализации IT

Становится невозможным выводить прибыль за границу. Помимо этого возникают геополитические риски – отключение интернета, например: завтра нам отключат интернет или введут невероятные санкции, и компания может оказаться парализована, потому что подавляющая часть IT-инфраструктуры находится за рубежом и управляется оттуда. Надо срочно ее локализовать; возможно даже продать компанию, но продать нельзя, пока не локализовали IT, на котором все держится.

Что же делать? Возникает мандраж и истерика. Приглашают CDTO – директора по цифровой трансформации.

Сразу про действующих лиц: во главе у нас SEO – это исполнительный директор. Ему подчиняется CFO – финансовый директор. Ему подчиняется директор по IT и новый сотрудник CDTO, директор по цифровой трансформации. Он приходит и получает задачу: нужно сделать так, чтобы при отключении международного интернета компания могла дальше жить. В головах начинаются жуткие метания из серии: «Давайте кусочек SAP отрежем у себя и развернем в России? Или внедрим какую-нибудь Галактику?» В общем, всякая дичь.

Этап ассессмента и формирование команды

Со временем все утрясается, и CDTO принимает правильное решение – провести этап ассессмента.

В крупных проектах, помимо оценки, обследования и непосредственного внедрения, есть этап ассессмента – предварительной оценки. Это скетч крупными мазками будущей информационной системы.

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

Дальше CDTO должен был сформировать программу проектов и проектные команды, нанять персонал под эти команды.

Но возник нюанс: когда CDTO пришел к исполнительному комитету, ему сказали: «Какие люди, какие проектные команды? У тебя есть подрядчики, вот они пусть все и делают. Зачем нам люди в штате?»

Три-четыре месяца он объяснял, что любой Равшан или Джамшут требует надзора. Даже если он работает в большом интеграторе, за ним все равно нужно наблюдать со стороны заказчика. Без архитектурного надзора успешного проекта не бывает. Долго и упорно он добивался команды архитекторов, РП и техподдержки. В итоге одобрили двух архитекторов и двух РП.

Остальное – из собственных ресурсов. Возникает вопрос: даже тех же РП где брать? Люди есть, но они не имеют опыта проектного управления и тем более IT-опыта. Решили, что ничего сложного нет – научатся по ходу дела.

Основной бизнес-процесс

Основной бизнес-процесс заключается в том, что заказчик отправляет заявку в Customer Service. Там проверяют, сколько у него денег, и дают команду в логистику. Логистика ищет на бирже машину, которая повезет заказ.

Допустим, нужно перевезти 5000 тонн цемента. В назначенный день машины начинают приезжать, система отгрузки пускает их на территорию предприятия и помогает загрузить. Все это отвозится клиенту. Документы, связанные с торговлей, проходят через систему EDI – не юридически значимого электронного документооборота, а закрывающие документы – через систему юридически значимого электронного документооборота.

Это схема сильно упрощенного целевого ландшафта. В центре – 1С:ERP.УХА. Полтора месяца шли споры о том, как построить архитектуру: нужен ли ERP, УХ или обмен между ними. В итоге из-за сжатых сроков приняли текущее решение.

Два важных момента: бюджет оценен в полмиллиарда, срок реализации – полтора года. Полгода до начала 2023 года – этап предпроекта, весь 2023-й – проект и переход в ОПЭ с 1 января 2024 года.

В ядре – ERP.УХ. Из важного стоит упомянуть транспортную логистику экспедирования, систему управления отгрузкой, о которой будет сказано отдельно, и решения на основе Битрикс: Битрикс24 и Битрикс УС в роли B2B/B2C клиентского портала.

Это roadmap по локализации, о котором только что шла речь. Видно, что программа проектов распределена по месяцам, но ничего не было реализовано в том виде, в котором планировалось.

Организация проекта и роль подрядчиков

Под каждый проект назначался свой РП, под каждый проект – отдельный подрядчик и так далее. Все по-взрослому.

Вы знаете, что такое теневое ИТ? Сталкивались с ним на практике? Коротко: есть централизованное ИТ, а в каком-нибудь подразделении, например в коммерческом департаменте, существует своя независимая ИТ-служба. Она считает, что у нее своя епархия, и просит не вмешиваться. Управлять ею можно лишь условно, влиять на решения – приблизительно. У нее отдельные отношения с подрядчиками, собственная служба технической поддержки, и она может послать куда угодно CDTO.

CDTO, увидев этот бардак, с шашкой наголо бросился в бой, чтобы победить этих супостатов, и проиграл. В результате служба теневого ИТ в коммерческом департаменте как существовала, так и осталась, и даже отчиталась об успешном внедрении.

Сжатие сроков и последствия

Теперь про реализацию. Изначально, когда исполнительный директор услышал срок полтора года, ему, наверное, стало не по себе, но в целом он этот срок воспринял и принял. В ноябре 2022 года, когда были утверждены основные действующие лица проекта, от него вдруг поступила команда: переход в ОПЭ не 1 января 2024 года, а 1 апреля 2023-го – на девять месяцев раньше.

Как известно, заказчик всегда ищет волшебника, а находит сказочника. Наши сказочники взяли под козырек и сказали: «Будет сделано». Разумеется, ничего не было сделано в указанный срок. Более того, когда дело дошло до этапа интеграционного тестирования и заказчики увидели MVP, они сказали: «Ребят, нас это не устраивает». – «Как не устраивает? Вы же подписали». – «Да, подписали». – «Мы сделали в соответствии с тем, что вы написали». – «Да, сделали». – «Принимайте». – «Не примем. Нас не устраивает».

Это так называемая валидация. В крупных организациях это этап, когда после выполнения работ возвращаются к заказчику и уточняют, нужно ли ему это еще или можно выбросить в мусорку.

Позже было принято решение провести второй этап и доработать замечания, но все это произошло по одной причине: вместо года на реализацию осталось четыре месяца, и этап ОПЭ по основным проектам не провели, его просто скомкали, и в результате не выявили большое количество функциональных требований.

Взяли двух архитекторов, в том числе Васю – классного функционального архитектора. Учредили архитектурный комитет, который должен был решать стратегические задачи и выполнять роль законодательной власти. Но не подумали об исполнительной власти. В итоге исполнялось дай бог 10% решений архитектурного комитета, на остальные просто спокойно забивали.

Сложности с тестовыми данными

Далее, в процессе решения задачи о том, как будет выглядеть целевой ландшафт, внезапно всплыла масса требований, которые кардинально меняли или усложняли реализацию.

Пример: CIO заявил, что не даст ЗУП в тестовый контур и контур разработки, потому что не позволит никому видеть свою зарплату. Зарплаты – чувствительная информация, и если их увидит конкурент, это может привести к краху бизнеса.

Что делать? Есть два варианта: обфускация данных, когда имена заменяются на абракадабру, или заполнение пустой базы демоданными. Система сильно интегрирована и содержит множество потоков, поэтому обфускация не подошла. Пришлось выбрать более сложный вариант с демоданными.

В результате добавили второй тестовый контур для демоданных. Методологи и разработчики работали в этих двух контурах с тестовыми данными, а пользователи тестировали на отдельном уровне. Второй, препродуктивный контур настоял добавить Вася – это daily copy, ежедневная копия продуктивной базы.

Технические архитектурные решения

Тезисно упомяну, что в основу архитектуры обменов были заложены смелые технические решения.

Во-первых, в основу уровня представления данных был положен формат Enterprise Data, который в дальнейшем планировалось перенести на шину данных. До шины дело не дошло – решение было заблокировано директором по IT.

Все потоки данных описывались через Enterprise Data. Это была масштабная работа.

Во-вторых, использовался асинхронный обмен данными. Из-за плохих каналов связи и периодического отсутствия интернета по 8–10 часов архитектуру пришлось выстроить так, чтобы все данные были денормализованы и каждая информационная система содержала только те данные, с которыми работает. Эти данные попадали в систему в момент их появления в результате обменов.

Таким образом, мы отказались от синхронной схемы, когда алгоритму в одной системе нужно сделать запрос в другую, дождаться ответа и только потом продолжить работу. Это решение было принято из-за непредсказуемости каналов связи.

Хранилище данных и миграция НСИ

Одной из самых сложных задач стала миграция НСИ.

Для Васи в процессе этого челленджа часто повторялся один и тот же психологический феномен – пять стадий принятия неизбежного. Сначала это забавляло, потом стало привычным. В данном случае CDTO заявил, что никакой нормализации данных делать не будут – нет времени. В итоге пришлось его убедить, и нормализация все-таки проводилась, причем многоэтапно.

Миграция выполнялась срезами, всего их было четыре. На схеме показан только один из циклов миграции.

В процессе моделирования данных решалось множество задач по их преобразованию. Некоторые данные, которые были смешаны в одном справочнике, приходилось разделять. Например, справочник WBS (Work Breakdown Structure) содержал все подряд.

Часть данных, наоборот, объединяли в ключи аналитики, потому что в 1С не хватало измерений, чтобы учесть все необходимое.

Некоторые данные мы трансформировали. Например, из одного справочника номенклатуры сделали два – производственный и коммерческий, четко разделив их по назначению.

Преобразовывали и адреса: если раньше они хранились в строках, теперь – в привязке к классификатору, Государственному адресному реестру. В процессе проекта было решено множество технических и очень интересных задач.

Система отгрузки и интеграция с исторической системой

Одно из самых интересных решений – обмен с исторической системой отгрузки.

CDTO задал вопрос: в чем проблема? Проблема в том, что на платформе 1С и вообще в России нет готовых решений, удовлетворяющих функциональным требованиям. Их просто не существует. Нужно с нуля разрабатывать полноценную систему отгрузки. Сроки при этом были крайне сжатые.

Вася предложил взять историческую систему отгрузки, интегрироваться с ней, а уже потом вместе с командой 1С-разработчиков создать новое решение. Ему ответили: «Нет, это черный ящик, мы ничего о нем не знаем. А кто возьмет на себя ответственность?» Ключевая фраза – «кто возьмет на себя ответственность».

В итоге решение все-таки продавили. Изучили образцы сообщений обмена, сделали мэппинг, реализовали интеграцию разными способами – через SOAP и через прямой доступ к SQL.

Решили проблему с RFID-картами – это когда водитель подъезжает к точке отгрузки, например к силосу или шлагбауму, и должен приложить карточку. Эти карты пришлось взломать и реплицировать, чтобы интеграция заработала.

Позже создали новую систему отгрузки уже на платформе 1С. В процессе отгрузки задействовано множество действующих лиц и информационных систем, между которыми проходит много сообщений. Хотя кажется, что все просто: подъехал к силосу, нажал кнопку, загрузился на 25 тонн и уехал – на деле процесс гораздо сложнее.

Go-live и управление переходом

Еще одной спецоперацией стал переход в go-live, то есть в опытно-промышленную эксплуатацию (ОПЭ).

Роль управления этой операцией взяла на себя функциональный архитектор. Она детально расписала по каждому проекту, кто и что должен делать в час X – с точностью до минуты. Переход осуществлялся методом «большого взрыва»: в ночь с 30-го на 1-е старые системы отключили, новые запустили. Эту операцию она провела блестяще.

Итоги и выводы

Переход состоялся, но с множеством нюансов. Бюджет превышен втрое только по основному бизнес-процессу, остальное даже не считали. В итоге сумма превысила два миллиарда.

• Данные в обменах теряются, потому что не все потоки реализованы,

• Время проведения документа - 7 секунд,

• На проекте отгрузок, до сих пор не законченном, РП меняются каждые 3-6 месяцев,

• Костяк команды внедрения уволился, новая команда поддержки, по мнению сотрудников, не способна даже полноценно поддерживать систему, не говоря о развитии.

Причины, по которым все это произошло:

• Недостаток персонала со стороны заказчика: архитекторы, внутренние методологи, служба поддержки внедренного решения (декларации на словах постоянно расходились с делом). Те же услуги у вендора намного дороже.

• Поскольку ФА и ТА не имели помощников, успевать качественно прорабатывать все архитектурные вопросы не успевали.

• Сдвиг сроков на 9 месяцев вперед (срок изначально нереальный).

• Отсутствие предпроекта по ключевым проектам.

• Созданное решение не удовлетворяло минимальным требованиям заказчика.

• Риторические войны, затягивание принятия решений: совещания с 10-40 высокоуровневыми участниками, на которых все ругаются и ничего не решают, забалтывание проблем.

• Неисполняемые обещания со стороны CIO: многократно срывались сроки как развертывания инфраструктуры, из-за чего пришлось арендовать ее в облаке, так и по созданию команды техподдержки.

• Блокирование архитектурных решений со стороны CIO, микроменеджмент. Требования к безопасности данных абсурдны, их реализация не была подкреплена ресурсами.

• CIO и CDTO были на одном уровне, в случае конфликта интересов формально должны были договориться, фактически CDTO всегда уступал.

• Теневой ИТ: начальник ИТ-подразделения в продажах пользовался покровительством так высоко, что CDTO не способен был ни отстранить его, ни повлиять на принимаемые решения. Он директивно продавил ту систему, которую хотел и с тем подрядчиком, которого хотел, напрямую выстроил все коммуникации и создал независимую техподдержку. Позиция: делайте, что хотите, но в коммерческом отделе – своя епархия.

Еще стоит отметить наличие скрытых интересов участников, которые во многом определили результат проекта:

• CEO – получить максимальную независимость от глобальной компании в кратчайшие сроки.

• CFO – всеми силами защитить своего близкого человека CIO, демонстрировавшего некомпетентность в новых условиях.

• CIO – стать единым центром принятия решений, заблокировать любые процессы, не включающие его как управляющее или согласующее лицо (единственное исключение – теневой ИТ с протеже в ком. отделе).

• CDTO – ни с кем не ссориться, продержаться до конца, получить «вознаграждение» со стороны подрядчиков.

• Теневой ИТ – не потерять «синекуру», получить «вознаграждение».

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.