Импортозамещение

Два-три года назад заказчики приходили к интеграторам с простым запросом: «У нас были западные CAD-, PLM- и ERP-продукты, подберите российские аналоги». Сейчас вопрос все чаще звучит иначе: «PLM мы уже внедрили. Как связать ее с MES, ERP и бизнес-аналитикой, чтобы данные передавались без потерь?» Это не значит, что переход на российское ПО завершен – предприятия находятся на разных этапах. Но характер запросов меняется.

Более того, раньше PLM нередко воспринимали как отдельный ИТ-проект: сначала как электронный архив, затем как инструмент управления разработкой изделия. Теперь от нее ждут работы в общем производственном контуре: состав изделия, спецификации, версии документов и сведения об изменениях должны переходить в MES и ERP, где они используются в производстве, закупках и планировании ресурсов. И вот здесь обычно начинается самая сложная часть проекта.

Каждый в своей экосистеме

После 2022 года на рынке появилось много новых промышленных продуктов, и многие вендоры начали развивать собственные экосистемы. Даже у зрелых PLM-, ERP- и MES-систем не всегда есть готовые коннекторы друг к другу, в итоге соединять продукты разных производителей приходится уже на стороне заказчика.

Открытый API позволяет связать их напрямую или через интеграционную шину, но не определяет, какие данные и по каким правилам будут передаваться. Так, сейчас мы участвуем в проекте по созданию инфраструктуры для нового производства. Партнерская команда внедряет ERP, наша – PLM. Мы настраиваем обмен между ними и отдельные модули, а затем еще будем проверять всю связку в опытно-промышленной эксплуатации.

Такие работы съедают заметную часть бюджета: например, по данным опроса Минпромторга, средняя стоимость внедрения PLM на крупном предприятии электронной отрасли оценивается примерно в 300 млн руб., а срок составляет около трех лет. При этом порядка 23% расходов уходит на интеграцию с другим ПО и оборудованием, еще 10% занимает миграция данных.

Государство компенсирует часть затрат через гранты, субсидии и льготные программы – эта поддержка помогает запустить проект, но настройка обмена остается задачей самого заказчика. Общие требования к совместимости только формируются: в 2024 году Минпромторг и Росстандарт запустили программу стандартизации PLM-систем, а в конце июня 2026 года Росстандарт утвердил первые стандарты для платформ промышленной автоматизации. Пока эти правила не заработали, каждое предприятие самостоятельно определяет порядок обмена данными в своих проектах.

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

Единый контур не заканчивается на границе холдинга

Даже если внутри крупного холдинга работает единая платформа, остается обмен с поставщиками и подрядчиками. Головное предприятие передает им 3D-модели, спецификации, конструкторскую документацию и извещения об изменениях, при этом участники производственной цепочки могут использовать совсем другие CAD- и PLM-системы.

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

Поэтому для крупного заказчика важна не только внутренняя интеграция. Еще до выбора PLM нужно понимать, как предприятие будет обмениваться данными с поставщиками: какие форматы они используют, какую информацию смогут принять и как конкретно им будут передаваться изменения.

Что проверить до закупки

До закупки стоит выяснить, с какими ERP-, MES- и аналитическими системами предстоит настроить обмен, есть ли для них готовые коннекторы и открытый API. Обычная демонстрация этого не покажет: вендор работает на подготовленном примере и внутри собственной экосистемы.

Совместимость лучше проверять на данных заказчика. В пилоте можно передать структуру изделия, внести изменение в документацию и посмотреть, как оно дошло до смежной программы. Заодно выяснится, что уже работает в коробке, какие модули придется настраивать и понадобятся ли отдельные коннекторы. Эти работы должны попасть в оценку проекта до выбора PLM, иначе их объем станет понятен уже во время внедрения, когда к покупке продукта добавится отдельная интеграционная задача со своими сроками и бюджетом.

Как не заменить одну зависимость другой

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

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

Автор – Николай Флягин, руководитель группы технической экспертизы Департамента решений САПР и ГИС «Софтлайн Решения» (ГК Softline)

По данным международных исследований, правильно выстроенное управление жизненным циклом продукта (Product Lifecycle Management, PLM) позволяет сократить время на его разработку до 30% и повысить эффективность компании до 40% в целом. Но что считать «правильно выстроенным»? И почему на практике переход на новую систему часто оборачивается операционным хаосом: кто-то работает в новой системе, кто-то по старинке, а производство не понимает, какая версия данных верная?

Как компании формулируют задачу – и что за этим стоит

После ухода вендоров российские компании оказались в разных ситуациях. Часть из них, пока лицензии действуют, работает на Siemens, PTC или SAP, другие в один момент лишились доступа к западным решениям и вынуждены менять PLM в цейтноте. При всей разнице в исходных условиях формулировки запроса у заказчиков во многом совпадают. Но за словом «PLM» в каждом случае понимают разный объем задач.

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

Встречается и запрос на решение, которое охватывает не только конструкторско-технологическую подготовку, но и весь производственный цикл. Чаще всего от компаний, которые еще несколько лет назад пытались решить задачу интеграции PLM с учетными системами, но тогда не получили ожидаемого результата. Теперь они возвращаются с пониманием, что им нужна сквозная цепочка.

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

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

Ограничения подхода «перенести как есть»

Проекты по замене PLM-систем, как правило, стартуют одинаково – с запроса «перенести все как было». Но через год возникает вопрос: «Зачем мы это сделали?».

Так происходит, потому что под переносом данных обычно подразумевается некий «магический» акт – все будет работать как раньше. На практике вместе с данными в новую среду переходят все накопленные искажения – дубли, несогласованные версии, устаревшие структуры. Часто о них либо просто не знают, либо привыкают с ними работать. После миграции эта разрозненность никуда не исчезает – она становится еще более явной. Из-за этого производство по-прежнему не получает однозначно актуальную информацию.

Для сложных изделий с 3D-моделями трансформация данных из NX или SolidWorks сама по себе становится отдельной задачей. При переносе «как есть» количество нюансов оказывается таким, что миграция превращается в цепочку временных решений.

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

Почему PLM не дает эффекта

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

Когда же система сталкивается с тем, как на самом деле строится структура изделия, проходят изменения, передаются данные, выясняется, что часть операций по-прежнему ведут в Excel, согласовывают по почте или закрывают вручную.

Отдельного внимания требуют интеграции: PLM все равно придется состыковывать с ERP, производственными и учетными системами. Если это не учесть заранее, сложности проявятся уже на этапе внедрения, когда цена ошибки значительно выше.

Управленческие факторы внедрения

Как только систему запускают на «живых» процессах и данных, становится видно, где действующая модель управления не справляется.

PLM по своей сути – это про связку, которая тянется через всю цепочку от конструктора к технологу, дальше – в снабжение и производство. И у каждого звена «своя оптика». Конструктор думает об изделии, а технолог – о том, как его сделать, их подходы по умолчанию не совпадают. Если процессы не синхронизированы в системе, изменения не доходят до всех участников: что-то закупают не в той версии, что-то не заказывают вовсе, сроки сдвигаются, а производство останавливается.

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

