воскресенье, 15 января 2017 г.

Моделирование риск-ориентированных процессов в ArchiMate

Одно из типовых использований мотивационного расширения ArchiMate - моделирование рисков и обоснований проектов.

Пример такой модели:
Общий вид модели. Обратите внимание на трассировку требований стейкхолдера  элементам конструкции модуля-оргпроцесса.

Мотивационное расширение.Модель рисков процесса и проектное обоснование TO BE.

суббота, 14 января 2017 г.

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

Разнесу два понятия.
  1. “Стадия” жизненного цикла (ЖЦ) продукта (системы), характеризуется заметной сменой состояния описания либо воплощения системы. Находится в логическом времени.
  2. “Фаза” ЖЦ проекта (обеспечивающей системы) как временной промежуток, на котором команде проекта выделено целевое финансирование для выполнения определенных работ или реализации требований стейкхолдеров. Факт выполнения работ и удовлетворения требований демонстрируется в конце фазы. Находится в физическом времени.

И стадии и фазы используются при обсуждении проекта как системными инженерами таки проектными менеджерами (ПМ). Основная путаница у ПМ между стадиями и фазами происходит из-за подмены логического времени физическим (1) и слабого разделения описания и воплощения системы (2).

Наиболее распространенное современное понимание проекта подразумевает, что он существует только в рамках программы или портфеля и его цель (продукт проекта) задаются вне проекта, приходят либо в рамках бизнес-кейса программы либо каскадируются от стратегии (описания портфеля активностей) предприятия.
В соответствии с законом Конвея, архитектурные решения по организации проекта, тоже задаются снаружи, см. Устав/Паспорт/Бриф  и т.п. и идут от описания проблемы и целевого состояния предприятия.
В соответствии с обратным законом Конвея, “жесткая инфраструктура проекта”, такие как ИТ-ландшафт предприятия, обязательные регламенты по комплаенс и т.д., будут диктовать как оргструктуру проекта и структуру его фаз и предметов поставки (результатов проекта, deliverables).

***
Вставка
Что почитать про закон Конвея?

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

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

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

ПМБОК неявно подразумевает, что проектный менеджер является как инженером предпринятия, так и лидером.

В эту же копилку попадает т.н. “Ориентация на процесс” и “ориентация на результат”. Ориентация на процесс - это когда новый дизайн пытаются сделать в неподходящей коммуникационной структуре. Ориентация на результат часто трактуется как “достижение целевых показателей KPI” или “достижение целей организации”, так любимой другим популярным стандартом БАБОК.
Для меня есть лидерские практики, в которых гораздо важнее ориентация на процесс - риск-менеджмент, принятие решений, выявление требований. Они применяются к системам систем. И есть инженерные и управленческие практики, где применима логика и строятся алгоритмы достижения результата. Это и есть ориентированность на результат в моем понимании.
Отсюда вытекает объяснение, почему алгоритмы (проектные планы) неэффективны тогда, когда эффективны циклы (Шухарта, например). И здесь же пролегает еще одна граница между процессами и проектами, помимо стабильности модульной структуры и интерфейсов. Оргпроцессы-кейсы более эффективны с мягкими системами, чем проектно-алгоритмический подход. Отсюда все эти Эджайл проекты, которые своими итерациями крайне напоминают процессные циклы. Мягкие системы.
В общем и целом, границы размываются и надо уходить от всех этих проектных-процессных подходов в адаптивный кейс-менеджмент с холистической платформой как в части технологий, так и в части команды.
***

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


