Разработка системы электронного документооборота

 















Выпускная квалификационная (дипломная) работа

Разработка системы электронного документооборота



Введение


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

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

Целью дипломной работы является автоматизация деятельности кафедры математического моделирования с помощью СЭД.


1.Системы электронного документооборота


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

Рынок СЭД в последние годы является одним из самых динамично развивающихся сегментов отечественной ИТ-индустрии. Потребителями технологий электронного документооборота являются различные по масштабу и специфике деятельности организации. Традиционно ключевым потребителем СЭД остается государственный сектор. По данным экспертов, порядка 30% проектов по внедрению технологий электронного документооборота приходится на государственные учреждения. При этом важно, что именно интерес со стороны государства стал основой устойчивости рынка СЭД, который даже в условиях кризиса получил существенный импульс развития. Электронный документооборот был назван ключевым элементом концепции «электронного правительства», реализация которой должна способствовать устранению бюрократических препон при взаимодействии государства, населения и бизнеса, а также снижению коррупции. В качестве особенности реализации проектов в органах государственной власти и крупных государственных институтах стоит отметить повышенные требования к информационной безопасности. Речь идет о построении (разработке) на базе тиражируемых программных продуктов защищенных систем электронного документооборота [3].


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

1.1 Решения по разработке СЭД


Выбирая решения класса СЭД, заказчик рассматривает различные варианты: коробочное решение, решение на базе платформы или заказная разработка. Российские разработчики в основном предлагают готовые решения, а западные выступают в качестве поставщиков платформ, на базе которых реализуются проектные решения и заказные разработки. По статистике в структуре рынка на долю российских разработчиков приходится порядка 95% от общего количества проектов по внедрению СЭД. Одним из объяснений является то, что в России до сих пор сильна специфика работы с документами, основывающаяся на отечественных традициях управления [4].

Стоит отметить, что ряд поставщиков начали предоставлять СЭД заказчикам в режиме SaaS (Software as a Service), но пока данный подход в силу целого ряда причин (доверие к провайдеру, качество и надежность каналов связи) скорее рассматривается как форма знакомства с возможностями системы, а не как реальный подход к автоматизации документооборота.

Одним из формирующихся трендов является использование для работы с документами систем класса ECM (Enterprise content management).content management (ECM) - управление информационными ресурсами предприятия или управление корпоративной информацией [2].

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


1.2 Государственные инициативы вокруг «Электронного документа»


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

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


1.3 Стандарты в области СЭД


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

?ГОСТ Р 51141-98. Делопроизводство и архивное дело. Термины и определения (утв. постановлением Госстандарта РФ от 27 февраля 1998 г. №28);

?Федеральный закон от 10 января 2002 г. №1-ФЗ «Об электронной цифровой подписи» (в ред. от 08.11.2007);

?ГОСТ Р 6.30-2003. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов (утв. постановлением Госстандарта РФ от 3 марта 2003 г. №65-ст);

?Постановление Правительства РФ от 22 сентября 2009 г. №754 «Об утверждении Положения о системе межведомственного электронного документооборота»;

?Федеральный закон от 27 июля 2006 г. №149-ФЗ «Об информации, информационных технологиях и о защите информации».

При реализации проектов по внедрению СЭД, в случае работы с персональными данными необходимо руководствоваться требованиями Федеральных законов от 27 июля 2006 г. №152-ФЗ «О персональных данных» и от 27 декабря 2009 г. №363-ФЗ «О внесении изменений в статьи 19 и 25 Федерального закона «О персональных данных».

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


1.4 Проблемы современных систем электронного документооборота и некоторые подходы к их решению


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

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

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

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

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

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

В связи с тенденцией массового подключения к СЭД бизнес-пользователей наблюдается нарастание проблемы удобства работы различных категорий пользователей в системе. Эксплуатационную эффективность СЭД следует оценивать с двух точек зрения. С одной стороны, она определяется временем отклика системы на различные действия (запросы) пользователей (быстродействие). С другой, - тем, насколько удобно и эффективно пользователь может сформулировать свои запросы к системе, адресовать их и получить адекватный ответ. (В стандарте ISO DIS 9241-11 определяется понятие «юзабилити» как степень, в которой продукт может быть использован определенными пользователями при определенном контексте использования для достижения определенных целей с должной эффективностью, отдачей и удовлетворением.) Однако разные категории участников документооборота по-разному работают с документами. Способы работы бизнес-пользователей ключевым образом отличаются от подходов, например, менеджеров СЭД. Поэтому и критерии удобства, комфортности, удовлетворенности у разных пользователей разные.

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

Федеративная топология СЭД

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

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

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

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

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

Рассмотрим более детально особенности построения федеративной СЭД.

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

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

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

Федеративность на уровне пользователей

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

Федеративная архитектура СЭД позволяет справиться с этой проблемой за счет создания распределенной системы динамических персональных коллекций документов (ПКД).

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

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

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

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

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

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

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

?регистрацию документа (без участия пользователя);

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

?создание поручения по поручению по документу;

?передачу в СЭД проекта документа и его согласование (запуск процесса согласования в СЭД и возврат статуса его завершения);

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

?фиксацию факта исполнения поручения;

?постановку на контроль поручения;

?снятие с контроля поручения;

?создание и доставку внутреннего документа по внешнему документу;

?запрос о состоянии документа / процесса;

?публикацию документа;

?передачу документа в архивный модуль.

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

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

Контекстное документированное электронное взаимодействие

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

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

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

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

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

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

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

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

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


1.5 Сравнение существующих систем электронного документооборота


С технической точки зрения, предметная область, которую автоматизируют средства документооборота, крайне проста. Если смотреть «по-крупному», любая система документооборота - это всего лишь хранилище неструктурированных документов [7]. Поэтому все системы без исключения реализуют следующие функции и могут быть охарактеризованы по следующим основным параметрам:

?централизованное хранение документов,

?карточка документа,

?безопасность,

?версионность,

?поиск,

?уведомления,

