Системный менеджмент и стратегирование

А.Левенчук. Системный менеджмент и стратегирование 7 марта 2018г.
Школа системного менеджмента 1
Системный менеджмент и
стратегирование
Материалы к тренингу А.Левенчука
(4 дня, версия 9 потока)
Москва
7 марта 2018г.
Материалы курса «Системный
менеджмент и стратегирование»
• Материалы были использованы в выпуске
девяти потоков тренинга «Системный
менеджмент и стратегирование» в Школе
системного менеджмента.
• В шестидневном тренинге первые два дня
было посвящено курсу «Системное
мышление» в объёме учебника
А.Левенчука
(https://ridero.ru/books/sistemnoe_myshlen
ie/) и видео и задач курса Coursera
http://www.systemsthinkingcourse.ru/.
• Нумерация тем части системного
менеджмента и стратегирования была
оставлена такой, какой она была в полном
шестидневном курсе (дни 3-6).
2

Курс и его контекст
Фитнесы (личное развитие)
Двигательный фитнес (4 дня)
(Онто)логический фитнес (4 вечера)
Системное мышление
1. Как определить свою систему среди чужих
2. Жизненный цикл системы или проекта?
Системный менеджмент и стратегирование
3. Управление жизненным циклом и управление работами (1 день)
Организационноеразвитие: оргизменения и стратегирование(3 дня)
4. Развитие и совершенствование
5. Архитектура предприятия
6. Стратегирование
Системное лидерство(2 дня)
Системная инженерия (практики MBSE)
Системнаяинженерия. Высокоуровневое моделирование на стадии разработки (4
дня+защита)
3
3. Управление жизненным циклом и
управление работами

Программа
0. Повторение системного мышления: знакомство
1. Управление жизненным циклом
• метод контрольных вопросов
• события и контрольные точки
2. Операционное управление
• метафора потока
• проект? программа? процесс? кейс?
• DEMO
3. Лучшие практики "управлений" (проектами,
процессами, задачами)
• где "запасы", которые нужно минимизировать в разработке?
• TOC, lean 2.0 и kanban
• с чего начнёте у себя?
4. Учёт и контроль как фундамент изменений
• Операционный учёт: управление конфигурацией целевой
системы (ALM, PLM, ERP, EAM)
• Управление конфигурацией обеспечивающей системы:
архитектура предприятия 5
0. Знакомимся!
• Расскажите о себе и своих занятиях.
• Для рассказа используйте материалы курса.
6

1. Управление жизненным циклом
• метод контрольных вопросов
• события и контрольные точки
7
Системная схема проекта
8
Технологический
менеджмент и
предпринимательство
Инженерный
менеджмент
Инженерия
Технологический
Using system
Enabling system
Systemof interest

Менеджерские практики в
системной инженерии
• ISO 15288:2015 (третья редакция) – практики
(processes) жизненного цикла системной инженерии
• Если выполняете практики – это и есть системная
инженерия
• Служит чеклистом
• Заведомо избыточен, его любят военные и
правительства
• Договорились в терминологии и наборе практик
ориентироваться на него.
• Упражнение: что вы осознанно делаете в своих
предприятиях из там написанного?!
• Какие альтернативы
указанным практикам
вы знаете?
9
Это технология (way of working) – это
относится к виду жизненногоцикла:
практикам.
Это не о модулях: процессах, не проектах,
делах (кейсах) – это о практикахих
ведения, компонентах.
Управление работами и
жизненным циклом
• Управление работами (operations management) –
управление выделением ресурсов для прохождения
всех контрольных точек в срок и в соответствии с
бюджетом.
• Управление проектами, программами, портфелями
• Управление процессами
• Управление кейсами/задачами/поручениями (ведение
дел), трекинг контрольных точек
• Управление жизненным циклом (lifecycle
management) – назначение практик на работы,
чтобы получился результат без конфигурационных
коллизий.
• водопад
• Agile
• Управление конфигурацией и изменениями (инженерной
документацией, PLM)
10

Междисциплинарность
в управлении деятельностью
(управлении обеспечивающей системой)
На основе
рис.3
в ISO 81346-1
-Модули (работы проекта,
процессы, задачи и
поручения)
=Компоненты
(практики ЖЦ)
+Места
выполнения
работ
Все специальности
• Проектное управление
• Процессное
управление
• Управление задачами
• Управление
персоналом
жизненнымциклом
• …
Все стадии ЖЦ
• Замысел
• Проектирование,
конструирование
• Сооружение,
изготовление
• Эксплуатация
• Модернизация
PLM/ALM, ERP, EAM
• Модель продукта – ЧТО делать
• Модель проекта (project) – что ДЕЛАТЬ
11
12
«Процесс»
«Процедура»
«Функция»
«Деятельность»
«Шаблон проекта»
ПланировщикМенеджер
по качеству
Менеджер
Консультант
Аналитик
http://ailev.livejournal.com/1195297.html
По материалам
компании FutureModels
Нужно как-то договориться: онтология
Что они имеют ввиду?! Компоненты или модули предприятия?
Если модули, то проекты или процессы? Или что-тодругое?

Жизненные циклы системы и проекта
удовлетворены в
использовании
представлены
признаны
извлекается
выгода
нужно решение
польза
установлена
жизнеспособна
определена
Используетсядля
вывода из
эксплуатации
непротиворечиво
используетсядля
замыслено
выведено из
в виде частей
демонстрируемо
эксплуатируется
закрыта
подготовлена
под контролем
закончена
инициирована
сформирована
сотрудничает
намечена
основа положена
наличествует
работает хорошо
принципы
установлены
стейкхолдеры возможность
определение
системы
воплощение
системы
работа команда технология
замысел
проектирование
разворачивание
испытания
изготовление
вышла из
употребления
распущена
готово
проверки
воплощения
вовлечены
удовлетворены для
разворачивания
использована
начата
производитиспользуетсядля
изготовления
в виде сырьяв согласии
используется
Вид жизненного цикла: все проекты разные
удовлетворены в
представлены
признаны
извлекается
выгода
нужно решение
польза
установлена
жизнеспособна
определена
вывода из
непротиворечиво
замыслено
выведено из
в виде частей
демонстрируемо
закрыта
подготовлена
закончена
инициирована
сформирована
намечена
основа положена
наличествует
принципы
стейкхолдеры возможность
определение
системы
воплощение
системы
работа команда технология
Под-
держка
Поддержка
вышла из
распущена
готово
проверки
воплощения
вовлечены
удовлетворены для
использована начата
производит
в виде сырья
в согласии
используется
Приёмка
эксплуатируется работает хорошосотрудничаетпод контролем

