Глава 2. МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ ПО УПРАВЛЕНИЮ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ

В качестве нотации моделирования бизнес-процессов, в силу удовлетворяющих в данной работе особенностей моделирования бизнес-процесса, выбрана нотация ARIS, являющаяся методологией предназначенной для моделирования бизнес-процессов организации, разработанная компанией IDS Sheer. Аббревиатура ARIS расшифровывается как «Архитектура интегрированных информационных систем» (Architecture of Integrated Information Systems). В данной методологии понятие «архитектура» служит для описания типа и функциональных свойств информационных технологий и взаимоотношений между отдельными составляющими ИС. Кроме того, учитывая развивающуюся и укрепляющуюся связь информационных технологий с бизнес-процессами компании, модели, построенные на базе концепции ARIS, позволяют описать бизнес-процессы достаточно полно и подробно.

Для описания бизнес-процессов в методологии ARIS предусмотрено большое количество типов моделей, каждая из которых принадлежит тому иному аспекту. Для описания бизнес-процессов работы с ЭД подходит модель ARIS eEPC (extended Event Driven Process Chain), предназначенная для создания моделей бизнес-процессов на нижнем уровне. Бизнес-процесс, созданный по данной модели, позволяет наглядно отразить поток работ, который протекает внутри подразделения, выявить связи между функциями и организационными единицами, и что немаловажно, в данной работе, отразить связи с ИС. Для каждой функции внутри процесса определяются конечные и начальные события, ответственные исполнитель, материальные и документальные потоки, сопровождающие, какую либо работу.

Также, важно отметить, что модель бизнес-процесса ARIS eEPC построена на определенных семантических правилах описания:

1) каждая функция должна быть инициирована событием и должна завершаться событием;

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

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

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

1. Процессы управления ЭД, протекающие в КИС:

a) систематизация, регламентация работы с ЭД;

b) создание, обработка ЭД по шаблонам;

c) автоматизация учетной деятельности с ЭД, в т.ч.:

- классификация ЭД по различным критериям;

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

- учет сроков хранения документов.

d) автоматизация поиска ЭД;

e) электронная рассылка документов;

f) автоматизация процедур коллективной работы с ЭД:

- совместная разработка проекта документа;

- согласование документа;

- экспертиза документа;

- исполнение документа.

g) обеспечение защиты от несанкционированного доступа, искажения, удаления информации из ИС.

Рассмотрим процессы в рамках стандартных архитектурных и программных решений систем, занимающихся управлением ЭД (пример укрупненной модели некоторых процессов представлен на рисунке 2.1).

Рис. 2.1 Укрупненная модель процессов в СЭД

В силу того, что в модели представлены только те процессы, которые позволяют очертить картину процессов, иллюстрирующих ЖЦ ЭД в КИС, связи между процессами условны. Это означает, что в промежутке между процессами, связанными на схеме пунктирной линией могут располагаться другие процессы, которые не несут важности в рамках отображения ЖЦ ЭД. Таким образом, условно обозначены три входа у процесса «Формирование, согласование, утверждение документ». Этот процесс отражает типичный и характерный для большинства средних/крупных предприятий процесс ЭДО.

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

Обозначенные в укрупненной модели бизнес-процессы компании по управлению ЭД необходимо рассмотреть подробно с точки зрения модели «как_есть», обозначив такие пункты: описание процесса, начало выполнения, результат процесса, требования к срокам выполнения процесса, владелец процесса, исполнители процесса, информационные технологии, поддерживающие процесс. Некоторые пункты описания носят приближенный характер.

2.1 Бизнес-процесс «Ввод документа в ИС»

Описание процесса. Бизнес-процесс «Ввод документа в ИС (сканирование)» является самым первым этапом движения документа в ИС. После сканирования бумажного документа и проверки на содержание ошибок бизнес-процесс сканирования переходит в бизнес-процесс регистрации документа в ИС. Далее, документ является уже электронным и в последующих этапах ЖЦ документа ИС оперирует ЭД.

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

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

Результат процесса. Результатом данного процесса является наступление следующих событий (см. табл. 2.1):

Таблица 2.1. Результат выполнения процесса «Ввод документа в ИС»

№	Событие	Предшествующее действие
	Основные события
1	Документ подлежит регистрации в ИС	Перевод документа на этап регистрации в ИС
	Неосновные события
