Пост по заданию из курса "Системный менеджмент" с описанием деления практик менеджмента и их ролей в терминах моей организации.
Когда обдумывал задание, появилась мысль оформить все в виде таблицы. Да вот только оказалось, что она плохо поддерживает многоуровневые списки (или я не нашел способа). Чтобы имитировать разные уровни, пришлось играться с начертаниями шрифта. Больше так оформлять не буду.
Табличное представление ниже. Пришлось основательно поломать голову, вспоминая лексикон обсуждения практик менеджмента в моей организации. Есть ощущение, что часть практик упоминается в компании в явном виде примерно никогда. Что, конечно, совсем не означает, что их нет, речь об уровне зрелости/maturity процессов. Не называем -> не выделяем вниманием -> не развиваем осознанно.
Мой уровень оцениваю по десятибалльной шкале, 0 — «абсолютно не владеет практикой, ничего не умеет», 10 — «владеет практикой лучше всех в мире, умеет делать в этой практике всё с неизменно превосходным результатом».
Практика менеджмента (метаУ) | Роль (метаУ) | Практика менеджмента (метаС) | Роль (метаС) | Комментарий | Мой уровень |
---|---|---|---|---|---|
Инженерия целевой системы | Инженер целевой системы | Инженерия | Инженер | Терминология в контексте: "инженер, проект, система" | 6 |
Визионерство целевой системы | Визионер | Контроль исполнения проекта | Куратор | Относительно недавно выделенная, описанная роль | 8 |
Архитектурная деятельность для целевой системы | Архитектор | Системная инженерия | Системный инженер | Иногда - скопиованный у заказчиков "ГИП" | 7 |
Разработка | Разработчик | Разработка | Разработчик | Часто - инженер | 5 |
Проектирование | Проектировщик | Проектирование | Проектировщик | Часто - инженер, инженер-проектировщик | 6 |
Изготовление/производство | Инженер-технолог | Изготовление | Изготовитель | Аутсорс | 0 |
Эксплуатация | Оператор целевой системы | Эксплуатация | Оператор | Чаще всего роль у внешнего заказчика | 6 |
Инженерия платформы разработки | Инженер платформы разработки | Системное администрирование, Документ-контроль | Системный администратор, Менеджер документ-контроля | Т.к. часто результат нашей работы - проектная доментация, то документ контролер - это наш DevOps | 6 |
Менеджмент | Менеджер | Руководство | Руководитель | Только по контексту | 7 |
Стратегирование | Бизнесмен | Стратегическое управление | Руководитель | Только по контексту | 6 |
Орг-архитектурная деятельность | Орг-архитектор | Проектирование оргструктуры | Проектировщик оргструктуры | Раритетный термин, не каждый год можно услышать | 7 |
Организовывание | Организитор | Организовывание | Организатор | Редкий термин | 8 |
Организационное развитие | Менеджер по оргразвитию | Функциональный менеджмент | Функциональный менеджер | Классическая матричная структура | 8 |
Оргпроектирование | Оргпроектировщик | Развитие оргзвена | Менеджер по развитию | Редкий для организации термин | 8 |
Лидерство | Лидер | Лидерство | Лидер | Часто употребляется, но с размытым контекстом | 8 |
Операционный менеджмент | Операционный менеджер | Менеджмент проекта | Менеджер проекта | Классическая матричная структура | 8 |
Администрирование | Администратор | Управление персоналом (как пример) | Менеджер по персоналу | Адм. практики выполняют многие роли | 6 |
Продвижение продукта или услуги | Продвиженец | Аккаунт-менеджмент | Аккаунт-менеджер | Работаем на B2B рынке | 6 |
Привлечение инвестиций | Фандрайзер | Привлечение инвестиций | Основатель компании | Компания - не акционерное общество | 1 |
Сама по себе таблица - больше про анализ. Чтобы не быть летописцем, опишу предложения, приоритетные кейсы в по улучшению работы организации; сделаю это на основе своего опыта и глядя на таблицу. Сам при этом нахожусь в роли орг-архитектора.
Кратко: приоритетными шагами видятся явное обозначение роли орг-архитектора, с задачей развертывания практик DevOps/инженерии платформы. Причем действие в таком паттерне применяется дважды - для инженерии целевой системы и для инженерии системы создания.
Подробнее:
- Инженерия целевой системы.
- Выделить роль архитектора, разрабатывающего концепцию системы. Создать чек-листы для контроля важных архитектурных характеристик. Примером для старта можно взять модель стандарта ISO 25010. Учитывать и документировать (ADR формат) про развилки/tradeoffs.
- В инженерии систем создания переход на DevOps практики для организации будет означать модернизацию системы документ контроля, переход на систему управления конфигурацией/CM. Добавлять отсутствующие сейчас метрики, бенчмаркинг. В таком случае появится возможности для аудита и постоянного улучшения системы. Первый шаг в улучшении: измерить качество, скорость и количество работ в в процессах - релизы, BoMы, запросы и изменения.
- Инженерии организации как системы создания.
- Выделить роль организационного архитектора. Декларировать стратегической моделью организации работ - поток. Запустить пропитку, убеждение сотрудников. Еще одна ментальная модель - компания как продукт, которым должно быть удобно пользоваться. Продумать фитнес функции, контролирующие архитектуру, настроить медленные переменные для сбора данных. Заход на управленческий учет в дальней перспективе.
- Инженерия целевой системы. Обязательно - совмещение с ролью операционного менеджера. Описание ролей. Выстраивание команд, производственных и платформенной/CM. Итеративная калькуляция SLA для контрактов/интерфейсов взаимодействия с платформенной/CM командой. Сбор информации для поиска процессов к автоматизации.
Mike Rother в книге "Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results" (2009) писал, что сообщество Lean при копировании японской системы менеджмента пропустило самую важную практику - кату совершенствования. Эта ката требует создания структуры для ежедневных и привычных практик улучшения. Первый черновик каты совершенствования моей организации написался в этом посте.