суббота, 19 августа 2017 г.

Модели стейкхолдеров


Полная модель в PDF.

Менеджеры, использующие системный подход, всегда рассматривают минимум 5 систем - использующую (1), целевую (2), в операционном окружении (3), обеспечивающую (5) и использующую обеспечивающей (не показана на рисунке) (предприятие, осуществляющее проект).
holon.png

простой холон.jpg
В нотации АрхиЭссенс выглядит так. Система отмоделирована как идеальный оргсервис-продукт (идеальная система это та, которая не имеет воплощения, наиболее близкий пример - облачные сервисы) и как 4Д-экстент Node. Идеальный оргсервис-продукт реализует “железку”, которую можно пнуть или погрузить в тачку. Отношение странное, т.к. отношение реализации направлено от более конкретных сущностей к менее конкретным (например, Программа реализует Бизнес-сервис).


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

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

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

Раскрываем обеспечивающую систему
поставляющая сторона.jpg


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

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

Организационные интерфейсы и интероперабельность
интероперабельность, дать ссылку на ГОСТ.png
Приобретающая и поставляющая сторона взаимодействуют через организационные принципы, в идеале построенные по принципам открытых систем (интероперабельность, business processes interoperability).
Это третье поколение “матричных организаций”, окончательное разрушение information silos.

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

Привязанность стейкхолдеров к практикам на примере конкретной системы
стейкхолдеры и практики.jpg
Целевая система в стадии использования становится подальфой “Технологии” системной холархии использующей системы. При этом для реализации бизнес-кейса может быть необходима смена Дисциплины практики, см. также полную диаграмму поставляющей и приобретающей стороны, курс действий “План использования модифицированной функциональной возможности для достижения целей”.
109304_original.png
Другими словами, стейкхолдер “Пользователь” нанимает целевую систему выполнять какую-то работу в жизненном цикле использующей системы, см.
Jobs To be Done by Intercom ePub mobi PDF

Подальфы Эссенс для проекта магазина
Другие подальфы для проекта поставки магазина:
Стейкхолдеры - Оператор магазина, Клиент магазина, Операционный менеджмент, Инвестор, Владелец помещения, Надзорный орган, Работник магазина.
Возможности - Конкурентное окружение, Трафик, Сегменты потребителей, Развитие территории
Определение системы - Локация, Концепт, Ассортиментная матрица, Планировка магазина, Клиентская петля, Бизнес-кейс
Система - Ассортимент, Торговый зал, Клиентские сервисы, Промо-предложения
Команда - Проектировщик, Строитель, Категорийный менеджер, Логист, Работник магазина, Талант
Технологии - Управление цепями поставок, Мерчендайзинг, Операции торгового зала и обслуживание клиентов, Собственное производство и ХАССП, Ценовое восприятие, Безопасность и потери.

Архитектурное описание квалифицированного стейкхолдера и режимов функционирования 1, 2 и 3
Подробно написано здесь*. Общая идея в том, что мышление квалифицированного стейкхолдера отвечает архитектурным требованиям к мышлению при уверенном владении предметным мышлением (освоение дисциплины на уровне базальных ядер, т.н. “Неосознанная компетентность”). Управление жизненным циклом команды направлено на вывод членов команды в стадию Использования, т.е., эффективное получение компетентных стейкхолдеров с высокой situation awareness, способностью планировать развитие ситуации, используя предметный фреймворк.

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

*Возможно, вместо бихевиоризма EAST, должна быть дисциплина Perceptual Control Theory (PCT).

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

Не описанные, но связанные темы:
Модель коммуникаций при корректировке поведения в ответ на отклик

Холархия команд и жизненный цикл команд, цели применения практик жизненного цикла команд
Талант-Команда практики ("Шина" или "Спагетти")-Облачное сообщество-Социальная сеть.
Трассировка сущностей модели системного менеджмента к модели PRINCE2

воскресенье, 13 августа 2017 г.

SMART - дело не в везении

  1. (Не)серьезный разговор об альфе “Возможности”
“— Формула выглядит следующим образом: начинаем с гудвила, после того как отработает гудвил, переходим на мультипликатор, с мультипликатора переходим на мультиплицирование, с мультиплицирования переходим в EBITDA, с EBITDA переходим опять в гудвил. И делаем следующий виток спирали.”
Сергей Матвиенко
   
    Проекты начинаются очень похоже. Появляется какая-то идея, ее прорабатывают, если она кажется адекватной, пробуют сделать прототип или хотя бы презентацию, ищут под все это ключевую команду, готовят sales pitch, находят людей с деньгами (своими или чужими), рассказывают им про проект, они дают какие-то деньги на старт, набирается основная команда, она договаривается о каких-то методах работы, развертывает под них технологии, планирует и делает работу по описанию продукта, который затем отдается в производство и поставляется заказчику или клиенту, тот платит, команда либо выплачивает дивиденды прямому инвестору, либо тот продает свою долю в компании другому инвестору.