?маршруты и задания пользователям,

?интеграция с электронной почтой,

?архивирование,

?распределенная структура хранилища,

?интерфейс,

?сканирование и распознавание,

?поддержка.


Таблица 1 - Сравнение карточек документов СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumЕсть возможность создания и настройки видов карточек. Одна карточка - один файл [8].Escom.docНеограниченная возможность создания любых дополнительных атрибутов карточек: полей, полей-справочников, полей ссылок, подчинённых справочников, ролей и т.д. Встроенные средства разработки позволяют не только редактировать существующие объекты и таблицы СУБД, но и создавать новые, устанавливать между ними связи, создавать вычисляемые поля, запросы и подзапросы, серверные обработки (сценарии).Optima-WorkFlowДля создания новых или модификации существующих электронных регистрационных карточек (ЭРК) применяется визуальный дизайнер макетов форм ЭРК. При проектировании макета формы ЭРК на ее страницах (закладках) размещаются соответствующие конкретным свойствам документа «поля карточки» различных типов. Кроме этого, при проектировании макета ЭРК на нем можно размещать поля, являющиеся сложными функциональными элементами управления, т.е. целые функциональные интерфейсные блоки для работы. Для хранения файлов любых форматов поставляется специальное приложение, представляющее собой контейнер данных. Количество файлов в контейнере не ограничено, файлы могут быть размещены по папкам и обрабатываться как композитный документ [11].Гран-ДокВ системе созданы различные типы регистрационно-контрольных форм для различных видов документов (письменных обращений граждан, служебной корреспонденции, директивных документов, устных обращений граждан и организаций и т.д.), отличающиеся друг от друга набором реквизитов. В каждой регистрационно-контрольной форме может храниться любое количество файлов, относящихся к документу [12].Е1 ЕВФРАТПрисутствует встроенный инструментарий (Дизайнер форм, Дизайнер маршрутов, Менеджер журналов и отчётов) для адаптации системы под требования организации [13].ЛетографВозможно создать несколько типов карточек документов и определить для каждой карточки уникальный набор атрибутов. Шаблон документа представляет собой перечень атрибутов различных видов, а также html-шаблоны отображения карточки. Сразу после создания, без запуска дополнительных скриптов карточка может быть использована. Существует возможность создания дополнительных реквизитов для карточек документов. Для каждого шаблона возможно определить любое количество атрибутов. Сразу после добавления атрибута пользователи увидят изменения карточки. Существует возможность хранения нескольких файлов для одной карточки документа. Несколько файлов могут быть присоединены к карточке документа как один или несколько атрибутов. При этом ведется контроль версий / изменений по каждому из них [14].

Таблица 2 - Сравнение безопасности СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumСистема обеспечивает доступ к документам строго в соответствии с назначенными правами пользователей. Тексты документов могут быть дополнительно зашифрованы с помощью паролей или цифровых сертификатов. Все действия, производимые пользователем над документом (чтение, изменение, подписание), протоколируются.Escom.docСуществует возможность настройки безопасности для типов документов. Предусмотрено разграничение доступа для каждого экземпляра карточки. Кроме того, в карточке предусмотрено разграничение доступа для каждого атрибута, а также предусмотрена возможность динамического скрытия страниц карточки в зависимости от текущего этапа процесса и той роли, которую выполняет текущий пользователь. Карточки экземпляров бизнес-процессов доступны (видны) только тем сотрудникам, которые имеют к ним отношение - являются ролями в данном процессе. Однако в зависимости от настроек процесса, карточка на определённом этапе может быть не доступна сотрудникам, участникам предыдущих этапов.Optima-WorkFlowЗа счет комбинации прав доступа и функциональных полномочий реализуется настройка уровней защиты информации на соответствие матрице доступа, утвержденной в установленном порядке. Используются профили (ролевые группы) пользователей системы. Функциональные полномочия и права на доступ / редактирование / адресацию документов могут быть назначены как всему профилю, так и конкретному пользователю. Все действия и события фиксируются в журнале аудита. Также хранится история изменения значений реквизитов карточек с указанием старого и нового значения, даты и времени изменения, автора изменения.Гран-ДокПредоставляет распределенную среду для ввода, хранения и обеспечения доступа к информации (вид документа, документ, зона документа, зона регистрационно-контрольной формы, поле документа). Каждый пользователь системы имеет статус: группа или персона. Для персоны фиксируются имя и пароль для входа в систему «Гран-Док», а также полное имя, под которым он будет присутствовать в списках пользователей. Для группы определяется только полное имя. Группа служит элементом гибкости и «натуральности» при определении наследования прав. Несмотря на то, что могут быть определены группы, наследование можно устанавливать от любого пользователя к любому другому вне зависимости от статуса этих пользователей. Система следит за тем, чтобы в иерархии наследования не возникло логических противоречий. Полные права пользователя определяются как суперпозиция личных и наследуемых прав. Возможность хранения информации по изменению значений реквизитов осуществляется в модуле администрирования системы. Возможна настройка перечня реквизитов, изменение которых отслеживается. Ведется протоколирование действий пользователей и администраторов при работе в системе.Е1 ЕВФРАТСуществует разграничение прав доступа. Используется механизм ролей.ЛетографСуществует возможность разграничения прав доступа (чтение, изменение, изменение прав, удаление) к различным объектам системы, документам и их атрибутам. Также предоставляется возможность ограничения доступа к любому объекту системы, разграничение доступа как к объекту в целом, так и к атрибуту объекта, разграничение доступа в зависимости от этапов маршрута движения документа и др.

