Статьи

По данным международных исследований, правильно выстроенное управление жизненным циклом продукта (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), и Александр Тимошин, директор АППИУС

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

Почему бизнесу не подходит «личная» логика

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

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

Объекты, блоки и папки – три кита, на которых все держится

Чтобы разобраться, какие облачные хранилища бывают, нужно обратить внимание на два ключевых параметра: как осуществляется доступ к хранилищу и по какой модели оно развернуто. По архитектуре доступа существуют объектные хранилища (например, S3), блочные хранилища и файловые хранилища (такие как NAS).

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

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

Файловые хранилища работают по протоколам NFS, CIFS или SMB и выглядят для пользователя как сетевые папки с иерархией каталогов. Один из самых распространенных примеров – FTP-хранилище, где есть общая файловая папка со структурой и иерархией. Данный тип хранилища удобен для совместной работы с файлами, общих сетевых дисков и резервных копий, когда нужны привычные «обычные» сетевые папки.

Свое, чужое или «все сразу»

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

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

Хранилище в частном (приватном) облаке, напротив, полностью контролируется ИТ-персоналом самого заказчика. Такое выделенное облачное хранилище может находиться либо в собственном ЦОДе компании, либо быть частью инфраструктуры облачного провайдера, но изолированной и настроенной индивидуально под заказчика. Для данных под 152-ФЗ и требований ФСТЭК часто требуется именно частное облако с сертифицированным ПО.

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

«Горячее», «холодное» и «ледяное» – почему дешевый гигабайт может разорить

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

«Горячее» (standard) хранилище предполагает высокую доступность и частые операции чтения и записи. Именно такие хранилища – самые дорогие в линейке, потому что они рассчитаны на постоянную работу с данными.

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

«Ледяное» (glacier или ice) хранилище подходит для архивов, которые нужно хранить по внутренним политикам организации или требованиям регулятора. Оно очень дешевое, но данные из него читаются и выгружаются долго, а цена за каждую операцию чтения, напротив, крайне высока.

Как не заблудиться в этих трех соснах

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

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

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

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

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

Вывод

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

Автор — Полина Абаимова, менеджер продукта Отдела развития облачных продуктов компании ГК Softline («Софтлайн Решения»)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компании редко начинают цифровизацию с глобальной стратегии. Чаще всего отправной точкой становится конкретная «боль»: договоры согласовываются слишком долго — значит, нужна система электронного документооборота (СЭД); поддержка пользователей хаотична — требуется платформа для сервис-деска; выполнение многочисленных рутинных операций не дает персоналу сфокусироваться на сложных, интересных задачах, движущих компанию вперед, — пора внедрять искусственный интеллект.

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

Что скрывается за интерфейсом корпоративного приложения

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

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

Второй слой — интеграции. Новая СЭД должна обмениваться документами с ERP, CRM — получать справочники из учетных систем, сервис-деск — подтягивать структуру подразделений из HR-контура. Без спроектированной заранее архитектуры обмена приходится использовать «костыли»: ручные выгрузки в Excel, промежуточные базы, скрипты, которые написали «под задачу» и забыли задокументировать. И когда накапливается критическая масса таких «временных решений», система перестает быть предсказуемой.

Третий слой — информационная безопасность. Любое приложение, работающее с персональными данными, коммерческой тайной или финансовыми операциями, обязано соответствовать внутренним политикам и требованиям регуляторов. Нужно проработать модель доступа, настроить журналирование, подключить системы сбора событий (SIEM) и предотвращения утечек (DLP), а нередко — еще и многофакторную аутентификацию. Если вопросы безопасности начинают решать уже после выбора бизнес-приложения, проект рискует упереться в аттестацию по ФСТЭК, доработку инфраструктуры и пересмотр архитектуры. В результате внедрение затянется на месяцы.

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

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