109304_original.png
Логическая последовательность проработки системных альф проекта

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

В этом тексте я буду разбирать только интерес капиталиста, владельца бизнеса.

Капиталист владеет предприятием, менеджмент управляет. Это различие в правах владения активами и контроля над активами. Для того, чтобы менеджмент делал поменьше лишнего, существует система governance, подотчетности, ее еще называют корпоративным управлением, даже если она применяется не в корпорации. Подотчетность - это правила, соблюдая которые менеджмент может контролировать активы. Можно провести аналогию с арендой квартиры, положения контракта являются правилами подотчетности для арендаторов, а квартирой распоряжаются они. С человеческим капиталом все гораздо сложнее, напрямую им владеть получается не всегда и поэтому приходится идти на множество ухищрений. Каких, я рассказываю на своем тренинге по системному лидерству.

Подотчетность состоит из двух частей:
  • Достижение целевых показателей финансовой эффективности (прибыль, денежные потоки, капитализация компании) (1)
  • Правила, которые надо соблюдать менеджменту, чтобы собственник не отнял у них право контроля над активами (2)
Со стороны менеджмента этому отвечают две вещи:
  • Ответственность за результат, accountability, и
  • Комплаенс, compliance. Комплаенс бывает различный, я сейчас говорю только про корпоративный, соответствие требованиям акционеров и владельцев, представляемых, допустим, советом директоров.

Менеджмент дает указания (directions) команде предприятия, те производят результат, за который несут ответственность за исполнение (responsibility).

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


Как ведет себя программа, которой поставили цель по СМАРТ. Ничего не напоминает?

  1. СМАРТ бывает разный, проблемы каскадирования целей
“Согласно последнему исследованию Росстата у среднего россиянина одна грудь и одно яичко.”
Оценочное мнение

После 11 лет в управлении проектами я выделяю для себя три основные проблемы со СМАРТ целями, которые не решены и в новомодном OKR-целеполагании:
  • Проблема измеримости. Измерениями занимается метрология и там есть понятия точности, воспроизводимости, повторяемости измерений, для каждого измеряемого параметра пишется статистически обоснованная методика измерений, а артефакты измерений корректно обрабатываются.
    В бизнесе, особенно российском, над методикой мало кто задумывается и уж совсем мало кто привлекает к ее разработке статистиков и специалистов по обработке данных. И если, допустим, в ходе проекта меняются ИТ-системы, формулы расчета, данные, оргструктуры, то концов не найти. Цель-то будет конкретной и “измеримой”, вопрос в том, как и чем мерить и каким измерениям доверять. Анекдот про главного бухгалтера “Дважды два сколько будет? - А сколько надо?” - это не анекдот, а правда жизни.
    Теперь вопрос на засыпку - если вы не можете однозначно и бесспорно измерить цель, является ли она конкретной?
  • Проблема достижимости. Часто цели ставятся на уровне “Повысить EBITDA на 1,3 п.п.” или “Обеспечить готовность города к проведению соревнований”. Нет ничего невозможного, мы на Марс летаем и меняем климат на планете. Вопрос ограничений - какие они? Без указания ограничений цель не может быть смартирована.
  • Проблема релевантности, адекватности. А нужно ли это владельцам и клиенту? Деньги в компанию приносят два человека - владелец и клиент. Владелец в любом случае будет приносить только под какое-то свое понимание пользы предприятия для общества. Он имеет какое-то представление, как будет возвращать вложенные деньги, как он будет зарабатывать или получать пользу от этого предприятия. У него есть модель ценности.

Для владельца все всегда упирается в ценность.
модель ценности предприятия.png
Модель ценности, основанная на функциональных возможностях (capabilities) предприятия

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

Примеры. Есть бизнесы, вся ценность которых заключается в том, что папа дает господряды. Это единственный актив предприятия. Другой пример - завод по производству процессоров Intel D1X. Ценность он имеет ровно до тех пор, пока стоит в Хиллсборо, штат Орегон, если перенести его под Самару, то его ценность будет примерно по цене металлолома оборудования и дисконтированные денежные потоки от сдачи коробки под склады.

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

Оценка стоимости актива зависит от многих факторов

целеполагание в отношении активов.png
Модель ценности предприятия и мета-стратегии работы с ценностью

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

Резюме.
Целеполагание по СМАРТ работает ровно в одной букве - там есть ограничение по времени. Все остальное очень сомнительно.

  1. 4 группы стейкхолдеров, подотчетность и комплаенс