Таблица 3 - Сравнение версионности СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumКаждый документ может иметь неограниченное количество версий. При этом версии одного и того же документа могут быть в разных форматах (например.doc и.pdf). Версия электронного документа отражает актуальность его содержимого. Каждая версия может находиться в одном из состояний жизненного цикла: в разработке, действующая, устаревшая.Escom.docФункция реализуется с помощью автоматической записи события изменения реквизита в специальный журнал, который ведётся для большинства объектов автоматически (карточки бизнес-процессов). Для объектов нормативно-справочной информации может быть реализован тот же принцип, по запросу заказчика. Реализуется с помощью встроенных в систему средств.Optima-WorkFlowКаждый сеанс обработки документа завершается созданием новой версии документа. Таким образом, поддерживается полная версионность изменений документа.Гран-ДокСистема предоставляет возможность хранения нескольких версий файлов.Е1 ЕВФРАТК сожалению, «Евфрат» не дает возможности отслеживать получение и возврат документов (check-out, check-in) и хранение версий, что может усложнить коллективную работу с документами.ЛетографВ системе ведется журналирование всех действий пользователей и изменений данных. Специальная компонента позволяет просмотреть в документе все изменения, которые были в нем произведены. Существует возможность хранения версий файлов.

Таблица 4 - Сравнение поиска в СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumСпециализированный поиск электронных документов, используя: предопределенные поиски (например, «Мои последние измененные документы»). Дополнительный поиск по часто используемым критериям, специально настроенный администраторами. Возможность задания для любого документа связанных с ним по смыслу или логике документов и перехода от одного связанного документа к другому, включая его собственные связанные документы.Escom.docПредусмотрен поиск по реквизитам карточки документа. Предусмотрен поиск по содержанию документа. Поиск с учетом морфологии русского языка возможен при установке для СУБД дополнительного ПО, например «Следопыт».Optima-WorkFlowПоддерживается поиск по всем реквизитам карточки и атрибутам документа. При установке сервера индексирования и поисковой машины ABBYY Retrieval&Morphology Engine 4.0, доступен полнотекстовый контекстный поиск с учетом морфологии 26 национальных языков. Также поддерживается поиск по образцу карточки. Возможно совместное применение атрибутивного и контекстного поиска. Поддерживается поиск по штрих-коду.Гран-ДокПоиск осуществляется по любым реквизитам документа (зона документа, зона исполнителей, зона сопроводительных писем, зона резолюции). Возможен поиск по содержанию: текстовым полям регистрационно-контрольной формы (корреспондент, содержание, текст поручения и т.д.), а также по содержанию прикрепленных электронных образов документов. Во всех вариантах поиска есть возможность найти документ по целому слову или его части (контексту).Е1 ЕВФРАТДополнительные поиски по часто используемым критериям, специально настроенные администраторами. Возможность задания для любого документа связанных с ним по смыслу или логике документов и перехода от одного связанного документа к другому, включая его собственные связанные документы.ЛетографПоиск по реквизитам карточки документа. Поиск по содержанию документа. Поиск с учетом морфологии русского языка.

Таблица 5 - Сравнение способов уведомлений в СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumВозможность существует.Escom.docОповещения пользователей осуществляются при изменении карточки документа. Реализуется с помощью встроенных в систему средств. Встроенная подсистема сообщений мгновенно уведомляет участников процессов о различных событиях, происходящих с процессом, а также о наступлении заданных сроков: задача поставлена, подходит срок завершения задачи, задача выполнена, задача просрочена и т.п.Optima-WorkFlowПоддерживаются как системные, так и почтовые оповещения при наступлении различных событий: при поступлении документа на обработку, приближении срока обработки, по истечении нормативного срока обработки документа, постановки поручения, наступлении срока исполнения поручения, завершении исполнения поручения и др.Гран-ДокСистема предусматривает возможность оповещения пользователей при внесении данных в регистрационно-контрольную форму.Е1 ЕВФРАТНет данных. Скорее всего, такая возможность есть.ЛетографФункционал «Подписка» позволяет пользователю получать оповещения об изменении и перемещении документа.

Таблица 6 - Сравнение маршрутов и заданий пользователям в СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumВозможно создавать типовые маршруты (например, «Согласование договора»). Механизм типовых маршрутов является инструментом для автоматизированного создания задач в соответствии с заданными бизнес-правилами любой сложности. С помощью типового маршрута автоматически задается список исполнителей (в т.ч., на основе ролей), могут заполняться любые поля задачи (например, текст или тема), считывается информация из вложений и связанных объектов (задач, подзадач, электронных документов, справочников). Анализ загруженности сотрудников может осуществляться через различные отчеты. Также учет отработанного времени возможен благодаря интеграции с ERP-системами. Являясь реализацией бизнес-ориентированного workflow, механизм типовых маршрутов включает в себя все средства, необходимые для настройки процессов любой сложности. При этом настройку маршрутов может осуществлять непосредственно бизнес-аналитик без участия программиста.Escom.docСистема позволяет создавать экземпляры имеющихся в системе классов бизнес-процессов, а также конструировать (разрабатывать) свои классы с последующей возможностью создания экземпляров их карточек.Optima-WorkFlowИмеется графический редактор моделей процессов, который позволяет осуществить визуальную разработку не только маршрутных схем движения конкретного документа, но и технологические схемы «переработки» одних документов в другие. Работы могут выполняться как последовательно, так и параллельно. Возможны возвраты и циклы последовательностей работ. Для сложных моделей можно применять методы декомпозиции, когда операция процесса в свою очередь является полноценным процессом, имеющим собственную модель реализации. Для построения статистической и аналитической отчетности используются средства широко распространенного генератора отчетов Business Object Crystal Reports 11. Run-Time библиотеки, осуществляющие генерацию отчетов на основе ранее спроектированных макетов форм отчетности, входят в комплект поставки. В состав СЭД входит специализированное приложение «Диспетчер процессов», которое позволяет в реальном времени осуществлять мониторинг хода выполнения деловых процессов. Это приложение позволяет визуально отмечать текущее положение документа в модели процесса, сопоставлять план-факт длительности исполнения работ на отдельных этапах процесса, формировать хронологическое описание работ, выполненных в рамках процесса. Все длительности определяются на основе календаря рабочего времени.Гран-ДокСистема не предусматривает создания бизнес-процессов, но возможна интеграция с системой «Управление процессами» обеспечивающей перечисленные выше возможности.Е1 ЕВФРАТ«Графический дизайнер маршрутов» позволяет проектировать типовые процессы обработки документов в организации; «Менеджер журналов и отчетов» позволяет создавать новые шаблоны журналов и отчетов для осуществления анализа деятельности организации.ЛетографСистема позволяет настроить любые маршруты движения документов: последовательные, параллельные, жестко заданные и «свободные», при которых дальнейшее движение документа определяется пользователем, у которого этот документ в данный момент находится. Кроме этого, в маршрутах могут быть заданы правила, позволяющие в зависимости от значения атрибутов карточки документа, направить его по определенной ветке маршрута. Поддерживает удобные визуальные маршрутные листы для быстрого определения местоположения документа в маршруте согласования, а также фиксации времени нахождения документа на каждом этапе. Система предоставляет пользователям удобный функционал по построению аналитических отчетов. Для реализации данной возможности не используются внешние средства. Пользователь, обладая соответствующими правами доступа, может самостоятельно осуществлять настройку необходимых ему отчетов. Для настройки статистического отчета достаточно выбрать шаблон отчета, а также поля, которые будут отображаться в отчете и функцию, которую будет выполнять отчет. Процесс похож на настройку сводного отчета в MS Excel.

