Собираем всё вместе

Вспомним таблицу, приведённую в начале раздела:

Ме****нтальный мир	Физический мир
(M4**)** Язык записи и неявно выбранные способы описания/неявные предположения: предположения о том, что BORO более для моделирования работ по методу, чем другие системы типов, …
(M3**)** Система типов: система типов BORO
(M2**)** Фундаментальная онтология: онтология путешествий объектов, онтология потоков
(M1**)** Мета-У-модель/прикладная онтология: онтология работ
(M1**)** Мета-С-модель/модель данных/рабочая онтология/шаблон описания: онтология работ TameFlow, заземлённая для конкретного предприятия
(M0) Экземпляры модели/модели конкретных объектов, операционная модель: описание работы №324 в отчёте	Объекты физического мира**😗* конкретные исполнители, конкретные акты выполнения работ и так далее

– и попробуем пройтись по ней ещё раз.

Допустим, у нас есть контентная команда, которая создаёт статьи по реальным ситуациям. Можно сказать, что она выпускает ситуации, упакованные в материал, или кейсы/case.

Мы выбрали BORO в качестве системы типов, поэтому можем говорить о том, что у нас есть объект типа «часть предприятия» или даже точнее «создатель». В учебниках, содержащих прикладные онтологии (мета-У-модели), создателей будут называть серверами, рабочими станциями, линиями/потоками/маршрутами. Мы договорились называть создателей в онтологии работ либо рабочими станциями (когда интересует выдача предметов работ наружу), либо производственными линиями (когда интересует, как именно создаётся выдаваемый наружу предмет работ).

Как уже договорились, сейчас за пределами рассмотрения находится вопрос «нужно ли нам вообще писать статьи, чтобы повысить мастерство наших клиентов, или мы должны делать что-то другое?». Решение полностью сменить метод создателя относится к стратегическим решениям создателя; а мы при моделировании работ неявно предполагаем, что стратегические решения находятся вне фокуса нашего внимания, выбранный в данный момент угол зрения/точка зрения/viewpoint не позволяет обсуждать такие вопросы. Мы принимаем как данность то, что команде нужно писать статьи по ситуациям (выпускать кейсы). При этом в ходе выполнения работ мы можем обнаружить, что на самом деле нам нужно провести конференцию. Но такое решение мы будем рассматривать уже не как операционные менеджеры, поэтому на данный момент оно опускается.

С точки зрения принципиальной модели компания как крупнейший создатель в фокусе внимания выпускает мастерство клиентов; контентная команда вносит свой вклад, реализуя кейсы (кортежи <ситуация, материал по ситуации>). Мы можем выбрать «кейс» (может быть удобнее) или «статью по ситуации» в качестве объекта, выпускаемого создателем «команда».

Далее вам, если вы руководите контентной командой, могут потребоваться 5 моделей создателей для управления работами:

1. Принципиальная модель предприятия как крупнейшего создателя – считаем, что уже есть в наличии, удерживаем на ней внимание;
2. Модель команды как производственной линии. Благодаря этой модели можно будет увидеть, как именно создаётся результат/предмет работ, выдаваемый наружу (объект типа «статья»);
3. Модель команды как рабочей станции, являющейся частью рабочей станции «группа команд» или «подразделение» (те создатель мельче, чем «компания», но крупнее, чем «команда», промежуточный уровень). Например, модель команды как одной из контентных команд, которые должны выпускать согласованные непротиворечивые кейсы для клиентов (и как-то перераспределять загрузку). Нам нужно видеть не только нашу команду, но и общую модель работы контентных команд. Команда в данном случае будет рассматриваться как одна из рабочих станций, который выполняет работы по одному методу над одним объектом;
4. Модель группы сотрудников, работающих по одному методу над одним объектом (рабочей станции, состоящей из группы серверов). С точки зрения команды они все вместе будут создателем – «рабочей станцией», которая выпускает одни и те же объекты одним методом или классом методов. Это рассмотрение важно для перераспределения загрузки. Например, у нас есть 2 корректора, и мы можем перераспределять задания между ними по-разному: одному отдать на проверку 3 кейса, которые требуют больше времени на обработку, а второму – 5 кейсов, каждый из которых будет выпущен быстрее. В итоге оба будут работать с примерно одной скоростью;
5. Модель сотрудника как рабочей станции. На этого создателя с точки зрения команды мы будем смотреть как на «рабочую станцию»; однако в случае если руководителю надо будет выступить методологом и обсудить метод, которым сотрудник даёт результат, то можем рассматривать сотрудника как «производственную линию». Допустим, эксперту, чтобы написать статью, надо сначала поработать «исследователем» и изучить материал, затем «автором», чтобы составить структуру материала, описать его и привести примеры, а затем «корректором», чтобы провести проверку материала до отдачи (уменьшить число переделок в следующих рабочих станциях). Поэтому де-факто у сотрудника свой микроконвейер, состоящий из рабочих станций – темпоральной части сотрудника в роли «исследователя», затем «автора», затем «корректора».