Сержант: “Рядовой, почему сапоги не чищены?” - “Да вас не волнует”. - “Что ты сказал?” - “Ваксы на складе нет, сапоги почистить нельзя!” - “А меня не волнует!” - “Я так сразу и сказал”.
Основной принцип постановки целей в некоторых компаниях

По идее, модель оценки ценности должна связывать стратегии предприятия с потребностями рынка, а поднадзорность и комплаенс обеспечивать реализацию тех стратегий, которые эту ценность повышают. Все это очень похоже на V-модель, где СМАРТ - это архитектурный дизайн предприятия, а поднадзорность - верификация воплощения предприятия против архитектурного описания. В этом месте БАБОКовцы радостно кричат “Ура! Мы так всегда делали!”, но подождите, не все так просто.
актив до и после.png
Ключевая вещь, которую бизнес-аналитики не объясняют руководителям проектов. Активы предприятия и есть их продукты проектов.
Это сказывается отсутствие мультидисциплинарности и множества viewpoints в BABOK и PMBOK, один из пунктов, за который я всегда их ругаю.

В реальности при организации работ надо смотреть на проект минимум с трех viewpoints:
три вьюпойнта.png
  • Viewpoint капиталиста. Основан на моделях активов и оценки их ценности.
  • Viewpoint системного инженера. Каждый актив - это система. Каждый проект по преобразованию актива - тоже система. И у тех и у других есть жизненные циклы.
  • Viewpoint менеджера (проектного, процессного, кейсового). Каждый актив должен исПОЛЬЗОваться, приносить ПОЛЬЗУ. И чем больше, тем лучше, поэтому активы надо улучшать. Активы можно улучшать только организованной деятельностью. Деятельность организуется тремя способами - процессами (PDCA цикл улучшения использования актива на фиксированных оргместах/оргпозициях), проектами (серия PDCA циклов улучшения использования актива на изменяемых оргместах/оргпозициях) и кейсами (OODA циклы поиска путей и способов улучшения использования актива).

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

  1. Модели измерения ценности/пользы и ее связь с моделью жизненного цикла
— Пожалуйста, вышлите нам инвойс! — Не слышу! — Вышлите инвойс! — Что выслать? — Инвойс, б%#ть, говорю по буквам: — Инна! Наталия! Валерий! Ольга! Иван краткий! Сергей! — Кто эти люди?
9.jpg
В PDF.

Несколько пояснений.
Как каскадировать цели?
  • Мета-стратегии владельцев преобразуются в курсы действий. Курс действий может измеряться какими-то достижениями. Эти достижения можно описать по модели СМАРТ. Это первый уровень каскадирования целей, цели ставятся в терминах общего менеджмента.
  • Достижения курса действий верхнего уровня реализуются практиками жизненного цикла предприятия. Цели достигаются изменением практик. Практики меняются двумя способами - в циклах развития и циклах совершенствования. Это два типа стратегий предприятия - в случае совершенствования улучшается технологиях, при этом принципиальных изменений не происходит и команда предприятия остается стабильной, а в случае реализации шагов развития технология меняется в корне и приходится либо значительно переучивать существующую команду либо набирать новых.
    Это второй уровень каскадирования целей - цели по стратегиям развития и совершенствования практик жизненного цикла. Цели ставятся в объектах этих практик.
  • Стратегии реализуются PDCA циклами совершенствования либо OODA циклами развития. Планирование происходит либо с помощью процессного менеджмента, либо с помощью проектного менеджмента либо становящееся планирование в кейс-менеджменте. Планирование на этом уровне дает каскад целей третьего уровня. Цели ставятся в объектах практик и отслеживаются в рамках performance/OKR goals management.

Почему нужно столько практик жизненного цикла? Зачем нужен маркетинг/системная инженерия/функционально-стоимостной анализ?
Однажды мне задали вопрос: “А зачем нужна системная инженерия”? Месяц думал над ответом и вот он: “Любая практика, освоенная предприятием, расширяет поле стратегического выбора. Неважно, системная это инженерия, лидерство, маркетинг или ФСА - без всего, кроме производства и сбыта можно прожить какое-то время. Больше практик - устойчивее предприятие, больше вариантов реагирования на изменения”. Для примера посмотрите какое пространство стратегического выбора существует при том минимальном количестве практик, которое есть в небольшой западной корпорации. И это я еще не смоделировал стратегии совершенствования, которых раза в два больше.
Стейкхолдеры команды.
Отдельно отмоделированы ролевые поведения стейкхолдеров команды, ответственных за исполнение практики.
каскад целей стейкхолдера.jpg
Каскад целей исполнителя.

При этом при планировании каскада целей и постановке целей по СМАРТ не надо забывать, что у практики тоже есть своя архитектура, определяющая достижимость и измеряемость целей:
0.jpg

