· возможность автоматизации процессов хранения и списания документов в архив;

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

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

интеграция с электронной почтой: регистрация писем из электронной почты в системе «ЕВФРАТ-Документооборот»; отправка документов по электронной почте внешним адресатам с использованием адресных книг почтовых программ;

регистрация документов - облегчение труда делопроизводителя: регистрация нового документа на основе существующего; автоматическая проверка документа на дублирование при его регистрации; поддержка потокового сканирования;

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

возможности администрирования: поддержка работы с иерархическими словарями; организация резервного копирования информационной базы данных по расписанию; работа «ЕВФРАТ-Документооборот Сервер» как сервиса; экспорт/импорт типовых маршрутов, форм документов, шаблонов отчетов; администрирование хранилища форм документов; новый Генератор отчетов [www.evfrat.ru].

Особенностью системы АС «ЕВФРАТ-Документооборот» является ее гибкость и простота настройки, обслуживания и администрирования.

Информации о наличии сертификата соответствия ГСДОУ отсутствует.

Проведенное в аналитическом обзоре исследование подготовлено на основе технических описаний систем, взятых из открытых источников, и тестирования демо-версий программных продуктов «Дело», «Евфрат-Документооборот», «Optima-Workflow». Исследование возможностей систем «Босс-Референт», «CompanyMedia», «LanDocs» проводилось только на основе технических описаний, поскольку компании-разработчики данных систем демо-версии не представляют.

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

Если говорить о выборе СЭД для организации с предполагаемым количеством одновременно работающих пользователей около 50, то наиболее оптимальным решением видится система «ЕВФРАТ-Документооборот», разработка компании Cognitive Technologies. При умеренной стоимости система, с одной стороны, содержит весь необходимый функционал для автоматизации работы с документами, а с другой стороны, предлагает широкие возможности настройки и модификации при внедрении разработчиком, партнерами и непосредственно заказчиками.

2. Анализ и моделирование автоматизируемого процесса

2.1 Выбор базовой программной платформы

2.1.1 Базовая программная платформа

В настоящей работе в качестве базовой программной платформы использованна платформа EMC Documentum. Это решение обусловлено следующими причинами:

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

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

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

2.1.2 Базовая архитектура решения

Архитектура общекорпоративной системы электронного управления документами включает:

ядро системы;

- множество функциональных подсистем.

2.2 Формирование требований к проектируемой системе

2.2.1 Требования к системе в целом

Состав системы. АСУ НТД должна содержать следующие основные функциональные подсистемы:

· централизованное хранилище документов;

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

· подсистему интеграции с прикладными системами;

· подсистему ведения справочников;

· подсистему формирования отчетности;

· подсистему, реализующую бизнес процессы для разработки и утверждения НТД и изменений к ним;

· подсистему, реализующую бизнес процессы для тиражирования НТД и изменений к ним и учета копий;

· подсистему поиска и выдачи аннулированных документов;

· подсистему мониторинга бизнес процессов по работе с документацией.

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

Роли пользователей в системе

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

Приведенный перечень ролей не является окончательным и может изменяться в ходе развития проекта.

Требования к способам и средствам связи

АСУ НТД должна функционировать в вычислительных сетях с использованием протокола передачи данных TCP/IP.

Требования к платформе

· АСУ НТД должна быть построена на платформе Documentum 6.5.

· АСУ НТД должна использовать СУБД Oracle для хранения данных.

Требования к режимам функционирования системы

· АСУ НТД должна поддерживать функционирование в круглосуточном режиме.

· Допускается остановка системы для проведения обслуживания в соответствии с регламентом эксплуатации системы.

2.2.2 Показатели назначения

Требования к приспособляемости системы

· АСУ НТД должна обеспечивать возможность хранения не менее 100 000 документов (плюс их версии), при условии, что используемые устройства хранения данных позволят хранить соответствующий объем информации.

Требования к модернизации и развитию системы

· Архитектура АСУ НТД должна обеспечивать в дальнейшем интеграцию системы в состав единой системы управления документацией на платформе Documentum.