Шестой слой — технологическая стратегия. Для проектов с ИИ это критично вдвойне: интеллектуальный бот или агент требует фундамента из правильно структурированных данных, продуманной архитектуры их хранения и вычислительных мощностей (например, серверов с GPU). Но прежде чем закупать «железо» и разворачивать модели, нужно ответить на стратегический вопрос: зачем это бизнесу и как решение будет развиваться в ближайшие 3–5 лет? Именно стратегия определяет все остальное — от выбора платформы до бюджета на развитие.

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

Как многослойная архитектура проявляется в реальных проектах

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

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

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

Однако технической изоляции недостаточно. Во-первых, требуется содержательная классификация: каждому документу должен быть присвоен гриф конфиденциальности — коммерческая тайна (КТ), служебная тайна (ДСП) или секрет производства (ноу-хау). Сами данные при хранении и передаче необходимо шифровать. Во-вторых, сотрудник обязан подтвердить, что осознает уровень ответственности. Для этого перед открытием документа система должна выводить дисклеймер с требованием подтвердить отсутствие рядом третьих лиц — и только после этого предоставлять доступ к содержимому.

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

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

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

Почему комплексный проект выходит за рамки сроков

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

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

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

Архитектурный подход как стандарт

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

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

С чего на самом деле начинается внедрение

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

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

• Оценены ли требуемые мощности и достаточно ли текущих ресурсов?
• Проработаны ли сценарии обмена данными со смежными системами?
• Учтены ли требования к защите данных в соответствии с их категорией?
• Определен ли порядок обучения сотрудников и обновления регламентов?
• Проанализировано ли состояние данных, подготовленных к загрузке?
• Заложена ли возможность масштабирования системы на горизонте 2-3 лет?
• Закреплена ли ответственность за поддержку и обновление системы после запуска?

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

Автор – Кирилл Александров, руководитель направления продаж комплексных бизнес-решений «Софтлайн Решения» (ГК Softline)

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

Где ИИ реально работает в СЭД

ИИ сегодня уже стал частью большинства российских СЭД. Речь не об отдельной умной кнопке, а о полноценном интеллектуальном слое внутри систем. В его основе — языковая модель (LLM), дополненная RAG-подходом: перед тем как сформировать ответ, система подтягивает релевантные фрагменты из корпоративных документов — договоров, переписки, базы знаний — и отвечает уже с опорой на этот контекст. Поверх этого слоя реализованы прикладные сценарии. В отличие от внешних ассистентов, здесь ИИ действует в рамках корпоративных регламентов, поэтому пользователь работает не с абстрактным ответом, а с результатом, включенным в действующий бизнес-процесс.

Самый простой сценарий – подготовка документов. Руководитель или сотрудник формулирует задачу в интерфейсе — например, просит подготовить официальный ответ партнеру, — а система предлагает несколько вариантов текста, которые дальше можно дорабатывать, согласовывать, утверждать. Еще один сценарий — поиск информации. Вместо того, чтобы искать по папкам и фильтрам, сотрудник просто задает вопрос в СЭД, а ИИ помогает найти нужные документы или данные в контексте. Третий сценарий — постановка задач. Руководитель создает запрос в свободной форме, — система оформляет его по рабочему шаблону: уточняет цель, сроки и ожидаемый результат.

Роль-ориентированная аналитика документов: от вычитки к управлению рисками

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

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

Экономика и масштаб

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

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

При этом система не становится полностью автономной. Например, в пилотах по подготовке ответов на обращения граждан ИИ сократил время подготовки черновика с 15 до 5 минут, однако около 13% ответов потребовали полной переработки, а средняя оценка качества составила 63%. То есть система ускоряет работу, но ответственность за итоговый результат остается у специалиста.

Таким образом, разговор об экономическом эффекте ИИ в документообороте никогда не сводится к сокращению людей. Главное, что получает бизнес, — возможность обрабатывать растущий объем документов без пропорционального увеличения нагрузки на ИТ и бизнес-подразделения. ИИ в СЭД позволяет компании расти по числу договоров, партнеров и операций без потери управляемости и резкого роста издержек.

Ограничения и условия внедрения: где проходят границы ИИ

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

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

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

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