Конкретный пример влияния архитектуры практики на стратегическое целеполагание:

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


  1. Портфельный, программный и проектный/процессный/кейс менеджмент. Зачем нужны практики? Проблема неявности конструкции работ предприятия, роль архитектора предприятия

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

Внимание, PMBOK подразумевает, что у компании есть стратегия, модель оценки бизнеса и портфельный менедмжент. Поскольку у большинства компаний этого нет, то модель OPM3 PMI не работает и все ударяются в некий “Эджайл”, а по факту принимают решения по месту, не учитывая интересы владельцев. Стоит ли разговаривать об успешности проектов в таких условиях?

Вы набрали портфель активностей, сбалансировали его, поставили задачи по элементам портфеля по СМАРТ, теперь надо спланировать ценность. Об этом много и хорошо говорит P2M standard и обстоятельно рассказывает Axelos MSP framework. Суть в том, чтобы так выстроить планы реализации, чтобы стратегии дали максимальный эффект. Программный менеджмент использует становящееся и up-front планирование, поэтому программные менеджеры, увидев возможности улучшения, часто изменяют свои вводные, беся этим процессных и проектных менеджеров. Это они не со зла, а из лучших побуждений. PMBOK иллюстрирует это табличкой:
пиэмбок.png
На уровне процессного и проектного управления уже идет детальное планирование в рамках конкретной методологии и предметной области.

Более детальные описания здесь:

  1. Зачем нужно системное лидерство?
“Сократить всех, кто не в разработке, производстве и продажах”.
Первое правило антикризисного реагирования менеджеров
CoQ concept.jpg

В принципе, у любой компании есть три ключевые функции, от которых зависит бизнес - разработка, производство и продажи. Зачем нужны остальные? Ранее был аргумент, что остальные нужны для расширения пространства стратегического выбора. Но это не единственный аргумент и не самый главный. Есть такая вещь, как качество. Это степень соответствия продукции или услуги требованиям клиента. И чтобы добиться качества нужно:
  • Понять, кто клиент и что ему нужно. Маркетинг и инженерия требований.
  • Понять, как удовлетворять требованиям множества клиентов на одном предприятии. Системная инженерия, инженерия предприятия, корпоративное управление и многое другое.
  • Проконтролировать и обеспечить, что производство производит, а продажи продают то, что клиент заказал. Управление конфигурацией, управление качеством.

И многое, многое другое. Например, в крупных проектах на одно только проектное управление и системную инженерию выделяет от 5 до 40% общего бюджета проекта. Только чтобы получить разумный, обоснованный уровень качества.
Обоснованность уровня качества определяется концептом “стоимости качества”, cost of quality, см. График. Это очень простая идея, состоящая из трех графиков - стоимости предотвращения несоответствия качеству, стоимости ошибки и стоимости оценки. Складываем эти три графика и получаем оптимум функции, который и будет обосновывать разумное распределение инвестиций между практиками жизненного цикла.

В общем и целом, я считаю, что на проектный менеджмент и системную инженерию на обычных проектах развития стоит выделять около 2% бюджета (1 руководитель проекта и 1 системный инженер на 100 человек проекта), плюс еще 2-3% на управление жизненным циклом команды (системное лидерство).

  1. Единство практик, стейкхолдеров, портфелей проектов и активов
“Это то же самое дерево, просто с другой стороны”. Слова стратега, переделавшего нашу стратегию так, что мы ее не узнали.
asset change project launch.jpg

Итак,
  • активы = системы = продукты проекта, все зависит от того, какой viewpoint используется
  • Управление проектами организации итеративно и постоянно уточняется, без этого смысл всей этой деятельности пропадает
  • Для управления проектами нужны три вещи - модель ценности предприятия (1), контроллинг, который будет измерять метрики модели ценности (2) и управление конфигурацией, которое будет поддерживать целостность и соответствие моделей предприятия реальности (3).

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

  1. Правильная постановка целей по СМАРТ. Архитектура процесса

Алгоритм работы:
1) Выберите цель мета-стратегии
2) Определите набор стратегий развития и совершенствования, которым будет реализована цель
3) Определите циклы развития и совершенствования практик жизненного цикла
4) Выберите подходящие технологии реализации шагов развития и совершенствования
5) Определите правила governance и соответствующие им accountability&compliance
6) Определите, как будут реализованы правила governance-compliance-accountability в выбранных технологиях (архитектура SMART)
7) Поставьте цель по SMART, сделайте каскадирование целей

В заключение.
В модели жизненного цикла некоторые стратегии отмечены оранжевым. Это те вещи, про которые я рассказываю на тренинге по системному лидерству, приходите. Кроме того, немного коснусь этой темы на конференции Адванты http://conference.advanta-group.ru/schedule (Зал 2 — Мастер-классы 15:50 — 16:40
"Как сэкономить деньги компании и зажечь команду на совместную работу?")