В статье рассматривается развитие средств пользовательского программирования в SCADA-системе - от решения нестандартных задач управления и контроля на технологическом языке ST до автоматизации процесса проектирования во встроенной среде сценарного языка С#. В продолжение этой линии впервые анонсирована новая среда программирования контроллеров , полностью реализующая требования стандарта МЭК 61131-3 и сохранившая принятую в объектную идеологию, которая обеспечивает удобство и скорость разработки, тиражирование проектных решений.

От «перетащи и брось»

к «напиши и запусти»

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

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

Первым инструментом технологического программирования в рамках стал графический язык схем функциональных блоков. Но это - способ создавать решения, основанные на уже имеющихся библиотеках, а их функционал ограничен даже в условиях постоянного расширения. Решительное развитие необходимого инструментария началось уже в 3-й версии . Библиотека функциональных блоков расширилась блоками пользовательских программ. Были реализованы блоки двух видов - для инженерного программирования на языке ST (стандарт МЭК 61131-3) и для автоматизации разработки проектов или реализации сложных задач на языке C#. Если программы на языке ST работают как на верхнем уровне систем, так и в контроллерах, то программы на С# предназначены исключительно для функционирования в рамках рабочих станций. Поскольку в создается единый проект на всю систему с автоматической организацией связи между ее частями, эту специализацию языков разработчик проекта должен учитывать изначально.

Программирование на языке ST

Язык ST прост для освоения инженерами. Поколениям, выпущенным из вузов в девяностых и нулевых годах, как правило, знаком из учебного курса язык Паскаль, от которого ST заимствовал основные идеи. К тому же программа на ST содержит чисто инженерные понятия - входы/выходы, переменные с типом «время» и т.п. Добавление в разделы INPUT или OUTPUT новых переменных автоматически приводит к появлению новых входов/выходов у функционального блока ST в проекте. Любые входы/выходы в проекте простым перетаскиванием могут быть связаны с входами/выходами других объектов или переменными проекта.

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

Созданная программа компилируется в специальный интерпретируемый код, который может выполняться и в компьютере, и во всех типах контроллеров, поддерживаемых входящей в состав исполнительной системой . Это контроллеры с практически любыми современными и не очень процессорами (x86, ARM7, ARM9 и т.п.) и распространенными операционными системами (от DOSа и Windows CE до Linux и Ecos). Существенно и то, что для отладки не требуется иметь контроллер в наличии. Программу можно отлаживать как на так называемом Windows-контроллере (исполнительной системе контроллера, запущенной на той же рабочей станции, что и проект для верхнего уровня), так и прямо в режиме разработки, запустив на исполнение код только одного разрабатываемого блока. При этом доступно традиционное исполнение программы по шагам, включая возможность входа во вложенные процедуры.

Рис. 2. Пример реализации вычислительного алгоритма на языке С#

Программирование на языке С#

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

Рис. 3. Вид дерева проекта до выполнения сценария

Автоматизация проектов на языке С#

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

Именно для этих целей можно выполнять сценарии, написанные на C# внутри и обращающиеся к ее объектной модели (рис. 4).

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

Рис. 5. Вид дерева проекта после выполнения сценария

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

Рис. 6. Вид мнемосхемы с созданными сценарием кнопками вызова окон

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

Логика развития - полная поддержка стандарта МЭК 61131-3

Резкий рост интереса пользователей к программированию контроллеров с открытой архитектурой на технологических языках, описанных стандартом МЭК 61131-3, привел нас к мысли не просто реализовать в полную поддержку стандарта, но и выпустить отдельный продукт для тех, кто программирует контроллеры для автономного применения, а не для использования в рамках вер­ти­кально-интегрированных сис­тем. Так появился . Это полнофункциональная, полностью отвечающая стандарту интегрированная среда разработки, которая сохранила принятую в объектную идеологию, позволяющую повысить не только качество проектов автоматизации, но и производительность труда проектировщиков. В связи с использованием новейшей программной архитектуры функционал этой среды не включен в состав версии 3, но станет частью будущей 4-й версии.

