Создание нового структурного подразделения

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

Ну дык, как говорят друзья китайцы, правильно поставленный вопрос уже содержит в себе ответ: "Спланировать и описать бизнесс-процессы новые?"

_________________
С уважением,
Александр Горшунов

Отлично.
А друзья-китайцы советуют какую-нибудь серьезную литературу по планированию бизнесс-процессов?=)
Хотелось бы подойти к вопросу на каком-то осмысленном уровне.
спасибо.

Так литературы на эту тему в сети немеряно. Правда, выделить из массы серьезные и несерьезные весьма проблематично.

_________________
С уважением,
Александр Горшунов

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

посоветуете что-нибудь?

Не, не посоветую. Я в таких случаях пользуюсь обычной логикой.

_________________
С уважением,
Александр Горшунов

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

2. Матричная структура - это двоевластие, когда управляют проектами/процессами и одновременно пересекающиеся функциональные подразделениям. Главная проблема матричной структуры - в разделении функций властей. Чтобы ее решить, нужно принять принципиальное решение, кому мы отдаем приоритет: функциональному или проектному управлению? Рекомендую функциональный приоритет, т.к. проектный гораздо сложнее в реализации.

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

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

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

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

Я в принципе за гибкость, но с вышеприведенным предложением в основном не согласен, потому что это гибкость мнимая. Она возможно в малых организациях, размером до 50-100 чел, но если число сотрудников больше, должны быть определены ключевые приоритеты - либо 1) мы занимаемся проектами, разрешая противоречия между функциональными областями (цель - результат для клиента), либо 2) мы совершенствуемся в функциональных областях, разрешая противоречия между проектными работами (цель - снижение рисков организации, устойчивый поток доходов, и т.п.) .

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

У нас приоритет по умолчанию отдали проектным менеджерам. Предприятие >20000 чел. Проектов немного: пару-тройку десятков штук.


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

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

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