Отдельная история – зависимость от интегратора. Зачастую проект воспринимается как полностью внешняя задача: есть подрядчик, значит, он все и сделает. На практике это работает только на этапе внедрения. Дальше PLM остается внутри компании, и если в ней нет людей, способных ее развивать и настраивать, любые изменения потребуют привлечения интегратора.

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

Граница между внедрением и результатом

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

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

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

Авторы — Виталий Лоза, руководитель направления машиностроение, «Софтлайн Решения» (ГК Softline), и Александр Тимошин, директор АППИУС

По оценкам Strategy Partners, к 2030 году российские решения для управления жизненным циклом продуктов (Product Lifecycle Management, PLM) могут занять до 93% рынка систем этого класса, при этом сам рынок продолжит расти темпами порядка 16% в год. Со стороны это выглядит как довольно уверенный рост: освободившуюся нишу быстро закрывают, появляются новые продукты, запускаются проекты. Но если смотреть не на динамику, а на то, как этот рынок устроен в принципе, картина становится сложнее. Риск здесь не в дефиците решений, а в их совместимости – и в том, смогут ли они вообще работать вместе через несколько лет.

Рынок разделился

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

Часть предприятий успела внедрить решения Siemens, PTC, SAP до ухода западных вендоров. Эти системы развернуты в локальном контуре, лицензии есть, процессы на них уже выстроены. Пока все работает, никто не торопится что-то менять. И дело не только в деньгах. Любое изменение – это вмешательство в уже работающие процессы, а последствия такого шага заранее оценить сложно. Поэтому компании предпочитают не трогать то, что работает, и откладывают решения на годы.

Есть и другие компании, которые в один момент остались без доступа к PLM-системе. Им пришлось вернуться к базовым инструментам – таблицам, почте, ручному ведению версий. Это не редкость, а вполне типичный сценарий.

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

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

Как рост приводит к фрагментации

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

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

Откуда берется разрыв

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

Источник требований. Когда деньги получает разработчик без привязки к конкретному производству, система собирается «в целом для рынка». Архитектура может быть выстроена правильно, но без учета реальных процессов – как данные проходят от конструктора к технологу, дальше в снабжение и производство. На внедрении это компенсируется доработками.

Обратная ситуация – когда заказчиком выступает предприятие. Тогда требования формулируются из текущей практики: не «как должно быть», а «как есть». В результате система фиксирует существующие разрывы, только уже в цифровом виде.

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

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

В результате возникает парадокс: решений становится больше, а связность рынка снижается.

Где развитие идет быстрее

Есть сегменты, где внедрение PLM идет заметно быстрее – и причины там вполне приземленные. Речь о ретейле, пищевой промышленности, FMCG. Там нет сложного инженерного моделирования, нет тяжелых 3D-сборок и длинных циклов подготовки производства.

По сути, «изделием» становится товар: лестница, кран или любая другая позиция на полке. И задача – не спроектировать его в CAD, а собрать вокруг него корректные данные: состав, изменения, поставщиков, ограничения, экономику. Важно, чтобы эта информация проходила по цепочке без разрывов – от разработки к закупкам и дальше до продаж.

За счет этого требования к системам другие. Гораздо важнее скорость запуска и сквозная работа с данными, а не сложная инженерная функциональность. Поэтому проекты идут быстрее, а эффект появляется уже через несколько месяцев. И здесь PLM – полноценный инструмент управления процессами.

Системы есть – взаимодействия нет?

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

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

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

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

Авторы – Виталий Лоза, руководитель направления машиностроение, «Софтлайн Решения» (ГК Softline); Александр Тимошин, директор АППИУС

В России усиливаются меры, призванные ускорить переход на отечественные ИТ-решения. Министр цифрового развития Максут Шадаев объявил о возможном введении оборотных штрафов для компаний, отвечающих за значимые объекты КИИ, если они не успеют перейти на российское ПО в установленные сроки. Фактически КИИ становится первой площадкой, где государство использует финансовую ответственность как инструмент ускорения импортозамещения. Но очевидно, что этим дело не ограничится: подобная логика неизбежно будет распространяться и на другие технологические контуры.

Стратегия государства в целом понятна: в последние годы появляются все более жесткие требования, запрещающие использовать зарубежное ПО и оборудование. Постановление Правительства № 1875 устанавливает единые требования в части национального режима для закупок в рамках 44-ФЗ и 223-ФЗ. Для объектов КИИ действует Указ Президента Российской Федерации № 166, который запрещает закупку иностранного ПО, в том числе в составе программно-аппаратных комплексов, без согласования с федеральным органом исполнительной власти, уполномоченным Правительством Российской Федерации. С 1 января 2025 года действует запрет на использование иностранного ПО и ПАК на значимых объектах КИИ для органов власти и заказчиков, определенных Указом. То есть экосистема регулирования последовательно «закручивается», выталкивая иностранные технологии из критичных и инфраструктурных сегментов.

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

Риски форсированного перехода

Формальное импортозамещение вместо инженерного результата

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

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

Рост технических, архитектурных и операционных рисков

Экстренное импортозамещение затрагивает все уровни технологического стека: программное обеспечение, промышленные контроллеры, телеком-узлы, САПР, автоматизированные системы управления, инженерное оборудование. Любой такой переход требует времени на обследование архитектуры, ревизию протоколов, перенастройку защитных механизмов, тестирование совместимости и проверку производственных цепочек.

Под давлением сроков этот цикл неизбежно сокращается. Компании вынуждены мигрировать без глубоких тестов, откладывая часть работ «на потом». Это приводит к ошибочным архитектурным решениям, появлению уязвимостей, несовместимости оборудования, нарушению отказоустойчивости или сбоям при пиковой нагрузке. В промышленности это может привести к простоям; в телекоме — к деградации связи; в КИИ — к повышению вероятности инцидентов ИБ.

Дефицит отечественных решений и рост стоимости проектов

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

Это приводит к ряду эффектов:

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

В итоге переход может оказаться не только более затратным, но и менее технологически оптимальным, чем если бы он строился на рыночной скорости.

Риск превращения штрафов в «стоимость использования иностранного»

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

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

Регуляторные и методологические ограничения, тормозящие развитие

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

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

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

Что важно учесть в регулировании импортозамещения

Реалистичное планирование и гибкие сроки

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

Дорожные карты и методическая поддержка компаний

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

Баланс штрафов и стимулов

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

Приоритет качества и надежности, а не только происхождения

Происхождение технологии — лишь часть картины. Если регулирование фокусируется исключительно на «российскости», компании будут стремиться закрыть чек-лист, а не обеспечить устойчивость архитектуры. В центре контроля должны быть надежность, производительность, совместимость компонентов, уровень кибербезопасности и способность систем работать без перерывов. Именно этот подход делает импортозамещение не формальной заменой, а шагом к более зрелой и управляемой технологической среде.

Заключение

