IMG_0802

Введение в управление, или что делают управляющие

Что лучше — отвертка или молоток? Что более эффективно — сварка или бетонирование? Что надо использовать — сталь или пластмассу? Думаю, очевидно — без контекста это совершенно идиотские вопросы. Вместе с тем, большинство дискуссий на тему управления ведутся именно так — вне контекста конкретной компании, и даже без понимания какие задачи решает та или иная управленческая технология. Чтобы предотвратить кипение го…н возможное недопонимание, я хотел бы изложить свое, очень странное, понимание задач управления. Тема сложная, поэтому зарезервируйте полчаса на вдумчиво прочесть, разобраться, подумать над примерами.

Мир вокруг удивителен — он полон систем. Ежедневно и ежечасно они возникают, живут, работают, взаимодействуют и умирают вокруг нас. Сам человек является системой, и семья является системой, и компания в которой ты работаешь — тоже система. Поскольку компания тоже является системой — то в ней действуют системные законы, она поддается методам системного анализа и даже — системной инженерии. Читать книжки — это тяжелая работа, поэтому я не надеюсь что все кинутся читать Джерри — не все на это способны, да. Поэтому проведу минимальный ликбез сам (Джерри несомненно лучше и полнее, и я тут временами безумно упрощаю практически искажая, так что лучше читать его, ага).

Что такое система? Система — это набор элементов, образующих функциональное единство для достижения цели. Чтоб не лезть в науку, рассмотрим бытовой пример — упрощенная система «кофейня».

Untitled

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

Система существует для создания Ценности. Поэтому в ее основе лежит набор функций, которые, выполняясь последовательно и\или параллельно, приводят к возникновению Ценности. Эти функции называются «цепочка работ», «поток», или «цепочка создания ценности». Очень часто эти функции просты как дерево — например, прилавок, с которого забирают готовый кофе. Эта функция состоит из одного единственного элемента «прилавок», и надо обладать недюжинным талантом чтоб умудриться ее сломать. А вот функция «сварить кофе» весьма сложна — в ней задействованы аж три элемента, и сбой в любом из них ломает функцию: кофе дрянь, бариста не умеет варить кофе, или машина сломалась — все, цепочка встала.

System Thinking Basics.001

 

 

 

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

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

Как отличить хорошего управленца от плохого управленца? В общем-то также, как хорошего software architect — по количеству проблем, задавленных еще на этапе проектирования организации, [несмотря на все давление ситуации, требующее свести все к code-and-fix].

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

У плохого управленца ж…па в дыму, глаза выпучены, и он носится кругами по кофейне, потому что кассир подрался с кастомером, бариста не вышел на работу, машина сломалась, а кофе кончился. Какие технологии ему нужны — он не знает, и знать не может. Он повторяет как мантру — «нехрен тут умничать, надо работать!..». Но зато движуха эта очень круто выглядит, практически как сражение космодесанта с орками.

Быть хорошим управленцем сложно. По счастью, так же, как и в software development, есть библиотеки решений, которые существенно помогают. Про это — скоро напишу, но вначале надо разобраться с парой очень важный понятий.

Еще раз:

  • Мир вокруг — это совокупность систем. Системы взаимодействуют между собой, и часто большой системе нужны меньше системы для выполнения тех или иных ее функций. Наиболее частый способ организационного оформления функции — это компания или отдел (в большой компании).
  • Компания — это система. У нее есть тоже цель (Ценность, которую она создает) и итоговая метрика для этой цели, у нее есть поток и функциональное единство, и в ней тоже есть оптимальное и неоптимальное состояние.
  •  Управленец — это системный инженер. В идеале он умеет проектировать системы, и обладает прикладными навыками чтоб потом воплотить свои «голубые листы» в жизнь.

Домашнее задание:

  • Попробуйте определить Цель/Ценность и итоговую метрику для:
    1. Золотого рудника.
    2. Молокозавода.
    3. Автосервиса.
    4. Адвокатского бюро.
    5. Районной поликлиники.
    6. Компании сотовой связи.
    7. Интернет-провайдера.
    8. [Если не будет получаться отжать в одну — ок, но постарайтесь оставить как можно меньше].
  • Проанализируйте городской транспорт как систему:
    1. Какова его цель? Какую Ценность он приносит людям?
    2. Как ее мерять?
    3. Как выглядит оптимальное состояние?
    4. Какие функции нужны для этого?
    5. Как выглядит поток?
    6. Каковы его элементы?
    7. Где бы ты ожидал проблем в этой системе? Как бы их исправлял?
    8. [Анализ можно опубликовать в комментах — обещаю ответить на вопросы и ревью каждого опубликованного]

