Управление реальностью в бизнесе. Магия без мистики

Фраза «Хьюстон, у нас проблема» давно стала нарицательной. Иногда кажется, что основная часть рабочего времени руководителя посвящена разрешению проблем. Умные мысли из учебников – о том, что надо правильно устанавливать цели, планировать, налаживать контроль и настраивать мотивацию, – так и остаются умными мыслями из идеального мира. Никто не спорит – цели нужны, и планировать нужно, не говоря уже о мотивации. Но суровая реальность заваливает многих из нас кучей крупных и мелких неприятностей, последствия которых мы устраняем с утра до вечера. Есть в такой ситуации что-то неправильное.

Так что же такое проблема? Договоримся, что проблемой мы дальше будем называть некое рассогласование, разрыв между тем, чего мы хотим, и тем, что имеем. Или (если мы обладаем достаточной проактивностью и способны смотреть хоть чуть-чуть вперед) разрыв между тем, что мы имеем сейчас, и тем, что можем и хотим иметь в будущем. Тогда мы говорим скорее не о проблеме, а о возможности. Вообще-то я уверен, что наши проблемы и есть наши нереализованные возможности.

Что следует из этого простенького определения? Прежде всего, если проблема – это разрыв между желаемым и действительным, значит, есть желающий. Есть кто-то, кому не нравится положение вещей и кто хотел бы что-то поменять. Или просто поворчать… Или тихонечко погрустить в уголке… Запросто может оказаться, что всех остальных текущее положение вещей более-менее устраивает, а кто-то и вовсе считает, что все просто превосходно! Но для нашего «желающего» это не так. Надо бы рассмотреть ситуацию через призму его восприятия, и тут я оказываюсь в явном затруднении. Когда-то давно я объяснил бы это просто: есть факты, которые для «желающего», то есть для «обладателя проблемы», говорят о том, что все идет не так, как надо. Для него такие факты являются симптомами проблемы.

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

Наша персональная реальность

Удивительная штука – персональная реальность. Это следствие работы наших ментальных фильтров, которые убирают из поля нашего зрения примерно 98 процентов всего, что нас окружает, и изрядно искажают оставшиеся 2 процента. По сути, бóльшая часть так называемых фактов – просто мнения и суждения. Как говорят полицейские, «никто не врет так, как очевидец». Тем же, кто по-прежнему уверен, что «факты – упрямая вещь», я посоветовал бы прочитать рассказ Михаила Веллера «А вот те шиш» [1]. Но, так или иначе, есть нечто, заставляющее обладателя проблемы ее видеть, – какое-то видимое проявление. Часто это действительно факт. В конце концов, если чашка упала, разбилась и лежит на полу грудой осколков, это трудно назвать оптической иллюзией. Назовем это симптомом проблемы. Разные люди, видя один и тот же симптом, видят разные проблемы и решают их по-разному. А для некоторых это не симптом, а просто факт, за которым не стоит ни одной проблемы. Наверное, лучше всего описать это на примере.

Скажем, у моего гипотетического лучшего друга, Коли Васечкина, с которым мы дружим еще с детского садика и у которого дача рядом с моей, нет машины. Что из отсюда следует? Пока ничего.

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

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

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

А с точки зрения моей гипотетической жены, тут вообще нет проблемы, потому что ее это просто не волнует.

Один и тот же факт, что у Коли нет машины, является симптомом совершенно разных проблем в зависимости от субъекта – обладателя проблемы. Или вообще не является симптомом проблемы, потому что не указывает для данного человека на проблему. Факт превращается в симптом и начинает указывать на проблему только в мозгу обладателя проблемы.

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

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

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

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

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

Если данные мониторинга показывают IT-директору, что система хранения данных стоимостью 70 тысяч долларов чувствует себя плохо и через какое-то время выйдет из строя (вполне реальная ситуация, в которой я когда-то оказался), не надо прятать голову в песок и ждать, когда все сломается окончательно. Впрочем, идти к генеральному директору и объяснять, что требуется внезапно взять откуда-то кучу денег для профилактической замены какой-то непонятной железяки, которая может выйти из строя через неделю, а может благополучно проработать еще полгода, – тоже не самое лучшее решение.

Как сформулирована проблема? «Железяка может выйти из строя». Чья это проблема? В данной формулировке – IT-директора. Скорее всего, вместо денег он получит массу неприятных и совершенно бессмысленных вопросов вроде «где он был раньше», «почему этого нет в бюджете», «сколько она гарантированно проработает», «что можно поставить подешевле», «как без нее обойтись» и т. д.

