0,07400920

BPwin

0,4437561

0,286561

0,6130815

0,1442769

0,39065682

Design/IDEF

0,1124876

0,144277

0,3086729

0,5691624

0,24782005

График-студио Лайт

0,4437561

0,569162

0,0782454

0,2865606

0,36152295

Таким образом, применив метод анализа иерархий, мы выяснили, что по совокупности критериев следует выбрать и использовать CASE-средство BP-Win, так как оно обладает максимальным значением глобального приоритета по совокупности обозначенных критериев, важных с точки зрения решаемой задачи моделирования бизнес-процессов отдела делопроизводства.

2.4 Функциональное моделирование бизнес-процессов

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

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

При выполнении используются информационная система и сотрудники ФГУП «ЦентрИнформ».

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

Детали использования информационной системы на верхнем уровне не видны, поэтому производим декомпозицию в IDEF0 на 4 блока:

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

Отправить документ - все, что касается использования методики организации внутреннего документооборота ФГУП «ЦентрИнформ» через сервис Dropbox.

Рисунок 8. Контекстная диаграмма бизнес-процесса

Зарегистрировать документ - все, что касается получения документа и обработки его секретарем с дальнейшей передачей на обработку делопроизводителю.

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

Рисунок 9. Диаграмма декомпозиции контекстной диаграммы

Далее рассмотрим только те процессы, в которых как механизм применяется информационная система:

1. Создать документ;

2. Отправить документ;

3. Обработать документ.

Начнем с первого, декомпозируем процесс в нотацию DFD:

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

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

Заполненный шаблон сохраняется в документ, приготовленный для отправки через внутреннее хранилище в Dropbox.

Рисунок 10. Диаграмма бизнес-процесса «Создать документ»

Процесс отправки декомпозируем в нотации IDEF3:

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

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

Если ошибок не найдено, то документ помещается в хранилище Dropbox и сотрудник уведомляет секретаря одним из доступных способов.

Если в документе найдены ошибки, то возвращаемся к процессу создания и вносим необходимые коррективы

Диаграмма с данными блоками показана ниже

Рисунок 11. Диаграмма бизнес-процесса «Отправить документ»

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

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

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

Рисунок 12. Диаграмма бизнес-процесса «Обработать документ»

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

информационный база данный делопроизводство

3. Проектирование информационной системы автоматизированной обработки отчетной документации филиалов ФГУП «Центринформ»

3.1 Формирование требований и критериев для отбора систем аналогов

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

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

Функциональные требования

1. Делопроизводственные функции

1.1 Создание документов (использование шаблонов документов)

1.2 Регистрация документов

1.3 Обеспечение сохранности конфиденциальной информации

1.4 Наличие справочников-классификаторов

1.5 Хранение нормативно-справочной информации по документообороту организации

2. Организация электронного архива

2.1 Ведение баз данных

2.2 Архивирование документов

2.3 Полнофункциональный поиск

2.4 Безопасность хранения документов

2.5 Организация доступа к архиву

3. Обеспечение задач электронного документооборота:

3.1 Работа с электронными файлами

3.2 Регистрация документов, поступивших по электронным каналам связи.

3.3 История работы с документами

3.4 Полнотекстовый поиск документов

Системно-технические требования

1. Программная реализация

1.1.Технология клиент - сервер

1.2.Наличие средств резервного копирования

1.3 Интеграция в информационную среду организации

1.4 Интерфейс, взаимодействующий с другими программами (например, со средствами создания, сканирования и распознавания документов)

1.5 Протоколирование действий в системе; совместная работа над документами

1.6 Территориально-распределенная работа. Критерий

2. Эксплуатационные требования

2.1 Надежность автоматизированной системы

2.2 Безопасность системы

2.3 Администрирование системы

2.4 Территориально-распределенная работа системы

2.5 Количество одновременно работающих пользователей - до 100

2.6 Средний объем документопотока (в год) - до 10000

3. Адаптационные возможности

3.1 Простота и удобство при внедрении системы

3.2 Обучение сотрудников организации

3.3 Удобство настройки системы

3.4 Возможность развития системы

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

3.2 Сравнительный анализ аналогов

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

