Наверх

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

Архив
Время чтения: 13 минут
4
Опыт использования стандартов взаимодействия СЭД (ГОСТ Р 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% рабочего дня делопроизводителя на регистрации входящих документов.

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

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

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 4

Сергей Рудин 7 ноября 2014

Дмитрий, если я правильно понимаю, МЭДО имеет свой формат обмена данными, не соответствующий ГОСТу и, как минимум, в одной системе (DIRECTUM) уже была реализована работа через МЭДО. Кроме того, скорее всего и Docs Vision имеет наработки по МЭДО. Почему в таком случае для обмена между системами был выбран формат ГОСТа? Не проще было использовать уже готовый "загрузчик/выгрузчик" в МЭДО, немного допилив его под свой транспорт? Или это использование ГОСТа ради использования ГОСТа?

Тогда можно развить мысль, а почему не формат СМЭВ? Глобально, насколько я понимаю, вся идея в применении "правильного" XSLT преобразования над родным (native) XML, таким образом, по-большому счету, работать можно в любом формате :)

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

Попробую сразу дать ответ на оба вопроса.

Главное: обратите внимание на даты: задача реализовывалась в конце 2011 года (а постановка задачи была в середине 2011г.).

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

Про степень готовности и понятности решений и технологий СМЭВ в тот период не мне Вам говорить. А уж про "широко используемой в гос.системах" формат СМЭВ и сейчас, в конце 2014 года по моему говорить преждевременно.

И, кстати, что СМЭВ, что МЭДО являются, по сути, "корпоративными" стандартами, ориентированными на решение специфической задачи.

Для решения задач документооборота, с учетом предметной области, как раз предусмотрен ГОСТ и МЭДО. СМЭВ изначально ориентированный на гос.услуги и межведомственные запросы не покрывает область "делопроизводства" (в связи с чем у архивистов к нему, кстати, колоссальное количество вопросов).

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

Можно сказать, как аналог МЭДО. С учетом того, что существует канал связи это было наиболее простым и быстрым в реализации решением. 

Чтобы прокомментировать, или зарегистрируйтесь