Место и роль документов в управлении на современном этапе

Автор работы: Пользователь скрыл имя, 27 Февраля 2011 в 11:33, реферат

Описание работы

Наши представления о месте системы управления проектами (СУП) в ИТ-структуре предприятия были сформулированы в [1]. Там же была показана вытекающая из этих представлений необходимость интеграции программного обеспечения управления проектами с другими пакетами прикладных программ, используемыми на предприятии для различных целей — для управления документами, персоналом и т. д., вплоть до ERP-системы.

Файлы: 1 файл

Большая роль документов в управлении проектами известна.doc

— 139.50 Кб (Скачать файл)

Архитектура интегрированного комплекса 

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

собственно системы  управления проектами, ядром которой выступает обычно профессиональный планировщик работ проекта (Primavera Enterprise, Оpen Рlan, MS Project и т. д.);

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

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

Планировщик мы рассматриваем  как основную (базовую) систему, а  системы управления документами  и workflow — как вспомогательные, обслуживающие (см. рис. 2). При этом следует указать  на то, что разделение систем на управляющие документами и процессами в значительной степени условно и отражает только существенное различие рассматриваемых функций. В зависимости от выбранной платформы эти функции могут быть представлены либо в рамках единой системы (например, Documentum 4i), либо как обособленные, глубоко специализированные программные системы. Примерами последних могут служить Docs Open / Docs Fusion, универсальная система автоматизации управления документами в масштабах средних и крупных корпораций (производитель — Hummingbird Ltd.), и Eastman Enterprise Workflow, система автоматизации управления бизнес-процессами (производитель — Eastman Software, Inc.).

Новое качество интегрированного решения 

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

Контроль и мониторинг 

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

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

Организация совместной работы 

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

Все современные  системы управления workflow — например, Documentum, Panagon Products (FileNET Corporation), Compaq Work Expeditor (Compaq Computer Corporation) — включают графические средства проектирования маршрутных схем либо по крайней мере относительно простые интерактивные программы («визарды», или «мастера»), обеспечивающие автоматизацию заполнения настроечных таблиц системы маршрутизации, как в DocsRout (компания «Весть», в настоящее время — «Весть-Метатехнология»). Средства построения шаблонов процессов, применения механизмов ролей и синонимов являются высокопрофессиональными инструментами (которые, увы, реализованы далеко не во всех упомянутых системах) — они позволяют обеспечить повторное использование выполненных ранее разработок, минимизировать затраты на адаптацию и сопровождение разработанных ранее маршрутных схем. 

Для лучших систем этого  класса, имеющих открытый интерфейс (Documentum, Compaq Work Expeditor), интеграторы обычно стараются обеспечить автоматическое формирование маршрутной карты бизнес-процесса на основании внешних схем, например описаний бизнес-процессов, экспортированных из системы ARIS (IDS Scheer AG), или плана проекта, сформированного в MS Project. 

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

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

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

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

Обратный поиск 

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

Так, используя только возможности системы управления документами, пользователи смогут выполнять  поиск документов, предъявляя в качестве поисковых атрибутов наименования проектов и/или этапов работ. Более  того, при применении специальных  средств визуализации структуры архива типа модуля «Смотритель Архива для DOCS Open» (разработан А. Бейдером) пользователи смогут увидеть полное логическое дерево взаимосвязей между проектами, этапами и работами и соответствующими документами (см. рис. 3).

Рис. 3. Пример связей, отображаемых «Смотрителем архива»

 

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

Какую систему выбрать, или Почему надо ориентироваться  на открытые системы 

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

Рассматривая возможные  решения среднего масштаба, мы остановились на MS Project и Docs Open, поскольку они обладают достаточной открытостью и функциональностью. Кроме того, наши исследования показали, что интеграция между MS Project и Docs Open принципиально возможна и не должна вызвать больших затруднений. Обе системы используют промышленные реляционные базы данных, структуры данных этих систем подробно документированы, системы используют схожие механизмы для доступа к данным. В таблице приведены возможности интеграции, доступные в этих системах.

Интеграция —  существующая и планируемая 

MS Project — это обычное офисное приложение, которое в наиболее распространенных случаях хранит проектные данные в файлах. В свою очередь, эти файлы могут сохраняться не в традиционной файловой структуре, а в корпоративном хранилище документов, функционирующем под управлением системы Docs Open, и извлекаться для обработки по запросу пользователя. Доступ к документам контролируется системой безопасности Docs Open, поддерживаются версии документов, обеспечивается многопользовательский доступ к документам и т. д. Файлы проектов могут отображаться вместе с другими документами в рамках единой иерархии бизнес-объектов хранилища, например, в контексте «заказчик — проект — задача - документ» в случае применения программных средств типа «Смотрителя архива». 

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

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

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

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

Интеграция на уровне данных 

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

наличие документа (приказа, распоряжения и т. п.) является условием начала работы;

наличие документа (например, в состоянии "утвержден") является критерием окончания работы;

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

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

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

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

Механизм реализации ссылок на внешние таблицы зависит от особенностей организации баз данных интегрируемых систем. Кроме того, указанные таблицы должны проектироваться с учетом возможности описания их в словаре данных Docs Open. В результате реализации модели и после выполнения работ по регистрации данных в словаре данных Docs Open, во-первых, проектные данные MS Project будут видимы для системы Docs Open и, во-вторых, проектные данные смогут служить в качестве справочника при заполнении регистрационных карточек документов в Docs Open. Пример карточки документа, в которой использованы такие возможности, приведен на рис. 4. чивающих интеграцию конкретных систем.

Интеграция на уровне VBA (Visual Basic for Application) 

Необходимо разработать  две группы программных модулей. 

1) Со стороны MS Project необходимо разработать модули, которые будут управлять вызовами  интеграционных функций при работе  пользователя в среде MS Project и  обеспечивать по крайней мере:

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

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

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

актуализацию состояния  таблицы экземпляров связей ("задача - документ") при удалении работы;

перенос связей при создании нового проекта на основе текущего;

переход к редактированию связанного документа непосредственно  с рабочего места MS Project, минуя (визуально) Docs Open.  

2) Со стороны Docs Open необходимо разработать модули, которые будут управлять вызовами интеграционных функций при работе пользователя в среде Docs Open и обеспечивать по крайней мере:

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

Информация о работе Место и роль документов в управлении на современном этапе