3.2.1 Выбор системы весовых коэффициентов

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

Таблица 14

Система баллов для экспертной оценки

Критерии	Количество баллов
1. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ	От 0 до 90
1.1 Делопроизводство	От 0 до 50
1.1.1 создание документов	От 0 до 10
1.1.2 регистрация документов	От 0 до 15
1.1.3 обеспечение сохранности конфиденциальной информации	От 0 до 15
1.1.4 наличие справочников-классификаторов	От 0 до 5
1.1.5 хранение нормативно-справочной информации по документообороту организации	От 0 до 5
1.2 Организация электронного архива	От 0 до 35
1.2.1 ведение баз данных	От 0 до 5
1.2.2 архивирование документов	От 0 до 10
1.2.3 полнофункциональный поиск	От 0 до 10
1.2.4 безопасность хранения документов	От 0 до 5
1.2.5 организация доступа к документам	От 0 до 5
1.3 Обеспечение задач электронного документооборота	От 0 до 5
1.3.1 работа с электронными файлами	От 0 до 5
2. СИСТЕМНО-ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ	От 0 до 155
2.1 Программная реализация	От 0 до 55
2.1.1 технология клиент - сервер	От 0 до 20
2.1.2 наличие средств резервного копирования	От 0 до 10
2.1.3 интеграция в информационную среду организации	От 0 до 5
2.1.4 интерфейс, взаимодействующий с другими программами	От 0 до 15
2.1.5 протоколирование действий в системе	От 0 до 5
2.1.6 территориально-распределенная работа	От 0 до 10
2.2 Эксплуатационные требования	От 0 до 60
2.2.1. надежность автоматизированной системы	От 0 до 20
2.2.2 безопасность системы	От 0 до 10
2.2.3 администрирование системы	От 0 до 10
2.2.4 территориально-распределенная работа системы	От 0 до 10
2.2.5 количество одновременно работающих пользователей - до 100 человек	От 0 до 5
2.2.6 средний объем документопотока (в год) - до 10000 единиц	От 0 до 5
2.3. Адаптационные возможности	От 0 до 40
2.3.1 простота и удобство при внедрении системы	От 0 до 15
2.3.2 обучение сотрудников организации	От 0 до 10
2.3.3 удобство настройки системы	От 0 до 10
2.3.4 возможность развития системы	От 0 до 5

3.2.2 Поиск программных продуктов

При поиске и выборе программных продуктов на рынке автоматизированных систем предъявлялись следующие требования:

· гибкость настройки и адаптация к особенностям предприятия ФГУП «ЦентрИнформ»;

· завершенность программного продукта - система не требует вмешательства программистов для ее сопровождения;

· объединяет территориально-удаленные рабочие места в единую информационную базу;

· невысокая стоимость;

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

«Внедрение АС ДОУ должна осуществлять внешняя фирма, несущая полную юридическую ответственность перед предприятием за успех проекта внедрения. К выбору фирмы-поставщика и внедренца АС ДОУ нужно подходить очень скрупулезно, так как после подписания контракта, проплаты каких-либо средств и начала внедрения АС ДОУ с этой фирмой будет непросто прекратить отношения в случае, если предприятие будет не полностью удовлетворять качество её работы. Фактически, в случае неправильного выбора фирмы-подрядчика, будут напрасно потеряны деньги, время и нервы. Конечно, при выборе АС ДОУ необходимо внимательно изучить несколько предложения, имеющиеся на рынке». [9]

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

Таблица 15

Данные по системе Directum

