Читать книгу: «Системный коучинг организаций. Организация под микроскопом. Вид изнутри», страница 2

Что мы называем проблемой

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что еще?

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

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

Вопрос номер два: «А почему он толком не знает, что у него есть?». Ответ: потому что данные в базе не точные!

Вопрос номер три: «А почему данные не точные?». Ответ: потому что их заносят с опозданием!

Вопрос номер четыре: «А почему их заносят с опозданием?». Ответ: потому что накладные складывают в папку и заносят в базу раз в неделю согласно регламенту.

Чем-то похоже на детскую «доставалку» «Купи слона», не правда ли?

И тогда вопрос номер пять: «А почему такой регламент?». Ответ: а потому что никто не говорил, что надо чаще!

Бинго! Корневая причина найдена, осталось поменять регламент.

Я уверен, что, во-первых, корневая причина всегда есть, во-вторых, очень часто это нечто, что раньше было обосновано и полезно. И это точно можно выяснить методом «пяти „почему“», но надо правильно формулировать первый вопрос. От него зависит все.

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

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

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

Правильно поставленный вопрос позволил просто ликвидировать ненужный бизнес-процесс вместе с этой капризной программой.

Все эти инструменты хороши, но не всесильны. Хороши, потому что просты, понятны и зачастую работают. А не всесильны, потому что подразумевают линейную зависимость проблемы от причин. Увы, жизнь намного сложнее. Часто причины вызывают друг друга, образуют длинные цепочки, причудливо переплетаются и в конце концов замыкаются сами на себя. Эти петли, да еще и с учетом временны́х задержек, прекрасно описал Питер Сенге в своей книге «Пятая дисциплина» [11]. Что делать? Для сложных неограниченных проблем – использовать системные подходы: те же системные архетипы, описанные Питером Сенге, или системное моделирование методом организационных расстановок.

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

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