СМК vs Управление проектами (или не vs?)

[Фефелов Андрей А.]

Андрей, а можно узнать, как у вас распределяется ответственность на практике?
Я имею в виду ответственность за выделенные процессы (владельцев процессов) и ответственность за проект (руководителей проектов). В теории вроде понятно, но на практике все пытаются перекинуть ответственность друг на друга: владельцы процессов на руководителя проекта и наоборот.

Елена уточните пожалуйста о чем конкретно мы говорим, а то могу сказать совсем не то.

[Елена Рыжова]

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

[Роман Озеранский]

Елена, а каковы зоны ответственности того и другого?

[Фефелов Андрей А.]

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

У нас Елена такой путаницы не так много, в связи с тем, что организационная структура эволюционно перешла в проектную. Сейчас в течении 3 лет ее надо обратно завернуть на матричную. Вот тогда вопрос встанет крайне остро. Плюс к этому у нас руководители проектов - замы генерального, что есть категорически неправильно.
Зато многие вопросы решаются быстро из-за административного ресурса.

В вообще такая проблема есть, но выражается чуть по другому.
Проектное управление (и наверно процессное) подразумевает, что Руководитель проекта нанимает те или иные подразделения, которые обслуживают его проект. Вот понимание "ПОТРЕБИТЕЛЬ - ПОСТАВЩИК УСЛУГИ" категорически сложно донести.
Что не надо делать как привыкли, а надо делать так, как надо Руководителю проекта. Со старой философией сейчас боремся, в том числе через премиальную систему.

Конкретно по вашему вопросу - нужно прописывать в матрице ответственности, но это не панацея.
Дополнительно нужно учиться работать в гибкой системе - Руководитель проекта определяет ЧТО ДЕЛАТЬ, а функциональный руководитель - КАК ДЕЛАТЬ.
То есть Руководитель проекта выдает ТЗ на работу, грубо говоря.

Приведите пример Вашей конкретной проблемы. Интересную тему Вы подняли

[Роман Озеранский]

Проектное управление (и наверно процессное) подразумевает, что Руководитель проекта нанимает те или иные подразделения, которые обслуживают его проект.
...Дополнительно нужно учиться работать в гибкой системе - Руководитель проекта определяет ЧТО ДЕЛАТЬ, а функциональный руководитель - КАК ДЕЛАТЬ.

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

[Фефелов Андрей А.]

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

Роман, я сколько уже про явные АНАЛОГИИ говорю, между проектным управлением, которым я сейчас занимаюсь, и ПРОЦЕССНЫМ управлением, про которое поднимаются темы.
Насколько эти аналогии прямые - я не знаю, да мне даже и не особо интересно.
У нас межфункциональная команда - это команда проекта. Но она временная.
В процессе ИМХО она тоже временная - на время жизни продукта/услуги.
Вывести продукт с рынка вовремя - тоже искусство

[Роман Озеранский]

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

[Фефелов Андрей А.]

Роман у нас нету межфункционального процесса.
У нас есть проект и есть команда проекта.
Оргструктура на сегодня не соответствует тому, что требуется проектному управлению.
Но этот вопросы сейчас решаются, а конкретно - мотивация в привязке к проекту и внутренним потребителям (тяжело), оптимизация организационной структуры в связи с переходом на проектную деятельность и выделением производственных структур в отдельные юрлица (крайне тяжело) и изменение философии мышления с упором на умение "договариваться" (ОЧЕНЬ И ОЧЕНЬ ТЯЖЕЛО).

[Роман Озеранский]

Роман у нас нету межфункционального процесса.
У нас есть проект и есть команда проекта.

А Вы видите смысл для своей организации разделять эти понятия?

[Фефелов Андрей А.]

Конечно.
Наш объект управления - строительный проект

[Роман Озеранский]

Конечно. Наш объект управления - строительный проект

А что тогда для вашей организации - процесс?

[Фефелов Андрей А.]

Конечно. Наш объект управления - строительный проект

А что тогда для вашей организации - процесс?

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

Я просто не совсем понимаю, какой подвох в Вашем вопросе?

[Роман Озеранский]

Я просто не совсем понимаю, какой подвох в Вашем вопросе?

Андрей, никакого подвоха. Я просто не вижу разницы у Вас между проектом и процессом, поэтому и уточнил.

[Андрей Волков]

Я просто не совсем понимаю, какой подвох в Вашем вопросе?

Андрей, никакого подвоха. Я просто не вижу разницы у Вас между проектом и процессом, поэтому и уточнил.

а она разве у кого-то есть? так никто и не доказал разницу, за исключением явной временности проектов и относительной постоянности процессов.