Производитель и распространители в России	Предназначение	Возможности
НПО «Компьтер, Компания «DIRECTUM»	Автоматизация делопроизводства и управленческих процессов на основе технологии Workflow: согласование документов, обработка сложных заказов, подготовка и проведение совещаний, поддержка цикла продаж и других процессов взаимодействия.	Система состоит из следующих модулей: 1)«Управление электронными документами», что включает в себя: - обеспечение создания, хранения, поиска (все документы размещены в едином информационном пространстве базы данных SQL сервера, что обеспечивает быстрый поиск); - изменения различных документов (тексты, рисунки, звуки, видео).Использование любых программ, шаблонов, хранение истории изменения содержания; -обеспечивается конфиденциальность путем настройки прав доступа, протоколирования всех действий. ЭЦП позволяет системе интегрироваться с различными системами криптозащиты. 2)«Управление деловыми процессами» включает: - автоматизацию процесса подготовки и согласования документов, учета и контроля исполнения устных и письменных распоряжений; -маршрутизация, управление задачами,
		наличие возможности изменения схемы движения документа, анализа данных о выполненных заданиях. 3) «Канцелярия» обеспечивает: - единую регистрацию всей входящей и исходящей корреспонденции, а также внутренних документов с использованием регистрационно-контрольных карточек; - регистрацию местонахождения бумажного документа на любом этапе жизненного цикла документа: рассмотрение руководства, согласование проекта документа, исполнение и т.д.; - осуществление контроля за своевременным исполнением поручений, резолюций и указаний руководства; - списание документов в дело в соответствии с принятой в организации номенклатурой дел; - быстрый поиск необходимой информации по состоянию, наличию, движению бумажных документов; - получение необходимых стандартных форм и журналов, а также статистических отчетов по документообороту организации. 4) «Управление договорами»: организация процесса согласования и регистрации договоров и сопутствующих документов, а также оперативной работы с ними (поиск, анализ, редактирование и т.д.).
		5) «Управление совещаниями»: организация подготовки и проведения совещаний (согласование места и времени, состава участников, повестки); формирование и рассылка протокола; контроль исполнения решений совещания. 6) «Управление взаимодействиями с клиентами»: ведение единой базы организаций и контактных лиц; ведение истории встреч, звонков и переписки с клиентами; сопровождение процесса продаж в соответствии с регламентированными стадиями; планирование маркетинговых мероприятий; анализ эффективности продаж и маркетинговых воздействий.

Архитектура и технические возможности системы DIRECTUM

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

· Адаптация системы DIRECTUM к специфическим нуждам организации и развитие системы вместе с ростом потребностей бизнеса обеспечивается возможностями инструмента разработки IS-Builder, который предлагает развитые средства быстрого создания новых справочников, карточек электронных документов, сценариев, экранных форм, типовых маршрутов, их отдельных блоков и других компонентов корпоративной системы электронного документооборота;

· интеграция DIRECTUM с ERP-системами, корпоративными порталами и другими составными частями ИТ-инфраструктуры организации возможна по разным направлениям, от двустороннего обмена данными до интеграции интерфейса систем, что становится возможным благодаря развитым интеграционным возможностям платформы DIRECTUM - предметно-ориентированного инструмента быстрой разработки корпоративных информационных систем IS-Builder;

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

· взаимодействие сотрудников через Интернет и в Интранет

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

· инструменты администрирования DIRECTUM позволяют управлять всеми задачами администрирования - от регистрации пользователей до создания политик миграции документов между файловыми хранилищами;

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

Таблица 16

Данные по системе DocsVision

Производитель и распространители в России	Предназначение	Возможности
DocsVision, фирма «Digital Design»	Создание автоматизированных корпоративных решений по управлению документами и бизнес-процессами. Стандартные приложения: · «Делопроизводство» законченное приложение, предназначенное для создания архивов документов, автоматизации основных делопроизводственных процедур и бизнес процессов обработки документов в организации. · «Управление процессами» - полнофункциональная WorkFlow система описания и исполнения сложных процессов обработки информации и взаимодействия с информационными системами.	Система DocsVision "Делопроизводство" включает: · Ведение картотеки документов; · создание электронного архива документов компании; · ведение справочников контрагентов и сотрудников организации; · организацию циклов разработки согласования документов; · организация контроля исполнения документов и заданий; · маршрутизация документов в организации и вне её; · автоматизация разнообразных процессов обработки документов · организация процедур периодической обработки документов и широковещательной рассылки документов.

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

Модуль репликации - предназначен для создания территориально-распределенных решений на базе DocsVision.

Шлюзы к другим системам - предназначены для интеграции DocsVision и других информационных систем:

· Файловая система,

· Microsoft Exchange,

· Microsoft SharePoint,

· Microsoft Dynamics AX,