ИИ в СЭД как управленческий инструмент

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

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

Автор — Полина Дуйкова, директор направления СЭД/ECM «Софтлайн Решения»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

До 95% компаний в России и мире внедряют ИИ без необходимой отдачи и не окупают инвестиции. Об этом и самых распространенных ошибках говорится в исследовании «От пилота к масштабу: как встроить ИИ в процессы и получить отдачу», проведенном Школой управления «Сколково».

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

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

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

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

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

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

При этом на пике популярности искусственного интеллекта многие компании запускают ИИ-проекты скорее ради статуса, чем ради результата.

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

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

Наконец, шестая причина — использование устаревших методов анализа эффективности внедряемых ИИ-процессов. Анализ показал: классический метод CRISP-DM и его отраслевые продолжения (DataPro, CRISP-ML(Q), MAISTRO) задали высокие стандарты работы с данными, но почти не учитывали управленческие и культурные барьеры. Из-за этого даже технически безупречные решения нередко оказывались невостребованными в компаниях.
При этом авторы выявили, что пробел восполняет обновленный фреймворк (AI Success Cycle), в котором управление когнитивной дистанцией и мониторинг принятия технологии пользователями встроены на каждом этапе. Это помогает адаптировать и внедрять ИИ-решения так, чтобы они естественно «приживались» в организации и приносили реальную пользу. Например, команда делает шаг вперед, показывает промежуточный результат, получает комментарии от бизнеса и дорабатывает продукт с их учетом. Такой ритм, по мнению экспертов, помогает держать участников «на одной волне» и превращает разницу в подходах в источник знаний, а не конфликтов.

Исследование показало, для эффективного внедрения ИИ-проектов компаниям необходимо выполнять следующие правила:

• оценить культуру принятия решений в компании, чтобы понять, насколько она реально data-driven;
• провести аудит данных до старта проекта и создать Data Story как «единый источник правды» для бизнеса и ИТ;
• разбить ключевые процессы на этапы и определить, где безопасно автоматизировать, а где важно оставить человека;
• создавать кросс-функциональные команды и назначать брокеров знаний, чтобы бизнес и разработка разговаривали на одном языке;
• запрашивать у команды рабочий прототип каждые 3–4 недели и обсуждать прототипы вместе с бизнесом, а не только внутри разработки;
• внедрять обновленный фреймворк (AI Success Cycle), чтобы эффективнее встроить ИИ в бизнес-процессы.

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

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

2. Проверять, есть ли у проекта реальная цель. Формулировка цели «внедрить ИИ» — тревожный сигнал. Настоящая цель звучит как конкретная бизнес-задача: «снизить коэффициент оттока на 10%» или «сократить время обработки заявки на 20%». Если такого фокуса нет, проект рискует превратиться в витрину.

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

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

5. Работать через граничные объекты. User Story, Data Story, MVP-прототип, дашборд с метриками — любые артефакты, которые понятны и бизнесу, и разработчикам. Важно фиксировать договоренности через такие объекты, чтобы все стороны видели одно и то же и могли отслеживать прогресс.

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

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

За последние десять лет спрос на бухгалтеров вырос на 318% — такие цифры приводят hh.ru и банк «Точка». Проблема в том, что предложение не успевает за спросом. По оценке правительства РФ, дефицит в этой сфере — около 1,5 млн кадров. И это неудивительно: чем крупнее компания, тем больше документов, сверок и операций ложится на плечи одного специалиста. При этом задач становится все больше — меняется законодательство, усложняются стандарты, растут требования.

Локальная автоматизация проблему не решает. Даже если компания использует «1С», СБИС, «Диадок», CRM и Excel-шаблоны, это еще не означает, что процессы стали сквозными. Данные остаются разрозненными: счета — в одном окне, договоры — в другом, выписки — в интернет-банке, сверки — в почте или мессенджерах. В итоге бухгалтеру все так же вручную приходится проверять:

