Текст книги "Почему цифровая трансформация не дает результата и что делать, чтобы всё заработало"

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

Ранее в этой главе – там, где речь идет про статью Джоша Берсина для Harvard Business Review[26]26
  Там же.


[Закрыть], – я уже упоминал о роли руководителя в постановке целей и включении их в стратегию. Обязательные элементы этой деятельности, которые перечисляет Берсин, включают многие культурные и организационные факторы. Превращение конкретных рабочих целей в элементы стратегии трансформации – как разовое, так и постоянное – должно осуществляться руководством (генеральным директором, владельцем бизнеса, главой правительства и т. д.).

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

Менее изучена, но не менее важна роль руководителя в преодолении препятствий в ходе трансформации. Жаль, что этой задаче, как правило, не придают особого значения – а между тем это и есть причина неудач большинства преобразований. Чем сложнее изменение (независимо от ступени трансформации), тем сильнее потребность в лидере, способном и готовом смести любые препятствия на пути вперед. Неудивительно, что на ступени 5 трансформации особенно остро необходима поддержка такого лидера, поскольку ставки высоки, а перемены трудны. Исторический успех P&G как в разработке блестящих принципов стандартизации, так и в масштабировании финансовых систем, продаж и цепочек поставок служит тому доказательством. Это прекрасный пример управления сложнейшей первой ступенью трансформации с опорой на заинтересованность со стороны руководства компании и ответственное владение стратегией. Этот проект не имеет отношения к нашей главной истории – формированию структуры NGS, однако он демонстрирует ключевую роль кураторов преобразований в преодолении возникающих препятствий.

Procter & Gamble – одна из немногих крупных международных компаний, обладающих единой стандартной системой планирования ресурсов предприятия (ERP) для осуществления глобальных операций. По сути, это стандартный цифровой «костяк» платформ для управления финансами, обработкой заказов, дистрибуцией и производством в сотне с лишним стран. Эта система делает возможным единообразное планирование и выполнение финансовых и физических операций в рамках корпорации по всему миру. ERP-системы – основа большинства компаний. P&G использует SAP.

С точки зрения автоматизации переход на единую ERP-систему во всем мире для большинства глобальных компаний – заветный святой Грааль. А это ступень 1 трансформации. Мы в P&G поднялись на эту ступень еще в начале 2000-х, но, что еще важнее, по-прежнему ведем необходимые на этой ступени работы, несмотря на постоянное приобретение новых бизнесов, требующее интеграции ERP-систем этих компаний в нашу единую систему. Привести к общему стандарту ERP-систему – задача чрезвычайно сложная, но еще сложнее придерживаться принятого стандарта и сохранять единообразие системы, несмотря на внедрение новых элементов и реструктуризацию. Чем крупнее организация, чем сложнее она устроена, тем труднее проводить трансформацию.

В том, что P&G удалось добиться этих целей, заслуга руководства компании с его заинтересованностью и владением стратегией. Рабочая цель ясна – запустить глобальное масштабирование бизнеса, используя единую ERP-систему. Интереснее роль руководства в преодолении препятствий на пути множества проектов, связанных с ERP-системами: эти препятствия появляются и в ходе заключения сделок по покупке новых бизнесов, и вследствие изменений в законодательстве и налоговой базе, и по другим причинам.

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

Когда в 2005 году корпорация Procter & Gamble приобрела компанию Gillette (стоимостью более чем 10 миллиардов долларов), я переехал в Бостон, где располагался головной офис Gillette, в качестве временного директора по информационным технологиям. У Gillette на тот момент была изумительная ERP-система, также основанная на SAP и специально приспособленная под нужды ее бизнеса – под бритвы и батарейки[27]27
  По состоянию на 2005 год Duracell была дочерней компанией Gillette (бренд был выкуплен ею еще в 1996 году). – Прим. пер.


[Закрыть]. Неизбежно возникли вопросы: какие процессы и системы Gillette должны будут измениться, чтобы соответствовать стандартам P&G, и что, напротив, P&G может позаимствовать из практики Gillette? Количество обострившихся проблем исчислялось сотнями.

