От работ - к документам, от документов - к работам

Большая роль документов в управлении проектами известна. Поэтому именно в области управления документами интеграция программных средств управления проектами с другими приложениями - идея наиболее понятная и востребованная

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

В данной статье мы рассматриваем одно конкретное направление интеграции, а именно со средствами управления документами. Значительная роль документов в процессах управления проектами известна. Так, международный стандарт качества управления проектами [2] выделяет специальную группу процессов, связанных с распространением информации и «обеспечивающих создание, сбор, распространение, хранение и конечное изъятие информации по проекту». Наш собственный опыт разработки СУП и общения с потенциальными заказчиками показывает, что идея интеграции наиболее понятна и востребована именно в области управления документами проекта.

Пример — «Процедура согласования документации и приемки работ в крупном проекте»

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

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

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

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

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

Шаг 2. В случае мотивированного отказа в согласовании исполнитель выполняет необходимые работы по корректировке документов. Исправления по замечаниям должны оформляться исполнителем путем перевыпуска документа.

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

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

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

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

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

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

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

Таким образом, в этом случае анализ информации идет по направлению от работ к документам.

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

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

Подчеркнем также, что, как видно из рассмотренного примера, большое значение в проектах имеет организация совместной работы над документами, то есть значение имеют не только традиционные функции управления документами — поддержание версий документов и истории работы с ним, ведение архива, авторизация доступа, поддержание связей между документами, или EDMS-функции (EDMS — Enterprise Document Management System, система управления документами предприятия). Может быть, даже большее значение приобретают функции управления движением документов и контроля сроков их исполнения (workflow-функции). Анализ функций таких систем и подход к их проектированию см. в [3].

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

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

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

Lotus Notes

Наверное, впервые идея интеграции средств планирования проекта и управления документами была реализована в системе Lotus Notes (производитель — Lotus Development Corporation). Эта система с самого начала, еще в эпоху ее реализации на OC 360, предназначалась для хранения документации и сообщений, которыми обмениваются члены проектной группы по ходу реализации проекта. Однако дальнейшее развитие этой системы пошло по пути усиления функций почтовых услуг и возможностей совместной работы, поэтому в настоящее время Lotus Notes выступает просто как один из возможных кандидатов на роль обслуживающей документарной подсистемы.

Primavera Enterprise

Система Primavera Enterprise (производитель — Primavera Systems) предназначена для автоматизации основных функций управления проектами. Для поддержки документарного аспекта управления проектами в составе Primavera Enterprise имеются две возможности.

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

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

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

Open Plan

Система Open Plan (производитель — Welcom Software Technology) предназначена для автоматизации основных функций управления проектами. Судя по названию, Open Plan просто обязан обеспечивать интеграцию с любым другим открытым продуктом и не должен выполнять никаких функций, чуждых собственно управлению проектами. Наш личный опыт общения с Open Plan, к сожалению, ограничен, и мы вынуждены основываться только на сведениях, полученных на презентациях этого продукта. Как утверждается, с рабочего места Open Plan можно вызвать систему управления документами LanDocs (система автоматизации делопроизводства и ведения архива электронных документов, производитель — компания ЛАНИТ). Это обеспечивает существенно больший уровень открытости, чем предоставляется, например, со стороны Primavera Enterprise, и позволяет предположить, что более глубокая интеграция Open Plan с системами управления документами (на уровне установки связей между документами и работами) также возможна и не потребует чрезмерных усилий.

Documentum

Система Documentum 4i (производитель — Documentum, Inc.) — универсальная система автоматизации управления документами и деловыми процессами в масштабах крупных корпораций. Documentum решает задачу интеграции систем управления документами и проектами с использованием технологии проектного портала в рамках специального продукта, поставляемого как отдельный компонент. Благодаря базовым возможностям Documentum у пользователей имеется мощная машина по управлению документами и workflow. С помощью проектного портала пользователь имеет возможность не только сохранять переписку, возникающую по ходу проекта, но эффективно использовать данные из базы MS Project 2000, включая такие привлекательные возможности, как автоматическая генерация описания бизнес-процесса на основании плана проекта и корректировка последнего в случае возникновения задержек на каких-либо из его этапов.

Небольшой комментарий

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

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

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

• собственно системы управления проектами, ядром которой выступает обычно профессиональный планировщик работ проекта (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.

Рис. 4. Регистрационная карточка документа

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

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

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

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

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

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

Перспективные направления развития

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

1. Усиление использования базовых возможностей систем управления документами. При развитии системы следует привлекать все большее количество возможностей, заложенных в штатный функции СУД. Например, при планировании проекта нам кажется целесообразным заранее привязывать к работе шаблон того документа, который должен явиться результатом ее выполнения. Очевидно, что при этом также должна быть обеспечена возможность автоматической привязки к работе документа, выполненного на основе заданного шаблона.
2. Усиление возможностей коллективной работы. Вполне реально обеспечить автоматическую генерацию проектов организационно-распорядительных документов (например, приказа о назначении сотрудника на работу), сохранение этих документов в библиотеке и рассылку с помощью средств электронной почты или средств workflow. По окончании некоторой работы работник, выполняющий следующую работу, может также получить ссылки на документы или копии документов, необходимых ему для выполнения этой работы.
3. Сокращение трудоемкости регистрации документов. Возможно обеспечить такую настройку системы, которая минимизирует количество операций поиска и выбора проектов (задач) при регистрации вновь созданного документа.
4. Расширение информационной базы связей. Возможно обеспечить привязку документов не только к проектам и работам, но и к другим объектам MS Project, например к ресурсам, назначениям, этапам и т. д.
5. Развитие технологий управления документами. Выше мы рассматривали возможность интеграции MS Project c системой DOCS Open, которая реализована в традиционной двухуровневой технологии клиент-сервер. Эта архитектура по-прежнему обеспечивает работу большинства пользователей и гарантирует минимальную трудоемкость работ при интеграции продуктов. Однако надо рассматривать возможность и необходимость выполнения интеграционных работ с продуктами, реализованными в трехуровневой архитектуре (поставляются в составе продуктовой линейки Docs Fusion, например в PowerDocs или CYBERDocs).

Резюмируя сказанное

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

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

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

Технология выполнения интеграционных работ может базироваться на достаточно общем подходе, пример которого был приведен в нашей статье. Однако сами интеграционные работы, по всей видимости, придется выполнять заново для каждой конкретной пары интегрируемых систем (Docs Open + Open Plan, Documentum + Primavera и т. д.), и, в значительной степени, для каждого нового заказчика. Очевидно, что критическим фактором при выполнении таких работ является опыт интеграции сложных пакетов и понимание сущности решаемых ими задач.

Литература

1. Ципес Г. Система управления проектами: интеграционный подход // Директору информационной службы, декабрь 2000.
2. Менеджмент качества. Руководство качеством при управлении проектами. ИСО/ТО 10006:1997. М.: НТК "Трек", 1999.
3. Бейдер А., Кэйв Р. О некоторых подходах к управлению документами // Открытые системы. 1998. № 3.

Об авторах