"Наивная цифровизация" - Почему строительный бизнес не справляется с крутыми поворотами рынка.

- -
- 100%
- +
Фактический рост составил 4%.
На совещании коммерческий директор спросил региональных менеджеров, почему прогноз оказался неточным.
Все присутствующие проявили удивление. Некоторые особенно убедительно.
Цифры не были выдуманы в традиционном смысле. Они появились в результате коллективного поиска показателя, который руководство согласилось считать реалистичным.
Это был не прогноз рынка.
Это был прогноз реакции начальника.
Система обработала данные без ошибок. Она рассчитала закупки, производственную программу и бюджет. Проблема находилась не в формулах.
В исходные данные встроили человеческое желание говорить то, что приятно слышать. Математика, как хорошо воспитанный официант, подала результат именно в том виде, в котором его заказали.
Статус определяет вес факта
В идеальной модели достоверность информации не зависит от должности человека, который её передаёт.
Если рабочий заметил дефект, сообщение должно рассматриваться по существу. Если директор ошибся, его решение должно проверяться по тем же правилам.
В реальной организации факт имеет не только содержание, но и служебный вес.
Одно и то же замечание, высказанное рабочим, инженером и директором, проходит три разных маршрута.
Рабочий говорит:
• Здесь неправильно установлено крепление.
Ему отвечают:
• Выполняйте по чертежу.
Инженер говорит:
• Возможно, требуется проверить узел.
Ему отвечают:
• Подготовьте служебную записку.
Директор проходит мимо и спрашивает:
• Почему крепление установлено неправильно?
Через десять минут создаётся комиссия.
Факт существовал всё время. Но управленческой реальностью он стал после того, как получил подходящий статус.
Пример 5. Молодой специалист и уважаемая колонна
На объекте молодой инженер заметил, что колонна установлена с отклонением.
Он сообщил мастеру.
Мастер посмотрел на колонну, потом на молодого инженера.
• Я такие колонны ставил, когда ты ещё в школу ходил.
Аргумент не имел прямого отношения к геометрии, но обладал значительным эмоциональным весом.
Инженер провёл измерение повторно. Отклонение сохранилось. Колонна, очевидно, не уважала производственный стаж мастера.
Инженер сообщил начальнику участка.
Тот ответил:
• Не драматизируй. Сначала поговори с геодезистом.
Геодезист подтвердил отклонение, но предложил измерить ещё раз утром, когда температура будет стабильнее.
Утром колонна всё ещё стояла неправильно.
Информация поднялась к руководителю проекта только после того, как отклонение обнаружил представитель заказчика.
Тогда проблема стала срочной.
Начались совещания, служебные записки и поиск ответственного. Молодого инженера спросили, почему он не сообщил раньше.
Он попытался объяснить, что сообщал.
• Нужно было настойчивее, — сказал руководитель.
Это универсальная управленческая формула. Она позволяет одновременно признать наличие информации и снять ответственность с тех, кто её проигнорировал.
После этого молодой специалист сделал правильный вывод: в следующий раз недостаточно обнаружить факт. Нужно ещё обладать достаточным статусом, чтобы факт согласился существовать.
Отношения между подразделениями
Информация не путешествует по компании в нейтральном пространстве. Она пересекает границы подразделений.
На каждой границе её встречают таможенники.
Производство считает, что снабжение постоянно задерживает материалы.
Снабжение считает, что производство не умеет планировать.
Проектировщики уверены, что строители не читают документацию.
Строители подозревают, что проектировщики никогда не видели настоящую стройку.
Финансовый отдел полагает, что все тратят слишком много.
Все остальные полагают, что финансовый отдел существует именно для того, чтобы работа остановилась в момент, когда наконец начала двигаться.
В этих условиях любой факт становится участником старого межведомственного конфликта.
Пример 6. Исчезнувшие окна
На строительный объект не поступили оконные блоки. Монтаж остановился.
Начальник участка сообщил, что снабжение сорвало поставку.
Снабжение ответило, что заявка была подана с опозданием.
Производственно-технический отдел заявил, что заявку нельзя было подготовить раньше из-за отсутствия согласованной спецификации.
Проектировщик сообщил, что спецификация была выпущена вовремя, но заказчик изменил цвет профиля.
Заказчик напомнил, что изменение обсуждалось два месяца назад.
Подрядчик добавил, что его никто официально не уведомил.
Цифровая система хранила все документы.
В ней находились заявки, письма, версии спецификаций, протоколы и согласования. Информации было столько, что установить истину стало значительно труднее, чем при её отсутствии.
На совещании открыли систему.
Каждое подразделение нашло документ, подтверждавший его правоту.
Это был подлинный триумф цифрового документооборота: все данные находились в одном месте, но процесс всё равно остановился.
Через два часа участники пришли к общему выводу:
• Необходимо повысить качество взаимодействия.
Окна от этого не появились, зато формулировка никого не обидела.
Система хранила историю действий, но не управляла последовательностью процесса. Она не проверяла, выполнены ли условия для заказа, не связывала изменение спецификации с графиком поставки и не запускала обязательное корректирующее воздействие.
Она знала всё.
Она ничего не делала.
Как старый дворецкий в детективном романе: видел каждого подозреваемого, слышал выстрел, знал расположение оружия, но считал неприличным вмешиваться в дела господ.
Желание избежать ответственности
Ответственность является особым фильтром информации.
Человек охотно сообщает о достижениях, если может связать их с собственными действиями. С проблемами всё сложнее. Прежде чем передать неприятный факт, он пытается понять, на кого этот факт указывает.
Если стрелка показывает на соседнее подразделение, сообщение передаётся быстро и подробно.
Если на самого сотрудника — требуется дополнительная проверка.
Если на его начальника — информация нуждается в глубоком методологическом осмыслении.
Если на генерального директора — вероятно, проблема вообще отсутствует.
Так возникает задержка обратной связи. Не техническая, а психологическая.
Система уже могла бы получить сведения. Но человек ждёт, пока рядом с фактом появится безопасное объяснение.
Пример 7. Красная кнопка
В одной компании система управления проектами позволяла сотруднику отметить критическое отклонение. После этого информация автоматически поступала руководителю программы.
Кнопка была красной.
Разработчики выбрали этот цвет, чтобы подчеркнуть серьёзность действия. Они добились большего. Кнопка выглядела так, будто после нажатия должны были остановиться реактор, биржа и сердце непосредственного начальника.
Сотрудники избегали её.
Они выбирали жёлтый статус и писали в комментарии:
Существует вероятность потенциального влияния на отдельные параметры срока при неблагоприятном развитии сопутствующих факторов.
На обычном языке это означало:
Мы уже опоздали.
Руководство узнавало о критической ситуации, когда срок был сорван окончательно.
ИТ-отдел предложил провести обучение по правильному использованию статусов.
Но сотрудники прекрасно понимали назначение кнопки. Они не знали другого: что произойдёт с человеком, который её нажмёт.
Пока система не отвечает на этот вопрос, красная кнопка не является инструментом обратной связи.
Она является тестом на личную храбрость.
Добросовестность нельзя использовать как архитектуру
Ни одна зрелая техническая система не должна зависеть от постоянного героизма участников.
Если безопасность самолёта обеспечивается только тем, что пилот никогда не устаёт, не ошибается и всегда принимает безупречные решения, это не безопасный самолёт. Это памятник оптимизму инженеров.
То же относится к управлению.
Призывы быть внимательнее, ответственнее и честнее полезны. Иногда после них человек действительно становится внимательнее — примерно до обеда.
Но добросовестность не может заменить архитектуру данных.
Цифровая система должна получать максимально возможную часть информации непосредственно из процесса:
• объёмы — из измерений;
• перемещения — из событий;
• сроки — из фактических переходов;
• параметры оборудования — из датчиков;
• версии документов — из контролируемой среды;
• качество — из стандартизированных критериев;
отклонения — из сопоставления плана и факта.
Человеку следует оставлять не механическую передачу факта, а интерпретацию исключений и принятие решений там, где алгоритм действительно не способен действовать самостоятельно.
Если система спрашивает сотрудника: «Работа выполнена?», она получает ответ.
Если система проверяет объём, качество, время и условия завершения операции, она получает данные.
Ответ и данные — не одно и то же.
Особенно если премия зависит от ответа.
Человек не виноват в том, что он человек
Самая простая реакция на недостоверные данные — обвинить исполнителя.
Он невнимательный.
Он безответственный.
Он неправильно заполнил форму.
Он несвоевременно сообщил.
Иногда обвинение справедливо. Чаще оно удобно.
Система требует от человека быть одновременно датчиком, аналитиком, контролёром, психологом и независимым арбитром. Затем удивляется, что результат зависит от его настроения и личных интересов.
Человек не является неисправным датчиком.
Он является другим типом элемента.
Он способен понять контекст, увидеть необычное, сформулировать гипотезу, усомниться в цели и изменить правила. Именно поэтому человек незаменим в сложных системах.
Но те же свойства делают его нестабильным источником типовых данных.
Он думает.
Он интерпретирует.
Он приспосабливается.
Он защищается.
Иногда ошибается.
Иногда хитрит.
Иногда просто хочет закончить отчёт и успеть домой к ужину.
В этом есть что-то раздражающее и одновременно успокаивающее. Организации состоят не из идеальных элементов, а из людей. Если бы сотрудники никогда не уставали, не спорили и безукоризненно следовали инструкции, руководству стоило бы проверить, не заменили ли их ночью бытовой техникой.
Проблема начинается не тогда, когда человек ведёт себя по-человечески.
Проблема начинается тогда, когда система спроектирована так, будто он этого делать не будет.
От управления добросовестностью — к управлению процессом
Зрелая цифровая система не должна задаваться вопросом:
Можно ли доверять конкретному сотруднику?
Она должна отвечать на другие вопросы:
• откуда получен факт;
• можно ли его проверить;
• каким событием он подтверждён;
• кто и когда изменил данные;
• какие условия должны быть выполнены;
• какое отклонение возникло;
• какое стандартное воздействие запускается;
в какой момент требуется решение человека.
Это не означает отказа от доверия.
Доверие необходимо людям.
Проверяемость необходима системам.
Когда эти понятия смешивают, руководитель начинает контролировать человека вместо процесса. Он проверяет, вовремя ли сотрудник заполнил форму, но не знает, правильно ли выполнена операция. Он требует дисциплины ввода данных, но не обеспечивает достоверного источника этих данных.
Так появляется ещё один парадокс наивной цифровизации:
• чем меньше система знает о процессе, тем больше она хочет знать о человеке.
Она отслеживает его входы, действия, подтверждения и комментарии. Постепенно цифровизация процесса превращается в цифровизацию поведения исполнителя.
Человек становится прозрачным.
Процесс остаётся непрозрачным.
Неустойчивый элемент в устойчивой модели
Человека невозможно исключить из управленческого контура. Да и не следует.
Он способен заметить то, чего нет в правилах. Увидеть новую угрозу. Понять изменение контекста. Отказаться от формально правильного, но бессмысленного решения.
Однако система должна учитывать его реальную природу.