На сегодняшний день процесс импортозамещения ПО и оборудования в России находится между фазой массовых деклараций и полноценной реализацией. С одной стороны, зарубежные решения составляют целых 75% инфраструктуры. С другой стороны, регуляторная нагрузка уже значительно возросла: введены запреты на закупку иностранных решений, утверждены сроки, развиваются отечественные серии ПО и оборудования. При такой «переходной» стадии важно признать: стимулы, в том числе штрафы, имеют смысл, но только если они встроены в комплексный подход. Если государство усиливает ответственность за промедление, но не обеспечивает инфраструктуру поддержки, компетенции, зрелые отечественные аналоги и разумные сроки, риск «быстрой миграции» с минимальной ценой для штрафов становится высок. Поэтому ответ на вопрос: «Нужны ли штрафы?» скорее всего — «Да, но в сопровождении». Штрафы могут выполнять функцию «ускорителя», напоминания о серьезности задачи, но они не могут заменить инженерную подготовку, модернизацию цепочек поставок, развитие отечественных решений и постепенное внедрение.

В конечном счете, цель — не просто заменить «чужое» на «российское», а создать технологически устойчивую, конкурентоспособную и безопасную среду. И только когда отечественные решения станут по качеству и масштабу сопоставимы с иностранными, механизм штрафов станет не просто рычагом принуждения, а дополнением к зрелой экосистеме.

Автор – Дмитрий Битченков, руководитель направления разработки технической и проектной документации компании «ГИГАНТ Компьютерные системы»

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

Бессмертный «зоопарк»

«Зоопарк» слабо интегрированных или вообще не связанных между собой программных продуктов, с которым бизнес активно боролся много лет назад, сегодня, похоже, наиболее характерен именно для вузов. Разносортный софт, которым пользуются деканаты и бухгалтерия, личные кабинеты студента и работодателя, расписание, рабочие приложения ректора, система управления учебным процессом (LMS) — все это надо увязывать. И нельзя сказать, что в этом направлении ничего не делается.

Как рассказал начальник управления информационных технологий, связи и информационной безопасности Омского государственного университета Сергей Барановский, цифровизация ОМГУ начиналась с самописных систем. «Но в 2020 году нас постигла катастрофа масштаба: замена каждого следующего сервиса требовала все большей трансформации существующей инфраструктуры, — поделился он. — С той поры мы начали радикально все менять, упорядочили самописные системы и положили в основу понятные платформы».

На проблему «зоопарка» обратили внимание и регуляторы, наметив движение в сторону типовых облачных ресурсов. Так, был запущен проект по типовым облачным ресурсам для вузов Донбасса, включающий операционную систему, офисный пакет, LMS и прочее. Кроме того, в этом году ожидается перезапуск проекта по созданию типового рабочего места под эгидой Минцифры и Минобрнауки, так что в небольших вузах остроту проблемы, возможно, удастся снизить.

А вот тема совместной разработки или обмена уже созданным ПО как средства борьбы с «зоопарком» на рабочем месте буксует, и понятно почему. Во-первых, вузы конкурируют за бюджеты, за абитуриентов «высокобалльников» и «олимпиадников» по всей стране. Поэтому помогать разрабатывать решения конкурентам готовы далеко не все. Во-вторых, внутреннее решение развивается под требования внутреннего заказчика, а у следующего заказчика будут иные идеи. Вырвать любую инхаус-разработку из существующей инфраструктуры конкретной организации и куда-либо перенести — сложнейшая задача. В-третьих, даже передав свои наработки безвозмездно, поддерживать их в другой организации бесплатно никто не будет. Тиражирование внутреннего решения требует серьезного уровня партнерства, командной работы. Отнюдь не каждой организации под силу повторить опыт создания «ЛОГОСа», разработанного в контуре Росатома для внутренних нужд, но превращенного в рыночный продукт.

Дорогая безопасность

Затронули участники обсуждения и весьма деликатный вопрос о жизни на два компьютера, один из которых «нормальный», а другой — аттестуемый для обработки персональных данных (ИСПДн). Общее мнение — лучше даже не задавать лишних вопросов о том, как вообще это устроено.

Еще один тонкий момент: вуз не имеет права хранить персональные данные студентов после окончания обучения — эти данные нужно перенести в архив, либо обезличить, либо уничтожить. Об это правило спотыкается организация эффективного взаимодействия с работодателями. Например, в МАИ создали цифровую кадровую платформу, чтобы пристраивать своих выпускников. Но, во-первых, на эти цели персональные данные не собирали, и, во-вторых, самые интересные работодателю студенты — выпускники, данные которых как раз и требуется убирать. МАИ должен готовить кадры, прежде всего, для авиационной промышленности и авиационно-ракетной отрасли. Однако ОАК, Ростех, Роскосмос и ОДК не могут конкурировать по стартовому уровню зарплаты для новичков с тем же «Яндексом». Поэтому кадровая платформа, где можно размещать вакансии, которые видят студенты, для них очень актуальна, подчеркнул Федор Васильев, заведующий кафедрой «Цифровые технологии и информационные системы» Московского авиационного института. Что касается вопроса, зачем государству готовить специалистов, которые потом уходят на свободный рынок, по его мнению, ответ прост: человек, который работает в условном «Яндексе», приносит государству налогов в разы больше, чем человек, работающий на авиационном заводе.

Федор Васильев: «Учить «буржуйскому» софту, который пока еще везде есть, или уже российскому, которого пока еще нигде нет?»

Обеспечить себя ИТ-специалистами высокого уровня для вузов тоже серьезная проблема. «Как затащить топ-айтишников в любую компанию, если это не «Сбер» и не «Яндекс», это большой вопрос», — обозначил проблематику Васильев. Возможность вырастить собственные кадры из студентов не спасает «кузницу кадров» от катастрофического кадрового голода. Сегодня вузам нужны любые ИТ-специалисты, которые способны самостоятельно и качественно решать различный спектр задач.

Помимо требований к защите персональных данных, еще один огромный ИБ-айсберг норовит потопить вузовские ИТ: по умолчанию вузы являются объектами критической информационной инфраструктуры с соответствующим уровнем требований к защите. Нелегальный доступ или модификация информации в объекте критической инфраструктуры является уголовным преступлением. Поэтому с «закручиванием гаек» и выходом новых нормативных актов, связанных с удаленным подключением, ИТ-службы вынуждены закрывать возможности удаленного доступа к системам учреждения, резко ухудшая таким образом качество сервиса. Если раньше сотрудники финансово-экономического управления и бухгалтеры могли работать удаленно, а преподаватели могли из дома делать рабочие программы по своим дисциплинам, учебные планы, смотреть результаты работы студентов, то теперь это можно делать исключительно с аттестованного компьютера на отечественной операционной системе. Ключевым сотрудникам стараются сохранить возможности для удаленной работы, но решение этой проблемы требует затрат, отметил Барановский. Для удаленного доступа на рабочем месте должны быть типовое программное обеспечение и средства защиты информации. Однако для рядового сотрудника нельзя купить за бюджетные деньги ноутбук с характеристиками лучше установленных, и потратить на него выше установленной суммы — тоже нельзя. Между тем купить ноутбук со всеми средствами защиты за установленную нормативом сумму просто невозможно, отметили участники дискуссии.

«Буржуйское», но сейчас, или свое, но потом?

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

