вторник, 27 февраля 2018 г.

Когда командами нельзя командовать


Гипотетический случай №1.
Есть команда консультантов по какому-то ИТ-решению. Они прекрасно сработались, они досконально знают ИТ-решение, у них есть зрелый метод, по которому они это решение продают и запускают у клиентов. Но трансформация процессов клиента после установки решения происходит только в половине случаев, а иногда клиенты и вовсе разочаровываются в предлагаемом решении и разрывают контракт с консультантами. Рынок жесткий, и репутация на нем значит много.
Гипотетический случай №2.
Руководитель внутреннего проекта развития. Хорошо знает методы проектного управления, владеет основными инструментами (ИСР, календарный сетевой график, реестр рисков, списки задач) и регулярно применяет их на практике. Но ему не удается построить взаимодействие с функциональными подразделениями и командой внутреннего заказчика. На взгляд руководителя проекта они слишком заняты своей функциональной работой, и обещанного выделения на 20% или 40% не происходит. Проект явно срывает сроки, у него есть серьезные проблемы с качеством.

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


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

Ближайший тренинг см. расписание.

понедельник, 26 февраля 2018 г.

Стратегирование с помощью Wardley maps и архитектура оргвозможностей

Системный подход применительно к предприятиям имеет особенности. Архитектурные требования к предприятиям - это стратегия, а архитектура состоит из оргвозможностей.
Т.к. предприятие - это система систем и вид жизненного цикла у нее эволюционный, то архитектурные требования к предприятию (стратегия) все время меняется, таким образом следует говорить не о стратегическом планировании, а о циклах стратегирования и ключевая характеристика этих циклов - это скорость стратегирования, адаптации к изменяющемуся окружению предприятия.
Как обеспечить высокую скорость стратегирования? Как вовлечь в стратегирование команду? Как обеспечить качество стратегии (архитектурных требований к предприятию)? Практика анализа и синтеза цепочек производственной кооперации с помощью техники Wardley mapping - одна из перспективных замен устаревшему методу событийного штурма (event storming).




Но у практики Wardley mapping есть серьезные недостатки, а среда моделирования не самая удобная, поэтому я доработал нотацию и адаптировал технику под свободный редактор Archi.



вторник, 20 февраля 2018 г.

Архитектура цепочек производственной кооперации

Обзор моего текущего представления об управлении программами проектов.

Основано на дисциплине системного мышления, см. Coursera.
Для понимания системного мышления студентам зачастую необходим курс онтологического фитнеса.

Терминология и проблематика:

Архитектура цепочек производственной кооперации (оргвозможностей, модулей обеспечивающей системы):

Обсуждение на семинаре в Школе системного менеджмента:

Современные представления об архитектуре предприятия являются основой для моего тренинга по системному лидерству.