Человек может ошибиться.
Может испугаться.
Может устать.
Может защитить себя.
Может сказать начальнику то, что начальник хочет услышать.
И может проявить исключительную добросовестность там, где этого никто не ожидал.
Но если достоверность всей модели держится только на последнем варианте, перед нами не цифровая система управления.
Перед нами ставка на человеческое благородство.
Ставка красивая.
Особенно если делать её чужими деньгами.
Человек должен оставаться источником смысла, гипотез и решений в нестандартных ситуациях. Но он не должен быть единственным источником фактов о стандартном процессе.
Иначе машина снова окажется счетоводом, руководитель — следователем, а сотрудник — подозреваемым, обязанным ежедневно доказывать, что всё сделал правильно.
Система будет хранить тысячи записей.
Руководство — смотреть на дашборды.
Сотрудники — выбирать безопасные статусы.
А факты будут стоять в коридоре и терпеливо ждать, когда их пригласят на совещание.
Глава 3. Психика как теневой контур управления
Просто опыт: Если система не учитывает возможность задержки, искажения и сокрытия FACT, человеческая психика становится её неуправляемым модулем.
У каждой организации есть два контура управления.
Первый нарисован на схеме.
Он начинается с цели, проходит через задания, сроки, показатели и ответственность, а заканчивается результатом. Стрелки на нём прямые, прямоугольники ровные, руководители компетентные. Информация движется вверх, решения — вниз, а ответственность распределяется по регламенту.