«Нам уже сейчас нужно готовить студента, который через 4-6 лет выйдет на предприятие и будет работать на том программном обеспечении, которое там будет использоваться», — говорит Сергей Попов, проректор по цифровизации МАИ. Только как обучить продукту, которого еще нет?

Сергей Попов: «Для понимания того, как сейчас учить студентов, нужна более плотная коммуникация с отраслью»

Разумеется, в крупных холдингах есть представление о том, на каком софте они будут работать через несколько лет, существуют дорожные карты по разработке ПО, в том числе в рамках индустриальных центров компетенции. Но сами продукты еще не готовы. «Для понимания того, как сейчас учить студентов, нужна более плотная коммуникация с отраслью в части разработки стратегии импортозамещения на предприятиях», — считает Попов.

Пока же остается в запасе классический тезис, что вузы не учат конкретным инструментам. «Все-таки конкретные инструменты — это ремесло, а мы — про образование», — заметил Васильев. Поэтому студенты знакомятся с разными программными инструментами, но основное что дает вуз — базовая теория. Правда, работодателей возврат к такой установке вряд ли обрадует.

Для Президентской Академии РАНХиГС импортозамещение сейчас не самая критичная задача, тем не менее, ее решением занимаются. И Р7, и «Мой офис» уже давно включены в программы обучения, на которых учат всех чиновников. «Что касается внутренних систем, то в апреле, когда Microsoft заявила, что уходит из России в соответствии с пакетом новых европейских санкций, для нас это был хороший повод, — рассказал Павел Клепинин, проректор по информационным технологиям и цифровой трансформации Президентской Академии РАНХиГС. — И мы через пять дней перевели наших пользователей на сервисы «Яндекса» — почту, календарь, диск и мессенджер». Все встречи и рабочие совещания теперь проводятся в сервисе «Яндекс.Телемост», а дистанционный процесс обучения и в гибридном формате — через «МТС Линк». Смена любой системы — всегда стресс и нужно с ним работать. В управлении изменениями есть множество инструментов, как этот стресс снять и сделать людей сторонником изменений. При переходе большое внимание было уделено именно этому компоненту. Нужно обязательно транслировать опыт воздействия на сотрудников.

В ОАО «РЖД» за короткое время осуществили перенос на импортонезависимую платформу основной функциональности управления критически важной для бизнеса НСИ. Кроме этого, в рамках проекта обеспечены технологические условия для тиражирования этого решения. О реализации проекта рассказывают Кирилл Семион, начальник департамента информатизации ОАО «РЖД», и Александр Толгский, руководитель дирекции по продажам департамента «Государственные программы» IBS – номинанты на премию Data Award.

— В каком состоянии находились процессы управления НСИ в РЖД до реализации проекта? Как они были реализованы?

Кирилл Семион: ОАО «РЖД» имеет разветвленную организационную структуру и осуществляет хозяйственную деятельность по различным направлениям. С учетом этого, а также высокого уровня автоматизации деятельности ОАО «РЖД» и его дочерних предприятий одним из ключевых вопросов, стоящих перед компанией, является обеспечение единства, полноты и достоверности нормативно-справочной информации, используемой различными специалистами компании в ходе исполнения своих обязанностей.

В рамках решения этой задачи в компании в разное время были созданы специализированные системы для ведения нормативно-справочной информации, но, несмотря на это, в различных создаваемых и развиваемых информационных системах ОАО «РЖД» разработчиками были реализованы возможности по ведению НСИ. Это приводило к нарушению принципов единства и полноты нормативно-справочной информации, затрудняло взаимодействие на уровне отдельных информационных систем, усложняло существующую архитектуру и ИТ-ландшафт ОАО «РЖД».

— В чем заключались основные проблемы? Почему это было важно для РЖД?

К.С.: Ключевая предпосылка проекта — отсутствие единой системы управления НСИ. По состоянию на 2022 год в ОАО «РЖД» эксплуатировались две информационные системы, обеспечивающие централизованное ведение справочников — ИС, предназначенная для ведения технологических справочников, и система, предназначенная для ведения справочников, используемых в рамках автоматизации предприятия в целом (ERP).

Второй предпосылкой стало то, что централизованные системы ведения НСИ были созданы с использованием лучших на тот момент из представленных на рынке решений — платформы и продукты иностранных производителей. Таким образом, использование решений иностранных вендоров для автоматизации функции ведения справочников во множестве функциональных и технологических систем ОАО «РЖД», после ухода иностранных вендоров из России несло существенные риски выхода из строя вычислительной инфраструктуры и общесистемного программного обеспечения, а также обострило вопрос информационной безопасности.

Совокупность этих факторов и привела к старту проекта по созданию новой версии Автоматизированной системы централизованного ведения нормативно-справочной информации (АС ЦНСИ-2), реализованной на базе решений, включенных в реестр отечественного программного обеспечения Минцифры России, и отвечающей всем требованиям ОАО «РЖД» к решению такого класса.

— Какой подход был выбран для решения задачи?

К.С.: В ОАО «РЖД» существуют довольно жесткие требования, предъявляемые к внедряемому ПО. На старте проекта было принято решение провести анализ включенных в реестр отечественного программного обеспечения продуктов, а затем предложить разработчикам пройти комплексное тестирование в соответствии с методикой ОАО «РЖД» и подтвердить возможность применения своего решения как в части показателей назначения, так и в части предоставляемых продуктом функциональных возможностей.

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

После выбора решения для создания АС ЦНСИ-2 ОАО «РЖД» была проведена объемная работа по формированию границ проекта, состава нормативно-справочной информации, организационного объема и требований к создаваемой на базе платформы автоматизированной системе.

— Какие требования предъявлялись к создаваемому решению?

Александр Толгский: В первую очередь создаваемое отечественное решение необходимо было за короткое время интегрировать в существующую ИТ-архитектуру ОАО «РЖД» без ущерба для существующих процессов управления НСИ в замещаемом ПО. Чтобы упростить переход специалистов к полноценному использованию новой системы, также было необходимо, с одной стороны, воспроизвести существующую в АС ЦНСИ функциональность, а с другой — обеспечить ее реализацию максимально удобным для пользователей способом с учетом существующих технологических возможностей платформы.

В целом, если говорить про требования, система на первом этапе должна была обеспечить централизованную миграцию исторических данных и ведение более 1,4 тыс. справочников и связанных с ними метаданных, обеспечить возможность интеграции с более чем 140 информационными системами ОАО «РЖД» (как потребителями, так и источниками данных).

— Что было сделано в рамках проекта?

А.Т.: В рамках проекта была проведена масштабная работа по развертыванию отказоустойчивой конфигурации инфраструктурного ПО и платформы «Планета.НСИ» в тестовом и производственном контурах ОАО «РЖД», настроена базовая функциональность платформы и реализована дополнительная функциональность в соответствии с ТЗ, реализованы типовые средства интеграции с системами-потребителями и системами- источниками, мигрированы справочники и связанные с ними метаданные, проведено комплексное тестирование и обеспечена возможность переключения взаимодействия внешних систем со старой АС ЦНСИ на новую АС ЦНСИ-2 без пауз в предоставлении нормативно-справочной информации.

— В какие сроки и какими силами реализован проект?