· 1С: Предприятие.

Таблица 17

Данные по системе «Дело»

Производитель и распространители в России	Предназначение	Возможности
Компания «Электронные офисные системы»	Автоматизация делопроизводства, архивного дела и организация электронного документооборота. Система обеспечивает в полном объеме работу, как с бумажными, так и с электронными документами. «АРХИВНОЕ ДЕЛО» - это подсистема, входящая в качестве опции в «ДЕЛО-ПРЕДПРИЯТИЕ». Подсистема «Архивное дело» создана для обеспечения автоматизации архивного дела в организациях, министерствах и ведомствах.	Система обеспечивает хранение РК и прикрепляемых к ней файлов. Основной рабочей подсистемой является подсистема «Документы» Подсистема «Отчеты» обеспечивает получение различных отчетов Подсистема «Ведения пользователей» предназначена для регистрации пользователей и предоставления им прав доступа к информации и функционалу системы. Подсистема ведения справочников предназначена для настройки системы на структуру организации и особенности ее делопроизводства. Основные функции системы: - Регистрация документов, в том числе обращений граждан; - ввод резолюций и контроль их исполнения; - создание, согласование и подписание проектов документов в электронной форме; - маршрутизация и контроль движения документов, рассылка по спискам; - многоаспектный поиск документов с сохранением запроса; - работа с взаимосвязанными документами; - сканирование и прикрепление файлов документов, полнотекстовый поиск по ним; -ЭЦП файлов документов; - обмен документами по электронной почте с использованием ЭЦП и шифрования; - справочно-аналитическая работа, формирование отчетов; - Web-доступ к базе данных; - подготовка и согласование документов в электронной форме; - электронная подпись файлов документов; - криптозащита документов, отправляемых электронной почтой; - обеспечение поточного сканирования документов; - интеграция с приложениями MS Office; - Web-доступ к информации.

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

Таблица 18

Данные по системе «Управление делами»

Производитель и распространители в России	Предназначение	Возможности
Компания «КИНТ»	Программный комплекс "Управление делами" получил сертификат "1С:Совместимо" и предназначен для автоматизации деловых процессов предприятия, согласования проектов, планов и мероприятий, организации потока бумажных и электронных документов. Ориентирован на упорядочивание повседневной деятельности менеджеров разных уровней. "Управление делами" также используется при организации внедрения на предприятии комплексной автоматизированной системы учета. Программный комплекс "Управление делами" функционирует в среде "1С:Предприятие» с любым набором установленных компонент: бухгалтерский учет, оперативный учет, расчет.	- Организация потока задач/поручений между сотрудниками компании, контроль хода исполнения поручений, учет плановых и фактических ресурсов. - Планирование и учет мероприятий компании, разбиение мероприятий на отдельные этапы (задачи), выдача поручений исполнителям по проведению мероприятия. - Учет движения и местоположения различного рода бумажных документов (делопроизводство). Подсистема построена на основе стандартов делопроизводства, принятых в России, и реализует все необходимые этапы прохождения документов. -Регистрация электронных документов, ведение архивов документов в электронном виде. -Управление отношениями с клиентами (CRM), учет различной информации о контрагентах компании, контактов. - Подсистема позволяет анализировать и планировать взаимоотношения с контрагентами, организовывать тематические рассылки. -Управление правами пользователей обеспечивает разделение информации внутри компании по степени конфиденциальности. -Ведение деловой переписки позволяет провести в электронном виде различного рода согласования и утверждения документов. -Интеграция с системами электронной почты дает возможность получать и отправлять электронные письма без использования дополнительного программного обеспечения. -Получение отчетов позволяет детально анализировать информацию о работе офиса. -Наличие путеводителей и инструкций.

Таким образом, системы, охарактеризованные в таблице, соответствуют предъявляемым функциональным и системно-технологическим требованиям, поэтому для выбора системы, пригодной для использования в ФГУП «ЦентрИнформ» необходимо подробнее проанализировать выполняемые системой функции по автоматизации делопроизводства по предложенной системе баллов, оценить, рассчитать стоимость внедрения платформы. Данная методика выбора автоматизированной системы разработана компанией Sputnik Labs [10] она позволит в соответствии с рекомендуемой последовательностью действий добиться максимального соответствия АС ДОУ целям и задачам предприятия.