Однако, как это водится в P&G, произошла волшебная синхронизация действий между кураторами изменений и командой, ответственной за проект по преобразованию ERP. В процесс были вовлечены первые лица компании, они контролировали происходящее еженедельно, а то и ежедневно. Решения принимались самые разные – стоит ли отсрочить перевод данных из одной системы в другую, чтобы не усложнять и без того загруженный сезон рождественских продаж, как модернизировать средства обеспечения корпоративной финансовой отчетности… Исполнительной команде проекта пришлось нелегко, но без активных действий кураторов по устранению препятствий мы никогда не добились бы успеха – и тем более успеха в масштабах отрасли. Все это очень типично для P&G – и обеспечивает крепкую поддержку жизнеспособности системы единых ERP-процессов по всему миру.

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

Цифровая грамотность – вызов руководителям

Эпоха бросает руководителям личный вызов по поднятию уровня цифровой грамотности – причем руководителям самых высоких уровней, включая генеральных директоров в государственном и частном секторе. Страшно? Чтобы управлять деятельностью, основанной на цифровых технологиях, необходимо эти технологии ценить и понимать, что несколько сложнее, чем стать просто «уверенным пользователем». Конечно, не всякий руководитель способен «кодить» на C++, как сингапурский премьер-министр Ли Сянь Лун, но всем необходимо как минимум обзавестись знаниями о текущем технологическом потенциале, причем как можно быстрее. Бизнес тоже «искусство возможного», и эффективный руководитель должен хотя бы приблизительно представлять, как могут повлиять на бизнес искусственный интеллект, программные роботы или платформенные решения.

IT-индустрия, где любят раздувать ажиотаж вокруг технологий, не очень помогает разобраться в этом вопросе. Беда в том, что главы многих компаний в вопросах цифровой стратегии слишком полагаются на мнение своих подчиненных – руководителей IT-отделов и директоров по цифровым технологиям. Проблема здесь, однако, состоит в том, что стратегия прорывных цифровых преобразований, задача которых – создание новых бизнес-моделей для всего предприятия в целом, отличается от корпоративной IT-стратегии, которая необходима для управления автоматизацией и продуктивностью повседневной деятельности. Не так давно было подсчитано, что 68 % затрат на технологии сейчас финансируется не из бюджетов IT-департаментов. Конечно, можно делегировать задачи по созданию новых прорывных бизнес-моделей главе IT-отдела или директору по цифровым технологиям, но гораздо эффективнее будет сделать из каждого руководителя в вашей компании сносного цифрового лидера. Руководители всех служб, всех бизнес-подразделений должны быть способны принимать решения, как именно будет переходить на цифровую основу их часть предприятия, и нести за них ответственность.

Цифровая грамотность – вызов членам советов директоров

К сожалению, чем выше должность, тем заметнее становится недостаток цифровой грамотности у руководителя. В конечном счете именно совет директоров несет ответственность за понимание тенденций развития цифровых технологий и определение соответствующего вектора движения компании. Если мы посмотрим на первую пятерку крупнейших мировых компаний, то в каждой из них увидим так называемых «цифровых директоров» – руководителей, знающих толк в «цифре». Примеров масса и среди давно известных фигур: сооснователь Microsoft Билл Гейтс, бывший председатель совета директоров Intel Энди Брайант, бывший генеральный директор телекоммуникационной компании Qwest Communications Эд Мюллер, бывшие президент и генеральный директор Yahoo Сьюзен Декер и Марисса Майер, генеральный директор Xerox Урсула Бернс, бывший председатель совета директоров IBM Сэм Пальмизано, сооснователь Instagram Кевин Систром, исполнительный вице-президент американской телекоммуникационной корпорации Comcast Стив Берк. Однако это не является нормой. По оценкам консалтинговой компании McKinsey & Company, менее чем в 20 % компаний члены советов директоров обладают адекватной требованиям современного мира цифровой грамотностью и менее 5 % компаний в Северной Америке имеют в своем составе комитет по технологиям. Таким образом, правления многих компаний просто-напросто совершенно не готовы к цифровой эпохе, особенно если учитывать, что угрозы существованию компании могут исходить от смежных сфер рынка и отраслей промышленности. Традиционный стиль работы, который привел к успеху членов советов директоров, может в итоге погубить компанию.

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

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