Поколение ПУ
Проект
Программа
1-ое поколение.
ПМ приходят из инженеров, подразумевается отличное знание предметной области. Сшивка целевой и обеспечивающей системы происходит в голове ПМ. Смерть подхода связана с превышением размера проекта предела, когда он помещается в голове одного человека.
Ориентирован на достижение запланированного результата в рамках тройных ограничений.
Запланированный результат задается вне проекта, сам проект покрывает только стадию жизненного цикла “Производство/Поставка”. Речь идет только об организации работ, ведущая дисциплина - исследование операций.
Т.к. люди бизнеса не понимали внутренностей проекта, единственный способ контроля за инвестициями была модель “стадия-гейт”.
Это такой большой проект, разве что из-за величины гораздо более важными становятся такие вещи, как контроль изменений и управление информацией.
Гейты еще более строгие, еще более длительные (до нескольких месяцев), происходит сшивка и согласование многих целевых и обеспечивающих систем.
2-ое поколение. Расцвет методологий и проектных офисов (офисов управления проектами, project management office, не путайте с офисом проекта project office).
Связаны с массовой компьютеризацией и второй промышленной революцией. Открытие процессного подхода в области управления качеством и рисками (мягкими системами) позволило сделать прорыв сложности. Получилось создавать успешные сложные системы для массового производства - автомобили, компьютеры, самолеты, бытовая и офисная техника. Смерть подхода связана с насыщением рынка, см. Современный Китай, где выпуск промпроизводства падает который год подряд и норма прибыли около ноля.

По иронии, государство сейчас внедряет гибрид между первым и вторым поколением.
Возникает четкое разделение между проектом, который нацелен на получение продукта, и программой, которая отвечает за получение эффекта.
Бизнес-кейс и архитектура целевой системы в классике приходит от уровня программы, но есть варианты, см. например PRINCE2 и MSP.
Управление представителями стейкхолдеров происходит здесь, есть разделение работ между ПМ, который работает с представителями стейкхолдеров в разрезе системы и ограничений проекта и бизнес-аналитика, который работает с логической архитектурой, требованиями и дизайном целевой системы.
К трем стандартным viewpoint добавляются еще качество, риски и многие другие.
Появляется separation of concerns и управление интеграцией, единственное, что эти рассмотрения происходят скопом как для целевой системы, так и для обеспечивающей, из-за чего возникает много путаницы.
Вводится понятие ЖЦ системы и появляются проекты управления системой на всем ЖЦ, см., например CDC UP https://www2a.cdc.gov/cdcup/library/pmg/default.htm
Но чаще всего проект захватывает либо стадию ЖЦ системы, либо ее часть, редко выходя за границы стадии. Слабо стыкуется с ЖЦ 2.0 как набора практик.
Операционный менеджмент уходит из критического пути в  критическую цепь, идет переход оценок из “классического” бета-распределения в байесовскую статистику , поощряется их уточнение по ходу выполнения работ. Становление системы канбан и управления узким местом прохода системы.
Успехом проекта начинает считаться удовлетворенность заказчика, повышается роль бизнес-кейса при управлении изменениями.
В рамках программного менеджмента определяется логическая и физическая архитектура обеспечивающей системы, решаются вопросы модульности и интерфейсов (контракт + сервис) внутри программы для проектных команд и снаружи программы для стейкхолдеров программы. Управление стейкхолдерами в аспекте интересов и работа с viewpoints происходит здесь.
ЖЦ системы как правило эволюционный, система становится, а не проектируется, соответственно программный менеджер часто меняет обеспечивающую систему - открывает новые проекты и закрывает текущие, меняет скоуп. Системные инженеры обитают на уровне программы, обеспечивают склейку
3-е поколение, развивающееся.
Уход проектных офисов, массовое их отмирание, переход методологической функции на проектные команды (ситуационная инженерия методов, временные методологии, становление метода в проекте, см. Блог Эдисона).
Связано со смертью массового производства в пользу кастомизированных продуктов с гораздо более коротким ЖЦ.
Один из основных профитов проектных офисов 2-го поколения - базы знаний и оценок теряют в современных проектах свое значение, т.к. и знание и оценки в силу изменения технологий теряют смысл.
Проекты из набора процессов-оргмодулей становятся наборами кейсов-оргмодулей, для каждого кейса проектируется метод. Целевая система рассматривается как холархия подсистем, для каждой из которых есть свои ЖЦ и метод разработки и производства. Склейка ЖЦ подсистем происходит в PLM.
Микрокоманды работают по раздельности внутри своих систем. Пример - Spotify https://www.youtube.com/watch?v=Mpsn3WaI_4k

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

На этом уровне существуют основные модели предпринятия.