Таким образом, сейчас в рамках инструментария MasterSCADAv.3 ИнСАТ предлагает программировать системы, которые содержат как нижний контроллерный уровень, так и операторские станции, а проекты для автономных контроллеров рекомендуется разрабатывать с помощью намного более мощного нового продукта - . Обе среды разработки используют одну и ту же исполнительную систему для контроллеров, поэтому с точки зрения технических характеристик и структурной функциональности (список поддерживаемых контроллеров и платформ, драйверы, архивы, протоколы, быстродействие) их возможности практически одинаковы. Новую среду можно использовать и для программирования тех контроллеров, которые все же взаимодействуют с верхним уровнем, но используют для этого имеющийся OPC-сервер либо один из поддерживаемых протоколов, а не принятую в технологию не требующего конфигурирования «прозрачного» обмена данных.

Рис. 7. Редактор схем релейной логики

Посмотрим на пример проекта, разработанного в среде (рис. 7). Основное преимущество новой среды - возможность создания программы одновременно на всех языках стандарта, используя для каждой части алгоритма тот язык, который для ее реализации окажется наиболее нагляден. Как правило, для динамических алгоритмов, например регулирования, удобнее использовать язык функциональных блоков (FBD), для описания логики инженерам-электрикам привычнее релейные схемы, а по­операционное управление прекрасно описывается языком шаговых последовательностей (SFC). Вычислительные и любые иные задачи могут быть решены на языке «Структурированный текст» (ST).

В приведенном на рис. 7 примере программа контроля параметра «нарисована» на языке LD и далее используется как библиотечный ФБ в программе, созданной уже на языке функциональных блоков (рис. 8).

Рис. 8. Редактор схем функциональных блоков

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

И.Е. Аблин, Генеральный директор,

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

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

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

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

Корпоративная информационная система управления проектами

Серия программных продуктов Primavera Enterprise, позволяет создать корпоративную систему управления проектами и включает ряд систем, работающих с единой базой данных, но предоставляющих различную функциональность. Ядром является программный продукт Primavera Project Planner for the Enterprise (P3e), предоставляющий обширный набор функций и предназначенный для групп планирования и служб мониторинга проектов, которые должны иметь возможность в любой момент вносить необходимые изменения по проектам — от переопределения технологии выполнения работ (последовательности и логики их выполнения) и сдвигов сроков, до перераспределения ответственных, а также решения ресурсных конфликтов.

Имеются дополнительные программные продукты, например, специализированный модуль Portfolio Analyst, обеспечивающий возможность формирования разнообразной аналитики и контроля отдельных проектов или портфелей проектов по заданным показателям. При необходимости Portfolio Analyst позволяет опускаться и на более детальные уровни информации по проектам, например, анализ загрузки ресурсов, потребности в материалах по отдельным пакетам работ. Исполнители работ по проектам могут использовать специальные приложения для сбора информации о проделанной работе. Причем, что немаловажно для компаний с территориально распределенными проектами, эти приложения позволяют работать, используя Internet-приложение (Progress Reporter), или, если это технически сложно, просто вводить информацию в карманный компьютер (Primavera Mobile) для её последующей передачи в общую базу.

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

Интеграционные решения

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

Новые версии Primavera Expedition совместимы с серией Primavera Enterprise и позволяют расширить возможности корпоративной системы управления проектами в части контроля выполнения договорных обязательств, мониторинга выпуска и согласования проектно-сметной документации и сопровождения переговоров по проектам. Кроме этого, поддерживается работа с СУБД Oracle, что облегчает решение интеграционных задач.

Но и при таком наборе инструментов все задачи предприятия охватить трудно, кроме того, во многих компаниях уже функционируют различные системы: бухгалтерские программы, системы документооборота, трехмерного проектирования, сметные программы и т. д. — при создании корпоративной системы управления было бы большой ошибкой не использовать накопленную в них информацию. В этой связи одним из направлений деятельности компании Primavera является интеграция с программным обеспечением других производителей — текущий перечень партнеров компании насчитывает более сотни поставщиков, специализирующихся в смежных областях деятельности: управлении ресурсами, процессами, поставками и т.д. Среди зарубежных партнеров можно упомянуть SAP, Oracle, PeopleSoft и J.D. Edwards, а также поставщиков систем трехмерного проектирования Bentley и Intergraph.

