#ОперационныйМенеджмент #ГИП #УправлениеПроектами #ЦифроваяТрансформация

А запутаться тут легко.

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

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

Почему это важно: если мы сразу вешаем на объект или отдел ярлык-роль, то легко ошибиться. А если сначала смотрим на поведение - что этот объект или человек делает в окружении, на какие системы вокруг влияет, - то название роли появляется само, из сути дела, а не из штатного расписания.

Итого, рабочая цепочка мышления:

1. Целевая система (или система создателей в широком смысле - обязательно с прослеживанием причинно-следственных связей до целевой). Здесь мы вниманием выделяем объект или сервис, который является предметом инженерии - тем, что должно появиться в результате работы команды. Систему определяем через то, какое поведение она будет оказывать на окружение в период использования.

2. Методы (иногда говорят “процесс” или “функция”). Смотрим на поведение рассматриваемого объекта или человека - какое действие в пространстве-времени приводит к желаемому состоянию целевой системы из п.1: для технической системы это поведение называем функцией; для людей и команд - методом, тем, что они умеют делать руками, головой, или уже связкой человек+ИИ.

3. Роль. Когда разобрались, какая функция или метод - главная по отношению к системам в окружении (а их может быть несколько), можно называть роль.

4. Конструктив. Тот, кто или что фактически исполняет роль - человек, отдел, механизм.

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

Как это применить в реальной работе предприятия? Классическая ситуация: перед отделом стоит задача “кто нам нужен, чтобы решить инженерную или организационную задачу”. По сути вопрос звучит как “какой конструктив подойдёт”. И самая плохая стратегия - сразу назвать конкретный отдел или должность как решение, не разобравшись, что именно нужно делать.

Если перейти на язык методов (в компаниях чаще говорят “процессы”), может выясниться неожиданное: отдел выполняет совсем не ту роль, под которую его когда-то создавали.

Пример из практики: отдел, который по идее должен заниматься разработкой наружных инженерных сетей линейного объекта транспортной инфраструктуры, на деле выполняет запрос и сбор коммерческих предложений, заключение договоров, переговоры с подрядчиками, проведение торгов, сравнительный анализ и бюджетирование при выборе поставщиков… и далее по списку. Сколько ролей мы уже насчитали?

И тут я как комплексный ГИП такой: “где мой сводник с…и?!” ))) Самому смешно - потому что запрос на “нужного человека” на самом деле оказывается запросом на пересборку зоны ответственности.

Берём на заметку рабочую цепочку: Методы/процессы -> Роли -> Оргзвенья

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