Главная Контактная информация Карта сайта

Тел./факс: +7 (499) 237-2271
Английская версия
 


Создание системы автоматизированного документооборота и делопроизводства сферы образования России

Больных Андрей Анатольевич,
ведущий инженер РГУИТП

Введение

Целью проекта является разработка и внедрение отраслевой системы автоматизированного документооборота и делопроизводства (САДД) в целях совершенствования документационного обеспечения управления и повышения его эффективности путем унификации состава и форм управленческих документов в электронном виде, технологий работы с ними и обеспечения контроля исполнения документов.

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

Внедрение САДД отрасли образования позволит:

  1. Уменьшить поток бумажных документов на стадии согласования.

  2. Повысить оперативность подготовки документов.

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

  4. Исключить утерю документов и сокращение числа ошибок при обработке больших потоков документов.

  5. Повысить надежность принятия решений за счет полноты представляемой информации.

  6. Ужесточить контроль за исполнением документов и поручений руководства.

  7. Согласовать работу структурных подразделений.

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

Компоненты САДД

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

  1. Корпоративной почтовой системы. Почтовая система базируется на программном обеспечении Lotus Notes/Domino и представляет собой масштабируемую, безопасную и управляемую платформу передачи почтовых сообщений и группового ведения календаря и планирования с возможностью Web-доступа.

  2. Корпоративной системы управления документами. Система управления документами базируется на программном обеспечении Lotus Domino.Doc и обеспечивает универсальную, повсеместно доступную среду для работы и хранения всех типов документов.

  3. Автоматизированной системы подготовки и исполнения документов (АСПИД), обеспечивающий обмен документами в соответствии со стандартами документоведения.

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

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

Работа с Domino.Doc возможна из клиентского места Lotus Notes, из любого браузера (Web-доступ), из Проводника Windows или пакета MS Office. Интеграция с MS Office и Проводником Windows позволяет сотруднику работать с документами непосредственно из этих программ, используя для работы знакомый, понятный интерфейс.

Результаты внедрения САДД

Работы по созданию отраслевой системы автоматизированного документооборота и делопроизводства ведутся с 2001 года. В настоящее время выполнены следующие работы:

  1. На компьютерах сотрудников Министерства образования, подключенных к компьютерной сети Министерства, закончены работы по внедрению почтовой системы Lotus Notes и централизованного хранилища документов Domino.Doc. Все сотрудники прошли обучение по работе с данными компонентами. Установлено 205 рабочих мест Lotus Notes и Domino.Doc.

  2. Проводится опытная эксплуатация программного обеспечения АСПИД. Данное программное обеспечение установлено на 28 рабочих мест. Все сотрудники, использующие АСПИД, прошли обучение.

Автоматизированная система подготовки и исполнения документов (АСПИД)

Автоматизированная система подготовки и исполнения документов, разработанная специалистами РГУИТП, соответствует стандартам делопроизводства для государственных учреждений РФ и предназначена для использования во всех структурных подразделениях Министерства. Система представляет собой набор баз данных, расположенных на сервере Domino.

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

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

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

    • составление проекта документа;

    • определение его рецензентов;

    • отправка проекта на согласование (рецензирование);

    • внесение изменений в текст документа;

    • отправка проекта на согласование;

    • в случае готовности отправка проекта документа на подпись руководителю.

Поддержка в Domino технологии OLE 2, сделала возможным обеспечить независимость автоматизированной системы документооборота от форм (шаблонов) документов. Документ "изготавливается" с помощью любого, уже известного пользователю текстового редактора, а затем "внедряется" в транспортную систему документооборота. Система не зависит от изменения видов и форм (шаблонов) транспортируемых системой документов, т.к. все это реализуется средствами редактора при создании документа.

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

Рисунок 1. (увеличить)

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

Рисунок 2. (увеличить)

Выбрав название документа, вид документа и нажав кнопку "СОСТАВИТЬ…" пользователь получает доступ к окну составления текста документа (рис. 3):

Рисунок 3. (увеличить)

Текст документа может быть создан любым из предложенных названиями кнопок способом, включая и непосредственный ввод текста в поле, отмеченное в левой нижней части рисунка "уголками". Составив текст и сохранив его с помощью кнопки "СОХРАНИТЬ И ВЕРНУТЬСЯ" пользователь получает возможность определить дополнительные реквизиты документа, при необходимости определить рецензентов проекта и оправить проект документа на согласование (рис. 4).

