ECM/СЭД для организаций: вопросы по интеграции и архиву

Сначала проясните задачу, а не названия систем

Выбор ECM/СЭД часто начинают с названий: Directum, Docsvision, 1С:Документооборот. Но если не договориться о целях, легко купить систему, которая отлично выглядит на демо, а в реальной работе не снимает ежедневные проблемы.

Опишите текущую ситуацию без общих слов. Где живет документ до подписи: в почте, мессенджере, папках на сетевом диске, Excel-реестре? Что именно съедает время: поиск, сбор согласований, контроль сроков, подготовка отчетов, передача в архив?

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

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

• Какой риск недопустим: утечка, подмена, потеря версии, срыв срока?
• Кто отвечает за документ на каждом шаге и где ответственность «размывается»?
• Какие сроки критичны и как система должна о них напоминать?
• Что руководитель должен видеть в один клик: статусы, просрочки, загрузку?
• Как измерим успех через 3-6 месяцев: время поиска, доля согласований без почты, число просрочек?

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

Пользователи, роли и сценарии: что должно работать каждый день

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

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

Быстро проясняют картину такие вопросы:

• Кто создает документы, а кто только читает и комментирует?
• Сколько согласующих в типовом процессе и кто замещает отсутствующих?
• Нужны ли внешние участники (подрядчики, партнеры, граждане) и что им можно показывать?
• Через что люди будут работать: веб, мобильный доступ, рабочие места в офисе?
• Нужны ли два языка в интерфейсе и карточках документов (например, русский и казахский)?

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

Отдельно назначьте администратора (ИТ, делопроизводство или выделенный сотрудник). От этого зависят скорость изменений и контроль за доступами.

Маршруты согласования: какие вопросы задать до настройки

Маршруты часто становятся причиной конфликтов уже после запуска: кажется, что система «не так работает», хотя правила просто не были проговорены. Заранее опишите 3-5 самых частых процессов и договоритесь, какие шаги в них обязательны.

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

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

Перед настройкой ответьте на вопросы:

• Какие 3-5 маршрутов запускаем первыми, и что считаем успешным результатом (срок, качество, отсутствие возвратов)?
• Какие условия влияют на путь: сумма, контрагент, филиал, тип документа, наличие приложения?
• Где нужна параллельность, а где строгая очередь (например, финансы после юриста)?
• Как задаются сроки: дедлайны по шагам, напоминания, эскалации руководителю при просрочке?
• Как выглядит история согласований: кто и когда согласовал, какие комментарии оставил, кто имеет право это видеть?

Пример: договор на 2 млн проходит юриста, финдиректора и директора филиала, а на 200 тыс - только юриста и руководителя отдела. Если правило не зафиксировать, сотрудники начнут просить согласовать «вручную» в мессенджере, и смысл СЭД теряется.

Отдельно уточните, что считается финальной версией: можно ли менять файл после согласования, как фиксируются правки и кто может вернуть документ на доработку.

Интеграции: как избежать ручного ввода и разрыва данных

Если СЭД живет отдельно от ERP, бухгалтерии и почты, сотрудники быстро начинают копировать данные руками. Итог предсказуем: разные суммы в разных местах, потерянные вложения, версии договора расходятся по папкам.

Сначала перечислите системы, с которыми нужна интеграция. Чаще всего это ERP и бухгалтерия (счета, договоры, контрагенты), HR (штат, оргструктура), CRM (клиенты и сделки), корпоративная почта и календарь.

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

Зафиксируйте «источник истины». По справочникам обычно один владелец: контрагенты в ERP, сотрудники в HR, оргструктура в AD или HR. По документам тоже: где хранится оригинал файла, а где только метаданные.

Попросите подрядчика заранее ответить:

• Какие события запускают обмен: создание карточки, смена статуса, подписание, закрытие?
• Что происходит при ошибке: повторная отправка, очередь, уведомление, журнал, сроки реакции?
• Кто разбирает сбои: ИТ, владелец процесса, подрядчик, как это фиксируется?
• Какие ограничения по сети и безопасности важны: сегменты, VPN, сервисные учетные записи, права?
• Как контролируется качество данных: дубликаты, обязательные поля, правила сопоставления?

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

Архив и хранение: вопросы про сроки, поиск и восстановление

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

Что спросить про сроки и неизменность

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

Проверьте:

• Сроки хранения по видам документов и что происходит после их окончания: удаление, продление, передача в долгосрочное хранение.
• Нужны ли неизменяемые копии (WORM-логика), запрет редактирования, правила контроля версий.
• Как фиксируются действия: кто изменил карточку, кто скачивал файл, кто согласовал.
• Как устроена выгрузка для проверок: пакет документов, реестр, история.

Метаданные, поиск и восстановление

Разберите метаданные: номенклатура дел, индексы, теги, связи между документами (договор, допсоглашения, счета). Поля должны заполняться не «вручную из головы», а по справочникам и правилам.

Проверьте поиск: по реквизитам, по полному тексту, по вложениям, по участникам и по истории изменений.

Отдельно обсудите резервные копии и восстановление: RPO/RTO, тесты восстановления, где хранятся копии, что будет при удалении документа или сбое базы. Для больницы или госоргана в Казахстане часто критично восстановить архив за часы, а не за дни, и доказать, что документ не менялся после подписания.

Права доступа и аудит: что должно быть проверяемо

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

Уточните гранулярность доступа. Иногда нужно скрывать не весь документ, а отдельные части: вложения (например, сканы паспортов), поля карточки (сумма, персональные данные), вкладки с историей согласования. Если система так не умеет, придется менять процесс или принимать риск.

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

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