Как дела?! Контрольные вопросы для снятия рисков в
командной работе
• Отражают не всё, а только главное (что все
знают, но почему-то забывают и
игнорируют).
• чеклист запуска двигателя в полёте: 1. Fly the
aircraft!
• Прогон в специальных паузах (pause point)
перед началом или перед окончанием
каких-то работ (обнаружить проблемы,
пока не поздно, гарантировать их
обнаружение!)
• Обязательно вслух перед всеми (общее
знание проблем)
• Проблемы находятся только 1 раз из 10.
Этот один раз полностью окупает все
затраты на остальные десять.
15
Штурм событий
• Софт: отражение предметной области
• Domain driven development (DDD) – «отражать
нужно явно»
• Два подхода к онтологической инженерии:
явные объекты («народная онтология») и
неявные объекты (результат моделирования,
исследования).
• Опора на события – изменения состояний
предметов, результаты взаимодействий
предметов
16

Контрольные вопросы: карточки
17
Признаны
1/6
Стейкхолдеры
Стейкхолдеры были определены.
 Все различные группы
стейкхолдеров, которые на данный
момент, или в будущем будут
затронуты разработкой и
функционированием инженерной
системы, определены.
 Есть соглашение по группам
стейкхолдеров, которые будут
представлены. Как минимум,
должны приниматься в расчёт
группы стейкхолдеров, которые
финансируют, используют,
поддерживают и обслуживают
систему.
 Ответственности представителей
стейкхолдеров были определены.
Рабочие продукты:
«чем докажешь»?
Длинный список
стейкхолдеров
Короткийсписок
стейкхолдеров,и
он утверждён
В коротком списке
указано, за что
ответственны
представители
стейкхолдеров
Дела в план
Узнать…
Провести
совещание
Обсудить и
сформулир
овать
Деятельность/практики меняют альфы/компоненты
Дела/работы/процессы/задачи/проекты меняют рабочие
продукты
18
меняют детальность
меняет состояния
продвигаетописывает
Практики
(компоненты) из
вида ЖЦ
Работы, дела, и процессы
(модули)из жизни
Как работает
(как организовать)
Как сделать (управлять)

Методологии управления работами
и контрольные вопросы
Можем спланировать:
• Проектное управление: контрольные точки
• Процессное управление: постусловия операций
Не можем спланировать (трекинг/мониторинг):
• Управление делами (кейс-менеджмент): цели
• Продуктное (product): нам говорят, как работать
• Адаптивное (adaptive): мы сами придумываем, как
работать
• Поручения – это кейсы/issue
19
Контрольная точка
Контрольная точка = контроль события выполнения
требования
Событие = момент изменения состояния, результат
работы
Контрольная точка = требование + время события
Требование = деонтическая модальность
+ высказывание (assertion)/описание
+ указание описываемой системы
20