· Архитектура АСУ НТД должна соответствовать базовым принципам построения информационных систем (нормализация данных, модульность, масштабируемость).

2.2.3 Требования к надежности

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

2.2.4 Требования к эргономике и технической эстетике

· АСУ НТД должна обеспечивать дружественный интерфейс пользователя.

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

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

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

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

· Должен быть предусмотрен быстрый поиск по справочникам при выборе значений из справочника.

Требования к технической эстетике

· Пользовательский интерфейс должен обеспечивать возможность работы с разрешением 1024*768 и выше.

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

2.2.5 Требования к обеспечению безопасности

Требования к авторизации и аутентификации

· АСУ НТД должна обеспечивать аутентификацию пользователей в системе с использованием возможностей аутентификации, входящих в состав платформы Documentum.

· АСУ НТД должна обеспечивать авторизацию действий пользователей с учетом ролей, исполняемых пользователями в системе.

Требования к защите информации от несанкционированного доступа

· АСУ НТД должна позволять назначать разные уровни доступа для документа и приложений к нему. По возможности, система должна самостоятельно выставлять права доступа на документы в зависимости от состояний их жизненных циклов и операций, подлежащих выполнению над ними.

· АСУ НТД должна поддерживать все механизмы защиты информации от несанкционированного доступа, встроенные в платформу Documentum.

Требования к протоколированию операций, выполняемых системой

Должен вестись системный журнал, протоколирующий операции, выполняемые системой.

2.2.6 Требования по сохранности информации

· АСУ НТД должна поддерживать полное резервное копирование информации в условиях останова Системы и восстановление информации из резервной копии.

2.3 Требования к функциям системы

2.3.1 Требования к подсистеме «Централизованное хранилище документов»

Требования к структуре архива

Подробные сведения о требованиях к структуре архива см. в приложении ХХХХ.

Требования к организации учета документов

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

· Любая версия документа, побывавшая актуальной, т.е. действовавшей на КУМЗ в течение некоторого времени, не может быть удалена пользователями из системы (кроме пользователя - администратор).

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

· Система должна обеспечивать автоматизированную процедуру актуализации документации.

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

· Должна обеспечиваться возможность совместной работы пользователей над документами с помощью механизма блокировок (Check-in/Check-out) при наличии у пользователей соответствующих прав доступа.

· Исполнители должны видеть в системе общедоступные (опубликованные) документы и те документы, которые находятся у них в работе, а также предыдущие версии этих документов.

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

Требования к доступу к документам

Доступ пользователей к документам может осуществляться через:

· Иерархию папок.

· Контрагентов. Любой документ, связанный с контрагентом может быть доступен через список контрагентов;

· Подразделений - держателей подлинников;

· Систему поиска;

Требования к поиску документов

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

Требования к организации ввода действующих (либо зарегистрированных) документов

Подробные сведения о требованиях к организации ввода действующих (либо зарегистрированных) документов смотри в приложении ХХХ

Требования к организации ввода действующих (либо зарегистрированных) изменений к документам

Подробные сведения о требованиях к организации ввода действующих (либо зарегистрированных) изменений к документам смотри в приложении ХХХ

Требования к вводу в систему действующих (либо зарегистрированных) извещений об аннулировании НД

Подробные сведения о требованиях к организации ввода действующих (либо зарегистрированных) извещений об аннулировании НД смотри в приложении ХХХ

Требования к вводу в систему действующих актов о проведении ревизии

При вводе в систему действующего акта о проведении ревизии выполняется последовательность действий, описанная в приложении ХХХ:

2.3.3 Требования к подсистеме ведения справочников

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

2.3.4 Требования к подсистеме формирования отчетности

· Подсистема формирования отчетности должна позволять формировать перечни действующих НД на момент составления перечня.

· Подсистема должна позволять сохранять сформированные перечни в хранилище.

2.3.5 Требования к подсистеме, реализующей бизнес процессы для разработки и утверждения НТД и изменений к ним

Общие положения

· Процедуры, описанные в данном разделе, характеризуют порядок прохождения в системе основных бизнес процессов от создания в системе проекта НД до его регистрации. Также в данном разделе описан процесс от создания до регистрации изменений к НД.