Литература по теме:

Еще на эту тему:

Введение в управление, или что делают управляющие: 11 комментариев

  1. привет Денис,
    >>Как отличить хорошего управленца от плохого управленца? В общем-то также, как хорошего software architect — по количеству проблем, задавленных еще на этапе проектирования организации, [несмотря на все давление ситуации, требующее свести все к code-and-fix].

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

  2. Метрика «сделано\не сделано» — лучше чем никакой метрики.
    Но она постфактум, а это значит, что проект делается голой силой и героизмом.
    Не запороть на этапе проектирования достаточно легко:
    1. Прикинь сценарий, который должен выполниться на проекте (примерно как сценарий для кино — только сценарий проекта). Уже на этом этапе станет ясно, что многое придумано неоптимально и требует переделки —
    (очень похоже на проектирование софта: пробуешь пройти в голове сценарий использования на своем софте и обнаруживаешь что кнопки ОК нет, что фильтры забыли, а они понадобятся, что одновременно запустить отчет может 10000 пользователей и т.д.)
    2. Прикинь, что может сбить исполнение сценария проекта. Тщательно уничтожь причины явлений, которе могут сбить исполнение сценария. Там, где не можешь уничтожить — подложи соломки. Там, где нельзя подложить соломки — приготовь шину и гипс.
    3. Избегай плохих практик и следуй хорошим — соблюдай fundamentals (обратно как с софтом — имей смок тест, не пиши сильно связанный код, не создавай суперклассов, аккуратно дели на слои и т.д.)
    Вот так, если коротко.

    1. как не запороть таки представляю =) вот чего пока не представляю, это как измерить и сравнить эффективность работы архитекторов систем: архитектор Вася дубасит лучше, его дизайн системы «давит N проблем в зародыше», а дизайн архитектора Пети всего 0.8*N проблем.
      Я скорее про такое спрашиваю.

      1. Имхо, ты никак не померяешь количество проблем задавленных в зародыше.
        Но ты можешь померять следование хорошим или плохим практикам, которые давят проблемы или создают их (примерно как fxcop по коду).
        Конечно, это будет работать только для известного набора проблем и предотвращающих их практик. Но и это думаю лучше чем ничего.

      2. Я понял, как померять.
        Смотри на итоговую метрику — «доступность сервиса».
        Если сервис доступен 99% времени и скорость обслуживания приемлемая — значит PotentialProblemPrevented == PotentialProblemsOustedOut.

  3. 1. Основная ценность городского транспорта — перевозка пассажиров из точек проживания к точкам работы и досуга и обратно. Развитая система городского транспорта снижает плотность расселения людей, повышая комфортность городской жизни.
    2. 1) Количество перевезенных пассажиров за период 2) Время поездки из контрольных точек к другим контрольным точкам. 3) Количество перевезенных пассажиров относительно пользующихся личными авто
    3. Весь транспорт ходит ровно по расписанию, при этом идеально покрывает потребности пассажиров, т.е. нет такого пассажира, который бы жил там/ехал туда где не ходит транспорт, при этом наполнение транспорта идеально сбалансировано, т.е. нет давок и пустых автобусов.
    4. Расчет логистики и аналитика, готовность к изменениям маршрутов/интенсивности, информирование людей об этом, поддержание парка машин в рабочем состоянии с запасом, + кадры, юристы, страховщики, финансисты и т.п.
    5. Водитель выезжает из точки А в точку Б вовремя, при этом вовремя прибывает на контрольные точки и обслуживает необходимое число пассажиров.
    6. Трезвый водитель, исправный транспорт, отлаженная логистика.
    7. Проблемы с любым из элементов в п.4. Чаще всего будут проблемы с логистикой, т.к. очень трудно сбалансировать маршруты под пассажиропоток. При этом транспорт несет социальную функцию — нужно пускать маршруты даже туда, где нет людей, иначе они там не поселятся. Социальная функция как паровоз потянет за собой финансовую проблему, что потребует поддержки со стороны муниципалитета. Поэтому транспорт очень редко бывает полноценным коммерческим предприятием.

    1. 1. Основная ценность городского транспорта — перевозка пассажиров из точек проживания к точкам работы и досуга и обратно. Развитая система городского транспорта снижает плотность расселения людей, повышая комфортность городской жизни.
      Вот это очень точно, это прекрасно замечено.
      2. 1) Количество перевезенных пассажиров за период 2) Время поездки из контрольных точек к другим контрольным точкам. 3) Количество перевезенных пассажиров относительно пользующихся личными авто
      Вообще прекрасно! Именно перевезенных пассажиров, а не проданных билетов 🙂 по пункту 2) — можно упростить: нам достаточно видеть, что длина поездки не возрастает — тренд: плоский, вверх, вниз. 3) уже лишнее, имхо.
      3. Весь транспорт ходит ровно по расписанию, при этом идеально покрывает потребности пассажиров, т.е. нет такого пассажира, который бы жил там/ехал туда где не ходит транспорт, при этом наполнение транспорта идеально сбалансировано, т.е. нет давок и пустых автобусов.
      Это можно выразить двумя переменными:
      а) % наполненность салона (оптимально — 80%)
      б) % соответствие расписанию.
      Я бы добавил разве что еще:
      с) время ожидания

      4. Расчет логистики и аналитика, готовность к изменениям маршрутов/интенсивности, информирование людей об этом, поддержание парка машин в рабочем состоянии с запасом, + кадры, юристы, страховщики, финансисты и т.п.
      Вот тут не совсем верно. Попробуй выстроить это в цепочку: Сначала А делает Х, из этого Б делает Y… Из этого получится поток. После этого 5 6 7 заиграют неожиданными красками 🙂 Иначе получается оргструктурное мышление, которое быстро приводит к возникновению департаментского мышления, и поток начинает сбоить и требовать ручного пропихивния.
      5. Водитель выезжает из точки А в точку Б вовремя, при этом вовремя прибывает на контрольные точки и обслуживает необходимое число пассажиров.
      6. Трезвый водитель, исправный транспорт, отлаженная логистика.
      7. Проблемы с любым из элементов в п.4. Чаще всего будут проблемы с логистикой, т.к. очень трудно сбалансировать маршруты под пассажиропоток. При этом транспорт несет социальную функцию — нужно пускать маршруты даже туда, где нет людей, иначе они там не поселятся. Социальная функция как паровоз потянет за собой финансовую проблему, что потребует поддержки со стороны муниципалитета. Поэтому транспорт очень редко бывает полноценным коммерческим предприятием.
      Умозрительно — одна из главных проблем определена верно. А вот если пройтись по потоку — их найдется гораздо больше (и некоторые из них свойственны и нашему транспорту, именно из-за оргструктурного мышления кстати :))
      В целом — отличный анализ, так держать.

  4. Денис, можно уточнить, через сколько итераций последует один глобальный вывод?

  5. Молокозавод:
    1. Ценность — всегда свежая молочная продукция на прилавках магазинов, в том числе и детских продуктов.
    2. Мерить ценность можно количеством заявок из торговых точек. Время отклика на эти заявки (как быстро отгружается). Выполнение заявок в ассортименте, жирность, кефир, простокваша и т.д.
    3. Оптимальное состояние — отсутствие или минимальное количество испортившихся продуктов (не купили).
    Количество (вовремя) исполненных заявок в полном объеме и ассортименте.
    Всю продукцию вовремя забирает заказчик.
    4. Сначала заказчик размещает заявку, затем молокозавод вносит все это в график и говорит когда эта заявка будет исполнена (или другой вариант гворит что можете забирать, есть на складе), график передается в производство, производство следует графику без отклонений, получаем все вовремя (или развитие другого варианта заказчик забирает со склада, молокозавод пополняет запасы на складе).
    5. Поток выглядит так:
    Заявка-исполнение (вывоз со склада и пополнение)-логистика-прилавок-довольный покупатель
    6. Доступный и быстрый способ подачи заявки, быстрый ответ планировщика, производство качественного продукта, герметичная современная упаковка, которая сохранит свежесть на длительный период, с логистикой затрудняюсь, оптимальное расположение полки, что бы глаз покупателя сразу видел продукт.
    7. Проблемы могут встретиться на реализации графика (поломка оборудования или нежелание персонала подчиняться графику, а с помощью локальных улучшение выполнять какие то показатели по количеству), что в следствии приведет к задержке отгрузки. Отгрузка многим заказчикам сразу, парализует работу склада.

    P.S. прошу разобрать мою утрированную версию, отдаленную от жизни. Спасибо.

    1. Добрый день!
      Молокозавод — очень интересный пример, потому что в нем есть не только линейный поток, но и параллельно работающий «обслуживающий поток». Постараюсь сегодня разобрать.

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *