Компания
140,93
рейтинг
12 декабря 2013 в 10:33

Разное → 2000 человек, 3K проектов в год: что такое PPM, и зачем это нужно вам tutorial

image
Пример ресурсного плана, где мы видим распределение сотрудников по задачам на несколько месяцев вперёд. У одного из них будет перегрузка через 3 месяца.

Одна из главных проблем руководителя — это получение актуальной информации о ходе проектов, за результаты которых он отвечает. По моей практике, до внедрения PPM руководители тратят очень много времени просто на то, чтобы проверить, что всё везде идёт по плану. Грубо говоря, 60% рабочего времени может уходить просто на то, чтобы понять, что все справляются, и вмешиваться не надо. С другой стороны, после внедрения PPM всю эту работу делать уже не надо – она делается автоматически системой. А вам только приходят алерты для ситуаций, в которых требуется внимание. Получается удобный и очень практичный инструмент управления по исключениям.

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

Что делают такие системы? Если кратко, Project & Portfolio Management позволяют увидеть статус любого проекта в любой момент с нужным уровнем детализации. Дают возможность правильно распределять ресурсы и загрузку сотрудников. Помогают тому, чтобы проекты попадали в бюджет, срок и качество.

Предпосылки внедрения PPM


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

Вторая причина – это когда компания вырастает и решает отслеживать статус своих проектов, плюс реально экономить при распределении ресурсов. Руководитель обычно чувствует такую необходимость довольно просто: когда он не может точно сказать, что прямо в деталях происходит на каждом проекте. Значит, пора что-то внедрять. Дело в том, что после внедрения руководитель получает очень полезный инструмент контроля и управления: ему теперь не надо пинать своих подчинённых каждый день, уточняя, что и как пошло. Достаточно заглянуть в PPM.

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

Кому это надо? Тем, кто вырос за обычные трекеры или CRM. У кого одновременных проектов больше десятка, и везде множество переменных и ресурсов. Например:
  • ИТ-компания и ИТ-отделам крупных компаний.
  • Банкам, особенно, запускающим множество тестовых проектов.
  • Нефтегазовой сфере.
  • Крупным рекламным агентствам со множеством подразделений.
  • Производственным объединениям c 5-6 производствами в разных точках.
И так далее.

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

Примеры внедрений



У себя в компании мы поставили CA Clarity PPM.
У нас тысячи проектов по IT-обслуживанию компаний, и они в большинстве предполагают работу далеко не одной команды. Раньше был довольно развитый трекер для постановки задач, отдельная финансовая система, отдельная система контроля ключевых точек. То есть получалось, что сотрудники использовали как минимум три (а чаще – больше) независимых инструмента: один для постановки задач, один для отчётов и координации с другими командами, и ещё один для финансов. Это неудобно, но в целом – нормально. При этом нам хотелось решить ещё сразу несколько вопросов. Например – сделать так, чтобы каждый планировал не как умеет, а в единых стандартах с другими. Во-вторых, по факту не было возможности ухватить общую картину: рабочий день мог начинаться с обзвона всех руководителей команд и получения статусов. Пока всех не обзвонишь – не поймёшь, как идёт процесс. Не было, соответственно, и единого пространства, где можно было посмотреть сразу всё – надо было лазить по куче подсистем и сравнивать отчёты. Плюс трудоёмкость проведения планового факт-анализа – например, чтобы ответить на вопрос — сколько и каких специалистов нужно, чтобы закончить проект на месяц быстрее, приходилось опять же всех обзванивать и считать руками.

image

Сейчас новая система интегрирована с CRM, системой учета тендеров, системой управления контрольными точками, системой микроменеджмента (привычным трекером), HRMS, HP SM, BPM, ERP, IBM WebSphere (ESB), системой аналитической отчетности. Всё это более чем на 2100 сотрудников, позволяет вести под 3000 проектов ежегодно. Есть сквозной контроль над проектами, и есть получение актуальной, полной и непротиворечивой отчетности. Понятно, что для многих переход означал несколько болезненное переобучение, но сейчас — все счастливы.

