Kitabı oxu: «Цифровая трансформация бизнеса: от проектов к способности меняться»

Часть I. Диагноз: почему не получается

Глава 1. Трансформация, которой не было

В 2021 году я сидела на закрытом комитете по цифровизации одного крупного ритейлера. Совет директоров с гордостью рассматривал слайд: «Завершена первая фаза масштабной цифровой трансформации. Освоено 240 миллионов рублей».

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

– Объясните мне простыми словами. Мы потратили четвёртую часть миллиарда. А почему у нас маржинальность упала на полтора процента, и доставка клиенту как шла три дня, так и идет?

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

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

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

Подмена понятий и три ступени зрелости

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

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

Ступень 1. Оцифровка (Digitization)

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

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

Ступень 2. Цифровизация (Digitalization)

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

Вернемся к договору. Цифровизация — это когда система сама проверяет контрагента по открытым реестрам, подтягивает реквизиты, маршрутизирует документ на подпись юристу и финансовому директору в зависимости от суммы сделки и отправляет его через сервис ЭДО.

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

Ступень 3. Трансформация (Digital Transformation)

Трансформация начинается ровно там, где меняется источник ценности или модель монетизации.

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

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

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

Жесткий критерий: изменился ли источник ценности?

Если отбросить презентационную шелуху, у руководителя есть только один надежный маркер. Чтобы понять, происходит ли у вас трансформация или вы просто обновляете ИТ-парк, задайте себе простой вопрос: «Изменилось ли то, за что и как нам платит клиент?»

Если ответы сводятся к:

●

«Мы стали на два дня быстрее согласовывать счета на оплату»,

●

«Мы перевели 80% отчетов в систему BI»,

●

«Мы заменили устаревшую учетную систему на свежую версию»,

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

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

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

Инструмент: Тест из семи вопросов «Что мы на самом деле делаем»

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

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

Рабочий бланк оценки инициативы

Интерпретация результатов:

●

0–4 балла: Оцифровка (Digitization). Вы занимаетесь технической гигиеной и ликвидацией отставания. Это нормальная работа, но не называйте ее трансформацией. Не ждите от этого проекта рыночных прорывов.

●

5–9 баллов: Цифровизация (Digitalization). Вы оптимизируете существующую бизнес-модель. Проект даст локальную экономию денег или времени, но не защитит от тектонических сдвигов в отрасли.

●

10–14 баллов: Настоящая цифровая трансформация. Вы перестраиваете саму способность организации создавать ценность. Главный риск здесь — оторваться от реальности и не довести изменения до работающей операционной модели.

Глава 2. Анатомия провала

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

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

Если анализировать эти истории, выясняется, что почти все провалы развиваются по шести типовым сценариям. У каждого из них есть характерные признаки, которые можно заметить в первые 30–60 дней, если знать, куда смотреть.

Шесть сценариев, по которым умирают изменения

Сценарий 1. Решение в поисках проблемы

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

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

Ранний симптом: На стартовых совещаниях звучат названия технологий, а не метрики бизнеса. Ответ на вопрос «Какую конкретно проблему клиента или какую операционную потерю мы закрываем?» формулируется туманно: «Это выведет нас в лидеры инноваций».

Сценарий 2. Пилот, который невозможно масштабировать

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

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

●

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

Сценарий 3. Проект без хозяина из бизнеса

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

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

●

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

Сценарий 4. Автоматизация хаоса

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

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

●

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

Сценарий 5. Метрика-пустышка вместо результата

Трансформация подменяется отчетами о проделанной работе. Руководство рапортует об обучении 500 сотрудников, закупке 1000 планшетов, переводе 90% документооборота в цифру.

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

●

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

Сценарий 6. Партизанская война инфраструктуры

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

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

●

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

Инструмент: Чек-лист ранних симптомов

Этот чек-лист – инструмент регулярного контроля. Заполняйте его перед запуском любой крупной инициативы и повторяйте проверку каждые 60 дней.

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

Форма проверки здоровья проекта (Заполняется каждые 60 дней)

Название проекта: ________________________________________________

Дата проверки: _______________

Ответственный: _____________________________________________________

0–2 положительных ответа: Проект находится в нормальном рабочем состоянии. Повторите проверку через 60 дней.

●

3–5 положительных ответов: Высокий риск попадания в один из шести сценариев провала. Требуется вмешательство спонсора проекта для устранения организационных блокеров.

●

Более 5 положительных ответов: Проект формально или фактически мертв. Продолжение финансирования в текущем виде – растрата ресурсов. Остановите работы, проведите аудит процессов и пересоберите рамки задачи.

Глава 3. Сопротивляются не люди, а система стимулов

За пятнадцать лет работы в качестве директора по персоналу и бизнес-тренера я провела сотни тренингов по управлению изменениями. Я учила топ-менеджеров эмпатии, активному слушанию и фасилитации фаз горевания по Кюблер-Росс. Мы рисовали красивые плакаты, делали командные упражнения, и на эмоциональном подъеме люди в залах обещали начать «новую цифровую жизнь» с понедельника.

А в понедельник они возвращались на свои рабочие места и продолжали делать ровно то же самое, что и до тренинга.

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

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

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

Архитектура системного противоречия

Давайте проанализируем несколько классических ситуаций, с которыми я столкнулась в проектах цифровизации.

1. Ловушка «Утилизации и удержания»

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

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

Что делает рациональный менеджер? Когда клиент звонит ему, чтобы оформить заказ, менеджер тихим голосом говорит: «Алексей Иванович, вы через портал не заказывайте, там база иногда лагает и цены некорректно подтягиваются. Вы мне на почту списочек сбросьте, я сам всё вобью и сделаю вам скидочку 2%».

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

2. Конфликт бюджетного цикла

Цифровизация требует права на гипотезу и быстрый эксперимент. Но традиционный бюджетный цикл компании строится на принципах годового планирования и жесткого контроля перерасхода.

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

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

●

Составить ТЭО (Технико-экономическое обоснование) на 15 страницах;

●

Пройти три комитета (бюджетный, IT и по рискам);

●

Дождаться пересмотра бюджета в следующем квартале.

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

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

3. Безопасность или скорость

IT-департамент и служба безопасности живут в разных системах координат.

●

У IT-директора и трансформаторов KPI завязан на время выхода продукта на рынок (Time-to-Market) и автоматизацию процессов.

●

У директора по безопасности KPI завязан на ноль инцидентов (утечек, сбоев, проникновений).

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

Поэтому регламент согласования доступов для подрядчиков пилотного проекта пишется так, чтобы максимально обезопасить подразделение СБ. В результате разработчики ждут доступы к тестовой среде по три недели. Проект заваливает сроки, а на отчетной встрече CISO с гордостью рапортует: «За прошедший квартал ни одной утечки не допущено».

Карта конфликтующих стимулов

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

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

Инструмент: Карта конфликтующих стимулов

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

Бланк аудита стимулов и барьеров

Как работать с инструментом:

Выберите ключевой процесс, где тормозит внедрение изменений.

Опросите сотрудников анонимно или на фокус-группах с простым вопросом: «Если вы завтра сделаете то, что от вас требует новый регламент/система, как это отразится на вашем годовом бонусе или ежедневной нагрузке?»

Заполните первые четыре колонки. Вы увидите, что 90% саботажа — это логичная самооборона.

Зафиксируйте решения в пятой колонке и не запускайте технологические изменения до тех пор, пока не перепишете противоречащие регламенты и показатели.

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