3.2.3 Оценка программных продуктов с точки зрения предъявляемых основных функциональных и системно-технических требований

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

A - DIRECTUM, B - Дело

C - DocsVision, D - Управление делами

Таблица 19

Сравнительный анализ систем

Критерии	Экспертная оценка
	A	B	C	D
1. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ от 0 до 90
1.1 Делопроизводство	От 0 до 50
1.1.1 создание документов	10	9	10	8
1.1.2 регистрация документов	9	9	9	7
1.1.3. обеспечение сохранности конфиденциальной информации	14	10	12	6
1.1.4 наличие справочников-классификаторов	4	4	5	3
1.1.5 хранение нормативно-справочной информации по документообороту организации	5	4	5	2
ИТОГО по п. 1.1	42	40	41	26
1.2 Организация задач электронного архива	От 0 до 35
1.2.1 ведение баз данных	5	4	4	2
1.2.2 архивирование документов	9	8	9	6
1.2.3 полнофункциональный поиск	10	10	10	8
1.2.4 безопасность хранения документов	4	4	4	3
1.2.5 организация доступа к документам	5	4	4	4
ИТОГО по п. 1.2	33	30	31	23
1.3. Обеспечение задач электронного документооборота	От 0 до 5
1.3.1. работа с электронными файлами	5	5	5	4
ИТОГО по п. 1.3	5	5	5	4
ИТОГО ПО ФУНКЦИОНАЛЬНЫМ ТРЕБОВАНИЯМ	80	75	77	53
2. СИСТЕМНО-ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ от 0 до 155
2.1 Программная реализация	От 0 до 65
2.1.1 технология клиент - сервер	19	19	18	17
2.1.2 наличие средств резервного копирования	9	9	9	8
2.1.3 интеграция в информационную среду организации	3	5	4	5
2.1.4. интерфейс, взаимодействующий с другими программами	14	13	14	8
2.1.5 протоколирование действий в системе	5	4	5	4
2.1.6 территориально-распределенная работа	9	9	9	6
ИТОГО по п. 2.1	59	59	59	48
2.2 Эксплуатационные требования	От 0 до 60
2.2.1 надежность автоматизированной системы	18	17	17	15
2.2.2 безопасность системы	9	9	9	9
2.2.3 администрирование системы	8	8	8	7
2.2.4 территориально-распределенная работа системы	9	9	9	8
2.2.5 количество одновременно работающих пользователей - до 100 человек	5	5	5	4
2.2.6 средний объем документопотока (в год) - до 700000 единиц	4	4	4	1
ИТОГО по п. 2.2	53	52	52	44
2.3 Адаптационные возможности	От 0 до 40
2.3.1 простота и удобство при внедрении системы	9	8	14	15
2.3.2 обучение сотрудников организации	9	8	8	9
2.3.3 удобство настройки системы	9	7	7	10
2.3.4 возможность развития системы	4	4	4	3
ИТОГО по п.2.3.	36	27	28	37
ИТОГО ПО СИСТЕМНО-ТЕХНОЛОГИЧЕСКИМ ТРЕБОВАНИЯМ	148	138	139	129
ВСЕГО	223	218	216	182

3.2.4 Отбор программных продуктов, удовлетворяющих функциональным и системно-техническим требованиям

В результате проведение оценки программных продуктов, их тщательного анализа, были сделаны следующие выводы:

1. Наибольшую суммарную оценку из программных продуктов получили системы автоматизации «DocsVision» (фирма «Digital Design») и «DIRECTUM» (НПО «Компьютер», компания «DIRECTUM»), следовательно системы в большей степени соответствуют функциональным и системно-техническим критериям, полностью автоматизируют операции работы с документами (как в традиционном бумажном виде, так и в электронном) с момента создания до момента уничтожения (списания в дело), включая контроль исполнения, обеспечение хранения документов, систему защиты данных, обладают большими возможностями, надежностью и средствами защиты.