А.Т.: Тестирование платформы заняло три месяца, далее порядка восьми месяцев шла работа проектной команды на стороне ОАО «РЖД». Сам проект реализации и внедрения платформы АС ЦНСИ-2 проходил с марта 2023-го по ноябрь 2023 год.

Общий размер команды с нашей стороны составил более 100 человек.

— В чем заключались сложности проекта? Как они решались?

А.Т.: При внедрении новой системы ведения НСИ требовалось воспроизвести все наполнение унаследованной системы, реализовать более 1,4 тыс. справочников, настроить связи между ними и контроли, которые обеспечивались не только видимыми триггерами в базе данных, но и в программном коде унаследованного приложения.

Кроме того, в новой системе ведения НСИ требовалось реализовать дополнительные ссылочные связи между справочниками, которые ранее велись независимо друг от друга. В процессе настройки был выявлен ряд расхождений в технологических справочниках.

Специалистами IBS совместно со специалистами Главного вычислительного центра с привлечением АО «НИИАС» была проведена работа по глубокому обследованию особенностей реализации каждого справочника, настроены автоматические процедуры сверки данных между унаследованной и новой системой АС ЦНСИ-2 и исследования причин каждого расхождения в данных и их устранения.

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

— Что представляет собой созданное решение?

К.С.: Созданная АС ЦНСИ-2 обеспечивает централизованную функцию ведения НСИ в ОАО «РЖД», функционирует на базе программной платформы и вычислительного кластера, созданных в Российской Федерации.

Сегодня система включает в себя более 1,4 тыс. справочников, для каждого из которых реализованы модели данных, средства контроля качества данных и пользовательские интерфейсы. Для основной массы справочников АС ЦНСИ-2 является мастер-системой, а для части систем, которые еще находятся в процессе перевода на отечественные решения, АС ЦНСИ-2 выступает в качестве шлюза-маршрутизатора в старую систему АС ЦНСИ.

— Как изменились процессы, связанные с управлением НСИ? Как это повлияло на работу сотрудников?

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

С внедрением платформы «Планета.НСИ» существенно упростились процедуры по созданию новых объектов НСИ. Создание новых объектов НСИ, включая создание моделей данных, экранных форм, форм поиска и алгоритмов контроля качества данных, теперь можно проводить непосредственно через веб-интерфейс АС ЦНСИ-2 без участия разработчика.

Система также предусматривает возможность создания новых объектов НСИ при помощи импорта метаданных из шаблона, что существенно ускоряет реализацию новых объектов НСИ, и перевод ведения справочников из смежных информационных систем ОАО «РЖД» в АС ЦНСИ-2.

— Каких результатов удалось достичь?

А.Т.: АС ЦНСИ-2 за короткое время была интегрирована в существующую ИТ-архитектуру ОАО «РЖД». При этом был обеспечен перенос на импортонезависимую платформу основного функционала управления критически важной для бизнеса НСИ. Кроме этого, в рамках проекта обеспечен технологический задел для тиражирования АС ЦНСИ-2 в части состава справочников и подключения новых источников и потребителей данных.

— А какие результаты ожидаются в перспективе?

К.С.: К АС ЦНСИ-2 активно подключаются новые системы, в том числе реализуемые в рамках стратегии цифровизации ОАО «РЖД».

Мы планируем и далее развивать АС ЦНСИ-2 как в части расширения функциональных возможностей и повышения удобства пользователей в работе с системой, так и в части перевода ведения справочников из функциональных систем в АС ЦНСИ-2 и обеспечения интеграции с автоматизированными системами ОАО «РЖД».

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

— В каких направлениях будет развиваться проект? И какие возможности он открыл для компании?

К.С.: Реализация проекта позволила ОАО «РЖД» выявить точки роста не только в части ведения нормативно-справочной информации, но и в существующих бизнес-процессах компании и смежных с АС ЦНСИ-2 системах. Мы продолжим и далее совершенствовать процессы ведения нормативно-справочной информации и переводить системы на централизованное ведение справочников. То есть новая информационная система стала и будет развиваться как полноценный компонент всей корпоративной системы управления данными.

Health&Nutrition (бывшее подразделение Danone в России) реализует проект перехода с корпоративной системы по управлению нормативно-справочной информацией на решение «Гармония MDM» – 100% российскую систему, внесенную в реестр отечественного ПО. О ходе работ и первых результатах рассказывает Анна Ерохина, руководитель команды технической поддержки сервисов по работе с мастер-данными Health&Nutrition и номинант на премию Data Award.

- В чем заключалась бизнес-проблема, почему внедрение MDM важно для компании?

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

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

- Какой подход был выбран для решения задачи?

Мы выбрали итерационный подход. В первую очередь, мы сфокусировались на переносе основного функционала из корпоративного решения – внедрение MVP-версии. Затем, вторым этапом, идет настройка интеграции с корпоративной ERP-системой. Одновременно с этим на стороне вендора ведется разработка функционала системы, который поможет адаптировать новое решение к бизнес-процессам компании. Третий этап – перенос в новую систему справочников, которые вручную ведутся командой бизнеса в формате Excel, а также настройка интеграции с хранилищем данных.

- В чем заключались сложности проекта?

Как обычно, основная сложность проекта заключалась в сочетании сжатых сроков и большого объема проекта. У нас было всего шесть месяцев на внедрение MVP по пяти крупным корпоративным справочникам. Мы приняли решение проводить сверку и выравнивание данных между MDM и ERP одновременно с эксплуатацией системы. Также нам потребовалась оптимизация производительности, и доработка критически важного функционала.

Из организационных проблем можно выделить вовлечение в проект порядка 10 различных команд бизнеса и ИТ, а также одновременное подключение ресурсов MDM-проекта к общему, «большому» проекту локализации компании.

- Как решались проблемы?

Производитель «Гармонии MDM» принял в бэклог доработки коробочного решения значительный объем задач, который позволил адаптировать систему под зрелые и развитые процессы управления справочниками в нашей компании. В частности, был разработан специализированный инструмент для сверки данных с ERP-системой.

До окончания сверки и выравнивания данных справочники одновременно ведутся вручную в MDM и ERP. Старт интеграции запланирован сразу после подтверждения полной сходимости данных.

Наконец, произошло усиление менеджерского состава со стороны подрядчика для повышения управляемости проектом.

- В какие сроки и какими силами реализован проект?

Проект реализован силами подрядчика Axenix с активным и деятельным вовлечением бизнес-заказчика и локального ИТ. На внедрение MVP потребовалось шесть месяцев, на настройку интеграции – 10 месяцев, сейчас мы находимся на финальном шаге по запуску интеграции MDM с ERP.

- Что представляет собой созданное решение?

Это полноценная MDM-система, в которой ведутся критичные для бизнеса справочники материалов, клиентов, поставщиков и контрактов, с реализованными процессами управления данными. В ней уже настроены правила для проверки соблюдения бизнес-логики ведения атрибутов. У системы более 700 конечных пользователей и на данный момент она на 80% готова к интеграции с ERP.

- Что было сделано в рамках проекта?

