Организационные структуры и команда проекта внедрения ERP-системы

[mazzy]

Статья Сергея Котова содержит информацию для руководителей проекта внедрения.

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

Подробнее...
http://axapta.mazzy.ru/lib/org_prog_team/

[alester_imported]

"Важность создания отдельной организационной структуры проекта подробнее обсуждается в главе 1.4.2."
ЭТО ГДЕ, ПРОСТИТЕ?

[Sergik]

alester - cпасибо, что обнаружили.

Данная статья входила в проект, который мы пока отложили до выхода новых версий Dynamics. Это ссылка на другой раздел, который был посвящен теме организационных структур. Я убрал лишние ссылки, но, похоже, эта осталась...

mazzy - если не трудно - удали пожалуйста эту фразу.

[alester_imported]

Дык вопрос-то интересный. Если раздел существует - в студию.

[mazzy]

Цитата:

Сообщение от serge kotov

mazzy - если не трудно - удали пожалуйста эту фразу.

Сделал.

[Sergik]

to mazzy - спасибо Сергей

to alester - пока еще не завершено

[bobkov_imported]

Добрый день, Сергей,

Позволю себе сделать одно замечание к вашей статье, надеюсь, небесполезное :-).

Вы рассматриваете функции "основных игроков" и "специалистов команды внедрения", но далеко не везде рассматриваете область ответственности каждого из них. Я думаю, статья стала бы значительно полезнее, если в ней четко описать, за решение каких конкретно видов вопросов в рамках проекта должен нести отвественность каждый участник. Причем, за решение каждого вида вопросов должен быть единственный ответственный, не так ли? :-). Было бы очень удобно для анализа, если бы эта информация о разделении ответственности была собрана в табличку, а не размазана по всей статье :-)

С уважением,
Андрей Бобков

[Sergik]

Спасибо Андрей за ценное замечание

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

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

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

[Галина]

Цитата:

Сообщение от serge kotov

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

Не соглашусь-совсем не очевидна ответственность каждого участника. Особенно когда только начинаешь разбираться с ведением проектов.

[Sergik]

Галина, неужели на практике вы формально расписываете вопросы ответственности для программистов и консультантов?

[bobkov_imported]

Цитата:

Сообщение от serge kotov

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

Как говорил мой университетский преподаватель функционального анализа,
когда нам лень доказывать какое-то утверждение, мы говорим, что оно очевидно.
Ничего личного! :-)
Пытаясь расписать "очевидные" вещи, лично я часто наталкивался на различные нюансы, которые подчас значительно меняли картину, которая мне казалась очевидной...

Цитата:

Сообщение от serge kotov

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

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

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

[Галина]

Цитата:

Сообщение от serge kotov

Галина, неужели на практике вы формально расписываете вопросы ответственности для программистов и консультантов?

У меня не такая большая практика, чтобы ответить на этот вопрос. Тем более я и написала, что когда только начинаешь разбираться с ведением проектов.
Хотя я и раньше на axforum задавала вопрос-в чем же разница в работе между консультантом и программистом. Если не нужно расписывать ответственность ( и обязанности), то тогда зачем это разделение на консультантов и программистов?
Возможно и не стоит расписывать ответственность на конкретном проекте, если каждый участник четко понимает свои обязанности, начиная от директора проекта.
Но вы то писали статью и там не мешало бы написать обязанности и ответственность каждого участника.
Хотя бы для того, чтобы объяснить участникам проекта, в чем их обязанности и ответственность, особенно если участники проекта до этого вместе не работали, или работали на других предприятиях и т.д и т.п.
Чтобы не было ситуации, когда каждый рассматривает обязанности и зону ответственности со своей колокольни. Кстати из опыта очень грустная ситуация

[Sergik]

Цитата:

Сообщение от bobkov

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

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

Цитата:

Сообщение от bobkov

... Пытаясь расписать "очевидные" вещи, лично я часто наталкивался на различные нюансы, которые подчас значительно меняли картину, которая мне казалась очевидной...

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

ИМХО Руководителю проекта стоит очень осторожно относится к саморефлексии, "глубокому анализу", особенно при людях. Окружающие могут не понять. Мир и ситуация вокруг меняется гораздо быстрее, чем мы успеваем докопаться до сути простых вопросов. Для РП очень важно качество схватывать всё на лету, быстро проводить оценку ситуации (как говорят "проинтуичить"), принимать верные решения. Хороший руководитель стоит как бы над ситуацией и управляет ей.

Цитата:

Сообщение от bobkov

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

ОК Андрей. Приведи пожалуйста для примера пример функций и ответственности для функциональной роли программиста. Я думаю Вам это будет несложно, раз Вы это делаете. А мы обсудим

[Sergik]

Цитата:

Сообщение от Галина

...Чтобы не было ситуации, когда каждый рассматривает обязанности и зону ответственности со своей колокольни. Кстати из опыта очень грустная ситуация

Галина, кстати не поделитесь опытом c грустной ситуацией? Разумеется без конкретных имен и компаний. Если не трудно конечно.

[Галина]

Сергей а ваш предпоследний пост к чему? Совершенно общие слова.
Увы, но на форуме пока не готова поделиться ситуацией. Слишком все высчитываемо.

[Sergik]

Цитата:

Сообщение от Галина

Сергей а ваш предпоследний пост к чему? ...

Беседа с Андреем на философские темы

[Галина]

Цитата:

Сообщение от serge kotov

Беседа с Андреем на философские темы

