Неявные предположения при моделировании
Как мы уже не раз писали в руководстве, мышление – это моделирование. Поэтому каждый агент/создатель, который мыслит, создаёт/конструирует модели – буквально цифровые копии объектов физического и ментального миров – у себя в голове. Но эти копии на самом деле не «точные копии», а скорее «отображения» или «реконструкции» – то есть, упрощённые, полезные модели, не отражающие объект во всей его сложности, а лишь моделирующие отдельные наиболее важные аспекты объекта. Например, «человек» как объект внимания очень сложен, его можно рассматривать с разных сторон и точек зрения – как физическое тело/физический объект, который движется в пространстве; как химический объект, в котором нас интересуют происходящие в теле химические реакции; как социальный объект, в котором нас интересует коммуникация с окружающими, и так далее. И в силу особенностей устройства биологического вычислителя мы не можем одновременно воспринимать все эти точки зрения/viewpoints – вычислительных ресурсов не хватит. Поэтому в каждый момент времени мы выбираем наиболее важное, концентрируемся на нём и воссоздаём модели, которые будут полезны для объяснения этого важного. Например, социальная модель человека (или команды) в коллективе предприятия, которая объясняет, с кем и как он общается, каких вопросов от него ожидать, а каких – нет.
Выбор тех объектов, на которых мы будем концентрироваться, часто происходит не только сознательно, то есть, когда вы составляете описания с применением изученных методов моделирования, но и неосознанно. Например, в рабочих ситуациях люди автоматически занимают позицию (выбирают точку зрения/viewpoint) инженера и обсуждают метод, забывая про работы или наоборот: выбирают точку зрения менеджера и обсуждают работы, забывая про метод (что привычнее). Такой способ описания мира часто называют профессиональной деформацией: вы начинаете интерпретировать все, что видите-слышите-воспринимаете, через специфические профессиональные картины мира. Например, криминалисты могут подозревать окружающих в нечистых делах, управленцы дома пытаются общаться с близкими как с подчинёнными. Но на самом деле профдеформация – лишь одно из проявлений этого общего механизма. Мы можем не играть какую-то профессиональную роль в области, но уже заранее выбрать какой-то способ описания/точку зрения/viewpoint и придерживаться её, отсекая то, что не подходит под это описание. Например, профессиональных политиков мало, но многие, кто роль политика не играет, имеет ту или иную точку зрения/viewpoint на неё, и часто готов эту точку зрения всячески отстаивать, игнорируя другие точки зрения/способы описания. И так будет происходить постоянно в разных областях вашей деятельности (и деятельности других агентов). Поэтому полезно иногда выявлять неявные предположения, которые лежат в основе ваших моделей – особенно если вы занимаетесь стратегированием или исследованиями.
Вместе с точкой зрения/viewpoint мы также обычно принимаем некоторый набор неявных предположений/unspoken assumptions. Когда вы моделируете потоки работ предприятия, вы тоже опираетесь на следующие неявные предположения:
- *Бизнес-модель (как предмет метода прибыльности/бизнеса)*не является объектом вашего внимания. При помощи модели потоков работ нельзя сказать, выгодно ли владеть этой компанией, стоит ли в неё вкладываться и так далее.
- Стратегия (как предмет метода стратегирования) не является объектом вашего внимания. Текущая версия стратегии предприятия относится к классу «входящей информации», которую вы принимаете как данность. Выбранная версия стратегии наложит ограничения на выбор операционных параметров предприятия: если вы выпускаете типовые продукты, то предприятие как конвейер должно работать максимально быстро с минимальной изменчивостью/variance, позволить себе удлинять потоковое время/Flow Time/Cycle Time вы не можете. Однако составитель модели потоков работ не может поменять стратегию предприятия, он может лишь сказать, может ли конкретно это предприятие реализовать выбранную стратегию без оргизменений или нет. Но менеджер должен знать стратегию предприятия, чтобы сказать, насколько возможно реализовать эту стратегию с текущей версией конвейера.
- Методы работы предприятия в целом не являются объектами вашего внимания. Менеджеру нужно знать, какие методы работы применяются, потому что отмоделировать работы по методу без этого не удастся. То есть, модельеру потоков работ нужно описание методов работы предприятия или его части, например, граф создателей с перечислением применяемых методов и функциональных объектов, применяющих методы[1]. Но это описание он принимает, а не составляет сам. Если такого описания нет, то человек, который будет моделировать потоки работ, должен переключиться на исполнение другой роли и отмоделировать методы, хотя бы в минимальном варианте. Когда моделируем потоки работ предприятия, мы пользуемся уже готовым описанием методов.
- Архитектур**ные характеристики предприятия не являются объектами вашего внимания. Вы не думаете о том, как поддерживать надежность работы предприятия, стабильность выпущенных результатов, и так далее. Это все находится за пределами точки зрения/способа описания/способа смотреть на мир, которым нужно воспользоваться при моделировании потоков работ.
- Способы совместить методы работы предприятия и оргзвенья*/модули не являются объектами вашего внимания.* Все это – данность при моделировании. Модель потоков работ может быть использована для переговоров с оргпроектировщиком об изменении концепции организации, но при моделировании мы описываем текущие реальные потоки работ на предприятии, а не планируемые.
- Методы проведения оргизменений не являются объектами вашего внимания. Операционный менеджер не меняет предприятие, он эксплуатирует его. Поэтому для начала надо вывести во внимание предметы метода управления работами.
- Операционного менеджера и модельера потоков работ интересует время эксплуатации предприятия, а не время создания. Что реально имеем сейчас, какие ресурсы есть и как можем ими распоряжаться; как реально выпускаем вещи и как можем с учетом имеющихся ресурсов – все это интересует при моделировании потоков работ.
Кроме того, когда вы моделируете потоки работ или используете модель для управления работами на предприятии, стоит помнить, что на операционного менеджера часто будут давить с целью ускорить выпуск. Это происходит потому, что из всех исполнителей роли менеджера именно операционный менеджер находится ближе к конечному результату, те отвечает за скорость до результата. Поэтому все косяки в стратегии, архитектуре и проекте организации обязательно проявятся при эксплуатации конвейера. И очень легко и удобно свалить всю ответственность за недостижение результата на операционного менеджера: плохо постарался, не включил режим форсажа[2]. Это не так: надо разбираться в причинах проблем, проводить исследование-расследование, как делают при авиакатастрофах. Модель потоков работ поможет вам быстрее выявить место, где возникла проблема, а значит – быстрее найти причину, по которой параметры прохода/выпуска отклоняются от желаемых или запланированных. Ошибки, допущенные при выборе стратегии или проектировании предприятия, нельзя исправить при помощи методов операционного менеджмента. Такое исправление ошибок тоже находится вне поля внимания операционного менеджера.
Сложные модели потоков работ нужны предприятиям, которые до этого росли в 2-3 раза в год, а потом перестали, и дальнейшее улучшение продукта или методов продвижения продукта не помогает. На стадии поиска бизнес-модели и продукта, который можно продавать с выгодой (Product-Market Fit), достаточно простых методов управления работами, которые вы уже знаете или научились применять после изучения первых разделов кусочка про работы. Продвинутые модели вам просто не нужны, фокус вашего внимания должен быть на исполнении других ролей.
Для составления модели потоков работ потребуется провести с командой предварительную подготовку: описать, зачем моделируем и что хотим получить на выходе. Затем потребуется описать граф создателей (принципиальную модель предприятия) с перечислением основных методов и ролей на предприятии. Также нужно будет получить описание физических объектов (исполнителей ролей), того, как они организованы в модули (подразделения) и как передается вещь и её описания от одного оргзвена к другому (путешествие вещи, её части или её описаний по конвейеру). Этим сейчас и займёмся.
Подробнее об этом в руководствах «Системное мышление» и «Методология». В рамках сессий рабочего развития по применению данного руководства вы можете получить первую версию графа создателей и первую версию описания методов. Эти первые версии моделей надо будет дорабатывать, чтобы систематически извлекать пользу от наличия моделей. ↩︎
https://tenchat.ru/media/1455022-vklyuchay-rezhim-forsazha ↩︎