ѻ члены проектной команды, которые в системе отчитываются о выполнении проектных работ, трудозатратах на выполнение работ, имеют доступ к проектной документации;
ѻ функциональные руководители, выступающие в качестве владельцев ресурсов, которые в ИСУП назначают исполнителей на работу из числа своих подчиненных, просматривают отчеты о загрузке исполнителей в проектах;
ѻ руководство, пользующееся отчетами с "общей картиной" проектной деятельности;
ѻ сотрудники проектного офиса, контролирующие полноту и своевременность внесения данных в ИСУП проектными командами, получающие аналитические отчеты из ИСУП.
Помимо количества пользователей, которые будут работать в ИСУП, нужно учитывать территориальное расположение предприятия и соответственно физическое местоположение пользователей ИСУП, ИТ-инфраструктуру предприятия, чтобы в результате все пользователи имели необходимый доступ к ИСУП.
• Каковы функциональные требования к ИСУП, исходя из методологии управления проектами? Чем более зрелая организация в сфере управления проектами, тем большее количество процессов в сфере проектной деятельности нужно будет автоматизировать. На начальном уровне зрелости ИСУП можно использовать только для сбора общего реестра проектов и контроля сроков. Более того, на начальных уровнях зрелости в области УП рекомендуется ограничить количество пользователей ИСУП, оставив только сотрудников проектного офиса и собственно руководителей проектов. Если же предприятие уже готово к детальному управлению ресурсами, более того, есть задача по автоматизации процессов в области управления портфелем, то и функциональные требования к ИСУП будут принципиально другими.
Вышеперечисленные требования рекомендуется предоставить для анализа вендорам и консалтинговым компаниям, которые предлагают решения в области автоматизации проектной деятельности на различных платформах.
После формирования требований к ИСУП рекомендуется провести оценку предложений по автоматизации на базе различных платформ и выбор платформы для ИСУП.
Для выбора программного обеспечения рекомендуется изучить предложения, разработанные поставщиками того или иного программного продукта, на соответствие предъявленным базовым требованиям к ИСУП, сформированным на предыдущем шаге. Конечно же, помимо соответствия предъявленным базовым требованиям при выборе платформы для ИСУП будет учитывать и стоимость внедрения и поддержки ИСУП на базе той или иной платформы.
При оценке стоимости внедрения ИСУП на базе различных платформ необходимо учитывать следующие составляющие стоимости внедрения и поддержки ИСУП:
• стоимость самих лицензий на ПО с учетом количества и ролей пользователей;
• стоимость аппаратного обеспечения, которое будет необходимо закупить для установки и поддержки работоспособности ИСУП;
• стоимость внедрения (возможно, будет принято решение о внедрении ИСУП силами внутренней ИТ-службы предприятия);
• стоимость обучения пользователей (опять-таки возможен вариант, что обучение будет проводиться командой внедрения СУП);
• стоимость технической поддержки.
Анализируя предложения по платформам для автоматизации проектной деятельности, многие компании рассматривают возможность использования решения на базе Microsoft Project, что вполне логично, ведь согласно аналитическим отчетам российских, европейских и американских компаний самое распространенное программное обеспечение по управлению проектами – решение на базе Microsoft Project.
Бесспорные достоинства Microsoft Project:
• наличие большого списка функций для автоматизации проектного управления;
• широкая распространенность данного решения, что упрощает задачу по обмену планами-графиками работ с подрядчиками и внешними заказчиками, уменьшает стоимость обучения, упрощает задачу по поиску консультантов по внедрению и специалистов для поддержке ИСУП в ходе промышленной эксплуатации;
• простота и понятность интерфейса;
• доступная ценовая политика на лицензии.
Однако не нужно думать, что решение Microsoft – единственно правильный выбор, так как предприятиям есть смысл рассматривать при внедрении ИСУП решения и от других производителей.
После выбора платформы для ИСУП на основании разработанных требований проводится разработка детальной технической спецификации, которая описывает все необходимые настройки, выполняемые в ИС. В техническом задании на настройку ИСУП обязательно должны присутствовать следующие разделы:
• Списки справочников в системе и список объектов, для которых используются данные справочники. Например, в системе будет вестись справочник подрядчиков, и он будет связан работами проекта в ИСУП, чтобы можно было указать, на какую работу назначен какой подрядчик.
• Список экранных и отчетных форм, которые будут использоваться для ввода и просмотра данных в системе.
• Профили ролей пользователей в системе, набор функций, которые доступны пользователям с данной ролью в системе, и набор объектов, к которым пользователи будут иметь доступ на чтение, редактирование.
Например, роль руководителя проекта в ИСУП характеризуется тем, что пользователи, которым присвоена данная роль в ИСУП, смогут иметь доступ на запись к тем проектам, где они указаны как руководители проектов, смогут просматривать, но не редактировать список ресурсов, смогут назначать ресурсы на работы своих проектов, но не изменять характеристики ресурсов и т. д. Комплект функций, которые могут быть доступны тем или иным профилям, зависит от платформы.
По детальному техническому заданию осуществляется настройка прототипа ИСУП и демонстрация прототипа команде внедрения СУП. Прототип нужен для того, чтобы команда внедрения СУП могла убедиться, что ИСУП поддерживает процессы по управлению проектами, заложенными в методологию управления проектами. По результатам демонстрации прототипа возможны уточнения или дополнения ранее предъявленных функциональных требований и, следовательно, корректировка детального технического задания на настройку ИСУП и самого прототипа.
Настроенная ИСУП должна сопровождаться "классической" необходимой документацией (руководство пользователя и руководство технического администратора) и регламентами работы с ИСУП по ролям участников проектной деятельности.
Руководства пользователей должны быть не только по стандартной функциональности, но и по тем функциям, которые были модернизированы в ходе настройки ИСУП под методологию управления проектами предприятия.
Регламенты работы в ИСУП – принципиальное условие успешного внедрения ИСУП как инструмента планирования и контроля проектной деятельности предприятия. Дело в том, что для соблюдения в ИСУП единых принципов ведения проектов нужно четко прописать необходимый порядок работы пользователей в системе, чтобы обеспечить регулярный информационный обмен между заинтересованными лицами в проекте, требования к детальности планов и фактических данных, периодичности актуализации данных. Регламент работы в ИСУП – это не руководство пользователя, в котором говорится о том, какие манипуляции можно провести в ИС, чтобы добиться того или иного результата. Регламент работы в ИСУП однозначно описывает, кто, в какой момент и какую информацию должен ввести в ИС, и требования к полноте этой информации. Например, в регламенте для руководителя проекта по работе в ИСУП должен содержаться примерно следующий набор действий для фазы планирования:
• После подписания приказа о старте проекта администратор проектного офиса информирует посредством электронного сообщения руководителя проекта о присвоении шифра проекта и о создании пустого проекта в ИСУП с определенным названием.
• Руководитель проекта должен на этапе планирования разработать календарный график проекта, при этом в календарном графике работы ближайшего квартала должны быть детализированы таким образом, чтобы длительность работ была не больше двух недель, не реже чем на каждый месяц должны быть запланированы вехи, которые будут включены в базовый календарный план, на каждую работу должен быть назначен один ответственный из справочника сотрудников в ИСУП.
• После разработки календарного расписания проекта руководитель проекта должен распечатать базовый календарный план по вехам из ИСУП, согласовать его в соответствии с методологией управления проектами, отсканировать подписанный документ, выложить в библиотеку проектных документов и уведомить проектный офис о том, что необходимо зафиксировать базовый календарный план с ИСУП на основании подписанного документа.
Как видно из примера, регламент работы в ИСУП должен обеспечивать единообразие планирования и контроля проектов всеми руководителями проектов для обеспечения получения сводной отчетности.
Для приемки ИСУП в эксплуатацию рекомендуется провести испытания настроенной ИСУП на контрольном примере. При этом, учитывая, что тестируется не разработанное с нуля под заказчика ПО, а настроенная платформа, нужно обращать особое внимание на то, насколько в ИСУП учтены функциональные требования, насколько понятна и удобна в использовании сопроводительная документация.
В ходе приемки ИСУП в эксплуатацию в соответствии с процедурами, принятыми в компании, ИСУП передается группе технического сопровождения предприятия на поддержку наравне с прочим программным обеспечением, которое используется в организации для автоматизации деятельности.