2. Наименьшую оценку получила система автоматизации «Управление делами» (компания «КИНТ»). Она не в полной мере отвечает требованиям по автоматизации делопроизводственного процесса, следовательно, не подходят для внедрения в ФГУП «ЦентрИнформ», но данная система проста и удобна при внедрении.

3. Система «Дело» («Электронные офисные системы») обладает почти аналогичными возможностями, что и система «DocsVision», но набрала меньше баллов экспертов.

Для того чтобы выбрать приложение оптимальной системы, необходимо определить для себя наиболее важные критерии и возможности предприятия. В ФГУП «ЦентрИнформ» недостаточно средств для приобретения дорогостоящей системы, но требуется автоматизация и решение проблем отдела делопроизводства.

Необходимо сравнить цены на модули организации делопроизводства выбранных автоматизированных систем. Цены приводятся в прайс-листах компаний. Рассматриваются цены на необходимые для предприятия приложения, сопроводительную документацию и обучение персонала. Существует 3 варианта поставки систем: для небольших организаций; для средних организаций (до 100 пользователей); для крупных организаций.

Был выбран 2 вариант.

1. Стоимость системы «DocsVision»- 217 080 руб. (не включает обучение).

2. Стоимость модулей «Канцелярии», «Управление договорами» системы «DIRECTUM» - 272 390 (включает обучение)

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

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

Цены на поставляемые продукты слишком высоки, а предоставляемый функционал избыточен, поэтому требуется проектирование собственной, более дешевой системы.

3.3 Выбор архитектуры проектируемой информационной системы

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

Таблица 20

Типовые компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic(логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логики обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

Поскольку эта архитектура предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема приводит к дополнительному усложнению администрирования приложений, разбросанных по различным клиентским узлам.

Для сокращения нагрузки на сеть и упрощения администрирования приложений компонент BL можно разместить на сервере. При этом вся логика принятия решений оформляется в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Хранимые процедуры могут компилироваться, что повышает скорость их выполнения и сокращает нагрузку на сервер.

Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность данных (нет прямого доступа к данным).

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней:

· нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;

· средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

· верхний уровень представляет собой удаленный специализированный сервер базы данных, выделенный для услуг обработки данных DS и файловых операций FS (без использования хранимых процедур).

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной.

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

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

Критериями оценивания описанных выше трех альтернатив будут:

а) Простота реализации;

б) Простота обновления ПО;

в) Затраты на эксплуатацию и установку.

Присвоим наиболее важному критерию оценку 100 баллов. Исходя из попарного отношения критериев по важности, дадим в баллах оценку каждому из критериев (таблица 28):

Таблица 21

Оценка критериев

Критерии	Баллы
Простота реализации	100
Простота обновления ПО	85
Затраты на эксплуатацию и установку	75

Сложим полученные баллы. Произведём нормировку весов критериев, разделив присвоенные баллы на сумму весов:

где A_i - баллы критерия,

n - количество критериев.

Результаты нормировки приведены в таблице 29.

Таблица 22

Нормированные оценки критериев

Критерии	Баллы	Нормировка весов
Простота реализации	100	0,384615385
Простота обновления ПО	85	0,326923077
Затраты на эксплуатацию и установку	75	0,288461538
сумма баллов	260	1

Измерим значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.

Таблица 23

Оценка альтернатив

Альтернативы	Критерии
	Простота реализации	Простота обновления ПО	Затраты на эксплуатацию и установку
Файл-сервер	90	70	95
Клиент-сервер	85	85	90
Многоуровневая	75	80	75

Определим общую оценку каждой альтернативы, используя формулу взвешенной суммы баллов общая оценка альтернативы - , где В_i оценка альтернативы по каждому критерию (таблица 31)

Таблица 24

Общая оценка альтернатив

Альтернативы	Критерии
	Простота реализации	Простота обновления ПО	Затраты на эксплуатацию и установку	Общая оценка
Файл-сервер	34,6153846	22,8846153	27,4038461	84,9038461
Клиент-сервер	32,6923076	27,7884615	25,9615384	86,4423076
Многоуровневая	28,8461538	23,0769230	21,6346153	73,5576923

Выберем как лучшую альтернативу, имеющую наибольшую общую оценку - это архитектура Клиент-Сервер.