Таблица 7 - Сравнение возможностей интеграции с электронной почтой в СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumИнтеграция с Microsoft Outlook позволяет не только сохранять пришедшие письма и их вложения как документы Directum, но и оправлять письма контактными лицам из единой адресной книги Directum, а также регистрировать контакты в модуле «Управление взаимодействием с клиентами».Escom.docИнтеграция с электронной почтой предусмотрена.Optima-WorkFlowРеализована интеграция с системами электронной почты, поддерживающими стандартные почтовые протоколы SMTP и IMAP4/POP3.Гран-ДокПредусмотрена возможность обмена сообщениями между пользователями с использованием встроенной почты. Система интегрирована с почтовым клиентом MS Outlook для оповещения пользователей о поступлении документа.Е1 ЕВФРАТВозможность существует. Встроенный почтовый клиент.ЛетографВозможность существует. Система может выполнять функции клиента электронной почты, импортировать почтовые сообщения и формировать электронные сообщения на основании документов.

Таблица 8 - Сравнение архивирования в СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumСлужбы файловых хранилищ Directum Storage Services позволяют хранить документы как в базе данных SQL-сервера, отличающегося простотой администрирования и высокой производительностью, так и в файловых хранилищах, что практически неограниченно расширяет доступное для хранения документов пространство и обеспечивает потоковый доступ.Escom.docДля этого предусмотрен специальный процесс «Архивный документ». При наступлении определённого этапа карточка бизнес-процесса может быть помещена во внутренний архив системы и классифицирована для поиска, для учёта мест хранения и для учёта сроков хранения.Optima-WorkFlowРеализованы методы архивирования путем вымещения документов во внешнее хранилище данных. Процесс может выполняться автоматически по расписанию и применяться к документам, отвечающим определенным условиям.Гран-ДокСистема предусматривает списание документа в дело, но ведение архива документов не осуществляется. Возможна интеграция с информационной системой «Электронный архив».Е1 ЕВФРАТДополнительный модуль «Архивариус» предоставляет средства автоматизации процессов списания и долговременного хранения документов, вышедших из оперативного обращения. Модуль поддерживает принятую в организации номенклатуру дел, а также поддерживает связь с оперативными документами.ЛетографАрхивные документы хранятся непосредственно в системе. Доступ к документам осуществляется как к обычным документам. Благодаря тому, что все документы перед размещением в системе проходят автоматическую процедуру индексирования, скорость поиска информации не зависит от объема хранимых данных.

Таблица 9 - Сравнение распределенных структур хранилищ СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumМеханизм репликации позволяет работать в едином информационном пространстве даже территориально распределенным компаниями. Система работает на нескольких (главных и вторичных) серверах. Частота сеансов связи определяется потребностями организации в актуализации данных (от одного раза в сутки до нескольких раз в час); между сеансами связи каждый сервер работает независимо. Таким образом, обеспечивается высокая отказоустойчивость системы: при временном выходе из строя одного из серверов или пропадании связи другие серверы продолжают работать в обычном режиме.Escom.docНетOptima-WorkFlowПоддерживает возможность создание решений с распределенными базами данных.Гран-ДокНаличие GUI-интерфейса. Реализован дружелюбный пользовательский интерфейс, основанный на механизмах многоуровневых меню и панелей инструментов. Предусмотрен также удаленный доступ к данным с использованием WEB-интерфейса.Е1 ЕВФРАТВозможна поддержка территориально распределённой работы благодаря наличию подсистемы обмена документами.ЛетографСистема предоставляет возможность создания территориально распределенных и многосерверных решений.