А ведь больше всех от крушения системы хранения данных потеряет сам генеральный директор, у которого, кстати, есть все ресурсы для решения проблемы. Поэтому ее надо сформулировать так, чтобы она стала проблемой самого генерального, – например, как можно спокойнее сказать, что все в порядке и можно не волноваться. Но, по данным мониторинга, корпоративная управляющая система, без которой не принять на склад даже копеечный кабель, может выйти из строя. Когда? Кто ж его знает. Может, и завтра, но может, и полгода еще продержится, поэтому волноваться нечего. Не тратить же 70 тысяч долларов просто так. Да и срок поставки – от шести до восьми недель. Мы все понимаем, что если учетная система, завязанная на этой системе хранения данных, прекратит работу, то встанет вся фирма с оборотом около одного миллиона американских зеленых бумажек в день, но ведь пока ничего страшного не случилось? Петр Петрович сам в уме подсчитает, во что обойдется остановка фирмы с оборотом миллион долларов в день на шесть – восемь недель. И сам сделает правильные выводы. Потому что проблема сформулирована как «перспектива потерять 40—50 миллионов долларов» и обладатель проблемы теперь сам генеральный директор. Так оно и есть, ведь он потеряет больше всех, и хорошо бы помочь ему это осознать. пока пока

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

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

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

Диаграмма Исикавы

Можно детализировать факторы, пририсовывая стрелочки к стрелочкам факторов (получатся факторы второго, третьего порядка и т. д.). При этом крайне важно выявлять именно причины, а не вносить в диаграмму симптомы. Различить их не всегда просто, поэтому вот основное правило: симптом – это то, как я понимаю, что проблема есть и в чем она заключается, а причина – это то, из-за чего проблема возникает или сохраняется.

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

Диаграмма Исикавы, или fishbone, была придумана для повышения качества продукции японского автопрома и изначально имела ориентацию на производство. Поэтому были сгруппированы и выделены такие основные факторы: человек, методы работы, механизмы, материал, измерение (контроль) и окружающая среда. В английском варианте это men, method, machine, material, measurement и mother earth (environment), поэтому ее еще называют диаграммой 6М. Впрочем, встречаются и другие варианты предполагаемых основных факторов. Что до меня, то я вообще предпочитаю работать с чистого листа, не привязываясь к каким-то группам. Как известно, «невозможно навести порядок в пустой комнате». Попытка сперва нарисовать структуру, а потом загонять в нее факты выстраивает в голове лишние фильтры, и в результате что-то важное не втиснется в рамки структуры и будет не замечено или отброшено.

Мне доводилось использовать этот инструмент именно в такой, заранее не предопределенной, форме. Организация, где я работал, крупный ритейлер компьютерной и бытовой электроники, столкнулась с проблемой возврата неисправного товара. В те времена процедура выглядела следующим образом. Клиент, в соответствии с Законом о защите прав потребителей, возвращал товар непосредственно в магазин, где он его купил. Магазин ремонтировал товар, или менял его, или возвращал клиенту деньги, или брал паузу, чтобы разобраться в проблеме. В любом случае в оговоренные законом сроки претензию клиента должны были либо удовлетворить, либо обоснованно отклонить. Далее ритейлер отправлял этот товар производителю и через некоторое время получал или новый/отремонтированный товар, или деньги. Однако сроки ответа производителя не регулируются законом. Вершиной неторопливости были дилеры крупной американской корпорации, которые один раз отреагировали через 245 дней после получения претензии. Поскольку ассортимент ритейлера состоял из многих десятков тысяч наименований от многих сотен поставщиков, все это привело к тому, что где-то между ритейлером, дилерами и производителями болталось товара примерно на 2 миллиона долларов. Деньги, как известно, стоят денег, за них надо платить, например, проценты по банковским кредитам. Таким образом, вся эта катавасия обходилась организации как минимум в 200—300 тысяч долларов в год.

Генеральный директор и по совместительству владелец компании поставил задачу сократить эту сумму в десять раз. Разумеется, лучше всего было бы решать эту проблему в стиле ТРИЗ (Теории Решения Изобретательских Задач), устранив не причины возникновения проблемы, а проблему как таковую. Сделать это можно было, например, предложив поставщикам поставлять 1—2—3 процента товара сверх основного заказа бесплатно. Взамен ритейлер мог бы взять на себя все расходы по замене товара потребителю, отправляя металлолом просто в мусорную корзину. Не нужно было бы тратить силы и время на пересылку туда-сюда отдельных единиц товара, что экономило бы массу сил и средств. К сожалению, по ряду причин в те времена это было невозможно. Отмечу, что для единичных и уникальных товаров, а также для маленьких партий это невозможно до сих пор.

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

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

Проблема была сформулирована как разрыв между желаемыми для генерального директора 200 тысячами долларов в год и имеющимися 2 миллионами долларов в «зависшем» между ритейлером и поставщиками товаре. Обратите внимание: проблема была сформулирована в строгом соответствии с теорией проблемно-ориентированного подхода – как разрыв между желаемым и действительным для вполне конкретного человека.

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

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

Предположив, что мы выявили бóльшую часть причин, которые вызывают проблему, я соединил кластеры стрелками, и перед нами возникла диаграмма Исикавы. Я предложил распределить проценты между кластерами, чтобы в сумме они дали 100 процентов. Каждый сделал это по-своему, однако после усреднения и обсуждения мы получили согласованный результат. Одну цифру я помню до сих пор: было признано, что проблемы IT-системы составляют 17 процентов. Я напишу еще прописью: «семнадцать процентов». А вовсе не сто, как считалось раньше.

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