Полная версия:
"Наивная цифровизация" - Почему строительный бизнес не справляется с крутыми поворотами рынка.
Финансовый директор сообщил размер возможного штрафа. Цифра произвела сильное впечатление. После неё отклонение стало казаться меньше.
В документации не было ясного алгоритма для такой ситуации. Решение должен был принять директор производства.
Он осмотрел изделие, изучил результаты измерений и сказал:
• Не отправляем. Проверяем всю партию.
Отгрузку задержали. Несколько изделий потребовали доработки. Компания понесла дополнительные расходы, но не передала заказчику сомнительную продукцию.
Все согласились, что директор поступил ответственно.
Затем совещание закончилось, и никто не изменил процедуру контроля.
Критерии реакции остались прежними. Алгоритм блокировки партии не появился. Порог автоматического решения не установили. Ответственность не формализовали.
Организация не устранила системный пробел.
Она убедилась, что у директора хорошая совесть.
Так моральное качество одного человека было принято в эксплуатацию вместо процедуры.
Следующая партия снова зависела от того, кто окажется в кабинете и насколько убедительно финансовый директор назовёт сумму штрафа.
Герой как симптом слабой системы
Организации любят героев.
Герой остаётся после работы. Лично обзванивает подрядчиков. Находит дефицитный материал. Уговаривает проектировщика выпустить решение ночью. Вручную сводит противоречивые данные и утром приносит руководству правильный отчёт.
Его благодарят.
Награждают.
Иногда даже дают помощника, который должен научиться работать так же героически.
Но регулярный героизм — это не признак сильного управления. Это показатель того, что стандартный процесс не способен получить результат без чрезвычайного человеческого вмешательства.
Если каждую неделю требуется подвиг, подвиг следует включить в технологическую карту.
Пример 4. Алексей Викторович спасает понедельник
Каждую пятницу строительный объект должен был получать план работ на следующую неделю.
Для его подготовки требовалось собрать сведения о готовности фронтов, наличии материалов, рабочих, техники и документации.
Формально каждое подразделение вносило данные в общую систему.
Практически в пятницу вечером Алексей Викторович звонил всем участникам и задавал короткие вопросы:
• Люди будут?
• Материал придёт?
• Чертёж окончательный?
• Кран работает?
• Вы точно уверены?
Последний вопрос был наиболее важным и отсутствовал в цифровой форме.
После звонков Алексей Викторович корректировал план. Одну работу переносил, другую добавлял, третью переставлял местами. Иногда звонил подрядчику второй раз — уже менее вежливо, но более результативно.
В понедельник объект начинал работать.
Руководство считало, что система недельного планирования действует успешно.
Однажды Алексей Викторович уехал в отпуск.
В следующий понедельник две бригады пришли на неготовый фронт, для третьей не оказалось материала, а кран был занят на соседнем участке.
На совещании руководитель спросил:
• Почему не сработал недельный план?
Участники посмотрели друг на друга.
План был заполнен. Все поля содержали данные. Документ был утверждён вовремя.
В нём отсутствовало только одно обязательное условие — Алексей Викторович.
После его возвращения работа восстановилась. Руководство вздохнуло с облегчением и решило назначить ему заместителя.
Так компания попыталась масштабировать человека вместо процесса.
Начальник как интеграционная платформа
Современные организации используют множество информационных систем.
Одна хранит документы.
Вторая — графики.
Третья — бюджет.
Четвёртая — заявки.
Пятая — дефекты.
Шестая помогает сотрудникам не забыть пароли от первых пяти.
Между системами часто отсутствует полноценная связь. Тогда интеграцию выполняет руководитель.
Он открывает календарный план и видит, что работа должна начаться завтра. Затем проверяет документооборот и обнаруживает несогласованный чертёж. Звонит в снабжение и узнаёт, что материал не заказан. После этого переносит задачу и сообщает подрядчику, чтобы люди не выходили.
Ни одна система отдельно не увидела проблему.
Начальник сопоставил данные вручную.
Он стал интеграционной платформой с голосовым интерфейсом.
Пример 5. Четыре программы и один Николай
В девелоперской компании использовали четыре основные системы:
• систему календарного планирования;
• электронный документооборот;
• программу бюджетного контроля;
приложение для фиксации работ на площадке.
В календарном плане монтаж фасада должен был начаться 15 апреля.
В документообороте рабочая документация находилась на согласовании.
В бюджете договор с подрядчиком числился неподписанным.
В приложении площадки фронт работ был отмечен как готовый.
Каждая система показывала свою часть правды.
Николай Сергеевич, руководитель проекта, открыл четыре окна на двух мониторах, сделал несколько звонков и установил следующее:
• фронт работ готов частично;
• чертежи требуют корректировки;
• договор согласован, но не подписан;
• подрядчик готов вывести людей, если получит гарантийное письмо;
материал прибудет на неделю позже.
После этого он вручную изменил график, подготовил поручения и назначил совещание.
Цифровая экосистема работала.
Экосистемой был Николай Сергеевич.
ИТ-директор сообщил, что в следующем году планируется интеграция систем.
Николай Сергеевич спросил:
• А до следующего года что делать?
• Пока продолжать в текущем режиме.
Текущим режимом называлась жизнь Николая Сергеевича.
Когда глаз становится бутылочным горлышком
Чем опытнее начальник, тем больше решений начинают ждать его оценки.
Сотрудники привыкают:
• Пусть посмотрит руководитель.
• Нужно согласовать с директором.
• Без него лучше не решать.
• Он вернётся и скажет.
Первоначально начальник включается только в сложные ситуации. Затем — в важные. Потом — в спорные. Наконец, без него невозможно заказать канцелярские скрепки, потому что прошлый раз приобрели не тот размер.
Универсальный регулятор постепенно превращается в бутылочное горлышко.
Он перегружен, но организация считает это доказательством его незаменимости. Сам начальник тоже может испытывать определённое удовлетворение. Человек редко возражает против собственной незаменимости, пока не пытается уйти в отпуск.
Пример 6. Директор и двести согласований
Руководитель компании настаивал на личном согласовании всех значимых расходов.
Он хорошо знал бизнес и часто замечал ошибки, которые пропускали сотрудники. Благодаря ему компания избегала необоснованных закупок.
Постепенно список согласований расширялся.
Сначала директор проверял крупные договоры.
Затем — все договоры.
Потом — дополнительные соглашения, командировки и закупки оборудования.
Наконец, у него накопилось более двухсот документов.
Подразделения ждали решений. Сроки сдвигались. Поставщики нервничали. Сотрудники начали заранее закладывать в график две недели на ожидание подписи.
Директор работал вечерами и возмущался:
• Почему никто не способен самостоятельно принять решение?
Сотрудники могли бы ответить, что самостоятельные решения всё равно требовали его согласования. Но сочли это решение недостаточно самостоятельным.
Организация создала замкнутый контур:
• директор не доверяет правилам;
• поэтому проверяет решения лично;
• сотрудники перестают принимать решения;
• качество самостоятельных решений снижается;
директор получает подтверждение, что доверять нельзя.
Система была устойчивой.
Как болото.
Зависимость от личности
Если процесс существует только в голове руководителя, организация не может его надёжно воспроизводить.
Она не знает:
• какие признаки начальник учитывает;
• как он оценивает риск;
• почему выбирает определённое воздействие;
• какие исключения считает допустимыми;
• кому доверяет;
при каких условиях меняет решение.
Уход такого человека воспринимается как природное бедствие.
Проводятся встречи по передаче дел. Создаются папки. Пишутся инструкции. Преемнику говорят:
• Тут всё просто. Постепенно разберёшься.
Фраза обычно означает, что формальная модель отсутствует, а настоящее обучение начнётся после первой серьёзной ошибки.
Пример 7. Когда Павел Андреевич ушёл
Павел Андреевич управлял производственным участком восемнадцать лет.
Он знал оборудование, людей, поставщиков и особенности каждой смены. Помнил, какой станок нельзя перегружать летом, какой оператор слишком оптимистично оценивает срок и как быстро получить редкую деталь, не начиная официальную процедуру закупки.
Когда Павел Андреевич решил уйти, руководство попросило его передать знания преемнику.
Он подготовил сорок страниц инструкций.
Через месяц после его ухода участок начал регулярно срывать план.
Инструкции были подробными. Но в них не было записано, что:
Ивану лучше давать задания утром;
• поставщику необходимо звонить дважды;
• станок № 8 вибрирует перед поломкой особым образом;
• ночная смена занижает остаток материала, чтобы оставить резерв;
главный механик быстрее реагирует на личную просьбу, чем на официальную заявку.
Павел Андреевич не скрывал знания.
Он просто не считал их знаниями.
Для него это была жизнь.
Компания потеряла не руководителя, а неописанную модель управления, восемнадцать лет работавшую в человеческой голове.
ИТ-система продолжила функционировать без ошибок.
Она и раньше не знала, как на самом деле работает участок.
Опасность доброго начальника
Особенно опасен для слабой системы хороший начальник.
Плохой руководитель быстро обнаруживает недостатки процесса. При нём всё останавливается, конфликты выходят наружу, данные расходятся с реальностью. Организация хотя бы понимает, что у неё проблема.
Хороший начальник незаметно закрывает пробелы собой.
Он исправляет неточные задания.
Договаривается между подразделениями.
Проверяет сомнительные данные.
Компенсирует отсутствие ресурсов.
Защищает людей от противоречивых решений.
В результате система выглядит устойчивой.
Руководство не видит причин что-либо менять. Оно видит результат.
Только результат создаёт не система.
Его создаёт человек, который каждый день удерживает конструкцию руками и старается не показывать, насколько она тяжёлая.
Когда он уходит, организация удивляется:
• Почему всё развалилось? Ведь процесс работал.
Работал не процесс.
Работал начальник.
Цифровизация глаза начальника
Наивная цифровизация не устраняет зависимость от руководителя. Она предоставляет ему больше экранов.
Раньше начальник обходил площадку, разговаривал с людьми и читал отчёты.
Теперь он открывает дашборд, просматривает уведомления, проверяет фотографии, читает комментарии и всё равно звонит тем же людям.
Количество информации возрастает. Способ принятия решения остаётся прежним.
Начальник по-прежнему должен:
• определить достоверность данных;
• понять причину отклонения;
• оценить критичность;
• выбрать воздействие;
• назначить ответственного;
проверить результат.
Цифровая система ускоряет доставку материалов для его размышлений, но не замыкает контур.
Это может повысить эффективность сильного руководителя.
Но одновременно увеличивает зависимость организации от его внимания.
Теперь начальник способен контролировать не один объект, а пять. Значит, вместо одного процесса, зависящего от его глаза, компания получает пять.
Прогресс налицо.
Особенно у начальника.
Как превратить опыт в систему
Задача цифровизации состоит не в том, чтобы убрать опытного руководителя.
Попытка заменить его несколькими индикаторами обычно заканчивается тем, что индикаторы продолжают гореть зелёным возле уже остановившегося процесса.
Нужно сделать другое: превратить повторяющиеся профессиональные решения в элементы системы.
Если начальник всегда проверяет готовность фронта по пяти признакам, эти признаки должны стать критериями готовности.
Если он определяет риск задержки по сочетанию нескольких событий, система должна отслеживать это сочетание.
Если при определённом отклонении он всегда запускает одну и ту же последовательность действий, она должна стать стандартным алгоритмом реакции.
Если руководитель сравнивает сведения из четырёх источников, данные следует связать.
Если он регулярно исправляет одинаковую ошибку, проблема находится уже не в людях, а в архитектуре процесса.
Опыт начальника необходимо разложить на:
• наблюдаемые признаки;
• правила оценки;
• допустимые границы;
• типовые причины;
• алгоритмы воздействия;
• условия эскалации;
исключения, требующие профессионального решения.
После этого глаз начальника не исчезает.
Он поднимается на другой уровень.
Вместо ежедневной проверки стандартных ситуаций руководитель анализирует исключения, меняет правила и улучшает модель.
Он перестаёт быть частью механизма.
Он становится его конструктором.
Глаз, совесть и алгоритм
Управление без человеческого опыта опасно. Алгоритм способен последовательно выполнять правило, даже если правило давно потеряло смысл.
Управление только через человеческий опыт не менее опасно. Оно зависит от памяти, состояния и присутствия конкретного человека.
Зрелая система соединяет три элемента:
• алгоритм управляет повторяющимися ситуациями;
• глаз начальника распознаёт новое и нестандартное;
совесть начальника не позволяет формально правильному решению уничтожить реальный результат.
У каждого элемента своя роль.
Проблема наивной цифровизации в том, что алгоритм занимается хранением документов, а глаз и совесть начальника продолжают управлять всем остальным.
Начальник становится последней инстанцией истины.
Он смотрит на объект, слушает объяснения, проверяет цифры и выносит решение. В этот момент он похож на частного детектива из старого романа: вокруг все что-то скрывают, документы противоречат друг другу, а единственный свидетель утверждает, что ничего не видел.
Разница лишь в том, что детектив получает гонорар за одно расследование.
Начальник проводит их ежедневно.
Не уничтожить начальника системой
У опытного руководителя есть достоинство, которого долго не будет у любой цифровой модели: он понимает смысл происходящего.
Он способен увидеть, что люди формально выполнили процедуру, но не достигли результата. Может нарушить правило ради безопасности. Может остановить процесс, который на экране выглядит идеальным.
Поэтому цель цифровизации — не заменить начальника.
Цель — перестать использовать его внимание для выполнения операций, которые можно стандартизировать.
Начальник не должен ежедневно проверять, заказан ли материал, согласована ли документация и готов ли фронт работ. Эти условия должна контролировать система.
Он должен решать, что делать, когда стандартный порядок больше не работает.
Его глаз нужен для исключений.
Его совесть — для решений, затрагивающих людей, риск и ответственность.
Его опыт — для изменения самой модели.
Всё остальное должно перестать жить в его голове.
Иначе однажды начальник уйдёт в отпуск, заболеет или просто выключит телефон.
Цифровая система продолжит показывать статусы.
Сотрудники продолжат заполнять формы.
Дашборды будут светиться спокойным зелёным цветом.
А организация впервые увидит себя без глаз.
Часть II. Советский эксперимент
Советская система допустила автоматизацию расчётов и рабочих мест, но не создала устойчивого сквозного управления экономическими процессами.
Она охотно разрешила машине считать.
Гораздо труднее оказалось разрешить ей сравнивать обещание с результатом, видеть отклонение и задавать неприятный вопрос:
• Кто принял это решение и почему оно не сработало?
Глава 5. Кибернетику разрешили — управление не отдали
Просто опыт. Власть легко принимает автоматизацию вычислений и значительно труднее принимает автоматизацию контроля над собственными решениями.
Распространённая история о советской кибернетике выглядит просто.
Сначала её объявили буржуазной лженаукой. Затем поняли ошибку, реабилитировали и начали развивать. Учёные создали вычислительные центры, экономико-математические модели и проекты автоматизированного управления. Но консервативная бюрократия испугалась машин, поэтому великий цифровой проект не состоялся.
История удобная.
В ней есть учёные, чиновники, запрет, прозрение и неосуществлённое будущее. Не хватает только сыщика в плаще и папки с надписью «Совершенно секретно».
В действительности всё было сложнее и потому интереснее.
В начале 1950-х годов кибернетика действительно подвергалась идеологическим нападкам и получала ярлыки «буржуазной» и «псевдонаучной». Но развитие самой вычислительной техники, особенно связанной с обороной, атомным проектом и сложными расчётами, не прекратилось. Машины создавались, математические методы развивались, а государственные структуры прекрасно понимали практическую ценность быстрых вычислений. Во второй половине 1950-х кибернетика получила признание и превратилась в широкую научную рамку — от теории управления до экономических моделей и исследований мышления. Поэтому утверждение «кибернетику в СССР просто запретили» слишком грубо: идеологическая атака была реальной, но вычислительная техника продолжала развиваться, а затем сама кибернетика стала институционально допустимой и престижной. Исследования истории советской вычислительной техники и истории советской кибернетики подтверждают именно эту более сложную картину.
Кибернетику не просто включили обратно.
Ей выдали кабинет, научный журнал и поручили помогать строительству будущего.
Но между разрешением заниматься наукой и разрешением перестроить управление находилась та же разница, что между приглашением инженера на совещание и передачей ему ключей от директорского кабинета.
Первое считалось полезным.
Второе вызывало вопросы.
Машина только считала — и этим нравилась
Советское государство охотно использовало вычислительную технику там, где задача имела чёткие границы.
Рассчитать траекторию.
Обработать результаты испытаний.
Оптимизировать отдельную технологическую операцию.
Рассчитать конструкцию.
Подготовить статистическую таблицу.
Выполнить большой объём арифметических действий.
Машина не спорила с целью. Она получала исходные данные, выполняла вычисления и выдавала результат.
Это был идеальный работник.
Не опаздывал, не требовал жилплощадь и не задавал вопроса, почему исходные данные не совпадают с действительностью. Последнее особенно ценилось.
Проблемы начинались, когда вычислительная машина переставала быть усовершенствованным арифмометром и приближалась к управленческому контуру.
Для сквозного управления было недостаточно быстрее считать. Нужно было собирать достоверные данные с предприятий, сопоставлять их между отраслями, обнаруживать отклонения, перераспределять ресурсы и связывать решение с ответственностью.
Тогда машина начинала интересоваться не числами, а властью.
Кто определяет план?
Кто формирует данные?
Кто распоряжается ресурсами?
Кто имеет право изменить решение?
Кто отвечает за расхождение плана и факта?
На такие вопросы арифмометр не претендовал.
Управленческая система претендовала.
Именно поэтому автоматизация вычислений могла восприниматься как техническое развитие, а сквозная автоматизация управления — как попытка перестроить отношения между ведомствами, предприятиями и центром.
Машине разрешили считать государственный план.
Но право понимать, почему он не выполнен, оставили людям.
Пример 1. Счётная машина в кабинете директора
Представим советское промышленное предприятие.
В плановом отделе появляется вычислительная машина. Она ускоряет обработку данных, рассчитывает потребность в материалах и помогает формировать производственную программу.
Начальник отдела доволен.
Раньше сотрудники сводили таблицы десять дней. Теперь справляются за два.
Директор доволен.
Министерство получает отчёт быстрее.
Все выиграли.
Теперь представим следующий шаг. Система должна автоматически сопоставить производственный план с фактическим наличием материалов, состоянием оборудования, трудовыми ресурсами и заказами смежных предприятий. Она обнаруживает, что утверждённый план невозможно выполнить при имеющихся ограничениях.
Вычислительная машина сообщает:
Для достижения установленного результата необходимо изменить распределение ресурсов или пересмотреть плановое задание.
В комнате становится тише.
Пока машина помогала выполнять решение, она была полезным инструментом.
Когда она показала, что само решение противоречиво, она приобрела неприятную привычку вмешиваться в дела руководства.
Директор смотрит на расчёт.
Начальник планового отдела смотрит на директора.
Все понимают, что математически машина права.
Но план уже утверждён.
Следовательно, исправлять придётся не план, а объяснение его невыполнения.
Так вычислительная техника снова возвращается к безопасной роли: помогает быстрее подготовить отчёт.
Научная судьба и управленческая судьба
Историю кибернетики в СССР необходимо разделить на две линии.
Первая — научная.
Она включает развитие вычислительной техники, теории автоматов, математической экономики, оптимизации, распознавания образов, управления сложными системами и многих других направлений. Здесь работали сильные научные школы, создавались оригинальные методы и амбициозные проекты.
Вторая линия — управленческая.
Она связана с вопросом, удалось ли превратить математические методы и вычислительные машины в единый контур управления экономикой.
Научные достижения не означали автоматического изменения управленческой архитектуры.
Можно построить вычислительный центр и оставить прежний порядок формирования данных.
Можно автоматизировать расчёт плана, но не связать его с фактическим исполнением.
Можно установить ЭВМ в министерстве, не изменив отношения министерства с предприятиями.
Можно создать автоматизированное рабочее место, на котором сотрудник станет быстрее выполнять старую бюрократическую операцию.
Компьютеризация увеличивает скорость существующего процесса.
Но если сам процесс устроен неправильно, результатом становится более быстрая ошибка.
Машина не реформирует организацию только фактом своего присутствия. Это всё равно что поставить электрический двигатель на телегу и ожидать, что она самостоятельно превратится в железную дорогу.
Лошади, возможно, удивятся.
Система — вряд ли.
Машины коммунизма
К началу 1960-х отношение к кибернетике изменилось радикально. Её начали рассматривать как важный инструмент научно-технического и экономического развития. В партийных и научных публикациях обсуждалось широкое применение электронных вычислительных машин в производстве, строительстве, транспорте, проектировании, учёте и управлении.
Компьютеры получили почти героический образ.
Если раньше в них видели подозрительное западное учение о машинах и обществе, то теперь они становились помощниками плановой экономики.
Будущее выглядело убедительно.
Данные поступают с предприятий.
Вычислительные центры их обрабатывают.
