Статьи

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

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

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

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

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

Отчет Service Desk видит только вторую половину инцидента

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

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

Некоторое время пользователи не замечали проблемы. Документы формировались, открывались и выглядели готовыми к отправке. Однако комплекты по ближайшим отгрузкам не получали требуемого статуса. В 9:05 специалист по оформлению отгрузок увидел, что машины готовы к выезду, а документы по ним продолжают находиться в промежуточном состоянии. Он обратился в поддержку. В 9:10 инцидент уже был в работе, а в 9:45 специалисты восстановили технический обмен.

В отчете результат выглядит хорошо: первая реакция — пять минут, восстановление с момента обращения — 40 минут, SLA выполнен. Но на самом деле бизнес жил с нарушением не 40, а 85 минут. Первые 45 из них не попали в отчет Service Desk, потому что никто еще не зарегистрировал инцидент.

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

Есть и вторая «слепая зона». В 9:45 интеграционная служба снова заработала, но процесс отгрузки еще не восстановлен. Нужно обработать накопившиеся документы без потерь и дублирования, синхронизировать их статусы с внутренней системой и проверить отгрузки, затронутые инцидентом.

Кроме того, причина сбоя может остаться. Если обмен восстановили перезапуском службы, организация уменьшила продолжительность текущего инцидента, но не обязательно снизила вероятность следующего. Показатель среднего времени, необходимого для устранения сбоя (Mean Time to Repair, MTTR) может улучшаться, а надежность сервиса — нет. Значит, вопрос уже не в том, как еще быстрее обработать заявку.

Что должно сработать без звонка пользователя?

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

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

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

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

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

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

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

Как применить эту модель к своим сервисам

Здесь легко сделать неверный вывод: решить, что теперь нужно расширять мониторинг всех систем и покупать новые инструменты. Начинать следует не с технологий, а с нескольких действительно критичных бизнес-операций. Возьмите одну из них и спросите: узнает ли ИТ о нарушении без звонка пользователя? Через сколько минут появится сигнал и будет ли из него понятно, что именно идет не так? Если ответов нет, разрыв в обнаружении уже найден.

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

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

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

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

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

Что можно изменить за один квартал

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

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

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

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

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

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

***

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

Автор – Андрей Шантарин, ИТ-директор завода «Уралхиммаш»

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

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

Сколько на самом деле стоит шестичасовой сбой

Возьмем интернет-магазин с годовой выручкой 240 млн руб. Ее средняя выручка за календарный час составляет около 27 тыс. руб., однако продажи распределяются неравномерно. Если основная активность приходится на период с 10:00 до 22:00, стоимость рабочего часа приближается к 55-60 тыс. руб. Допустим, сайт перестал принимать заказы на шесть часов в субботу. В этом случае потеря выручки составит примерно 330-360 тыс. руб.

На этом расчет часто заканчивается, хотя это только самая заметная часть ущерба. Во время сбоя простаивают сотрудники офиса и склада, часть операций останавливается, часть выполняется вручную, часть переносится на следующие смены. Если инцидент затронул 10-15 человек, а полная стоимость их рабочего часа составляет 800-1000 руб., компания потеряет еще 50-90 тыс. руб.

Добавим штрафы, срочную доставку уже оплаченных заказов, претензии со стороны партнеров и маркетплейсов. В зависимости от модели бизнеса это еще 50-150 тыс. руб. Техническое восстановление тоже требует денег. Инженеры проводят диагностику, меняют компоненты, привлекают дополнительные ресурсы, заказывают срочную доставку оборудования. Допустим, подрядчик выставил счет на 100-120 тыс. руб.

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

Таким образом, прямо измеримые потери уже достигают 600-800 тыс. руб. Если часть покупателей ушла к конкурентам, компания также теряет будущие покупки и деньги, которые ранее потратила на привлечение этих клиентов. С учетом отложенного эффекта полная стоимость шестичасового сбоя может приблизиться к 900 тыс. или даже 1,5 млн руб.

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

Почему реактивный сервис оказывается дорогим

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

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

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

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

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

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

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

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

Как продлить жизнь EOSL-оборудования без постоянного аврала

Один из наших проектов был связан с поддержкой систем хранения данных в региональном медицинском ЦОДе. В инфраструктуре использовались EMC VNX5400, HPE 3PAR 8200 и HP P2000 G3. Вендорская поддержка этого оборудования закончилась, оригинальные запчасти стали дефицитными, а сроки поставки перестали быть предсказуемыми.

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

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

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

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

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

SLA должен начинаться с бизнес-процесса

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

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

После определения сервисов бизнес присваивает им классы критичности. Для систем уровня Critical могут потребоваться доступность 99,95%, круглосуточная реакция в течение 15 минут и восстановление за два часа. Для High требования будут мягче: доступность 99,9%, реакция в течение часа и восстановление за четыре часа. Системам классов Medium и Low часто достаточно поддержки в рабочее время и восстановления на следующий рабочий день.

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

Отдельно нужно различать время реакции и время восстановления. Реакция означает, что инженер принял заявку и начал работу. Однако она ничего не говорит о том, когда сервис вернется в эксплуатацию. Resolution Time, RTO и RPO также описывают разные обязательства. Если стороны используют эти показатели как взаимозаменяемые, спор при первом же инциденте почти неизбежен.

Штрафы в SLA тоже должны отражать реальный риск. Условный 1% от месячной стоимости поддержки не меняет поведение подрядчика и не компенсирует ущерб, если простой критичного сервиса обходится компании в миллионы рублей. Размер санкций нужно соотносить с ожидаемыми потерями и зоной ответственности каждой стороны.

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

Что можно изменить уже на следующей неделе

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

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

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

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

Автор — Владимир Кудряшов, директор сервисного отдела компании «ГИГАНТ — Компьютерные системы»

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