Управление ресурсами проектов уходит на уровень программы, выделение динамическое, по Hyper Kanban или TameFlow.

Управление инфраструктурой проектов делится на две части - архитектурная (ERP, PLM, EAM и прочие ИТ-системы с высоким КАПЕКСом) остается на уровне программы, динамическая уходит в проекты и ее никто не контролирует.

3-е поколение вкратце и есть адаптивный кейс-менеджмент:
  1. Системный подход позволяет разбивать целевую систему на маленькие кусочки, которые можно отдать 2-pizza team и без проблем сшить итоговый результат
  2. Есть IT platform и people platform (я про нее писал недавно, пост про ПЛАС)
  3. Есть управленческая платформа - это архитектура предприятия и руководящие микропринципы (в моей терминологии это СОП, стандартные операционные процедуры, SOP, standard operating procedures).

А теперь перечитайте 100 правил руководителей проектов в НАСА, http://www.oliverlehmann.com/project-management-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf
Стало ли яснее, о чем они и что надо в них менять для современных проектов?


пятница, 6 января 2017 г.

Как улучшить майндмэп?

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

Это основы визуальной грамматики, позволяющей создать диаграммы из текста.

Перейти на визуальную грамматику непросто. Хорошо, если вы начнете с того, что будете ставить стандартные иконки в майндмэпах. Откройте их, посмотрите. Какая из них больше всего подходит под данный пункт? Что она напоминает? 

четверг, 5 января 2017 г.

Бриф Канемана "Думай медленно, решай быстро"

Книга на Озоне
1. Перегрузка информацией невыносима для мозга. Когда мы перегружаемся, мы фильтруем. Сильно фильтруем. И тогда шум становится сигналом.
2. Отсутствие смысла нас запутывает. И мы начинаем заполнять пробелы. Сигнал становится историей.
3. Нам нужно действовать быстро, иначе мы упустим шанс. И мы прыгаем к заключениям. Истории становятся решениями.
4. И тут все становится совсем сложно. Мы запоминаем только важные моменты. Решения определяют модели восприятия мира (mental models, cognitive framework).

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

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

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

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

В чем проблемы?
1. Мы не видим всей картинки. Часть информации, которую мы фильтруем, имеет значение и важна.
2. Наши поиски смысла могут вызывать иллюзии. Иногда мы придумываем детали и предположения, которые создают несуществующий смысл.
3. Быстрые решения могут быть очень плохими.
4. Наша память усиливает ошибочное поведение. Некоторые вещи, которые мы помним, приводят только к большему отклонению от правильного поведения и ухудшают ситуацию.

https://en.wikipedia.org/wiki/Availability_heuristic
http://rationalwiki.org/wiki/Frequency_illusion

понедельник, 2 января 2017 г.

Дональд Трамп о системном лидерстве

Это вы. И ваши конкуренты. И рынок. Рынок постоянно движется. Вы должны быть быстрее конкурентов.
Это вы. А это ваши конкуренты. Много конкурентов.
Это ваш рынок. Много рынков. Ваши специалисты говорят, что быстро-качественно-дешево не бывает. Рынки уменьшаются и места для всех не хватает. Нужно постоянно искать свою нишу.

Как ее найти и как в ней удержаться? В этом помогает системный подход.

Почему он поможет? На самом деле вам не надо быстро-дешево качественно. Вам надо быстрее-дешевле-качественнее, чем у других.


И тогда вы сможете наслаждаться (почти) одиночеством.

Как к этому подойти?

Вчерашний подход к менеджменту говорил, что достаточно разбираться на один уровень внизСейчас уже надо владеть деталями. Всеми деталями. Абсолютно всеми деталями.
Что будет завтра?
Что по этому поводу думают инженеры?
Вчера у инженеров был постоянный конфликт с производством. Теперь у них конфликты со всеми. Проекты стали слишком сложными и слишком дорогими. Цена ошибки все время возрастает. Интересы специалистов, менеджеров, предпринимателей кажутся несовместимыми.
Но есть одна вещь, которая их объединяет - это продукт или услуга, которую бизнес оказывает клиенту
Системный подход позволяет вам смотреть на тысячи людей, их деятельность, оборудование и программы и четко понимать, как каждый кусочек этой головоломки участвует в создании продукта или услуги. 
И это доступно любому образованному человеку. Не хотите получить ярлык эффективного менеджера после непродуманной реорганизации или проекта по повышению эффективности? Не хотите стать инженером, который создал хайтек продукт, который не нужен никому?