В рамках MVP был реализован довольно объемный функционал. Во-первых, созданы справочники для хранения данных из ERP-системы: материалы, клиенты, поставщики, закупочные и сбытовые контракты, производственные рецептуры, ассортиментные матрицы, а также связанные с ними более 200 вспомогательных справочников. Работа серьезная — данные о материалах содержат 400 тыс. записей и 600 атрибутов, о клиентах – 300 тыс. записей и 300 атрибутов, о поставщиках – 70 тыс. записей и 200 атрибутов, о контрактах с клиентами и поставщиками – 4 млн и 600 тыс. записей соответственно.

Во-вторых, выстроены 90 бизнес-процессов, содержащих в себе от 1 до 10 шагов от момента инициирования заявки до финального обновления данных в справочнике, а также отправка уведомлений на почтовый ящик пользователей, задействованных в процессах. Создано 1,8 тыс. бизнес-правил, позволяющих автоматически заполнять значения атрибутов и выполнять проверку соблюдения бизнес-логики ведения данных. Настроена ролевая модель – более 60 ролей в системе, позволяющая управлять доступами и полномочиями пользователей. Функционал решения позволяет гибко скрывать и делать доступными для просмотра и заполнения поля справочника в зависимости от выбранного бизнес-процесса и роли пользователя.

Кроме того, разработан функционал массового обновления данных в системе через интерфейс (загрузка с помощью Excel-шаблона). Настроена прямая и обратная интеграция в режиме реального времени по перечисленным справочникам с корпоративной ERP-системой.

По итогам проекта разработано более 100 дополнительных функций, которые были добавлены в «коробочную» версию системы.

- А какие работы еще предстоят?

Предстоит реализовать различные справочники для хранения данных из Excel-файлов, а также из системы поддержки работы мобильных сотрудников (sales force automation, SFA) и веб-приложений: матрицы торговых точек, актуальная цена товаров на полке, мастер-данные торговых точек, варианты дизайна SKU, новинки, сроки действия дизайнов, данные для расчетов RTM. Конечно, потребуется настроить бизнес-процессы управления перечисленными справочниками и их интеграцию с хранилищем данных и другими системами.

- В каких направлениях будет развиваться проект? И какие возможности он открыл для компании?

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

В планах на май – настройка интеграции с корпоративной ERP-системой по справочникам материалов, клиентов и поставщиков, а также интеграция с хранилищем данных по ряду ручных справочников. В планах на июнь – настройка интеграции с корпоративной ERP-системой по клиентским и сбытовым контрактам. В планах до конца года – перенос для ведения в MDM-системе порядка 100 ручных справочников и развитие интеграции с хранилищем данных и системой SFA.

«Промсвязьбанк» разработал и внедрил универсальную платформу для построения аналитических хранилищ данных – Единое Хранилище Данных (ЕХД ПСБ). Она реализована на импортозамещенном стеке технологий и вносит весомый вклад в технологический суверенитет банка. Накопленная экспертиза при реализации данного проекта может быть полезна и другим участникам банковского рынка, а также госкомпаниям – участникам директив импортозамещения.

Создание ЕХД ПСБ позволило, в числе прочего, решить такие важнейшие задачи, как централизация работы с данными, использование единых сквозных методологий расчета показателей, а также расширить число используемых внутренних и внешних источников данных. О реализации этого проекта и его роли для развития банка рассказывает Екатерина Варламова, директор департамента управления данными ПСБ и номинант на премию Data Award.

- Какие проблемы стояли перед банком, какую бизнес-задачу решали?

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

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

- Почему это важно для банка?

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

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

- Какой подход был выбран?

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

ЕХД ПСБ – универсальная платформа для построения аналитических хранилищ данных, она может быть использована как самостоятельное решение, в организациях любого масштаба и любой отрасли для построения хранилищ данных. Она уже зарегистрирована в едином реестре российских программ Минцифры.

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

- Что представляет собой созданная система, какие данные она охватывает?

Платформа ПСБ ЕХД аккумулирует данные из более чем 20 информационных систем банка, а также более 50 внешних источников данных. Она создана на основе российских технологий и открытого ПО, что обеспечивает полный технологический суверенитет.

Основными инструментами для создания ядра системы выступили продукты компании Arenadata: Arenadata DB и Arenadata Hadoop. Инструменты Kafka, AirFlow, NiFi и пр. легли в основу универсальной транспортной системы, входящей в ядро ПСБ ЕХД – PSB DataCollector.

- Что сделано в рамках реализации проекта?

Нами разработано качественно новое масштабируемое ядро системы хранения, обработки и поставки данных, отвечающее как директивам импортозамещения, так и требованиям информационной безопасности. Кроме того, оно обеспечивает поддержку растущих объемов бизнеса, вызванных объединением новых банковских структур и открытием новых отделений. ПСБ первым из системно значимых банков начал работать в Крыму и Севастополе, а также пока единственный федеральный банк в новых российских регионах.

Итеративное повышение качества данных за счет использования подхода совместных сводных проектных команд с бизнесом позволило получить первые значимые результаты уже в течении первых месяцев работы с данными.

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

- Какие проблемы возникали в ходе реализации проекта? Что было самым сложным?

Как и весь рынок, с 2020 года мы столкнулись с такими масштабными вызовами, как пандемия коронавируса, затем – с санкциями в отношении нашей страны и банка, увеличение требований со стороны регулятора и усиление контроля за исполнением директив импортозамещения. Как одним из первопроходцев данной темы, нам пришлось столкнуться со множеством трудностей, но из них можно выделить наиболее сложные и интересные для решения.

Например, изменение ИТ-ландашфта банка параллельно с построением платформы аналитического хранилища данных потребовало постоянно учитывать как внутренние, так и внешние изменения связанных проектов. Также важно отметить, что это одно из первых крупных внедрений Arenadata DB, и нам приходилось совместно создавать и накапливать экспертизу. Благодаря общим усилиям нашего банка и вендора накоплен огромный практический опыт. И третье, что мы понимали уже на старте, – безопасность данных является основой такого решения, как корпоративное хранилище данных в текущих реалиях нашей страны.

- Как эти проблемы решали?

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

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

Другой важный фактор – это люди, их компетенции и вовлеченность. В текущих реалиях на рынке просто нет готовых специалистов, которые уже внедряли бы российские разработки в таких масштабах. Поэтому мы сделали дополнительный акцент на привлечении в команду аналитиков и архитекторов не только из банковского сектора, но и телекома. Нас интересовали эксперты из кросс-функциональных предметных областей, имеющие опыт работы с различными СУБД и системами с разной нагрузкой, специалисты, имеющие опыт разработки коммерческих, а также полностью «закрытых» систем, «инфраструктурщиков» и «безопасников». Никто из нас не решал подобную комплексную задачу в системе столь «высокой неопределенности», поэтому поиск оптимально работающего решения задачи стал даже более важным мотивирующим и объединяющим фактором, чем директивы регулятора.

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

- Какие из первых результатов вы можете выделить?

