четверг, 18 октября 2018 г.

Как управление по контрольным точкам влияет на восприятие успешности проекта

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

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

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

Поэтому все пункты чек-листа делятся на:
1) Дисциплинарные. Проверка причинного вывода по основным дисциплинам. Должны быть предоставлены свидетельства, которые по микротеории дисциплины сдвигают оценку вероятности успешности проекта. Например "Архитектурные требования выделены и запланирована их проверка", "Скорость при посадке больше 200 узлов".
2) Технологические. Проверка готовности технологий к использованию. Должны быть предоставлены свидетельства того, что технология способна реализовать практику жизненного цикла. Например, "производственная линия выпускает продукцию по спецификациям с выходом годных 99.5% на пиковом времени такта в течение минимум трех производственных смен".
3) Архитектурные. Проверка правильности реализации архитектуры. Должны быть предоставлены свидетельства того, что архитектура системы соответствует определению архитектуры. Например, "команда согласна, что продукт реализован в соответствии с замыслом".
4) Надежности человека. Проверка минимум на skills based/rules based/knowledge based ошибки в ходе работ. Например, "аудит безопасности не выявил критических нарушений в технике безопасности на производственной линии, процесс обеспечения безопасности постоянно улучшается.

Пост про успешность системы http://sdu2020.blogspot.com/2018/06/blog-post_6.html
Пост про успешность проектов, программ и портфелей http://sdu2020.blogspot.com/2018/06/blog-post_7.html
Пост про онтологию мышления о рисках
Пост про уровни абстракции
Страница метода РИМ-3 https://rim-iii.postach.io
Контрольные точки при управлении проектами. Применение и проектирование https://www.litres.ru/uriy-shoydin/kontrolnye-tochki-pri-upravlenii-proektami-primeneni-35232320/

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

Факты могут относится к М0, предметной области конкретного проекта либо задачи, либо к М1 для контрольных точек из методологий (гейты, готовность рабочих продуктов метода) либо состояний подальф для данного класса проекта (ключевой технологический партнер выбран, где технологический партнер подальфа команды).

Методически КТ из М0 приходят из PBS/WBS и из диаграмм системного контекста, подробно я опишу эту практику в следующих постах.

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

Например, как это делает МинОбороны США:
Группировка обычно делается по структуре PBS/WBS, например, отслеживается не смена состояний системных элементов, а смена состояний подсистем. Учитывая, что системных разбиений может быть множество, в зависимости от дисциплин, которые задействованы в проекте, в проекте может быть множество планов по контрольным точкам - инженерный, маркетинговый и продажный, финансово-экономический и другие. Прожекторная модель позволит вам показывать только те КТ, которые значимы для данного стейкхолдера и сдвигают его оценку успешности проекта.

В примере чек-листов МинОбороны США можно четко увидеть использование подальф “платформа” для альфы “Система” и подальфы “релиз” для альфы “Определение системы”.

среда, 10 октября 2018 г.

Польза от архитектуры предприятия (обновлено 18.10.2018)

Системная инженерия предприятия и архитектура предприятия это сравнительно новая область знания, появилась в начале 90-х годов. Она до сих пор активно развивается и границы дисциплины не определены. Для примера можно сранвить программы российских и иностранных ВУЗов:


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


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


Если обобщить возможные выгоды от архитектуры предприятия, то их можно разбить на две большие группы:
- выгоды на уровне управления ИТ активами;
- выгоды от улучшения коммуникациями.