Для одной рекламной компании делали корпоративную систему управления проектами.
Была проведена единовременная миграция инсталляций Microsoft Project Server 2007 и Microsoft Project Server 2003 на платформу MS Project Server 2010, а также интеграция системы с корпоративными системами DevTrack и TFS. Основными пользователями системы являются руководители проектов и участники проектных команд. Главный функционал: управление сроками, управление ресурсами, работа с проектной документацией, координация действий участников проектов.

Одному крупному банку нужна была реализация инструмента централизованного управления сроками и ресурсами проектов по переформатированию точек обслуживания клиентов.
В ходе проекта было выполнено проектирование и внедрение системы на базе Microsoft Project Server 2010, проведено обучение ключевых пользователей. На выходе: управление проектами и программами, контроль над соблюдением сроков, контроль качества проектов, координация усилий всех участников проектов, создание единого информационного пространства проектов, отслеживание хода выполнения проектов, формирование сводной отчетности по проектам.

Ну и для ещё одной компании интегрировали Oracle Primavera EPPM с порталом на базе Microsoft SharePoint.
Получилось создание единого информационного пространства, обеспечение оперативной коллективной работы проектных групп, обеспечение оперативного управления проектами и координация использования ресурсов, контроль выполнения задач проектов, ведение отчетности по задачам проектов.

Какие задачи решаются?


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


Чем это всё отличается от трекеров?


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

Кто выигрывает от внедрения?


  • Руководитель компании. Он сразу получает инструмент «держать руку на пульсе» всего с любой глубиной погружения.
  • Финансовый директор. Он понимает, как лучше планировать и распределять финансовые ресурсы, необходимые для реализации проектов.
  • Директор по персоналу. Получает информацию о текущей и плановой утилизации сотрудников, плановой потребности в специалистах.
  • Руководители направлений. Те же профиты, плюс они точно знают, что и как у них идёт, где и что может быть рисковым, на что обратить внимание.
  • Проект-менеджеры — на их уровне это расширенный менеджмет задачи с возможностью видеть ситуацию с разных сторон. А ещё частично снимается вечная проблема с тем, что кто-то в цепочке раньше что-то не сделал или накосячил, а виноват PM — это особенно важно для задач, где до вас работают другие независимые компании.
  • Члены команд — есть чёткие задачи, есть напоминалки, никто не ставит задач не по профилю, плюс всегда известно, что делать.

Что вообще умеет PPM и как выбирается конкретная система?


На рынке PPM решений я вижу четкую разбивку систем на три типа. Во-первых, это «монстры» или core-системы, в которых есть все модули управления проектами, которые можно придумать, (от стратегического управления до планирования операционной деятельности). Они ставятся на сервера компании и потихоньку становятся своего рода кровеносной системой бизнеса, проникая во все процессы без исключения. Внедрение идёт долго, сложно, но из-за 20-летней эволюции таких решений предусматриваются почти все проблемы крупного бизнеса. Есть системы, где нет почти ничего – только базовая отчётность и мало аналитики. И есть решения, которые лежат где-то в середине, позволяющие, с одной стороны, легко развернуться, а с другой – достаточно гибкие для модернизаций.

«Монстры» PPM


Среди «монстров» на отечественном рынке мне чаще всего встречаются следующие решения:
  • CA Clarity
  • HP PPM
  • Oracle Primavera
  • Microsoft Project Server

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

Все перечисленные системы хороши в зависимости от компаний и типов задач. В моей практике одна компания выбирала себе решение из примерно такого же списка 11 месяцев: две недели составлялся шортлист, потом специалисты компании обучались у каждого поставщика, затем – прогоняли некие тестовые проекты в демо-версиях на реальных данных. То есть, по сути, всё это время корректировал техзадание и требования. Через 11 месяцев система была выбрана, 3-4 месяца внедрялась первая версия и оставшееся время делалась миграция исторических данных + обучение пользователей.

