Comments 20
и не сломалась при очередном обновлении 1С
Ну как не пнуть 1С мимоходом.
капитализация игроков вроде Box и OpenText сократилась на треть за несколько месяцев
Так в чём причина-то? Только из-за опасений? Или уже есть реальные разработки на замену СЭД?
Конечно есть разработки! Теперь полностью решен вопрос с заявлениями на отпуск!
Причина падения капитализации не в фантазиях аналитиков под утренний кофе. Инвесторы испугались не абстрактной «угрозы ИИ», а конкретного демо: 12 января 2026 года Anthropic показала Claude Cowork - агента, который сам открывает файлы, правит таблицы, пишет отчёты и согласует документы без человека. Когда такое показывают в прямом эфире, а не в научной статье, деньги начинают перекладываться мгновенно, с этого и началася пресловутый SaaSpocalypse.
Теперь про «полностью решён вопрос с заявлениями на отпуск». Да, звучит как анекдот. И я бы тоже смеялся, если бы три недели назад не развернул на OpenClaw систему, которая делает это за минуту. Но, внимание, она же за те же минуты может и прогнать договор на 100500 рублей по цепочке из пяти человек, пинает опаздывающих в Телеграм, сверяется с бюджетом в 1С и складывает подписанный PDF в архив с правильным именем. Именно так и начнется подпольный бунт против вендорского засилья в заказной разработке/интеграции. Заявления на отпуск - это верхушка айсберга, демка для скептиков. А под водой уже полноценный конвейер, который собирается из кубиков LLM за выходные.
Нейро текст статьи слишком заметный. Это отталкивает.
О, классика! Когда аргументов против сути не остаётся, начинается проверка стиля на детекторе нейросетей. Знаете, как это называется в риторике? Ad hominem. Бить не по тезисам, а по автору - точнее, по подозрению, что автора вообще не существует, а статья сгенерирована кнопкой «сделать красиво». Видимо, я таки пишу настолько хлёстко, что даже нейросети позавидовали бы.
А вот вам вопрос: почему вас задел именно стиль? Может, потому что по существу возразить нечего? Цифры по Box и OpenText смотрели? Отчёт Celent читали? Или проще сказать «это нейросеть», чем признать, что привычный бизнес на СЭД катится к закату?
Давайте так: если от стиля тошнит - окей, я могу писать ещё более коряво, специально для вас. Но суть от этого не изменится. ИИ-агенты уже оркеструют документооборот быстрее, чем вы допишете ТЗ. Хотите опровергнуть - давайте конкретику, цифры, кейсы. А стилистический анализ оставьте филологам на пенсии.
Или - давайте уж откровенно - видимо вы сами топ-менеджер одного из пресловутых «лидеров СЭД» и у вас болит от того, как точно все эти тезисы ложатся на ваш личный квартальный бонус? Я понимаю, когда под угрозой годовая премия, проще всего кричать «это фейк, автор нейросеть!». Но давайте честно: если бы статья была тупой и неверной, вы бы размазали её фактами, а не диагнозами стиля. А раз вместо фактов - догадки о идентичности автора, значит, по существу вам крыть нечем. И от этого действительно может быть «жим-жим».
Поток мыслей больше, чем живого текста в самой статье 😁
О, а это уже интересный поворот. Сначала вам нейросеть чудилась, теперь, наоборот, «поток мыслей больше, чем текста». Определитесь уже: то ли я бездушный алгоритм, то ли, наоборот, слишком живой и многодумный. Или это такой изящный способ сказать, что вы не осилили дочитать, но мнение оставить надо?
Знаете, в психологии это называется проекция. Когда человек не может переварить смысл, он начинает обсуждать форму. «Слишком нейросетевой стиль» превратилось в «слишком много мыслей». А чего вы ждали от автора, который разложил ваш бизнес-модель на атомы? Что я вам тут смайликов накидаю, чтобы полегче читалось?
Давайте так: вы мне лучше скажите, как лично у вас обстоят дела с КЭДО. Внедрили уже «коробочку» от лидера рынка, или всё ещё Excel по сетке гоняете? А то я смотрю, у вас тут поток комментариев больше, чем аргументов, ну так что, таки ведете график отпусков в Excel, коллега?
Агенты пишут статью про агенты.
Красивое...
Агент не тупит. Ему не надо объяснять, что такое «просрочен на три дня»
ха-ха-ха. А потом выясняется, что промпт-инженер считал просрочку от последнего шага, а заказчик - от начала процесса. А писателя ТЗ, который бы это заметил нет - всех выгнали и заменили Клодом
Ну или вот так: "Да, ты совершенно прав, на этапе "отправь финансовый отчёт всем ответственным" не надо отправлять его нашему кладовщику. Я исправлю это со следующим отчётом". Причём в этой ситуации не надо придумывать никакой физики - тут просто неверное понимание умолчаний.
В общем, согласен, ИИ всех победил, пойду искать простыню и искать направление к кладбищу.
Вы говорите, что «промпт-инженер считал просрочку от последнего шага, а заказчик - от начала процесса». Это и есть главная проблема. Вот только в старой парадигме компания узнала бы об этом не после первого же теста за час, а через три месяца, когда вендор наконец то раскачался и выкатил релиз, а бухгалтеры уже вручную всё пересчитали и тихо ненавидили и вендора и подрядчика.
Разница вот в чём: LLM ошиблась, ткнули пальцем, она исправилась. И это заняло не спринт с планированием, а время обеда. Система не стала идеальной, но скорость исправления ошибок выросла в сто раз. Раньше ошибка в логике стоила миллион деняк и месяц ожидания. Теперь она стоит полчаса диалога владельца процесса.
А кто пальцем будет тыкать? Бизнес сам будет следить? Увольте - у них своих бизнесовых дел хватает, надо деньги зарабатывать.
Вы пишете, что все отделы внедрения должны строевым шагом отправиться в сад. А я вижу так, что у аналитиков и архитекторов наоборот работы прибавится, потому что итерации ускорятся. То, что хотелки будут реализовываться быстрее не отменяет работы по планированию и выстраиванию бизнес-процессов
Именно так! Это как раз и есть тот сдвиг парадигмы, ради которого все затевалось, просто чуть с другого ракурса. Аналитики и архитекторы не исчезают. Они переезжают. Раньше они сидели на стороне вендора, потому что без них никто не мог заставить «коробку» работать. Все приходили к заказчику с ритуалом: интервью, моделирование, ТЗ, разработка, внедрение. Все знания былы в головах этих людей. И вендор брал деньги не столько за софт, сколько за эти головы, типа “в аренде”.
Теперь этот артефакт больше не нужен. Компания может иметь собственный центр компетенций, который не ждёт релизный цикл вендора, а превращает хотелку бизнеса в работающий процесс в течение дня. Да, это требует, чтобы в компании был кто-то, кто понимает и бизнес-процессы, и как общаться с агентами. И это не «Вася из бухгалтерии, который немножко шарит в Excel». Это новый тип штатного аналитика-архитектора, который владеет инжинирингом и архитектурой агентных связок.
В целом таких людей нужно меньше, чем в классическом проекте внедрения, потому что итерации сжаты в сто раз. Раньше один аналитик мог вести проект полгода, а теперь он за утро настраивает маршрут, за обед получает обратную связь от бизнеса, к вечеру правит. И при этом не пишет ТЗ на 200 страниц, а просто общается с агентом и с заказчиком в одном лице. Остальные аналитики, которые раньше сидели на стороне вендора и ждали заявок, теперь либо переходят в штат компаний, либо ищут другой заработок. Но рынок аналитики не схлопывается, он просто перетекает из вендора в инхаус.
Раньше вендор продавал «коробку» и обязательно пристёгивал к ней услуги: настройка, доработки, поддержка. Это была его рента. А теперь бизнес говорит: «Спасибо, у меня свой аналитик есть, он на выходных собрал нам документооборот на OpenClaw, и интеграции сам допилил. Зачем мне ваш софт и ваша поддержка? Кто вы вообще?». Вендор теряет доходы не только от лицензии, а от всего пакета услуг. Остаётся голая инфраструктура, которую уже продают облачные провайдеры, а не СЭД-вендоры.
Так что да, аналитиков и архитекторов работы прибавится. Просто бизнес резонно спросит: «А почему я должен кормить вашу команду, если могу нанять двух таких же (или даже уволенных на волне сокращения ваших) спецов к себе в штат и они будут делать в пять раз быстрее и без абонентской платы?» Вот это и есть сдвиг парадигмы. Центр компетенций переезжает с территории вендора на территорию бизнеса, а вендор становится лишним звеном, которое пытается продать воздух под видом «уникальной методологии».
И да, «тыкать пальцем» будет не сам бизнес, а эти новые штатные архитекторы. Они будут переводчиками между предметной областью и агентами. Ровно так же, как раньше аналитик вендора был мостом между заказчиком и разработчиками. Только теперь разработчики не нужны как класс, а мост стал прямым и дешёвым. Именно поэтому я и говорю: бизнес вендора мёртв, а центры компетенций в бизнесе только растут.
но скорость исправления ошибок выросла в сто раз
Соответственно и скорость появления выросла?
Это называется сжатие цикла обратной связи. Когда итерация ускоряется, время поставки (time-to-delivery) падает кратно. Классический кейс: после перехода на Scrum Lead Time сокращается, а частота релизов возрастает.
Раньше: длинный цикл (аналитика - ТЗ - разработка - тестирование - релиз). Ошибка, найденная в конце, стоит дико дорого.
Сейчас: LLM-агент выдаёт результат за минуты. Да, он может ошибиться. Но in-house бизнес-аналитик видит ошибку сразу и тут же правит. Итерация занимает не месяцы, а день.
Половина российских компаний уже используют agile именно для сокращения time-to-market на 15–20%, треть имеет свои собственные центры разработки, посмотрите на hh кого именно сейчас нанимают в IT наши “традиционные офлайновые бизнесы” типа FMCG ритейла, DIY, или ипотечные компаний (прости господи...) - процесс переезда центров компетенций уже идет
Автор, только один вопрос. Вы сейчас серьезно???
Это офигенно - сказать "все договора идут к Петровой". И они даже пойдут.
Вот только через пять лет к Вам придет регулятор. Не с паяльником, а с зениткой. И запросит детальную информацию по согласованиям за пять лет. Кто и на каких основаниях, "покажите приказ". И за каждое "а нету" будет расстреливать из этой зенитки.
Приказы по организации на наделение правом подписи тоже LLM будет генерировать? На основании той же инструкции? А Петрову вообще юридически можно наделять правом подписи документов выше 10 миллионов? Уровень должности позволяет? А квалификация? На некоторые должности ЦБ утверждает людей. Кто согласует ее право подписи? Кто при ее согласовании проверит, что у нее полномочия есть? Кто согласует новую версию справочника тарифов банка - младший аналитик. владелец продукта или руководитель кредитной розницы? Или все, вместе взятые? А утверждает председатель совета директоров?
Если Вы реально занимались разработкой СЭД, то странно Вам объяснять, что документооборот - это не галочки поставить. Это очень часто - юридически обязывающие действия. Там каждую букву надо проверять, и каждую точку. Там огромный объем нормативки, у нас юристы иногда на неделю уходят изучать внутренние документы. У вас контекст не треснет у LLM? Правила, по которым создаются маршруты, они накопительным итогом идут, их выбрасывать нельзя.
Мы недавно одно положение меняли внутреннее. Там на десяток страниц - кто на что имеет право и кто что согласует. А ролей всего пять или шесть. "Секретаря такого-то коллегиального органа утверждает правление по представлению такой-то роли..." и т.д. и т.п. И, да, тут просто "правление" указано, а для создания маршрута нужно полезть в еще пару-тройку нормативных документов и собрать состав правления на нужную дату (!), потому что выдвижение произошло в нее, а кто-то после этого смениться успел, на повышение пошел и т.п., но должен согласовать, сменщик не имеет права, иначе всю процедуру заново проходить.
Все договора идут к Петровой, ага.
P.S. По поводу запросов регулятора. 12000+ номеров карт. По каждому - указать человека, который эту карту выдал физически и при этом идентифицировал клиента, и на основании каких документов он действовал. И что им ответить? "Петрова выдавала карты, потому что в промпте было написано, что она это делает, и все задачи падали на нее"?
Слушайте, а ведь ваш пример - это не опровержение. Это идеальная иллюстрация того, почему агентная архитектура на голову выше классической СЭД. Вы просто пока не перестроились в новую парадигму, где любой дополнительный слой контроля не требует отдельной доработки. Давайте по пунктам:
Раньше: чтобы закрыть требование «показать регулятору основания по 12000 картам», вы нанимали команду внедрения, писали ТЗ на 300 страниц, полгода ждали, пока вам допилят модуль аудита, и молились, чтобы при следующем обновлении он не сломался. Каждый бизнес-процесс обрастал своим уникальным кодом контроля, который старел, гнил и требовал поддержки. Это как строить отдельную сигнализацию на каждую дверь в здании, а потом держать штат электриков, которые чинят каждую по отдельности.
Теперь: вы просто подключаете агента-контролёра. Не пишете код для под-процесса «выдача карт», не пишете код для под-процесса «согласование тарифов», не пишете под-процесс «назначение секретаря правления». Вы клонируете универсального детерминированного агента, который обучен одной простой вещи: перед любым действием проверять полномочия действующего лица, логировать основание (приказ, доверенность, протокол) и записывать результат в неизменяемый журнал. на этом вобщето все.
Хотите покрыть ещё один процесс? Клонируете этого же агента ещё раз. Он не тупит, не просит обед, не уходит на повышение. Он делает ровно то, чему вы его научили: взял действие - нашёл основание - записал в лог. И на каждый процесс не надо писать новую логику, потому что проверка полномочий - это универсальная функция, которая отвязана от конкретного маршрута. Да, они это уже понимают…
Как это работает в вашем примере:
Выдача карты Петровой - агент контроля: «Петрова действует на основании приказа №456 от 12.03.2024, срок действия до 11.03.2025, право подписи до 10 млн. Основание подтверждено. Запись внесена».
Назначение секретаря коллегиального органа - этот же клонированный агент: «Состав правления на дату выдвижения: согласно приказу №789 от…, Иванов исключён с 01.05.2025, Петров включён с 10.05.2025. Процедура соблюдена. Запись внесена».
Регулятор через пять лет запрашивает 12000 карт - вы показываете лог (красивый подшитый журнал, собранный из лога), где по каждой операции стоит ссылка на основание, а не «Петрова выдала, потому что так в промпте написано».
Вы говорите: «Там огромный объём нормативки, юристы неделю изучают». А кто мешает скормить всю эту нормативку агенту в виде базы знаний? Он же не должен сам придумывать правила. Он должен их применять. И применять их он будет не от случая к случаю, как уставший человек, а методично и одинаково на каждом шагу. Это не замена юристу, это экзоскелет для юриста: вместо того чтобы вручную вычитывать каждую операцию, он один раз описывает правило, а 20 клонов агента разносят его по всем процессам разом.
Главный сдвиг парадигмы он здесь:
Классическая СЭД зашивала контроль внутрь бизнес-процесса. Изменился процесс - переписывай контроль. Изменилось основание - переписывай код. Агентная архитектура выносит контроль на отдельный универсальный слой. Вы не допиливаете каждый процесс, вы подключаете к процессу уже готовый, многократно проверенный детерминированный компонент. Хотите ещё один уровень гарантий? Клонируйте второго агента, который будет перепроверять первого. Это стоит копейки и делается за минуты, а не за месяцы.
Так что ваш пример с регулятором и зениткой - ну никак не страшный сон агентного подхода. Это ровно та задача, где он показывает десятикратное преимущество. Потому что когда регулятор приходит с запросом, вы ему показываете не «промпт», а непрерывный аудиторский след, собранный универсальным детерминированным агентом, которого вы клонировали на все процессы за один день. И этот след переживёт любые кадровые перестановки, потому что он не прибит гвоздями к коду, а порождён правилом, которое живёт в базе знаний вместе с нормативами.
В классической СЭД вы бы до сих пор писали ТЗ на доработку модуля аудита. А Петрова, в реальности, таки бы продолжала выдавать карты без оглядки на срок доверенности. Потому что контроль, который требует доработки под каждый процесс, это мёртвый контроль. Контроль, который клонируется одним кликом, это то, о чём я пишу всю статью. И да, это уже происходит, про то и кричу.
Перечисленные Вами СЭД вроде Directum и Docsvision (я бы сюда еще добавил Tessa и ELMA) - не внедряются ради процессов "ЕСЛИ сумма договора > 100.000, то согласует Иванова, ИНАЧЕ Петрова", это слишком дорого. По моему опыту это происходит чтобы:
"было как у всех" - когда СЭД/ЭДО уже в каждом утюге как тот DOOM, а у тебя еще нет или только зачатки,
"навести порядок" - когда мидл-менеджмент продает C-level'у идею наведения порядка/оптимизации/ускорения в
бардакахпроцессах под соусом оптимизации,"документы не терялись" - тут инициатива может быть и от "C".
Причем бизнесу, который может себе позволить внедрение СЭД - не так важны "коробочные" решения (хотя по началу многие интересуются как раз стандартными возможностями), потому что любые коробки ломаются не столько о "роли", которые согласовывают документы в зависимости от атрибутов документа, сколько о разной степени безумности хотелки бизнеса, которые возникают после первых внедрений/успехов. Мои любимые примеры:
Миллион отчетов в разрезе всего что можно - сколько времени документ провел в согласовании/подписании/нормоконтроле/согласовании у юристов/согласовании у контрагента/подписании в ЭДО/сколько времени документ готовился в SAP прежде чем его перенесли в СЭД на подписание.
"А теперь давайте контролировать сколько в среднем документ находится на согласовании у меня и у других отделов, только когда я "спускаю" документ вниз на допсогласование/комментирование - вы это время у меня не учитывайте".
"Мы вот на бумаге работали с 20 отчетами, нам в электронном виде они все очень нужны тоже, и пофиг что они будут стоить миллион, без них вся работа встанет". По факту используется два отчета.
"Нам надо проверять, что в документе используются только правильные шрифты и правильные отступы/интервалы".
"Мы хотим поправить в ворде файл, а вы нам перенесите это обратно в карточку документа".
"Как это нельзя хранить закрытый ключ подписи на сервере? Нам надо, чтобы Иванова могла подписать документ от организации раз в год/квартал, но мы не готовы отдавать ей токен даже под контролем".
По тому, что я вижу сейчас в маркетинге известных СЭД - все использование ИИ сводится к OCR на стероидах, но реально тюнинг "объектов" в СЭД - все еще удел инженеров/разработчиков, ну или продвинутых аналитиков/системных аналитиков, если решение хорошо документировано (к сожалению документация обычно не на первом месте при внедрении) и есть реальный low-код, а не тот, который показывают в коробках на пресейлах.
Для небольших компаний, которые и так не могли себе позволить СЭД, или сидели на ломанных битриксах - агенты вполне могут быть заменой, но для кровавого энтерпрайза - не уверен, что кто-то будет готов взять на себя ответственность за дела, которые может наделать агент в проде.
А вы только что описали идеальный шторм, который как раз и хоронит классическую вендорскую модель. Но сначала давайте разберёмся с одной путаницей, которая сквозит в вашем комментарии.
Вы путаете «действия агента» и агентско ориентированный продуктовый подход
Когда я говорю «все договора свыше 100 тысяч идут к Петровой», это не про то, что один голый LLM-агент сейчас побежит и всё сделает. Это про то, что в агентно ориентированной архитектуре вы описываете правило на естественном языке, а дальше в работу включается не один агент, а целая связка: агент-маршрутизатор, агент-контролёр, агент-логировщик, агент-аудитор. Вы не заменяете СЭД одним чат-ботом. Вы заменяете монолитный код вендора на распределённую сеть специализированных агентов, которых можно клонировать, обучать и контролировать независимо друг от друга.
Разницу чувствуете? «Действие агента» - это когда Claude сгенерировал резолюцию. А «агентский продуктовый подход» - это когда у вас на каждый чих есть отдельный детерминированный агент, обученный не фантазировать, а тупо исполнять правило, логировать каждый шаг и передавать эстафету следующему. Это как сравнивать одиночный выстрел и автоматизированную линию сборки. И именно эта архитектура убивает классические СЭД.
Теперь пройдёмся по вашим «безумным хотелкам», чтобы показать, как это работает.
«Миллион отчётов в разрезе всего»
В классике это доработка на полгода. В агентской модели вы один раз описываете правило для агента-аналитика: «Собери время по этапам из лога агента-контролёра, отфильтруй допсогласование, сгруппируй по отделам». И он генерит отчёт за секунды. Захотелось новый разрез - не надо писать ТЗ, надо просто изменить текстовое описание правила. Штатный архитектор справляется за день.
«А теперь давайте не учитывать время, когда я спускаю документ на допсогласование»
Эта логика в коде классической СЭД превращается в ад из исключений. Агент-контролёр же просто получает правило: «Если статус “допсогласование”, пауза в учёте времени по инициатору X». Одна строка на естественном языке. Никакого кода.
«Проверять, что используются только правильные шрифты и отступы»
Агент-валидатор не устаёт, не моргает и за секунду прогоняет документ через правило «шрифт Times New Roman 14, отступ 1.25». Это не доработка за миллион, это конфигурация за пять минут.
«Хранить закрытый ключ подписи на сервере»
Это вопрос не к агенту, а к инфраструктуре. Но агент-оркестратор может быть настроен так, что при наступлении события «подписать от организации раз в год» он инициирует вызов к доверенному криптографическому модулю, который физически отделён от остальной логики. И ответственность за безопасность несёт этот модуль, а не LLM.
Кровавый энтерпрайз уже в деле
Вы сомневаетесь, что кто-то в «кровавом энтерпрайзе» доверится агенту. На самом деле процесс уже идет, и преимущества настолько сильно перевешивают риски, что все идет очень быстро. Вот не мои фантазии, а конкретные кейсы, которые можно проверить:
Customers Bank (США, активы около $26 млрд) запустил более 500 внутренних AI-агентов. Экономия составила 28 000 часов, производительность выросла на эквивалент почти 15 полных сотрудников. Коммерческое кредитование планируют сократить с 30-45 дней до примерно 7 дней. https://ncfacanada.org/customers-bank-uses-500-ai-agents-to-rebuild-operations/
Nubank (Бразилия, 120 млн клиентов) внедрил AI-агента для денежных переводов через Pix: время транзакции сократилось до 60%, безопасность обеспечивается встроенными защитными механизмами приложения. https://international.nubank.com.br/en/nubank-leverages-ai-to-scale-pix-operations/
Lloyds Banking Group (Великобритания) запустил платформу Envoy для безопасного построения AI-агентов в масштабе всей организации. Группа уже получила £50 млн ценности от генеративного AI в 2025 году и планирует превысить £100 млн в 2026-м. https://www.lloydsbankinggroup.com/media/press-releases/2026/lloyds-banking-group/lloyds-banking-group-unveils-envoy.html
Tata Steel в партнёрстве с Google Cloud развернул флот из более чем 300 специализированных AI-агентов всего за девять месяцев. Агенты работают по всей глобальной цепочке создания стоимости - от прогнозирования обслуживания активов до сокращения времени отклика клиентам. Внутренняя low-code платформа Zen AI позволяет сотрудникам без навыков data science создавать собственных агентов. https://www.googlecloudpresscorner.com/2026-04-22-Tata-Steel-Partners-with-Google-Cloud-To-Deploy-a-Unified-Agentic-AI-Across-its-Global-Value-Chain/
Simplyhealth (Великобритания, 153-летняя история) с помощью Salesforce Agentforce сократил количество жалоб с 600 до 40, а обработка обращений клиентов ускорилась в разы. https://www.cxtoday.com/contact-center/from-600-complaints-to-40-how-simplyhealth-used-agentforce-to-transform-cx-with-ai/
Ну и про «ответственность»
Вы боитесь, что агент наделает дел. Но кто отвечает сейчас, когда классическая СЭД глючит из-за неправильно зашитого маршрута?
Вендор? Нет, он продал лицензию и поддержку.
Бизнес-заказчик? Нет, он писал ТЗ полгода назад и уже не помнит деталей.
В итоге крайний - несчастный аналитик, который всё настраивал.
В агентской же модели центр ответственности остаётся там же, где и был: на людях, которые проектируют правила. Только теперь эти люди сидят в штате компании, а не в штате вендора. Они пишут правила на естественном языке, они же тестируют агента-контролёра, они же читают логи. И если регулятор спрашивает «почему Петрова подписала документ на 50 млн», они показывают не промпт, а запись: «Агент-контролёр проверил: доверенность №123 от 01.02.2025, срок действия до 01.02.2026, лимит 100 млн. Действие разрешено».
Это не снятие ответственности. Это её формализация и автоматизация. А в классической СЭД всё держалось на том, что Петрова помнит свой лимит и не ошибается. Так что ваши «безумные хотелки» - не аргумент против агентов, а лучший кейс для них.
Почему ваш бизнес на SaaS‑решениях для СЭД уже мёртв