Многоуровневая стратегия развития моего подразделения. #СМС23

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

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

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

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

После прочтения стратегий Nvidia и Volkswagen я понял, что самый верхний уровень возможно не ограничивается уровнем компании, но нужно выходить на уровень extended enterprise и потом на уровень ecosystem, и попытаться понять, какие же изменения должны произойти там. Кроме этого, стало понятно, что нужно каким то образом трассировать изменения с нижних системных уровней на более верхние системные уровни, для того, чтобы показать влияние изменений bottom up и также показать последовательность изменений между уровнями, так как некоторые изменения на высших уровнях не будут иметь смысла, пока изменения на низших уровнях не произойдут, или окажут негативный эффект.

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

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