· Операции, описанные в разделах 2.3.5, 2.3.6 реализуются с использованием системы Workflow, являющейся частью архитектуры Documentum 6. Для пользователя система Workflow представляется в виде набора заданий и уведомлений, поступающих в его папку «Входящие». Под «заданием» понимается побуждение пользователя к выполнению заданного действия над набором связанных с заданием документов. Задания для пользователей могут формироваться как другими пользователями, так и системой. Обычно пользователи формируют задания через пункт меню «Действия».

Разработка внутренних НД

Подробные сведения о требованиях к разработке внутренних НД смотри в приложении ХХХ

Подготовка к вводу в действие иностранного НД

Подробные сведения о требованиях к подготовке к вводу в действие иностранного НД смотри в приложении ХХХ

2.3.6 Требования к подсистеме, реализующей бизнес процессы для тиражирования НТД и изменений к ним и учета копий

Уведомление о новых НД либо изменениях к существующим

· Операцию тиражирования НД может инициировать любой сотрудник подразделения-разработчика.

· Сотрудник подразделения-разработчика формирует перечень подразделений для ознакомления с НД либо документом-основанием для внесения изменений.

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

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

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

Уведомления об изменениях

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

Создание и учет контрольных копий

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

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

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

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

2.3.7 Требования к подсистеме поиска и выдачи аннулированных документов

Требования к доступу к документам

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

Доступ пользователей к документам может осуществляться через:

· Контрагентов. Любой документ, связанный с контрагентом может быть доступен через список контрагентов;

· Подразделений - держателей подлинников;

· Систему поиска

2.3.8 Требования к подсистеме мониторинга

Подсистема позволит:

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

· Получать оперативные данные о состоянии исполнительской дисциплины (данные о заданиях в разрезе сотрудников и подразделений) с возможностью фильтрации по типам документов, подразделениям, выполняемым операциям, периоду дат. В том числе, подсистема отдельно выделяет исполнителей (подразделения), у которых имеются задания с нарушенными сроками обработки;

· Получать информацию о состоянии всех сформированных пользователем заданий;

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

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

2.4 Требования к видам обеспечения

2.4.1 Требования к информационному обеспечению

Состав, структура и способы организации данных в системе

· Данные в системе представляются в виде объектов зарегистрированных в хранилище типов.

· Поведение типов данных реализуется в виде Java-классов.

2.4.2 Требования к лингвистическому обеспечению

· Пользовательский интерфейс и вся документация на систему должны быть разработаны на русском языке.

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

2.4.3 Требования к программному обеспечению

Перечень покупных программных средств

АСУ НТД включает следующие покупные программные средства:

· Documentum Content Server 6.5;

· Documentum client Webtop;

· Documentum Administrator;

· Documentum Application Builder;

· Documentum Index Server;

· Documentum Transformation Services.

Требования к операционной системе

АСУ НТД должна функционировать под управлением ОС Windows (2003 Server).

Требования к инфраструктурному программному обеспечению

Для работы АСУ НТД должен использоваться сервер приложений (Apache Tomcat) версии, определенной в Release Notes для используемых продуктов Documentum.

Требования к системе управления базами данных

Система должна использовать СУБД Oracle для хранения атрибутивной и индексной информации.

3. Проектирование информационной системы

3.1 Аналитическая модель для системы АСУ НТД

3.1.1 Общие положения

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

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

3.1.2 Диаграммы классов

Все документы

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

Рисунок 1 - Диаграмма «Все документы»

Описание классов:

- Акт о проведенной ревизии. Содержит ссылки на НД, упомянутые в акте.

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

- ИАД (Информационно-аналитический документ).

- НТД - Нормативный и технический документ.

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

- ОРД - Организационно-распорядительный документ.

- ОРД со ссылкой на НТД - План ОТМ либо ОРД на ввод в действие.

Нормативные документы (НД)

Диаграмма, представленная на рисунке 2, отражает иерархию классов-наследников класса НТД.