2	Документы возвращены клиенту	Документы не пригодны для сканирования; Документы отложены для возврата клиенту

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

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

Исполнители процесса. Основными исполнителями процесса ввода документа в ИС (сканирования) являются сотрудники документационного управления - 2 человека (см. табл. 2.2).

Таблица 2.2. Исполнители процесса «Ввод документа в ИС»

№	Организационная единица	Подразделение	Предмет деятельности
1	Сотрудник отдела документационного управления -1	Отдел документационного управления	- прием бумажной документации; - регистрация входящей документации; - сортировка документации для сканирования - взаимодействие с поставщиками процесса
2	Сотрудник отдела документационного управления -2	Отдел документационного управления	- сканирование бумажной документации; - контроль сканирования; - перевод документации на этап регистрирования в ИС

Информационные технологии, поддерживающее выполнение процесса отображены в табл. 2.3.

Таблица 2.3. Информационные технологии процесса
«Ввод документа в ИС»

№	Функция	Наименование информационных технологий	Тип программного обеспечения
1	Потоковое сканирование бумажных документов	МФУ для потокового сканирования	Офисное оборудование
2	Сканирование документов по одному	МФУ для единичного сканирования	Офисное оборудование
3	Проверка реквизитов документов	Система ввода	Модуль ИС
4	Перевод документа на этап регистрации в ИС	Система ввода	Модуль ИС

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

2.2 Бизнес-процесс «Регистрация документа в ИС»

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

Начало выполнения процесса. Началом выполнения процесса является наступление следующего события: Документ подлежит регистрации в ИС.

Результат процесса. Результатом данного процесса является наступление следующего события: Документ зарегистрирован в ИС

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

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

Исполнители процесса. Основными исполнителями процесса регистрации документа в ИС является сотрудник отдела документационного управления (см. табл. 2.4).

Таблица 2.4. Исполнители процесса «Регистрация документа в ИС»

№	Организационная единица	Подразделение	Предмет деятельности
1	Сотрудник отдела документационного управления	Отдел документационного управления	- обработка документа в ИС на всех этапах процесса; - регистрация документа в ИС

Информационные технологии, поддерживающее выполнение процесса отображены в табл. 2.5.

Таблица 2.5. Информационные технологии процесса «Регистрация документа в ИС»

№	Функция	Наименование информационных технологий	Тип программного обеспечения
1	Извлечение из документов атрибутов, ключевых слов	Система автоматического индексирования	Модуль ИС
2	- Обработка документа в ИС; - Верификация документа; - Извлечение из документа атрибутов, ключевых слов; - Присвоение атрибутов, ключевых слов документу; - Формирование формата выходного документа; - Формирование карточки документов в ИС	Система ввода	Модуль КИС

Схема бизнес-процесса представлена в приложении E на рис. E.1.

2.3 Процесс «Выполнение заявки на выдачу документа из архива»

Описание процесса: Выполнение заявки на выдачу документа из архива представляет собой процесс, протекающий в ИС. Сотрудник отдела документационного обеспечения должен отреагировать на заявку о выдаче документа и предоставить документ запрашивающему сотруднику. Процесс отражает работу с ЭД на этапе ЖЦ «хранение».

Начало выполнения процесса. Началом выполнения процесса является наступление следующего события: Поступила заявка на предоставление доступа к ЭД из архива.

Результат процесса. Результатом данного процесса является наступление следующих событий (см. табл. 2.6):

Таблица 2.6. Результаты процесса «Выполнение заявки на удаление»

№	Событие	Предшествующее действие
	Основные события
1	Запрашиваемый пользователем документ предоставлен	Предоставление запрашиваемого пользователем документа
2	Запрашиваемый пользователем документ не предоставлен	Определение причин несоответствия
	Неосновные действия
3	Заявка не принята на рассмотрение	Направление пользователю сообщения об отсутствии документа в архиве; Направление пользователю сообщения о несоответствии уровня доступа.

Требования к срокам выполнения процесса. Длительность выполнения бизнес-процесса составляет не более 5 минут.

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

Исполнители процесса. Основными исполнителями процесса регистрации документа в ИС является сотрудник отдела документационного управления.

Информационные технологии, поддерживающее выполнение процесса отображены в табл. 2.7.