В России используются как интеграционные модули, разработанные совместно с зарубежными производителями, так и собственные решения, специфичные для местного рынка. Одним из примеров является совместная разработка компаний «ПМСофт» и «Инфострой», обеспечивающая передачу информации из стандартных строительных смет в календарно-сетевой график проекта. Этот программный продукт работает со сметной программой «А0» и системой Primavera Project Planner. Проблемы интеграции систем календарно-сетевого планирования и сметных программ хорошо известны: прежде всего это несоответствие уровней детализации сметы и календарно-сетевого графика. При составлении сметы определяется стоимость строительства на основе объемов работ, поэтому сметчики часто не учитывают план производства работ, объединяя, например, в одной расценке одинаковые работы по всему объекту, что не удобно с точки зрения управления.

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

Другой пример интеграционного решения основан на экспорте данных из типового проекта на базе сметной программы WinAvers.

Потребность в подобных решениях и их разнообразие инициировали работы по интеграции системы Primavera Enterprise и с другими современными сметными системами.

Еще один пример — интеграция Primavera Expedition и информационных систем российской компании «ТрансИнвестИнтегратор », реализованной для учета договоров и первичных документов на ряде предприятий атомной энергетики в России. В настоящее время разработанное решение находится на стадии тестирования.

Отдельного внимания заслуживает программный продукт OSIRIS, который является развитием известной российским пользователям утилиты Primavera Post Office и ее аналога „ПМ Почта“ для Primavera Project Planner. Приложение OSIRIS направлено на поддержание оперативного и эффективного взаимодействия между группой управления проектом и его исполнителями. Используя модули, составляющие приложение OSIRIS, участники проекта могут осуществлять детальное планирование на местах проведения работ, вносить фактические данные и обновлять информацию по статусу выполняемых ими работ, а также вносить свои предложения и комментарии в ходе реализации проекта.

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

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

Вместе с программным обеспечением Primavera поставляются средства разработки приложений, позволяющие осуществлять интеграцию с другими решениями, настроить модуль передачи данных из приложений Primavera в другие программные продукты и, наоборот, при этом, работа с данными осуществляется на более высоком уровне, c учетом всех бизнес правил приложения, что обеспечивает сохранность логической модели данных. С помощью Primavera SDK возможна интеграция пакетов Primavera Enterprise/Primavera TeamPlay с пользовательскими базами данных и приложениями. Для этого используется интерфейс ODBC, OLE-DB и JDBC. ODBC-клиентами поддерживаются стандартные языки программирования VB, PowerBuilder, C++ и т.д. Primavera SDK делает программное обеспечение открытым для написания интеграционных модулей с любыми внешними приложениями. Работа с Primavera SDK осуществляется с помощью стандартного языка SQL.

Управление распределенными проектами

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

Корпоративная система обязана предоставлять возможность для работы распределенных или удаленных участников проектов. Уже упоминался ряд программных продуктов Primavera, которые позволяют обеспечить удаленный доступ к информации по проекту, её просмотру и обновлению в ограниченном объеме. Но, если удаленные группы должны иметь полный доступ к проекту: корректировать график, обновлять структуры кодов или инициировать новые проекты, тогда центральный модуль Primavera Project Planner for the Enterprise должен работать как на офисных, так и на удаленных рабочих станциях одновременно. Существует несколько путей решения этой задачи, например, построение сети терминальных рабочих станций на базе технологии Citrix MetaFrame. Эта технология позволяет получить полнофункциональный доступ к приложениям P3e и Primavera Expedition посредством тонкого клиента, например, при подключении через стандартный модем, при этом достигается максимальная степень сохранности данных, которые постоянно остаются в пределах центральной базы данных.

Перспективы

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

Практически все системы управления проектами берут за основу некий план, составляемый на предварительном этапе. Затем в соответствии с этим планом автоматически организуются выполнение, анализ и управление рабочими этапами плана, пакетами работ и самими работами. Методологии систем автоматизации деловых процессов (САДП) и СУП, несмотря на различие в масштабах автоматизируемых действий, в известной степени перекликаются, что позволяет установить двустороннюю синхронизацию между схемами workflow и стратегическим планом (в виде календарносетевого плана или графика выполнения работ по проекту). Здесь важно отметить, что в рамках системы управления проектами календарное планирование и ход выполнения этапов происходят в полуавтоматическом режиме, а интеграция с workflow-системой позволяет создать корпоративную систему управления проектами. Перед такой системой стоит несколько задач: возможность управлять одновременно группой проектов; возможность управлять взаимосвязями проектов; анализ портфеля (группы) проектов; поддержка возможности выбора проекта по заданным критериям; возможность использования лучшего практического опыта; контроль выполнения проекта и т.д.

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

