Опыт использования стандартов взаимодействия СЭД (ГОСТ Р 53898 и/или МЭДО)

Андрей Колесов, в своем блоге привлек внимание к дискуссии, развернувшейся на ECM-Фейсбук-группе на тему стандартов обмена документами в СЭД. Как руководитель проекта по внедрению СЭД в Правительстве Ярославской области попробую ответить на вопросы, заданные в ходе дискуссии.

На определенном этапе внедрения СЭД в Правительства Ярославской области (история проекта, pdf) уже недостаточно стало реализации межведомственного документооборота внутри органов исполнительной власти области. Необходимо было обеспечить взаимодействие и обмен электронными документами в масштабе всей области и в первую очередь с ОМСУ и ТОФОИВ. Самый простой (и организационно, и технически) способ — обеспечить подключение к ЕСЭД ОГВ ЯО (Единая система электронного документооборота органов исполнительной власти Ярославской области) по одному рабочему месту с ограниченным функционалом (только прием и отправка документов) всех корреспондентов, с которыми планируется обмен ну и закрепить легитимность данного механизма (путем двухсторонних соглашений и выпуском соответствующих НПА). Что и было сделано уже в середине 2011 года.

При этом «особняком» встал вопрос с мэрией Ярославля. И основное затруднение даже не в том, что такой подход потребовал бы ручного переноса документов и реквизитов из одной СЭД в другую (Правительство на DIRECTUM, мэрия на Docs Vision). Мэрию областного центра и крупнейшего города области было весьма неудобно трактовать как «одного» корреспондента, т. к. различные структурные подразделения мэрии (управления, департаменты, территориальные администрации) выступали самостоятельными корреспондентами и вели активную переписку/взаимодействие с различными органами власти области и ТОФОИВ. Поэтому было принято решение обеспечить взаимодействие двух систем в рамках организации обмена служебной корреспонденцией, поручениями.

Интеграция разных СЭД на базе ГОСТ Р 53898

За основу такого взаимодействия и был взят утвержденный в 2010 году стандарт ГОСТ Р 53898 «Системы электронного документооборота. Взаимодействие систем управления документами. Требования к электронному сообщению». Обе технологические платформы имеют развитые средства, позволяющие реализовать взаимодействие систем согласно указанного стандарта. И, собственно, такая интеграция была проведена. Стоит отметить, что реализация такого взаимодействия не потребовала внесения никаких изменений в логику работы обоих СЭД. И та и другая система являются полностью самостоятельными, самодостаточными и автономными. Ни одна из систем по отношению к другой не является «подчиненной».

Единая система электронного документооборота (ЕСЭД) Единственное исключение — на базе ЕСЭД (DIRECTUM) как системы, обеспечивающей «межвед» с большим количеством абонентов, организован реестр абонентов и при появлении в структуре мэрии нового подразделения, которое может выступать абонентом системы, об этом необходимо уведомить СТП ЕСЭД (службу технической поддержки).

Эта интеграция начала функционировать в начале 2012 года и за прошедшие время доказала свою работоспособность, результативность и эффективность.

Конечно, данный механизм не соответствует ГОСТу на 100%. При проработке решения с обеих сторон (а данное решение реализовывалось совместной работой нас, как партнера DIRECTUM, и компании Проф-Консалтинг, как партнера DocsVision) требования ГОСТ были взяты нами за основу, технологически адаптированы с учетом детализации требований Заказчика и функциональных особенностей обоих систем. Но наличие ГОСТа позволило нам не «изобретать велосипед», а с учетом конкретной специфики проекта основываясь на нем в кратчайшие сроки выполнить задачу, поставленную Заказчиками (Мэрией города и Правительством области).

При этом у меня нет данных обо всех внедрения СЭД в России, но участвуя во многих конференциях по ECM/СЭД тематике у меня сложилось впечатление, что это чуть ли не единственный проект такого рода.

Почему СЭД не имеют функционал для обмена по ГОСТу

На первый взгляд действительно резонный вопрос — почему «тиражные» СЭД, по крайней мере тройка-пятерка лидеров рынка, по умолчанию не включают в себя функционал для обмена в строгом соответствии указанному ГОСТу и почему для реализации такого взаимодействия внедренцам пришлось что-то дополнительно «реализовывать»?

Тут я (не являясь представителем вендороа) могу только гадать. Но думаю, основные причины в следующем:

1.Слабая востребованность рынком данного решения. Ведь обмен документами и метаданными между системами это лишь вершина айсберга межведомственного/межкорпоративного электронного документооборота. Далеко не все и не ото всех готовы принимать электронные документы, как равнозначную замену «бумаге». До недавнего времени (да и сейчас) эта ситуация возникала только в холдингах (и других аффилированных структурах), областных органах исполнительной власти и тесно взаимодействующих между собой компаниях. Ведь правовой фундамент такого обмена — заключение взаимных соглашений о признании документов или выпуск ЛНА вышестоящей организацией значительно ограничивал возможную сферу применения таких решений.