Таблица 2.7. Информационные технологии процесса «Выполнение заявки на удаление»

№	Функция	Наименование информационных технологий	Тип программного обеспечения
1	Извлечение из документов атрибутов, ключевых слов	Система автоматического индексирования	Модуль ИС
2	- Обработка документа в ИС; - Верификация документа; - Извлечение из документа атрибутов, ключевых слов; - Присвоение атрибутов, ключевых слов документу; - Формирование формата выходного документа; - Формирование карточки документов в ИС	Система ввода	Модуль ИС

Схема бизнес-процесса представлена в приложении F на рис. F.1.

2.4 Процесс «Выполнение запроса на удаление документа из ИС»

Описание процесса: Выполнение проса на удаление документа из ИС представляет собой процесс, протекающий в ИС. Сотрудник отдела документационного обеспечения должен отреагировать на запрос об удалении документа и выполнить запрос или отклонить. Процесс отражает работу с ЭД на этапе ЖЦ «вывод из ИС» и «обеспечение сохранности».

Начало выполнения процесса. Началом выполнения процесса является наступление следующего события: Поступил запрос на удаление документа из ИС.

Результат процесса. Результатом данного процесса является наступление следующего события (см. табл. 2.8):

Таблица 2.8. Результат процесса «Выполнение запроса на удаление»

№	Событие	Предшествующее действие
	Основные события
1	Запрос на удаление документа выполнен	Сохранение изменений в ИС
2	Запрос на удаление документа отклонен	Определение причин запрета на удаление
	Неосновные действия
3	Запрос не может быть выполнен	Направление сообщения пользователю о несоответствии уровня доступа; Направление сообщения пользователю об отсутствии запрашиваемого документа

Требования к срокам выполнения процесса. Длительность выполнения бизнес-процесса составляет не более 5 минут.

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

Исполнители процесса. Основными исполнителями процесса регистрации документа в ИС является сотрудник отдела документационного управления.

Информационные технологии, поддерживающее выполнение процесса отображены в табл. 2.9.

Таблица 2.9. Информационные технологии процесса «Выполнение запроса на удаление»

№	Функция	Наименование информационных технологий	Тип программного обеспечения
1	- идентификация пользователя; - поиск запрашиваемого документа в ИС; - направление сообщений пользователю; - определение уровня доступа пользователя к запрашиваемому документу; - регистрация запроса для исполнения; - определение уровня контроля над документом; - удаление документа из ИС	Система электронного документооборота	Модуль ИС

Схема бизнес-процесса представлена в приложении G.

2.5 Процесс «Выполнение запроса на редактирование документа»

Описание процесса: выполнение процесса на редактирование документа представляет собой процесс, протекающий в ИС. Сотрудник отдела документационного обеспечения должен отреагировать на запрос о редактировании документа и выполнить запрос или отклонить. Процесс отражает работу с ЭД на этапе ЖЦ «управление» и «обеспечение сохранности».

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

Результат процесса. Результатом данного процесса является наступление следующих событий (см. рис. 2.10):

Таблица 2.10. Результаты процесса «Выполнение заявки на редактирование»

№	Событие	Предшествующее действие
	Основные события
1	Запрос на редактирование документа выполнен	Сохранение изменений в ИС
2	Запрос на редактирование документа отклонен	Определение причин запрета на удаление
	Неосновные действия
3	Запрос не может быть выполнен	Направление сообщения пользователю о несоответствии уровня доступа; Направление сообщения пользователю об отсутствии запрашиваемого документа

Требования к срокам выполнения процесса. Длительность выполнения бизнес-процесса составляет не более 5 минут.

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

Исполнители процесса. Основными исполнителями процесса регистрации документа в ИС является сотрудник отдела документационного управления.

Информационные технологии, поддерживающее выполнение процесса отображены в табл. 2.11.



Таблица 2.11. Информационные технологии процесса «Выполнение запроса на редактирование»

№	Функция	Наименование информационных технологий	Тип программного обеспечения
1	- идентификация пользователя; - поиск запрашиваемого документа в электронном архиве; - направление сообщений пользователю; - определение уровня доступа пользователя к запрашиваемому документу; - регистрация запроса для исполнения; - определение уровня контроля над документом; - переформирование документа.	Система электронного архива	Модуль ИС
2	- идентификация пользователя	КИС	КИС

