Новогодний винегрет

«Система автоматизирована, но не управляема.
Потому что мы не знаем, что контролировать»
© Откровения менеджера

Как написал мне один знакомый менеджер, управление ходом проекта хорошо описано в творчестве Егора Летова: «всё идёт по плану → всё как у людей → всё летит к чертям → нечего терять».

В триединстве составляющих любого проекта «технология – управление – экономика» имеет смысл отдельно вспомнить про управление, которое далеко не исчерпывается рисованием в MS Project диаграммы Гантта. Проблемам управления посвящена эта статья.

1.  Основной состав блюда (проблемы управления бизнес-процессом)

Ожидания потребителя

Таким образом, возникает необходимость в построении модели деятельности организации, которая позволит:

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

Качество ингредиентов

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

• с помощью статического описания возможно распутывание только явных, наиболее грубых нестыковок бизнес-процессов;
• использование графических нотаций в чистом виде невозможно и требует переноса моделей процессов в прикладные системы;
• исследования поведения системы в динамике обычно не предусматривается, а значит и проверить адекватность модели существующей реальности не представляется возможным;
• построение модели ориентировано на формирование комплекта должностных инструкций (ну да, это, конечно, самое главное, за что мы, заказчики, платим деньги…).

То есть ситуация складывается как обычно: есть классическое знание и есть «облегчённое» знание, причём последнее занимает 99% рынка. Проблема только в одном: облегчённое знание не работает.

Между тем даже классический анализ с применением метода имитационного моделирования (ИМ) по Форрестеру ([1]) не даёт однозначного и простого ответа на все вопросы управления процессом, поскольку представляет из себя прямой прогон большого количества вариантов процесса при заданных вариантах изменения значения в узлах системы. То есть результаты мы видим: например, в 40% случаев производственный план в срок выполнен не будет, но что послужило причиной – требуется пошаговый ручной анализ. Если система большая, то трудозатраты аналитика растут в прогрессии. И самое главное, нет ответа на вопрос: а что и где менять?..

Зайдём с другой стороны: методика построения модели деятельности требует от нас адекватного отражения реальности. Следовательно, нам необходимо сравнить совокупность промежуточных и конечных результатов прогона модели с полевыми замерами этих результатов в анализируемой реальной системе. Сразу встаёт вопрос выбора показателей, результаты которых будем фиксировать, – мы не можем замерять всё подряд, замеры в реальной системе – это дорого. Значит мы сначала должны определить принцип отбора показателей по «важности».

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

Оптимальность (исключение простоев техники, персонала) обычно достигается на этапе планирования проекта, показатели загрузки персонала и техники получить достаточно просто, а вот обеспечить устойчивость… Дело в том, что исключение заторов, когда возникает «узкое место» и его начинают «расшивать», обычно добавляя туда дополнительные ресурсы, не объясняет причины – почему затор иногда возникает, а иногда нет, а также почему он возникает в разных проектах в разных местах. Дело в том, что для обеспечения устойчивости нам нужны совершенно другие показатели. Рассмотрим пример.

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

Таким образом, эффективность управления процессом заключается в переходе от показателей, связанных с результатом, к показателям, связанным с фактором. В сложных системах таких факторов может оказаться несколько.

Итак, «оптимальность» связана в большей степени со «статическими» факторами, которые действуют более-менее постоянно и учитываются на этапе разработки технологии производства. А вот «устойчивость» определяется способностью системы к возвращению к «норме» при отклонениях от технологии в результате переменно-действующих, «динамических» факторов эксцессов.

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

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

2.  Экзотическая заправка (проблемы управления персоналом)

Для раскрытия смысла этого выражения используется следующий пример:

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

*True and fair – первая запись правдивая и честная, а вторая тоже правдивая, но – нечестная 

Мораль: меньше доверяйте бумагам, больше работайте с людьми 

3. К столу!

[1]. Джей Форрестер «Основы кибернетики предприятия (индустриальная динамика)», М.: Прогресс, 1971.