Комментарии 36
НЛО прилетело и опубликовало эту надпись здесь
я пропустил расшифровку «РРМ» или её действительно нет в тексте?
Project & Portfolio Management, есть в тексте
Project & Portfolio Management, вот ссылка на английскую Википедию.
UPD: в тексте явно прописал после вашего комментария, была в теге.
UPD: в тексте явно прописал после вашего комментария, была в теге.
День добрый!
каков порядок затрат по KEYEDIN?
на их сайте инфо отсутствует.
каков порядок затрат по KEYEDIN?
на их сайте инфо отсутствует.
Стоимость внедрения будет зависеть от нескольких факторов. От срока, за который делается предоплата, от длительности подписки, от широты функционала, от того, своими силами настраиваете, интегрируете и пр. или нет. Если говорить только про лицензии, то в среднем это несколько десятков долларов за пользователя в месяц (от $10 и выше).
НЛО прилетело и опубликовало эту надпись здесь
Вижу, была проделана серьезная работа, респект! Через использование самодельных решений на Excel многие компании проходили.
В таких случаях через какое-то время наступает момент, когда вы понимаете, что поддерживать в полуручном режиме несколько десятков проектов становится очень сложно, проджект менеджеры и обычные пользователи не всегда будут вовремя присылать свои данные, которые постепенно будут терять актуальность.
Многие компании как раз и ищут замену своим решениям на Excel. Кстати, в KeyedIn кроме прочего можно учитывать списания трудозатрат сотрудниками на проекты и многие другие вещи, недоступные при использовании Excel.
В таких случаях через какое-то время наступает момент, когда вы понимаете, что поддерживать в полуручном режиме несколько десятков проектов становится очень сложно, проджект менеджеры и обычные пользователи не всегда будут вовремя присылать свои данные, которые постепенно будут терять актуальность.
Многие компании как раз и ищут замену своим решениям на Excel. Кстати, в KeyedIn кроме прочего можно учитывать списания трудозатрат сотрудниками на проекты и многие другие вещи, недоступные при использовании Excel.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Наверное, вы про KeyedIn. На данный момент существует интеграция с SAP Business One, MS Dynamics Ax, Salesforce и рядом других систем. С точки зрения архитектуры KeyedIn интегрируется с другими системами (как облачными, так и установленными у заказчика) через web-сервисы. Для ускорения интеграции можно бесплатно использовать платформу Jitterbit (там есть много встроенных коннекторов). Интеграция с Jira сейчас в разработке, по планам должны реализовать в январе-феврале.
Запланирована следующая логика:
— KeyedIn используется для укрупненного планирования проектов, на задачи назначаются руководители групп разработчиков;
— Такой же проект автоматически создается в Jira c задачами и назначенными руководителями, которые Jira создают подзадачи, распределяют их разработчикам;
— Разработчики отчитываются по срокам работ и трудозатратах, эти данные агрегируются и на уровне задач передаются обратно в KeyedIn.
Итого имеем укрупненное управление задачами KeyedIn и использование разработчиками привычного инструмента.
Интеграции с MS TFS пока в планах нет, надо понимать в каком объеме и для чего требуется, остальное дело разработчиков.
Запланирована следующая логика:
— KeyedIn используется для укрупненного планирования проектов, на задачи назначаются руководители групп разработчиков;
— Такой же проект автоматически создается в Jira c задачами и назначенными руководителями, которые Jira создают подзадачи, распределяют их разработчикам;
— Разработчики отчитываются по срокам работ и трудозатратах, эти данные агрегируются и на уровне задач передаются обратно в KeyedIn.
Итого имеем укрупненное управление задачами KeyedIn и использование разработчиками привычного инструмента.
Интеграции с MS TFS пока в планах нет, надо понимать в каком объеме и для чего требуется, остальное дело разработчиков.
«после внедрения PPM всю эту работу делать уже не надо – она делается автоматически системой»
Вот прям таки само все делается? Или все же нужно сотрудникам дырку в голове сверлить «Укажи прогресс задачи!», «Затрекай потраченное время!», что сотрудники так любят игнорировать, считая (зачастую, небезосновательно) абсолютной ерундой?
Вот прям таки само все делается? Или все же нужно сотрудникам дырку в голове сверлить «Укажи прогресс задачи!», «Затрекай потраченное время!», что сотрудники так любят игнорировать, считая (зачастую, небезосновательно) абсолютной ерундой?
НЛО прилетело и опубликовало эту надпись здесь
Какая же это плюшка? Вы отняли у разработчика возможность сказать «Не готово, потому что все бросил и занимался вот той новой задачей» одному и «Не готово, потому что у меня кроме этой задачи есть и другие» другому. Еще один минус системе.
НЛО прилетело и опубликовало эту надпись здесь
Главное, чтобы разработчик не говорил так одновременно. Я, к сожалению, сталкивался с такими случаями.
Конечно, низкая дисциплина сотрудников — это не повод внедрять систему, а повод поработать с персоналом. Но, согласитесь, уровень ответственности при наличии системы трекинга (в любом виде) повышается.
Наличие автоматических рассылок-напоминаний, наглядного интерфейса с красными значками напротив просроченных задач (или же задач, требующих указания комментариев и статуса), а также самого факта наличия системы ввода и контроля проектной информации сильно упрощает работу менеджера.
«Автоматически делается системой» не сам ввод данных (хотя частично можно сделать и так — авторасчеты статусов на основе данных из других систем), а сбор, анализ и демонстрация текущего статуса менеджеру.
Просто если без ppm менеджер вынужден 1) пинать сотрудников о регулярных отчетах и 2) сводить и анализировать их по каким-то параметрам, то при автоматизации, по крайней мере, становится попроще со вторым пунктом.
Конечно, низкая дисциплина сотрудников — это не повод внедрять систему, а повод поработать с персоналом. Но, согласитесь, уровень ответственности при наличии системы трекинга (в любом виде) повышается.
Наличие автоматических рассылок-напоминаний, наглядного интерфейса с красными значками напротив просроченных задач (или же задач, требующих указания комментариев и статуса), а также самого факта наличия системы ввода и контроля проектной информации сильно упрощает работу менеджера.
«Автоматически делается системой» не сам ввод данных (хотя частично можно сделать и так — авторасчеты статусов на основе данных из других систем), а сбор, анализ и демонстрация текущего статуса менеджеру.
Просто если без ppm менеджер вынужден 1) пинать сотрудников о регулярных отчетах и 2) сводить и анализировать их по каким-то параметрам, то при автоматизации, по крайней мере, становится попроще со вторым пунктом.
Насчет того что от этого выиграют члены команд и менеджеры-не уверен. Обычно такие системы требуют чтобы задачи постоянно поддерживались в актуальном состоянии, то есть членам команд придется писать отчеты о проделанной работе каждый день. А так как у таких систем возможна и почасовая шкала-то надо чтобы человек помнил-что он делал за каждый час. А если человек делал задачу которой нет в таблице? Тогда придется просить менеджера добавить ее в таблицу чтобы можно было о ней отчитатся. В общем, я не согласен с тем что административной работы станет меньше.
НЛО прилетело и опубликовало эту надпись здесь
А если человек делал задачу которой нет в таблице? Тогда придется просить менеджера добавить ее в таблицу чтобы можно было о ней отчитаться.
Мы делали подобную систему для заказчика. Изначально в ней были только четко определенные задачи, по которым был проложен единственно верный маршрут (называлось это «карта процессов»). Через некоторое время руководитель попросил добавить возможность сотрудникам самим добавлять в таблицу «другие дела» — те задачи, которым не нашлось места в жесткой структуре процесса, но которые периодически возникают и выполняются.
Соглашусь с тем, что отчитываться никто не любит.
Соглашусь и с тем, что часто это бывает небезосновательно, т.к. при подготовке отчета выясняется, что человек занимался не той задачей, которая ему была назначена, а занимался другой, которой ему было приятнее заниматься, например.
Для того чтобы люди отчитывались – необходимо их мотивировать и стимулировать. Но это уже отдельная тема. Скажу только, что механизмы не должны отнимать время менеджера на выбивание отчетов.
Выигрыш же менеджера и команды в том, что сотрудник четко знает что ему делать и за выполнение каких задач ему держать ответ. А менеджер лишний раз подумает прежде чем даст сотруднику новую задачу – видя его плановую загрузку.
И при такой организации работы каждый будет делать в системе те действия, которые нужны ИМЕННО ЕМУ, а не кому-то другому, а именно:
— менеджер выписывать, назначать и контролировать исполнение задач (чтобы они исполнялись, и проект шел вперед к победе)
— сотрудник исполнять и закрывать в системе свои задачи, списывая на них потраченное время (чтобы формировать свой таймшит и повышать свои KPI от которых должны зависеть стимулирующие меры его поощрения, например).
Ну и ниже очень правильный комментарий от S_A про то, что PPM и микроменеджмент — это всё-таки очень разные вещи.
Соглашусь и с тем, что часто это бывает небезосновательно, т.к. при подготовке отчета выясняется, что человек занимался не той задачей, которая ему была назначена, а занимался другой, которой ему было приятнее заниматься, например.
Для того чтобы люди отчитывались – необходимо их мотивировать и стимулировать. Но это уже отдельная тема. Скажу только, что механизмы не должны отнимать время менеджера на выбивание отчетов.
Выигрыш же менеджера и команды в том, что сотрудник четко знает что ему делать и за выполнение каких задач ему держать ответ. А менеджер лишний раз подумает прежде чем даст сотруднику новую задачу – видя его плановую загрузку.
И при такой организации работы каждый будет делать в системе те действия, которые нужны ИМЕННО ЕМУ, а не кому-то другому, а именно:
— менеджер выписывать, назначать и контролировать исполнение задач (чтобы они исполнялись, и проект шел вперед к победе)
— сотрудник исполнять и закрывать в системе свои задачи, списывая на них потраченное время (чтобы формировать свой таймшит и повышать свои KPI от которых должны зависеть стимулирующие меры его поощрения, например).
Ну и ниже очень правильный комментарий от S_A про то, что PPM и микроменеджмент — это всё-таки очень разные вещи.
Да уж. Если бы не упоминание систем, поддерживающих хоть в каком-то виде PPM каким он должен быть (Primavera например)…
Вообще говоря, PPM это не про трекинг. Точнее про трекинг далеко не в первую очередь, да и трекинг не совсем задачек-поручений специалистам. PPM — это принятие решений по портфелю. По портфелю! В привязке к стратегии. PPM в настоящее время — острие проектно-управленческой мысли и средоточие всей проблематики области.
Организация и автоматизация сбора отчетности — это вообще подтема проектного управления, а то что там данные сливаются воедино — ну так и что. Данные должны агрегироваться и быть доступными для аналитики иного уровня. Ни один из перечисленных продуктов не позволяет проводить аналитику портфеля по всем возможным аспектам (но все поддерживают что-то из PPM). Например кстати, почему-то не вижу нашего Spider Project в списке.
Я когда-то написал не одно ТЗ по автоматизации портфельного управления. И трекинг весь можно подтягивать из стандартных трекеров. Это всего лишь «первичка», выражаясь бухгалтерскими терминами. Основное — это та картина, которая может быть получена в результате обработки этой первички, а на основе которой можно принять решение:
1. О приостановке, о закрытии проекта,
2. Об открытии нового проекта, подпроекта,
3. О переходе на следующий этап, фазу,
4. Об изменении параметров проекта (сроков, бюджета, ресурсов, требований).
5. Об изменении сразу нескольких проектов, программ. И, более того, возможно, об изменении страт. целей.
Портфель даёт вклад в стоимость организации, повышение которой — цель корпоративного управления, а портфель — инструмент. И использование этого инструмента должно быть согласовано именно с этим.
Где об этом? После прочтения статьи сложилось ощущение, что у менеджеров вся работа заключена исключительно в контроле.
P.S. Для тех, кому интересна тема PPM, могу порекомендовать книгу и книгу (начало как минимум и той и той).
Вообще говоря, PPM это не про трекинг. Точнее про трекинг далеко не в первую очередь, да и трекинг не совсем задачек-поручений специалистам. PPM — это принятие решений по портфелю. По портфелю! В привязке к стратегии. PPM в настоящее время — острие проектно-управленческой мысли и средоточие всей проблематики области.
Организация и автоматизация сбора отчетности — это вообще подтема проектного управления, а то что там данные сливаются воедино — ну так и что. Данные должны агрегироваться и быть доступными для аналитики иного уровня. Ни один из перечисленных продуктов не позволяет проводить аналитику портфеля по всем возможным аспектам (но все поддерживают что-то из PPM). Например кстати, почему-то не вижу нашего Spider Project в списке.
Я когда-то написал не одно ТЗ по автоматизации портфельного управления. И трекинг весь можно подтягивать из стандартных трекеров. Это всего лишь «первичка», выражаясь бухгалтерскими терминами. Основное — это та картина, которая может быть получена в результате обработки этой первички, а на основе которой можно принять решение:
1. О приостановке, о закрытии проекта,
2. Об открытии нового проекта, подпроекта,
3. О переходе на следующий этап, фазу,
4. Об изменении параметров проекта (сроков, бюджета, ресурсов, требований).
5. Об изменении сразу нескольких проектов, программ. И, более того, возможно, об изменении страт. целей.
Портфель даёт вклад в стоимость организации, повышение которой — цель корпоративного управления, а портфель — инструмент. И использование этого инструмента должно быть согласовано именно с этим.
Где об этом? После прочтения статьи сложилось ощущение, что у менеджеров вся работа заключена исключительно в контроле.
P.S. Для тех, кому интересна тема PPM, могу порекомендовать книгу и книгу (начало как минимум и той и той).
Спорный вопрос, на самом деле.
Вы, безусловно, правы с той точки зрения, что внедрение комплексного ppm-решения не стоит начинать только ради перевода всей базы данных по проектам в многофункциональную систему, т.е. мигрировать с простенького трекинга в нечто более масштабное и заканчивать на этом.
Но это чаще всего — первый шаг. И один из самых болезненных, поскольку простоты для участников процесса уже нет (одно дело — внести одной строчкой информацию по проекту или задаче, и совсем другое — заполнить те же взаимосвязи, оценку трудозатрат, добавить сверху риски и т.д.), и при этом наглядной выгоды от таких действий еще нет — ни нормальной отчетности, ни статистики, ретроспективу сделать невозможно.
О портфеле, как о некоторой совокупности отдельных проектов, вообще речи не идет — ведь отсутствует даже полноценный контроль на уровне проектов.
Поэтому, на мой взгляд, верно отмечен сам тренд — необходимость, начиная с определенного момента, переходить на следующий уровень контроля и отчетности, т.е. на комплексную ppm, но для начала — на проектном, а не портфельном уровне.
Кстати, в примавере и clarity инструменты портфельного анализа все же достаточно серьезные — как минимум, система прав доступа, агрегация данных и планирование в обе стороны (от портфеля вниз или от проекта вверх), а также инструментарий балансировки проектов портфеля и what-if анализ на портфельном уровне. Есть еще что-то критичное, что отсутствует в этих продуктах?
P.S. Если есть опыт по быстрому переходу от упрощенного тайм-ресурс-контроля до уровня портфельного управления — с удовольствием бы познакомился или почитал.
Вы, безусловно, правы с той точки зрения, что внедрение комплексного ppm-решения не стоит начинать только ради перевода всей базы данных по проектам в многофункциональную систему, т.е. мигрировать с простенького трекинга в нечто более масштабное и заканчивать на этом.
Но это чаще всего — первый шаг. И один из самых болезненных, поскольку простоты для участников процесса уже нет (одно дело — внести одной строчкой информацию по проекту или задаче, и совсем другое — заполнить те же взаимосвязи, оценку трудозатрат, добавить сверху риски и т.д.), и при этом наглядной выгоды от таких действий еще нет — ни нормальной отчетности, ни статистики, ретроспективу сделать невозможно.
О портфеле, как о некоторой совокупности отдельных проектов, вообще речи не идет — ведь отсутствует даже полноценный контроль на уровне проектов.
Поэтому, на мой взгляд, верно отмечен сам тренд — необходимость, начиная с определенного момента, переходить на следующий уровень контроля и отчетности, т.е. на комплексную ppm, но для начала — на проектном, а не портфельном уровне.
Кстати, в примавере и clarity инструменты портфельного анализа все же достаточно серьезные — как минимум, система прав доступа, агрегация данных и планирование в обе стороны (от портфеля вниз или от проекта вверх), а также инструментарий балансировки проектов портфеля и what-if анализ на портфельном уровне. Есть еще что-то критичное, что отсутствует в этих продуктах?
P.S. Если есть опыт по быстрому переходу от упрощенного тайм-ресурс-контроля до уровня портфельного управления — с удовольствием бы познакомился или почитал.
Заказчик трекинга и PPM на уровне балансировки — один. Высшее руководство. От этого и стоит плясать. Переход к портфельному управлению — тема больная для PPM, но в частности есть Кендалл-Роллинз и Бенко-Макфарлан.
По поводу критичного, что отсутствует. Сравните Spider Project с Primavera. Для портфеля критично основное:
1. NPV, IRR, и прочие фин. попугаи,
2. Риски и их соотношение с показателями п.1,
3. Реализуемость, ресурсная, финансовая, и прочая.
What-if — конечно элемент анализа рисков. Но например в Project Server есть подбор оптимального портфеля. Хотя минус ему за то, что вклад проектов оценивается качественно (а не количественно).
Самое критичное для портфеля, сколько я сталкивался с PPM — это соотношение дохода-риска, по типу ц.б. Но у меня своя теория по этому поводу, на защиту которой у меня нет времени, сил, эмоций, и чего бы то ни было еще (забил я на аспирантуру если вкратце:)). Где в примавере можно увидеть, какой портфель оптимален при заданном уровне риска? Покрутить, да, можно. Я не зря в своем коменте упомянул примаверу — из зарубежных решений — оно пожалуй самое мощное. Из наших — Spider.
По поводу критичного, что отсутствует. Сравните Spider Project с Primavera. Для портфеля критично основное:
1. NPV, IRR, и прочие фин. попугаи,
2. Риски и их соотношение с показателями п.1,
3. Реализуемость, ресурсная, финансовая, и прочая.
What-if — конечно элемент анализа рисков. Но например в Project Server есть подбор оптимального портфеля. Хотя минус ему за то, что вклад проектов оценивается качественно (а не количественно).
Самое критичное для портфеля, сколько я сталкивался с PPM — это соотношение дохода-риска, по типу ц.б. Но у меня своя теория по этому поводу, на защиту которой у меня нет времени, сил, эмоций, и чего бы то ни было еще (забил я на аспирантуру если вкратце:)). Где в примавере можно увидеть, какой портфель оптимален при заданном уровне риска? Покрутить, да, можно. Я не зря в своем коменте упомянул примаверу — из зарубежных решений — оно пожалуй самое мощное. Из наших — Spider.
Добавьте в монстров PowerSteering. Тыц.
Система очень мощная. В плане планировщика даст прикурить Microsoft Project.
В нашей стране используется вроде только в компании Pepsi.
Система очень мощная. В плане планировщика даст прикурить Microsoft Project.
В нашей стране используется вроде только в компании Pepsi.
РРМ — штука полезная, вот только есть ощущение, что среди большинства наших крупных компаний либо ничего о нем не знают.
Насчет интеграции вот хотел спросить: HP SM — имелось в виду Service Desk? Идет ли интеграция через Agosense или у них своя реализация? И что используется для управления требованиями/demand mgmt?
Насчет интеграции вот хотел спросить: HP SM — имелось в виду Service Desk? Идет ли интеграция через Agosense или у них своя реализация? И что используется для управления требованиями/demand mgmt?
Про 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 с используемым в настоящее время решением.
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 с используемым в настоящее время решением.
Тема очень интересная, но скорее всего очень сложно внедряемая на уровне российской компании. А проблема в том, что у нас не работает классический треугольник проектного управления, хочешь не хочешь, но модель русского управления и бизнеса всегда требует где-нибудь но поставить разрыв, то между финансами и сроками, то между сроками и качеством =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
2000 человек, 3K проектов в год: что такое PPM, и зачем это нужно вам