Рекомендации по внедрению финансового архива и МКДО. Часть 2. Сложности и как их решать

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

Схема работы с финансовыми документами

В первую очередь, при внедрении необходимо выяснить у заказчика, что глобально он хочет от Directum RX: фин. архив, т.е. место, куда будут попадать уже принятые, согласованные, подписанные всеми необходимыми участниками корректно сформированные пакеты документов ИЛИ систему для принятия, обработки (перкомплектования, распределения, согласования и подписания) и хранения этих документов.

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

В зависимости от целей можно выделить несколько верхнеуровневых схем обработки:

• МКДО или БУМАГА -> Информационная система заказчика для обработки и подписания документов (возможно, она же учетная система заказчика) -> Отражение в учетной системе заказчика -> хранение в Directum RX
• МКДО или Бумага -> создание в Directum RX -> передача в информационную систему заказчика для обработки документов (возможно, она же учетная система заказчика) -> отражение в учетной системе заказчика -> подписание в Directum RX –> хранение Directum RX
• МКДО или Бумага -> создание или интеграция в Directum RX -> согласование и подписание в Directum RX -> отражение в учетной системе заказчика -> хранение Directum RX

«Пакетность» финансовых документов

Фин. документы, как правило, «ходят» пакетами и это становится проблемой при внедрении, если схема обработки подразумевает принятие, согласование и подписание документов в Directum RX. Причина в том, что в Directum RX нет такого объекта как «пакет документов». Единственный подходящий инструмент коробки для реализации пакетности – это связи. Но для этого документы одного пакета должны как-то связываться. И тут кроется еще одна загвоздка для внедрения: если мы говорим об обмене через ЭДО, то связать их автоматически со 100% уверенностью в корректности связи автоматически не получится, т.к.:

• Контрагент может направить в одном сообщении 2 (и больше) пакетов;
• Контрагент может направить один пакет 2-мя (и больше) сообщениями, при этом разница между первым и вторым сообщением может быть исчисляться неделями;
• Контрагент может направить пакет из 2 (и более) документов, но один из документов нужно отказать/аннулировать

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

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

• пакет не полный;
• в пакете есть некорректные документы;
• если в одном сообщении более одного пакета.

Со своей стороны направлять контрагентам документы исходя из тех же правил:

• не направлять неполные пакеты;
• аннулировать весь пакет документов, если в нем есть некорректный документ;
• не направлять в одном сообщении больше одного пакета.

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

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

Сложность определения ответственных

Каждый финансовый документ кто-то должен обрабатывать: подтверждать корректность документа и направлять на согласование и подписание.

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

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

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

1. или уже есть правила определения ответственных, которые устраивают заказчика. Тогда рекомендую оставить ее, т.к. если перекраивать эту схему, а итоговой схемы заказчик еще не придумал, то это почти 100% вероятность срыва сроков проекта.
2. или ответственные не определяются, а сотрудники сами ищут свои документы в общем списке. Вы можете реализовать это так же и в Directum RX. И тут есть очевидные проблемы, которые надо решить с заказчиком:

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

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

• Большинство финансовых документов формируется на основании заказа. В заказе есть или «получатель» или, как минимум, автор. Этот получатель (или автор) и является ответственным за документы по этому заказу. Если документ создан не на основании заказа – есть сотрудник или подразделение, цель которых выяснить, кто ответственный за документ, и переадресовать ему задание на обработку.
• Практически каждый финансовый документ формируется на основании договора. В информационной системе согласования договоров в карточку договора добавить коллекцию «отв. за фин. документооборот».  Настроить, чтобы кому-либо из участников процесса создания и согласования договоров (как правило автору) необходимо было ее обязательно заполнить. Разработать отправку финансовых документов сотрудникам из этой таблицы

Миграция документов

Если в рамках проекта Заказчик требует выполнить миграцию документов из сервиса обмена, то тут важно понимать, что миграция документов – это непростая процедура. Если период миграции, например, 5 лет, то часть документов могут быть уже неподдерживаемого формата, часть документов – дубли, часть – не в том статусе, в котором должны быть и т.д. И прежде, чем пытаться тянуть весь этот, прямо говоря, бардак в Directum RX, важно выяснить, зачем это заказчику и как он этим будет пользоваться. Если вы получите ответ «чтобы у нас был полный архив в одном месте», то нужно объяснить заказчику, что архив будет все равно не полный - это будет архив только электронных документов, а в этот период были еще документы, полученные на бумаге. Если заказчик говорит, что:

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

то важно обозначить заказчику, что Диадок хранит ограниченное количество информации о документе. Если Заказчик привык искать документы в своей информационной системе по подразделению, статье затрат, ЦФО и т.д., то после миграции этого не получится сделать. Мы не сможем мигрировать эти данные из Диадока, потому что их там попросту нет. Если мигрированные документы отправлялись из учетной системы, где хранятся все необходимые данные и хранится ИД сообщения в сервисе обмена, то можно эти данные передать в Directum RX. Но это дополнительная интеграция или миграция, которая не заложена в рамки проекта. А если без этих данных мигрированными документами будет невозможно пользоваться – то может и смысла в миграции нет? Или, возможно, стоит вынести миграцию на развитие вместе с синхронизацией данных из учетной системы.

Обратите внимание на ограничения импорта файлов XML

В системе есть готовая функциональность по импорту формализованных документов, НО она имеет ряд существенных ограничений. Полный их перечень есть в справке в разделе Прикладные модули – Финансовый архив – Импорт документов. Среди этого перечня особенно важно помнить следующее ограничение: «для успешного импорта файла, между нашей организацией и контрагентом должен быть установлен электронный обмен». Это важное ограничение, потому что оно не позволяет импортировать документы, полученные от контрагента из других сервисов обмена. Т.е. если заказчик говорит, что он получил документы от контрагента через оператора ЭДО «Калуга Астрал» и ему нужно как-то загрузить их в Directum RX, то нельзя предлагать ему загрузить эти документы с помощью функционала импорта XML-файлов. И тем более не стоит и заикаться о реализации коннектора к новому сервису обмена: это тысячи часов на разработку и поддержку. Вопрос получения документов из других сервисов обмена решается настройкой роуминга между условной «Калугой Астрал» и сервисом обмена заказчика, с которым настроен коннектор к Directum RX.

Выводы

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

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