Как бизнесу сэкономить ресурсы на методологиях, которые не работают «из коробки» • ЦКП и статистики

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

Российские компании охотно берут готовые управленческие методологии, будь то KPI, OKR, ЦКП и статистики, Lean или Agile. Чаще всего их внедряют как свод правил, который достаточно аккуратно повторить, и гораздо реже как теорию, которую сначала нужно понять, проверить на своих условиях и доработать. Разница между этими подходами решает, получит ли компания работающий инструмент или дорогую имитацию.

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

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

Коротко о главном

• Самые дорогие ошибки в корпоративных продуктах обычно сидят не в интерфейсе, а в том, как устроена сама система учёта и контроля. Их цена размазана по десяткам отделов, поэтому в отчётах её не видно, хотя компания платит её каждый месяц.

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

• Это не ошибка одной организации, а распространённая привычка бизнеса обращаться с теорией как с готовым рецептом. Наука об организациях описывает эту привычку давно и подробно.

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

1. Введение и постановка проблемы

Об авторе и о том, зачем эта статья

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

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

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

Болезнь быстрых решений

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

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

Чем больше команда торопится, тем больше она платит за то, что торопилась вчера.

В 1992 году программист Уорд Каннингем сравнил поспешные технические решения с долгом, по которому растут проценты [1]. Сэкономил время сегодня, значит, завтра отдашь больше, и с каждым месяцем сумма будет расти. Метафора родилась в разработке, но к управленческим системам она подходит, пожалуй, даже лучше. Методологический долг копится так же, как технический, а обходится обычно дороже, потому что затрагивает не код, а мотивацию людей, их доверие к руководству и то, как они каждый день принимают решения.

В чём проблема

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

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

2. Почему методологии ломаются при переносе

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

Почему компании копируют чужие практики

Социологи Пол Ди Маджио и Уолтер Пауэлл в 1983 году показали, что в условиях неопределённости организации начинают копировать тех, кто кажется успешным [9]. Они назвали это миметическим изоморфизмом, но суть очень простая. Если непонятно, как правильно, проще сделать «как у лучших». Такое копирование снимает тревогу и даёт ощущение, что всё сделано по науке, но никак не гарантирует, что практика заработает в новой компании.

Эрик Абрахамсон описал похожий механизм и назвал его управленческой модой [10]. Методики расходятся волнами через консультантов, тренеров, конференции и деловые медиа, и решение внедрить что-то нередко зависит от того, насколько это сейчас популярно, а не от того, подходит ли это под задачи конкретного бизнеса.

Перевод вместо копирования

Исследователи скандинавской школы Барбара Чарнявска и Гуйе Севон предлагают смотреть на распространение управленческих идей как на перевод с одного языка на другой [11]. Попадая в новую организацию, идея обязательно меняется, и вопрос только в том, делают этот перевод осознанно, понимая исходный смысл, или он происходит сам собой. Стихийный перевод обычно сохраняет внешнюю форму, то есть термины, шаблоны и регламенты, но теряет то, ради чего всё это когда-то придумали.

Ричард Фейнман называл такое явление карго-культом [16]. Жители тихоокеанских островов после войны строили взлётные полосы из бамбука и вырезали наушники из кокосов, в точности повторяя всё, что видели у военных, но самолёты с грузом так и не прилетали. Ритуал скопировали, а механизм, ради которого он существовал, так и остался непонятым. С управленческими методиками происходит то же самое, когда копируют форму и забывают про смысл. Подробнее об этом явлении я писал в статье неэффективные менеджеры.

Культура и менталитет

Голландский исследователь Герт Хофстеде и его последователи показали, что одни и те же инструменты управления по-разному работают в разных культурах [12]. Для российской деловой среды исследователи обычно отмечают высокую дистанцию власти и сильное стремление избегать неопределённости. Я не считаю это оценкой или приговором, скорее это рабочее предположение, которое помогает заранее понять, как люди поведут себя с системой показателей.

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

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

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

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

