80 за 20 — как не надо оптимизировать процессы

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

    Началось все с простого замечания: две компании, работающие на одном рынке и имеющие одинаковую численность персонала, могут иметь обороты и прибыль, отличающиеся на порядок. Почему так происходит, если, по сути своей, они делают одну и ту же работу? Иногда основное отличие заключаются в том, что кто-то является дочкой крупной госкомпании или умеет хорошо выигрывать тендеры, но, как мне кажется, это только часть объяснения.

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

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

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

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

    Если на любом уровне происходит непредвиденная ситуация, она эскалируется вверх по цепочке заказчиков до уровня, где будет возможна ее обработка. Например, новый сотрудник в отделе продаж, на которого переложили обязанность проверки формальной корректности поступающих запросов, обнаружил, что заказ сформулирован некорректно (продукция с таким наименованием отсутствует). Он сообщает об этом главе отдела, курирующему его работу. Глава отдела может обнаружить, что имеется ввиду не товар с наименованием WSX012, а WSXO12 (клиенты всегда путают букву O с нулём), вручную скорректировать текст заказа и вернуть его на повторную проверку. Или он может подтвердить, что запрос составлен некорректно и вернуть задачу с ошибкой на верхний уровень, с которого информация попадет исходному клиенту, который уже будет решать, как именно запрос должен быть переформулирован.

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

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

    В подавляющем большинстве случаев недовольство заказчиков возникает по одной из двух причин:
    — задержки во времени. Результат не получен или получен за время, не удовлетворяющее заказчика;
    — результат не соответствует базовым ожиданиям клиента (хотел A, получил B), или существуют проблемы с качеством исполнения.

    Одни и те же причины встречаются на всех уровнях организации: коллега просрочил возложенную на него задачу, еще и накосячив в процессе; отдел закупок три месяца не мог закупить новый принтер, а когда закупил – он оказался черно-белым, а не цветным; компания неделю не могла выслать коммерческое предложение, а когда сделала – в нем не оказалось того, что действительно просили.

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

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

    Данный способ представления процессов имеет много аналогий с процессом программирования в целом и его базовыми концепциями (такими как инкапсуляция), очень удобен и имеет много полезных применений. Например, можно, используя несколько идеально работающих «черных ящиков», как из кубиков Lego, конструировать новый процесс, который позволит заработать/сэкономить компании еще немного денег. Сравнивая кубики между собой, можно принимать управленческие решения: если кубик внутри компании работает не эффективно по сравнению с аналогами – можно оптимизировать его или просто выкинуть, решая задачу другим способом или вынося ее на аутсорс. Однако, как показывает практика, даже первый вариант — конструирование новых процессов из старых кубиков — плохо работает на практике, и дело отнюдь не в нежелании меняться.
    Рассмотрим ситуацию: вы обратили внимание, что после покупки услуги A иногда клиенты возвращаются и докупают услуги B и C. Вы решаете, что можно увеличить продажи B и C, делая предложение о покупке каждому, кто покупает A. Расчет стоимости предложения каждой услуги делается независимо разными командами, но в итоговом предложении клиенту они должны присутствовать все вместе – а значит, если какая-то из трех команд не успевает подготовить предложение в срок, то оставшиеся две ждут ее. Если опаздывают несколько команд – ждут последнюю из них. Во время пилотного проекта вы обнаруживаете, что шансы не уложиться в срок для каждой из команд – около 20%. А значит шансы, что никто не опоздает – 0.8^3=0.51, т.е. задержки сроков будут происходить в половине случаев. Предположим, что в одном из трех случаев подобная просрочка приводит к тому, что клиент уходит. Вы сравниваете потери от ухода клиента с возможной прибылью от продажи B и C, обнаруживаете, что первое больше, и решаете свернуть проект.

    Почему это произошло? Потому что когда-то давно, в момент создания кубика, было принято решение «20% усилий – 80% результата». Тогда это выглядело простым и правильным решением – не известно, пойдут ли вообще продажи каждой из услуг, а после того, как они пошли, нужно было как можно быстрее нарастить объем, концентрируясь только на «стандартных» клиентах и игнорируя любые отклонения. Однако эта стратегия привела к тому, что компания фактически закрыла для себя возможность для развития. Она не может эффективно осуществлять комплексные продажи, она не может делать кросс-продажи даже в тех случаях, когда они уместны. Из-за того, что каждый элемент большого процесса работает нестабильно как по качеству, так и по срокам, на его основе нельзя построить что-то новое.

    В ситуации выше был возможен и альтернативный вариант: в каждом отделе, готовившем предложение по своему продукту, был проведен анализ, который показал, что все богатство предлагаемых вариантов можно свести до пяти коробочных продуктов, каждый из которых подходит для своей целевой аудитории. Подготовка предложения каждому клиенту теперь сводится к замене наименования клиента в шапке документа (хотя и от этого можно отказаться), а просрочки и ошибки просто исчезли. Каждое предложение теперь состоит из тщательно подготовленных и проверенных частей, которые гораздо лучше, чем те, которые были раньше. Проект с кросс-продажами успешно запущен и приносит прибыль, планируется расширить его опыт на другие услуги компании. Более того – за счет оттачивания базовых процессов (продажи A, B и C по отдельности) компания получила лояльных клиентов, которые в курсе, с какими трудностями приходится сталкиваться при попытке купить то же самое у конкурентов. Самая приятная часть – на основе этого процесса можно сделать следующий, который принесет компании еще больше денег. Помимо работы с входящими заявками можно начать активные продажи потенциальным покупателям – благо подготовка предложения для каждого из них теперь является механическим процессом, который может быть выполнен за 5 минут.

    Предложенный пример очень схематичен и шаблонен, но он наглядно показывает ситуации, с которыми я сталкиваюсь каждый день. Обычно в компании есть небольшое число идеально работающих процессов и большое количество процессов, в которых, с той или иной периодичностью, возникают какие-то проблемы. Как правило, процессы второго типа включают в себя первые, но очень редко процесс, содержащий проблемы, используется в другом процессе. Идеально работающие процессы можно представить как кубики правильной формы, из которых можно сделать любой процесс, который только можно себе представить. Вторые – уродливые, деформированные кубики, которые можно прикрепить к чему-нибудь, но которые нельзя использовать для дальнейшего строительства конструкции. Не то, чтобы их не пытаются использовать, но любые попытки сделать это обычно заканчиваются провалами. Попытки использовать кубики, которые работают хорошо, встречаются примерно столь же часто, но процент удачных попыток несопоставимо выше. Получается своего рода эволюция в рамках одной компании, причем, чем больше идеально работающих кубиков есть в ее составе – тем шире поле для экспериментов и тем большую гибкость компания получает.
    Для оценки того, насколько процесс близок к идеалу, удобно использовать правило 6 сигм. В простом изложении его можно представить как оценку доли ошибок среди общего числа попыток выполнения какого-либо действия. Если в процессе возникает менее 6 ошибок на тысячу – процесс удовлетворяет условию 4 сигм, если меньше 2 на десять тысяч – правилу 5 сигм, меньше трех на миллион — 6 сигм. Для большинства процессов, с которыми я работал, я так и не смог достичь уровня 6 сигм, но этот уровень является хорошим ориентиром на будущее.

    Любопытное замечание: практически для всех ситуаций, которые я видел, новый процесс, состоящий из нескольких старых идеально работающих частей, приносит или экономит компании гораздо больше денег, чем базовые процессы, входящие в его состав по отдельности. Составные продукты и услуги, которые становятся возможными, часто имеют несопоставимо большую ценность для потребителей, чем каждый из элементов по отдельности. В то же время, даже улучшение базовых процессов само по себе может выделить вас по сравнению с конкурентами, делая вас «выбором по умолчанию». Я полагаю, что, во многих случаях, именно такой подход позволяет одним компаниям превосходить других, работая в изначально равных условиях.
    Впрочем, такой подход к конструированию и улучшению процессов не гарантирует успеха. Он имеет свои недостатки – например, не учитывает сопутствующие расходы. Да, те пользователи, которые уже согласились воспользоваться процессом, будут довольны – они получат предсказуемый результат точно в обещанный момент. Но это ничего не говорит о внутренней эффективности процесса – внутри черного ящика могут совершаться лишние действия, неэффективно расходоваться время и деньги, но внешний пользователь ничего не будет знать об этом, поскольку он работает с системой, внутрь которой заглянуть у него нет возможности. По этой причине удовлетворенность старых пользователей процесса не будет ничего значить, если рядом окажется конкурент, который сможет выполнять те же самые действия, но в два раза быстрее или по гораздо более низкой цене. Для решения таких проблем лучше воспользоваться другими методиками – например, «бережливым производством» или его аналогами в применении к сфере услуг.

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

    Подводя итоги:
    — представление компании в виде последовательности вложенных друг в друга черных ящиков является удобной абстракцией, дающей новый подход к анализу проблем компании;
    — идеально работающие черные ящики (обеспечивающие стабильный результат за заранее известное время) могут естественным образом быть включены в более сложные конструкции, что повышает их важность для компании;
    — подход «20% усилий – 80% результата» является прекрасной стратегией в начале, но тормозит или делает невозможным дальнейшее развитие;
    — процессы, состоящие из нескольких элементов, как правило, более ценны для клиентов, чем каждая часть процесса по отдельности.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 10

      0
      У вас ошибка в расчетах. Вот вы пишете:
      «Во время пилотного проекта вы обнаруживаете, что шансы не уложиться в срок для каждой из команд – около 20%. А значит шансы, что опоздает хоть кто-нибудь из них – 0.8^3=0.51»

      На самом деле — представляем себе что есть не три команды, а 1 команда которая как будто работает последовательно. Делает 3 проекта подряд.

      Какие будут исходы? Не будем утруждать себя формулой Бернулли:
      1 раз опоздали, 2 раза не опоздали. Причем таких ситуаций аж 3.
      2 раза опоздали, 1 раз не опоздали. Таких ситуаций аж 3.
      3 раза опоздали. Таких ситуаций 1.

      0.2 * 0.2 * 0.2 + 3 * 0.2 * 0.8 * 0.8 + 3 * 0.2 * 0.2 * 0.8 = 0.008 + 0.384 + 0.096 = 0.488

      Как я провел этот анализ. Давайте подумаем наоборот. «Хоть кто-нибудь опоздает — это все равно что от 1 отнять вероятность, что никто не опоздает».

      0.8 — вероятность что один не опоздает. Значит что все трое не опоздают — 0.8^3 = ваши 0.512. То есть 0.512 — это никто не опоздает. А что хоть кто-нибудь опоздает — это 0.488

      Статья очень хорошая. Помните, что теорию вероятностей не так просто опровергнуть как вам кажется. Спасибо, пишите еще.

        0
        Да, мой косяк. Изменил формулировку с «что опоздает хоть кто-нибудь из них» на «что никто не опоздает».
        Поскольку вероятность опоздания примерно равна вероятности успеть в срок, дальнейший текст править не стал)
        0
        Интересная статья, есть над чем подумать, что попробовать. Спасибо.
          0
          Хотя самому додуматься пока не получается — может Вы посоветуете:
          Как можно сделать коробочные (скомпилированные) решения там, где нужно очень детально вникать в проект, чтобы правильно рассчитать стоимость услуги? Например, ландшафтный дизайн или ремонт стен (строительство).
            0
            Ответ может быть не релевантен поскольку в этих областях не работал)
            Но обычно я начинаю с создания однозначных последовательностей действий на самом нижнем уровне, которые объединял в более общие на верхнем. Например, в случае с ремонтом стен, могу предложит следующий вариант — человек приезжая на объект заполняет подробную анкету однозначно описывающую необходимые действия (материал стены, площадь, несущая/не несущая, дефекты поверхности (выбор из закрытого списка), желаемый тип доработки, требования по шуму, требования по допустимому времени работы, ...). Т.е. отвечает на закрытый перечень вопросов. Затем на основе этих ответов однозначным образом рассчитывается стоимость услуги и время выполнения от которой не отступают в дальнейшем. Затем запускается шаблонная последовательность действий по вызову бригады и т.д.

            В данном случае элементарными операциями является сбор исчерпывающей информации (1) и расчет стоимости на ее основе (2). Человек собирающий данные (1) может не иметь квалификации для оценки стоимости работ, но это от него и не требуется. Его единственная функция на данном этапе — собрать корректную и исчерпывающую информацию. Затем он передает собранные данные (привозит в офис заполненные от руки бумажные бланки или отправляет через специальное приложение на планшете — не важно), на основе которых происходит оценка работ (2). Если данных не достаточно для однозначной оценки — либо не все данные собраны либо используемая модель оценки некорректна. Их можно будет улучшит в будущем в следующих итерациях взаимодействия с другими клиентами, когда появится статистика по тому насколько выставляемая клиенту стоимость работ отличается от реальной и почему так получилось.
              0
              C этим понятно, спасибо!
              А как быть в случае (этот посложнее), когда ещё нет той стены, с которой придётся работать — есть только 200-300 страниц чертежей, из которых реально нужно максимум 20. Но чтобы понять, какие именно нужны страницы и получить-таки необходимые данные (какие именно стены нужны и что именно с ними делать) — придётся перелопатить все 200-300 страниц?

              Это я не просто так спрашиваю. Меня действительно интересует как применить то, о чём Вы пишите, в реале. А то обычно получается, что «творчество специалистов» в «техническую рутину» переделать просто не получается — не понятно как. Видимо, нужно менять сам бизнес-подход, если хочется обрабатывать такие заказы быстрее и проще, но в каком направлении копать? Ведь не хочется тыкать пальцем в небо, оценивая заказ (а то потом придётся за этот воздух и делать всю работу)… но и «работать по старому» — означает тратить кучу ресурсов на изучение 200-300 страниц. Как работать по-современному, чтобы и себя не обидеть, и чтобы клиент не ушёл?
                0
                Прием который я видел на практике:
                — неквалифицированные сотрудники контролируют что пришла вся необходимая документация (должны прийти 5 документов — до тех пор, пока все они не пришли, готовый пакет документов не передается дальше в работу). Т.е. высококвалифицированные специалисты не тратят время на переписку с клиентом. Вся необходимая для работы информация у них в момент начала работы уже на руках.
                — сюда можно добавить разметку внутри документа — на какой странице какая информация. Обычно полезная инфа хранится в 2-3 основных разделах, остальные практически не влияют на принятие решения. Нужно чтобы эти разделы могли быстро найти.
                — Аналогично — если есть формальные признаки для отсеивания заведомо ненужно для анализа информации (например, «документ не содержит чертежей») — их нужно использовать для уменьшения количества поступающей к специалисту информации.

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

                Если пытаться сводить эти возможности к единому знаменателю:
                1. Составьте алгоритм выполнения задачи «в общем случае»
                2. те части, которые содержат однозначную последовательность действий — отдайте неквалифицированным сотрудникам или реализуйте в виде программы.
                3. Те части, которые «требуют творческого подхода» отдайте квалифицированным сотрудникам или попытайтесь опять выполнить пункт 1 — иногда «творческий подход» — это набор из 3-5 правил.
                  0
                  Если хотите обсудить тему подробней — можете в личку написать. Мне будет интересно посмотреть на проблемы за пределами моей текущей области деятельности (страхование) и понять — применимы ли там мои рекомендации на практике)
            0
            Занимательная статья. Спасибо!
              +1
              идеально работающие черные ящики (обеспечивающие стабильный результат за заранее известное время) могут естественным образом быть включены в более сложные конструкции, что повышает их важность для компании;

              Майк Ганцарз. Философия UNIX
              Маленькое прекрасно.
              — Пусть каждая программа делает одну вещь, но хорошо.

              Only users with full accounts can post comments. Log in, please.