Внедрение системы достаточно трудоемкий и дорогостоящий процесс, однако затраты окупаются: продолжительность проектов сокращается на 15-20%, расходы на планирование уменьшаются на 25%, не говоря уже об оптимизации ресурсов. Применение систем управления проектами непосредственно влияет на совершенствования процессов на предприятии посредством установления связей между командами проектов, обмена полученными результатами и построения системы управления проектами на основе обратной связи. В результате, компания живет как единый организм, адекватно реагируя на изменения рынка.

Алексей Лысаков,
Александр Цветков
Компания «ПМСофт»

Просмотры: 6 220

«Информационные системы и инструменты управления проектами»

Конспект видеолекции

	УПРАВЛЕНИЕ	ПРОЕКТАМИ:ОРГАНИЗАЦИОННЫЕ	И ТЕХНОЛОГИЧЕСКИЕ
РЕШЕНИЯ.................................................................................................................................
			.......................................
Оценка эффективности ИСУП..................................................................................................
Виды программных продуктов по УП.......................................................................................
Структурный подход к внедрению систем УП.........................................................................
Выбор программных средств для управления проектами......................................................
Параметры оценки качества		программного пакета управления проектами.......................
Корпоративная система управления проектами...................................................................
Пример основных курсов системы самообучения................................................................
Пример: разработка и внедрение КСУП в high tech компании.............................................
Пример: внедрение системы управления проектами в строительной компании................
Пример основных регламентов проектной деятельности предприятия..............................
Концепция зрелости бизнеса		.................................................................................................
	ОФИС УПРАВЛЕНИЯ ПРОЕКТАМИ И		УПРАВЛЕНИЕ	ПОРТФЕЛЯМИ
ПРОЕКТОВ..............................................................................................................................
Офис управления проектами и его задачи............................................................................
Как оптимально сформировать портфель проектов? ...........................................................
Стадии формирования офиса управления проектами.........................................................
Приложение.............................................................................................................................

Раздел 1. УПРАВЛЕНИЕ ПРОЕКТАМИ:ОРГАНИЗАЦИОННЫЕ И ТЕХНОЛОГИЧЕСКИЕ РЕШЕНИЯ

Информационные системы управления проектами. Определение

Информационная система управления проектами(далее по текстуИСУП) – это специализированный программный комплекс методических, технических, программных и информационных средств, направленный на оптимизацию процессов планирования и управления проектами.

В настоящее время существует более200 ИСУП, среди которых наиболее распространенными информационными системами УП являются:

MS Project, Производитель Microsoft Corp. (США);

Spider Project, производитель Spider Technologies Group (Россия) ;

PJM ORACLE, Oracle (США);

Primavera Project Planner (P4), производитель Primavera Systems, Inc. (США);

SureTrak Project Manager, производитель Primavera Systems, Inc. (США);

Project Expert, производитель Про-Инвест Консалтинг(Россия);

Open Plan, Производитель Welcom Corp. (США).

Здесь важно не путать систему и инструмент. Хотя в расшифровке ИСУП есть понятие «система», это, по сути, только лишь инструмент. При выборе ИСУП для своего предприятия надо иметь в виду, что сегодня нет универсальных инструментов: для одних проектов удобнее одни, для других – иные.

Использование ИСУП позволяет:

· Определять и контролировать информационные потоки проектной деятельности;

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

· использовать математические методы расчета параметров проектов;

обеспечении и финансировании на план проекта.

Пример информационной системы управления проектами (ИСУП)

На предприятиях, где полноценно функционирует ИСУП, как правило, присутствуют следующие базовые комплексы (рис. 1):

· нормативно-регламентная документация на ИСУП;

· аппаратный комплекс ИСУП;

· автоматизированные рабочие места, АРМы ИСУП;