• первичные документы — счета, акты, УПД, договоры. Нужно открыть, сверить, внести в учет, а если пришли по почте — сохранить, переименовать, согласовать;
• взаиморасчеты — даже обычная сверка с данными контрагента может занять часы, особенно в случае с авансами, частичными оплатами или ошибками в назначении платежа;
• банковские выписки — бухгалтер получает их ежедневно, разносит оплаты по договорам, проверяет, кто и за что заплатил. Если платеж пришел с ошибкой, без ссылки на договор или в валюте, требующей конвертации, обработка занимает еще больше времени;
• отчетность — может формироваться автоматически, но сдача в ФНС, ФСС и Росстат требует ручной загрузки, сверки квитанций, контроля статусов и оперативной реакции на запросы контролирующих органов.

Кто не ошибается

При ручной работе ошибки — лишь вопрос времени. Проводки забываются, документы дублируются, и все это всплывает в самый неподходящий момент. Достаточно одной неверной цифры в реквизитах контрагента — ИНН, КПП, расчетном счете или БИК, — чтобы деньги ушли не туда. Это не только прямые финансовые потери, но и риск нарушения валютного законодательства и 115-ФЗ: банк вполне может признать такую операцию подозрительной.

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

Ошибки в расчетах зарплаты и страховых взносов — одна из самых частых причин штрафов и претензий от ПФР, ФСС и ФОМС. Даже небольшая неточность в отчетах — будь то 6-НДФЛ, СЗВ-ТД или РСВ — почти гарантированно выявляется при камеральной проверке. В итоге бухгалтерия тратит массу времени и сил на исправление ошибок и подготовку уточненных отчетов.

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

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

Автоматизация бухгалтерских процессов: что происходит внутри

Представьте, что рутинные операции бухгалтера в «1С», СБИС или «Диадоке» выполняет виртуальный сотрудник — и делает это в среднем в 2–3 раза быстрее человека. Чтобы это организовать, достаточно внедрить готовую RPA-платформу (Robotic Process Automation) и настроить роботов под конкретные задачи. По нашему опыту, половина компаний успешно реализуют такие проекты самостоятельно при наличии внутренних компетенций и ИТ-ресурсов.

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

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

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

После обработки данных робот формирует готовые документы — акты, отчеты, проводки — в нужном формате: PDF, Excel, XML или напрямую в интерфейсе учетной системы. Он может отправлять их через внешние ЭДО-сервисы, корпоративные платформы и, при наличии доступа, через модули сдачи в ФНС. Также он умеет отслеживать статус доставки, сохранять подтверждения и архивировать данные.

Что может помешать автоматизации работать как надо: семь причин

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

1. Автоматизация хаоса

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

По данным ОБИТ, 35% провалов ИТ-проектов связаны именно с несоответствием ИТ-решений реальным бизнес-требованиям, в том числе из-за недостаточного анализа на старте.

2. Процесс описан «на коленке»

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

3. Проблемы с доступами и ИБ

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

4. Нет синхронизации между командами

Сначала настроили робота, а затем компания перешла с Google Docs на «МойОфис», сменила интегратора ЭДО или перенесла данные в другую CRM. Когда нет налаженной коммуникации между ИТ, бизнесом и командой автоматизации, роботу «забывают» сообщить об изменениях, и автоматизация внезапно перестает работать.

5. Стремление автоматизировать все

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

6. Недооценка сложности интеграции

Сложность интеграции зависит не столько от RPA-платформы, сколько от того, насколько «открыта» и готова к взаимодействию исходная система. С «1С», СБИС или «Диадоком» обычно проблем нет — там все стандартизировано. С кастомными системами могут возникать нюансы. Чаще всего интеграцию удается настроить через API, но нужно быть готовыми к тому, что если они реализованы недостаточно качественно, то потребуются доработки.

7. Считать окупаемость только в деньгах

Как бизнес может оценивать окупаемость RPA-проекта: допустим, бухгалтер обходится компании 1,2 млн руб. в год, а лицензия на робота — 1,5 млн. На первый взгляд, внедрение робота кажется невыгодным. Но так ли это?

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

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