Как измерение меняет поведение

Есть ещё одна группа идей, без которых разговор о показателях был бы неполным. Экономист Чарльз Гудхарт заметил закономерность, которую антрополог Мэрилин Стратерн позже сформулировала в виде знаменитой фразы «когда показатель становится целью, он перестаёт быть хорошим показателем» [3]. Сегодня её называют законом Гудхарта.

Социальный психолог Дональд Кэмпбелл добавил

Чем активнее цифру используют для важных решений, тем сильнее её искажают и тем сильнее портится сам процесс, который она должна отражать [7].

Стивен Керр написал известную статью о «безрассудстве награждать за А, надеясь на Б» [4], Эдвардс Деминг предлагал вообще отказаться от управления по числовым целям и заменить его лидерством [5], а историк Джерри Мюллер назвал перекос в сторону измерений «тиранией метрик» [8].

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

3. Исходная ситуация

Организация, которую здесь берем условно для образного примера и о которой буду говорить от первого лица ради удобства повествования, крупная, в ней десятки подразделений и больше тысячи сотрудников в корпоративных системах. До появления единого инструмента (своего сервиса) каждое подразделение годами считало свои показатели само, в Excel, Google-таблицах и прочих сторонних сервисах, по своим формулам и в своём ритме. Продажи вели таблицы звонков и встреч, бухгалтерия сводила объёмы из учётной системы, разработка смотрела метрики в трекере задач и т. д.. Снаружи всё выглядело вполне рабочим, ведь у каждого руководителя были цифры, и он по ним управлял.

Сложность была в том, что эти цифры видели только внутри самого подразделения, а для руководства компании они оставались чёрным ящиком. Проявлялось это сразу в нескольких вещах.

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

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

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

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

4. Как методологию перенесли в продукт

Чтобы получить эту прозрачность, в корпоративной платформе сделали модуль учёта эффективности. За основу взяли методологию «ценного конечного продукта» (ЦКП) и «статистик». Она довольно популярна в российской практике и обычно приходит в компании через бизнес-тренинги и консалтинг, причём часто сразу в виде готового шаблона. Логика у неё простая. У каждой должности есть свой ЦКП, работу измеряют статистиками, то есть числами, которые сотрудник раз в месяц вносит в систему, а от этих чисел зависит премия.

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

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

2. Вторая трудность в том, что формулы никуда не исчезли из таблиц и одновременно появились в продукте. Одну и ту же цифру считали в двух-трёх местах, и результаты не всегда совпадали.

3. Третья связана с тем, к чему привязали показатели. Их закрепили за техническим кодом бюджетной структуры в учётной системе, а этот код менялся при любых кадровых или структурных изменениях. Стоило компании что-то перестроить, и показатели просто отваливались от сотрудников.

4. Четвёртая трудность в том, что заполнять систему вручную обязали всех, от линейного сотрудника до директора департамента.

Что стояло за техническими проблемами

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

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

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

5. Как было устроено исследование

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

По итогам у нас получился набор материалов, и каждый отвечал на свой вопрос.

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

• Карта покрытия исследования показала, что мы знаем точно, что вероятно, а что пока остаётся предположением, какие подразделения и роли мы не охватили и как закрыть эти пробелы.

• Карты пути пользователя (User Journey Maps) описали опыт каждой роли по отдельности, то есть сотрудника, руководителя, администратора системы и топ-менеджмента.

• Карта опыта (Experience Map) показала, как опыт разных ролей накладывается друг на друга в течение месяца и где проблема одной роли становится проблемой другой.

• Схема сервиса (Service Blueprint) помогла увидеть, что происходит за сценой на каждом шаге, кто, где и что делает руками [2].

• Итоговые выводы связали корневые проблемы в цепочки причин и следствий и наметили следующие шаги.

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

6. Что показало исследование

6.1. Система никому не приносит пользы

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

6.2. Таблиц стало больше

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

6.3. Замкнутый круг порчи данных

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