Современные гибкие решения


Но не всегда хочется переделывать весь бизнес и менять мировоззрение на процессы в нём, и не всегда хочется строить новую ИТ-инфраструктуру для PPM.

Гораздо чаще есть локальные задачи вроде ведения портфеля проектов и оценки того, как и что в нём происходит. В таких случаях практически идеальными становятся решения, которые быстро развёртываются в облаке и «закрывают» самые горячие задачи. В России сейчас постепенно появляются решения этого класса, а Gartner уже ставит их в свой квадрат и объясняет, для какого бизнеса они актуальнее «монстров». Одно из таких решений — KeyedIn Projects, которое работает из «облака», но может быть развернуто и в инфраструктуре компании. Ниже пример как раз про «облачный» вариант работы по одной из задач.

Пример управления ресурсами


Распределение ресурсов – одна из типичных задач для многих организаций и структур, особенно сервисных. Это может быть:
  • Оценки, какие сотрудники понадобятся, если вы возьмёте в работу новый проект.
  • Оценки, что в первую очередь нужно делать в IT-проектах компании и в каком порядке.
  • Распределение задач в проектном офисе.
  • Планирование проектов с учетом загрузки ресурсов.

И так далее. Итак, делается это так. Сначала каждый проект получает приоритет. В случае IT-департамента можно посчитать, какие вещи окажут наибольшее влияние на прибыль компании в итоге, либо поставить всё по данным руководителя.

image
Пример анализа сценария по портфелю проектов. Предположим, мы хотим «повесить» IT-департаменту новую задачу. Смотрим, что изменится в графике — и видим загрузку по ролям. По одному из направлений — перегрузка в ближайшие 4 месяца (скорее всего – требуется ещё сотрудник). Так мы видим, как выбранная нами конфигурация портфеля проектов влияет на загрузку сотрудников.

Нужно распределять не просто людей, а роли, плюс учесть наличие оборудования, время, возможности и вообще кучу деталей, включая навыки каждого ресурса в проекте. То есть в части стратегического планирования мы говорим о том, что есть возможность сопоставлять capacity (ресурсные возможности) компании с тем, какие роли и в каком объеме требуются для реализации каждого проекта и портфеля проектов в целом. При этом можно проводить сценарный анализ. То есть для каждого проекта могут быть разные сценарии выделения ресурсов — к примеру, как работать при оптимистичном прогнозе хода проекта или при пессимистичном. Или что делать, если финальный релиз получится раньше графика, либо задерживается. Это называется «What If — анализ».

Другая сильная сторона KeyedIn Projects — это возможность навести порядок в «головах» руководителей проектных офисов. В системе можно структурировать все проекты, посмотреть по каждому из них статусы, кто занимается, хорошо идет или плохо, нужно ли предпринимать контрмеры. Руководить офисом, где ведется, начиная от десятков и заканчивая тысячами проектов без такого инструмента просто невозможно.

image
Панель руководителя. Видим 4 проекта в группе – и последние статусы светофором «бюджет, результаты, ресурсы». Если «желтый» или «красный» – значит, нужна наша реакция.

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

image
Панель пользователя – данные для работы: задачи, списание рабочего времени, назначенные действия по управлению рисками и проблемами.

Сколько занимает внедрение?


Как правило, core-системы «уровня ОС» типа HP PPM или Clarity внедряются от полугода, в зависимости от широты выбранного заказчиком функционала. Очень много времени уходит на перенос процессов и данных внутрь системы, плавную миграцию и так далее. Обычно на 3-4-й месяц переходит один отдел, потом это делается для остальных. В конце внедрения пользователи ещё пару месяцев постоянно звонят в хелпдеск спрашивать, как что-то делать, потом привыкают и радуются. Или печалятся, если раньше ничего не делали, а теперь это всплыло. Такое тоже бывает.