Рисунок 4 (увеличить)

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

Нажав кнопку "ОТПРАВИТЬ ПРОЕКТ НА СОГЛАСОВАНИЕ", пользователь получает следующее:

Рисунок 5. (увеличить)

Теперь проект документа недоступен для изменений и пользователь может только следить за процессом его согласования.

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

Рисунок 6. (увеличить)

Если рецензент согласен с содержанием проекта документа, он нажимает кнопку "СОГЛАСЕН С СОДЕРЖАНИЕМ ПРОЕКТА", в противном случае он, в рамках системы, составляет рецензию на проект документа и кнопкой "ВЕРНУТЬ НА ДОРАБОТКУ" возвращает проект исполнителю документа. В процессе согласования исполнитель получает информацию о ходе процесса в виде, представленном на рис. 7.

Рисунок 7. (увеличить)

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

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

Существенным является то, что система регистрирует все действия каждого пользователя над каждым документом, что позволяет определить активность сотрудников организации. Просмотреть эту информацию можно с помощью кнопки "ПОКАЗАТЬ ОПЕРОГРАММУ ДОКУМЕНТА" (рис. 8).

Рисунок 8. (увеличить)

Использование этой информации очевидно должно существенным образом повысить исполнительскую дисциплину.

Аналогичным образом реализованы и все другие этапы работы системы.

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

Интеграция САДД с разнородными базами данных и информационными системами

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

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

Для решения этой задачи было сделано следующее:

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

    • разработаны спецификации на различные слои метаданных, которые будут описывать данные в каждой из подсистем, вовлеченные в процессы информационного обмена. Сам по себе стандарт XML является обобщенным форматом данных, он создан консорциумом, состоящим из многих компаний, и необходимо дополнить язык XML семантикой, которая существует в области разработки информационных систем, основанных на понятии "документ", таких как: электронные архивы, системы документооборота и делопроизводства, генераторы отчетов из различных ERP-систем и т.д.

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

В каждой системе имеется XML-Репозитарий, где хранятся XML-файлы, содержащие схемы загрузки и выгрузки информации из собственного Хранилища (1-й слой метаданных). Со схемами загрузки/выгрузки работают универсальные Java-приложения DBImport и DBExport, доступ к которым может быть осуществлен через Web-интерфейс (см. на схеме Web-приложение). Они не модифицируются при переносе из системы в систему (или при добавлении новых систем), а настраиваются на работу со схемами данных (XML-схемы). Достоинством этих модулей является то обстоятельство, что они не нуждаются в перепрограммировании. Они обеспечивают возможности экспорта/импорта через гибкие, универсальные интерфейсы:

    • уровень XML-схемы (XML-парсер, обеспечивающий разбор XML-файлов из Репозитария и безошибочное извлечение данных);

    • уровень доступа к Хранилищу (JDBC или Сonnector), обеспечивающий извлечение и запись данных в Хранилище c использованием XML-конвертора и валидации данных по схеме.

Разработанное программное обеспечение позволяет производить загрузку/выгрузку данных как периодически так и динамически.

В варианте регулярного периодического обмена данными, в общем случае процесс обмена осуществляется с использованием сценариев загрузки/выгрузки автоматически, или с возможностью административного интерфейса через Web-приложение:

"Выгрузить из системы X данные по схеме выгрузки N и загрузить в систему Y по схеме загрузки M ".

В данном варианте существует два способа организации административного интерфейса:

1. Централизованное администрирование репозитария сценариев загрузки/выгрузки данных. Этот вариант предполагает создание единого репозитария схем загрузки/выгрузки для всех систем участвующих в обмене данными и средства его администрирования.

2. Распределенное администрирование локальных репозитариев для каждой системы в отдельности. Этот вариант предполагает создание отдельных репозитариев схем загрузки/выгрузки для каждой из систем и развертывания локальных средств их администрирования.

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

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

SOAP-сообщение выглядит следующим образом:

<Envelope

xmlns="http://schemas.xmlsoap.org/soap/envelope/"

<Header>

<!-- заголовки -->

</Header>

<Body>

<!-- документы -->

</Body>

</Envelope>

Заголовки пакета (содержимое элемента <Header>) могут быть любыми. Прикладные программы должны формировать их с учетом потребностей конкретной среды передачи данных в соответствии со стандартом SOAP.

Тело пакета <Body> состоит из одного или более документов. Документами считаются все элементы, непосредственным родителем которых является <Body>.

