Системное мышление: подходы и техники развития

Основные тезисы прямого эфира с Константином  Тютюновым, директором департамента развития управленческих программ Русской Школы Управления. 

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

Системный подход очень помогает в хаосе, непостоянстве самой жизни — появляется четкая картинка и возможность предсказывать (конечно, не на 100%) будущие события. И, что самое важное, можно выстраивать работу больших объектов, создавать целые бизнесы. Без системного мышления, конечно, тоже получается, но не очень надежно. 

Свойства систем

Разберем несколько базовых свойств систем, которые в большинстве источников признаются правильными. 

1. Система состоит из элементов. 

2. Элементы должны взаимодействовать между собой. 

3. Вместе они в виде системы выполняют какую-то полезную функцию. Если что-то поменять в схеме взаимодействия, составе элементов, система начнет меняться, а также изменится ее основная функция. 

Системный подход обязательно нужен в менеджменте. Его можно использовать в процессном и проектном подходе, стратегическом менеджменте, оргпроектировании. Любая функциональная область в компании — финансы, персонал, маркетинг — при выходе на самый минимальный уровень управления нуждаются в системном подходе. 

Общие навыки системного подхода

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

Как определить границы процесса  

Задуматься над вопросом: какую цель/полезную функцию описываемый процесс должен выполнять? Например, если цель — продажа, то придется включить в систему и продавца, и прием денег, и отгрузку товара, потому что конечный результат дает цепочка. Но так получается слишком много данных, нужно уменьшить объем анализа и сделать целью конвертацию сделки из лида в собственно продажу. И с такой четко сформулированной целью окажется, что при конвертации необязательно получать деньги, отгружать товар. Значит, в действиях остается получить потребности клиента, провести презентацию и подсветить преимущества товара/услуги и дожать клиента до сделки. Это основные действия процесса, который требовалось описать. таким образом, были установлены границы процесса с набором действий для достижения цели всей системы. 

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

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

Процессное управление

Системный подход необходим для процессной деятельности. Альтернативой системному подходу с похожими проблемами является процессное управление. Недавно РБК PRO провела опрос среди 200 компаний, узнавая основной фактор успеха и провала проектов. И как ни странно, топовым фактором и успеха, и провала стал один и тот же — управление объемами проекта. То есть управление границами проекта, границами управляемой системы. 

В проектах часто начинают рассуждать об одном объеме работ, одних задачах, по ходу дела выясняется, что их можно дополнить или убрать лишние И при неумелом управлении элементами проект провалится (по крайней мере, так считают 40% опрошенных РБК PRO предпринимателей). 

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

Так, можно по штатному расписанию оценить, имеются ли все нужные сотрудники с требуемой квалификацией. Или провести аттестацию, оценить, способны ли они выполнять требуемые функции. Либо сделать аудит или нанять «тайного покупателя». Все три способа позволяют оценить, есть ли в компании нужный для выполнения работ персонал. Однако они подразумевают разные точки окончания проекта — банально календарные даты. Например, проверка штатного расписания выполняется быстрее всего. При проведении аттестации время добавляется и, кроме того, в проект добавляется объем работы по обучению персонала. В третьем случае учитывается не только время выполнения самого проекта, но и время запущенного периода работы «тайного покупателя»/аудита. Это довольно четко определяет точку завершения проекта через выбранные продукты и способы. 

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

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

Делегирование

Существует еще один прием определения границ проекта, который можно сделать на старте. Он похож на делегирование в общем менеджменте. 

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

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

Определение уровней системы 

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

Так часто происходит, когда предприниматели при обсуждении скачут между уровнями задач. В итоге в принятых решениях появляются неучтенные, противоречивые элементы. Чтобы этого не случалось, нужно тренировать навык разделения системы на уровни. 

Как тренировать навык разделения на уровни

Детализация уровней «вниз». Система всегда имеет большой масштаб, поэтому второй способ упростить для себя анализ и проектирование — разложить ее на уровни, спускаясь ниже и ниже. И детализация отдельных элементов помогает обсуждать элементы, важные для конкретной задачи. Здесь тренировка проста: возьмите отдельный рабочий вопрос, определите заложенную в него систему и ее полезную функцию (например, процесс продаж или процесс техподдержки специалистов) и спуститесь на уровень ниже, детализируйте пошагово мини-систему. Так тренируется навык выделения двух уровней в системах. 

Такую детализацию можно вести и дальше, «копать вглубь». Некая официальная норма в классическом процессном подходе позволяет выделить минимум 4 бизнес-процесса в компании. От больших до конкретных операций, которые выполняют конкретные люди. На больших уровнях анализируется поток создания ценности, а на нижнем, четвертом, уровне — то, что должны делать специалисты. Уровни управления компании разделяют на стратегический, тактический и операционный. 

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

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

Детализация уровней «вверх». Еще один полезный навык— уходить на уровень выше, определять не только границы проекта, но и цели, границы для нижележащих уровней. Для этого нужно выделить вопрос (в нем выделить три уровня), определить подсистему и надсистему. 

Что делать с разными взглядами на систему

Кроме определения границ, уровней, с точки зрения неудачи проекта очень важно учитывать ошибки с заинтересованными сторонами. Говоря о системе, можно в ней выделять элементы, выделять свойства, и в каждый раз по-другому. Маркетолог, производственник или финансист видят систему по-разному. Но часто они вместе решают какой-то вопрос, требуя от нее противоречивых заданий. И задача руководителя — спроектировать решение так, чтобы удовлетворить всех. Потому что все правы со своей точки зрения. 

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

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

Как тренировать этот навык 

Опишите его с точки зрения клиента (поиск, сама покупка) и одновременно напишите то же самое с точки зрения исполнителя-продажника. И, в-третьих, описывайте процесс с точки зрения владельца компании (он может к процессу продаж предъявить свои ожидания). В такой таблице, составленной из многих этапов проекта, из многих (как минимум трех) точек зрения будет понятно, как оптимизировать процесс в целом. 

Так, в бережливом производстве описание процесса с точки зрения клиента — это классика. Также как описание того, что должен выполнить клиент и исполнитель для получения результата. Ведь часто руководитель перекладывает часть забот на клиента, и последнему не нравится взаимодействие с компанией. Поэтому в маркетинге сейчас в тренде customer journey map — описание процесса с точки зрения клиента, но так, чтобы компания могла в него вмешиваться, улучшать. Само описание процесса неплохо тренирует навыки определения ролей, понимания нужд этих ролей, удержания последовательности поведения в каждой роли, системного мышления. 

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

Принимать системное решение в одиночку сложно. Общая терминология в команде, общее мышление, системное проектирование — это еще одна область, которую стоит тренировать. 

Следите за нашими обновлениями: