Одной из важнейших целей СМЭВ – это обеспечить условия для соблюдения требований Федерального закона от 27 июля 2010 г. N 210-ФЗ "Об организации предоставления государственных и муниципальных услуг" таким образом, чтобы они были реалистичными – технически и экономически обоснованными.

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

Даже не все ИТ-специалисты знают сегодня что такое EDI. Хотя успехи отечественных высокотехнологичных EDI-компаний весьма весомы.

Полезный опыт

Создавая СМЭВ, мы хотим, прежде всего, создать надежную инфраструктуру для такого взаимодействия, при котором гражданин, обратившись в любое ведомство любым способом (через интернет, МФЦ и т.д.) по своему месту текущего нахождения, сразу же получит надлежащим образом задокументированный ответ или же решение по своему обращению в органы власти. Так выглядят задачи и цели СМЭВ по части выполнения требований 210-ФЗ, если взглянуть на них глазами EDI-эксперта.

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

Принцип единого окна

С точки зрения граждан, не важно, сколько промежуточных межведомственных запросов будет сформировано и обработано при их обращении в ОГВ по тому или иному поводу. Главное, чтобы все это было удобно организовано и для оказания большинства наиболее популярных у населения госуслуг не требовалось бы большего, чем предъявление своего паспорта (или УЭК).

Часто задачу автоматизированного обмена и обработки данных отождествляют с задачей электронного обмена документами. И то и другое сокращенно в русском языке часто именуется сокращенно как СЭД (Система электронного документооборота).

В то же время, практики все чаще подразделяют ECM (Enterprise Content Management) и EDI (Electronic Data Interchange) как отдельные, вполне самостоятельные решения. Грань, отделяющая одно от другого, проходит, очевидно, в степени структурированности информации, ее фактического соответствия форматам и общепринятым стандартам.

Быстро передать - не значит быстро обработать

Если мы хотим просто ускорить только передачу документа, то нам вполне достаточно электронной почты. Это будет гораздо быстрее и дешевле отправки документа “с синей печатью” через курьера.

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

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

Для использования электронной почты никакие операторы, кроме технологического - почтового провайдера, не нужны. Достаточно знать адрес получателя. При этом можно использовать ЭЦП и шифрование данных.

Логика работы СМЭВ примерно та же. Вместо почтовых сообщений – там сервисы. Сеть обмена защищена дополнительно. У нее есть провайдер технологического уровня. Сервисы могут быть интегрированы (или не интегрированы) с ведомственными ИС. И т.д.

Так нужен ли сети оператор?

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

Сегодня в России свыше 100 торговых сетей и около 20 тыс поставщиков при закупке и поставке товара используют EDI. EDI–оператор ведет справочники товаров, магазинов, складов или распределительных центров. Он решает задачи подключения поставщиков, приема-передачи заказов, уведомлений об отгрузке, накладных, счетов-фактур, актов приемки товаров, хранения всех перечисленных документов и т.д. Сегодня оператор обрабатывает до 500 тыс документов в день (с среднем). И эта цифра постоянно увеличивается.

Передача и хранение документов в EDI-формате производятся по защищенным каналам связи. При этом возможно применение ЭЦП. Этот результат был получен за 6 лет развития EDI-рынка в России.

В самом начале применения EDI очень остро стоял вопрос доверия данных о поставках EDI-оператору. Ведь через его руки проходит важная коммерческая информация. Приходилось часто доказывать, что EDI-оператор технически более подготовлен к обеспечению сохранности данных, нежели сами клиенты. На доверии к EDI-оператору основан весь его бизнес, поэтому он сам кровно заинтересован в сохранении своей деловой репутации и конфиденциальности данных клиентов. С течением времени (за 6 лет) этот вопрос исчез сам собой. Клиенты его задавать перестали. Если заказчик хочет сделать часть передаваемой коммерческой информации сделать физически недоступной для оператора, то есть надежные способы это сделать.

Стены и крыша

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

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

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

Вернемся к аналогии со строительством дома. Вообще говоря, даже стены пока строить тоже рано. И это скажет вам любой, кто знает, как строят сети уровня EDI. Ведь нет фундамента - отсутствует описание и стандартизация информационных объектов, которыми предполагается обмениваться. Даже в части обязательных атрибутов. А про цели обмена (просто получить данные или данные для автоматизированной обработки и принятия конкретного решения) пока и речи не идет. Поэтому имеет смысл подробнее остановится на этих вопросах.

Сервисы появляются в самом конце