Изучайте системный подход, приходите на тренинг
Меня зовут Турханов Саша и я эксперт :)

среда, 28 декабря 2016 г.

Системное лидерство - тренинг

Если вы:


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

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

То это тренинг для вас.

В основу тренинга поставлен стандарт по управлению программами проектов Р2М, конкретно те разделы, которые описывают платформу сообщества (Р2М community platform). 

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

Для унификации терминологии с курсом системного мышления программа проектов далее будет называться предпринятием, а  платформа сообщества программы «платформой сообщества предпринятия», далее ПЛАС. 

Здесь и далее используется модульное рассмотрение предпринятия, т.е., программа или портфель проектов состоит из отдельных проектов и кейсов.

Необходимое предварительное требование программы обучениякурс системного мышления Школы системного менеджмента в объеме первых трех дней.
Материал курса намеренно предельно урезан и приближен к практическим навыкам (hard skills).
Место ПЛАС в управлении программой проектов

Содержание тренинга. То, что будет даваться. Сгруппировано не в порядке подачи материала, а по смысловым блокам.

1. Архитектура платформы сообщества предпринятия
a. Место ПЛАС в архитектуре программы
b. Модель мотивации деятельности в программе
c. Функциональная схема ПЛАС
d. Основные модульные решения ПЛАС
e. Основные подальфы команды, их состояния (новый руководитель, новый подчиненный, сформировавшаяся команда с новым руководителем, неорганизованный член команды, неэффективный член команды, эксперт, творческий работник, член команды с проблемами общения, суперзвезда)
f. Основные интерфейсные решения ПЛАС

2. Коммуникационные циклы и модели
a. Циклы информирования (для исполнителя)
b. Циклы влияния (для knowledge worker)
c. Циклы ритуального общения
d. Модель коммуникации DEMO
e. Технологии использования коммуникационных циклов
f. Ситуационное лидерство и паттерны работы с подальфами команды
g. Типовые проблемы и ошибки в коммуникационных циклах (кризисы производительности и доверия), подход к восстановлению разрушенных отношений в команде

3. Дисциплины
a. GTD и Тойота Ката (адаптированный вариант пустого инбокса Максима Дорофеева)
b. Визуальная грамматика
c. Основные ошибки мышления (cognitive bias)
d. Принятие решений по схеме WRAP
e. Эмоциональный интеллект
f. Техника переговоров Джима Кэмпа
g. Управление организационными изменениями по методике changesetter (круг изменений, микс 4 комнат, Коттера и ситуационного лидерства)

Программа обучения 2 дня, домашние задания, вебинар, две личные сессии по Скайп по домашнему заданию. Лекции, итоговый семинар, симуляция проекта организационных изменений.
Предварительная подготовка – Джим Кэмп «Сначала скажите нет», «Ловушки мышления» Чип и Дэн Хиз. Подготовка к деловой игре, анализ и групповая работа над переговорной позицией

Программа обучения
День 1. Коммуникационные циклы и модели. Основные подальфы команды и практики работы с ними. Деловая игра «Переговоры в проекте внедрения CRM» команда филиала-внедренца против команды корпоративного центра. Разбор итогов игры с использованием материалов курса.
Домашнее задание. «Эмоциональный интеллект. Российская практика», «Бла-бла-бла» Дэн Роэм, «Наш айсберг тает» Коттер. Минимум 5 прогонов на симуляторе организационных изменений.

День  2. Разбор результатов симуляции. Changesetter и связь с подальфами команды. Архитектура ПЛАС. Закрывающая сессия.
Домашнее задание. «Все начальники делают это» Тулган, «Как привести дела в порядок» Аллен.
Сессии по разбору ситуаций в проектах участников, планирование индивидуальных траекторий развития с использованием подхода Making the Matrix work by Kevan Hall.