1. У показателя нет точного описания того, что и как измерять, поэтому сотрудник вносит значение на глаз.

2. Если он ошибся, исправить можно только через поддержку, и это занимает один-два дня.

3. Руководитель не видит, что внёс сотрудник, поэтому никакой проверки нет.

4. Руководитель не доверяет данным и ведёт свою таблицу, а топ-менеджмент перепроверяет всё вручную.

5. Сотрудник видит, что его данные никто не использует, и в следующий раз вносит их ещё небрежнее.

Разорвать такой круг, улучшив одно звено, не получится. Удобная форма ввода не поможет, если сам показатель выбран неправильно, а автоматизация не поможет, если она собирает бесполезные числа. Исправлять нужно всю цепочку, и начинать нужно с основы, то есть с вопроса о том, какие данные мы вообще собираем и что они значат.

6.4. Один шаблон для очень разной работы

Методология статистик хорошо работает там, где результат естественно считается в штуках и рублях, как в продажах. Но значительная часть подразделений делает работу совсем другого рода, и это хорошо видно, если разложить её по видам.

6.5. Работа на показатель вместо работы на результат

Привязка показателей к премии дала ровно тот эффект, который предсказывает теория. В разработке сотрудники начали подстраивать работу под значение статистики и отказываться от дополнительных задач, чтобы не испортить себе показатель. Это в целом иллюстрирует законы Гудхарта и Кэмпбелла [3], [7] и мысли Керра [4]. Система платила за цифру в надежде получить результат, но получила людей, которые научились оптимизировать цифру. Важно понимать, что дело здесь скорее всего не в недобросовестности сотрудников, ибо каждый человек в такой системе стимулов повёл бы себя с большей вероятностью точно так же.

6.6. Ручной труд и слепая зона управления

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

В разработке нужные данные лежат в трекере задач у руководителя, поэтому сотрудник идёт к нему за цифрой, чтобы потом самому внести её в систему. Руководитель эту цифру прекрасно знает, но внести её за сотрудника не может.

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

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

6.7. Подразделения живут каждое само по себе

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

При этом в одном вопросе руководители (на моей практике) сошлись почти единогласно, им нужен понятный дашборд со светофором, планом и фактом, списком подчинённых и динамикой, и именно светофор получил почти максимальную оценку. Людям был нужен не контроль ради контроля, а картина, по которой можно управлять и быстро понимать, что происходит.

7. Чего не учли при переносе

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

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

8. Модель самоконтролирующейся системы

Текущая система была разомкнутым контуром, когда данные вводились, но не проверялись, не агрегировались и не стыковались между уровнями и отделами.

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

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

Сама модель состоит из шести уровней контроля по моей теории. Каждый следующий опирается на предыдущий, поэтому внедрять их можно поэтапно.

8.0 Основа. Результат сотрудника отдельно, финансовый учет отдельно

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

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

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

8.1 Карточка статистики как «живой контракт»

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

Блок А. Обязательные поля

Без этих полей показатель просто нельзя создать.

Блок Б. Поля самоконтроля

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

Коридор допустимых значений с минимумом и максимумом стоит задавать всем показателям без исключения, потому что на нём держится проверка при вводе. И отдельно нужна логика расчёта плана, ведь людям было непонятно не только как считать факт, но и откуда вообще берётся план.

Блок В. Справочные поля

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

Проверки при создании

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

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

8.2 Каскад

По вертикали

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

Допустим, руководитель отдела продаж ставит план на 60 млн рублей. Система смотрит на планы менеджеров и видит, что у первого стоит 20 млн, у второго тоже 20 млн, а у третьего 15 млн, то есть в сумме выходит 55 млн. Руководитель сразу получает предупреждение о том, что плану не хватает 5 млн, или примерно 8%.

Чтобы утвердить план, ему нужно выбрать одно из трёх действий.

• Можно снизить свой план до 55 млн;

• Можно распределить недостающие 5 млн между менеджерами;

