[Из песочницы] Кошка сдохла, хвост облез
Кошка сдохла, хвост облез — кто слово скажет, тот ее и съест. Все знают эту детскую считалочку.
Но сегодня не о считалочках, а о системном мышлении и его применении для понимания бизнес-процессов предприятия.
Мне, как программисту и ИТ-директору, часто приходилось бывать на различных совещаниях руководителей, оперативках, стратегических сессиях топ-менеджмента и т.д.
Там все чего-то говорят, спорят, ругаются, предлагают свои и поносят чужие идеи, нападают и защищаются, плачут и смеются. Смотрится забавно, иногда страшно, в большинстве случаев скучно, но, главное, почти всегда — безрезультатно.
Цель совещаний, как правило — принятие решений по каким-то вопросам: оперативным, тактическим, стратегическим. Решения — это результаты, продукты совещания.
Но вот незадача — в большинстве случаев решений нет вообще, просто потрепались, помитинговали, вылили желчь и разошлись. Если же решения и приняты, то они обычно низкого качества.
Что интересно — в момент принятия решения на совещании оно кажется отличным. Понимание того, что решение — отстой, приходит после. Иногда сразу после собрания, в курилке например, иногда в момент объявления решения команде, иногда при составлении плана реализации, но почти всегда такой момент наступает. Почему решение кажется отличным на совещании, стало понятно довольно быстро. Тут работают три сценария.
Первый сценарий
Если совещание ограничено во времени, и модератор не спит, то цель принятия решения — успеть принять решение. Это критерий успеха — успел или нет. Качество решения, даже его нормальное обсуждение не входят в повестку. Решение принято — уфф, не зря мы называемся руководителями, мы сделали свою работу. Да еще так быстро. Некоторые даже прием такой применяют для ускорения — проводить совещания стоя. Раньше я думал, что это специфика нашей компании, оказалось — нет, даже кто-то из новоиспеченных губернаторов такой прием использует.
Второй сценарий
Если совещание по времени не ограничено, то цель принятия решения — чтобы это совещание побыстрее закончилось. Все хотят вернуться в свою зону комфорта — в кабинет, или домой, а часами сидеть и жевать сопли никто не хочет. В такой ситуации сойдет решение любого качества, лишь бы услышать заветное «друзья, мы отлично поработали, приняли решение, всем спасибо». А дальше хоть трава не расти.
Третий сценарий
Мозг человека так устроен, что очень ценит свои выдумки. Если руководителю, имеющему значительный вес на данном совещании, пришло в голову решение, то он с высокой вероятностью от него уже не откажется — просто потому, что он его придумал. Качество решения также не важно, главное — его придумал я. Есть множество приемов, как такую ситуацию преодолевать — адвокат дьявола, метод Чингисхана, управляемый мозговой штурм и т.д., о них расскажу в другой раз.
Во всех сценариях происходит одно и то же — подмена результата суррогатом. Качественное, продуманное решение — это продукт. Факт принятия решения — это суррогат.
Массу примеров суррогата вы можете увидеть вокруг — и в вашей компании, и в государственном управлении. Обычно суррогаты начинаются с фраз «сформирована дорожная карта», «намечены шаги», «найдены точки соприкосновения», «принято решение выработать решение» и т.д.
Я решил использовать такое положение вещей в свою пользу. Программистский разум понимал, что выход есть, и он несложный. К тому же, если найти правильный подход, то его можно использовать как карьерный стероид — ключевое преимущество по сравнению с коллегами-руководителями.
Фрейморком, наиболее подходящим к такой ситуации, мне показалось системное мышление. В двух словах поясню. Системное мышление — это абстрактная философия, рассматривающая мир, во всех его проявлениях, и бизнес в частности, как системы — сложные совокупности людей, процессов, отношений (формальных и неформальных), явных и скрытых лидеров, материальных объектов, информационных систем, клиентов, поставщиков, оборудования, и т.д., до бесконечности.
Если перед вами все элементы, вы их знаете, или даже видите ¬– например, собрали все это в одном месте — то перед вами не система, а набор элементов. Просто куча деталей.
Как из этой кучи сделать систему? Правильно, ее надо включить — запустить в работу.
Это хорошо понимают программисты, или инженеры. Вот программный код, вот компьютер или сервер, вот входные данные для обработки. Нажимаешь ВКЛ — система заработала. Ну или не заработала, если в ней есть ошибка.
В системах, состоящих из людей, обычно все наоборот, и это отличие — ключевое. Системы из людей работали до вас, и будут работать после вас. Но не будут работать при вас, в вашем присутствии. Собственно, в вашем присутствии они перестают быть системами, и снова превращаются в набор элементов. Возвращаясь к примеру выше, когда вы собрали все и всех элементов системы в одном месте. Что вы сделали? Правильно, вы выключили систему.
Чем отличается система во включенном и выключенном состояниях? Люди вроде те же, должности те же, процессы те же, руководитель тот же — все на месте. Отличие в свойствах системы, которые проявляют себя только при ее «включении», т.е. когда система работает. Примеры таких свойств систем — повсюду, вы их найдете без труда.
Телевизор без электричества — выключенная система, которая не демонстрирует нам главного своего свойства — показывать изображение. Включаете телевизор — увидите изображение, свойство проявится. Плеснете на работающий телевизор воды — увидите новое свойство системы, о котором, возможно, и не подозревали.
Такие свойства системы называются эмерджентными, или возникающими.
Возникают они, когда из набора элементов собирается и включается система. Важны оба условия — и собирается, и включается. В нашем случае — когда не выключается.
Если задача — понять систему, чтобы впоследствии ее изменить, то решение простое — наблюдать за ней, не выключая.
Итак, фреймворк «Системное мышление» говорит мне — наблюдай систему в действии, пойми ее свойства, особенно эмерджентные, и найдешь точку приложения силы для улучшения этой системы.
Выключать совещания я, разумеется, не мог и не собирался. Но и не наблюдал, потому что был частью системы, т.к. активно участвовал в совещании. Ключевой подход фреймворка, дающий понимание системы — наблюдать ее, а не участвовать в ней.
Я подумал — как именно я участвую в системе совещаний и принятия решений? Ответ пришел, откуда не ждали — из фильма «Бойцовский клуб». Есть там сцена, в которой обсуждаются отличия групп поддержки (алкоголиков, больных раком и т.д.) от обычного общения. И звучит ключевая фраза: «когда люди думают, что ты умираешь, тебя серьёзно слушают. А не только ждут своей очереди заговорить».
Мое участие в совещаниях длилось непрерывно, а не только когда я что-то говорил — потому что я постоянно ждал своей очереди заговорить. Я ждал, когда до меня дойдет очередь что-то сказать — свой вариант решения, свое мнение о чужом решении, «ну скажи хоть что-нибудь».
Ожидание своей очереди заговорить заставляло не столько слушать и вникать, сколько на ходу придумывать ответ, аргументы и контраргументы. Времени и ресурсов мозга просто не оставалось на продуктивное размышление над решением проблемы.
Чтобы все-таки перейти к наблюдению, я придумал для себя простой прием — молчать. Сознательно, бескомпромиссно и, главное, с разрешения начальства.
Внедрить молчание сразу и для всех совещаний нельзя — просто не поймут, и вместо карьерного стероида получится карьерный яд. Поэтому я внедрял молчание постепенно.
Есть такая категория — проблемные совещания, когда руководители собираются, чтобы обсудить не очень важную, или еще не наступившую проблему. Именно с таких я и начал.
Когда до меня доходила очередь, я говорил: «я пока послушаю, а свое мнение выскажу чуть после совещания, по электронной почте». Как вариант — на следующем совещании по этой же теме. Руководитель удивился, но согласился, и я стал молчать и внимательно слушать.
Обычное напряжение ожидания как рукой сняло. Предмет обсуждения — проблема — стала мне по-настоящему интересна. Мнения людей перестали восприниматься в штыки. Когда знаешь, что имеешь право вообще ничего не говорить, не аргументировать, не нападать и не защищаться, начинаешь просто слушать и вникать, собирать информацию.
Ключевое условие — в обещанный срок, после совещания, действительно нужно что-то написать или сказать. Но оказалось, что это совсем несложно, даже интересно. Сами знаете, как мозг программиста любит решать задачи по изменению систем, а бизнес — это и есть система, с теми же законами, что и информационная система.
Дальше стало интереснее. Решения, которые я формулировал после совещаний, были на порядок более качественными, продуманными, учитывающими реалии, ресурсы и возможности компании. Это не потому, что я такой молодец, а потому, что я принимал решения в правильном месте и в правильное время.
Разумеется, руководитель заметил качество предложенных решений. Особенно после их реализации, которую я зачастую брал на себя. Он понял, что это — результат молчания на совещаниях, и стал мое молчание поддерживать, иногда даже настоятельно рекомендовал мне молчать.
Так было даже на совещаниях, где присутствовали только я и он. Руководитель рассказывал проблему, смотрел на меня, вспоминал и говорил — «а, ты же сразу не ответишь, жду письма».
Такой подход я стал использовать все чаще, и вылезла одна проблема. Коллеги, которые заметили мое «особое» положение на совещаниях, стали саботировать совещания. Когда спрашивали их мнение, они говорили: «а чего говорить, вот он уйдет и придумает решение, я-то здесь зачем».
Нельзя было оставить место для саботажа, потому что коллеги-руководители — носители ценной информации о проблемах бизнес-процессов. Собирать такую информацию самостоятельно для меня было бы слишком затратно, и весь эффект сошел бы на нет.
Поэтому пришлось балансировать между молчанием и троллингом. Если я видел, что совещание и его проблема — не существенны, не играют большой роли для бизнеса — то я не молчал, а говорил, притом больше всех. Троллил коллег, провоцировал их (в хорошем смысле) на раскрытие всех знаний о проблеме, ссорил и примирял, поддерживал и вдохновлял. В общем, делал все, чтобы они не думали, что я всегда молчу.
И этот прием сработал — на молчание перестали обращать внимание. Некоторые даже стали использовать в своих интересах — приносили свою проблему, получали электронное письмо с предлагаемым решением. Или само решение, если оно было в компетенции ИТ.
Так появился и сработал карьерный стероид — компетенции, возможности и сфера влияния ИТ в компании выросла. Раз ИТ может предлагать неИТшные решения — например, реинжиниринг бизнес-процессов, разработку систем мотивации, выбор и внедрение методик управления закупом, производством или проектами — то почему нет?
Конечно, в приеме «молчать на совещаниях» нет ничего нового — это просто практическая реализация фразеологизма «хорошая мысля приходит опосля». Но ведь работает, это ж главное.