Второй контур на схеме отсутствует.
По нему сотрудники узнают, кому лучше пока ничего не сообщать, какой показатель следует улучшить до совещания, куда можно перенести ответственность и сколько времени удастся выиграть фразой:
• Давайте сначала уточним исходные данные.
Первый контур управляет официальным процессом.
Второй — последствиями участия человека в этом процессе.
Он формируется из страха, личного опыта, служебных отношений и инстинкта самосохранения. У него нет утверждённой архитектуры, владельца и технической поддержки. Тем не менее он работает быстрее многих корпоративных платформ.
Мы назовём его теневым контуром управления.
Именно в нём принимается решение не о том, как исправить отклонение, а о том, когда о нём сообщить, как сформулировать и кому предоставить честь отвечать за последствия.
FACT
и его человеческая биография
Обозначим словом FACT событие, которое действительно произошло в процессе.
Не оценку.
Не комментарий.
Не объяснение.
И не утверждённую версию для руководства.
FACT — это физическое или зафиксированное событие:
• материал не поступил;
• операция не выполнена;
• срок превышен;
• изделие имеет дефект;
• оборудование остановилось;
• объём не соответствует плану;
• решение не принято;
необходимое условие не выполнено.
В идеальной цифровой модели FACT возникает и немедленно попадает в систему. Там он сравнивается с планом, классифицируется как отклонение и запускает корректирующее воздействие.
В реальной организации у факта начинается биография.
Сначала его замечают.
Затем обсуждают с ближайшими коллегами.
После этого решают, можно ли устранить проблему без регистрации.
Если нельзя, ищут безопасную формулировку.
Потом выбирают момент для сообщения.
Наконец, FACT попадает в систему — умытый, причёсанный и с рекомендательным письмом.
Иногда к этому времени он уже перестаёт быть фактом и становится исторической справкой.
Система получает его не в момент возникновения, а после завершения психологической обработки.
Цифровая платформа видит дату регистрации.
Процесс помнит настоящую дату события.
Между ними располагается человеческая психика — пространство, где информация может провести от нескольких минут до нескольких месяцев, в зависимости от размера проблемы и темперамента начальника.
Пример 1. Бетон, который решил немного подождать
На строительном объекте завершили бетонирование перекрытия. На следующий день инженер обнаружил участок с признаками недостаточного уплотнения.
FACT был прост:
• качество части конструкции требует проверки.
Инженер сообщил мастеру.
Мастер посмотрел на участок и сказал:
• Давайте не будем раньше времени создавать проблему.
Фраза заслуживала внимания. Проблема уже существовала, но ещё не была создана административно. До внесения в систему она считалась личным впечатлением бетона.
Решили подождать представителя лаборатории.
Лаборатория могла приехать только на следующий день.
Представитель приехал, осмотрел конструкцию и предложил провести дополнительное обследование.
Начальник участка попросил сначала обсудить вопрос с подрядчиком. Подрядчик заявил, что необходимо проверить проектные требования. Проектировщик попросил официальное обращение.
Официальное обращение решили не отправлять до получения заключения лаборатории.
Круг замкнулся.
Цифровая система продолжала показывать, что бетонирование завершено. Статус операции был зелёным. Следующая работа по графику могла начинаться.
На площадке тем временем стояли четыре человека и рассматривали конструкцию с выражением опытных врачей, которым пациент сообщил неудачные результаты анализов.
• Может, ничего серьёзного, — сказал один.
• Скорее всего, — согласился второй.
• Но проверить нужно, — добавил третий.
• Обязательно, — подтвердил четвёртый.
Все согласились. Проверка от этого не началась.
FACT существовал в физической реальности, но отсутствовал в цифровой. Между ними работал теневой контур, который пытался выиграть время и найти версию события, не требующую неприятных решений.
Когда дефект наконец зарегистрировали, система показала, что проблема выявлена сегодня.
Бетон мог бы возразить, но не имел учётной записи.
Задержка как психологическая анестезия
Люди откладывают сообщение неприятной информации не только ради обмана.