• Можно оставить всё как есть, но тогда обязательно объяснить причину в комментарии.

Это не жёсткий запрет, а запрет на молчаливое утверждение. Руководитель вправе осознанно оставить разрыв, но это решение будет записано и видно уровнем выше. Главное, что о нехватке плана становится известно в момент утверждения, не в конце квартала.

По горизонтали. Договорённость о передаче работы

Для каждой пары связанных подразделений система хранит «контракт передачи». В нём записано, какой показатель считается результатом подразделения А и одновременно входом для подразделения Б, по каким признакам этот результат принимают и как качество входа влияет на оценку.

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

Качество входа измеряется долей комплектов, которые приняли без возврата на доработку. Если эта доля опускается ниже 80%, показатель подразделения Б помечается как «ограничен внешним фактором» и перестаёт влиять на его премию, а руководитель подразделения А получает сигнал о проблеме.

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

8.3 Контроль при вводе

Сейчас в систему можно вписать что угодно, и никто этого не заметит. В новой модели каждое значение проходит три проверки, а для некоторых показателей ещё и подтверждение.

Сначала система смотрит, попадает ли значение в допустимый коридор. Если коридор от 100 до 600 штук, а сотрудник вносит 500, всё в порядке. Если значение выходит за коридор, система не блокирует ввод, а предупреждает и просит оставить комментарий.

Потом система сравнивает значение с прошлыми периодами. Допустим, в среднем за последние три месяца было 300, а теперь сотрудник вносит 500, то есть на 67% больше, при том что порог стоит на 50%. Тогда появляется просьба объяснить, почему значение так сильно отличается, и без этого пояснения сохранить данные нельзя.

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

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

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

Появляются и понятные правила исправления ошибок, которые заменяют заявку в поддержку и ожидание в один-два дня.

В хорошо устроенной системе ручного ввода со временем становится всё меньше. Чем больше показателей собирается автоматически, тем меньше вообще приходится что-то проверять.

8.4 Качество самих статистик

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

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

Так система постепенно очищается от мусора и не копит его годами. По сути это встроенное «обучение двойного цикла», о котором писал Крис Аргирис [13]. Система проверяет не только то, правильно ли люди вносят данные, но и то, правильно ли мы вообще измеряем.

8.5 Типология показателей

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

Работа с отложенным эффектом

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

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

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

Роли, где главное качество

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

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

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

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

Оценка на стыках

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

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

8.6 Здоровье всей системы

Последний уровень представляет собой дашборд для руководства и администраторов. Он показывает не бизнес-результаты, а качество самой системы измерений, и глядя на него, топ-менеджмент понимает, можно ли доверять цифрам, ещё до того, как начнёт принимать по ним решения.

9. Как защитить модель от закона Гудхарта

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

• Любой количественный показатель в премии должен иметь «противовес» по качеству. Количество документов идёт в паре с долей возвратов, скорость закрытия задач с количеством возвратов из тестирования, объём продаж с долей отказов и дебиторкой. Обмануть одну цифру легче, чем две противоположные.

• Для разработки и других работ «разной сложности» мерить не штуки задач, а взвешенный объём (оценка сложности, время цикла, предсказуемость сроков). Тогда сложная задача перестаёт быть угрозой для показателя, и проблема «не беру лишнее, чтобы не испортить статистику» уходит.

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

• В премию не попадает то, на что сотрудник не влияет. Индикатор управляемости из уровня 4 схемы контроля и метка «ограничен внешним фактором» из уровня 2 как раз для этого.

• Число открывает разговор руководителя с сотрудником. Комментарии к отклонениям из уровня 3 нужны не для отчётности, а чтобы этот разговор был предметным.

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

10. Порядок внедрения и риски

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

Риски и как их снизить

11. Ограничения модели и как её улучшить

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

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

• Требуют настройки типы показателей и все пороговые значения, то есть коридоры, 50% для странных значений, 80% для приёмки и 95% для качества. Это стартовые цифры, и их нужно подбирать на реальных данных каждого направления.

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