Таблица 10 - Сравнение интерфейсов СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumНаличие двух способов работы пользователей с системой: через desktop-клиент и через WEB-клиент (с помощью WEB-браузера). При работе с сервером WEB-доступа Directum можно использовать любой удобный браузер (Internet Explorer, Firefox, Opera).Escom.docТолько GUIOptima-WorkFlowНаличие GUI-интерфейса. Реализованы пользовательские интерфейсы с учетом требований к эргономике и технической эстетике. Наличие WEB-интерфейса.Гран-ДокНаличие GUI-интерфейса. Реализован дружелюбный пользовательский интерфейс, основанный на механизмах многоуровневых меню и панелей инструментов. Предусмотрен также удаленный доступ к данным с использованием WEB-интерфейса.Е1 ЕВФРАТИспользуется протокол обмена данными TCP/IP, что позволяет вести работу в системе с удаленного компьютера посредством Internet/Intranet-сетей. Модуль «HTTP-сервер» дает возможность пользователям получать доступ к документам и поручениям при помощи WEB-браузера из любой точки мира.ЛетографДоступ к системе осуществляется с любого WEB-браузера и не требует установки на рабочей машине пользователя никакого дополнительного программного обеспечения.Таблица 11 - Сравнение возможностей сканирования и распознавания СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumСпециализированные службы ввода документов Directum Capture Services обеспечивают массовый ввод документов со сканеров, МФУ («сендеров»), а также с факсов, из папок файловых систем, электронной почты и т.д. Интеграции со средствами распознавания образов нет.Escom.docИнтеграция со сканерами (интегрирована в карточку бизнес-процесса). Интеграция со средствами распознавания образов (предусмотрена интеграция с внешним ПО).Optima-WorkFlowПоддерживается возможность создания документа путем сканирования бумажной копии используя функциональность системы с автоматическим распознаванием текста. Для организации потокового сканирования и распознавания поставляется специализированное приложение. Для сканирования и распознавания используются средства продукта ABBYY Fine Reader Scripting Edition.Гран-ДокРеализована технология потокового сканирования документов и создания электронных образов оригиналов, их хранения и использования в системе. Распознавание образов осуществляется в рамках технологии потокового сканирования.Е1 ЕВФРАТНаличие встроенных средств сканирования и распознавания объектов с поддержкой поточного сканирования. Уникальная технологическая разработка - Drag&Recog (распознавание «на лету»), а также встроенный модуль просмотра и печати.ЛетографВозможна интеграция со сканерами. Сканирование документа может быть инициировано прямо из системы (TWAIN). Возможна интеграция со средствами распознавания образов. Для решения задачи распознавания преимущественно используются серверные продукты ABBYY (FineReader, FormReader, Reconition Server).

Таблица 12 - Сравнение поддержки СЭД

СИСТЕМАХАРАКТЕРИСТИКИDirectumНабор средств интеграции Directum Integration Toolset позволяет интегрировать систему с уже существующими на предприятии системами и решениями, в том числе с ERP-системами, включая «1С». Лежащий в основе системы инструмент разработки IS-Builder, будучи открытым и предметно-ориентированным, соответствует обоим требованиям и имеет ряд преимуществ перед другими инструментами разработки. Открытость IS-Builder позволяет адаптировать систему к специфическим нуждам организации, развивать функциональность системы и проводить ее интеграцию с другими системами, в том числе, силами программистов заказчика. Предметная ориентация IS-Builder позволяет легко развивать высокоэффективные прикладные возможности системы, абстрагируясь от конкретных технических деталей их реализации.Escom.docСуществует возможность доработки системы. Существует возможность предоставления исходного кода. Системы интегрирована с офисными приложениями MS Widows, MS Office. Система не интегрирована с приложениями CAD/CAM. Предусмотрена возможность интеграции с «1С».Optima-WorkFlowСозданные решения на платформе Optima-WorkFlow могут расширяться и дорабатываться как в части функциональности, так и в части автоматизации новых бизнес-процессов. Система интегрирована с приложениями MS Office. За счет наличия интерфейса межпрограммного взаимодействия (API), документированной структуры хранения данных и встроенных средств запуска программируемых сценариев, разработанных на языках VB или J-Script, могут быть разработаны любые сценарии межсистемной интеграции или синхронизации данных.Гран-ДокВозможна доработка системы в соответствии с требованиями заказчика. Интегрирована с офисными приложениями Microsoft Word, Microsoft Excel, MS Outlook. Не предусматривает интеграцию с приложениями CAD/CAM. Не предусматривает интеграцию с «1С».Е1 ЕВФРАТИмеет клиент-серверную архитектуру. Благодаря «HTTP-серверу» и модулю АРМ «Руководитель» доступ к системе может осуществляться через Интернет. Наличие подсистемы обмена документами позволяет организовать территориально-распределённую работу. В качестве базы данных используется СУБД собственной разработки - НИКА, которая поставляется вместе с продуктом. Имеется открытый API для создания интеграционного программного обеспечения на платформе системы.ЛетографИнтегрирована с офисными приложениями Office (Word, Excel, и т.д.), Acrobat. Интегрирована с приложениями CAD/CAM: AutoCAD, AutoDesk, SolidWorks. Существует возможность интеграции с «1С». Обеспечивается возможность мониторинга и синхронизации данных документов и справочников, организация сквозных бизнес-процессов. Существует возможность доработки системы. Решение может быть развито за счет использования типовых решений, а также дополнено силами специалистов исполнителя по проекту или силами специалистов внутренней команды внедрения, прошедшими обучение по программе «Системный технолог Летограф». Система не требует изменения программного кода, необходимая функциональность настраивается. Заказчик может самостоятельно модифицировать систему: добавлять и изменять справочники, карточки документов, маршруты, а также создавать интеграционные решения. Заказчику предоставляется конфигурация решения, а также исходный код интеграционных решений. В силу того, что приложение имеет только WEB-интерфейс, интеграция с клиентскими приложениями достаточно затруднительна.

2.Постановка задачи

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

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

Основные особенности разрабатываемой СЭД кафедры:

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

-централизованный сбор и обмен документами;

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

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


3.Реализация приложения СЭД


В качестве средства реализации СЭД, была выбрана СУБД MS Access [15] из пакета MS Office 2003, как самое доступное и известное средство на кафедре математического моделирования. Также было принято во внимание, что основным программным средством для оформления текстов курсовых и дипломных работ является MS Word.


3.1 Модель данных общей части СЭД


С учетом требований к разрабатываемой СЭД, было принято решение разбить систему на две составляющие: общая часть и пользовательская. Каждая из частей представляет собой отдельное приложение в MS Access. На рисунке 1 представлена схема данных общей части СЭД.


Рисунок 1 - Схема данных общей части СЭД


В таблицах 13 - 17 описаны поля данных созданных таблиц.


Таблица 13 - Таблица «Документ»

Имя поляТип данныхОграниченияКод документаСчетчикПервичный ключДата отправкиДата/времяОбязательное полеДата полученияДата/времяОписание документаПоле MEMOДокументПоле объекта OLEОбязательное полеОтправительЧисловойВнешний ключПолучательЧисловойВнешний ключГруппаЧисловойВнешний ключ