· базовое программное обеспечение (например: P4, MSP, Spider или другие);

· обеспечивающие интеграцию ИСУП с другими системами управления предприятия, в том числе шлюзы с:

o системой документооборота; o системой кадрового учета;

o системой финансово-экономического учета; o BSC (ССП);

o CRM;

o ERP (и/или MRP, MES);

o системой информационной безопасности; o системой архивизации;

· система обучения ИСУП;

· группа сопровождения и развития ИСУП.

Рис.1. Пример информационной системы управления

Оценка эффективности ИСУП

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

Один из обзоров был проведен Институтом управления проектами США (PMI) и включает данные, полученные более чем от 100 североамериканских компаний и профессионалов в области управления проектами.

На диаграмме ниже представлены результаты опроса по уровню эффективност использования ИСУП на базе методологии управления проектами PMBoK института PMI.

Рис. 2. Оценка эффективности внедрения ИСУП по данным PMI

По результатам обзора были получены следующие результатыбольшинство специалистов в области управления проектами и представителей компаний различных отраслей США сошлись во мнении, что прирост эффективности составляет при использовании ИСУП порядка21% по отношению к показателям компаний, не использующих подобные системы для ведения проектной деятельности.

В таблице 1 представлены средние оценки прироста эффективности после внедрения ИСУП по ключевым областям управления проектами:

Таблица 1. Оценка эффективности ИСУП

Управление			Интеграция	проектной	деятельности
			деятельность компании
областью
			Актуализация целей проектов
Управление расписаниями			Управление расписаниями проектов
			Прогнозирование расписаний
			Управление бюджетом проектов
Управление стоимостью			Рост продаж
			Возврат инвестиций (Return on Investment)
			Сокращение времени выхода на рынок
			Управление ресурсами проекта
Управление ресурсами
			Эффективность использования ресурсов
			Продуктивность работы персонала
Управление		проектов	Управление
		заказчикам	Информированность заказчиков
			Вовлечение заказчика
поставщиками
			Управление поставками

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

Виды программных продуктов по УП

Информационные системы масштаба предприятия. Такие системы, с одной стороны,

содержат практически всю информацию о деятельности предприятия, а с другой - имеют специализированный модуль, который выбирает из общей базы данных информацию, относящуюся к конкретному проекту или группе проектов, и выполняет такие стандартные для управления проектами задачи, как расчет сроков проекта, расчет требуемых ресурсов, разрешение ресурсных конфликтов, расчет стоимости проекта, расчет рисков и пр. В качестве примера можно привести системуSAP R/3 со специализированным модулем Project System или комплекс программных продуктов Oracle Applications, в состав которого входит специализированный продуктOracle Project. Такого рода системы предназначены для достаточно крупных предприятий, которые могут позволить себе значительные капиталовложения и трудозатраты, требуемые для внедрения и отладки столь масштабных программных комплексов.

Специализированные пакеты по управлению проектами общего назначения. В этот класс входят такие продукты как MS Project, Primavera, Time Line, Spider Project, Artemis и

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

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

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

В последние годы на рынке появились программные продукты для управления проектами

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

Структурный подход к внедрению систем УП

В первой половине1990-х в России российской компаниейLVS был адаптирован и внедрен Структурный подход к внедрению систем, УПразработанный фирмой Lukas Management Systems.

Структурный подход к внедрению систем УП в общем случае включает4 основных этапа, и лишь успешно пройдя один, можно переходить к другому.

I этап. Демонстрация преимуществ проектного управления и анализ требований

Цели этапа:

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

· проанализировать стратегические цели бизнеса компании;

· оценить степень зрелости существующей системы УП;

· определить требования к УП для обеспечения целей бизнеса;

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

II этап. Определение процесса и процедур управления проектами

Цели этапа:

· спроектировать и описать процесс УП;

· определить функции и ответственность руководителей проектов и персонала (членов проектных команд);

· выявить информационные потоки и описать базовые требования ним;

· разработать корпоративные стандарты и процедуры УП;

· разработать и внедрить общую терминологию УП(корпоративный глоссарий);

· провести оценку сроков, стоимости и риска самого проекта по внедрению системы УП.

Рис. 3. Внедрение системы управления проектами

