ECM/СЭД *

На реальном кейсе ИТ-компании разберем, когда доработка СЭД оправдана, что важно учесть заранее и почему со временем от кастома можно отказаться.

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

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

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

Рынок программного обеспечения в 2026 году заметно отличается от того, каким он был еще 4 года назад. Импортозамещение ускорило развитие технологического рынка, сегодня компаниям есть, из чего выбрать.

Как не ошибиться? Что спросить на первой встрече?

— В этом проекте нам надо хорошо распознавать документы.

— А что значит «хорошо»?

— Сейчас же везде ИИ. Я загружаю документ в чат, и он мне всё правильно отвечает. Нам надо так же для всех документов.

Такие диалоги я всё чаще слышу при обсуждении новых проектов.

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

Я много лет занимаюсь промышленными системами обработки и распознавания документов. Когда система «смогла» на одном документе, я стараюсь не очароваться этим и не смотреть как на магию. Я стараюсь думать, как это сделать потоком.

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

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

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

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

«Почему для компании «Ромашка» ваша СЭД стоит 5 рублей, а для нашей ООО «Василек» –15 ₽?». В статье рассказали, как цена системы и скорость запуска зависит от того, кто ее будет внедрять.

Вы когда-нибудь подписывали положение о неразглашении коммерческой тайны или положение об информационной безопасности? Наверняка ответ будет положительный. Всё это верхняя часть айсберга, который называется «Регламентирующие документы» (РД). К видам таких документов относятся положения, кодексы, должностные инструкции, приказы по компании, штатное расписание.

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

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

Привет, Хабр! Это Илья Петухов, руководитель проектов развития ИИ-решений в Directum. Сегодня я продолжаю серию статей про ИИ-агентов:

В первой части статьи мы разобрались, чем отличаются ИИ-агенты от чат-ботов и ассистентов.

Во второй остановились подробнее на преимуществах workflow-агентов.

Думаю, настало время поговорить о самом щекотливом вопросе — замене сотрудников ИИ-агентами.

Мессенджер — один из самых удобных инструментов на старте бизнеса. В нем легко создать рабочий чат, быстро обсудить задачу, отправить файл, согласовать правки и связаться с клиентом. Но по мере роста компании переписка начинает заменять собой CRM, таск-трекер, базу знаний, сервис-деск и даже архив документов. А иногда доходит до того, что в чатах согласуют договоры и другие важные бумаги. Оптимальной альтернативой может стать суперапп.

Год назад компания приобрела СЭД Directum Lite и планировала внедрить ПО самостоятельно. Мы ожидали стандартный проект на пару месяцев. Но спустя год система так и не была запущена. Разбираем ситуацию и рассказываем о рисках, которые могут возникнуть у любой организации.

Клиент попросил API для подключения OpenClaw и запуска своих ИИ-агентов. Прежде чем делать своё, разобрались вместе: сколько реально стоит поднять агента с нуля (компетенции, доступы, железо) и что модели знают о Directum RX «из коробки».

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

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

Именно это третье состояние и создаёт самый неприятный класс проблем. И именно о нём — эта статья.

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

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

А зачем? Чтобы бухгалтер Петровна перестала бегать по этажам с бумажкой и начала кликать мышкой в интерфейсе одной из модных тогда российских СЭД. Мы искренне верили, что несём цифровую революцию.

Сейчас мне смешно. И страшно. Потому что весь этот рынок, оценённый CNews и аналитиками в 95–110 миллиардов рублей, идёт ко дну. И нет, его не убьют конкуренты. Его убьёт тишина. Та самая, с которой ИИ‑агенты за пару дней соберут то, на что вы тратили месяцы и миллионы.

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

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

В новой версии платформы Инкоманд появился No Code инструмент «Инкоманд Объекты», позволяющий создавать структуры данных и управлять ими без написания кода — Object Definition’ы, поля, связи, представления, права доступа настраиваются через UI. Но данные не всегда рождаются и живут в самой системе. На практике объекты часто находятся в смежных системах, и задача разработчика — не дублировать их, а организовать бесшовный доступ.

В этой статье я расскажу, как мы реализовали такое решение с помощью механизма Proxy Object Storage, и с какими проблемами пришлось столкнуться на пути интеграции Инкоманд с Microsoft Graph API.

Привет, Хабр! Это Илья Петухов, руководитель проектов развития ИИ-решений в Directum.

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

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

Так ли это?

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