Таблица 14 - Таблица «Пользователь»

Имя поляТип данныхОграниченияКод пользователяСчетчикПервичный ключКлюч пользователяТекстовый (255)Обязательное полеФ.И.О.Текстовый (100)Обязательное полеТип пользователяЧисловойВнешний ключ

Таблица 15 - Таблица «Группа пользователей»

Имя поляТип данныхОграниченияКод группыСчетчикПервичный ключНазвание группыТекстовый (50)

Таблица 16 - Таблица «Тип пользователя»

Имя поляТип данныхОграниченияКод типа пользователяСчетчикПервичный ключНаименование типаТекстовый (50)Обязательное поле

Таблица 17 - Таблица «Список группы»

Имя поляТип данныхОграниченияКод группыЧисловойПервичный ключКод пользователяЧисловойПервичный ключ

3.2 Модель данных пользовательской части СЭД


Схема данных пользовательской части СЭД представлена на рисунке 2.


Рисунок 2 - Схема данных пользовательской части СЭД


Отличие представленных таблиц от таблиц общей части СЭД заключается в дополнительной таблице «Отправитель» (таблица 18), которая хранит код пользователя локальной части СЭД и замене типа данных «Счетчик» на «Числовой» для возможности записи данных из общей части в пользовательскую.


Таблица 18 - Таблица «Отправитель»

Имя поляТип данныхОграниченияКод отправителяЧисловойПервичный ключ

3.3 Интерфейс общей части СЭД


Доступ к данным в общей части СЭД реализован через главную кнопочную форму, представленную на рисунке 3.


Рисунок 3 - Главная кнопочная форма общей части СЭД


Через главную кнопочную форму можно редактировать, добавлять и удалять: типы пользователей (рисунок 4), группы пользователей (рисунок 5), вести списки групп пользователей (рисунок 6), пользователей (рисунок 7).


Рисунок 4 - Форма «Тип пользователей»

Рисунок 5 - Форма «Группа пользователей»


Рисунок 6 - Форма «Список группы»


Рисунок 7 - Форма «Пользователь»


Через форму «Пользователь», нажатием на кнопку «Создать файл базы данных пользователя», создается пользовательская часть СЭД, представленная файлом «kmm_user.mdb», с записью всех переданных документов текущему пользователю. Программный код, выполняющий перечисленные действия вынесен в приложение А. В дальнейшем, этот файл передается пользователю. Общая часть СЭД представлена файлом «kmm.mdb», к которому подключается пользовательская часть в процессе работы пользователя. Файл «kmm.mdb» должен храниться на компьютере кафедры и иметь следующее расположение «C:\Program Files\СЭД». Файл «kmm_user.mdb» можно хранить в любом месте.

Список документов пользователей представлен на рисунке 8.


Рисунок 8 - Форма «Документ»


Документ на форме, представленной на рисунке 8, можно открыть, редактировать, сохранить.


.4Интерфейс пользовательской части СЭД


Главная кнопочная форма пользовательской части СЭД, представлена на рисунке 9.


Рисунок 9 - Главная кнопочная форма пользовательской части СЭД


Через главную кнопочную форму можно посмотреть список входящих документов (рисунок 10) или отправить документ другому пользователю (рисунок 11).


Рисунок 10 - Форма «Список входящих документов пользователя»


Рисунок 11 - Форма «Список исходящих документов»

Заключение


В результате проделанной работы были изучены возможности, предоставляемые современными системами электронного документооборота. Разработана СЭД для кафедры математического моделирования с учетом поставленных требований. СЭД состоит из двух частей: общей и пользовательской, которые реализованы в виде приложений в СУБД MS Access. Из общей части можно создавать пользовательскую часть СЭД и редактировать общие данные. С помощью пользовательской части СЭД можно получать документы от других пользователей и отправлять свои, через подключение к общей части.


Список использованных источников


1.Обзор систем электронного документооборота URL: #"justify">Приложение А

Sub Create_file_DB_Click()dbs As DAO. Database, rst, rstCurrent, rstTable As DAO. RecordsetQuerySQL As String


' Открываем базу пользователяdbs = DBEngine. OpenDatabase («C:\Program Files\СЭД\kmm_user.mdb», True)rst = dbs. OpenRecordset («Документ»)

'Удаляем все записи из таблицы «Документ»

With rstWhile Not.EOFWith

rst = dbs. OpenRecordset («Отправитель»)

'Удаляем все записи из таблицы «Отправитель»

With rstWhile Not.EOFWith

rst = dbs. OpenRecordset («Список группы»)

'Удаляем все записи из таблицы «Список группы»

With rstWhile Not.EOFWith

rst = dbs. OpenRecordset («Группа пользователей»)

'Удаляем все записи из таблицы «Группа пользователей»

With rstWhile Not.EOFWith

rst = dbs. OpenRecordset («Пользователь»)

'Удаляем все записи из таблицы «Пользователь»

With rstWhile Not.EOFWith

rst = dbs. OpenRecordset («Тип пользователя»)

'Удаляем все записи из таблицы «Тип пользователя»

With rstWhile Not.EOFWith

rstCurrent = CurrentDb. OpenRecordset («Тип пользователя»)rst = dbs. OpenRecordset («Тип пользователя»)

'Переписываем все записи из текущей таблицы «Тип пользователя»

With rstWhile Not rstCurrent.EOF

! [Код типа пользователя] = rstCurrent. Fields («Код типа пользователя»).Value

! [Наименование типа] = rstCurrent. Fields («Наименование типа»).Value

Update=.LastModified. MoveNext. Close. CloseWith

rstCurrent = CurrentDb. OpenRecordset («Пользователь»)rst = dbs. OpenRecordset («Пользователь»)

'Переписываем все записи из текущей таблицы «Пользователь»

With rstWhile Not rstCurrent.EOF

AddNew