Ага вы на философские темы, а не которые путаются (типа меня)

[bobkov_imported]

Ну хорошо, если ты хочешь, давай и философские темы затронем... :-)

Цитата:

Сообщение от serge kotov

ИМХО Руководителю проекта стоит очень осторожно относится к саморефлексии, "глубокому анализу", особенно при людях. Окружающие могут не понять. Мир и ситуация вокруг меняется гораздо быстрее, чем мы успеваем докопаться до сути простых вопросов. Для РП очень важно качество схватывать всё на лету, быстро проводить оценку ситуации (как говорят "проинтуичить"), принимать верные решения. Хороший руководитель стоит как бы над ситуацией и управляет ей.

Сергей, ты тем самым предлагаешь отнести управление проектом к искусству, которое в формализации не нуждается? Интересно твое мнение, что конкретно качественно изменилось в нашем бизнесе (создание и ввод в действие автоматизированных систем), скажем, за последние 5 лет?

Цитата:

Сообщение от serge kotov

ОК Андрей. Приведи пожалуйста для примера пример функций и ответственности для функциональной роли программиста. Я думаю Вам это будет несложно, раз Вы это делаете. А мы обсудим

Сергей, расписывать отдельно взятую роль я смысла никакого не вижу, так как роли на проекте тесно взаимосвязаны. Расписывать надо все роли вместе, а это большая работа.
Кроме того, я могу расписать функции и ответственность только по тем ролям, которыми я оперировал на своих проектах. А по тем ролям, которые ты выделил в своей статье, я расписать не могу по той причине, что я их четко не понимаю. Я не понимаю, например, зачем ты выделил роли тестировщика, технического писателя, эксперта, аудитора? Я же не могу к тебе в голову залезть, чтобы понять, что ты имел в виду! :-)

[Sergik]

Цитата:

Сообщение от bobkov

Сергей, ты тем самым предлагаешь отнести управление проектом к искусству, которое в формализации не нуждается? ...

Если говорить именно об управлении проектом, то мне нравится сравнение с искусством. Но пока я не готов обсуждать эту тему. Формализации хорошо поддаются стабильные процессы, а управление (и именно управление) проектом внедрения ERP-системы к таковым пока сложно отнести.

Цитата:

Сообщение от bobkov

Сергей, расписывать отдельно взятую роль я смысла никакого не вижу, так как роли на проекте тесно взаимосвязаны. Расписывать надо все роли вместе, а это большая работа.
Кроме того, я могу расписать функции и ответственность только по тем ролям, которыми я оперировал на своих проектах. А по тем ролям, которые ты выделил в своей статье, я расписать не могу по той причине, что я их четко не понимаю. Я не понимаю, например, зачем ты выделил роли тестировщика, технического писателя, эксперта, аудитора? Я же не могу к тебе в голову залезть, чтобы понять, что ты имел в виду! :-)

Вот вот, именно, легко рассуждать об этом :P , а сделать даже простой пример трудно. Ответственность более относится к конкретным людям, а функциональная роль может исполняться одним человеком или несколькими, и один человек может исполнять несколько ролей. И всё это приложимо именно для конкретного проекта, а не для проектов в целом.

[bobkov_imported]

Цитата:

Сообщение от bobkov

Сергей, ты тем самым предлагаешь отнести управление проектом к искусству, которое в формализации не нуждается? ...

Цитата:

Сообщение от serge kotov

Если говорить именно об управлении проектом, то мне нравится сравнение с искусством. Но пока я не готов обсуждать эту тему. Формализации хорошо поддаются стабильные процессы, а управление (и именно управление) проектом внедрения ERP-системы к таковым пока сложно отнести.

Хорошо, обсуждать не будем. Отмечу только, что процесс управления проектом внедрения формализован, например, в Oracle AIM 3.0.

Цитата:

Сообщение от bobkov

Сергей, расписывать отдельно взятую роль я смысла никакого не вижу, так как роли на проекте тесно взаимосвязаны. Расписывать надо все роли вместе, а это большая работа.
Кроме того, я могу расписать функции и ответственность только по тем ролям, которыми я оперировал на своих проектах. А по тем ролям, которые ты выделил в своей статье, я расписать не могу по той причине, что я их четко не понимаю. Я не понимаю, например, зачем ты выделил роли тестировщика, технического писателя, эксперта, аудитора? Я же не могу к тебе в голову залезть, чтобы понять, что ты имел в виду! :-)

Цитата:

Сообщение от serge kotov

Вот вот, именно, легко рассуждать об этом :P , а сделать даже простой пример трудно. Ответственность более относится к конкретным людям, а функциональная роль может исполняться одним человеком или несколькими, и один человек может исполнять несколько ролей. И всё это приложимо именно для конкретного проекта, а не для проектов в целом.

Я и не говорил нигде, что это сделать легко :-) Напротив, я из опыта знаю, что это сложная, трудная, долгая работа. Вместе с функциями и ответственностью по ролям надо будет расписать "типовой" план проекта, "типовые" проектные документы, классификатор автоматизируемых бизнес-процессов... Я потому сам и не берусь, что не вижу платежеспособного спроса на эту большую работу! А тут твоя статья подвернулась... :-)
Тем не менее, я убежден, что:
1. Можно сделать такое обобщение, и оно будет очень полезно на практике.
2. Если такое обобщение не сделать, то реализация проектов внедрения Axapta и Navision так и останется искусством, посильным только опытным руководителям проектов.
Но вот только кто эту работу оплатит? :-)