Качество клиентских данных физических лиц «карточки клиента», используемых в аналитических задачах и операционных процессах банка, улучшено на 56%. Это достигнуто благодаря разработанным системам мониторинга и контролям качества данных. На их основе внедрены новые проверки корректности ввода и обогащения данных на уровне фронт-офисных систем. Повышение качества данных позволяет сократить среднее время на обслуживание клиентов, повышать доходность каналов продаж и, что еще важнее, улучшать клиентский опыт.

- Как это отразилось на результатах банка?

Только за счет дедубликации рассылок по двум каналам коммуникаций и сокращения времени работы клиентских менеджеров при актуализации персональных данных, нам удалось достичь экономии более 8 млн руб. Совокупно за 2023 год уже удалось высвободить 22 тыс. часов на продажи и консультации по всей сети. В сегментах продаж улучшение качества одних только телефонных номеров позволило повысить процент успешных дозвонов и, как результат, заключить дополнительные контракты общей доходностью 15,7 млн руб.

Фактически, при улучшении качества карточки клиента всего на 4%, общая конверсия повысилась на 1%. Потенциал доходности при росте конверсии составляет до 15%, что превысит 47 млн руб. на новом потоке клиентов.

Коллеги из розничного блока также выделяют влияние проекта в задачах разумного потребления и охраны окружающей среды: так, например, дополнительная экономия бумаги на заявлениях об изменении персональных данных составила 7 млн руб., что равносильно 189 деревьям или среднему городскому парку.

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

- А как изменилась жизнь сотрудников банка?

С точки зрения результатов проекта, использование расширенных наборов данных позволило решать новые аналитические задачи. Платформа ЕХД ПСБ используется в задачах привлечения и удержания, оценки банкротств, проблемной задолженности, эффективности взысканий и на многих других направлениях. Ключевыми пользователями являются такие подразделения как ЦОР ГОЗ, департамент финансового мониторинга, розничный бизнес, маркетинг, операционный департамент и т.д. Более 200 пользователей банка получили доступ к расширенной и детальной аналитической и транзакционной информации, включая обогащение данными из внешних источников (более 50 внешних реестров), в соответствии с ролевой моделью доступа.

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

- Что реализовано с точки зрения безопасности данных?

Безопасность данных стала краеугольным камнем в архитектуре нашей системы. Наряду с использованием высоко доверительных программных систем и библиотек данных, нами была разработана модель безопасности данных и управление сегментами «чувствительности». Реализовано более 700 объектов доступа в классах чувствительности «персональные данные», «ОПК/ГОЗ», «общие». Внедрена система логирования системных, программных и пользовательских операций. Модель безопасности позволяет исключить риск несанкционированного доступа к данным, в том числе вызванного внешним воздействием.

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

- В каком направлении планируется развивать проект? Каково его будущее?

Если заглянуть в далекое будущее – 2040-е годы, то здесь хочется привести слова председателя ПСБ Петра Михайловича Фрадкова, что будущее будет сконцентрировано в отраслях высокотехнологичного сектора: «Экономика России будет полностью сконцентрирована на том, что мы сейчас называем высокотехнологичным сектором – виртуальная реальность, большие данные, искусственный интеллект и пр. В свою очередь банки в том виде, в котором они существуют сейчас, умрут, но с учетом влияния онлайн-технологий и ИТ-индустрии они переродятся в другом виде».

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

«Домклик» от Сбера построил BI-систему на базе бесплатных инструментов. Целью проекта стало не только импортозамещение зарубежных систем, но и разработка удобного и простого сервиса для визуализации данных, не требующего специальных знаний, кроме владения SQL и принципами работы сводных таблиц. О реализации проекта рассказывает Дмитрий Леонов, руководитель направления по исследованию данных и номинант на премию Data Award.

— В чем заключалась проблема? Зачем потребовалось создавать собственную BI-систему?

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

Все эти потребности закрывались с большим количеством ручного труда аналитиков, отчетность была очень разрозненна по своему формату, структуре и размещалась в разных местах. Не было должного контроля качества данных и «единого источника правды». У разных команд были разные подходы к построению отчетов и разные инструменты для этого.

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

— Какой подход к решению был выбран?

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

— Какие требования предъявлялись к будущему решению?

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

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

— На каких технологиях построено решение?

Бэкенд реализован на Python и PostgreSQL, а также Clickhouse. В качестве фронтенда используется React.

— Как учитывали потребности пользователей? Что им вообще нужно?

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

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

— Что получилось удачнее всего, а над чем еще предстоит работать?

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

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

Остается большое количество технических задач и задач по улучшению пользовательского опыта.

— Каких результатов удалось достичь?

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

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

— Насколько сильно снизились требования к аналитикам? И как вообще более простой сервис отразился на процессах?

При найме новых аналитиков перестало требоваться знание BI-инструментов вроде Tableau, PowerBI, QlikView. Основным требуемым навыком выступает SQL и аналитическое мышление.

Простой процесс создания дашбордов значительно снизил время их разработки. Уменьшилось дублирование одних и тех же показателей от разных аналитиков. Как следствие, повысилось доверие к отчетности.

— Пытались ли оценить финансовый результат?

Проводился сравнительный анализ расходов на покупки лицензий зарубежных популярных BI-инструментов (до ухода этих компаний из России). Получались достаточно крупные суммы с учетом большого количества пользователей и аналитиков.

Создание отдельной команды под разработку собственного решения получилось более выгодно экономически.

— В чем роль проекта для компании и для рынка в целом?

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

Ожидается распространение системы на другие подразделения – такой шаг поможет коллегам перенять наш опыт и лучшие практики, а не тратить ресурсы на создание собственной системы аналитики в условиях практически отсутствия альтернатив на рынке. Конечно, можно найти решения open source, но требуется много времени и ресурсов чтобы развернуть и настроить их под себя. А для специфических задач наверняка потребуются доработки такой системы.

— Каковы планы по развитию решения?

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

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

Важнейшую роль в обеспечении хороших финансовых результатах «Сбера» в 2022 году сыграл проект миграции на импортонезависимую CRM, поддерживающую работу всех В2В-компаний группы. Он позволил не только обеспечить непрерывность процессов, но и существенно повысил их качество. О его реализации и результатах рассказывает Евгений Горбачев, руководитель проектов Центра корпоративных решений «Сбера» и номинант на премию Data Award.

— Что стало причиной реализации проекта?

Наша команда представляет Центр корпоративных решений – контакт-центр «Сбера», поддерживающий юридических лиц по банковским продуктам и продуктам компаний нашей группы. У нас на поддержке более 50 дочерних обществ и партнеров банка, а это более 200 продуктов компаний B2B в различных сферах и отраслях, с разными бизнес-моделями и процессами. Мы предоставляем им и сервис, и платформу для организации поддержки продуктов.

Изменения ощутило на себе большинство российских компаний. «Сбер» также был вынужден резко ускорить скорость разработки собственных ИТ-решений.

Мы начали испытывать сложности с иностранными вендорами: длительные процессы согласования и внедрения, не кастомизированные под наши цели и задачи решения. Появился риск остаться без технологической платформы, которая является неотъемлемой частью нашей повседневной работы. Это ставило под угрозу нормальное функционирование поддержки в крупнейшем банке и всех компаниях В2В группы «Сбер», поэтому мы приступили к реализации антикризисного сценария – переходу от импортного программного обеспечения к отечественным разработкам.