• И наконец, часть подразделений и ролей в исследование не попала, а карту связей между подразделениями удалось восстановить лишь частично.

  Что можно улучшить

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

  • Настроить пороги «в тени». В течение двух-трёх месяцев собирать значения, никак не связывая их с премией, и уже по этим данным выставить коридоры и пороги для каждого типа показателей.

  • Развивать проверку связи с целью. Это главная защита от красивых, но бесполезных цифр, и её стоит превратить в регулярный разбор того, какие показатели действительно предсказывают результат подразделения.

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

  • Закрепить защиту от эффекта Гудхарта в регламенте, и не оставлять её на усмотрение каждого руководителя.

12. Что это даёт бизнесу и как посчитать потери

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

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

Чтобы оценить нынешние потери в деньгах, хватит простого расчёта.

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

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

Модель не требует ломать всё до основания. Нужно додумать методологию, собрать полную картину связей между направлениями и приложить идею к реальной работе конкретных подразделений.

13. Почему организациям трудно менять уже внедрённую методологию

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

1. Первая причина известна как эскалация обязательств. Тот же Барри Стоу показал, что чем больше ресурсов уже вложено в выбранный путь, тем сильнее желание продолжать по нему идти, даже когда появляются признаки того, что он не работает [14]. Каждый месяц жизни с системой одновременно увеличивает потери и делает её пересмотр психологически всё дороже. Это та самая ловушка невозвратных затрат.

2. Вторая причина в привычке к тому, что уже есть. Уильям Самуэльсон и Ричард Зекхаузер показали, что при прочих равных люди и организации выбирают текущее положение дел [17]. Изменения кажутся рискованнее привычных потерь, особенно если эти потери размазаны по отделам и не видны в отчётах.

3. Третья причина связана с тем, как организации учатся. Аргирис писал, что компании охотно исправляют ошибки исполнения, но с большим трудом пересматривают исходные допущения [13]. Улучшить интерфейс значит исправить исполнение, а пересмотреть методологию значит признать, что изначально были приняты неправильные решения, и организационно это сложнее любой технической задачи.

4. Четвёртая причина в том, что настоящая прозрачность меняет баланс информации внутри компании. Она неудобна не только тем, кого измеряют, но и всем, кто участвует в управлении, потому что становится видно и качество самих управленческих решений. Это естественное свойство любых систем учёта.

5. Пятая причина связана с авторитетом заимствованной методики. Если её внедряли как признанную и проверенную практику, любой пересмотр воспринимается как сомнение в ней самой. Поэтому любую методологию стоит с самого начала представлять как теорию, которую предстоит подстраивать под себя.

6. И шестая причина в языке, на котором идёт разговор. Фразу «показатели методологически неверны» бизнес обычно пропускает мимо ушей, а вот фразу «руководители тратят сотни часов в месяц на перепроверку цифр, которым сами не верят» услышать гораздо проще. Об изменениях лучше говорить в часах, деньгах и рисках.

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

14. Как адаптировать методологию к своей компании

Этот случай хорошо показывает общий принцип. Любую заимствованную управленческую методологию, будь то ЦКП и статистики, KPI, OKR, сбалансированная система показателей, Lean или Agile, нужно переводить, а не в тупую копировать. Для этого можно пройти шесть шагов.

1. Разобраться, откуда методика пришла. Где, когда и для какой работы её придумали и что она молча предполагает о данных, устройстве компании, горизонте планирования и мотивации людей. Удобно собрать это в таблицу вроде той, что приведена в разделе 7, и проверить каждое допущение на своей компании.

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

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

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

5. Провести пилот и настроить систему. Начать с небольшой группы подразделений разных видов, какое-то время собирать данные без влияния на премию и заранее определить, что будет считаться успехом.

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

Такой подход опирается на идею управления на основе доказательств, которую развивали Джеффри Пфеффер и Роберт Саттон [15]. Решение о том, внедрять ли практику, принимают по данным о том, работает ли она в конкретных условиях, а не по тому, насколько она популярна или авторитетна.