Схема бизнес-процесса представлена в приложении H.

2.6 Бизнес-процесс «Формирование, согласование, утверждение»

Описание процесса: Бизнес-процесс «формирование, согласование, утверждение документа» отражает ЖЦ проекта документа и его последующую обработку сотрудниками разных подразделений согласно бизнес-требованиям к данному процессу.

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

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

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

Владелец процесса. Владельцем процесса является начальник отдела делопроизводства.

Исполнители процесса. Основными исполнителями процесса выполнения запроса на редактирование в электронном архиве является сотрудник отдела документационного управления (см. табл. 2.12).

Таблица 2.12. Исполнители процесса «Согласование и утверждение документа»

№	Организационная единица	Подразделение	Предмет деятельности
1	Сотрудник отдела делопроизводства	Отдел делопроизводства	- регистрация документа в СЭД; - перевод документа на этап согласования; - отправка сообщений; - отправка документа
2	Автор документа	Любое	- формирование документа, требующего утверждения
3	Согласующий	Любое (профильное по компетенции положений в документе)	- формирование замечаний к документу
4	Начальник подразделения	Любое	- согласование документа

Информационные технологии, поддерживающее выполнение процесса отображены в табл. 2.13.



Таблица 2.13. Информационные технологии процесса «Согласование и утверждение документа»

№	Функция	Наименование информационных технологий	Тип программного обеспечения
1	- регистрация документа в СЭД; - отправка документа; - формирование листа согласования.	СЭД	Модуль ИС

Схема бизнес-процесса представлена в приложении I.

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

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

Бизнес-процесс «Регистрация документа в ИС» после применения семантических технологий на некоторых этапах, сокращается по времени, удаляются некоторые этапы, в большей степени связанные с аннотирование, выделением ключевых слов, индексированием. Регистрация документа и извлечение данных из них является самым основополагающим этапом для применения семантических технологий. Схема бизнес-процесса «Регистрация документа в ИС» в модели «как-должно быть» представлена в приложении D на рис. D.2.

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



Глава 3. ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ КИС

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

3.1 Разработка методики оценки эффективности архитектуры КИС

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

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

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

3.3.1 Методы оценки архитектуры КИС

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

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

Оценки ИС с точки зрения оценки качества рассматриваются в многочисленных работах и стандартах, например [35]. Основной характеристикой качества на основе стандарта ISO 9126 определена функциональная пригодность ИС для пользователей. Также рассматриваются такие характеристики как защищенность, способность к взаимодействию и корректности. К факторам качества, согласно [13], относят: эффективность, надежность, сопровождаемость, удобство, применение, универсальность. Все эти характеристики применимы, как в целом ко всей ИС, так и к архитектуре ИС.

3.3.2 Методика оценки архитектуры КИС

Аудит ИС проводится на основании различных стандартов и методик [12], которые разработаны в основном за рубежом. Среди зарубежных методик оценки ИС следует остановиться на стандарте COBIT. Данный стандарт нацелен на аудит ИТ с точки зрения бизнеса, поэтому финансовые и стратегические критерии занимают в нем значительно место. Кроме этого, в стандарте COBIT делается акцент на оценку процессов аудита ИТ в совокупности всех процессов.

Тем не менее, не существует такой методики оценки, которая учитывала бы специфику разрабатываемой архитектуры КИС с акцентом на управление ЭД и движение ЭД в рамках КИС, а также оценивающей архитектуру с точки зрения жизнеспособности. Поэтому в данной работе будет применена методика оценки архитектуры КИС, базирующаяся на стандартах качества ИС [15] COBIT, а также обеспечивающая оценку архитектуры со стороны жизнеспособности.

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

Таким образом, перед формированием требований целесообразно провести оценку показателя эффективности для проектируемой архитектуры КИС. Формируя показатели обратимся не только к стандарту COBIT, а также к ГОСТ Р ИСО/МЭК 12207-2010, стандарту определяющему ЖЦ ИС, в частности к разделу описывающему процесс проектирования архитектуры.

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

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

2. Выстроить иерархию целей, поддерживающих бизнес-цель (предусмотреть ИТ-цели, цели процесса, цели действий).

3. Выделить выходы процессов всех уровней.

4. Скоординировать все выходы и процессы относительно друг друга.