! [Код пользователя] = rstCurrent. Fields («Код пользователя»).Value

If rstCurrent. Fields («Код пользователя»).Value = UserNum. Value Then

! [Ключ пользователя] = rstCurrent. Fields («Ключ пользователя»).ValueIf

! [Ф.И.О.] = rstCurrent. Fields («Ф.И.О.»).Value

! [Тип пользователя] = rstCurrent. Fields («Тип пользователя»).Value

Update=.LastModified. MoveNext. Close. CloseWith

rstCurrent = CurrentDb. OpenRecordset («Группа пользователей»)

Set rst = dbs. OpenRecordset («Группа пользователей»)

'Переписываем все записи из текущей таблицы «Группа пользователей»

With rstWhile Not rstCurrent.EOF

! [Код группы] = rstCurrent. Fields («Код группы»).Value

! [Название группы] = rstCurrent. Fields («Название группы»).Value

Update=.LastModified. MoveNext. Close. CloseWith

rstCurrent = CurrentDb. OpenRecordset («Список группы»)rst = dbs. OpenRecordset («Список группы»)

'Переписываем все записи из текущей таблицы «Список группы»

With rstWhile Not rstCurrent.EOF

! [Код группы] = rstCurrent. Fields («Код группы»).Value

! [Код пользователя] = rstCurrent. Fields («Код пользователя»).Value

Update=.LastModified. MoveNext. Close. CloseWith

rst = dbs. OpenRecordset («Отправитель»)

'Добавляем код пользователя в таблицу «Отправитель»rst

! [Код пользователя] = UserNum. Value=.LastModifiedWith


QuerySQL = «SELECT Документ.*» + _

«FROM Пользователь, Документ, [Список группы]» + _

«WHERE (Документ. Группа=[Список группы]. [Код группы]) And» + _

«([Список группы]. [Код пользователя]=Пользователь. [Код пользователя]) And» + _

«(Пользователь. [Код пользователя]=» + CStr (UserNum. Value) +»);»rstCurrent = CurrentDb. OpenRecordset(QuerySQL)rst = dbs. OpenRecordset («Документ»)

'Переписываем все записи групповых документов в таблицу «Документ»

With rstWhile Not rstCurrent.EOF

! [Код документа] = rstCurrent. Fields («Код документа»).Value

! [Дата отправки] = rstCurrent. Fields («Дата отправки»).Value

! [Дата получения] = rstCurrent. Fields («Дата получения»).Value

! [Описание документа] = rstCurrent. Fields («Описание документа»).Value

! [Документ] = rstCurrent. Fields («Документ»).Value

! [Отправитель] = rstCurrent. Fields («Отправитель»).Value

! [Получатель] = rstCurrent. Fields («Получатель»).Value

! [Группа] = rstCurrent. Fields («Группа»).Value=.LastModified. MoveNext. Close. CloseWith

= «SELECT Документ.*» + _

«FROM Пользователь, Документ, Пользователь AS Пользователь_1» + _

«WHERE (Пользователь_1. [Код пользователя]=Документ. Получатель) And» + _

«(Пользователь. [Код пользователя]=Документ. Отправитель) And» + _

«(Пользователь_1. [Код пользователя]=» + CStr (UserNum. Value) +»);»rstCurrent = CurrentDb. OpenRecordset(QuerySQL)rstTable = CurrentDb. OpenRecordset («Документ»)rst = dbs. OpenRecordset («Документ»)

'Переписываем все записи личных документов в таблицу «Документ»

With rstWhile Not rstCurrent.EOF

! [Код документа] = rstCurrent. Fields («Код документа»).Value

! [Дата отправки] = rstCurrent. Fields («Дата отправки»).Value


If IsNull (rstCurrent. Fields («Дата получения»).Value) Then. Index = «PrimaryKey». Seek «=», Val (rstCurrent. Fields («Код документа»).Value). Edit

rstTable! [Дата получения] = Now

! [Дата получения] = rstTable! [Дата получения]. Update. Bookmark = rstTable. LastModified

! [Дата получения] = rstCurrent. Fields («Дата получения»).ValueIf

! [Описание документа] = rstCurrent. Fields («Описание документа»).Value

! [Документ] = rstCurrent. Fields («Документ»).Value

! [Отправитель] = rstCurrent. Fields («Отправитель»).Value

! [Получатель] = rstCurrent. Fields («Получатель»).Value

! [Группа] = rstCurrent. Fields («Группа»).Value=.LastModified. MoveNext. Close. Close. CloseWith


' Закрываем базу. Closedbs = Nothing

Sub


Приложение Б

Sub Form_Load()dbs As DAO. Database, rst, rstCurrent, rstTable As DAO. RecordsetQuerySQL As StringUserNum As Long


' Открываем базу администратора

Set dbs = DBEngine. OpenDatabase («C:\Program Files\СЭД\kmm.mdb», True)

rstCurrent = CurrentDb. OpenRecordset («Тип пользователя»)rst = dbs. OpenRecordset («Тип пользователя»)

'Переписываем все записи из текущей таблицы «Тип пользователя»

With rstCurrentWhile Not rst.EOF= «PrimaryKey»«=», Val (rst. Fields («Код типа пользователя»).Value)

If. NoMatch Then

! [Код типа пользователя] = rst. Fields («Код типа пользователя»).Value

! [Наименование типа] = rst. Fields («Наименование типа»).Value

Update=.LastModifiedIf. MoveNext. Close

Set rstCurrent = CurrentDb. OpenRecordset («Пользователь»)rst = dbs. OpenRecordset («Пользователь»)

'Переписываем все записи из текущей таблицы «Пользователь»

With rstCurrentWhile Not rst.EOF= «PrimaryKey»«=», Val (rst. Fields («Код пользователя»).Value). NoMatch Then

! [Код пользователя] = rst. Fields («Код пользователя»).Value

! [Ключ пользователя] = rst. Fields («Ключ пользователя»).Value

! [Ф.И.О.] = rst. Fields («Ф.И.О.»).Value