Системы под конкретные задачи вроде KeyedIn – пару месяцев, причём большая часть времени – это сбор данных и их перенос в систему. Если развёртывание идёт в облаке – то ещё меньше.

Если кому интересно, систему можно протестировать в «облаке» у вендора. По запросу можем разместить систему и в публичном облаке КРОК (как сервис).

По конкретным системам и конкретным ценам – могу подсказать в личке, или пишите на AlKiselev@croc.ru. Туда же можно отправить вопросы, которые вы не хотите (или не можете) задавать в комментариях.
Автор: @alkiselev
КРОК
рейтинг 140,93

Комментарии (36)

  • +2
    Странно, судя по некоторым скриншотам, делались они 11.12.2013, а загрузка сотрудников на текущий и следующие месяцы отсутствует…
    • 0
      Это потому что для скриншотов использовалась тестовая база данных.
  • 0
    я пропустил расшифровку «РРМ» или её действительно нет в тексте?
    • 0
      Project & Portfolio Management, есть в тексте
    • 0
      Project & Portfolio Management, вот ссылка на английскую Википедию.
      UPD: в тексте явно прописал после вашего комментария, была в теге.
      • +2
        На теги сходу как-не посмотрел.

        Мы еще не очень большие, но уже некоторые неудобства с кучей трекеров (продажи, внедрение, сапорт, разработка, финансовая отчетность) начинают надоедать. Очень ко времени ваша статья, спасибо.
  • 0
    День добрый!

    каков порядок затрат по KEYEDIN?
    на их сайте инфо отсутствует.
    • 0
      Стоимость внедрения будет зависеть от нескольких факторов. От срока, за который делается предоплата, от длительности подписки, от широты функционала, от того, своими силами настраиваете, интегрируете и пр. или нет. Если говорить только про лицензии, то в среднем это несколько десятков долларов за пользователя в месяц (от $10 и выше).
      • 0
        понял, спасибо!
        • 0
          Будут вопросы или сложности — пишите на мою почту в конце топика, поможем разобраться.
  • +1
    Дело очень важное и архинужное.
    Я делал систему учета трудозатрат сам, консолидируя данные из кучи систем (кадры, бюджетирование проектов, данные о трудозатратах с трекера и так далее). На выходе были отчеты о трудозатратах, карточки сотрудников, карточки проектов и так далее. База была сделана на MS SQL Server, отчетность и карточки — MS Reporting Services.

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

    Вот примеры того, что можно было получить на выходе.

    Отчет по долям трудозатрат на разных типах проектов:
    image

    Карточка сотрудника:
    image

    И это в системе, сделанной «на коленке».
    Так что я могу оценить важность и нужность профессионально развернутой и настроенной системы, объединяющей всё и вся. Для компании внедрение такой системы — это просто прорыв. Очень здорово.
    • +2
      Вижу, была проделана серьезная работа, респект! Через использование самодельных решений на Excel многие компании проходили.

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

      Многие компании как раз и ищут замену своим решениям на Excel. Кстати, в KeyedIn кроме прочего можно учитывать списания трудозатрат сотрудниками на проекты и многие другие вещи, недоступные при использовании Excel.
      • 0
        Спасибо!
        Это был Excel только в самом начале.
        Когда он начал пересчитывать сводные таблицы по 20 минут, я перевёл работу на MS SQL Server.
        Excel хорош в начале таких проектов: покрутить так и сяк небольшие наборы данных, прикинуть, что можно из них получить и как. А когда на вход начинают подаваться реальные данные — лучше переходить на СУБД.
        С MS SQL Server работать еще хорошо тем, что к нему прилагается MS SQL Reporting Services. И — вуаля! :)
      • 0
        У меня, кстати, есть пара вопросов по вашей системе.
        1. Есть ли интеграция с Jira?
        2. Есть ли интеграция с MS TFS?
        • +2
          Наверное, вы про KeyedIn. На данный момент существует интеграция с SAP Business One, MS Dynamics Ax, Salesforce и рядом других систем. С точки зрения архитектуры KeyedIn интегрируется с другими системами (как облачными, так и установленными у заказчика) через web-сервисы. Для ускорения интеграции можно бесплатно использовать платформу Jitterbit (там есть много встроенных коннекторов). Интеграция с Jira сейчас в разработке, по планам должны реализовать в январе-феврале.

          Запланирована следующая логика:
          — KeyedIn используется для укрупненного планирования проектов, на задачи назначаются руководители групп разработчиков;
          — Такой же проект автоматически создается в Jira c задачами и назначенными руководителями, которые Jira создают подзадачи, распределяют их разработчикам;
          — Разработчики отчитываются по срокам работ и трудозатратах, эти данные агрегируются и на уровне задач передаются обратно в KeyedIn.
          Итого имеем укрупненное управление задачами KeyedIn и использование разработчиками привычного инструмента.

          Интеграции с MS TFS пока в планах нет, надо понимать в каком объеме и для чего требуется, остальное дело разработчиков.
          • 0
            Спасибо!
  • 0
    «после внедрения PPM всю эту работу делать уже не надо – она делается автоматически системой»

    Вот прям таки само все делается? Или все же нужно сотрудникам дырку в голове сверлить «Укажи прогресс задачи!», «Затрекай потраченное время!», что сотрудники так любят игнорировать, считая (зачастую, небезосновательно) абсолютной ерундой?
    • 0
      Есть системы полуавтотрекинга, там сотруднику надо прикладывать минимум усилий. А чтобы минимум прикладывался — ну да, поначалу надо немножко поменять сознание сотрудников. Через какое-то время они сами оценят систему, для них там тоже куча пряников имеется. У примеру, никто не может подойти к разработчику и сказать: «все бросай, занимайся вот этой новой задачей».
      • 0
        Какая же это плюшка? Вы отняли у разработчика возможность сказать «Не готово, потому что все бросил и занимался вот той новой задачей» одному и «Не готово, потому что у меня кроме этой задачи есть и другие» другому. Еще один минус системе.
        • 0
          Никто ничего не отнимал.
        • +1
          Главное, чтобы разработчик не говорил так одновременно. Я, к сожалению, сталкивался с такими случаями.

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

          «Автоматически делается системой» не сам ввод данных (хотя частично можно сделать и так — авторасчеты статусов на основе данных из других систем), а сбор, анализ и демонстрация текущего статуса менеджеру.
          Просто если без ppm менеджер вынужден 1) пинать сотрудников о регулярных отчетах и 2) сводить и анализировать их по каким-то параметрам, то при автоматизации, по крайней мере, становится попроще со вторым пунктом.
  • +1
    Насчет того что от этого выиграют члены команд и менеджеры-не уверен. Обычно такие системы требуют чтобы задачи постоянно поддерживались в актуальном состоянии, то есть членам команд придется писать отчеты о проделанной работе каждый день. А так как у таких систем возможна и почасовая шкала-то надо чтобы человек помнил-что он делал за каждый час. А если человек делал задачу которой нет в таблице? Тогда придется просить менеджера добавить ее в таблицу чтобы можно было о ней отчитатся. В общем, я не согласен с тем что административной работы станет меньше.
    • +1
      Любая задача должна сначала появляться в таблице. И это же не просто таблица. Это БД рабочих элементов, которые могут быть самыми разными и каждый из них может иметь свой жизненный цикл. Это похоже на электронный документооборот.
      Пока проекты небольшие и задач мало — это не играет роли и ни на что не влияет.
      Но когда количество проектов измеряется сотнями и тысячами, а количество задач — десятками тысяч, без подобной системы просто не обойтись.
    • +1
      А если человек делал задачу которой нет в таблице? Тогда придется просить менеджера добавить ее в таблицу чтобы можно было о ней отчитаться.

      Мы делали подобную систему для заказчика. Изначально в ней были только четко определенные задачи, по которым был проложен единственно верный маршрут (называлось это «карта процессов»). Через некоторое время руководитель попросил добавить возможность сотрудникам самим добавлять в таблицу «другие дела» — те задачи, которым не нашлось места в жесткой структуре процесса, но которые периодически возникают и выполняются.
    • +1
      Соглашусь с тем, что отчитываться никто не любит.

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

      Для того чтобы люди отчитывались – необходимо их мотивировать и стимулировать. Но это уже отдельная тема. Скажу только, что механизмы не должны отнимать время менеджера на выбивание отчетов.

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

      И при такой организации работы каждый будет делать в системе те действия, которые нужны ИМЕННО ЕМУ, а не кому-то другому, а именно:
      — менеджер выписывать, назначать и контролировать исполнение задач (чтобы они исполнялись, и проект шел вперед к победе)
      — сотрудник исполнять и закрывать в системе свои задачи, списывая на них потраченное время (чтобы формировать свой таймшит и повышать свои KPI от которых должны зависеть стимулирующие меры его поощрения, например).

      Ну и ниже очень правильный комментарий от S_A про то, что PPM и микроменеджмент — это всё-таки очень разные вещи.
      • +1
        От разработчика (тестировщика, интегратора) всей отчетности требуется — сколько часов над какой задачей он работал.
        Это 1-5 чисел в день.
        Если все задачи имеют ID, и каждая задача привязана к проекту — то дальше всё просто.
        Если что, устриц этих я ел.
  • +2
    Да уж. Если бы не упоминание систем, поддерживающих хоть в каком-то виде PPM каким он должен быть (Primavera например)…

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

    Организация и автоматизация сбора отчетности — это вообще подтема проектного управления, а то что там данные сливаются воедино — ну так и что. Данные должны агрегироваться и быть доступными для аналитики иного уровня. Ни один из перечисленных продуктов не позволяет проводить аналитику портфеля по всем возможным аспектам (но все поддерживают что-то из PPM). Например кстати, почему-то не вижу нашего Spider Project в списке.

    Я когда-то написал не одно ТЗ по автоматизации портфельного управления. И трекинг весь можно подтягивать из стандартных трекеров. Это всего лишь «первичка», выражаясь бухгалтерскими терминами. Основное — это та картина, которая может быть получена в результате обработки этой первички, а на основе которой можно принять решение:
    1. О приостановке, о закрытии проекта,
    2. Об открытии нового проекта, подпроекта,
    3. О переходе на следующий этап, фазу,
    4. Об изменении параметров проекта (сроков, бюджета, ресурсов, требований).
    5. Об изменении сразу нескольких проектов, программ. И, более того, возможно, об изменении страт. целей.

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

    Где об этом? После прочтения статьи сложилось ощущение, что у менеджеров вся работа заключена исключительно в контроле.

    P.S. Для тех, кому интересна тема PPM, могу порекомендовать книгу и книгу (начало как минимум и той и той).
    • 0
      Спорный вопрос, на самом деле.

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

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

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

      P.S. Если есть опыт по быстрому переходу от упрощенного тайм-ресурс-контроля до уровня портфельного управления — с удовольствием бы познакомился или почитал.
      • +1
        Заказчик трекинга и PPM на уровне балансировки — один. Высшее руководство. От этого и стоит плясать. Переход к портфельному управлению — тема больная для PPM, но в частности есть Кендалл-Роллинз и Бенко-Макфарлан.

        По поводу критичного, что отсутствует. Сравните Spider Project с Primavera. Для портфеля критично основное:
        1. NPV, IRR, и прочие фин. попугаи,
        2. Риски и их соотношение с показателями п.1,
        3. Реализуемость, ресурсная, финансовая, и прочая.

        What-if — конечно элемент анализа рисков. Но например в Project Server есть подбор оптимального портфеля. Хотя минус ему за то, что вклад проектов оценивается качественно (а не количественно).

        Самое критичное для портфеля, сколько я сталкивался с PPM — это соотношение дохода-риска, по типу ц.б. Но у меня своя теория по этому поводу, на защиту которой у меня нет времени, сил, эмоций, и чего бы то ни было еще (забил я на аспирантуру если вкратце:)). Где в примавере можно увидеть, какой портфель оптимален при заданном уровне риска? Покрутить, да, можно. Я не зря в своем коменте упомянул примаверу — из зарубежных решений — оно пожалуй самое мощное. Из наших — Spider.
  • +1
    Добавьте в монстров PowerSteering. Тыц.
    Система очень мощная. В плане планировщика даст прикурить Microsoft Project.
    В нашей стране используется вроде только в компании Pepsi.
  • 0
    РРМ — штука полезная, вот только есть ощущение, что среди большинства наших крупных компаний либо ничего о нем не знают.

    Насчет интеграции вот хотел спросить: HP SM — имелось в виду Service Desk? Идет ли интеграция через Agosense или у них своя реализация? И что используется для управления требованиями/demand mgmt?
    • 0
      Ответил вам чуть ниже.
  • 0
    Про PPM – уверен, знают многие (или все), но не все уверены в экономическом эффекте от внедрения. Особенно, если ресурсы, которыми надо управлять, стоят недорого. Но это, опять же, отдельная тема. А вот о том, что можно запустить такую систему у себя сравнительно быстро и без капитальных затрат (из «облака») – знают, похоже, действительно, не все.

    HP SM — речь об интеграции внедренной у нас CA Clarity с HP SM. Здесь, действительно, имеется в виду Service Desk и реализованы следующие принципиальные сценарии интеграции:
    1) Планируемые сервисные заявки (сервисные работы по плану, например, регулярное обслуживание инженером стендов в ЦОД) заводятся в Clarity менеджером проекта как задачи и синхронизируются в HP SM, где и обрабатываются инженерами.
    2) Внеплановые заявки – вводятся в HPSM (через коллцентр, обращения по емейлу и т.п.…), где и обрабатываются инженером и переносится в Clarity, где инженер может увидеть все свои задачи и списать время, формирую свой таймшит за период в единой для всей компании системе.
    Таким образом, каждый из исполнителей свою регулярную работу делает в привычной ему системе: менеджеры проектов – в Clarity, а инженеры – в HP SM.

    Реализована интеграция (как и интеграция с остальными системами) с помощь интеграционной шины, построенной на IBM WebSphere (ESB).

    Что касается управления требованиями (requirements management), то сейчас в компании используется специализированное ПО для решения этой задачи и в планах по развитию проекта стоит задача проработать вопрос о внедрении функциональности управления требованиями Clarity, либо реализовать интеграцию Clarity с используемым в настоящее время решением.
    • 0
      Хотелось бы почитать про WebSphere, компаний его пользующих у нас мало, а штука интересная. На хабре вводных статей о нем считай и нет.
      • 0
        Согласен. Спасибо за идею, постараемся написать в следующем году статью на тему интеграции, в том числе и про WebSphere. Но если у Вас вдруг сейчас есть какой-то конкретный вопрос по WebSphere, мой коллега Алексей Смирнов согласился помочь – asmirnov@croc.ru
  • 0
    Тема очень интересная, но скорее всего очень сложно внедряемая на уровне российской компании. А проблема в том, что у нас не работает классический треугольник проектного управления, хочешь не хочешь, но модель русского управления и бизнеса всегда требует где-нибудь но поставить разрыв, то между финансами и сроками, то между сроками и качеством =)

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

Самое читаемое Разное