5. Для каждого процесса определить показатели оценки результативности и эффективности, на основании которых будет выполняться оценка.

6. Определить важность каждого критерия, используя метод анализа иерархий, внутри группы целей.

7. Посчитать суммарные значения, сделать выводы.

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

3.2 Формирование требований к разрабатываемой архитектуре

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

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

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

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

Требования к функциональной архитектуре: архитектура КИС на объектах автоматизации должна состоять из ряда подсистем, представляющих собой совокупность модулей, подсхем данных, компонент доступа к этим данным и компонент логики управленческих и деловых процессов. Основные функции системы должны делиться на 5 групп, согласно ЖЦ ЭД (этапы ввода/вывода - одна группа).

Предъявляемые функциональные требования:

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

Требование обеспечивается за счет ввода в информационную модель ЖЦ ЭД блока метаданных.

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

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

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

- Все помещенные в КИС материалы должны автоматически индексировать по атрибутам и содержанию, что впоследствии упростит поиск документов и информации в архиве.

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

- Благодаря применению авторизации на уровне объектов каждый объект содержания, версия и представление содержания, а также каждый контейнер (объект, содержащий другие объекты), начиная с папок и заканчивая репозиториями, должен управляться средствами КИС в течение всего жизненного цикла документа.

Система безопасности архитектуры КИС должна обеспечивать решение следующих задач:

- целостность (предотвращение возможности несанкционированных изменений электронных документов);

- конфиденциальность (разграничение прав доступа к электронным документам);

- аутентичность (подтверждение авторства электронных документов);

- юридическая значимость.

Юридическая значимость документов обеспечивается с помощью использования сертифицированных средств криптозащиты информации (СКЗИ) - электронно-цифровой подписи (ЭЦП).

Должны обеспечиваться:

- идентификация и проверка подлинности субъекта доступа при входе в систему по паролю условно-постоянного действия;

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

- регистрация входа (выхода) субъектов доступа в систему (из системы);

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

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

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

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

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

Полнотекстовые индексы КИС должны обеспечивать функциональность интеллектуального поиска, как по атрибутам объектов содержания, так и по тексту внутри файлов содержания с учетом семантики русского языка. Необходимо обеспечить возможность полнотекстовой индексации по основным офисным форматам документов (doc, pdf, xls и др.).

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

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

3.3 Проектирование архитектуры КИС

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

- концептуальный уровень;

- логический уровень;

- физический уровень.

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

3.3.1 Проектирование концептуального уровня архитектуры КИС

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

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

Поставщик сервисов обеспечивает реализацию и описание сервиса. Реестр сервисов содержит информацию о существующих сервисах. А потребителем сервисов в свою очередь, являться такой компонент системы, который нуждается в функциональных возможностях поддержки своих бизнес-целей сервисом того или иного поставщика. Кроме того, потребитель сервиса при обращении к реестру для нахождения описания сервиса может напрямую использовать универсальный идентификатор ресурса (URI). Схема взаимодействия компонентов ИС изображена на рис. 3.1. Цифрами обозначена последовательность этапов взаимодействия.

Рис. 3.1 Схемы взаимодействия компонентов ИС в концепции СОА

Обращая внимание на то, что в проектируемой архитектуре должна учитываться возможность использования семантических технологий, вышеописанная модель может быть усовершенствована с учетом особенностей семантических технологий. В семантической схеме взаимодействия компонентов, определим следующие моменты: a) поставщик сервиса регистрирует в реестре описание в обычном и онтологическом формате; b) потребитель сервиса передает в реестр запрос и онтологическое описание запроса. С учетом этих изменение, схема семантического взаимодействия компонентов ИС примет вид, изображенный на рис. 3.2.

Рис. 3.2 Схема семантического взаимодействия компонентов ИС в концепции СОА

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

Переход к семантической модели СОА вызван наличием недостатков технологий, участвующих во взаимодействии поставщика и потребителя сервисов. В работе [3] обозначены следующие недостатки технологий: спецификация WSDL (Web Services Description Language) - язык описания Web-сервисов и доступа к ним. Основан на языке XML, использующаяся для описания сервисов, жестко регламентирует формат сообщений, используемые протоколы и адрес, по которому находятся сервисы, и не позволяет отразить семантику; реестр UDDI (Universal Description Discovery & Integration) - инструмент для расположения описания Web-сервисов для последующего их поиска слабо интегрируется в существующие ИС и не содержит семантики, необходимой потребителям сервисов.