Рисунок 2 - Диаграмма «Нормативные документы»

Описание классов:

- Внешний. Отличается от НТД наличием ссылки на контрагента.

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

- Иностранный стандарт. Расширяет понятие Внешнего НД за счет наличия ссылок на оригинал и матрицу соответствия.

- Метод производства. Уточняет понятие "Внутренний НД" за счет наличия возможной ссылки на перевод (либо набор переводов).

- Метод производства поставщика. Уточняет понятие "Внешний НД". Может содержать обозначение документа, присвоенное контрагентом.

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

Исполнение операций

Диаграмма, представленная на рисунке 3, иллюстрирует механизмы, предназначенные для хранения в системе данных о сотрудниках, выполнявших операции над документами.

Рисунок 3 - Диаграмма «Исполнение операций»

Описание классов:

- Исполнитель операции. Данные об исполнителе операции и времени ее выполнения.

- Исполнитель операции внешний. Уточняет понятие "Исполнитель операции". Хранит данные об исполнителе операции, его должности и ссылку на контрагента.

- Исполнитель операции внутренний. Уточняет понятие "Исполнитель операции". Характеризуется наличием ссылки на элемент справочника "Сотрудник и должность", содержащий данные о сотрудники и его должности.

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

Иностранный НД

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

Рисунок 4 - Диаграмма «Иностранный НД»

Описание классов:

- Матрица соответствия. Документ, всегда ссылающийся на иностранный стандарт.

Изменение и аннулирование

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

Рисунок 5 - Диаграмма «Изменение и аннулирование»

Описание классов:

- Извещение об аннулировании. Имеет ссылку на версию НД, подлежащую аннулированию либо уже аннулированную на основании данного извещения.

- Основание для изменений. Обычно это извещение об изменении. До момента публикации содержит ссылку на новую версию НД (ту, которая вводится в действие настоящим документом). После публикации содержит ссылку на измененную версию НД.

Оргструктура

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

Рисунок 6 - Диаграмма «Оргструктура»

Описание классов:

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

- Должность по классификатору. Должность в соответствии с общероссийским классификатором должностей. Идентифицируется кодом должности. Является версионной, т.е. ведется история изменений (например, изменения наименования должности).

- Контрагент - внешняя по отношению к системе организация.

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

- Сотрудник - физическое лицо. Идентифицируется табельным номером. Является версионным.

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

- Элемент трудовой биографии. Расширяет данные об объекте "Сотрудник и должность" посредством хранения периода актуальности данных о должности сотрудника.

3.2 Проектирование пользовательского интерфейса

Работа пользователей в системе происходит посредством браузера. Выбор данного вида взаимодействия обусловлен тем, что он наиболее удобен для пользователя, так как он сможет работать через любой знакомый ему браузер (IE, Opera, Chrome, Firefox, Safari) в любой операционой системе.

На приведенном на рисунке 7 скриншоте показанно, как выглядит интерфейс системы. Это сконфигурированный стандартный интерфейс платформы Documentum для работы с документами, локализованный с учетом предметной области. (Локализация производится с использованием специальных файлов c расширением .properties которые представляют собой набор пар ключ-значение. Таких файлов может быть как угодно много, следовательно, интерфейс может быть переведен на любое количество языков. Язык интерфейса выбирается при входе в систему.)

Рисунок 7 - Общий вид интерфейса системы

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

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

С помощью данного выпадающего списка (показан на рисунке 7) мы можем, например, найти какого-нибудь сотрудника и отредактировать его права.

Интерфейс поиска пользователей выглядит как показанно на рисунке 8.

Рисунок 8 - Интерфейс поиска пользователей

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

Рисунок 9 - Интерфейс карточки пользователя

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

На рисунке 10 представлен интерфейс карточки документа.

Рисунок 10 - Интерфейс карточки документа

Для примера рассматривается карточка документа типа «Иностранный стандарт». На вкладке “Общие” карточки ИС располагаются основные атрибуты документа:

· Обозначение

· Количество изменений

· Количество приложений

· Дата ввода в действие

· Дата проверки

· Наименование