! [Тип пользователя] = rst. Fields («Тип пользователя»).Value

Update=.LastModifiedIf. MoveNext. CloseWith

rstCurrent = CurrentDb. OpenRecordset («Группа пользователей»)

Set rst = dbs. OpenRecordset («Группа пользователей»)

'Переписываем все записи из текущей таблицы «Группа пользователей»

With rstCurrentWhile Not rst.EOF= «PrimaryKey»«=», Val (rst. Fields («Код группы»).Value). NoMatch Then

! [Код группы] = rst. Fields («Код группы»).Value

! [Название группы] = rst. Fields («Название группы»).Value

Update=.LastModifiedIf. MoveNext. CloseWith

rstCurrent = CurrentDb. OpenRecordset («Список группы»)rst = dbs. OpenRecordset («Список группы»)

'Переписываем все записи из текущей таблицы «Список группы»

With rstCurrentWhile Not rst.EOF= «PrimaryKey»«=», Val (rst. Fields («Код группы»).Value). NoMatch Then

! [Код группы] = rst. Fields («Код группы»).Value

! [Код пользователя] = rst. Fields («Код пользователя»).Value

Update=.LastModifiedIf. MoveNext. CloseWith

rstCurrent = CurrentDb. OpenRecordset («Отправитель»)

'Считываем код пользователя из таблицы «Отправитель»

With rstCurrent=! [Код пользователя]With

= «SELECT Документ.*» + _

«FROM Пользователь, Документ, [Список группы]» + _

«WHERE (Документ. Группа=[Список группы]. [Код группы]) And» + _

«([Список группы]. [Код пользователя]=Пользователь. [Код пользователя]) And» + _

«(Пользователь. [Код пользователя]=» + CStr(UserNum) +»);»

Set rstCurrent = CurrentDb. OpenRecordset («Документ»)rst = dbs. OpenRecordset(QuerySQL)

'Переписываем все записи групповых документов в таблицу «Документ»

With rstCurrentWhile Not rst.EOF= «PrimaryKey»«=», Val (rst. Fields («Код документа»).Value). NoMatch Then

! [Код документа] = rst. Fields («Код документа»).Value

! [Дата отправки] = rst. Fields («Дата отправки»).Value

! [Дата получения] = rst. Fields («Дата получения»).Value

! [Описание документа] = rst. Fields («Описание документа»).Value

! [Документ] = rst. Fields («Документ»).Value

! [Отправитель] = rst. Fields («Отправитель»).Value

! [Получатель] = rst. Fields («Получатель»).Value

! [Группа] = rst. Fields («Группа»).Value=.LastModifiedIf. MoveNext. CloseWith


QuerySQL = «SELECT Документ.*» + _

«FROM Пользователь, Документ, Пользователь AS Пользователь_1» + _

«WHERE (Пользователь_1. [Код пользователя]=Документ. Получатель) And» + _

«(Пользователь. [Код пользователя]=Документ. Отправитель) And» + _

«(IsNull (Документ. [Дата получения])) And» + _

«(Пользователь_1. [Код пользователя]=» + CStr(UserNum) +»);»

Set rstCurrent = CurrentDb. OpenRecordset («Документ»)rstTable = dbs. OpenRecordset («Документ»)rst = dbs. OpenRecordset(QuerySQL)

'Переписываем все записи личных документов в таблицу «Документ»

With rstCurrentWhile Not rst.EOF= «PrimaryKey»«=», Val (rst. Fields («Код документа»).Value). NoMatch Then

! [Код документа] = rst. Fields («Код документа»).Value

! [Дата отправки] = rst. Fields («Дата отправки»).Value


rstTable. Index = «PrimaryKey». Seek «=», Val (rst. Fields («Код документа»).Value). Edit

rstTable! [Дата получения] = Now

! [Дата получения] = rstTable! [Дата получения]. Update. Bookmark =.LastModified

! [Описание документа] = rst. Fields («Описание документа»).Value

! [Документ] = rst. Fields («Документ»).Value

! [Отправитель] = rst. Fields («Отправитель»).Value

! [Получатель] = rst. Fields («Получатель»).Value

! [Группа] = rst. Fields («Группа»).Value=.LastModifiedIf. MoveNext. Close. CloseWith


' Закрываем базу. Closedbs = Nothing

Sub

Sub Form_AfterInsert()dbs As DAO. Database, rst, rstCurrent, rstTable As DAO. RecordsetQuerySQL As String


' Открываем базу администратораdbs = DBEngine. OpenDatabase («C:\Program Files\СЭД\kmm.mdb», True)

= «SELECT * FROM Документ» + _

«WHERE [Код документа]=0;»rstCurrent = CurrentDb. OpenRecordset(QuerySQL)rstTable = CurrentDb. OpenRecordset («Документ»)rst = dbs. OpenRecordset («Документ»)

'Переписываем все записи личных документов в таблицу «Документ»

With rst

! [Дата отправки] = rstCurrent. Fields («Дата отправки»).Value

! [Описание документа] = rstCurrent. Fields («Описание документа»).Value

! [Документ] = rstCurrent. Fields («Документ»).Value

! [Отправитель] = rstCurrent. Fields («Отправитель»).Value

! [Получатель] = rstCurrent. Fields («Получатель»).Value

! [Группа] = rstCurrent. Fields («Группа»).Value=.LastModified. Index = «PrimaryKey». Seek «=», Val(0). Edit! [Код документа] =! [Код документа]

rstTable. Update. Bookmark = rstTable. LastModified. Close. CloseWith


' Закрываем базу. Closedbs = NothingSub

Sub Form_BeforeInsert (Cancel As Integer)rstCurrent As DAO. Recordset

rstCurrent = CurrentDb. OpenRecordset («Отправитель»)

'Считываем код пользователя из таблицы «Отправитель»

With rstCurrent. Value =! [Код пользователя]With

Sub


Выпускная квалификационная (дипломная) работа Разработка системы электронного документооборота

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