C точки зрения EDI-оператора такого рода обмен, как мы наблюдаем сегодня в рамках СМЭВ, крайне неэффективен. Сформулируем несколько общеизвестных правил построения системы электронного обмена данными (EDI), применив их к СМЭВ.

Во-первых, нужно определить номенклатуру информационных объектов, свойственных для каждого региона. Сразу же заметим, что информационный объект – это, вообще говоря, не бумажный или электронный документ. Это реально существующий материальный, физический объект, который можно параметризовать. Сфотографировать, измерить в чем-нибудь и т.д. С точки зрения информационного обмена важнейший информационный объект - это сам человек, гражданин. Он может вновь родится в регионе или приехать туда временно или постоянно. У него есть движимое и недвижимое имущество: автомобиль или участок земли, недвижимость и т.д. И это тоже объекты, у которых есть свои свойства (атрибуты).

Состояние и перемещение нематериальных объектов (знаний, интеллектуальной собственности) пока рассматривать не будем.

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

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

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

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

В-третьих, понятно, что нужен протокол (SOAP и т.д.), форматы информационного обмена (например, xml ) и спецификации каждого информационного объекта и/или спецификации его состояния, особенно если у объекта есть продолжительный жизненный цикл. Как правило, конкретное состояние информационного объекта в какой-то его части и описывается тем, что мы привыкли называть документом, требующимся для осуществления межведа. Документ - это некий срез информационного объекта в пространстве и во времени, или, как говорят EDI-операторы, проекция информационного объекта.

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

Таким образом, прежде чем рапортовать заказчику об успешном запуске тех или иных сервисов, любой EDI-провайдер привык проделывать достаточно большой объем работ. И, честно говоря, плохо представляет то, что это может быть организовано как-то иначе, в “рабоче-полуспонтанном” режиме.

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

Без руля и ветрил

Можно пытаться решать все эти вопросы "по ходу", в процессе построения СМЭВ. Это будет так называемая "лоскутная модель". Допустим, два крупных федеральных ведомства как-то построят обмен между собой. И потом будут пытаться "натянуть", - как выражаются EDI-профессионалы, - на все это остальных пользователей. Но нет никаких гарантий, что остальным это подойдет по набору информационных объектов и по атрибутивному составу признаков, описывающих эти объекты, а также по самим регламентам обмена.

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

Иначе придется фактически интегрироваться по модели "каждый с каждым", хотя и не всем это будет столь же очевидно, как и EDI-специалистам. Но будем оптимистами. Не важно, что это недостаточно эффективно, но зато создается фронт работ и условия для роста ИТ-компаний в РФ.

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

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

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

Оператор все-таки нужен

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

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

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

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

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

Вопрос безопасности данных

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

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

Полное наименование и адрес места доставки может быть заменен кодом GLN. А ведение справочника GLN - ответственность отдельной организации GS1. Говоря иными словами, передавать можно не сами значения полей, а их индексы. В этом случае обмен данными становится безопасным. А связывание индексов с государственной базой НСИ может производиться непосредственно в ИС государственного ведомства, без участия оператора данных. Этот относительно несложный процесс вполне может быть осуществлен, например, на уровне зашифрованного канала связи и технологического провайдера этого канала.

Таким образом, при разделении функций ведения НСИ (государственный оператор) и передачи обезличенных (персональных и пр.) данных обмена (EDI-оператор), использование услуг коммерческих EDI-операторов в целом ряде случаев становится вполне допустимым даже при отсутствии ЭЦП, шифрования и пр. Более того, это во многом снижает потребность в усиленной защите каналов передачи данных.

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

Как найти друг друга

Еще один важный вопрос – маршрутизация электронных запросов и документов. В EDI-сетях он решается посредством построения статичных взаимосвязей для каждой пары участников обмена на уровне ядра EDI-платформы. Это возможно там, где заранее четко известен получатель документа. В случае РСМЭВ ситуация усложняется, так как первоначально точно не известно, где находится запрашиваемая информация, как запросу и хранящимся где-то данным найти друг друга.

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

Таким образом построение СМЭВ – это очень сложный интеграционный проект, очевидно требующий системного подхода. Его главная цель - обеспечить построение и развитие инфраструктуры для автоматизированного информационного взаимодействия всех органов нашего государства. Как в интереса граждан, так и в интересах самого государства. По сути сегодня такие технологии и определяют устойчивость государства как системы динамического управления. И без глубокой теоретической проработки и привлечения лучших отечественных и зарубежных практик успешное решить эту задачу до конца будет довольно сложно. Для этого отечественные ИТ-компании и ОГВ должны, наконец, найти друг друга и понять, что они делают одно совместное и достаточно важное для страны дело.