— Какой подход был выбран?

Реагируя на изменившуюся среду, мы осознали необходимость сформировать собственное решение для контакт-центра. В рамках импортозамещения были поставлены несколько целей. Во-первых, требовалось создать технологическое решение, с помощью которого можно будет поддерживать разнородные бизнес-процессы более 200 продуктов. Во-вторых, решение должно иметь брендовую составляющую – оно должно было стать разработкой, конкурирующей с мировыми лидерами индустрии контакт-центров. Наконец, было важно сократить затраты на поддержку продуктов группы и банковских продуктов «Сбера» на сумму более чем 100 млн руб. в год.

— Как были сформулированы задачи проекта?

Важно было не просто не потерять в качестве сервиса, но и стать лучше, причем это касается очень многих показателей. Например, сохранение уровня доступности, а он очень высок: 80% всех обращений принимаются за 30 секунд, потери составляют менее 5% от всех обращений. Сохранение и повышения уровня удовлетворенности клиентов – поставлена цель выше 90%. Более того, рассчитывали на сокращение времени обслуживания за счет интеграции с автоматизированными системами дочерних обществ банка и формирования единой истории взаимоотношений с клиентами по всем каналам коммуникаций.

Нужно было подумать и о сотрудниках (например, сохранить и повысить уровень удовлетворенности операторов рабочим местом, автоматизировать процессы), и о клиентах (иметь бесшовный клиентский путь), и об эффективности (объединить все обращения клиентов в единую базу, иметь единую систему инцидент-менеджмента, формировать единый дашборд по всем обращениям клиентов). И конечно, хотелось сократить время запуска новых проектов, сохранив гибкий, кастомизированный подход к каждому продукту.

— Из каких вариантов выбирали?

В части техники и платформ для разработки перед нами встал сложный выбор из следующих вариантов: разработать решение «с нуля» или использовать open source, а может – готовое решение? Было нужно проработать встраивание в общую архитектуру банка, создание единого профиля клиента, предоставление доступов к CRM вне контура банка, а также многочисленные интеграции с автоматизированными системами.

По итогам анализа приняли решение разрабатывать свой софт, а для ускорения реализации использовать open source решение OTRS. В результате мы получили функционал для гибкой настройки бизнес-процессов обработки обращений в офлайн-режиме, а для онлайн-обращений доработали решение OTRS на базе платформы Platform V «Сбера». Нашу разработку мы назвали «Единая CRM для обращений клиентов компаний B2B группы Сбер».

— Что собой представляет созданное решение?

Итоговое решение стало универсальным для всех компаний, мы смогли создать единый профиль клиента, не привязанный к конкретному продукту или компании. Обрабатывая обращения от клиентов, мы получаем «портрет» пользователя продуктов и на основе аналитики клиентских путей, обращений, предложений и жалоб можем предлагать клиенту новые услуги или продукты.

При работе с клиентами оператору нужно использовать данные из многочисленных систем, поэтому мы реализовали возможность интегрировать в рабочее место оператора данные из автоматизированных систем «Сбера», которые необходимы для обработки обращений. Гибкая ролевая модель CRM позволила настроить решение в соответствии с требованиями безопасности банка, предоставить доступ к необходимым для работы данным и обезопасить клиентскую информацию.

— Что удалось лучше всего?

Преимущество нашего решения в гибкости – запуск новых проектов обходится без участия разработчиков и занимает считанные дни, что является скорее исключением, чем правилом для больших корпораций. Под каждый бизнес-процесс любой компании группы можно реализовать любые правила работы с обращениями – SLA, уведомления, эскалация, автоматическая отчетность. У команды появились планы по выводу решения на внешний рынок, о результатах расскажем на Data Award 2024.

— Какие результаты были достигнуты?

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

Если говорить о влиянии на бизнес и клиентский опыт, то омниканальность решения позволяет гибко управлять ресурсами, формировать единую историю взаимоотношений с клиентами, единый клиентский путь, обеспечивать доступность поддержки продукта. Единый профиль клиента позволяет нам развивать продукты, повышать уровень сервиса. После перехода на новую CRM уровень удовлетворенности в части поддержки продуктов компаний В2В группы «Сбер» вырос с 74,3% до 81,1%. И мы не останавливаемся на достигнутом.

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

Если говорить об операционной эффективности, то уровень доступности линии поддерживается в целевых показателях, сокращено время обработки обращений в среднем на 30%, увеличен показатель загрузки операторов с 70% до 90% за счет омниканальности. Сокращено время реакции на сбои – имея единую систему отслеживания инцидентов, можем оперативно информировать всех участников процесса. Единый дашборд позволяет мониторить нашу работу по всем компаниям группы.

— А что говорит персонал?

Удобный интерфейс единого рабочего места позволяет минимизировать трудозатраты наших операторов. По проведенным опросам, удовлетворенность рабочим местом по 10-ти бальной шкале выросла и сейчас достигла 8,5-8,6 баллов.

— Какими финансовыми эффектами можете похвастаться?

Благодаря автоматизации и интеграции с внешними системами сокращено время обработки обращений по всем каналам с 6,2 до 4,2 минут. При объеме в 400 тыс. обращений в месяц это дает экономию компаниям группы в 150 млн руб. в год. Кроме того, как и планировали, произошло сокращение затрат на доработки.

— Каково значение проекта для компании?

Уже к началу второго квартала 2022 года более 700 сотрудников из 30 компаний B2B группы «Сбер» подключились к работе в новой CRM. В единой системе сотрудники увидели профиль клиента и его запросы по всем продуктам компаний. На основе аналитики по запросам клиентов можно предугадывать их потребности и превентивно предлагать новые продукты и услуги.

Можно сказать, что мы победили кризис. Разработав и внедрив нашу CRM, мы закрыли все риски, которые видели до внедрения. Сейчас мы работаем на собственном решении. Разработанный нами инструмент повысил нашу эффективность по всем направлениям: экономика, операционное управление и, главное, — удовлетворенность клиентов и персонала.

— В каком направлении будет развиваться платформа?

Первое направление – в сторону клиента: накапливая данные о наших клиентах о его обращениях по продуктам группы «Сбера», мы сможем более точно и превентивно решать проблемы клиента, закрывать его потребности и предлагать актуальные услуги и продукты. Удовлетворенность клиента – наш важнейший приоритет.

Второе направление – в сторону пользователей: в рамках единого окна у операторов контакт-центра должен быть доступ ко всем необходимым данным о клиенте: прошлые обращения, продукты, актуальные предложения для клиента. Оператор в рамках одного окна должен иметь возможность и найти посылку клиента в «СберЛогистике», и оформить договор по «СберЛизингу».

Наконец, в сторону технологий: мы не перестаем развивать CRM, наращиваем функциональность платформы, повышаем надежность системы и защищенность данных клиентов. В 2023 году основной задачей будет интеграция с новой платформой контакт-центра «Сбера» – SberContactPlatform. Комплекс решений CRM и SberContactPlatform должен полностью закрыть потребность в собственном решении и обеспечении технологического суверенитета «Сбера» в сфере контакт-центров.