• кто открыл документ и когда
• кто скачал или распечатал
• кто изменил карточку или файл и что именно
• кто согласовал, отклонил или подписал
• кто выдал или снял права

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

Входящие документы и сканы: от бумаги к управляемому процессу

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

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

Сканирование, распознавание и качество

Уточните поддержку устройств (сканер, МФУ), нужен ли потоковый режим и OCR. Ошибки распознавания критичны для поиска и автозаполнения карточки, поэтому заранее задайте требования к качеству: например, 300 dpi, правила для печатей и подписей.

Согласуйте форматы: PDF/PDF-A для архива, TIFF для сканов, JPEG/PNG для вложений, офисные файлы (DOCX, XLSX). Отдельно выясните, что происходит при конвертации и сжатии.

Связь оригинала и электронной копии

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

Пять вопросов, которые быстро выявляют пробелы:

• Как система связывает скан и бумажный оригинал, кто отвечает за маркировку (штрихкод/наклейка)?
• Можно ли распознать контрагента, номер договора, ИИН/БИН из скана и заполнить карточку?
• Что считается «входящим» и какие маршруты для разных типов: письмо, обращение гражданина, акт, счет?
• Как контролируются сроки ответа и смена исполнителя, если человек в отпуске?
• Можно ли быстро собрать полный пакет по делу: письмо, резолюция, вложения, ответ и версии ответа?

Инфраструктура и производительность: что спросить у ИТ и подрядчика

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

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

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

• Поиск по реквизитам и тексту - сколько секунд при базе в N документов.
• Открытие карточки и просмотр вложений (PDF, сканы, большие файлы).
• Пиковая нагрузка - сколько одновременных пользователей и какие операции в «час X».
• Где хранятся база и файлы - одно хранилище или разделение (активные документы и архив).
• Как индексация, кэш и права доступа влияют на поиск.

Обсудите эксплуатацию: кто обновляет систему, как проверяют совместимость, как устроен мониторинг и куда идти при сбоях.

Не забудьте про рабочие места и сеть: какие ПК/моноблоки нужны по ролям, какие сканеры требуются, что с каналами между офисами, как политики безопасности (антивирус, запрет USB, прокси) влияют на клиент.

Если инфраструктуру планируете обновлять, заранее оцените, какие серверы и рабочие станции потребуются. Это помогает не упереться в «железо» уже после пилота.

Пошаговый план внедрения: от требований до запуска

Начните не с выбора «Directum или 1С», а с инвентаризации реальности: какие документы ходят по организации, где они рождаются, кто согласует, где возникают задержки, что должно оказаться в архиве.

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

Рабочая схема обычно выглядит так:

• Описать 3-5 ключевых процессов и документы в них, назначить владельцев.
• Согласовать справочники и обязательные реквизиты, определить источник истины.
• Составить список интеграций (почта, ERP, бухгалтерия, кадровые системы, ЭДО) и назначить ответственных.
• Сделать прототип 1-2 процессов и прогнать на реальных кейсах.
• Провести пилот на одной группе, обучить пользователей и запустить поэтапно, с календарем и метриками.

Хороший признак зрелого проекта - заранее определенные критерии успеха пилота. Например: «договор проходит согласование за 3 дня вместо 10», «нет ручного ввода контрагента», «документ в архиве находится за минуту».

Частые ошибки при выборе Directum, Docsvision, 1С и аналогов

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

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

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

Еще одна боль - справочники. Если не назначить владельцев (кто отвечает за контрагентов, подразделения, договоры, номенклатуру), быстро появляются дубли: «ТОО Ромашка», «Ромашка ТОО», «Romashka LLP». Потом интеграции ошибаются, а отчеты расходятся.

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

Короткий чеклист перед договором и запуском

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

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

Дальше проверьте интеграции: откуда берутся справочники и реквизиты (контрагенты, подразделения, договоры, счета), кто отвечает за качество данных и что считается «истиной», если значения расходятся.

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

В приложениях к договору полезно закрепить:

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

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

Пример сценария: согласование договора без потери версий

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

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

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

На пилоте проверяйте не «красоту интерфейса», а практику:

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

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

Следующие шаги: как провести оценку и подготовиться к внедрению

Чтобы разговор с подрядчиком был предметным, возьмите 15-20 вопросов из этой памятки и проведите встречу в формате воркшопа: ИТ, делопроизводство, юристы, безопасность и 1-2 руководителя, которые регулярно согласуют документы.

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

Чтобы оценка не превратилась в бесконечные обсуждения, заранее зафиксируйте границы работ:

• какие интеграции входят в проект (почта, AD, 1С/ERP, ЭЦП, сканирование)
• что делаем с архивом и хранением (сроки, форматы, восстановление)
• будет ли миграция старых папок/сетевых дисков и какие правила качества
• как выглядит обучение и поддержка после запуска
• какие метрики считаем успехом пилота (время согласования, доля ручного ввода)

Отдельно проверьте инфраструктуру: хватит ли текущих серверов, дисков и резервного копирования, и как проект выдержит рост пользователей и объема вложений через 1-2 года.

Если нужен единый подрядчик, который возьмет на себя системную интеграцию и подбор инфраструктуры под нагрузку (серверы, рабочие места, поддержка), этот контур обычно закрывают интеграторы уровня GSE.kz (gse.kz), особенно когда важны требования по безопасности и прозрачности цепочки поставок.