Пора нанимать роботов: чек-лист для бизнеса

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

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

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

Автор – Сергей Азаров, руководитель направления департамента бизнес-решений «Софтлайн Решения» (ГК Softline)

«СберАналитика» разработала сервис «Геоаналитика», который помогает предпринимателям эффективно использовать данные о потенциале локации для принятия обоснованных бизнес-решений. С подробностями проекта знакомит Денис Козицкий, директор по развитию ИТ и инновациям компании «СберАналитика».

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

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

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

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

- Почему так важно и так сложно выбрать подходящую локацию?

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

Анализ множества различных критериев требует большого объема данных и серьезных инструментов для их глубокого изучения. Эту сложность берет на себя сервис «Геоаналитика», делая работу над стратегическим планированием доступной и удобной для компаний любого размера.

- Каковы ключевые возможности вашего сервиса?

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

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

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

- На какие технологии и платформы опирается решение?

Платформа «Геоаналитика» работает на базе «связки» Django и Vue. В продукте мы используем решения на стыке технологий (геоданные и большие данные). Кроме того, мы исследуем на базе нашей платформы возможности новых технологий подготовки и отображения данных.

- Какие данные обрабатывает сервис?

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

- Какой математический аппарат используется в продукте?

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

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

- Какую функциональность или особенность решения вы считаете реализованной наиболее удачно?

Главным достоинством «Геоаналитики» мы считаем возможность быстро работать с очень большими объемами данных. Сервис построен на базе фактического потребления с применением ML-моделей, что позволяет предоставлять точные ответы на все индивидуальные вопросы клиентов, строить предиктивные и гравитационные модели и предоставлять отчет в формате pdf. в режиме онлайн. Точность модели прогнозирования товарооборота составляет 90%, а в 80% подобранных локаций заказчик достигает ожидаемого результата.

- Каков круг заказчиков этого решения?

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

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

Благодаря интеграции с ГБУ «Малый бизнес Москвы» сервис «Геоаналитика» стал доступен всем текущим и будущим предпринимателям уже сейчас. Данные открыты по городу Москва.

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

- На какие результаты могут рассчитывать клиенты сервиса?

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

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

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

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

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

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

- По каким направлениям планируете развивать сервис?

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

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

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

Продукт «Геоаналитика» основан на уникальных, запатентованных алгоритмах, которые обеспечивают высокую точность и большую вариативность показателей, используемых для исследований. Например, патент номер 2766548 (способ и устройство определения местоположения терминала) позволяет обеспечить почти 100% покрытие по размещению торговых точек и корректно оценивать их местоположение в гексагональной сетке.

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

ИИ и облака

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

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

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

Геополитика. Эпоха «простых и доступных больших облаков», где главные американские гиганты вроде Amazon, Google и Microsoft без особых проблем предоставляли свои сервисы по всему миру, постепенно уходит в прошлое. Европейский бизнес все острее осознает угрозу неконтролируемого роста стоимости, а также опасность ограничения доступа к собственным данным, которые по факту им не контролируется. В результате многие компании начинают консолидироваться вокруг местных поставщиков, пытаясь выстраивать инфраструктуру, меньше зависящую от глобальных гиперскейлеров.

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

На фоне этих факторов формируется сразу несколько отчетливых тенденций:

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

Локализация против глобализации

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

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

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

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

Логистика и серверы

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

Кроме того, крупные игроки вроде Intel и AMD представили новые сверхмощные процессоры, в которых насчитывается до 288 физических ядер, при этом энергопотребление составляет всего 500 Вт. Такая эффективность открывает перед облачными провайдерами и крупными центрами обработки данных серьезные возможности для оптимизации: теперь можно разместить то же количество вычислительных ресурсов в половине одного стандартного шкафа вместо, например, четырех. Для экологии это означает меньшее энергопотребление, а для бизнеса — более высокую плотность размещения серверов и экономию на счетах от дата-центров.

Выводы

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

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

Автор — Руслан Райкевич, СТО ActiveCloud (ГК Softline)