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


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

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

помоему ПМ-ство это такой гимор, тебя со всех сторон домогаются

to АлексО:
если РМ не знает функционала, то как он:
1) Правильно спланирует время на выполнение задачи, проконтролирует исполнение?
2) Сможет контролировать качество проектной документации?
3) Отвечать на вопросы клиентов типа: как система расширит их горизонты? сделать грамотную презентацию и т.п.?
3) Общаться с консультантами на их языке и решать традиционные проектные проблемы (Мизантроп уже писал про это).

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

Татьяна, отвечу по пунктам на примере.
По первому пункту. Я веду план работ в проджекте. В проектах участвуют от 5 до 30 человек. На данный момент в зависимости от проекта, количество задач варьируется от 1000 до 3000. Даже если я буду знать функционал и тратить на планирование одной задачи одну минуту, на формирование плана будет уходить от двух до шести дней. В реальности у меня получалось не меньше недели. А ввиду того, что в нашей реальности объем задач меняется регулярно, у вас руководитель проекта будет только планировать и ничего более. Поэтому эффективнее всего для этого использовать руководителей функциональных направлений и архитектора.
По второму вопросу - Вы много встречали саперов, знающих систему в объеме ММ, FI, CO, PP, BW, достаточном для контроля качества?
А сколько сейчас проектов?
По третьему вопросу - тут достаточно иметь общее понимание о системе, на уровне вводных курсов, и подвешенный язык (вот это точно необходимо), а для детальных консультаций опять же лучше привлекать спецов. Здесь более всего выжны навыки продаж, нежели же бэкграунд консультанта.
А по поводу последнего - если руководитель проекта может и, что главное, хочет общаться с командой, он найдет общий язык.

+1

У нас проект более 50 человек, функциональный объем большой, поэтому управление многоуровневое и в некотором смысле - распределенное.

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

Все правильно Татьяна пишет
- не может менеджер в сапе работать если нет бэкграунда консультанта - если вы менеджер то вам конечно нормально . Но как вы можете принимать стратегические решения если вас могут делать дурачком консультанты среднего уровня - я с такими сталкивался менеджерами - они сначала прозевают как клиент завел пользователей с точками в имени пользователя, тогда конструкция break username - не работает - то пугаются дампов в продуктиве - и прибегают вместе с менеджером от клиента с полными штанами - потому что никогда такого не видели - а потом у клиента складывается впечатление как о студенческой команде. По поводу 1000-3000 задач - они не все критичные - критичные и существенно влияющие на затраты проекта на пальцах одной руки можно пересчитать. их можно переложить на руководителей направлений, если они есть тогда зачем такой менеджер - ( попка - секретарь ) - если можно сделать менеджером одного из руководителей направления а для механической работы есть секретари

Консультантов, которые могут выставить перед клиентом своего ПМ'а дурачком, надо гнать из консалтинга поганой метлой.
И бэкграунд работы в качестве функционального консультанта очень мало поможет при переходе на работу в качестве ПМ.
Когда, еще во времена развитого социализма, я работал на большом предприятии. Так вот во всех отделах бал начальник отдела, и был заместитель начальника. Жизнеспособными были только те отделы, в которых один из этих людей был технарем, а другой администратором. И без разницы кто кем. Редко встречаются технари, которые могут тянуть административную работу.

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

Ужос... А разработчик этого тоже не заметил и никому не сообщил? Или заметил, забил, а потом огорчился, что у него бряки не ставятся где угодно...

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

Loyso, даже на эмблеме форума написано что он для консультантов и пользователей. Так что легкая ироничная градация: если с мнением разработчика считаются, то он консультант по разработке, а если абаперу принять к исполнению, то ...

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

Имел реальный опыт на среднем проекте ( 15 тех консультантов + 10 методологов). PM ни в одном глазу по сапу... в результате полный крах и хаос... в итоге, пм сменился под конец проекта.