Международный стандарт качества управления проектами (ISO 10006:1997) предъявляет высокие требования к процедурам документирования и контроля обоснован­ности управленческих решений, устанавливая, таким образом, существенные взаимо­связи между работами и документами.

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

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

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

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

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

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

• собственно системы управления проектами, ядром которой выступает обычно про­фес­сиональный планировщик работ проекта (Primavera Project Planer, Оpen Рlan, MS Project и т.д.);
• системы управления документами, решающей задачи ведения архивов документов, ведения версий, разграничения доступа, и другие специальные задачи своего класса;
• системы управления бизнес - процессами, решающей задачи определе­ния маршрутов движения документов в процессе их жизненного цикла, перемещения документов по выбранному маршруту, контроля сроков исполнения документа на каждом этапе, а также другие специальные задачи.

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

При этом следует указать на то, что разделение систем на управляющие документами и процессами является в значительной степени условным, и отражает только существенное различие рассматриваемых функций. В зависимости от выбранной платформы эти функции могут быть представлены либо в рамках единой системы (например, Documentum 4i), либо как обособленные глубоко специализированные программные системы (например, Docs Open и Eastman).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интеграция на уровне VB/VBA

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

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

• Установку связи выбранной задачи (проекта) с документом или удаление этой связи;
• Просмотр списка документов, привязанных к выбранной задаче (проекту);
• Изменение типа привязки документов к задаче;
• Актуализацию состояния таблицы экземпляров связей при удалении документа;
• Перенос связей при создании нового проекта на основе текущего;
• Переход к редактированию связанного документа непосредственно с рабочего места MS Project.

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

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