3 этап. Проектирование и внедрение системы управления проектами

Цели этапа:

· предложить проект автоматизированной системы УП, которая учитывает:

Цели бизнеса;

Организацию;

- стандарты и процедуры, разработанные на предыдущем этапе;

- учет необходимых данных;

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

·разработать, сконфигурировать и установить автоматизированную систему УП;

1. Проведение общих семинаров(объяснение, зачем вообще нужно внедрять тот или иной инструмент, снять настороженность персонала относительно нововведений).

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

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

IV этап Сопровождение и обеспечение работоспособности системы УП

Цели этапа:

·сопровождение и обеспечение работоспособности системы

·обеспечение эффективности использования системы УП

·непрерывное совершенствование системы

·управление изменениями и развитием корпоративной системы управления проектами

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

Руководитель Московского отделения PMI В.И.Либерзон рекомендует подходить к выбору программного обеспечения УП как к самостоятельному проекту. В этом проекте он выделяет две фазы – фазу анализа и фазу решения. Что включают в себя эти фазы?

Фаза анализа

· анализ рынка

· контакт с поставщиками

· технические требования

· функциональные требования

он эти требования удовлетворяет. Более того, можно порекомендовать оценить в баллах

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

примерную балльную оценку предлагаемого программного пакета.

Целесообразно задавать перечисленные ниже вопросы поставщикам пакетов, просить их

показать, как реализованы те или иные важные для деятельности

именно Вашей

компании функции. По тому, как вам будут отвечать, вы сможете оценить

и будущее

сопровождение пакетов.

Пример списка параметров:

1) Качество составляемых графиков выполнения работ(оптимальность использования ресурсов проекта),

2) Размеры проекта, поддающиеся анализу с помощью пакета (количество работ, ресурсов, связей, календарей),

3) Возможность использования в проектах нормативных баз, присущих области применения,

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

5) Гибкость - возможность использования в проекте дополнительной информации,

6) Возможность использования в проектах множественных иерархических структур работ, проведения выборок и сортировок по любым используемым показателям и в том числе, определяемым пользователями,

распределения ресурсов,

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

9) Легкость освоения, консультационная и обучающая поддержка,

10) Полнота документации/информационного обеспечения,

11) Качество оформления выходных документов,

12) Возможности экспорта и импорта данных - связь с другими программами, базами данных,

13) Возможность вывода информации в Интернет,

14) Возможность управления не одним, а многими проектами– программами и мультипроектами,

15) Скорость выполнения отдельной работы/работ,

16) Удобства работы с графическим интерфейсом и т.д.

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

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

Корпоративная система управления проектами

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

Рис. 5. Пример корпоративной системы управления проектами (КСУП)

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

Офис управления проектами предприятия(или центр управления проектами) – функция своеобразного «мозга проектной деятельности предприятия»;

Банк знаний в области УП;

Внутренняя система обучения;

Документооборот УП(Нормативные корпоративные документы– законы внутренней деятельности в области УП - регламенты);

Информационная система управления проектами(ИСУП).

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

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

Взаимодействие подсистем может осуществляться в оперативном илиотложенном режимах.

В оперативном режиме программное обеспечение, реализующее решение задач одной подсистемы, при необходимости в данных, сформированных другой подсистемой, запрашивает и получает их от программного обеспечения данной подсистемы автоматически. Это - наиболее эффективный способ взаимодействия программного обеспечения различных подсистем. Однако он возможен только тогда, когда программное обеспечение различных подсистем способно взаимодействовать в автоматическом режиме. А это не всегда возможно. Например, в том случае, если при создании ИСУП используется программное обеспечение разных производителей, наладить оперативное взаимодействие подсистем удается в крайне редких случаях. Более того, если в одной подсистеме используются программные продукты различных поставщиков, то и внутри этой подсистемы оперативное взаимодействие организовать обычно не удается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Информационная система управления проектами (ИСУП)

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

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

Исследование, проведённое компанией PmExpert среди отечественных компаний, доля крупных организаций (от 300 человек) среди которых составила 65%, выявило, что 60% опрошенных организаций, внедривших у себя ИСУП, положительно оценивают эффект от внедрения. Таким образом, подтверждается возрастание важности ИСУП при наличии большого объёма проектных данных.

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