Раскроем подробнее эти пункты.

Понимание принципиальной модели предприятия нужно, чтобы вы могли сказать, какой вклад команда вносит в работу предприятия. Если руководитель команды не может этого объяснить, то команда либо не разобралась, что от неё требуется, либо она не очень-то нужна. На этом подробно останавливались в подразделе «Принципиальная модель предприятия». Контентная команда в нашем случае помогает доносить до клиентов, как разбираться с конкретными проблемами в определённых ситуациях, при помощи материалов статей – растит мастерство клиентов. Соответственно, статьи должны помогать сделать реальное действие, например, правильно сдать бухгалтерскую отчётность, в спорной ситуации.

Модель команды как создателя, выпускающего кейсы, будет основной для руководителя команды и его подчинённых (обратите внимание, что руководитель и подчинённый – это не роли, а обозначение места в иерархии подчинения). Нужно понимать, как именно команда создаёт результат, каков выпуск команды, чтобы можно было обсуждать, как воздействовать на команду, чтобы ускорить выпуск. В вашей рабочей онтологии должны быть понятия, при помощи которых вы опишете модель работы команды. В случае контентной команды это выглядит так: у вас есть создатели – эксперты, редакторы, корректоры, публикаторы – которые выступают как совместно работающие «рабочие станции», обеспечивающие выпуск статей. Всё это – ваша команда. Здесь может быть нюанс: с точки зрения организационной структуры и иерархии подчинения часть из реальных сотрудников («серверов» или рабочих станций), входящих в производственную линию, или целая станция могут находиться вне вашего прямого контроля. Например, под прямым контролем находятся сотрудники, которые пишут итоговые версии статей, но не те, которые публикуют их на сайте. Но если мы моделируем работу команды, мы должны проигнорировать это и включить в состав команды публикаторов тоже, поскольку без них выпуск статьи для клиентов не состоится. С нюансами иерархии подчинения можно разобраться позже и отдельно. Точно так же в состав команды уместно включать внешних подрядчиков в качестве рабочей станции, если они де-факто участвуют в создании результата: например, в судебном кейсе «банкротства» юридическая компания может считать арбитражных управляющих (внешних подрядчиков) частью команды, которая обеспечивает утилизацию обязательств в сделке между физическим лицом и банком. Это поможет сделать целостный граф создания, привязанный к результатам для клиентов, увидеть реальное ограничение команды как производственной линии, а также увидеть «серые» места производственной линии, за которые никто толком не отвечает, но которые важны для результата. Например, контентной команде важно, чтобы материал был опубликован вовремя, так что со стороны этой команды должен быть присмотр за тем, чтобы публикации происходили. Иначе получится ситуация как в миниатюре Райкина «кто сшил костюм». Все по отдельности работали, и может, даже неплохо, только костюма на выходе нет, есть нечто несуразное, что носить нельзя, и никто не несёт за это ответственность.

Эксперты пишут статьи по конкретным ситуациям, отдают их редакторам, которые вносят содержательные правки в текст. Затем статьи отдаются корректорам, которые проверяют текст на грамотность, правят опечатки, расставляют запятые. Наконец, согласованные статьи уходят публикаторам, которые размещают их на сайте. Такова общая модель путешествия статей через контентную команду как создателя/часть конвейера предприятия. Вместо статей мы можем выбрать объект «кейс», общая схема описания будет такой же.

Теперь мы можем назвать экспертов, редакторов, корректоров и публикаторов «рабочими станциями» и рассчитать, сколько именно статей или кейсов находится сейчас в работе/не выпущены/являются незавершёнкой (WIP):

• У команды в целом: это все статьи, которых коснулись эксперты (те начали писать, взяли в работу – произошло некоторое событие «начала работы», о котором договорились в команде), но ещё не выпустили публикаторы;
• Для каждой рабочей станции по отдельности: все статьи, которых коснулись сервера конкретной станции, но ещё не передали дальше (например, все статьи, над которыми начали работу редакторы, но которые ещё не передали корректорам). Здесь вы встретитесь с ситуацией, когда рабочая станция, например, редактор, отдала объект (статью) дальше, но нужны переделки/rework. Можно оценивать эту ситуацию по-разному: например, можно считать, что «дата завершения» работы редактора – это дата и время, когда статья уже не может вернуться на переделку; до этого она будет числиться для редактора «незавершёнкой». Можем принять решение, что статью для редактора считаем «выпущенной», когда она в первый раз передана дальше, и просто закладываем время на возможные переделки.

Далее для команды в целом мы можем подсчитать, сколько статей она выпускает за период (выпуск/Throughput) и сколько у неё в этот период незавершёнки, а затем по закону Литтла рассчитать среднее время выпуска статьи. В случае если у вас статьи разных классов, например, есть сложные/уникальные, а есть лёгкие/типовые, то можно проделать расчёты отдельно для каждого класса.

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

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