[Роман Озеранский]

Я просто не совсем понимаю, какой подвох в Вашем вопросе?

Андрей, никакого подвоха. Я просто не вижу разницы у Вас между проектом и процессом, поэтому и уточнил.

а она разве у кого-то есть? так никто и не доказал разницу, за исключением явной временности проектов и относительной постоянности процессов.

Андрей сказал что есть, вот его ответ

Конечно.
Наш объект управления - строительный проект

[Андрей Волков]

Андрей сказал что есть, вот его ответ

Конечно.
Наш объект управления - строительный проект

он противопоставил это межфункциональному процессу, насколько я понял. Причем противопоставил термины, а не суть

[Роман Озеранский]

он противопоставил это межфункциональному процессу, насколько я понял. Причем противопоставил термины, а не суть

Не знаю, Андрей сам скажет что он имел в виду. Для меня более важно что он озвучил два фактора, характеризующие сквозной процесс:
1. Проектное управление (и наверно процессное) подразумевает, что Руководитель проекта нанимает те или иные подразделения, которые обслуживают его проект.
2. Руководитель проекта определяет ЧТО ДЕЛАТЬ, а функциональный руководитель - КАК ДЕЛАТЬ.
Оба пункта совершенно не характерны как для "традиционных" систем управления, так и для процессов по нишам.
Первый регламентирует, что в команду входит далеко не вся организация, в дальнейшем пункт приведет к изменению принципов оплаты труда в межфункциональных командах и вне их, а также к изменению взаимоотношений внутри команды.
Второй фактически меняет принципы целеполагания и меняет функционал линейных начальников, убирая из под их подчинения персонал находящийся в межфункциональных командах. В дальнейшем это приведет к изменению оргструктуры, с большой долей вероятности на матричную.

[Фефелов Андрей А.]

он противопоставил это межфункциональному процессу, насколько я понял. Причем противопоставил термины, а не суть

Не знаю, Андрей сам скажет что он имел в виду. Для меня более важно что он озвучил два фактора, характеризующие сквозной процесс:
1. Проектное управление (и наверно процессное) подразумевает, что Руководитель проекта нанимает те или иные подразделения, которые обслуживают его проект.
2. Руководитель проекта определяет ЧТО ДЕЛАТЬ, а функциональный руководитель - КАК ДЕЛАТЬ.
Оба пункта совершенно не характерны как для "традиционных" систем управления, так и для процессов по нишам.
Первый регламентирует, что в команду входит далеко не вся организация, в дальнейшем пункт приведет к изменению принципов оплаты труда в межфункциональных командах и вне их, а также к изменению взаимоотношений внутри команды.
Второй фактически меняет принципы целеполагания и меняет функционал линейных начальников, убирая из под их подчинения персонал находящийся в межфункциональных командах. В дальнейшем это приведет к изменению оргструктуры, с большой долей вероятности на матричную.

Так и есть - с этим сейчас и сталкиваемся.
Я сознательно не употребляю термин "ПРОЦЕСС". У нас "ПРОЕКТ", у нас руководитель ПРОЕКТА, менеджер ПРОЕКТА.
Никакого противопоставления я не делал. Если форумчане считают, что есть аналогия с процессным управлением - так этому и быть.
Я это не утверждаю, не специалист в процессном управлении.

[Андрей Волков]

1. Проектное управление (и наверно процессное) подразумевает, что Руководитель проекта нанимает те или иные подразделения, которые обслуживают его проект.
2. Руководитель проекта определяет ЧТО ДЕЛАТЬ, а функциональный руководитель - КАК ДЕЛАТЬ.
Оба пункта совершенно не характерны как для "традиционных" систем управления, так и для процессов по нишам.

"по нишам" я бы тоже в кавычки поставил. Ибо нет ни термина "традиционные", ни "по нишам". Каждый волен понимать так, как понимается.

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

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

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

не убирает.

[Роман Озеранский]

"по нишам" я бы тоже в кавычки поставил. Ибо нет ни термина "традиционные", ни "по нишам". Каждый волен понимать так, как понимается.

Не возражаю.

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

Тут сразу несколько вопросов. Многие на форуме вообще не признают команд, более того не понимают как они работают. Да и вопрос, сколько должно быть команд если сквозных процессов два. Ответы в диапазоне – ни одной/одна/две.

не убирает.

Когда человек не в команде, не убирает. Его начальник это его начальник. А когда он в команде, его начальник не имеет права давать ему указания административного характера. Как правильно сказал Андрей – говорит "как надо делать", а не "что надо делать".