· Держатель (подразделение держатель подлинника документа может быть выбранно из справочника подразделений)

· Фирма (Может быть выбрана из справочника контрагентов)

· ДСП (Для служебного пользования)

· Разделы (разделы к которым относится данный ИС)

· Оригинал на иностранном языке ( Ссылка на документ типа «Оригинал»)

· Переводчик (может быть выбран из справочника пользователей)

· План ОТМ (ссылка на документ типа «План ОТМ»)

· ОРД (ссылка на документ типа «ОРД» который вводит в действие данный ИС)

· Примечание

На вкладке «Матрицы соответствия» находится список матриц соответствия для данного ИС. Название матрицы соответствия является ссылкой на документ типа «Матрица соответствия». При нажатии на данную ссылку мы попадем на карточку данной матрицы соответствия, как показано на рисунке 11.

Рисунок 11 - Интерфейс вкладки «Матрицы соответствия»

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

Рисунок 12 - Интерфейс вкладки «Приложения»

На следующей вкладке, представленной на рисунке 13, располагаются редакции данного ИС.

Рисунок 13 - Интерфейс вкладки «Редакции»

Далее расположены вкладки «Ревизии», «Изменения» По своей структуре они не отличаются от вкладок «Приложения» или «Редакции» и представляют собой таблицы документов определенного типа. Каждая строка такой таблицы является ссылкой на указанный документ.

Вкладка «Ссылочные» представлена н рисунке 14.

Рисунок 14 - Интерфейс вкладки «Ссылочные»

На ней расположены таблицы со ссылками данного документа на другие документы находящиеся в системе и ссылки с других документов на данный документ. Это удобно для поиска связанных документов.

На вкладке «Согласующие», представленной на рисунке 15, отображаются сотрудники, участвующие в БП согласования данного документа.

Рисунок 15 - Интерфейс вкладки «Согласующие»

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

На вкладке «Связи», представленной на рисунке 16, отображаются и настраиваются связи данного документа.

Рисунок 16 - Интерфейс вкладки «Связи»

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

На вкладке «Учетные копии», представленной на рисунке 17, будет расположен список (дерево) подразделений, в которые были отправлены учетные копии данного документа. Кроме того будут указаны номера учетных копий. Но данный список появится только в случае запуска для данного ИС бизнес-процесса «Тиражирование».

Рисунок 17 - Интерфейс вкладки «Учетные копии»

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

На рисунке 18 приведена карточка документа типа «ГОСТ»

Рисунок 18 - Интерфейс карточки типа «ГОСТ»

Для каждого конкретного типа документв атрибуты будут отличаться. Список типов документов и их атрибутов приведен в приложении 1. Дизайн всех карточек выполнен в едином стиле (весь стиль может быть легко изменен путем внесения соответствующих правок в файлы .css ) с использованием стандартных элементов HTML разметки. Кроме того используются сконфигурированные элементы BOF.

Заключение

Проведенные нами исследования и работы по созданию автоматизированной системы управления нормативной и технической документацией (АСУ НТД), позволяют нам сделать ряд выводов и предложений:

1)Актуальность проблемы выбора и внедрения электронного документооборота определяется необходимостью создания на предприятии единого документационного пространства с учетом рационального использования человеческих ресурсов при выполнении определенных делопроизводственных работ.

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

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

- попадание документов и информации, содержащейся в них, третьему лицу;

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

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

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

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

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

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

- непроизводственные затраты рабочего времени на поиск необходимого документа, формирование тематической подборки документов;

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

3)Изучение понятия «системы электронного управления документами» помогло разграничить, в зависимости от характеристики и способов решения делопроизводственных задач, «системы электронного документирования», «системы электронного документооборота», «корпоративные системы электронного управления документами».

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

5)Разработано техническое задание на создание АСУ НТД

6)Была создана автоматизированная система электронного документооборота нормативной и технической документации (АСУ НТД).

При создании АСУ НТД нами были предусмотрены все нюансы работы с документами при внедрении и последующей эксплуатации электронного документооборота.

Размещено на Allbest.ru

...