В соответствии с разрабатываемой спецификацией, в состав SOAP-сообщения могут входить один или более XML - документов, являющиеся универсальными документами обмена между системами. Спецификация предусматривает один стандартный тип документа обмена, прикладные программы могут вводить свои.

Вместе с этим, спецификация определяет четыре стандартных подтипа передаваемых сообщений:

  1. Команды для управления действиями систем;

  2. Метаданные (описания) предоставляемых ресурсов;

  3. Передаваемые данные;

  4. Результат обработки запроса системой.

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

Обеспечение безопасности функционирования САДД отрасли

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

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

    • средства создания частных виртуальных сетей на основе инкапсуляции и кодирования пакетов;

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

Комплексирование этих технологических групп в интегрированную корпоративную систему информационной безопасности для построения защищенного корпоративного документооборота позволяет решить задачи: как разделения ресурсов, так и построения защищенной системы передачи данных. Предлагаемое решение должно обеспечить, с одной стороны, надежную защиту сетевых ресурсов, а с другой, высокую масштабируемость и производительность работы информационных приложений, которые обеспечены эффективной системой авторизации и аутентификации. Предлагаемая структура системы информационной безопасности отраслевого документооборота на базе Lotus Notes/Domino представлена на рис. 9.

В основе создаваемой системы защиты лежат две взаимоувязанные телекоммуникационные среды, которые имеют общую точку обмена данными с открытой сетью и Интернет:

    • информационная магистраль (ИМ), через которую обеспечивается доступ к порталам и другим сетевым ресурсам, с использованием средств контроля за трафиком на базе межсетевых экранов (МЭ);

    • защищенная виртуальную магистраль (ЭВМ), которая для передачи данных использует имеющиеся телекоммуникационные ресурсы, доступ к которым осуществляется с использованием криптошлюзов (КШ).

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

Анализ уязвимости приложений в сети Интернет показывает, что существуют ряд воздействий, которые могут нарушать процесс обмена данными: подмена IP-адреса отправителя другим адресом (IP spoofing); перехват сеанса, когда установленное соединение переключается на новый хост-узел; перехват пароля передаваемого в незащищенном виде (password sniffing); посредничество в обмене незашифрованными ключами (man-in-the middle). Все перечисленные воздействия возможны в следствии того, что: аутентификация отправителя осуществляется только на основе его ЕР адреса; процедуры аутентификации выполняются только на стадии установления соединения; часть данных, влияющих на степень защищенности приложений, передается через сеть в незашифрованном виде.

Использование в предлагаемом решении спецификаций IP Sec позволяет выделить достаточное число средства организации защиты: протокол аутентификации заголовка, который связывает данные в пакете с параметрами, которые позволяют удостоверится в целостности и подлинности отправителя; протокол шифрования данных (Encapsulated Security Payload, ESP), позволяющий применять различные алгоритмы и процедуры криптообработки данных; протокол обмена ключами (Internet Key Exchange, DCE), позволяющий согласовать параметры алгоритмов аутентификации, шифрования и обмена ключами.

Рисунок 9.

Учитывая это, для организации системы передачи данных и распределения ресурсов в качестве ключевого компонента предлагается использовать многокомпонентный межсетевой экран, работающий в "стелс"-режиме (рис. 10), что позволит:

  1. реализовать систему без внесения изменений в отраслевую политику маршрутизации;

  2. распределять ресурсы в зависимости от установленной отраслевой политики информационной безопасности;

  3. организовать защищенное и контролируемое соединение с централизованной системой авторизации;

  4. контролировать совершаемые сетевые транзакции;

  5. разделять политики информационной безопасности для каждой виртуальной ЛВС (VLAN).

Рисунок 10.



Члены
Гильдии Управляющих Документацией

     

Дистанционное обучение по образовательным программам
курсов повышения квалификации
  Лицензия № 039458   Государственная аккредитация № 0210

Наши слушатели

Курсы повышения квалификации руководителей, специалистов в сфере ДОУ и электронного документооборота, секретарей-референтов 
на 2019год.
Современные технологии в работе службы ДОУ
Современные технологии в работе секретаря-референта, помощника руководителя23-28 сентября 2019
21-26 октября 2019
18-23 ноября 2019
Современные технологии в работе с электронными документами


Полный перечень законодательных актов на CD
Законодательные, иные нормативные правовые акты, методические документы в сфере информации и документации до 2019 года.
Заказать