⁂

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

■ Мир цифровых технологий – относительно новая и стремительно меняющаяся сфера. Он требует особой вовлеченности руководителей компаний и организаций.

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

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

■ Еще более важная задача руководителя состоит в преодолении препятствий в процессе воплощения стратегии цифровой трансформации. Успешная работа единой стандартизированной системы планирования ресурсов предприятия в P&G по всему миру служит примером содействия цифровой трансформации за счет способности быстро справляться с любыми препятствиями.

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

Оцените степень вашей цифровой трансформации, руководствуясь нижеприведенными вопросами, чтобы дисциплинированно проследовать по всем ступеням «Цифровой трансформации 5.0».

Глава 4
Итеративное выполнение

1 октября 2013 года, четверг, полночь – знаменательный момент для команды, ведущей проект по разработке федерального веб-портала для программы «Доступное здравоохранение» (Affordable Care Act, ACA) – HealthCare.gov, известной в народе как Obamacare. Когда сайт, функционирование которого контролировали рабочие группы Medicare и Medicaid[28]28
  Medicare и Medicaid – национальные программы медицинского страхования в США, учрежденные в 1965 году. – Прим. пер.


[Закрыть], а также их подрядчики, был открыт для пользователей, первоначальные отзывы оказались довольно положительными. Трафик в сети был выше, чем ожидалось: прекрасная новость для команды Белого дома, где тревожились за показатели по участникам программы.

Однако в офисе CGI Federal, одного из главных разработчиков сайта, настроения были не такие радужные. IT-специалисты постепенно осознавали, что из-за избыточного трафика все трещит по швам, в то время как у посетителей при попытке создать аккаунт сайт ужасно тормозил, а вскоре и вовсе рухнул. Едва ли такой сомнительно удачный старт порадовал президента Барака Обаму: его коронная законодательная инициатива в итоге сработала, но была слегка запятнана техническими несовершенствами.

Но на самом деле проблема с сайтом Obamacare не сводилась к техническому сбою, а заключалась скорее в нехватке дисциплины. Увы, для многих организаций это обычное дело – когда IT-проект идет наперекосяк. Да, проект HealthCare.gov был крупным и комплексным, но совершенно непонятно, почему разработчики не применили итеративный подход, чтобы избежать «большого взрыва» на старте и решать мелкие технические проблемы по мере их выявления. В контексте работы над ПО это называется «гибкая методология разработки» (или аджайл): для создания портала «Доступного здравоохранения» прибегали и к ней, но лишь частично, в основном работали по методу «большого взрыва», также известному как «водопад», когда за длинными этапами проектирования и разработки следует крупный запуск.

Но, если говорить о цифровой трансформации, чем крупнее проект, тем больнее падать. Минимизация рисков в ходе цифровых преобразований (как на первой ступени, так и на последующих) за счет разделения процесса на более мелкие итеративные этапы и постоянного анализа полученных результатов – ключевой принцип, помогающий избежать громких провалов. Разумеется, он применяется не только при разработке программного обеспечения. Из него выросла и концепция «Бережливый стартап», призванная указать крупным и мелким предприятиям, что можно сократить цикл разработки продукта и ускорить выявление жизнеспособности бизнес-модели. Задача состоит в том, чтобы использовать несколько небольших экспериментов по проверке гипотез, дабы подтвердить результаты анализа, прежде чем осуществлять итеративный запуск продуктов.