6-, Multi-, poly-, … D
• Все контрольные точки делаются на базе частей
системы, т.е. на базе product model
• Для каждой части системы предусматриваются
типовые контрольные точки (спроектирована,
заказана, получена, смонтирована, проверена)
• Моменты времени для контрольных точек
расставляются исходя как из технологической
последовательности (сначала стены, потом
крыша), так и из балансировки ресурсов
(«побыстрее» против «равномерной загрузки»
• Проверка – анимационными роликами
(имитационное моделирование)
21
Жизненный циклсистемы(клиент)________________________________________
22
Признаны
1/6
С тейкхолдеры были определены.
 Все различные группы
стейкхолдеров, которые на
данный момент, или в
будущем будут затронуты
разработкой и
ф ункционированием
инженерной системы,
определены.
 Есть соглашение по группам
стейкхолдеров, которые будут
представлены. Как минимум,
должны приниматься в расчёт
группы стейкхолдеров,
которые ф инансируют,
используют, поддерживают и
обслуживают систему.
 О тветственности
представителей стейкхолдеров
были определены.
Представлены
2/6
М еханизмы вовлечения
стейкхолдеров согласованы и
назначены представители
стейкхолдеров.
 Представители стейкхолдеров
согласились выполнять свои
обязанности.
уполномочены выполнять свои
обязанности.
 Подход к обеспечению
сотрудничества среди
представителей стейкхолдеров
был согласован.
поддерживают и уважают
технологию работы команды.
Вовлечены
3/6
Представители стейкхолдеров
активно вовлечены в работу и
выполняют свои обязанности.
помогают команде в
соответствии со своими
обязанностями.
обеспечивают обратную связь
и принимают участие в
принятии решений
своевременно.
быстро сообщают изменения,
которые имеют значение для
их групп стейкхолдеров.
В согласии
4/6
Представители стейкхолдеров в
согласии.
согласились с минимальными
ожиданиями по следующему
разворачиванию новой системы.
удовлетворены своей
вовлечённостью в работу.
согласны, что их вклад в работу
ценится командой и учитывается в
работе с уважением.
 Члены команды согласны, что их
вклад в работу ценится
представителями стейкхолдеров и
учитывается в работе с
уважением.
согласны с тем, как их различные
приоритеты и точки зрения
балансируются для обеспечения
ясного руководства для команды.
Удовлетворены для
5/6
М инимальные ожидания
представителей стейкхолдеров были
достигнуты.
обеспечивают обратную связь
с точки зрения их групп
подтверждают, что система
готова для разворачивания.
Удовлетворены в
6/6
С истема удовлетворяет или
превышает минимальные ожидания
 С тейкхолдеры используют
новую систему и
предоставляют обратную связь
об их опыте.
 С тейкхолдеры подтверждают,
что новая система
соответствует их ожиданиям.
Определена
1/6
Возможность
Коммерческая, общественная или
инвестиционная возможность,
которая могла бы быть адресована
инженерным решением, определена.
 Идея по способу улучшения
текущих технологий работы,
увеличения рыночной доли
или по применению новой или
инновационной инженерной
системы была определена.
 Как минимум один из
стейкхолдеров желает сделать
инвестицию в более подробное
понимание возможности и
пользы, связанной с
адресацией этой возможности.
 Другие стейкхолдеры, для
которых это общая
возможность, определены.
Нужно решение
2/6
Потребность в инженерном решении
была подтверждена.
 С тейкхолдеры для возможности
и предложенное решение были
 Потребности стейкхолдеров,
которые порождают
возможность, были установлены.
 Любые связанные с
возможностью проблемы и их
корневые причины были
 Было подтверждено, что
инженерное решение нужно.
 По меньшей мере одно
инженерное решение было
предложено.
Польза установлена
3/6
Польза успешного решения была
установлена.
 Польза адресации возможности
была определена количественно
либо в абсолютных значениях,
либо в единицах дохода или
экономии за период (например,
за год).
 Влияние решения на
стейкхолдеров понятно.
 Польза, которую инженерная
система предлагает
стейкхолдерам, которые
ф инансируют и используют
систему, понятна.
 Критерии успеха, по которым
будет приниматься решение о
разворачивании системы, ясны.
 Желаемые результаты,
требуемые от решения, ясны и
определены количественно.
Жизнеспособна
4/6
С огласовано, что решение может быть
произведено достаточно быстро и
дёшево, чтобы успешно адресовать
возможность.
 Р ешение обрисовано в общих
чертах.
 Есть признаки, что решение
может быть разработано и
развёрнуто в текущих
ограничениях.
 Р иски, связанные с решением,
приемлемы и управляемы.
 Грубая оценка цены решения
меньше, чем ожидаемая польза от
реализации возможности.
 Причины для разработки
инженерного решения
понимаются всеми членами
команды.
 Ясно, что реализация
возможности жизнеспособна.
Адресована
5/6
Р ешение, которое произведено,
демонстрирует адресацию
возможности.
 Готовая к использованию
система, которая
демонстрирует реализацию
возможности, доступна.
 С тейкхолдеры согласны, что
доступное решение
заслуживает разворачивания.
 С тейкхолдеры удовлетворены
тем, как разработанное
решение адресует
возможность.
Извлекается выгода
6/6
Э ксплуатация или продажа решения
создаёт осзязаемые выгоды.
 Р ешение начало извлекать
выгоды для стейкхолдеров.
 Проф иль возврата инвестиций
по меньшей мере так хорош,
как ожидалось.

Жизненный циклсистемы(инженерное решение)_______________________________
23
Замыслено
1/6
Определение
системы
Ясно, каково будет определение
системы.
 Ясно, что будет считаться
успехом для новой систем.
 М етоды описания системы
согласованы.
 С пособ согласования описаний
со стейкхолдерами согласован.
 М еханизмы управления
конф игурацией описаний
согласованы.
Непротиворечиво
2/6
О пределение системы создано и
непротиворечиво.
 О писания документированы и
доступны команде и
стейкхолдерам.
 Происхождение описаний
ясно.
 О писания проверяются.
 Противоречивые описания
идентиф ицированы и ими
занимаются.
 Команда понимает описания и
соглашается их воплотить.
 С истема, соответствующая
описаниям, принимается
стейкхолдерами как
заслуживающая воплощения.
Используется для
3/6
О пределение системы используется
для изготовления системы.
 Подготовлено достаточное
количество описаний системы,
чтобы начать изготавливать
систему.
 Т ехнологии изготовления
 Часть команды,
изготавливающая систему,
признаёт описания
достаточными для
изготовления системы.
 Возникающие при
изготовлении проблемы
приводят к переработке и
актуализации определения
системы.
проверкивоплощения
4/6
для проведения тестов и испытаний.
 Нет частей определения
системы, без которых
проверки невозможны.
 Проверки, критерии их
успешности и способ их
проведения определены.
 С тейкхолдеры согласны с
объемом проверок.
Используется для
5/6
стейкхолдерами для её
эксплуатации.
 О пределение системы
используется для сбора
инф ормации о состоянии
эксплуатируемого воплощения
системы.
 О пределение системы наряду с
инф ормацией о состоянии
эксплуатируемой системы
используется для принятия
решений о техобслуживании,
ремонтах, модернизации.
вывода из эксплуатации
6/6
для ликвидации и/или переработки
системы.
используется для определения
момента вывода из
эксплуатации или принятии
решения о продлении
демонстрирует отсутствие
вредных эф фектов (например,
загрязнения окружающей
среды) при выводе системы из
используется для
планирования и проведения
работ по ликвидации и/или
переработке воплощения
системы.
В виде сырья
1/6
М атериалы для воплощения системы
наличествуют и готовы к
изготовлению частей.
 М атериалы для воплощения
системы наличествуют и
позволяют создать детали с
нужными характеристиками.
 О борудование для
переработки материалов в
детали наличествует.
 Граф ик производства и
логистики деталей согласован.
 Возможны работы по
изготовлению деталей.
В виде частей
(parts)
2/6
Части системы созданы и готовы к
интеграции.
 Детали системы созданы и/или
закуплены и проверены.
 Граф ик интеграции (сборки,
монтажа, строительства) из
частей согласован.
 Возможны работы по интеграции
(сборке, монтажу,
строительству).
Демонстрируемо
3/6
С истема собрана из её частей и готова
к проверке.
 С истема может быть опробована
в её отдельных ф ункциях и её
ключевые характеристики могут
быть измерены.
 Ключевые характеристики
системы могут быть
продемонстрированы.
 Критические интерфейсы были
продемонстрированы.
 Интеграция с другими
существующими системами была
продемонстрирована.
 Необходимые стейкхолдеры
согласны, что систему нужно
проверять.
Готово
4/6
С истема (как целое) была принята для
эксплуатации её в операционном
окружении.
 Функциональность, обеспечиваемая
системой, протестирована.
 У ровни деф ектов приемлемы для
 У становочная и другая
пользовательская документация
доступна.
принимают систему, как
удовлетворяющую своему
назначению.
 С остав передаваемой стейкхолдерам
системы известен.
 Представители стейкхолдеров хотят
принять систему в эксплуатацию.
 Э ксплуатационная поддержка
наличествует.
Эксплуатируется
5/6
С истема эксплуатируется в её
операционном окружении.
 С истема сделана доступной
стейкхолдерам, которые
намерены её использовать.
 Есть как минимум один пример
полностью работающей
системы.
 С истема полностью
поддерживается на
согласованном уровне
сервиса.
Выведеноиз
6/6
Воплощение системы больше не
поддерживается, система
ликвидирована и/или переработана.
 Воплощение системы было
заменено или прекращено в
использовании.
 С истема больше не
поддерживается.
 Нет «оф ициальных»
стейкхолдеров, которые до сих
пор используют систему.
 Доработки /доделки системы
больше не будут производиться.
 Все материальные компоненты
системы либо повтороно
используются, либо надлежащим
образом ликвидированы.
системы
системы
системы
системы
системы
Воплощение
системы
системы
системы
системы
системы
системы
Жизненный циклсистемы(предпринятие)________________________________________
24
Намечена
1/5
Команда
М иссия команды ясна и знания о том, как
растить команду, наличествуют.
 М иссия команды определена в
терминах возможностей и результатов.
 О граничения на работу команды
известны.
 М еханизмы для роста команды
наличествуют.
 С остав команды определён.
 Все ограничения, определяющие где и
как будет выполняться работа,
 О бязанности команды обрисованы в
общих чертах.
 У ровень принятых командой
обязательств ясен.
 Т ребуемые компетенции определены.
 Р азмер команды определён.
 Правила контроля за деятельностью
 Форма управления выбрана.
Сформирована
2/5
Команда была пополнена достаточным
количеством людей с принятыми
обязательствами, чтобы начать миссию.
 Индивидуальные обязанности понимаются.
 Было набрано достаточное число членов
команды, чтобы работа продвигалась.
 Каждый член команды понимает, как
команда организована, и какая у него
индивидуальная роль.
 Все члены команды понимают, как
выполнять их работу.
 Все члены команды встретились
(возможно, виртуально) и начинают узнавать
друг друга.
 Члены команды понимают их обязанности
и как они увязаны с их компетенциями.
 Члены команды принимают работу.
 Любые внешние смежники (организации,
команды и индивиды) определены.
 М еханизмы общения в команде
 Каждый член команды принял
обязательство работать в команде, как это
определено.
Сотрудничает
3/5
Члены команды работают вместе
как одно подразделение.
 Команда работает как одно
сплочённое подразделение.
 О бщение в команде открытое
и честное.
 Команда сф окусирована на
достижение миссии команды.
 Члены команды знают друг
друга.
Производит
4/5
Команда работает результативно и
эф ф ективно.
 Команда систематически
выполняет обязательства.
 Команда непрерывно
адаптируется к
изменяющемуся контексту.
 Команда определяет и
адресует проблемы без
внешней помощи.
 Прогресс в результатах
достигается с минимальным
необходимым возвращением к
сделанному и переделками.
 Р абота впустую и причины для
работы впустую постоянно
устраняются.
Распущена
5/5
Команда больше не ответственна за
выполнение своей миссии.
 О бязанности команды были
переданы или прекращены.
 Члены команды доступны для
назначения в другие команды.
 Командой не предпринимается
дальше никаких усилий для
завершения миссии..
Инициирована
1/6
Р абота была запрошена.
 Р езультат, требуемый от
инициированной работы, ясен.
 Любые ограничения на
выполнение работы ясно
 С тейкхолдеры, которые будут
ф инансировать работу,
известны.
 Инициатор работ известен.
 С тейкхолдеры, которые будут
принимать работу, известны.
 Источник ф инансирования
ясен.
 Приоритет работы ясен..
Подготовлена
2/6
Все предусловия для начала работы
выполнены.
О бязательства приняты.
Цена и потребные усилия оценены.
Доступность ресурсов понимается.
Правила и процедуры контроля ясны.
Р иски понимаются.
Критерии приёмки определены и
согласованы с клиентом.
Р аботы разбиты достаточно для того,
чтобы началась производительная
работа.
С тейкхолдерами и командой задачи
определены и приоритизированы.
П Правдоподобный план
Финансирование для начала работы
Команда или, как минимум, часть
команды готова начать работу.
М оменты интеграции и поставки
Начата
3/6
Р абота происходит.
 Р абота по разработке начата.
 Прогресс работы отслеживается.
 Р абота разбита на единицы
действий с ясными
определениями того, что нужно
сделать.
 Члены команды принимают и
выполняют задания.
Под контролем
4/6
Р абота продвигается хорошо, риски под
контролем, уровень производительности
достаточен для достижения
удовлетворительного результата.
 Количество завершенных задач
растёт.
 Незапланированная работа под
контролем.
 Р иски под контролем, их влияние,
если они реализуются, и
вероятность их реализации
снижены до приемлемых уровней.
 О ценки пересматриваются, чтобы
отражать производительность
команды.
 Доступны меры для показа
продвижения и скорости работы.
 Переделки под контролем.
 Задачи успешно завершаются
вовремя и в соответствии с их
оценками.
Закончена
5/6
Р абота по производству результатов
была закончена.
 Все невыполненные задачи
относятся к административным
или подготовке к следующему
куску работ.
 Р езультат работ был
достигнут.
 С тейкхолдеры приняли
результирующую инженерную
систему.
Работа
КомандаКомандаКомандаКоманда
Работа Работа Работа Работа
Закрыта
6/6
Все остающиеся служебные задачи
были завершены и работа была
оф ициально закрыта.Полученные
уроки были сф ормулированы,
записаны и обсуждены.
 М етрики были сделаны
доступными.
 Всё было архивировано.
 Бюджет был сверен и закрыт.
 Команда была освобождена.
 Нет незавершённых,
недоделанных задач.
Работа

Жизненный циклсистемы(предпринятие)________________________________________
25
Принципы
1/6
Технология
Принципы и ограничения, которые
определяют технологию, установлены.
 Команда придерживается принципов
и ограничений.
 Принципы и ограничения
согласованы стейкхолдерами.
 Потребные для работы инструменты
и их стейкхолдеры согласованы.
 Р екомендации по избранному
подходу доступны.
 Контекст, в котором будет работать
команда, понятен.
 О граничения, которые применимы к
выбору, приобретению и
использованию практик и
инструментов, известны.
Основа положена
2/6
Ключевые практики и инструменты, которые
ф ормируют основу технологии, выбраны и
готовы к использованию.
 Ключевые практики и инструменты,
которые формируют основу технологии,
выбраны.
 Командойсогласовано достаточное число
практик, чтобы начать работу.
 Все не подлежащие обсуждению практики и
инструменты были определены.
 Неувязки, которые есть между доступными
практиками и инструментами, и
необходимыми практиками и
инструментами, проанализированы и
поняты.
 Неувязки между тем, что нужно для
выполнения желаемой технологии и
уровнем возможностей команды,
проанализированы и поняты.
 Выбранные практики и инструменты были
интегрированы, чтобы сформировать
технологию, которую можно использовать.
Используется
3/6
Некоторые члены команды
используют технологию и адаптируют
её.
 Практики и инструменты
используются для реальной
работы.
 Использование выбранных практик
и инструментов регулярно
проверяется.
адаптированы к контексту
команды.
 Использование практик и
инструментов командой
поддерживается.
 Процедуры для учёта обратной
связи по поводу технологии
работы команды – наличествуют.
поддерживают общение команды и
сотрудничество.
Наличествует
4/6
Все члены команды используют
технологию, чтобы выполнять свою
работу.
используются всей командой
для выполнения работы.
 Все члены команды имеют
доступ к практиками и
инструментам, требующимся
для их работы.
 Вся команда вовлечена в
проверку и адаптацию
технологии.
Работает хорошо
5/6
Т ехнология для команды работает
хорошо.
 Члены команды продвигаются
в работе согласно плану,
используя технологию и
адаптируя её к их текущему
контексту.
 Команда естественно
применяет практики, не
задумываясь о них.
 Инструменты естественно
поддерживают способ работы
команды.
 Команда постоянно
подстраивает своё
использование практик и
инструментов.
ТехнологияТехнологияТехнологияТехнология
Вышлаиз
6/6
Т ехнология больше не используется
командой.
 Т ехнология команды больше
не используется.
 У роки опубликованы для
использования в будущем.
Технология
2. Операционное управление
• метафора потока
• проект? программа? процесс? кейс?
• DEMO
26

Операционный менеджмент (потоки)
Обеспечение бесперебойного потока объектов работы по
предписанным технологией рабочим станциям в ходе всего
жизненного цикла целевой системы/сервиса.
Организациякак чего-то «провод», максимизация «прохода»:
• Голдратт – течёт inventory, вытекает throughput
• Андреев – течёт сила по жиле
• Цепочки приращения стоимости
• Сетевая организация (не структура!)
• Системная динамика
• Кооперативные процессы СМД-методологии
• Бизнес-процессы и «информационные потоки»
• …
Три метода описания (viewpoints) для предпринятия
Работа с потоками:
• Работы – ориентированный на дела (process-based, activity-based).
Проекты, процессы.
• Технология – ориентированный на рабочие продукты (product-based).
Ведение дел, управление задачами, работа с практиками, управление
кейсами.
• Команда – коммуникационный, диалоговый (communications-based).
Полномочия и поручения, работа с деятелями.
• Отсутствует (проблема) внятный подход для: leadership (DEMO только
упоминает «выход в дискурс», Essence только упоминает
компетенции, но в целом дисциплина отсутствует)
28
http://www.cordys.com/ufc/file2/cordyscms_sites/download/731375d512f6789e8dd8a2775d26c123/pu/cor0027_modeling_rfi_white_paper_lr_v1.pdf

Акценты моделирования «потоков»
• Проектное управление (графики работ и задействования
ресурсов – когда кто что делает?)
• Теория массового обслуживания (потоки и очереди –
переварим всё за минимальное время!)
• Процессный подход в смысле BPMN (кто что должен
делать, но не когда)
• Адаптивное ведение дел / case management (agile:
достичь цели, но по какому маршруту, заранее
неведомо)
• Потоки пользы / value networks (бизнес, т.е. кому это
выгодно)
Смежные:
• Практики и жизненные циклы
• Трансакционные модели DEMO
29
Процессы, проекты, кейсы
• Премии платят за выполнение проектов, не за выполнение процессов.
• Сертификация качества даётся за выполнение процессов, не за выполнение
проектов.
Упражнение:
• На каком языке предпочтут говорить люди в организации?!
• Когда вам поручают новое дело, вы рисуете процесс или проект?
• Откуда вы берёте «детальки», из которых рисуете? Библиотеки справочных
данных в этой области? 30
Шаблон
проекта
Проект
Процесс Шаблон
Кейс
Экземпляр
процессаОдин раз
Много раз
Программа
???

Это всё разные view (наборы
моделей) одного объекта
моделирования – работ!
31
Нет «на самом деле», это всё
альфы, которые мы замечаем
везде – даже где их нет!
Нет «на самом деле»
проектов,процессов,кейсов!
Это всё разные акценты
моделированияодной и той
же реальности живой работы
(а хоть и будущей,у нас 4D).
Как сочетать управление проектами и
ведение дел / управление задачами?
• Объявлять проект «программой»! По факту это будет
кейс-менеджмент (только «крупными кусками»).
• Директивный график – проектное управление
(критическая цепь: буфер проекта).
• Альфы – это группы работ (по мотивам PRINCE2). Важно,
что альф будет 7, а не 2! С точностью до исполнителей
(обосновывается у Голдратта), а не «подробно».
Содержательное планирование лучше делать в issue
tracker.
• Изменения в проекте, неожиданности, оперативное
планирование – issue tracking.
32

Развитие практики проектного управления
33
Р
Е
З
У
Л
Ь
Т
А
Т
Ы
ВРЕМЯ
III поколение,
P2M, TOC
программы,
проект как commodity
II поколение,
PMBoK, PRINCE2
проект, процесс commodity
I поколение,
«сетевое планирование»
2000 201019901960
IV поколение
Проектное управление
• Когда есть нормы (можно планировать
продолжительности работ)
• Когда есть учёт ресурсов
• Когда заранее известна последовательность работ
(up front plan), в том числе состав системы
• Сегодня: не бывает без управления программой!
Но проекты внутри всё одно планируются up front и
подразумевают нормирование работ и учёт
ресурсов.
• Управлять проектом – это перекидывать ресурсы с
проекта на проект, то есть не бывает. Всегда в
масштабах предприятия!
34

Исполняемые описания деятельности
(слово «поток» не используется, но смысл в нём!)
• Регламенты
• Проект и шаблон проекта
• Процесс и экземпляр процесса – OMG BPMN 2.0
• Кейс и план – OMG CMMN
• Обрабока сложных событий и правила
деятельности – KRL (Kinetic Rule Language).
• …
35
Нотация BPMN 2.0
36

Особенности управления разработкой
Что хорошо для производства (manufacturing), то для
разработчиков смерть (и наоборот). Что хорошо для 10
человек, то плохо для 10000.
Нет универсальных ответов!!!
• Есть циклы, их число заранее неизвестно.
• Есть тупики, их число заранее неизвестно.
• Иногда требуется время на размышление – это не
физическая работа, его нельзя точно оценить.
• Собрать результаты размышлений вместе – это не собрать
конструкцию из деталей, время оценить нельзя.
• Определение системы легко изменить (по сравнению с
воплощением системы) – то есть легко как исправить, так
и внести ошибку.
• Невозможно применить известные способы оптимизации
проектов и процессов – например, очереди невидимы.37
Как бороться со сложностью?
Разделением труда/деятельностей!
• Более умные люди, оснащённые более сложными инструментами
• Специализация (больше людей, каждый из которых глубоко разбирается в своём
предмете)
• Пример: «фордовский конвейер» в бангалорской больнице Narayana Hrudayalaya
hospital
http://www.worldcrunch.com/culture-society/in-india-henry-ford-039-s-assembly-line-inspires-the-high-tech-hospital-of-the-future/c3s5573/#.UUrCIcrrNIH 38
Операциина открытом
сердце за $2,000, минимум
$20,000 в США и Европе

39
Объединение труда/деятельностей
(координация по Henry Minzberg)
1. Взаимная подгонка (как в джазе) – в самых
простых и самых сложных случаях (agile).
2. Прямой надзор (приказы из центра)
3. Стандартизация процессов работы
(формализация поведения)
4. Стандартизация результатов
5. Стандартизация навыков (общий тренинг)
6. Стандартизация убеждений и целей
(индоктринация).
Упражнение: отсортируйте по важности для вашей организации
Уход от засилья
«процессного подхода»
• Всё процессное автоматизируется и перестаёт
называться «процессом» (и даже «автоматизацией»:
суть работы меняется)
• «Процессом» называют всё что ни попадя, но кроме
названия там уже мало что остаётся от классической
пошаговости
(http://ailev.livejournal.com/1195297.html). Это только
кажется, что у людей в головах именно «процессы». В
головах у них «практики», BoK вместо «пошаговых
регламентов».
• Упор на рабочие продукты (case management, issue
tracking), облегчает договорённости – это отсылка к 4D
• Гранулярность (отдельные операции описываем, а их
цепочки не описываем) – ситуационная инженерия
методов, а не монолитные огромные «методологии».
• Декларативность (правила пред- и постусловий, а не
указание последовательности), OMG CMMN 40

Дело: issue, ticket, bug
41
вопрос задача уведомление
Табло: облегчение подгонки
• Менеджмент пассажиров
• Визуальный менеджмент vs. IT-систем (канбан:
рекомендуется «И»)
• Способ координации и стратегия: нужны на табло.
• Моделирование (невидимое становится видимым)
• Писцы-модельеры-аналитики против инженеров и
менеджеров: статус того, что на табло (тест: проверки
и приёмки)
Личное сознание = коллективное бессознательное
Табло = коллективное сознание
42
Упражнение: выпишите разные табло вашей организации.
Какие схемы из материала семинара вы бы повесили в
переговорных как плакаты?

Пример табло: поток работ
(Kanban board)
43
Пример: олимпийский комитет
• 5000 контрольных точек из проектов
(Олимпстрой)
• 5000 контрольных точек из сервисов
(процессов) – сама Олимпиада как
мероприятие
• 5000 контрольных точек из поручений
• Терминология: проектное управление (но пока
не управление программами)
• Софт: issue tracker «на коленке»
Пост «проекты нельзя процессы» -- http://ailev.livejournal.com/1176241.html44

Adaptive case management
Кейс -- ситуация, обстоятельства или начинание, которые
требуют набора действий для получения приемлемого
результата или достижения цели. Кейс фокусируется на
предмете, над которым производятся действия (например,
человек, судебное дело, страховой случай), и ведется
постепенно появляющимися обстоятельствами дела.
Case. A situation, set of circumstances or initiative that requires
a set of actions to achieve an acceptable outcome or objective.
A case focuses on a subject that is the focus of the actions such
as a person, a lawsuit or an insurance claim, and is driven by the
evolving circumstances of the subject.
Важно (для adaptive): программируются ли шаблоны
настройщиками софта, или самими работниками!
45http://ailev.livejournal.com/946134.html http://ailev.livejournal.com/1092118.html
Кейс: то, у чего есть свой какой-то
жизненный цикл, с чем работают практики
Dana Khoyi в главе 6 книжки Mastering the Unpredictable:
"For the employee onboarding process, our brainstorming session
resulted in the following list of business entities:
• Сandidates -- These cases represent the people who are under
consideration for positions.
• Managers -- These cases represent the positions to be filled.
• References -- These cases represent the references supplied by
candidates.
• Interviews -- These cases represent interviews that have occurred.
• Recruiters -- These cases represent the recruiters that supplied
candidate.
These business entities will be represented as cases in the ACM system".
46

47
DEMO
два мира: производства и координации
Актор
Мир
координации
(состояние)
Мир
продуктивности
(состояние)
координация
компетенцияполномочияответственность
производствоДеятельностная
роль
К-факты
К-акты
П-факты
П-акты
•Координация – это просьбы, обещания, предъявление выполненной работы, акцепт результатов,
отказы.
•Продуктивность порождает новые факты (в т.ч. нематериальные, например, факты новых решений)
•Факты – интерсубъектны (предъявление факта и его акцепт всегда происходят «между людьми»:
продуктивные факты не «объективны», даже если они относятся к материальным продуктам!)
http://www.demo.nl/ http://ailev.livejournal.com/644440.html
Дискурс: в мире координации его нет! Но в жизни он есть и крайне важен!
48
DEMO
Трансакция = координация + продукция
П-факт
желателен
П-факт
сдан
П-факт
принят
П-факт
запрошен
П-факт
обещан
1. запрос
4. приёмка
3. сдача
2. обещание
П-факт
произведен
Роль
инициатора
Роль
исполнителя

3. Лучшие практики «управлений»
(проектами, процессами, задачами)
• где "запасы", которые нужно минимизироватьв разработке?
• TOC, lean 2.0 и kanban
• Закон Конвея, лидерство
• с чего начнётеу себя?
49
Когда как управлять?
инвестзамысел проектирование сооружение эксплуатация
вывод из
эксплуата
ции
50
Операционный
Управлениекейсами
Управление
проектами
кейсами (incidents)
• управление процессами
(happy path)

51
Выборспособасоставления графикаработ
на базекакого подхода,какой модели?
Управление процессами
(очереди к станкам)
Управление проектами
(у одного человека
много проектов)
Критическая цепочка (TOC)
общий буфер времени для
группы операций
Задача: три работы
Использованы материалы
Eli Schragenheim и Daniel P.Walsh
Где «запасы» в разработке?!
• Производство: запасы/очереди видны
• Софт, разработка: запасы/очереди не видны
(винчестеры большие, на них всё поместится – и оно не видно!)
• Поэтому: lean 2.0, пост-Голдратт
• Упражнение: как искать waste, как искать «запасы»,
если они не видны?
52

Поток – это наше всё!
Источники идей для управления потоком.
• сomputer operating systems
• control engineering
• data communications networks
• finance and economics
• information theory
• maneuver warfare
• Manufacturing
• operations research
• probability and statistics
• queueing theory
По Donald Reinertsen
53
Методологии agile + lean + TOC
• XP (agile)
• SCRUM (agile)
• Open Kanban (lean, TPS +agile)
• TameFlow (agile+lean+TOC/CCPM)
• Operational Flow
• Financial Flow
• Informational Flow
• Psychological Flow
54
http://www.jrosspub.com/hyper-productive-knowledge-work-performance.html
Пример софта: http://www.a-dato.com/agile-scrum/

Канбан для разработки: холизм
(нетthinking processиз TOC,намеренно!Ибо это будетплан,а не эволюция!)
55
http://www.amazon.com/Kanban-David-J-Anderson-
ebook/dp/B0057H2M70/
ИНЖЕНЕРИЯ
1. Фокус на качестве
2. Уменьшить работы «в работе»
3. Поставка чаще
4. Балансировать спрос и проход
5. Приоретизировать
6. Бороться с источниками
изменчивости, чтобы улучшить
прогнозируемость
МЕНЕДЖМЕНТ
С чего начнёте у себя?
Дайте себе рекомендации:
• Использовать ли проектное
управление/управление программами?
• Использовать ли процессное управление?
• Использовать ли управление
задачами/делами/кейсами?
• С чего начать наводить порядок?
56

4. Учёт и контроль как фундамент
изменений
• Операционный учёт: управление конфигурацией целевой
системы (ALM, PLM, ERP, EAM)
• Управление конфигурацией обеспечивающей системы:
архитектура предприятия
57
С чего начать?!
• «Не быть лохом». «Не надеяться на авось/не быть лохом».
«Убрать бардак». «Не прощёлкивать» -- это всё «отсутствие
конфигурационных коллизий».
• Начинать нужно с управления конфигурацией.
• Продолжать с управления изменениями.
• Конфигурация и изменения целевой системы (версии,
запросы и поручения)
• Конфигурация и изменения обеспечивающей системы
(архитектура предпринятия, операционный учёт).
• Инструменты/софт!
• Производственная дисциплина!
• С себя – все дела записывать, все заметки хранить!
58

Параллельная инженерия
1. Коллаборативная инженерия
2. Параллельная инженерия
• Не путайте! http://ailev.livejournal.com/943532.html
• Возможно только за счёт IT
• Управление конфигурацией
• Управление изменениями
• Начинайте с управления конфигурацией, управления
изменениями («инженерный менеджмент»,
бюрократия)
• Потом уже операционный менеджмент (ускорение
работ)
59
Главные понятия управления конфигурацией
• Конфигурация (configuration)
• Конфигурационная единица (configuration item) –
определяется логистически как единица передачи, а не
инженерно!
• Версия (version)
• Базис (baseline)
• Не «управление версиями», ибо кроме версий там
много чего входит (управление данными, выпуск
рабочих продуктов и т.д.)
• «Управление изменениями» часто включают в состав
управления конфигурацией, но чаще добавляют
отдельно (другая дисциплина)
• Иногда синонимично «управлению жизненным циклом»
и PLM, иногда синонимично «управлению инженерной
документацией»
60

Подпрактики управления конфигурацией и
изменениями (и там внутри «управления» разными
альфами – например, управления требованиями):
• практика выпуска (release) инженерных артефактов
(например, выпуск чертежей), в том числе по
жизненному циклу
• практика выпуска самых разных видов заказных
спецификаций (BOM, bill of materials)
• практика запросов на изменения
• практика изменения проекта
• практика управления данными (включая
подпрактики выдачу имён объектов/кодирования,
регистрации, нормативно-справочной информации
aka знаний и т.д.)
61
Управление конфигурацией и изменениями
задействовано во всех других практиках!
Пример: Практики ЖЦ требований (по ISO 15288:2015)
• 6.4.2 Stakeholder needs and requirements definition process
• Подготовиться(идентифицироватьстейкхолдеров,определить стратегию
определения потребностейстейкхолдерови требований,получить или купить
обеспечивающуюсистему и сервисы)
• Определить потребности стейкхолдеров (определить контекст использования,
идентифицироватьпотребности стейкхолдеров, приоритизировать и отобрать
потребности,определить потребностистейкхолдеров и их обоснование)
• Разработать Концепцию функционирования (operationalconcept) и другие
концепциижизненного цикла (определитьнабор сценариев,определить
взаимодействия пользователей и системы)
• Преобразовать потребности стейхколдеров в требования стейкхолдеров
(идентифицировать ограничения на инженерные решения,идентифицировать
требования стейкхолдерови все функции для требований качества,
гармонизировать требования стейкхолдеров)
• Анализироватьтребования стейкхолдеров (анализироватьполное множество
требований стейкхолдеров,определить критическиепоказатели
результативности,которые позволят оценить техническиедостижения,
получить обратную связь от стейкхолдеров – валидировать,устранить все
проблемы и противоречиясо стейкхолдерами)
• Управлятьопределением потребностей стейкхолдеров и требованиями
(получить явное согласие на требования стейкхолдеров,поддерживать
трассировку потребностейи требований,обеспечивать сведения по базисам)
62

Как организовать управление
конфигурацией в машиностроении
• Коротенькая (188 страниц)
• Управление жизненным
циклом, управление
инженерной документацией,
управление конфигурацией –
это всё одно.
• Служба подчиняется
инженерам, а не менеджерам!
• Не учитывает стандартов
системной инженерии (ISO
81346), совсем уж
современных решений
(«облачные» BOM), но зато
представлена бездна опыта
для «традиционных
производств».
63
https://www.amazon.com/Configuration-Management-Senior-Managers-Manufacturing/dp/B019NDYT9C/
Учёт в инженерии
• Управление конфигурацией и изменениями
• Управление конфигурацией:
• Распределено в программной инженерии (Git, GitHub)
• Ушли в облака в PLM и ALM
• Но не распределены в PLM и ALM
• Управление изменениями
• Issue trackers уже ушли в облака (стали нейтральными)
• Не распределены в PLM и ALM
• Пока не связаны с финтехом (например, биллинг)
64

Операционный учёт
• Архитектура (важная часть design)– это самые общие
решения
• Проект (design) – это типы
• Нужен учёт индивидов! Нужен операционный учёт
= управление конфигурацией и изменениями
• Учётные системы – это технология для практики
управления конфигурацией!
• Базы данных – «это наше всё», они и есть модель
предприятия! Отчёты – это выписки из учётных
систем.
• Статус учётных систем, регистры.
65
Информационныесистемыдляуправленияконфигурациейи изменениями
в жизненномциклезадвижки
66
Ситуация
Объект
Спецификация
функции (СФ)
Спецификация
компонента
(СК)Спецификация
продукта (СП)
Индивидуальный
журнал (ИЛ)
Физический
образец
Объект
«задвижка» «Задвижка» в обычном
языке
Реальный,
функционирующий
Запланированный,
историческая
запись, и т.п.
PLM
ERP
EAM
Разные цвета – разные «задвижки»:
• комплектующее (PLM),
• предмет снабжения (ERP),
• установленное оборудование («актив» в EAM).
Информационныхсистем больше, чем
только PLM, ERP, EAM. Ручной переввод
информации в среднем 7 раз в ходе
проекта!!! Это:
• медленно,
• вносятся ошибки,
• очень дорого (работа людей).
Чьи данные? Кто ответственен за оригинал?
Новый класс систем: регистрационные

Эко-система жизненного цикла:
«инжиниринговые киборги»
67
люди
программы
оборудование
люди
программы
оборудование
Многоуровневое
взаимодействие
• Данные
• Действия
• Энергия
• Масса
Множественность PLM/ALM/ERP/EAM:
управление конфигурацией и изменениями
в расширенном предпринятии
МОДЕЛЬ ИНЖИНИРИНГА
(ПРЕДПРИЯТИЯ)
управление изменениями
МОДЕЛИ СИСТЕМЫ И
ЕЁ ОКРУЖЕНИЯ
конфигурацией
Действия
МОДЕЛЬ ИНЖИНИРИНГА
(ПРЕДПРИЯТИЯ)
управление изменениями
МОДЕЛИ СИСТЕМЫ И ЕЁ
ОКРУЖЕНИЯ
конфигурацией
Действия
Мультимодельное
взаимодействие
• Данные
• Действия
требования архитектура рабочка
как
сделано
требования архитектура рабочка
как
сделано
базисы базисы
68
Systems Framework
http://ailev.livejournal.com/1277009.html

69
Нет сверхчеловека, есть сверхорганизации
По факту -- киборги (cybernetic organisms – роль IT,
начиная с business process re-engineering) уже
заполонили всю планету, но они оказались не
«людьми», а организациями:
• Сверхмасштабы (счет на миллионы единиц
продукции, миллионы обслуженных людей, а иногда
уже и миллиарды)
• Сверхскорость (18 месяцев – время жизни
полупроводниковой технологической линии, затем
опять перестройка)
• Сверхресурсы (бюджеты ТНК сравнимы с бюджетами
государств, и не размазываются по многим темам)
Держатся за счёт IT-систем и телекоммуникаций!
Упразднение роли менеджера как диспетчера работ.
Киборги-2, мультиагентные системы
• Агент – сущность, способная к действию (https://en.wikipedia.org/wiki/Agency_(philosophy))
• Пока разделение «человек или компьютер» важно:
• Мультиагентские системы
• Экономика, социология, правоведение психология, и т.д.
• Завтра эти дисциплины начнут смешиваться
• Киборг-1 = кибернетический организм
• Киборг-2 = кибернетическая организация
• Киборгизируются и
• отдельные люди (экзокортекс и персональные агенты), и
• Команды, коллективы (корпоративные информационные системы как агенты), и
• общество в целом (агенты социальных сетей).
• Команда, коллектив, общество = мультиагентная система из людей и достаточно умных компьютеров
• Инженерия предприятиябез учёта его информационных систем:
целостность деятельности людей обеспечивается компьютером
(управление конфигурацией и изменениями).
• Управление проектами, процессами, задачами без информационных
систем невозможно: конфигурация и изменения работ и задач
должны быть в базе данных, а не в головах!
• В простейших случаях – вместо компьютера выступают стены
(визуальный менеджмент). 70

Операционный софт
• Каждый софт поддерживает дисциплину: прихват софта –
это прихват дисциплины
• Проще переделать организацию под софт и его
подразумеваемые, чем софт под организацию! Это и есть
best practice!
• Без перестройки деятельности смысла использовать софт
(т.е. автоматизировать что-то) нет. И тем самым
«автоматизации» не бывает.
• Обзоры делать бесполезно (каждые полгода смена
лидера + важна отраслевая специфика)
• Тенденция конвергенции разных типов операционного
софта
• Связка с модели проекта с моделью продукта важна
• Уход в облака и мобильность.
• Ботовые интерфейсы (аватаризация)
• Стикеры на стене – это тоже такой софт (визуальный
менеджмент)
71
Пример управления структурированными
данными Behtel
BSAP
5
b1
D
RES
T
BSAP
523 234 0f 3043
RES
T
BSAP
RES
T
BSAP
5
b1
D
RES
T
App
RES
T
App
RES
T
APIs
Ccc4;d0dfff8d
5209h934000
Mobile BrowserWidgets
Standardized
Representation
Bechtel Mobile
Data
Exchange
Data Query
Diverse
Information
(For printed copy)
72
Partners

Распределённый реестр
(и там внутри блокчейн)
73
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/492972/gs-16-1-distributed-ledger-technology.pdf
Безлюдные организации и их проблемы
• Блокчейн и DAO
• Если банкомат недодал $50, то нужно разобраться не с банкоматом,
а с его хозяином. Если хозяина-человека нет, то беда!
• Автоматизированная на 100% система – беда, в ней не с кем
договариваться! (нельзя выйти в дискурс!)
• Проблемы агент-принципал: если слуга шалит, то где найти хозяина?
Если хозяин скрывается, то с кем разбираться? Если суда нет, то кто
поможет?
• Кризис переналадки при сбоях:
• События в аэропорту -- https://qz.com/881454/automation-is-already-
here-and-its-taking-jobs-and-annoying-customers/
• Проблемы есть ВСЕГДА, и они ВСЕГДА ВДРУГ.
• Если автоматизации ВДРУГ нет, то очередь вручную не обработать
• Если автоматизации ВДРУГ нет, то персонал не знает, как вести
обработку вручную
• Если автоматизации ВДРУГ нет, то возникает бардак (потеря
конфигурации, требуются нестандартные решения. Требования
capacity по учёту на фондовых рынках). Не так важен сам кризис,
как разгребание его последствий потом.
• Если автоматизации ВДРУГ нет, кто оплачивает потерю вложенного и
застрявшего в системе ресурса? Время – деньги! 74

Смарт-контракты
• Программы, исполняющиеся в доверенной среде
(инфраструктура доверия – повсеместная
доступность).
• Особенности: упор на идентификацию входов и
выходов, гарантию запуска на исполнение
• За доверенную среду нужно платить. Платы нет –
контракт прекращает выполняться (например, при
зацикливании программы).
• Особо оговаривается связь реального мира и
программ (оракулы).
75
Кризис переналадки
• События в аэропорту --
https://qz.com/881454/automation-is-already-here-and-its-
taking-jobs-and-annoying-customers/
• Проблемы есть ВСЕГДА, и они ВСЕГДА ВДРУГ.
• Если автоматизации ВДРУГ нет, то накапливается
очередь: вручную невозможно её обработать
• Если автоматизации ВДРУГ нет, то возникает бардак
(потеря конфигурации, требуются нестандартные
решения. Требования capacity по учёту на фондовых
рынках). Не так важен кризис, как разгребание его
последствий потом.
• Если автоматизации ВДРУГ нет, то персонал не знает, как
вести обработку вручную
• Если автоматизации ВДРУГ нет, кто оплачивает потерю
вложенного и застрявшего в системе ресурса? Время –
деньги!
• Автоматизированная на 100% система – беда, в ней не с
кем договариваться!
76

Современная работа с каталогами и информацией: по
виду, а не по атрибутам!!!
(в промышленности такое тоже вполне возможно)
• Понимает,чтонужно (можетпоглядетьнапринесённыйпокупателемобразец)
• Покажетварианты(доступк каталогу)
• Отведётктоваруна полке
• В среднемобслуживает5-10 человеквчас
• Уже работает(смотретьвOrchardSupplyHardware,locatedat377 Royal Avenue,SanJose, CA)
OSHBot -- http://fellowrobots.com/https://www.cortexica.com/
Торговцамможно вставлять
видеопоискв свои приложения.
Промышленникам,думаю, тоже. 77
Архитектура предпринятия
Учёт практик, планирование развития
78
деятельность
программы
«железо IT»
«физические объекты»
Бизнес
(стратегирование,целеполагание, развитие)
ArchiMate 3.0

4. Развитие и совершенствование
Программа
0. Что вы успели использовать в ваших проектах?
1. Развитие: научиться делать что-то новое/по-новому
• Развитие: постановка практик
• Гранулярность и модульность как ключ к развитию
• Совместимость практик
2. Практики: моды и поветрия
• Моды и поветрия (примеры)
• Тренд в развитии практик: автоматизация, вплоть до полной
3. Развитие: постановка практик
4. Циклы развития и совершенствования
• Постановка практик
• Цикл Бойда (сражения с конкурентами)
• Цикл Дёминга (управление качеством)
• POOGI (process of on-going improvement, ускорения хода
работ)
• Цикл lean startup 80

0. Что вы успели использовать
в ваших проектах?
Прошла половина курса (три дня из шести).
• Сколько часов в день вы в среднем тратите на
курс за две недели между днями тренинга?
• Прочли ли учебник?
• Что вы успели использовать из курса в ваших
проектах, в вашей жизни?
• Что получилось, что не получилось?
81
1. Развитие: научиться делать что-
то новое/по-новому
82

Системный менеджмент и стратегирование

Системный менеджмент и стратегирование

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Системный менеджмент и стратегирование

Similar to Системный менеджмент и стратегирование (20)

More from Prapion Gaybaryan

More from Prapion Gaybaryan (6)

Системный менеджмент и стратегирование