Трудности цифровой трансформации реального сектора
1. Текучка/срочное против важного.
Топ менеджеры считают, что они заняты важным, но на самом деле -- срочным. Основная задача топ-менеджеров -- организовать производство, чтобы поднять общую производительность (throughput). Это важное, оно характеризуется тем, что нет дедлайнов, нет договоров, непонятно что делать, непонятно что это даст и какое будет вознаграждение или наказание. Но это ровно то, для чего существуют топ-менеджеры и топ-инженеры. Срочное характеризуется тем, что какой-то внешний заказчик чего-то хочет: понятно, что делать, понятно сколько это даст, дедлайн тоже понятен. По идее, с этим должны справляться не топ-менеджеры, а "просто менеджеры" и "просто инженеры". Но они не могут: именно потому, что топ-менеджеры их не организовали и не научили.
На что уходит время топ-менеджеров? На перехват срочного (контрактного) у менеджеров и инженеров, ибо те не справляются. Происходит многократная разовая организация, "экспедирование" конкретного дела. Это ОК, если не занимает 100% времени топ-менеджмента. Но дальше надо конвертировать "срочное дело" в "важное": сделать "разбор полётов"/ретроспективу:
-- понять, из-за чего случился очередной "пожар",
-- что не хватило в организации, чтобы этот "пожар" вообще не случился, а предприятие отработало ситуацию "штатно"
-- предложить микро-оргреформу, а затем её провести.
Вот план для оргреформы, и эти оргреформы -- это и есть "важное", они относятся к работе предприятия в целом, а не к выполнению конкретного договора:
-- Написать регламент или изменения к регламенту, как описанию метода какой-то работы, это "важное".
-- К регламенту сделать чеклист для прохождения каждой конкретной ситуации, поддержать чеклист софтом.
-- Научить людей действовать по регламенту и принудить использовать чеклист.
-- Проверять, следуют ли регламенту и честно ли проходят чеклист.
-- Принимать меры, если новый регламент саботируется или работает не как ожидается -- или менять регламенты и чеклисты на улучшенные, или доучить сотрудников, или уволить сотрудников
Как узнать, справляются ли топ-менеджеры с оргреформами? Поглядеть на то, что они сделали за неделю: сколько людей предприятия пошли по новым или изменённым чеклистам. Пусть покажут то, что заполняются новые чеклисты -- это означает, что регламенты составлены, чеклисты поддержаны хоть какой-то техникой (хоть бумагой, хоть софтом, хоть зарубками на деревянном столбе), люди с ними ознакомлены и реально им следуют. Если такого нет, то важная работа топ-менеджерами не выполняется, предприятие в целом бесхозное, работа ведётся только "по договорам", срочная. Топ-менеджера, который не занимается важной работой, надо просто разжаловать в "менеджера нестандартных проектов", "траблшутера" или кого другого рангом пониже. Ему не нужны полномочия топ-менеджера, ему нужны локальные полномочия антикризисного управляющего по каким-то договорам. Топ-менеджер -- это который организует работу так, чтобы кризисов не было (учит людей работать по-новому).
2. Долой каскадирование, верните инженерную культуру принятия решений
Чтобы выполнить пункт 1, у топ-менеджеров должны быть полномочия. Они их реализуют путём выпуска обязательных к выполнению распоряжений. Распоряжением (явным или неявным, это можно обсуждать) могут быть выпущены (не "утверждены", а "выпущены"/released/"приняты"/delivered)
-- регламенты и изменения к ним
-- чеклисты: и содержание, и указание, как они реализованы -- например, в каком софте
-- планы учебных мероприятий (надо ведь сотрудникам разъяснить, что изменилось в их методах работы, а также первый раз провести заполнение чеклистов с ними вместе, чтобы потом они делали это сами. Если что пойдёт не так, немедленно поменять регламент и чеклист. Если сотрудник заартачится -- проявить лидерство, а если упрётся -- уволить без сожаления).
А потом распоряжения сотрудникам надо будет выполнять, а топ-менеджер будет отслеживать (или организовывать отслеживание) их выполнение.
И вот тут проблема: надо вернуть полномочия по принятию решений как менеджерам (включая топ-менеджеров), так и инженерам. В текущей организации есть сдвиг полномочий на ступеньку вверх, это приводит к появлению дополнительного срока на "утверждение". В управлении это ведёт к диким задержкам. Как надо? Смотрим труды John Doyle (https://ailev.livejournal.com/1622346.html) по "синтезу уровня системы": контроллер/управляющий какого-то уровня посылает сигнал прямо на своё исполнительное устройство, хотя и участвует в сложной сети обратных связей (например, посылает копию управляющего сигнала, точнее, делает её доступной для вышестоящего уровня управления).
Вот как это выглядит на предприятии сейчас (случай гипотетический! Но в каждой шутке есть доля шутки):
-- топ-менеджер пишет докладную записку с ПРЕДЛОЖЕНИЯМИ о подготовке приказа (слово "предложения" тут капслоком, ибо это верный лексический признак того, что разработчик не принимает решение, а бесправный аналитик -- то есть ни разу не топ-менеджер).
-- какая-нибудь кадровая служба или канцелярия (они-то тут причём?) переводит докладную записку в формат готового к подписанию приказа, который УТВЕРЖДАЕТ регламент, чеклисты, даёт указание айтишникам и обязывает дальше следовать регламенту как корпоративному стандарту.
То есть вместо управления/организовывания топ-менеджер делает "предложения по управлению", а потом генеральный директор осуществляет управляющий акт. Разработчик только ПРЕДЛАГАЕТ (как аналитик, пишет "аналитический отчёт" и прилагает отдельно "рекомендации", а кто-то уровнем выше УТВЕРЖДАЕТ "рекомендации"). Это долго и неверно (ибо тот, кто утверждает, плохо владеет ситуацией -- он может ориентироваться только на металл в голосе предлагающего и непротивление окружающих предложениям, когда "принимает решение об утверждении". "Принятие решения об утверждении" -- это не принятие собственно организационного решения! Это совсем другое!
Налицо каскадирование: каждый уровень служебной иерархии занимается спихиванием исполнения вниз, а ответственности вверх. Так что работа двух смежных уровней (один предлагает, другой утверждает) это хороший случай, чаще один разрабтывает (сотрудник топ-менеджера), а другой (топ-менеджер) просто передаёт вверх на утверждение генеральному. Ну, и если уровней десять, то каскад на десять уровней. Не спрашивайте, что там думает архитектор предприятия про такую модульность -- архитектора предприятия там нет. А генеральный конструктор? У него разузловка/предложение модульной структуры изделия делается примерно так же -- не инженерно, а начальственно, "предложением-утверждением".
Против этого работает инженерная парадигма, в которой инженер-проектировщик выпускает проектную документацию (в случае организатора это как раз регламенты и чеклисты по изменению состояния какого-то предмета регламента), а инженер-технолог потом реализует этот проект на заводе.
Но постойте, а как действуют инженеры? Вы удивитесь, они сегодня копируют менеджеров: они тоже стали аналитиками, которые не выпускают инженерные рабочие продукты, а только ПРЕДЛАГАЮТ, а какие-то их начальники их УТВЕРЖДАЮТ. Та же самая сдвижка "шкуры инженера на кону" на уровень вверх. Инженер-разработчик не говорит, "согласно моим расчётам в ракете будет 3 ступени, а варианты с двумя и четырьмя ступенями не прошли" -- и дальше все остальные инженеры ориентируются на него. Нет, он делает "предложение", а потом кто-то "утверждает" это предложение. Один генеральный конструктор пожаловался, что он у себя на почте вечером находит примерно двести предложений, требующих утверждения.
А как там с коллизиями? В нашем курсе системной инженерии говорится: "В DevOps тоже рассматривают версионирование (для описаний) и управление конфигурацией (для целевой системы), на этом основана практика непрерывной интеграции (continuous integration, в любой момент времени есть готовый целостный вариант системы). Часть этой практики - магистральная разработка/trunk-based development. Управление изменениями в виде независимого принятия решений какой-нибудь «комиссией по изменениям» экспериментально было показано, что не работает (см. подробности в книге «Accelerate»). Это очень контринтуитивно, но команда сама принимает решение, что ей добавлять в общий продукт. Нет долгоживущей версии baseline и трудной процедуры внесения в неё изменений. Более того, одновременно в работе (например, при A|B-тестировании) могут находиться несколько версий системы, все они «главные», и все они «экспериментальные». В любой момент жизни системы она рассматривается не как окончательная конфигурация на базе окончательной версии описаний системы, полученных из разработки, но как «текущая», которая будет меняться много раз в день. Поиск конфигурационных коллизий - тут". Ещё фрагмент из этого же курса: "каждая команда выдаёт поток небольших инкрементальных изменений в общую «магистраль» (trunk) сборки, и это происходит ежедневно (иногда ежечасно), но не еженедельно и уж тем более не ежемесячно. Это практика магистральной разработки (trunk-based development) вместо практики «долгоживущих ветвей для изменений» (long-lived feature branches) и последующих больших шагов по интеграции. Сегодня это уже практика не только программной инженерии, но и «железной» инженерии: в самолётостроении конструкторы результаты своей работы выкладывают в общую PLM-систему немедленно, каждый день, а не по мере окончательной готовности каких-то крупных частей. Ещё лет десять назад в моде была поговорка, что «дураку половину работы не показывают», сегодня на эту поговорку сразу возражают:
• Смотрят не дураки, поэтому с такими заявлениями нужно быть осторожней.
• Значит взял слишком большую работу, надо было поделить её на части, которые можно показывать.
• Если не показываешь, то ошибки (начиная с того, что вообще ненужную работу делаешь, не тем занялся) выявятся позже, а это недопустимо.
• Покажи ещё и тесты для своей работы.
Каждая интеграция маленького инкремента не занимает много времени, а если выявляются «большие проблемы» (например, необходимость доработки интерфейсов), то они выявляются рано. То, что это небольшие законченные части, помогает как с обеспечением «потока» (flow) работ в части менеджмента (отсутствуют «заторы» в местах ограничения/constraints потока - small batch size практика), так и помогает быстро находить ошибки, уменьшать число переделок/reworks в части прикладной инженерной работы".
Итого: каждый сам принимает свои решения и немедленно отдаёт результаты этих решений для всей команды, а не "предлагает на утверждение" и не "утверждает решения других". Тут и "шкура на кону", и субсидиарность, и continuous delivery и даже в какой-то мере you build it, you run it! Много самых разных идей, которые все про одно и то же: давайте люди будут принимать решения и воплощать их, а не "утверждать". "Утверждение" -- это только замедление дела, прощё каждому принимать свои решения и дальше быстро обнаруживать конфигурационные коллизии и устранять их, сотрудничая с другими инженерами и менеджерами.
Вернуть инженерию и менеджмент на предприятия вместо аналитики и начальничества! Это резко ускоряет работы:
-- меньше время на выпуск каждого решения ("выпуск" вместо "предложения -- утверждения"), меньше времени на лишнюю "координацию", больше на саму работу
-- ранняя обратная связь, то есть раннее устранение конфигурационных коллизий, ошибки не успевают закрепиться
-- устраняет длинные цепочки "один предлагает, другой утверждает, третий вносит изменения в софт". Кто предлагает, тот и вносит своей властью решения как изменения в софте! Отредактировать в универсальном моделере строчку чеклиста -- это не так трудно, и много быстрее, чем вовлекать в это дело множество людей и устранять ошибки недопонимания.
И ещё замечание сюда же: власть никогда не дают, её берут!
3. Регламенты, чеклисты, обучение, присмотр.
Самым крутым учебником методологии до сих пор является книжка Атула Гаванде про чеклисты. Второй по крутости -- это мой курс "Методология". По большому счёту, именно курс "Методология" -- это курс организационного моделирования в части "процессного подхода" (хотя он и намеренно не касается таких вопросов, как архитектура предприятия, это даётся в "Системном менеджменте").
В курсе методологии рассказывается, как сделать из чего угодно моделер для моделирования выполнения практик. Если кратко, то практика/культура/метод работы (там ещё десяток синонимов) приводит к изменению состояния каких-то объектов. Это изменение производится агентом/оргзвеном, который отыгрывает роль в этой практике, руководствуясь её дисциплиной/теорией/знанием и задействуя технологию/оборудование и материалы.
Если мы хотим, чтобы предприятие (оргзвенья: люди с оборудованием, в том числе с компьютерами) что-то начало делать по-новому, то надо это сначала описать/отмоделировать:
-- описать, "как это делается вообще" в виде регламента (или ссылочно: сказать, где найти описание. Ответ "в чертогах моего разума, сейчас покажу" обычно не подходит. Да, про tacit knowledge и "непосредственную передачу традиции" всё знаем. Но когда традиция оказывается записанной, то можно проводить масштабирование и можно проводить улучшения. Без явного использования внешней памяти -- будет "хотели как лучше, получается как всегда").
-- описать, какие изменения состояния какого-то объекта попадают в чеклист, то есть сделать шаблон чеклиста ("дверь найдена", "дверь закрыта", "о закрытии двери сообщено" -- и формулировки имеют значение, лучше всего работают формулировки достижения состояния после выполнения какой-то практики). Впрочем, Гаванде говорит, что чеклисты бывают проверки состояния и чеклисты выполнения операций. Вот нам все нужны. Главное, что а) экземпляр чеклиста используется при выполнении каждой работы, а регламент пишется один раз на все варианты работы, это "учебник", и б) в чеклист попадает не всё, а только самое главное, а вот "всё" описывается в учебнике.
-- описать каждый экземпляр работы отдельным экземпляром чеклиста, который может существовать в очень разной форме. Мы рекомендуем табличную форму описания процессов/практик/методов работы, и как это сделать, описано в курсе "Методология". Важно: если вы не прошли "Моделирование и собранность", то результаты вашего моделирования могут быть не слишком хорошими. Секрет не в форме табличек и моделерах, а в их содержании. Но вы должны обеспечить, чтобы по шаблону порождался для каждого экземпляра работы свой экземпляр чеклиста. Грубо говоря, для каждой открываемой двери должен порождаться экземпляр чеклиста открытия этой двери по шаблону открытия "дверей вообще".
-- дальше надо описать (спланировать), как вы будете осуществлять лидерство: как люди узнают содержание регламента и как они захотят и будут проходить чеклисты. Совещания, тренинги, совместная работа по первому прохождению чеклиста -- всё это тут.
И потом всё это надо сделать: чеклисты запрограммировать или распечатать или ещё как-то реализовать, а людей обучить -- и затем контролировать, что они пошли по этим чеклистам. Как проверить, что вы выполнили организационное изменение, выполнили микрореформу какой-то области деятельности предприятия? Проверить, что люди идут по обновлённым чеклистам. Если идут -- ОК, предприятие занималось важным. Если не идут -- топ-менеджеры не занимаются своим главным делом. За топ-менеджерами тоже нужен присмотр, governance никто не отменял. Это когда уволняют не за невыполнение работы в срок и бюджет, а за неследование методам работы (в том числе выполнение не той вообще работы, которая ожидается).
4. Цифровая трансформация
А где ж там цифровая трансформация/интеллектуализация/автоматизация/компьютеризация? Это она и есть, самые первые шаги. Первый шаг в любом чеклисте -- это состояние, когда понятно, с каким именно объектом мы работаем. Если непонятно, то чеклист не к чему применять. Цифровая трансформация поддерживает производственные/рабочие процессы/практики/методы/культуры/стили работы предприятия. Если непонятно, какие, они невидимы -- то непонятно, что там поддерживать. Так что давайте сделаем их видимыми: сделаем важным делом (пункт 1 нашего текста, про важное против срочного), теперь проверим, что мы этим важным делом занимаемся -- и делаем это быстро, а не "предлагаем изменения -- утверждаем изменения" (пункт 2 текста про возврат инженерии и менеджмента против "аналитики с начальничеством"), отмоделируем в виде чеклистов (пункт 3 текста про методологию и моделирование практик/рабочих процессов).
Это всё -- цифровая трансформация. Если вы не знаете, что вы и ваши сотрудники делают, никакая трансформация им не поможет. Если вы не понимаете, что делаете, то вы не можете это поддержать компьютерами!
Второй момент -- это моделирование. Надо начинать работать с моделями, а не выписками. Это довольно сложный поворот в мозгах. Что надо сделать:
-- чеклист на слова "послал" и "получил". Если они встречаются в регламентах и документах, то имеем дело с выпиской. Работа с моделями происходит через "изменил" и "увидел", другая лексика.
-- в чеклистах объекты изменения, проходящие состояния -- модели, а не выписки. Есть объект моделирования, есть модель. Вот её и меняем. Собственно, это и есть "цифровая трансформация" в "народном понимании".
-- сами чеклисты -- это ж тоже модель, так что тоже должны быть поддержаны софтом (а не бумагой). Помним, что они могут существовать в самой разной форме (у Атул Гаванде сказано, что план строительных работ на 6000 работ -- это как раз чеклист, ибо выполнение каждой работы в этом плане, который поддержан софтом, чекается на "работа выполнена").
Отдельные слова про АСУ и АСУ ТП (ещё один синоним цифровой трансформации -- "асучивание предприятия"). Когда говорим о цифровой модели -- это обычно время проектирования, когда о цифровой тени -- это эксплуатация в "ручном режиме"/"автоматизированная система" (как раз АСУ), а когда о том, что у нас цифровой двойник -- это эксплуатация в автоматическом режиме (АСУ ТП обычно как раз об этом: все уставки динамически меняются без участия человека, https://ru.wiktionary.org/wiki/уставка ). Разница в том, что АСУ это про предприятие, а АСУ ТП это про какой-то "техпроцесс" в оборудовании. Разговор же про "цифрового двойника" (и неминуемый -- про цифровую модель и цифровую тень как частые ступеньки на пути к цифровому двойнику) -- это абстрагирование от того, управление чем именно автоматизируется: предприятием ли, техпроцессом ли, или чем-то совсем другим (цифровой двойник сотрудника, например -- это когда зарплата ему выставляется автоматом по итогам работы, "автоматически", а если вы таки собираете данные автоматически по итогам работы, а зарплату выставляете потом руками -- это "автоматизированно", то есть цифровая тень сотрудника, а если только проектируете что там с сотрудником будет -- это просто цифровая модель сотрудника. Слова про АСУ тут не очень помогали различить, но смысл -- тот же).
Итого:
-- для занятия цифровой трансформацией реального сектора надо сделать это важным и заняться изменением методов работы, а не только разруливанием клиентских проектов
-- надо сделать видимыми методы работы, то есть отмоделировать их
-- работа должна быть с моделями, а не выписками
-- дальше цифровые модели надо делать цифровыми тенями, а потом и цифровыми двойниками.
Всё это прописано в наших курсах программы "Организационное развитие", но это тысячи страниц текста, которые всё это подробно разъясняют. Тут же коротенькая выжимка, которую хорошо бы держать перед глазами топ-менеджерам. Чек-лист, по которому легко определить, работают ли топ-менеджеры топ-менеджерами, или они продолжают быть исполнителями контрактов, простыми работниками, а не организаторами исполнения контрактов, не организаторами предприятия. Смотрим на чеклисты, по которым идут их сотрудники. И смотрим, как эти чеклисты меняются во времени и какие объекты в этих чеклистах меняют свои состояния. Дальше надо или учить топ-менеджеров быть топ-менеджерами, или увольнять их за неспособность отличить важное от срочного.
UPDATE: обсуждение в https://vk.com/wall2449939_5487, в чате блога с https://t.me/ailev_blog_discussion/23588, в клубе ШСМ -- https://systemsworld.club/t/trudnosti-czifrovoj-transformaczii-realnogo-sektora/8034/3
Топ менеджеры считают, что они заняты важным, но на самом деле -- срочным. Основная задача топ-менеджеров -- организовать производство, чтобы поднять общую производительность (throughput). Это важное, оно характеризуется тем, что нет дедлайнов, нет договоров, непонятно что делать, непонятно что это даст и какое будет вознаграждение или наказание. Но это ровно то, для чего существуют топ-менеджеры и топ-инженеры. Срочное характеризуется тем, что какой-то внешний заказчик чего-то хочет: понятно, что делать, понятно сколько это даст, дедлайн тоже понятен. По идее, с этим должны справляться не топ-менеджеры, а "просто менеджеры" и "просто инженеры". Но они не могут: именно потому, что топ-менеджеры их не организовали и не научили.
На что уходит время топ-менеджеров? На перехват срочного (контрактного) у менеджеров и инженеров, ибо те не справляются. Происходит многократная разовая организация, "экспедирование" конкретного дела. Это ОК, если не занимает 100% времени топ-менеджмента. Но дальше надо конвертировать "срочное дело" в "важное": сделать "разбор полётов"/ретроспективу:
-- понять, из-за чего случился очередной "пожар",
-- что не хватило в организации, чтобы этот "пожар" вообще не случился, а предприятие отработало ситуацию "штатно"
-- предложить микро-оргреформу, а затем её провести.
Вот план для оргреформы, и эти оргреформы -- это и есть "важное", они относятся к работе предприятия в целом, а не к выполнению конкретного договора:
-- Написать регламент или изменения к регламенту, как описанию метода какой-то работы, это "важное".
-- К регламенту сделать чеклист для прохождения каждой конкретной ситуации, поддержать чеклист софтом.
-- Научить людей действовать по регламенту и принудить использовать чеклист.
-- Проверять, следуют ли регламенту и честно ли проходят чеклист.
-- Принимать меры, если новый регламент саботируется или работает не как ожидается -- или менять регламенты и чеклисты на улучшенные, или доучить сотрудников, или уволить сотрудников
Как узнать, справляются ли топ-менеджеры с оргреформами? Поглядеть на то, что они сделали за неделю: сколько людей предприятия пошли по новым или изменённым чеклистам. Пусть покажут то, что заполняются новые чеклисты -- это означает, что регламенты составлены, чеклисты поддержаны хоть какой-то техникой (хоть бумагой, хоть софтом, хоть зарубками на деревянном столбе), люди с ними ознакомлены и реально им следуют. Если такого нет, то важная работа топ-менеджерами не выполняется, предприятие в целом бесхозное, работа ведётся только "по договорам", срочная. Топ-менеджера, который не занимается важной работой, надо просто разжаловать в "менеджера нестандартных проектов", "траблшутера" или кого другого рангом пониже. Ему не нужны полномочия топ-менеджера, ему нужны локальные полномочия антикризисного управляющего по каким-то договорам. Топ-менеджер -- это который организует работу так, чтобы кризисов не было (учит людей работать по-новому).
2. Долой каскадирование, верните инженерную культуру принятия решений
Чтобы выполнить пункт 1, у топ-менеджеров должны быть полномочия. Они их реализуют путём выпуска обязательных к выполнению распоряжений. Распоряжением (явным или неявным, это можно обсуждать) могут быть выпущены (не "утверждены", а "выпущены"/released/"приняты"/delivered)
-- регламенты и изменения к ним
-- чеклисты: и содержание, и указание, как они реализованы -- например, в каком софте
-- планы учебных мероприятий (надо ведь сотрудникам разъяснить, что изменилось в их методах работы, а также первый раз провести заполнение чеклистов с ними вместе, чтобы потом они делали это сами. Если что пойдёт не так, немедленно поменять регламент и чеклист. Если сотрудник заартачится -- проявить лидерство, а если упрётся -- уволить без сожаления).
А потом распоряжения сотрудникам надо будет выполнять, а топ-менеджер будет отслеживать (или организовывать отслеживание) их выполнение.
И вот тут проблема: надо вернуть полномочия по принятию решений как менеджерам (включая топ-менеджеров), так и инженерам. В текущей организации есть сдвиг полномочий на ступеньку вверх, это приводит к появлению дополнительного срока на "утверждение". В управлении это ведёт к диким задержкам. Как надо? Смотрим труды John Doyle (https://ailev.livejournal.com/1622346.html) по "синтезу уровня системы": контроллер/управляющий какого-то уровня посылает сигнал прямо на своё исполнительное устройство, хотя и участвует в сложной сети обратных связей (например, посылает копию управляющего сигнала, точнее, делает её доступной для вышестоящего уровня управления).
Вот как это выглядит на предприятии сейчас (случай гипотетический! Но в каждой шутке есть доля шутки):
-- топ-менеджер пишет докладную записку с ПРЕДЛОЖЕНИЯМИ о подготовке приказа (слово "предложения" тут капслоком, ибо это верный лексический признак того, что разработчик не принимает решение, а бесправный аналитик -- то есть ни разу не топ-менеджер).
-- какая-нибудь кадровая служба или канцелярия (они-то тут причём?) переводит докладную записку в формат готового к подписанию приказа, который УТВЕРЖДАЕТ регламент, чеклисты, даёт указание айтишникам и обязывает дальше следовать регламенту как корпоративному стандарту.
То есть вместо управления/организовывания топ-менеджер делает "предложения по управлению", а потом генеральный директор осуществляет управляющий акт. Разработчик только ПРЕДЛАГАЕТ (как аналитик, пишет "аналитический отчёт" и прилагает отдельно "рекомендации", а кто-то уровнем выше УТВЕРЖДАЕТ "рекомендации"). Это долго и неверно (ибо тот, кто утверждает, плохо владеет ситуацией -- он может ориентироваться только на металл в голосе предлагающего и непротивление окружающих предложениям, когда "принимает решение об утверждении". "Принятие решения об утверждении" -- это не принятие собственно организационного решения! Это совсем другое!
Налицо каскадирование: каждый уровень служебной иерархии занимается спихиванием исполнения вниз, а ответственности вверх. Так что работа двух смежных уровней (один предлагает, другой утверждает) это хороший случай, чаще один разрабтывает (сотрудник топ-менеджера), а другой (топ-менеджер) просто передаёт вверх на утверждение генеральному. Ну, и если уровней десять, то каскад на десять уровней. Не спрашивайте, что там думает архитектор предприятия про такую модульность -- архитектора предприятия там нет. А генеральный конструктор? У него разузловка/предложение модульной структуры изделия делается примерно так же -- не инженерно, а начальственно, "предложением-утверждением".
Против этого работает инженерная парадигма, в которой инженер-проектировщик выпускает проектную документацию (в случае организатора это как раз регламенты и чеклисты по изменению состояния какого-то предмета регламента), а инженер-технолог потом реализует этот проект на заводе.
Но постойте, а как действуют инженеры? Вы удивитесь, они сегодня копируют менеджеров: они тоже стали аналитиками, которые не выпускают инженерные рабочие продукты, а только ПРЕДЛАГАЮТ, а какие-то их начальники их УТВЕРЖДАЮТ. Та же самая сдвижка "шкуры инженера на кону" на уровень вверх. Инженер-разработчик не говорит, "согласно моим расчётам в ракете будет 3 ступени, а варианты с двумя и четырьмя ступенями не прошли" -- и дальше все остальные инженеры ориентируются на него. Нет, он делает "предложение", а потом кто-то "утверждает" это предложение. Один генеральный конструктор пожаловался, что он у себя на почте вечером находит примерно двести предложений, требующих утверждения.
А как там с коллизиями? В нашем курсе системной инженерии говорится: "В DevOps тоже рассматривают версионирование (для описаний) и управление конфигурацией (для целевой системы), на этом основана практика непрерывной интеграции (continuous integration, в любой момент времени есть готовый целостный вариант системы). Часть этой практики - магистральная разработка/trunk-based development. Управление изменениями в виде независимого принятия решений какой-нибудь «комиссией по изменениям» экспериментально было показано, что не работает (см. подробности в книге «Accelerate»). Это очень контринтуитивно, но команда сама принимает решение, что ей добавлять в общий продукт. Нет долгоживущей версии baseline и трудной процедуры внесения в неё изменений. Более того, одновременно в работе (например, при A|B-тестировании) могут находиться несколько версий системы, все они «главные», и все они «экспериментальные». В любой момент жизни системы она рассматривается не как окончательная конфигурация на базе окончательной версии описаний системы, полученных из разработки, но как «текущая», которая будет меняться много раз в день. Поиск конфигурационных коллизий - тут". Ещё фрагмент из этого же курса: "каждая команда выдаёт поток небольших инкрементальных изменений в общую «магистраль» (trunk) сборки, и это происходит ежедневно (иногда ежечасно), но не еженедельно и уж тем более не ежемесячно. Это практика магистральной разработки (trunk-based development) вместо практики «долгоживущих ветвей для изменений» (long-lived feature branches) и последующих больших шагов по интеграции. Сегодня это уже практика не только программной инженерии, но и «железной» инженерии: в самолётостроении конструкторы результаты своей работы выкладывают в общую PLM-систему немедленно, каждый день, а не по мере окончательной готовности каких-то крупных частей. Ещё лет десять назад в моде была поговорка, что «дураку половину работы не показывают», сегодня на эту поговорку сразу возражают:
• Смотрят не дураки, поэтому с такими заявлениями нужно быть осторожней.
• Значит взял слишком большую работу, надо было поделить её на части, которые можно показывать.
• Если не показываешь, то ошибки (начиная с того, что вообще ненужную работу делаешь, не тем занялся) выявятся позже, а это недопустимо.
• Покажи ещё и тесты для своей работы.
Каждая интеграция маленького инкремента не занимает много времени, а если выявляются «большие проблемы» (например, необходимость доработки интерфейсов), то они выявляются рано. То, что это небольшие законченные части, помогает как с обеспечением «потока» (flow) работ в части менеджмента (отсутствуют «заторы» в местах ограничения/constraints потока - small batch size практика), так и помогает быстро находить ошибки, уменьшать число переделок/reworks в части прикладной инженерной работы".
Итого: каждый сам принимает свои решения и немедленно отдаёт результаты этих решений для всей команды, а не "предлагает на утверждение" и не "утверждает решения других". Тут и "шкура на кону", и субсидиарность, и continuous delivery и даже в какой-то мере you build it, you run it! Много самых разных идей, которые все про одно и то же: давайте люди будут принимать решения и воплощать их, а не "утверждать". "Утверждение" -- это только замедление дела, прощё каждому принимать свои решения и дальше быстро обнаруживать конфигурационные коллизии и устранять их, сотрудничая с другими инженерами и менеджерами.
Вернуть инженерию и менеджмент на предприятия вместо аналитики и начальничества! Это резко ускоряет работы:
-- меньше время на выпуск каждого решения ("выпуск" вместо "предложения -- утверждения"), меньше времени на лишнюю "координацию", больше на саму работу
-- ранняя обратная связь, то есть раннее устранение конфигурационных коллизий, ошибки не успевают закрепиться
-- устраняет длинные цепочки "один предлагает, другой утверждает, третий вносит изменения в софт". Кто предлагает, тот и вносит своей властью решения как изменения в софте! Отредактировать в универсальном моделере строчку чеклиста -- это не так трудно, и много быстрее, чем вовлекать в это дело множество людей и устранять ошибки недопонимания.
И ещё замечание сюда же: власть никогда не дают, её берут!
3. Регламенты, чеклисты, обучение, присмотр.
Самым крутым учебником методологии до сих пор является книжка Атула Гаванде про чеклисты. Второй по крутости -- это мой курс "Методология". По большому счёту, именно курс "Методология" -- это курс организационного моделирования в части "процессного подхода" (хотя он и намеренно не касается таких вопросов, как архитектура предприятия, это даётся в "Системном менеджменте").
В курсе методологии рассказывается, как сделать из чего угодно моделер для моделирования выполнения практик. Если кратко, то практика/культура/метод работы (там ещё десяток синонимов) приводит к изменению состояния каких-то объектов. Это изменение производится агентом/оргзвеном, который отыгрывает роль в этой практике, руководствуясь её дисциплиной/теорией/знанием и задействуя технологию/оборудование и материалы.
Если мы хотим, чтобы предприятие (оргзвенья: люди с оборудованием, в том числе с компьютерами) что-то начало делать по-новому, то надо это сначала описать/отмоделировать:
-- описать, "как это делается вообще" в виде регламента (или ссылочно: сказать, где найти описание. Ответ "в чертогах моего разума, сейчас покажу" обычно не подходит. Да, про tacit knowledge и "непосредственную передачу традиции" всё знаем. Но когда традиция оказывается записанной, то можно проводить масштабирование и можно проводить улучшения. Без явного использования внешней памяти -- будет "хотели как лучше, получается как всегда").
-- описать, какие изменения состояния какого-то объекта попадают в чеклист, то есть сделать шаблон чеклиста ("дверь найдена", "дверь закрыта", "о закрытии двери сообщено" -- и формулировки имеют значение, лучше всего работают формулировки достижения состояния после выполнения какой-то практики). Впрочем, Гаванде говорит, что чеклисты бывают проверки состояния и чеклисты выполнения операций. Вот нам все нужны. Главное, что а) экземпляр чеклиста используется при выполнении каждой работы, а регламент пишется один раз на все варианты работы, это "учебник", и б) в чеклист попадает не всё, а только самое главное, а вот "всё" описывается в учебнике.
-- описать каждый экземпляр работы отдельным экземпляром чеклиста, который может существовать в очень разной форме. Мы рекомендуем табличную форму описания процессов/практик/методов работы, и как это сделать, описано в курсе "Методология". Важно: если вы не прошли "Моделирование и собранность", то результаты вашего моделирования могут быть не слишком хорошими. Секрет не в форме табличек и моделерах, а в их содержании. Но вы должны обеспечить, чтобы по шаблону порождался для каждого экземпляра работы свой экземпляр чеклиста. Грубо говоря, для каждой открываемой двери должен порождаться экземпляр чеклиста открытия этой двери по шаблону открытия "дверей вообще".
-- дальше надо описать (спланировать), как вы будете осуществлять лидерство: как люди узнают содержание регламента и как они захотят и будут проходить чеклисты. Совещания, тренинги, совместная работа по первому прохождению чеклиста -- всё это тут.
И потом всё это надо сделать: чеклисты запрограммировать или распечатать или ещё как-то реализовать, а людей обучить -- и затем контролировать, что они пошли по этим чеклистам. Как проверить, что вы выполнили организационное изменение, выполнили микрореформу какой-то области деятельности предприятия? Проверить, что люди идут по обновлённым чеклистам. Если идут -- ОК, предприятие занималось важным. Если не идут -- топ-менеджеры не занимаются своим главным делом. За топ-менеджерами тоже нужен присмотр, governance никто не отменял. Это когда уволняют не за невыполнение работы в срок и бюджет, а за неследование методам работы (в том числе выполнение не той вообще работы, которая ожидается).
4. Цифровая трансформация
А где ж там цифровая трансформация/интеллектуализация/автоматизация/компьютеризация? Это она и есть, самые первые шаги. Первый шаг в любом чеклисте -- это состояние, когда понятно, с каким именно объектом мы работаем. Если непонятно, то чеклист не к чему применять. Цифровая трансформация поддерживает производственные/рабочие процессы/практики/методы/культуры/стили работы предприятия. Если непонятно, какие, они невидимы -- то непонятно, что там поддерживать. Так что давайте сделаем их видимыми: сделаем важным делом (пункт 1 нашего текста, про важное против срочного), теперь проверим, что мы этим важным делом занимаемся -- и делаем это быстро, а не "предлагаем изменения -- утверждаем изменения" (пункт 2 текста про возврат инженерии и менеджмента против "аналитики с начальничеством"), отмоделируем в виде чеклистов (пункт 3 текста про методологию и моделирование практик/рабочих процессов).
Это всё -- цифровая трансформация. Если вы не знаете, что вы и ваши сотрудники делают, никакая трансформация им не поможет. Если вы не понимаете, что делаете, то вы не можете это поддержать компьютерами!
Второй момент -- это моделирование. Надо начинать работать с моделями, а не выписками. Это довольно сложный поворот в мозгах. Что надо сделать:
-- чеклист на слова "послал" и "получил". Если они встречаются в регламентах и документах, то имеем дело с выпиской. Работа с моделями происходит через "изменил" и "увидел", другая лексика.
-- в чеклистах объекты изменения, проходящие состояния -- модели, а не выписки. Есть объект моделирования, есть модель. Вот её и меняем. Собственно, это и есть "цифровая трансформация" в "народном понимании".
-- сами чеклисты -- это ж тоже модель, так что тоже должны быть поддержаны софтом (а не бумагой). Помним, что они могут существовать в самой разной форме (у Атул Гаванде сказано, что план строительных работ на 6000 работ -- это как раз чеклист, ибо выполнение каждой работы в этом плане, который поддержан софтом, чекается на "работа выполнена").
Отдельные слова про АСУ и АСУ ТП (ещё один синоним цифровой трансформации -- "асучивание предприятия"). Когда говорим о цифровой модели -- это обычно время проектирования, когда о цифровой тени -- это эксплуатация в "ручном режиме"/"автоматизированная система" (как раз АСУ), а когда о том, что у нас цифровой двойник -- это эксплуатация в автоматическом режиме (АСУ ТП обычно как раз об этом: все уставки динамически меняются без участия человека, https://ru.wiktionary.org/wiki/уставка ). Разница в том, что АСУ это про предприятие, а АСУ ТП это про какой-то "техпроцесс" в оборудовании. Разговор же про "цифрового двойника" (и неминуемый -- про цифровую модель и цифровую тень как частые ступеньки на пути к цифровому двойнику) -- это абстрагирование от того, управление чем именно автоматизируется: предприятием ли, техпроцессом ли, или чем-то совсем другим (цифровой двойник сотрудника, например -- это когда зарплата ему выставляется автоматом по итогам работы, "автоматически", а если вы таки собираете данные автоматически по итогам работы, а зарплату выставляете потом руками -- это "автоматизированно", то есть цифровая тень сотрудника, а если только проектируете что там с сотрудником будет -- это просто цифровая модель сотрудника. Слова про АСУ тут не очень помогали различить, но смысл -- тот же).
Итого:
-- для занятия цифровой трансформацией реального сектора надо сделать это важным и заняться изменением методов работы, а не только разруливанием клиентских проектов
-- надо сделать видимыми методы работы, то есть отмоделировать их
-- работа должна быть с моделями, а не выписками
-- дальше цифровые модели надо делать цифровыми тенями, а потом и цифровыми двойниками.
Всё это прописано в наших курсах программы "Организационное развитие", но это тысячи страниц текста, которые всё это подробно разъясняют. Тут же коротенькая выжимка, которую хорошо бы держать перед глазами топ-менеджерам. Чек-лист, по которому легко определить, работают ли топ-менеджеры топ-менеджерами, или они продолжают быть исполнителями контрактов, простыми работниками, а не организаторами исполнения контрактов, не организаторами предприятия. Смотрим на чеклисты, по которым идут их сотрудники. И смотрим, как эти чеклисты меняются во времени и какие объекты в этих чеклистах меняют свои состояния. Дальше надо или учить топ-менеджеров быть топ-менеджерами, или увольнять их за неспособность отличить важное от срочного.
UPDATE: обсуждение в https://vk.com/wall2449939_5487, в чате блога с https://t.me/ailev_blog_discussion/23588, в клубе ШСМ -- https://systemsworld.club/t/trudnosti-czifrovoj-transformaczii-realnogo-sektora/8034/3