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

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

Я вел множество 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% результата» является прекрасной стратегией в начале, но тормозит или делает невозможным дальнейшее развитие;
— процессы, состоящие из нескольких элементов, как правило, более ценны для клиентов, чем каждая часть процесса по отдельности.