quality .eup.ru
Вероятно, самый старый в рунете сайт о менеджменте качества
Интуиция — это то, что еще отличает одного потребителя от другого. (В.В. Киянский)
Опыт организации проектного офиса
«Если делаешь что-нибудь
неправильно — не нужно
рассчитывать на
Народная китайская мудрость
Организация проектного офиса — это прежде всего показатель зрелости системы управления проектами в компании.
Проектный офис предназначен для поддержки управления проектами в организации. В нем ведутся архивы проектов, разрабатываются методические рекомендации и руководящие материалы по управлению проектами, проводится обучение и консультации руководителей проектов (РП) и членов проектных команд, разрабатываются и ведутся компьютерные модели проектов. В организациях, где внедрено мультипроектное управление (общее управление ресурсами организации, задействованными в различных проектах), проектный офис служит как раз штабом такого управления.
Поэтому типичными подразделениями проектного офиса <2, 3>являются -см.Рис. 1:
Аналитический отдел, в котором ведутся компьютерные модели проектов,
Методологический отдел, в котором разрабатываются стандарты управления проектами в организации,
Архив, в котором ведутся архивы проектной документации.
(Информация по управлению проектами в рисунках в основном базируется на терминах стандартов ISO 9000 <1>и PMBOK <2>. Рисунки взяты из репозитария моделей бизнес процессов в среде моделирования ARIS <5>)
Рис. 1 Пример Структуры Проектного офиса в проектной компании
Именно на сотрудников Проектного офиса ложиться обязанность по описанию существующих в организации практик управления проектами и сравнении их с лучшими практиками стандарта (best practices). Таким образом, существенно возрастают методические функции офиса проектов. Кроме того, появляются аналитические функции, связанные с оценкой эффективности применяемых методик и выработкой предложений по их улучшению. Расширение учетных функций происходит за счет того, что необходимо наладить сбор, накопление и обработку метрик: количественных показателей выполненных проектов, что является необходимым условием постоянного совершенствования проектного управления.
Увеличивается и объем обучения: каждый РП должен хорошо понимать и уметь использовать на практике требования разработанного стандарта.
На Рис. 2 показан пример дерева функций Проектного офиса.
Рис. 2 Пример дерева функций Проектного офиса
С точки зрения СМК на Проектный офис ложится роль согласования проектного управления с общей системой менеджмента качества компании, а также проведение аудита проектных подразделений и участие в контроле качества результатов проекта.
На Рис. 3 показан пример распределения ответственности Ролей Проектного офиса и СМК.
Рис. 3 Пример схемы ответственности ролей Проектного офиса и СМК
На Рис. 4 показан пример с хемы взаимодействия функционалов Проектного офиса и СМК .
Необходимо отметить, что проектный офис должен постоянно решать задачу управления ресурсами -так называемый ресурс-менеджмент!
Тайм или ресурс-менеджмент -это управление распределением рабочего времени между сотрудниками (проектными группами) <3>. Как показывает наша практика, это самая «конфликтоопасная» зона .
Практические задачи которые должен решать ресурс-менеджмент:
Анализ первоначальных ( Base) планов реализации проектов компании,
Декомпозиция целей проектов до задач конкретным исполнителям,
Оценка временных затрат на выполнение заданий,
Распределение заданий среди сотрудников,
Создание временных резервов, которые будут задействованы при поступлении новых проектов или затягивании работ над старыми,
Проведение регулярного мониторинга загрузки персонала.
Контроль над соблюдением сроков сдач работ,
Предотвращение конфликта ресурсов — при увеличении загрузки персонала до критической — разнесение проектов во времени.
Эти задачи у нас, например, решает Группа координаторов, состоящая из ресурс-менеджеров по каждому проектному подразделению. Принятие решений по управлению ресурсами лежит на Руководителях проектных подразделений, а информацию по управлению ресурсами для них предоставляет именно группа координаторов — см. Рис. 3
Без этого на практике у Вас постоянно будут возникать конфликты (недостаток) ресурсов. У компании могут неожиданно появиться новые проекты, которые нужно будет срочно реализовывать. Кроме того, всегда есть риск, что работа над уже имеющимися проектами затянется. Так, по результатам исследований специалистов, около 18% дел, запланированных на день, переносится на более позднее время. В результате конфликта ресурсов сроки сдачи проектов будут постоянно сдвигаться.
Рис. 5 Схема взаимодействия функционалов Проектного офиса и СМК
Чтобы извлечь из корпоративной системы управления проектами максимальную пользу, необходимо не только создать стандарты управления проектами, но и выбрать оптимальную Информационную систему планирования, прогнозирования и контроля проектов.
Выбор Информационной системы управления проектами
Примерно 70% пользователей в мире для управления проектами используют продукт Microsoft Project. Поскольку сомнительно, что данный продукт люди используют для домашнего использования, очевидно, что подобная масса набрана именно за счет значительно числа корпоративных потребителей.
И это не случайно — дело в том, что продукты Microsoft в интегрированных решениях, как бы усиливают полезность друг друга и их совместная потребительская ценность значительно возрастает.
Если говорить о MS Project, то без интеграции продукт, конечно, явно не дотягивает до выставленной рынком планки корпоративных решений.
Но, видимо, Microsoft и рассчитывает, что интеграция будет обязательным компонентом внедрения, поэтому принципиально отказывается развивать в MS Project целый ряд функционалов.
(По мнению Microsoft, если функционал реализован лучше и стоит дешевле в специализированных системах, то следует интегрироваться с ними, а не пытаться «изобретать велосипед».)
Кроме того, как правило ( 90 % всех компаний ), все отчетные документы ведут уже в Word и Excel, то есть используют все тот же продукт Microsoft -MS Office.
Вот по этому пути дальнейшего использования продуктов Microsoft и придется Вам идти дальше — поэтому для управления проектами я рекомендую пользоваться все-таки именно MS Project.
Просто для успешной организации Проектного офиса на основе популярного MS Project необходима его интеграция с MS Share Point Team Services -см. Табл. 1. Это даст возможность легко управлять версиями документов и обеспечит необходимое управление записями по качеству. Другой важный аспект — MS Share Point позволяет Вам создавать «виртуальные пространства» для совместной работы.
Еще большее усиление синергетический эффекта наблюдается со средствами групповой работы ( обеспечение эффективных внутренних коммуникаций ) на базе MS Outlook и MS Exchange -см.Рис. 1.
Рассмотрим теперь, как можно реализовать требования наиболее эффективной модели в смысле обеспечения качества проекта СММ при организации проектного офиса на примере его реализации в среде MS Project -см. Табл.1
Табл.1 Пример Матрицы реализации требований наиболее эффективной модели в смысле обеспечения качества проекта- СММ <4>при управлении проектами с использованием информационной системы управления проектами (ИСУП), построенной в среде MS Project
Такая ИСУП позволит:
Иметь актуальную и достоверную картину хода проекта в части:
плановой (например, на 1-2 месяца вперед) загрузки человеческих и материальных ресурсов компании по проектным департаментам;
фактической загрузки человеческих и материальных ресурсов компании по департаментам.
Создать корпоративную базу знаний (документов) по управлению проектами для использования лучших практик, корпоративных шаблонов, библиотек проектных документов, метрик задач в новых (последующих) проектах.
Получить отчетность и аналитику по всем проектам компании для своевременного принятия решений по проблемам, рискам, конфликтам ресурсов:
отчет по отклонениям проектов от запланированных сроков и затрат в текущих проектах;
отчеты по плановой и фактической загрузке ресурсов и утилизации ресурсов;
отчет по освоенному объему (экспериментально)
Сократить издержки на проведение аудитов проектов.
Пример реализации процедуры управления стоимостью проекта (бюджетирование проекта) при помощи ИСУП на базе MS Project представлен на Рис. 6
Рис. 6 Пример реализации процедуры управления стоимостью проекта (бюджетирование проекта) при помощи ИСУП на базе MS Project
Пример матрицы метрик, сбор которых можно обеспечить с помощью отчетов MS Project представлен в Табл. 2
Табл. 2 Матрица метрик, сбор которых можно обеспечить с помощью отчетов MS Project
| №№ | Метрика | Описание возможности реализации измерения |
| 1 | Количество этапов (фаз) проекта, N | Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 2 | Количество отдельно оплачиваемых этапов (фаз) проекта, N1 | Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 3 | Общее количество задач в проекте, n | Реализуемо стандартными средствами в Web Access |
| 4 | Среднее количество задач в одном этапе (фазе) проекте, n1 | Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 5 | % реализованных рисков | Для WSS реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 6 | % решенных проблем | Для WSS реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 7 | Количество документированных запросов на изменения (CR), m1 | В плане надо ввести для задач признак CR или, еще лучше, заложить в код признак CR. Тогда реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 8 | % проектных документов, прошедших рецензию | Теоретически реализуемо, но требуются организационные изменения. С помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
| 9 | % увеличения срока выполнения проекта | Реализуемо стандартными средствами в Web Access |
| 10 | % увеличения себестоимости проекта | Реализуемо стандартными средствами в Web Access для внутренней себестоимости трудозатрат |
| 11 | Общая плановая длительность проекта, T | Реализуемо стандартными средствами в Web Access |
| 12 | Средняя плановая длительность выполнения задачи проекта, t | Реализуемо с помощью внешнего программирования. Нужно написать SQL-запрос к БД и вывод данных в Excel |
Анализ проектной деятельности, например в нашей компании, проводится Центром управления проектами в соответствии со Стандартом по управлению проектами и имеет целью предоставление необходимой и достаточной информации всем категориям руководителей о состоянии и ходе проектов, выполняемых компанией. Аналитическая работа ЦУП является непрерывным процессом. Для анализа проектов устанавливаются измеримые ключевые показатели деятельности, кроме того, аналитические материалы дополняются комментариями сотрудников, выполняющих анализ — см. Рис. 7.
Рис. 7. Пример аналитического анализа в рамках проектного офиса ( ЦУП)
Как видно из Рис 3, 5 и 7, и в соответствии с требованиями ISO 9000, предметом особого внимания необходимо считать мониторинг корректирующих и предупреждающих действий.
Рассмотрим пример организации такого мониторинга на реальном примере проектно ориентированной компании.
Организация мониторинга корректирующих и предупреждающих действий
Пример матрицы действий, документирования, ответственности и отчетности по корректирующим действиям представлен в Табл.3
Примечание к Табл 3 и 4 :Д ЦУП -директор ЦУП, РСК-руководитель Службы качества ( СК), РПД- руководитель проектного департамента ( или подразделения).
принимает решение о необход.
отвечает за контроль выполнения
Протоколы совещаний по проекту.
Форма регистрации проблемы ( см. Приложение 6.1);
Решение о необходимости проведения корректирующих действий принимаетcя на основании анализа причин появления отклонений или несоответствий и степени влияния этих несоответствий на качество проекта и функционирование СМК.
Отчеты по корректирующим действиям проверяются :
Д ЦУП при проведении последующих внутренних проверок проектов;
РСК при проведении последующих внутренних аудитов СМК ;
РП в дальнейшем ходе проекта;
РПД в ходе их производственной деятельности.
Результаты корректирующих действий анализируются на заседаниях Руководства и анализ документируется в протоколах заседаний.
Пример матрицы действий, документирования, ответственности и отчетности по предупреждающим действиям представлен в Табл. 4
отвечает за выполнение
Отдела Маркетинга
«Анализ удовлетворенности Потребителей
по результатам проведения ERP-форума»
Отдела Маркетинга по маркетинговым исследованиям
(Клуб Потребителей создан со следующими целями:
Изучение мнения и пожеланий клиентов и профессионалов, занимающихся внедрением, развитием, эксплуатацией ИТ-систем, по развитию ИТ- услуг (в неформальной обстановке),
Определение имеющихся проблем в развитии ИТ- услуг и путей их решения,
Получение оперативной информации о новых технологиях и решениях в области ИТ-индустрии.
Результаты неформального опроса обобщаются в Отделе маркетинга в виде отдельного отчета и передаются для анализа Руководству компании и в ЦУП ( в виде внешней составляющей исходных данных для отчета по анализу СМК).
Проект компании — » ERP-форум» -это ежегодная конференция, в которой принимают участие:
представители компаний, являющихся потенциальными Потребителями ИТ-услуг;
представители компаний-Клиентов TopS BI;
профессионалы различных отраслей бизнеса и информационных технологий,
руководители подразделений самой компании.)
Результаты анализа базы данных выполненных проектов и тенденций в ходе выполнения проектов и функционирования БП СМК обобщаются в ЦУП в виде внутренней составляющей исходных данных для отчета по анализу СМК.
СК после согласования с ЦУП выносит эти результаты в отчет по анализу СМК на заседание Руководства.
Руководство Компании анализирует рассмотренные на этих заседаниях данные и на этой основе вырабатывает план предупреждающих действий.
Литература
1. ISO 9000:2000.Система Менеджмента Качества. Требования.
2. Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute.
3. Либерзон В. И. Основы управления проектами. М., 1997
Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software ( SW-CMM), version 1.1. // CMU/SEI-93-TR-024, — Februaru, 1993.
5. «Инструментарий ARIS. Методы». Файл pdf. Поставляется вместе с демо-версией системы ARIS Toolset.
- Главная
- »Документы
- Часть 1
- Часть 2
- Часть 3
- Часть 4
- Часть 5
- Часть 6
- Часть 7
- »Материалы
- Часть 1
- Часть 2
- Часть 3
- Часть 4
- Часть 5
- Часть 6
- Часть 7
- Часть 8
- Часть 9
- Часть 10
- Часть 11
- Часть 12
- Часть 13
- Часть 14
- Часть 15
- Стандартизация
- Метрология
- Сертификация
- Экономика качества
- Стандарты ISO
- Литература
- Плакаты
- »Скачать
- Полезные файлы — Часть 1
- Полезные файлы — Часть 2
- Полезные файлы — Часть 3
- Полезные файлы — Часть 4
- Испытательная лаборатория
- Рефераты
- ФОРУМ
О проекте
quality.eup.ru — один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.
Нам более 7 лет, и все это время ресурс пополняется новыми и новыми материалами, почти ежедневно. Если вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.
Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.
]]>
Создание инструментов проектного офиса на базе Microsoft Project Server
Сегодня мы расскажем о своем опыте использования Project Server для планирования и учета трудозатрат по проектам, о том, как мы его оперативно настроили под свои задачи и добились в итоге четкой картины: менеджеры видят, как работает компания, насколько успешно сдаются проекты, какова эффективность каждого отдельно взятого сотрудника за запрашиваемый период времени и т.д.
История и статистика использования Project Server в EastBanc Technologies
Мы используем Project Server c 2005 года для учета рабочего времени и планирования работ в рамках группы компаний, состоящей из двух офисов в разных часовых поясах — в России и США. Также учитываем в системе временно привлекаемых подрядчиков.
Примерная статистика:
Всего проектов в системе — 603,
Табелей учета рабочего времени (они же time sheets, они же таймщиты) на проверку еженедельно — 140,
Задач в неделю 260.
Workflow выглядит так: каждый проект мы заводим в Project, включаем туда всех членов проектной команды, создаем план проекта (задачи, планируемые сроки и трудозатраты). Сотрудники регулярно заносят информацию о том, сколько рабочего времени было потрачено на задачи по проектам за каждый рабочий день — заполняют так называемый time sheet, табель учета рабочего времени.
Для сотрудника это выглядит просто как проставление цифр в таблице с назначенными на них задачами по дням. При необходимости, задачи в проекте они могут заводить самостоятельно. А поскольку речь идет о «бюрократической», рутинной для сотрудника процедуре, о которой несложно забыть, настроены автоматические email-напоминания.
На основе данных, отправленных сотрудниками, строится OLAP-куб, который позволяет менеджерам парой кликов конструировать отчеты различных форматов – по сути, отчет можно собрать под любые нужды, которые приходят в голову менеджерам, и анализировать информацию в удобном виде в любом разрезе.
Инструменты для реализации данного решения на Project Server
Что мы сделали, чтобы настроить Project Server под свои нужды, описанные выше?
Для построения отчетности в интересующих нас разрезах существует несколько технических возможностей, которые предоставляет Project Server 2010:
1. Использование одной из баз данных Project Server (о том, как конфигурировать здесь).
Результат с помощью Pivot таблиц публикуется в Excel Services:
2. Использование OLAP-кубов, встроенных в Project Server (как конфигурировать тут).
В Excel выглядит так:
Список полей, доступных в аналитическом кубе:
В нашем случае мы столкнулись с тем, что оба способа имеют серьезные недостатки.
С точки зрения структуры данных:
- Необходимо уметь фильтровать сотрудников по признакам «уволен» или «работает», т.к. за 10 лет истории компании база пользователей Project Server накопила довольно большой архив.
- В измерении времени нужно иметь возможность строить отчеты по реальным месяцам, а не по фискальным периодам, т.к. они ложатся в основу табелей учета рабочего времени для бухгалтерии и впоследствии загружаются 1С.
- В измерении сотрудника нужно понимать следующие вещи: a. Принадлежность к структурному подразделению компании: Россия, Америка или внешние организации-контрактеры; b. Табельный номер сотрудника в 1С; c. Адрес электронной почты для рассылки уведомлений о незаполненном вовремя отчете.
- Задачи проекта.
В публикации в Excel Services есть один, но важный недостаток: при большом объеме данных (см. количество проектов, сотрудников, задач в нашей системе выше) любое применение фильтра приводит к выполнению запроса на БД, а это — время на ожидание результатов и построение самого отчета.
У OLAP-кубов тоже есть нюанс: они разбиты на серию различных кубов с разбросанными по ним данными, например, задачи в одном, а time sheets в другом. В целом, кубы больше заточены на анализ портфеля, чем на Ad Hoc-работу.
Что мы сделали для обеспечения своих нужд:
За основу построения OLAP-куба мы взяли стандартный sql-запрос от MicroSoft’a к Project Server, немного доработав его под наши нужды. В частотности внесли изменения во временные периоды, т.к. нам важно иметь два измерения — по реальным неделям и по рабочим неделям, добавили электронный ящик сотрудника и признак «уволен».
Из-за удалённости сервера нам пришлось сделать небольшой SSIS пакет для «перекачки» данных во временную таблицу. После этого мы сделали полученную таблицу источником данных для нашего куба, добавили необходимые измерения и меру.
Для обеспечения актуальности создали sql-джоб для получения данных, а затем и процессинга куба.
Практика показала — сотрудникам свойственно забывать, что отчеты о потраченном времени нужно заполнять еженедельно. Для это мы написали небольшой SSIS-пакет, который выполняет MDX-запрос к кубу, определяет «забывчивых» сотрудников и отправляет письмо с просьбой заполнить таймщит. При этом если сегодня пятница, то проверяется текущая неделя, а если понедельник, вторник или среда, то прошлая.
Отдельно остановимся на возникшей с данным пакетом проблемой. Она заключалась в том, что фактически sql-джоб, выполняющий данный пакет «живет» по часовому поясу GMT+6. Нашим американским коллегам необходимо отправлять напоминание в их пятницу в 17:00, а в Новосибирске это уже суббота 5:00 (либо 4:00 в зависимости от перевода часов в США), и так как рабочая неделя в кубе начинается с субботы, всем коллегам из США приходило письмо, что отчет не заполнен. Решение данной проблемы лежит на поверхности и заключается в добавлении дополнительного условия проверке текущего дня недели.
Результат
Вот что у нас получилось, примеры некоторых отчетов:
1. Отчет за период по всем сотрудникам. Еженедельно менеджеры просматривают табели всех сотрудников – контролируют сам факт заполнения и правильность разноски трудозатрат по проектам.
2. Отчет по проекту. После окончания проекта менеджеры могут проанализировать, как прошла реализация: какие задачи фактически были сделаны, сколько ресурсов на них потрачено, насколько это соответствует нашим изначальным планам на проект. Это же можно контролировать и по ходу проекта.
3. Отчет по сотруднику. В любой момент можно проанализировать деятельность отдельно взятого сотрудника по проектам за интересующий период.
- Все сотрудники EastBanc заполняют минимум по 40 часов, так как у нас 40-часовая неделя. Заполняют вовремя!
- Сотрудники заполняют таймщиты правильно: отпуска, больничные, праздники, проекты, на которых они работают, в том числе и внутренние, — всё разносится по нужным графам.
- Задачи на проектах соответствуют плану, т.к. они достаточно детализированы. Нет задач больше 16 часов, чтобы вовремя спохватиться, когда что-то идет не так.
- По завершению каждого проекта менеджеры получают подробнейший анализ.
- Каждый менеджер следит за своими проектами. За картиной в целом следит менеджер проектного офиса.
Сейчас мы имеем очень удобный enterprise-инструмент, которым вся компания пользуется каждый день. Сделать все удалось с помощью улучшения существующих стандартных средств Project Server за очень ограниченное время, т.к. стояла задача, не изощряясь и не изобретая велосипед, быстро решить проблему учета трудозатрат.