вторник, 27 декабря 2016 г.

Сравнение бизнес-анализа и системного мышления


Резюме после пролистанных по диагонали 120 страниц.

Бизнес-анализ примерно соответствует инженерии требований. Главными артефактами работы аналитика, работающего на основе BABOK является гармонизированный набор требований и логической архитектуры решения.

Два ключевых отличия аналитика от инженера по требованиям:
1) Не используется прием абстрагирования системы как черного ящика с сервисом и интерфейсом, требованиями называются как требования, так и ограничения и архитектура;
2) Не рассматривается воплощение системы, работа аналитика завершается выпуском т.н. "архитектуры требований", которая состоит из гармонизированного набора требований и логической архитектуры. Модели привязаны (оттрассированы к модулям).

В чем системное мышление и бизнес-анализ схожи?

  1. Работают со стейкхолдерами, сгруппированными по интересам. Каждому интересу предъявляют свой частный метод описания и частное описание.
  2. Работают с потребностями, потребности фокусируют требования. Используется целеориентированная инженерии требований, есть трассировка от стейкхолдеров и их целей к требованиям и архитектуре. Требования рассматриваются как функциональный объект (альфа), с набором состояний.
  3. Используется функциональная декомпозиция, требования трассируются к модулям.
  4. Есть понятие платформы системы как набора типовых архитектурных решений
В чем системное мышление и бизнес-анализ различаются?
  1. Требования и архитектура (requirements and designs) постоянно путаются и смешиваются. Прямо заявляется "Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle".
  2. Состояния альфы "Требования" определяется по усмотрению, нет чек-листа для определения состояния требований.
  3. Под верификацией БА подразумевает " Requirements (verified): a set of requirements that have been verified to be of sufficient quality to be used as a reliable body of work for further specification and development...Verify Requirements: ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality." Т.е., верификация требований в БА - это соответствие требований требованиям к требованиям.
  4. Под валидацией БА подразумевает "Validate Requirements: ensures that a set of requirements or designs delivers business value and supports the organization's goals and objectives", т.е., валидация производится против требований к обеспечивающей системе.
  5. Методы БА не могут быть рекурсивно использованы на любом уровне холархии системы. Системы задаются объективно. Холархия требований отсутствует.
  6. Воплощение системы не рассматривается, жизненный цикл системы с выделенной стадией эксплуатации не используется, хотя стейкхолдеры из стадий использования и обслуживания заявлены.
  7. Стейкхолдеры не рассматриваются в ролях, 4Д экстенсионализм к ним не применяется. Роль стейкхолдера фиксирована на исполнителе.
  8. В БА платформы системы не содержит типовых интерфейсов и модулей.
  9. БА использует пять аспектов рассмотрения системы "The perspectives included in the BABOK® Guide are:• Agile• Business Intelligence• Information Technology• Business Architecture• Business Process Management"
  10. Функциональное разбиение используется по большей части при анализе оргпроцессов, не используется при модульном синтезе. Модульный синтез основан на фольклоре (мозговые штурмы, рабочие встречи), нет метода.
  11. Логическая и физические архитектуры не связаны "Requirements architecture is the structure of all of the requirements of a change. A requirements architecture fits the individual models and specifications together to ensure that all of the requirements form a single whole that supports the overall business objectives and produces a useful outcome for stakeholders.Business analysts use a requirements architecture to:• understand which models are appropriate for the domain, solution scope, and audience,• organize requirements into structures relevant to different stakeholders,• illustrate how requirements and models interact with and relate to each other, and show how the parts fit together into a meaningful whole,• ensure the requirements work together to achieve the overall objectives, and• make trade-off decisions about requirements while considering the overall objectives. Requirements architecture is not intended to demonstrate traceability, but rather to show how elements work in harmony with one another to support the business requirements, and to structure them in various ways to align the viewpoints of different stakeholders. Traceability is often used as the mechanism to represent and manage these relationships (see Trace Requirements (p. 79)). Traceability proves that every requirement links back to an objective and shows how an objective was met. Traceability does not prove the solution is a cohesive whole that will work."