Часто они надеются, что проблема исчезнет сама, прояснится, станет меньше или хотя бы перейдёт в чужую смену.
Задержка действует как психологическая анестезия.
Пока сообщение не отправлено, проблема сохраняет неопределённый статус. Она ещё не стала официальным нарушением. За неё не назначен ответственный. Не запущена процедура. Не начался отсчёт срока устранения.
Человек получает несколько часов спокойствия.
Иногда — несколько дней.
Организация теряет время, но сотрудник выигрывает передышку. С точки зрения процесса это вредно. С точки зрения нервной системы — вполне рационально.
Управленческая модель обычно предполагает, что человек заинтересован в максимально быстром раскрытии отклонения.
Человек иногда заинтересован в том, чтобы отклонение первым обнаружил кто-нибудь другой.
Пример 2. Письмо, которое созревало три дня
Специалист отдела снабжения получил сообщение, что поставщик не сможет поставить оборудование в согласованный срок.
Он открыл письмо в понедельник утром.
Срок поставки был критическим. Задержка могла остановить монтаж.
Специалист решил сначала позвонить поставщику. Возможно, ситуация изменится.
Поставщик обещал уточнить.
Во вторник сообщил, что ищет альтернативную машину.
Специалист пока не уведомлял руководителя проекта. Он не хотел создавать панику раньше времени.
В среду выяснилось, что машина не найдена.
Тогда специалист подготовил письмо. Перечитал. Убрал слово «срыв» и заменил его на «возможное смещение». Затем убрал «смещение» и написал «уточнение логистического графика».
Письмо стало спокойнее.
Поставка от этого не приблизилась.
В четверг информация дошла до руководителя проекта.
• Когда вы узнали о проблеме? — спросил тот.
Специалист ответил честно:
• Мы до последнего пытались найти решение.
Это была правда.
Он действительно искал решение. Одновременно он откладывал момент, когда проблема станет официальной и появится вопрос об ответственности.
В цифровой системе задержка возникла в четверг.
В реальности — в понедельник.
Между этими датами находился теневой контур управления, который три дня согласовывал FACT с человеческой надеждой.
Как улучшить показатель без улучшения результата
Любой показатель постепенно становится объектом человеческого внимания.
Сначала его используют для оценки процесса.
Затем начинают оценивать по нему людей.
После этого люди учатся управлять показателем.
Не обязательно обманом. Иногда достаточно изменить классификацию, время регистрации или границу измерения. Цифра становится лучше, хотя физический результат остаётся прежним.
Это напоминает весы, которые показывают меньше, если встать на них боком. Способ не особенно научный, но настроение улучшает.
Пример 3. Отдел технической поддержки победил обращения
Корпоративная служба поддержки измеряла среднее время закрытия заявок.
Руководство поставило цель: сократить его с трёх дней до одного.
Сотрудники получили чёткий показатель и быстро нашли способ его улучшить.
Если проблема требовала длительного решения, заявку закрывали с комментарием:
Пользователю предоставлена консультация. При повторном возникновении необходимо создать новое обращение.
Пользователь создавал новое обращение.
Первое считалось успешно закрытым.
Среднее время обработки сократилось. Количество обращений выросло. Пользователи стали раздражительнее. Служба поддержки получила премию за повышение эффективности.
Руководитель отдела демонстрировал график:
• Как видите, мы значительно ускорили работу.
График это подтверждал. Графики вообще редко спорят с человеком, который выбирает для них данные.
Проблемы не решались быстрее.
Они просто получали новые номера.
Система измеряла время жизни заявки, а не время устранения неисправности. Сотрудники не нарушали установленного правила. Они научились достигать показателя способом, не предусмотренным авторами модели.
Так теневой контур выполнил корректирующее воздействие. Только корректировал он не процесс, а его цифровое отражение.
Показатель становится мишенью
До тех пор, пока показатель используется для понимания процесса, он может быть полезен.
Когда от него начинают зависеть премия, статус и безопасность сотрудника, показатель превращается в мишень.
Люди стреляют в неё всеми доступными способами.
Если оценивают количество закрытых задач, задачи начинают дробить.
Если оценивают отсутствие дефектов, дефекты перестают регистрировать.
Если оценивают соблюдение сроков, дату завершения переносят ближе к фактической.
Если оценивают производительность, незавершённую работу объявляют почти завершённой.
Если оценивают точность планирования, план корректируют до тех пор, пока он не совпадёт с фактом.
Последний способ особенно эффективен. Будущее не оправдало прогноз — значит, необходимо исправить прошлую версию будущего.
Пример 4. Проект, который никогда не опаздывал
Компания управляла проектами через календарные графики. Каждый месяц руководители должны были показывать отклонение от базового срока.