15. Выводы

• Любая методология остаётся теорией прежде всего, не догмой и не регламентом действий. Проблема не в конкретных методиках, а в том, как бизнес с ними обращается. Если копируют форму, а смысл, то есть понимание того, как устроена работа конкретных подразделений, не переводят, система воспроизводит ритуал вместо пользы.

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

• Контроль через обязанность даёт вторую версию правды, а контроль через удобство даёт данные. Если система только забирает время и ничего не даёт взамен, её будут заполнять для галочки, а настоящее управление останется в таблицах.

• Показатель, привязанный к премии, постепенно начинает измерять умение работать на показатель. Защищаться от этого нужно устройством системы, то есть парными показателями, учётом сложности и ограниченным весом каждой цифры в премии, а не призывами заполнять честно.

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

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

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

• Механизмы пересмотра закладываются до запуска. Чем дольше организация живёт с неадаптированной методологией, тем дороже ей обходится признать это и всё поменять.

16. Чек-лист, если у вас похожая ситуация

Если вы внедряете или уже внедрили ЦКП и статистики или любую другую систему KPI, попробуйте честно ответить на эти вопросы, прежде чем вкладываться в продукт.

1. Можете ли вы для каждого показателя за минуту объяснить, что он измеряет, по какой формуле считается, откуда берётся цифра и кто за него отвечает?

2. Какая часть показателей уже есть в рабочих системах, и почему люди всё равно вносят их вручную?

3. К какому виду работы относится каждое подразделение, и подходит ли ему показатель в штуках?

4. Сходятся ли планы сотрудников с планом руководителя, и узнаёте ли вы о разрыве до начала периода?

5. Учтено ли, что результат подразделения зависит от того, что ему передало другое подразделение?

6. Может ли сотрудник исправить свою ошибку без заявки в поддержку?

7. Есть ли у каждого премиального показателя противовес по качеству?

8. Что вы делаете с показателем, который месяцами не меняется или которым никто не пользуется?

9. Сколько часов в месяц уходит на сбор, сверку и перепроверку цифр, и сколько это в деньгах?

10. Отказались ли руководители от параллельных таблиц, а если нет, то почему?

11. Какие допущения исходной методологии вы проверили на своей организации, своём рынке и своей культуре?

12. Есть ли в системе механизм, который регулярно пересматривает саму методологию?

Если на половину вопросов ответа нет, проблема скорее всего не в интерфейсе, а в методологии, и начинать нужно именно с неё.

17. Заключение

Быстрое внедрение по шаблону кажется дешёвым, потому что его цена отложена и размазана по подразделениям, а продуманное внедрение кажется дорогим, потому что его цену по временным и финансовым затратам видно сразу. В итоге организация, как правило, платит дважды, сначала за систему, которая так и не дала прозрачности, а потом ещё долго за часы ручного труда на переделку или поддержку и за данные, которым никто не верит.

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

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

18. Литература и источники

1. Подробный разбор метафоры технического долга в материале Agile Alliance Technical Debt.

2. Nielsen Norman Group. Service Blueprints. Definition.

3. Формулировка закона по работе. Обзор в статье Goodhart's law.

4. On the Folly of Rewarding A, While Hoping for B

5. 14 принципов менеджмента, пункт 11а.

6. The Balanced Scorecard. Measures that Drive Performance

7. Обзор в статье Campbell's law.

8. Muller J. Z. The Tyranny of Metrics

9. The Iron Cage Revisited. Institutional Isomorphism and Collective Rationality in Organizational Fields.

10. Abrahamson E. Management Fashion.

11. Translating Organizational Change

12. Cultures and Organizations. Software of the Mind.

13. Double Loop Learning in Organizations

14. Knee-deep in the Big Muddy

15. Evidence-Based Management

16. Cargo Cult Science. Речь перед выпускниками Калтеха, 1974.

17. Status Quo Bias in Decision Making