Применение специализированного программного обеспечения позволяет повысить эффективность выполнения процессов проектного управления за счёт:

• Сокращения трудозатрат при выполнении процессов проектного управления;
• Улучшения коммуникаций участников проектной деятельности за счёт использования общих информационных ресурсов;
• Повышения скорости выполнения процессов проектного управления и процесса мотивации участников проектов;
• Минимизации количества ошибок проектной информации;
• Автоматизированной обработки и централизованного хранения информации о проектах.

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

1. Базовые системы поддержки проектного управления. Представляют собой специализированное программное обеспечение, предназначенное для выполнения узкого набора базовых процессов проектного управления, например календарного планирования, учёта проектных трудозатрат, фиксации проектных решений и т.д. Базовые системы обычно имеют локальный режим работы, устанавливаются на персональном компьютере пользователя, обычно руководителя проекта или администратора. К таким системам можно отнести Microsoft Project локальная версия (Microsoft, США), Open Project (Serena Software, США) и другие.
2. Расширенные системы поддержки проектного управления. К ним можно отнести программное обеспечение, предназначенное для поддержки широкого набора «классических» процессов проектного управления. Такие информационные системы содержат взаимосвязанные данные разных процессов проектного управления, могут иметь возможность разного представления данных для разных уровней управления организации, возможность многопользовательской работы, но обычно имеют ограниченные возможности интеграции со смежными информационными системами. К системам данного класса можно отнести такие системы как PM Foresight (ГК «Проектная ПРАКТИКА», Россия), ADVANTA (Адванта Груп, Россия), Microsoft Enterprise Project Management (Microsoft, США) и др.
3. Продвинутые системы поддержки проектного управления. Представляют собой эволюционное развитие систем, относящихся к классу «Расширенные». Отличаются от них в первую очередь тем, что позволяют интегрировать проектную деятельность с другими видами деятельности и процессами организации за счёт создания единого информационного пространства, использования продвинутых механизмов интеграции данных. Точнее будет сказать, что это уже не специализированные системы поддержки процессов проектного управления, а комплексные информационные системы, создающие единое информационное пространство организации, и включающие в себя, в том числе, и функционал для поддержки процессов проектного управления. Примерами таких систем могут служить Oracle e-Busines Suite (ORACLE, США), SAP ERP (SAP, Германия).

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

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

• Должна ли система использоваться на всех уровнях управления?
• Кто будет пользователями системы?
• Должна ли система использоваться только для высокоприоритетных проектов?
• Какие процессы проектного управления должна автоматизировать ИСУП?
• С какими бизнес-процессами организации планируется интеграция ИСУП?
• Какие эффекты ожидаются от внедрения ИСУП?

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

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

Критически важными условиями успешного внедрения ИСУП являются поддержка руководства организации и наличие в организации методологии проектного управления.

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

Примеры процессов, автоматизируемых с помощью ИСУП, приведены в таблице.

Типовые процессы, автоматизируемые ИСУП

№ п/п	Наименование процесса	Рекомендуемая очерёдность внедрения
Процессы проектного управления
1.	Паспортизация проектов	первая
2.	Календарное планирование	первая
3.	Управление показателями проекта	первая-вторая
4.	Учёт трудовых ресурсов проекта	вторая
5.	Учёт рабочего времени проектного персонала	вторая-третья
6.	Управление финансами проекта	первая-третья
7.	Управление рисками, проблемами и открытыми вопросами	вторая-третья
8.	Сбор и формирование отчётности по проекту (проектам)	первая-третья
9.	Управление изменениями	первая
10.	Хранение проектной документации	первая-третья
11.	Организация совещаний и ввод результатов совещаний	первая
12.	Контроль исполнения проектных решений	первая
13.	Ведение договоров и планирование поставок проекта	третья
14.	Управление портфелями проектов	третья
Процессы ИСУП
15.	Администрирование ИСУП	первая
16.	Журналирование действий ИСУП	первая
17.	Нотификация участников проекта	вторая
18.	Интеграция со смежными процессами организации	третья

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

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

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

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

LDAP (англ. Lightweight Directory Access Protocol - «облегчённый протокол доступа к каталогам») - сетевой протокол для доступа к службе каталогов.