2.Банальная конкуренция. Любой вендор при внедрении СЭД в «голове» холдинга заинтересован не объединять различные СЭД, а «вытеснить» конкурентные СЭД из филиалов. И ИТ-служба Заказчика всегда это поддержит, т. к. унификация используемых на уровне холдинга решений несет колоссальную экономию на содержании, обслуживании и дальнейшем развитии СЭД уровня холдинга. Кстати, такую же ситуацию мы наблюдаем и на рынке сервисов, обеспечивающих межкорпоративный ЭДО: Диадок, Synerdocs, Тензор. Проекты по роумингу систем единичны и перспектив этому не видно. И если один контрагент подключен к Диадок, а другой к Synerdocs — то обмениваться электронными документами между собой они не могут. И я уверен — если бы разработчики этих сервисов были бы заинтересованы в роуминге — все технические сложности тут же были бы преодолены. Однако сейчас компании предпочитают завоевывать рынок увеличивая число «своих» абонентов и добросовестно аргументируют «ненужность» и даже «вредность» роуминга. В результате те же вендоры-внедренцы СЭД для полноценной организации межкорпоративного документооборота у своих Заказчиков вместо того, чтобы обеспечить взаимодействие СЭД с одним из операторов вынуждены разрабатывать такие «коннекторы» к большинству операторов ЭДО. Ведь как была бы логична схема: Любая СЭД — любой (но один) из операторов, к которому СЭД подключена — роуминг между операторами и вот уже имея любую СЭД и подключившись к любому из операторов ЭДО обмениваешься юридически-значимыми электронными документами со всеми, кто подключен к любому из операторов. Ан нет! У того же DIRECTUM уже есть коннекторы к Диадоку, Synerdocs, думаю скоро появится еще к нескольким… И каждый Заказчик вынужден подключаться как минимум к двум, а то и больше операторам ЭДО и платить за эти техрешения (благо коннектор к Synerdocs у DIRECTUM бесплатный).

3.Отсутствие поддержки данного ГОСТа (как требование или рекомендация) каким-либо регулятором. Тут показателен опыт эксплуатации МЭДО. Едва вышел ГОСТ, как появилась МЭДО (затрудняюсь ответить, что было раньше). Задачи — идентичные. Формат МЭДО очень похож на ГОСТ. Но вот именно, что похож. Есть отличия. Поэтому система, обеспечивающая обмен в соответствии с ГОСТом все равно потребует доработки для обмена по МЭДО. С другой стороны, МЭДО — объективная реальность, а не «отвлеченный документ», каковым является ГОСТ. Требование обеспечить от своих СЭД возможность взаимодействия с МЭДО (как и со СМЭВ) зафиксировано в документах Правительства РФ. Поэтому реализация выгрузки-загрузки в формате МЭДО уже у большинства вендоров есть. А раз есть, этот механизм уже используется для тех задач, которые скорее был призван решать ГОСТ, а именно «взаимодействие различных СЭД». Классический пример из практики: Рослесхоз использует DocsVision, а его ТОФОИВ (Департамент лесного хозяйства по УрФО) DIRECTUM. Обмен документами и поручениями между системами (чтобы не изобретать интеграции) построен по форматам МЭДО, т. к. обе системы его поддерживают. Но МЭДО поддерживают и двигают в массы Администрация Президента, Правительство РФ, Минкомсвязь. А у ГОСТа такой «крыши» нет. И его перспективы как рабочего документа поэтому туманны.

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

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

Практика реализации обмена документами между СЭД

Еще на первом этапе проектирования взаимодействия ЕСЭД с мэрией и другими ОМСУ нами предусматривался именно механизм взаимодействия независимых систем. Ведь даже когда мы говорим об ОМСУ Ярославской области, которые работают на платформе DIRECTUM, могу сказать, что они не работают «на той же СЭД, что и Правительство». С точки зрения внутренней реализации в их СЭД из ЕСЭД Правительства по определенному формату «выгружаются» документы и поручения и так же они «выгружают» отправляемы документы, письма, отчеты и другую информацию другим получателям (Правительство, Мэрия, другие ОМСУ, ТОФОИВ, подведомственные учреждения). Кстати, на одном из совещаний по организации работы компания, осуществляющая внедрение DocsVision в г. Рыбинск подтвердила готовность обеспечить такое взаимодействие (с учетом того опыта, что был получен при реализации интеграции с мэрией г. Ярославля). Т.е. отсутствие такого взаимодействия уже не вопрос к системам (которые технологически готовы), а к организационной составляющей проекта. Кстати, по неофициальной информации интеграция в г. Рыбинск (т.е. автоматическая загрузка–выгрузка) будет настроена до конца года.

Отдельно замечание по кнопочкам: «Я так понимаю, что если их СЭДы соответствуют ГОСТ Р 53898-2013 или даже ГОСТ Р 53898-2010, то нажав в одном кнопочку „Экспорт в…“, а в другом „Импорт из…“ регистратор ЛЕГКО решит задачу», «Сейчас вопрос вроде закрыт, конвертация выполняется ГДЕ-ТО, но кнопочек „экспорт/импорт“ не появилось.».

Действительно, кнопок для ручной загрузки-выгрузки ни мы в DIRECTUM, ни наши коллеги в DocsVision не делали. Наличие кнопочек — дополнительный риск человеческого фактора. Почему, скажите, делопроизводитель зарегистрировав письмо и указав способ доставки «Автоматически» должен еще и кнопочки нажимать? А если забудет? Зарегистрированный в системе исходящий документ никуда не уйдет? Так это фактически — потеря документа, т. к. исключает документ из документооборота.

Поэтому действительно эти процессы реализованы «где-то», на сервере. И регистрация документа есть достаточное основание для того чтобы система уже автоматически проверила его готовность к отправке и отправила его получателю. А если что-то не в порядке (электронной подписи на зарегистрированном документе нет или еще какие-то проблемы) уже ЯВНО уведомит делопроизводителя о проблеме. И импортировать вручную ничего не надо. При поступлении документа система его сама загрузит, сформирует карточку, зарегистрирует и даже отправит получателю на рассмотрение. Тем самым экономит до 30% рабочего дня делопроизводителя на регистрации входящих документов.

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

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

Оригинал записи: https://www.pcweek.ru/ecm/forum/forum44/topic8051/#bf

Источник: Блоги на PCWeek

* — организация, признанна экстремистской на территории РФ