Только 3% проектов цифровой трансформации всерьёз результативны. Что же делать?

Д. Левин: Питер Шродер (Peter Schroder) — основатель и CEO компании Aras, одного из лидирующих PLM-вендоров. Ниже помещаю вполне наглядную картинку из нашей недавней публикации «У какого вендора PLM лучше?», а здесь приведу характеристики Aras из Википедии:

Aras — частная компания, основанная в 2000 году в США. С 2007 года компания поставляет PLM корпоративного уровня Aras Innovator в качестве бесплатного ПО с открытым кодом, зарабатывая на сопровождении и консалтинге на основе подписки. Наряду с базовым PLM, Aras Innovator применяется для планирования качества и экономичной разработки продуктов, организации коллективной работы и др. Он основан на Microsoft .NET Framework и SQL Server. В июле 2020 года Aras объявил о выпуске нового продукта Digital Twin Core, с помощью которого в рамках Aras-пакета для low-code (с минимальным применением программирования) разработок будут строиться цифровые двойники.

До того как Питер Шродер основал Aras, он занимал пост руководителя американского отделения Eigner + Partner, поставщика PDM, затем поглощенного компанией Agile Software. Питер имеет диплом Cornell University в области электротехники.

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

Ральф Грабовски озаглавил своё изложение доклада Шродера «Agility Eats Black Swans for Breakfast» / «Agility проглотит черных лебедей на завтрак», а в программе конференции доклад называется «Empowerment—The Missing Ingredient to Digital Transformation» / «Расширение прав и возможностей — недостающая составляющая цифровой трансформации (ЦТ)». Исконное название передаёт мессидж главы Aras: для успеха ЦТ следует гораздо больше инициативы передавать от начальников к реальным специалистам — инженерам и низовым экспертам. Что же касается вынесенной в заголовок данной публикации жесткой оценки ЦТ от агентства McKinsey, в реальной жизни она, на мой взгляд, существенно смягчается тем, что конструктивных определений (успешности) цифровой трансформации нет и быть не может, поэтому любой руководитель имеет возможность с довольно-таки широкой степенью раскованности сам оценить результаты проведенной им модной трансформации и, если потребуется, сообщить об этом мировой общественности и/или своему начальству.

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

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

Давайте назовём 2020 год «Годом выученных уроков». Однако должен вам сказать, что это был не один черный лебедь, их была целая стая.

Известно высказывание, которое я использую годами: «Ни один план не переживет первой встречи с противником». Были ли у вашего проекта такие жесткие планы, что их легко нарушить?

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

Следует спросить себя: Была ли наша реакция на кризис адекватной? Как именно мы отвечаем на кризис, действительно имеет важное значение, тем более что обратная сторона кризиса — это новые возможности. Наш ответ — быстрота, адаптивность (resilience) и гибкость (agility). Гибкость способна съесть черных лебедей на завтрак.

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

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

Гроссмейстерское планирование проектов

Во всех компаниях ЦТ реализуется на основе решений высшего руководства. Имея в виду некоторую аналогию, назовём такой подход «гроссмейстерским». Один из больших начальников (уровня С — Chief или назначенный ответственным умный парень) управляет проектами ЦТ, сообщая, что следует делать в тех или иных случаях. При этом имеются большие амбиции, подразумевающие применение искусственного интеллекта, больших данных, машинного обучения — всё это нам хочется реализовать. Однако это не работает. Честно говоря, это оторвано от реальности. Подход «сверху вниз» как следует не работает.

И кстати: все эти модные штучки вовсе не дешевы. Для управления нашими проектами ЦТ мы инвестируем миллионы долларов в озера данных (так это называется?), в переход в облака, чтобы нанять аналитиков данных, сегодня у нас уже есть Chief Data Officers (Главные Управляющие по Данным) — и всё же 80% таких проектов неудачны. Не просто неудачны, но неудачны впечатляюще.

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

Реализуя сверху вниз крупные проекты, мы недооцениваем

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

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

Обработка данных

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

Представим себе типичных PLM-пользователей, они работают со старыми версиями Teamcenter, 3DEXPERIENCE, Windchill или SAP. Путь обновления до современных технологий сопряжен с большими трудностями. Если у нас нет новейших версий, нам не доступны открытость и возможности эффективной интеграции. Как мы собираемся работать с данными в рамках собственной закрытой системы?

В общем смысле я имею в виду, что мы недооцениваем степень нашего технического обременения, возникшего в результате 30-40-летнего накопления мало согласованных между собой данных для разного рода PDM, ERP, CRM, MES…

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

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

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

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

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

Расширение прав и возможностей рядовых сотрудников

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

Черные лебеди становятся обычным делом, мы видим их множество. (Это мой второй оксюморон). Как же в таких условиях вы управляете цифровой трансформацией? Теперь не существуют CIO-гроссмейстеры, способные в одиночку сверху вниз насаждать ЦТ. Нам следует распределить права принятия решений и делегировать их вниз — в окопы, туда, где находится реальное операционное знание.

Несколько лет назад все программные разработки нашей компании Aras были переведены в режим SAFe (scaled agile framework; например, см. русскоязычную статью). Соответствующая схема приведена ниже. SAFe поддерживает хорошо структурированный вариант распределенного принятия решений, при котором права и средства принятия решений спускаются на все нижние уровни и — самое главное — на уровень окопов. У нас это сработало чрезвычайно эффективно. Мы заменили пешки на многомерных ферзей.

Элементы масштабируемой гибкой платформы для предприятий

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

Мы наблюдали, как наши клиенты начинали с установки Aras PLM параллельно с ранее используемым TeamCenter, постепенно перемещая рабочий процесс от одной системы к другой. Это отличный способ выполнять работу эффективно и успешно. Это итеративно: мы говорим об эволюции, а не о революции.

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

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

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

www.aras.com