Похоже...
Очень похоже....

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

Именно поэтому, я близко к сердцу воспринимаю ПРОБЛЕМЫ ПРОЕКТА:
* Уровень подготовки участников проектной группы, их реальное знакомство с функциональностью смежных модулей и последний раз фразу "я отстаиваю интересы SD" я слышал от внешнего консультанта, а сотрудники моей группы способны реально оценить, как их очередная "хотелка" зацепит другой модуль....
* Удержание сотрудников проектной группы - всякое подписание нового контракта SAP'ом в регионе - очередная головная боль на тему "кого потеряем, кем можно поддержать направление?". Благо, что в оценке этой "ПРОБЛЕМЫ" я не одинок и пока нахожу общий язык с топами.
* Способность разработчика правильно понять поставленное Техническое задание и вести с постановщиком реальный диалог об оптимальных путях решения задачи!

И что самое удивительное,
специалисты по функциональным направления, которые постоянно участвую в мелких/крупных проектах у себя в подписи электронной почты пишут, что они "Аналитики по направлениям",
а вот "базисники" до сих пор: "SAP Project System Administrator", хотя проект в котором они принимали активное участие уже очень давно завершился!

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

Граждане.
Проектный менеджмент это не исключительно консалтинговое "Ноу-хау".

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

SAP Project System Administrator - улыбнуло.
Системный администратор проекта SAP, а не SAP-системы.

Chirva - поддерживаю это то что я имела в виду , смежные модуля должны знать что могут зацепить друг у друга .
Далее по поводу жизни проекта - он таки должен завершится , я имею в виду проект внедрения . Но на смену приходит ПРОЦЕСС работы в SAP... то изменилось законодательство , то расширился / изменился бизнес и т.д.
То есть SAP все время требует внимания и доработок.
Кстати ... при покупки программы это нигде Исполнителем не акцентируется ... а это доп затраты и немаленькие. По этому я таки за собственную подготовленную команду.
А риски ... риски есть всегда.

И вы начинаете проект. У вас появляется явная цель и объем работ.
Вы с руководством в той или иной форме согласовуете сроки выполнения.
И у вас есть бюджет. (Зарплата ваших сотрудников и/или затраты на консалтинг)




А какая система не требует доработок?
Например, изменился НДС.
Хоть SAP, хоть OEBS, хоть 1С, даже если у вас всё в ёкселе, все равно, прийдется вдорабатывать/переделывать.

murenets, не согласна это уже не проект , а процесс . Так как нет ни цели ни объема.
Есть возникающие потребности , которые необходимо решать по мере поступления + контроль работы системы.
Проект - это четко обозначенные временные + функциональные рамки.
Про развитие и поддержку программы этого сказать нельзя.
Естественно бюджет есть (странно было бы если бы его не было) , но опять таки в любой компании есть бюджет у каждого подразделения (что опять таки не связано с проектом).
Хммм... по поводу доработок с 1С я работала много лет и с 7.7 и с 8.0 , скажу я вам там намного проще решались все вопросы по изменения .

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



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



Ну и сам 1С намного проще.

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

Будете или не будете обзывать проектом это дело ваше.
Но проектом она-то от этого не перестанет быть.

Коллеги, Разделите процесс Service Desk от реализации изменений . Почитайте про процесс Change Request Management - управление запросами на изменение. Можете его реализовать хотя бы на базе Solution Manager. Классический Service Desk не требует экспертных знаний. Крупные дополнительные реализации процессов либо изменения в системе необходимо реализовывать отдельными проектами. Если у вас их много лучше агрегировать в программу проектов. Понимание необходимости разделения функций и проектов лежат исключительно в зрелости проектного управления в компании.
Фраза про покупку программы у Исполнителя - улыбнула
Есть вендор – который имеет авторские права и развивает систему . Есть лицензионный договор покупки и сопровождения лицензий на эту систему. Есть Исполнитель который внедряет систему. Есть клиент который не хочет разбираться, кто за что отвечает и в случае отсутствия компромисса реализации большинства БП получает значительную кастомизацию которую вендор уже поддерживать не будет. И не надо про 1С, которые узнают информацию по изменениям еще до его официального выхода. Если вы существенно кастомизируете систему, то 1С поддержка вам тоже не поможет. У нее есть свои существенные минусы если только вы не рассматриваете ERP систему как в помощь бухгалтеру.

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

это не большая проблема.

это следствие возможно большой проблемы.

а в чем причина?

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