Чтобы создать модель команды, как видите, придётся пойти на уровень ниже и рассмотреть «группу сотрудников» как создателя/рабочую станцию и сотрудника как создателя/сервер. Это потребуется, чтобы рассчитать, как реально работают станции. Однако выше предлагалось смотреть ещё и на модель команды как создателя, являющегося частью создателя «группа команд» или «подразделение». Это нужно для того, чтобы понимать, как команда вносит вклад не только в работу предприятия как создателя несколькими уровнями выше, но и в работу создателя одним уровнем выше. Допустим, у нас несколько контентных команд, и они иногда могут выпускать статьи об одних и тех же ситуациях, причём выражать в этих статьях разное мнение по поводу способов разрешения ситуаций. Как быть в таком случае? Надо рассмотреть модель, в которой ваша контентная команда – лишь одна из команд («сервер»), которые совместно должны обеспечить результат, и думать о совместном выпуске группы контентных команд. Чтобы вы могли совместно выпускать качественные материалы по разным ситуациям и не противоречить друг другу, надо договориться о способах распределения работ по соответствующим кейсам. Возможно, вы договоритесь, что какие-то классы кейсов уходят одной команде, поскольку в ней сосредоточены наиболее опытные в теме кейса эксперты. Возможно, вы договоритесь о совместном написании статей и выработаете совместный подход к тому, чтобы справиться с определёнными классами кейсов. Какой именно способ разрешения конфликтов между командами вы выберете, не так важно; важно, что команды работают вместе, а не по отдельности, и не играют в перетягивание каната. С точки зрения топ-менеджмента это обеспечивается постановкой общих целей этим контентным командам – тогда они будут стараться оптимизировать общий результат.

Также руководителю может потребоваться вмешаться и повлиять на работу сотрудника. В таком случае ему нужно понимать модель работы сотрудника. В частности, ему нужно уметь посмотреть на сотрудника и как на сервер, то есть, часть команды, и как на создателя со своими методами работы. У отдельного сотрудника тоже можно обнаружить свой микроконвейер. Например, эксперту нужно написать статью. Поэтому сам сотрудник должен исполнить ряд ролей: сначала поработать «исследователем» и изучить материал, затем «автором», чтобы составить структуру материала, описать его и привести примеры, а затем «корректором», чтобы провести проверку материала до отдачи (уменьшить число переделок в следующих рабочих станциях). То есть, самому сотруднику надо в разных ролях выполнить работы по разным методам, чтобы получить на выходе нужный результат. Сотрудник может испытывать проблемы с исполнением какой-то из этих ролей; чтобы иметь возможность найти проблему и продумать решение, руководитель должен уметь составить модель работы сотрудника и при необходимости удерживать её во внимании.

Как видите, даже линейному сотруднику требуется иметь несколько моделей своей работы: модель себя как части команды/создателя более высокого уровня (для понимания вклада в команду), а также модель себя как создателя (микроконвейер со множеством ролей). В целом, этих моделей линейному сотруднику достаточно. А вот руководителю приходится удерживать внимание на куда более многоуровневом моделировании: он должен уметь отмоделировать работу отдельно взятого сотрудника, посмотрев на него как на часть команды и как на микроконвейер, ещё рассматривать группу сотрудников, применяющих одни и те же методы, ведь между ними надо будет перераспределять работу, а ещё – смотреть на команду как на линию/конвейер и как на часть группы команд. И уже начинать думать о том, как команда вносит вклад в работу предприятия. То есть, при повышении должности резко растёт потребность в сложном многоуровневом моделировании – и в удержании внимания на всех этих моделях, потому что руководителю в разных ролях придётся регулярно переходить по уровням и рассматривать ситуации исходя из моделей нужного уровня.

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

Для дальнейшего заземления менеджер контентной команды может составить таблички с перечислением рабочих станций команды, исполнителей в каждой рабочей станции, реальным количеством статей, и так далее. В ячейках таблицы будут указаны экземпляры модели M0, например, рабочая станция «корректоры», исполнитель/сервер Смирнова С.Ю. Для представления команды как производственной линии можно нарисовать схему.

То же самое можно делать, если у вас в фокусе группа команд, совместно выпускающая объекты. Например, группы команд, которые совместно организуют и проводят мероприятия. Совместным выпуском будут «проведенные мероприятия» (в штуках), но каждая команда может заниматься своей частью работ по методу: одна команда договаривается о темах и спикерах, вторая ищет подходящее место, договаривается об оплате, обеспечивает необходимые инструменты (например, проектор) и другие штуки (например, воду) на мероприятии, и так далее. В таком случае уместно сначала отмоделировать путешествие мероприятия по группе команд как мини-конвейеру/производственной линии (как показано на картинке ниже). А потом уже определять вклад вашей команды и создавать модель команды.