Примечание Романа Соколова:
Перед тем как оценивать пользу и вообще начинать проекты, хорошо бы уточнить какое определение EA мы используем (и соответственно scope проекта). Есть 3 школы-взглядов на EA -- enterprise IT architecture (EITA), enterprise integration (EI) and enterprise ecological adaptation (EEA).
В первом случае мы работаем над Business-IT Alignment, соответственно одна из главнейших задач там снижение расходов на ИТ, оптимизация и согласование ИТ-портфолио под нужды бизнеса.
Во втором, также известном как Enterprise Coherency, ИТ это всего лишь одна грань, кроме которой необходимо проектировать бизнес (операционную) архитектуру, capability planning, бизнес модели и т.п. и согласовывать все аспекты внутри одного предприятия между собой.
В третьей EA школе мыслей, фокус перемещается с одного конкретного предприятия на планирование межорганизационную кооперацию например правительств или всей цепочки поставщиков-дистрибьюторов, индустрии, глобального рынка -- в общем адаптация к ускоряющимся изменениям окружающей среды вокруг предприятия, которую можно планировать и менять. Здесь же все тренды на virtual/boundaryless/networked enterprise, аутсорсинг и облака, big data & IoT часто не под контролем предприятия, глобализацию, объединение культур и тп.
Вторая и третья школы EA это прямая отсылка к системному мышлению (которых кстати тоже много разных сортов, см. Jackson M.C. 2003), но прежде всего к open and soft systems thinking, холизму, конструктивизму. Очевидно, что польза во всех случаях будет разная, значит и метрики разные. И да, все три типа ЕА школ могут быть реализованы в одном предприятии, потому надо договариваться что мы имеем в виду под EA.

У меня есть пару более свежих статей ( https://aisel.aisnet.org/mcis2014/41 , https://ieeexplore.ieee.org/document/7880427 , https://www.researchgate.net/.../323848486_Achieving... ), в итоге EA ROI хоть с какими то цифрами было исследовано только в 2006 году ( https://pdfs.semanticscholar.org/.../5c1ee60125238185aa59... ), в 2015 Zachman приводит ЕА кейс с цифрами (doi: 10.1080/08874417.2013.11645654 , p.11-12) , и еще пару цифр здесь ( http://www.opengroup.org/cio/CIOCornerArticle11.htm ) -- хотя там автор говорил что EA и не должна иметь ROI и return on assets (ROA) подходит лучше.
Польза от ЕА неявная, это похоже на вопрос как оценить стратегическое планирование или более эффективное принятие решений (в чем помогает EA) или системную инженерию (у Левенчука в книге было пару цифр) или прочие архитектурные практики. А также похоже на проблему оценки knowledge management, т.к. EA is about share of strategic knowledge.

Второй по частоте упоминания гол EA -- борьба со сложностью и снижение затрат на ИТ происходит еще и из-за устранения дубликатов, когда например в компании более сотни бизнес юнитов со своими несогласованными ИТ департаментами, а соответственно и ИТ системами +переиспользование которые вы упомянули.
Раз уж мы говорим про вторую и третью EA школы, то польза там должна быть куда больше чем "выгоды на уровне управления ИТ активами", т.к. ИТ это всего лишь одна грань этих школ. Эти школы еще мало исследованы в научном сообществе (соответственно и их польза). Тем не менее, там речь про agile enterprise и быструю адаптацию к изменениям вокруг, и к трендам как техническим так и организационным, которые я упоминал в комментарии выше.
Lankhorst (один из ключевых разработчиков Архимейта) писал что в Архимейт с самого начала закладывались идеи networked enterprise, поэтому для второй и третьей школы нужны скорее новые вьюпоинты, а не совершенно новые концепты (хотя они и появляются в каждой новой версии языка). Т.е. моделирование ЕА в этих школах надо будет начинать с business network, а не с одного конкретного предприятия. По аналогии со стейкхолдерами, у каждого предприятия в сети будут свои роли. Межорганизационная кооперация также связывается с конкретными орг.процессами участвующих организаций, а также с ИТ сиситемами, стандартами, ограничениями и тп которые поддерживают эти орг.процессы.


Выгоды на уровне управления ИТ активами хорошо описал Гербен Вирда в ролике:



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



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

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



Итого:
1) Модель архитектуры предприятия нужна для устойчивой трансляции стратегии и видения первого лица до уровня руководителей, которые отвечают за исполнение стратегии.
2) Она задает общий язык и общие объекты внимания команды и говорит, что в организации важно, а что нет.
3) Она указывает на ключевые взаимосвязи и инварианты организации, не опускаясь до до подробностей реализации, которые ведутся в классических инструментах: органиграмма, модели бизнес-процессов и ИТ-ландшафт.
Распределенное лидерство и архитектура предприятия.