Электронный документооборот и DMS для компаний

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

Когда электронной почты, папок и таблиц уже недостаточно?

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

Стоит проверить документооборот, если:

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

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

Один документ от поступления до завершения

Полезный процесс описывает весь путь документа. Для одного типа документа мы определяем:

1. Источник. Документ может поступить по электронной почте, через форму, клиентский портал, сканер или API либо быть создан сотрудником.
2. Регистрацию и описание. Мы задаем идентификатор, тип документа, важные данные и способ выявления недостающей информации.
3. Проверку комплектности. Система может контролировать обязательные поля и вложения. Решения, требующие оценки, остаются за ответственным человеком.
4. Назначение ответственного. Документ получает роль или сотрудник, который выполняет следующий шаг.
5. Решение. Пользователь может согласовать, отклонить, вернуть на исправление или передать дальше в соответствии с установленным процессом.
6. Передачу результата. Данные или решение могут поступить в CRM, ERP, бухгалтерскую программу, B2B-портал или другую согласованную систему.
7. Статус и историю. Пользователь с необходимыми правами видит текущий этап, выполненное действие и информацию для продолжения работы.

Система может контролировать последовательность, обязательные данные, сроки и передачу информации. Она не должна самостоятельно принимать деловое решение, если компания не установила четкое правило и ответственность.

Хранилище, готовая DMS, интеграция или собственный модуль?

Решение должно соответствовать реальной проблеме. Самый дорогой или самый большой вариант не всегда лучший.

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

Что мы определяем до начала работ?

Типы и источники документов

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

Роли и права доступа

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

Статусы, решения и исключения

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

Версии и история

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

Исходные и целевые системы

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

Хранение, экспорт и резервные копии

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

Начните с одного процесса

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

Первый этап может включать:

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

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

Как мы проверяем первый этап?

Критерии приемки зависят от процесса, а не только от внешнего вида экранов. Например, можно проверить, что:

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

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

Интеграция с используемыми программами

Электронный документооборот может работать с CRM, ERP, бухгалтерией, B2B-порталом, складской системой или другим приложением. Мы подтверждаем интеграцию только после проверки документации, прав доступа, форматов данных и условий поставщика.

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

Смотрите также интеграции систем и API и CRM- и ERP-системы на заказ.

Опыт: HUB.ITM.PL

Примерно в 2018 году мы создали систему для крупной бухгалтерской компании, которая получала данные из нескольких программ и форматов. Решение обрабатывало связанные со счетами данные из Comarch ERP Optima, Sage Symfonia ERP, JPK-FA и источников UBER, а также файлы XML, XLS и CSV.

Система считывала, сопоставляла и проверяла данные, а затем готовила EDI++ для импорта в Subiekt GT и Subiekt nexo. Она сократила ручной ввод данных из тысяч счетов и позволила компании принимать новых клиентов без пропорционального роста ручной работы.

Это исторический проект, который больше не используется, поскольку форматы и способы обмена данными изменились. HUB.ITM.PL не был полноценной DMS. Это был слой импорта и преобразования данных из документов, поэтому мы не представляем его как подтверждение версионирования, согласований, сроков хранения или хранения документов.

Прочитайте полное описание проекта HUB.ITM.PL.

Безопасность, история и правовые требования

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

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

Техническое решение не гарантирует автоматически соответствие GDPR, KSeF, правилам бухгалтерского учета или отраслевым требованиям. Эти требования нужно определить, проверить и закрепить за ответственными лицами до согласования объема.

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

Как мы начинаем сотрудничество?

1. Кратко уточняем потребность. Определяем, какой документ создает проблему, откуда он поступает и что должно произойти дальше. Короткий разговор не заменяет анализ сложного процесса.
2. Описываем один процесс. Собираем роли, решения, данные, исключения, текущие программы и ожидаемый результат.
3. Выбираем направление. Проверяем, достаточно ли хранилища, готовой DMS, интеграции, небольшого модуля или решения, адаптированного к процессу.
4. Определяем первый этап. Согласовываем объем, критерии приемки, риски, срок и индивидуальную цену.
5. Создаем и тестируем весь поток. Проверяем обычный случай, отсутствие данных, исправление, отклонение, повтор и ошибку соединения.
6. Планируем следующие процессы. Дополнительные типы документов, роли и интеграции реализуются как отдельно согласованные этапы.

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

Часто задаваемые вопросы

Нужна ли нам полноценная DMS?

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

С какого документа лучше начать?

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

Можно ли связать процесс с нашей CRM, ERP или бухгалтерией?

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

Может ли система поддерживать согласование, исправление и отклонение?

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

Можно ли сохранить историю решений и доступ по ролям?

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

Включает ли проект OCR, электронную подпись или KSeF?

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

Нужно ли менять существующие системы?

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

Как подготовить пример документа?

Удалите персональные данные, номера счетов, конфиденциальные суммы, подписи, данные клиентов и коммерческие тайны. Можно также отправить только описание полей, источника и решений, которые требуется принять.

От чего зависят стоимость и срок?

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

Что отправить вначале?

В первом сообщении опишите:

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

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

CTA: Обсудить первый маршрут документа

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

Смотрите также интеграции систем и API, CRM- и ERP-системы на заказ, B2B-порталы и системы заказов и бизнес-анализ с определением объема MVP приложения.