Первый сайт компании Amazon был запущен в июле 1995 года: ничего общего с сегодняшним «гладким» дизайном, интеллектуальными алгоритмами и техническими возможностями, только каталог книг и кнопка размещения заказа. Внутренние операции компании также были довольно простыми – сотрудники собственноручно доставали книги, упаковывали их и отвозили на почту. Зато Amazon прекрасно умел пользоваться тем, что работает, и избавляться от того, что не работает, упрямо двигаясь к цели, какой ее видел основатель Джефф Безос: в один прекрасный день стать «магазином всего на свете».

Заминка с запуском портала HealthCare.gov представляет собой прекрасный урок: хотите избежать громких провалов – положитесь на итеративную модель разработки, и не только в случае с небольшими частными проектами. Как применить этот подход к комплексным программам, состоящим из множества проектов, – скажем, таким, как трансформация всего предприятия?

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

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

Почему возникли проблемы на стадии запуска портала HealthCare.gov?

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

Напомню, что Закон о защите пациентов и доступном здравоохранении, или Закон о доступном здравоохранении, чаще всего именуемый Obamacare, должен был стать коронной законодательной инициативой президента Барака Обамы. Закон, подписанный 23 марта 2010 года, был нацелен на сокращение числа незастрахованных граждан в США. На разработку портала HealthCare.gov отводилось около трех с половиной лет, запуск был запланирован на 1 октября 2013 года. Наступила полночь, и тут же несколько тысяч пользователей попытались зарегистрироваться в программе. Сайт быстро упал. Изначально предполагалось, что слабое звено – неспособность справиться с трафиком при массовых попытках авторизоваться на сайте. Но, как только эта причина была устранена, вылезли другие проблемы. На устранение всех этих технических неполадок ушли месяцы. Когда пыль улеглась, то к концу периода открытой регистрации, который официально завершился 15 апреля 2014 года, примерно 13,5 миллиона человек подали заявки на страховое покрытие, а около 8 миллионов выбрали страховую программу. Это было выше целевых показателей, что свидетельствует об успехе самой политики здравоохранения, но проблемы с порталом, увы, испортили все впечатление.

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

Чем крупнее проект, тем больнее падать. IT-проект HealthCare.gov был гигантом. Согласно журналу Forbes, в нем принимали участие 55 подрядчиков, пять федеральных агентств, 36 штатов, 300 частных страховых компаний и более 4000 страховых программ. Предполагалось, что рядовой пользователь портала просмотрит около 75 страниц сайта (а всего сайт насчитывал более 1000 страниц). Понятно, что проект был обречен на масштабность. Большинство крупных организаций, преследующих серьезную прорывную цель, скорее всего, тоже будут вынуждены работать с масштабным проектом. Вопрос заключается в том, как превратить вашего монстра в кучу безобидных монстриков.

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

Непонятно, кто главный. Опыт портала HealthCare.gov может послужить хорошим уроком в плане распределения ответственности. Кэтлин Себелиус, секретарь Министерства здравоохранения и социальных служб США, обеспечивала прямой доступ к президенту Обаме в ходе проекта. Она назначила директора по информационным технологиям для управления своими IT-проектами. В служебной записке, датированной августом 2011 года, офис Административно-бюджетного управления Белого дома настоятельно рекомендовал, чтобы директор по информационным технологиям взял на себя ответственность за все проекты в IT-сфере. Но на деле этого так и не произошло.

Проектом управляло федеральное агентство министерства здравоохранения – Центр по обслуживанию программ Medicare и Medicaid (CMS). Дальше – больше, в CMS решили произвести интеграцию систем своими силами, то есть взяли на себя ответственность за управление отношениями с различными партнерами по разработке, а также за техническое сведение воедино всех решений. Проблема заключалась в одном: у CMS было недостаточно ресурсов, чтобы выступить в роли системного интегратора. Хуже того, CMS терзали серьезные внутренние распри – по поводу и чисто пользовательской составляющей, и технических аспектов работы сайта. В результате подрядчики не получили необходимых инструкций. Ничто так не тормозит проект, как размывание ответственности.

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

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

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