В связи с вышеперечисленными недостатками технологий, применяющихся в архитектуре СОА, в семантической модели СОА для придания описания сервиса семантической окраски будет использоваться расширение WSDL в виде описания на языке OWL-S. На рис. 3.3 отображены стандартная и семантическая модели СОА КИС с использующимися технологиями.

Рис. 3.3 Модели СОА КИС: a) Стандартная модель СОА КИС, b) Семантическая модель СОА КИС

Рассмотрим модели СОА КИС более подробно. Уровень потребителей сервисом в семантической модели отличается от стандартной наличием OWL описания запроса. Для обмена информацией между потребителями сервисов и сервисами по транспортному протоколу HTTP используется протокол SOAP, являющийся рекомендованным и самым широко используемым коммуникационным протоколом для Web-сервисов. На уровне сервера ИС включает в себя такие компоненты как:

- корпоративная сервисная шина (Enterprise Service Bus, ESB), отвечающая за взаимодействие элементов ИС (клиентов и сервисов);

- реестр сервисов, хранящий данные о предоставляемых поставщиками сервисах, а также содержащий информацию о бизнес-процессах, находящихся в ИС;

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

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

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

Уровень поставщиков сервисов в семантической модели отличается от стандартной тем, что вместе с WSDL-файлом описания сервиса поставщик передает OWL-S описание (онтологию сервиса), в то время как в стандартной модели WSDL-файл - это единственный вариант описания сервиса.

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

3.3.2 Проектирование логического уровня архитектуры КИС

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

Поскольку, в рамках данной работы, архитектура КИС ориентируется на управление ЭД, все технологии совершенствования направлены на изменение концепции работы ИС с документами. Естественно, что документы, данные и знания в компаниях хранятся в электронной среде в виде корпоративной памяти [19]. Целесообразно рассмотреть структуру корпоративной памяти в архитектуре КИС на трех уровнях: онтологический уровень (т.к. было принято решение о выборе онтологического подхода семантических технологий), содержательный уровень, уровень физического хранения (см. табл. 3.1). Уровень физической хранения является более детальным и относится к этапу проектирования физического уровня архитектуры, поэтому в данном разделе будут рассмотрены первые два уровня корпоративной памяти.



Таблица 3.1. Структура корпоративной памяти

№ п/п	Уровень	Данные	Знания	Документы
1	Онтологический уровень	Метаданные	Онтологии	Структура архивов
2	Содержательный уровень	Справочники, каталоги	Правила выбора	Отчеты, методики, технологии
3	Уровень программной реализации	БД, файлы, Web-страницы	Базы знаний	Электронные документы, чертежи и др.

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

Описав форматы представления и хранения данных, целесообразно перейти к уровню бизнес-логики архитектуры (см. рис. 3.4).

Рис. 3.4 Уровень бизнес-логики архитектуры КИС

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

Кроме уровня бизнес-логики, на этапе формирования логического уровня архитектуры, необходимо выделить уровень инфраструктуры (см. рис. 3.5).

Рис. 3.5 Уровень инфраструктуры архитектуры КИС

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

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

К числу функциональных модулей архитектуры относятся такие модули, которые удовлетворяют функциональным и техническим требованиям, предъявляемым к архитектуре и входящие в рамки ЖЦ ЭД (исключая хранение и вывод из ИС). Функциональные модули КИС с составляющими подсистемами перечислены ниже.

1. Ввод документов в ИС (модуль ввода):

a) подсистема распознавания образов;

b) подсистема обработки форм;

c) подсистема аннотирования;

d) подсистема индексирования;

e) подсистема категоризации.

2. Обеспечение сохранности документов (модуль безопасности):

a) подсистема идентификации пользователей;

b) подсистема контроля версиями;

c) подсистема контроля доступа к контенту;

d) подсистема контроля взаимоисключений.

3. Управление (модуль управления):

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

b) подсистема управления записями;

c) подсистема управления web-контентом;

d) подсистема управления электронной почтой;

e) подсистема управления цифровыми активами.

4. Доставка (модуль доставки):

a) подсистема интеграция контента;

b) подсистема выборки;

c) подсистема синдикации;

d) подсистема локализации;

e) подсистема публикации.