Рисунок 13. Архитектура информационной системы отдела делопроизводства

Информационная система отдела делопроизводства состоит из сервера с базой данных, и клиентских АРМ-ов двух типов.

1. АРМ делопроизводителя, включающий:

§ средство проверки корректности

§ редактор шаблонов

§ средство поиска документов

§ средство автоматического формирования выходных документов

2. АРМ-ы сотрудников ФГУП «ЦентрИнформ», включающие:

§ средство проверки корректности

§ базу шаблонов

3.4 Проектирование структуры базы данных информационной системы отдела делопроизводства ФГУП «ЦентрИнформ»

IDEF1X [7,11] является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

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

Правила устанавливают, что атрибуты и группы атрибутов должны:

· Уникальным образом идентифицировать экземпляр сущности.

· Не использовать NULL значений.

· Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

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

При выборе первичного ключа для сущности, разработчики модели часто используют дополнительный (суррогатный) ключ, т.е. произвольный номер, который уникальным образом определяет запись в сущности. Атрибут "Номер преподавателя " является примером суррогатного ключа. Суррогатный ключ лучше всего подходит на роль первичного ключа потому, что является коротким и быстрее всего идентифицирует экземпляры в объекте. К тому же суррогатные ключи могут автоматически генерироваться системой так, чтобы нумерация была сплошной, т.е. без пропусков. Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы. Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими. Основным преимуществом IDEF1X, по сравнению с другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая, несомненно, является значительным недостатком. Первым делом необходимо определить ту информацию, которую необходимо хранить в БД, на основании этого можно будет построить логическую модель БД. Моделирование логической структуры базы данных целесообразно производить с помощью методологии «сущность-связь». Процесс построения БД состоит из следующих шагов: методологии, [11],

· выбор сущностей

· определение атрибутов сущностей;

· приведение модели к требуемому уровню нормальной формы;

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

· генерация базы данных.

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

База данных информационной системы отдела делопроизводства показана на рисунке 14.

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

База данных проектируемой информационной системы состоит из 7 сущностей:

· Документ - любой документ, единожды открытый через информационную систему, попадает в БД и хранится вместе со сведениями об отправителе, типе.

· История изменений - на каждый документ ведется история вносимых в него правок, с указанием автора;

· Шаблон - каждый хранимый или создаваемый в системе документ построен по одному из хранимых в данной сущности шаблону;

· Сведение - с шаблоном ассоциировано понятие сведения, извлекаемого автоматически их входящих в систему документов и автоматически вносимое в выходной документ;

· Выходной документ - автоматически создаваемый по выбранному шаблону из хранящихся сведений документ;

· Пользователь - лицо, имеющее право создавать выходные документы или просматривать существующие в системе;

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

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

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

Указав типы данных, мы получили физическую модель данных для создания БД.

4.  Реализация информационной системы автоматизированной обработки отчетной документации филиалов ФГУП «Центринформ»

4.1 Описание алгоритма извлечения сведений из документов

Чтобы извлекать данные из электронных документов, поступающих в адрес делопроизводителя, воспользуемся методикой, описанной в [12].

Используемая технология состоит из следующих этапов.

1. Преобразование (печать) электронных документов разных форматов в метафайлы.

2. Получение данных (текста и разграфки) из метафайлов.

3. Обнаружение таблиц на страницах.

4. Анализ функций ячеек таблицы.

5. Сегментация таблицы.

6. Структурный анализ таблицы.

7. Представление выделенных сведений в XML-файлах.

Схема технологии извлечения табличной информации из электронных документов показана на рисунке 16.

Рисунок 16. Технология извлечения информации из электронных документов

На рисунке 16 представлена схема, демонстрирующая основные компоненты и этапы предлагаемой технологии. Стрелками на этой схеме показаны потоки данных в предлагаемой технологии. Электронные документы разных форматов, например, DOC, RTF, XLS, PDF, plain-text (ASCII-текст), HTML, содержащие таблицы в виде машиночитаемого текста, печатаются с помощью виртуального EMF принтера в метафайлы. При этом каждый полученный метафайл представляет одну страницу исходного документа.

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