Перевод этой книги подготовлен сообществом "Книжный импорт".
Каждые несколько дней в нём выходят любительские переводы новых зарубежных книг в жанре non-fiction, которые скорее всего никогда не будут официально изданы в России.
Все переводы распространяются бесплатно и в ознакомительных целях среди подписчиков сообщества.
Подпишитесь на нас в Telegram: https://t.me/importknig
Перезагрузка. Руководство McKinsey по преодолению конкуренции в эпоху цифровых технологий и искусственного интеллекта
Оглавление
"Отличное руководство по цифровой трансформации и трансформации с использованием искусственного интеллекта, в котором представлен комплексный подход к ключевым элементам, необходимым для достижения успеха, включая формирование талантов, внедрение новых операционных моделей, использование передовых технологий и внедрение данных. Обязательно к прочтению для любой организации, стремящейся сохранить конкурентоспособность в цифровую эпоху".
Мэтт Андерсон, директор по цифровым технологиям, The Carlyle Group
"Сочетая оригинальные исследования с реальными примерами из практики, Ламарре, Смае и Земмель демонстрируют, что цифровая трансформация и трансформация с помощью ИИ вышли за рамки модернизации систем и технологий. Они доказывают, что максимальное использование цифровых преимуществ сегодня предполагает смелое переосмысление вашего бизнеса, от стратегии до реализации, с учетом возможностей искусственного интеллекта, данных и передовой аналитики. В этой книге подробно описаны идеи управления талантами и организационных преобразований, которые должны быть в центре внимания любого руководителя, стремящегося продвинуть свою компанию по шкале цифровой зрелости. Благодаря своей ясности и полноте "Rewired" станет настольной книгой для тех, кто хочет использовать цифровые инновации для достижения конкурентоспособных бизнес-результатов".
Д-р Альберт Бурла, председатель совета директоров и генеральный директор компании Pfizer
"Победа в цифровую эпоху требует дифференцирующей стратегии, уникальных возможностей и смелых решений. Rewired" не ограничивается вопросами "что", а углубляется в "как". В книге подробно описаны реальные перемены, и она представляет собой убедительное руководство к действию для современных лидеров, готовых совершить скачок".
Беттина Дитше, директор по персоналу и культуре, Allianz Group
"Rewired" - это практическое и продуманное руководство по переходу на цифровые технологии, где технологии и данные служат основой для модели работы компаний в качестве цифровых предприятий. Становление цифровым предприятием - это постоянное путешествие, которое требует постоянного переосмысления талантов, организации и лежащих в основе технологий и данных для создания конкурентного преимущества. Эта книга дает представление о возможностях и структурах, необходимых для победы".
Джули Диллман, исполнительный вице-президент, старший исполнительный директор по операциям и технологиям и специалист по цифровой трансформации, Chubb Group
"Rewired" - это лучшее справочное руководство по цифровой трансформации, которое я видел, с подробным описанием того, как это сделать и добиться результатов. Мы находимся на пути к переосмыслению себя как лидера в области цифровой печати и цифровых упаковочных решений. Rewired будет рекомендована к прочтению моей команде".
Тед Доэни, президент и генеральный директор корпорации Sealed Air
Если у вашего бизнеса есть цифровые возможности и проблемы, и вы стремитесь к успеху, независимо от того, где вы работаете - в зале заседаний совета директоров или в проектной комнате, и независимо от отрасли, "Rewired" - это книга для вас. Она сочетает в себе четкое представление о том, что важно, с ясным руководством о том, как этого добиться, а также подробные прагматические схемы и рекомендации, которые помогут вам на этом пути. Это обязательный к прочтению справочник, практическое руководство и поставщик решений. Держите ее под рукой - я так и сделаю!"
Рона Фэйрхед, совет директоров Oracle; пожизненный член Палаты лордов Великобритании; председатель совета директоров RS Group plc; бывший председатель и генеральный директор Financial Times Group Ltd.
"Как утверждают авторы книги Rewired, каждый руководитель до конца своей карьеры будет работать над использованием технологий, чтобы превзойти конкурентов. Это кажется особенно верным, поскольку искусственный интеллект становится все более значительной частью нашей жизни и бизнеса, заставляя нас переосмыслить, как меняться, и делая Rewired одновременно своевременной и нестареющей. Но эта книга помогает представить ИИ и технологии в перспективе, разбивая механику изменений и описывая все, что нужно сделать, чтобы технологии оказали влияние на ваш бизнес, - от формирования кадрового резерва для цифровых технологий до внедрения современных методов разработки программного обеспечения и организации предприятия для обеспечения непрерывных цифровых инноваций."
Роджер В. Фергюсон-младший, член совета директоров Alphabet Inc, Corning и IFF;
бывший президент и генеральный директор TIAA
"Книга Rewired представляет собой подробное, но в то же время простое и понятное руководство по разработке и реализации цифровой трансформации и трансформации с использованием искусственного интеллекта. Хотя ни одна трансформация никогда не бывает простой, Rewired предоставляет четкую дорожную карту для создания возможностей предприятия и конкретные примеры, которые значительно повысят шансы вашей организации на успех".
Джефф Харменинг, председатель совета директоров и генеральный директор компании General Mills
"Одна из главных проблем цифровой трансформации и трансформации с использованием искусственного интеллекта заключается в технологиях, которые лежат в ее основе. Технологии сложны, быстро меняются, и они необходимы любой компании, которая хочет создать отличный цифровой опыт. Для многих руководителей эта реальность может быть довольно пугающей. Но умение работать с технологиями сегодня необходимо любому руководителю. Rewired - одна из лучших книг, которые я читал, объясняющая то, что руководители должны знать, на уровне, который одновременно понятен и достаточно подробен, чтобы быть значимым. Это отличное пособие для тех руководителей, которые хотят по-настоящему разобраться в технологиях".
Питер Якобс, генеральный директор, ING Bank Netherlands
"Технологии меняются так быстро, что порой кажется, что за ними невозможно угнаться. Но Rewired показывает путь вперед, не только разъясняя роль технологий, но и показывая, как их применять для достижения конкурентного преимущества".
Д-р Маркус Креббер, генеральный директор, RWE AG
"Переосмысление бизнеса в цифровую эпоху - настоятельная необходимость для современных руководителей предприятий, и Rewired - это практическое руководство, которое проведет их по пути создания или изменения бизнес-процессов, возможностей, культуры и клиентского опыта для обеспечения устойчивой стоимости. В типичной манере McKinsey, эта проницательная книга делает задачу преобразований с помощью технологий еще более доступной и практичной!"
Чуа ("СК") Сок Кунг, член совета директоров Bharti Airtel, Prudential, Royal Phillips,
Корпорация Ayala; бывший генеральный директор компании Singtel
"Цифровая трансформация" - одно из тех выражений, которые многие используют, но не многие понимают. Ламарре, Смае и Земмель оказали уникальную услугу, отфильтровав все сложности и сделав их понятными". Цифровая трансформация для крупной компании - сложная задача, как ни крути. Но Rewired предоставляет четкую карту того, как собрать все части и объединить их вместе, чтобы компании могли не только меняться, но и использовать потенциал новых технологий для создания конкурентных преимуществ".
Чак Магро, генеральный директор, Corteva Agriscience
"История цифровых технологий в adidas - это история о том, как делать много вещей хорошо, одновременно, в рамках глобальной организации. Масштаб этой задачи просто фантастический, и она потребовала от нас разработки порой обескураживающего набора новых возможностей, при этом оставаясь верными тому, что делает нас особенными для наших потребителей. Книга Rewired отражает эту сложность и предлагает четкий набор действий и шагов для ее решения. Эта книга - абсолютный must- read для любого руководителя, стремящегося возглавить транснациональную компанию и воплотить обещания цифровых технологий в реальность".
Мартин Шэнкленд, член исполнительного совета по глобальным операциям, adidas
"Чтобы оставаться конкурентоспособными и занимать передовые позиции в любой отрасли, очевидно, что компании должны постоянно адаптироваться и развиваться вместе с технологиями. Rewired решает ключевой вопрос "как": предоставляет план трансформации бизнеса и готовит к сложностям, которые возникают на этом пути".
Робин Винс, президент и генеральный директор, BNY Mellon
Книга "Rewired" представляет собой "единую теорию поля", основанную на всех элементах, которые создают конкретные практические подходы, помогающие компаниям перейти от разрозненных цифровых проектов к сквозному созданию настоящего цифрового предприятия. Книга дает команде высшего руководства руководство, необходимое для согласования целей, людей, процессов и технологий, а также для преобразования операционной модели, ритма работы и результатов компании. Только благодаря тому, что команда генерального директора сама возглавит этот путь, вы сможете стать цифровым лидером в своем конкурентном пространстве и создать устойчивую ценность для клиентов, акционеров и других заинтересованных сторон".
Рон Уильямс, член совета директоров компаний Boeing, agilon health, Warby Parker; председатель и генеральный директор,
RW2 Enterprises; бывший председатель и генеральный директор компании Aetna
Что мы понимаем под цифровой трансформацией и трансформацией с помощью искусственного интеллекта?
Цифровая трансформация и искусственный интеллект - это то, что нужно для развития организационных и технологических возможностей, которые позволяют компании постоянно совершенствоваться и повысить качество обслуживания клиентов, снизить себестоимость единицы продукции и со временем сохранить конкурентное преимущество.
процесс
Введение
Возможности предприятия, которые превращают цифровые технологии и ИИ в источник постоянного дохода и конкурентное преимущество
Лидеры бизнеса будут заниматься цифровыми преобразованиями своих компаний до конца своей карьеры.
Это утверждение отражает две фундаментальные реальности: первая заключается в том, что цифровые технологии постоянно меняются. За последнее десятилетие цифровые технологии проникли практически во все сферы нашей жизни благодаря слиянию новых технологий (например, облачных вычислений, ИИ), новых архитектурных парадигм (например, микросервисов, API) и новых способов создания программного обеспечения (например, agile, DevSecOps), унаследованных от технологической индустрии. И мы даже не потрогали поверхность генеративного ИИ, вычислений на границах, квантовых вычислений и других передовых технологий.
Пока технологии продолжают развиваться, будет развиваться и ваш бизнес. По этой причине само слово "трансформация" немного вводит в заблуждение, поскольку подразумевает одноразовую программу с конечным результатом. На самом деле цифровая трансформация - это путешествие, направленное на постоянное повышение конкурентоспособности.
Вторая фундаментальная реальность заключается в том, что цифровые преобразования и преобразования с использованием искусственного интеллекта даются нелегко. По данным нашего последнего ежегодного исследования, 89 % компаний приступили к цифровой трансформации. Но они получили лишь 31 % от ожидаемого прироста прибыли и реализовали только 25 % от общей ожидаемой экономии затрат.
К сожалению, быстрых решений не существует. Вы не можете просто внедрить систему или технологию и закончить. Мы видим, что у лидеров цифровых технологий нет одного "волшебного" сценария использования. Вместо этого необходимо иметь сотни технологических решений (собственных и готовых), работающих вместе, которые вы постоянно совершенствуете для создания отличного опыта для клиентов и сотрудников, снижения себестоимости и генерирования стоимости. Создание, управление и развитие этих решений требует от компаний коренной перестройки своей работы. Это означает, что тысячи людей в разных подразделениях организации должны работать вместе и работать по-другому. Это означает привлечение новых талантов и разработку циклов ускоренного обучения, которые используют их навыки и помогают им расти. Как бы ни были важны технологии, цифровые преобразования и преобразования с использованием ИИ также в значительной степени связаны с развитием новых организационных возможностей.
Ни одной компании не чужда эта борьба. Даже известным нам технологическим компаниям приходится инвестировать, экспериментировать, терпеть неудачи и адаптироваться, чтобы добиться успеха. Возьмем, к примеру, розничный бизнес Amazon. Она автоматизировала работу с поставщиками, пополнение запасов, ценообразование и выполнение заказов. Все эти процессы были автоматизированы с помощью собственных решений, разработанных тысячами кросс-функциональных команд, состоящих из специалистов по бизнесу, технологиям и операциям. Но все начиналось не так - даже Amazon не был тем "Амазоном", который мы знаем сейчас. Она перестроилась, инвестируя в технологии и возможности предприятия - и постоянно совершенствуя их с течением времени, - чтобы стать цифровой до мозга костей".
Успех Amazon хорошо известен, но есть и хорошие примеры крупных, состоявшихся компаний, которые побеждают в гонке цифровых и искусственных преобразований и создают большую цифровую дистанцию между собой и своими конкурентами. В основе этих успехов лежат уроки, полученные с большим трудом, которые вылились в рецепт того, что работает. Эта книга - такой рецепт. Эта книга - их история.
Цифровые технологии как источник конкурентного преимущества
Не так давно руководители крупных компаний часто предпочитали откладывать изменения в своих основных системах, потому что "это было бы дешевле и менее рискованно сделать это позже, когда система будет протестирована и проверена другими". Руководители говорили: "Мы хотим покупать стандартные пакеты... создавать индивидуальные - слишком дорого и сложно". Технологии, конечно, были необходимы для работы компании, но они редко давали конкурентное преимущество, потому что любая компания могла купить ту же самую технологию у поставщиков. Преимущество, если оно и было, заключалось в том, чтобы развернуть эти системы в срок и в рамках бюджета, а также эффективно использовать приобретенные возможности.
Все изменилось и перевернулось с ног на голову. Компании по-прежнему покупают системы у поставщиков для управления своими предприятиями, но развитие цифровых технологий и связанные с этим новые архитектурные парадигмы и способы разработки программного обеспечения позволяют также разрабатывать и поддерживать собственные приложения. По мере становления и развития индустрии программного обеспечения появилась цепочка поставок программного обеспечения, в которой вы можете разрабатывать приложения, собирая их из существующих программных блоков и разрабатывая новый код только там, где это необходимо. Эти разработки, а также новые, такие как генеративный искусственный интеллект, радикально снижают стоимость и время разработки собственных приложений и позволяют любой компании конкурировать на этой основе уже сейчас.
Так где же те примеры состоявшихся компаний, которые создали конкурентное преимущество за счет цифровых технологий и получают за это вознаграждение? На эффективность работы компании влияет множество факторов, и, будем откровенны, требуется время, чтобы преобразовать компанию настолько глубоко, чтобы результаты отразились на ее финансовых показателях. Тем не менее, вопрос остается принципиальным. Устоявшиеся компании берут на себя значительные организационные и финансовые обязательства по внедрению цифровых технологий. Низкий процент успеха заставляет задуматься о том, стоит ли все это затраченных усилий.
Наш собственный анализ, проведенный в ходе многолетних исследований, ясно показывает, что наиболее эффективные компании добиваются значительных улучшений, когда внедряют ряд цифровых практик.8 Например, наш последний опрос более 1300 руководителей высшего звена показал, что 70 % ведущих компаний используют передовую аналитику для получения собственных знаний; 50 % используют искусственный интеллект для улучшения и автоматизации процесса принятия решений.
Опираясь на эти исходные данные, мы попытались получить твердые эмпирические данные, связывающие цифровую трансформацию с финансовыми успехами. Мы обратились к банковской отрасли, где у нас есть уникальный набор данных по 80 глобальным банкам на развитых рынках. Банковская сфера - это сектор, который проводит цифровые преобразования в течение 5-10 лет, что дает достаточно времени, чтобы увидеть эффект от трансформации.
Наше исследование охватывало период 2018-2022 годов и было сосредоточено на группе из 20 цифровых лидеров и 20 цифровых отстающих, что позволило выявить три основных факта:
Цифровые лидеры превзошли всех. Цифровые лидеры имели лучший показатель рентабельности материального капитала (ROTE) - ключевой финансовый показатель в банковской сфере - и также улучшили его. Аналогичным образом обстоят дела и с коэффициентом P/E. За этот период времени цифровые лидеры обогнали отстающих за счет лучшего операционного рычага. В результате их совокупный доход для держателей акций (TSR) увеличивался на 8,2 % в год по сравнению с отстающими на 4,9 %. Цифровые лидеры были вознаграждены финансово.
Конкурентное преимущество достигается за счет сквозной трансформации бизнес-модели. Мы рассмотрели четыре показателя трансформации бизнес-модели в банковской сфере и то, как эти показатели менялись с течением времени у наших цифровых лидеров и отстающих (Рисунок I.1). Первым показателем было принятие клиентами мобильного банковского приложения. Лидеры опередили отстающих, но и те, и другие добились значительных улучшений. Поначалу это может показаться удивительным, но это не так. Как только один банк вводит новую мобильную функцию, другие следуют за ним в течение 6-12 месяцев. Мобильное приложение - это ставка в банковском деле; оно не обеспечивает конкурентной дифференциации. Большинству банков удалось создать цифровую команду, которая может развивать и улучшать мобильное приложение.
Теперь давайте посмотрим на три других показателя: цифровые продажи и уровень персонала в филиальной сети и контакт-центрах. Эти показатели отражают истинное превосходство в операционной деятельности, и именно здесь лидеры демонстрируют ускоренное улучшение по сравнению с отстающими. Улучшить эти показатели гораздо сложнее, поскольку каждый из них требует сквозной трансформации процессов.
Основные показатели цифровой трансформации в банковской сфере
Отстающие
Лидеры
Принятие мобильных приложений
% от общего числа клиентов, активных в мобильном приложении в течение последних 90 дней
Цифровые продажи
% продаж через цифровой канал
+15
+32
процентные пункты
8
40
70
17
+53
35
32
18
+14
процентные пункты
50
2018
2022
2018
2022
Укомплектование филиальной сети персоналом. Изменение в процентных пунктах среднего количества ЭПЗ в филиальной сети на 100 тыс. клиентов
Персонал контакт-центров. Изменение в процентных пунктах среднего количества ЭПЗ в контакт-центре на 100 тыс. клиентов
С 2018 по 2022 год С 2018 по 2022 год
-29
-20
-11
+20
На переднем этапе этого процесса ведущие банки интегрируют аналитику пер- сонализации и цифровые маркетинговые кампании, чтобы донести до (потенциальных) клиентов актуальные предложения. В середине процесса они создают омниканальный опыт, где специалисты отделений и контакт-центров имеют инструменты и данные для поддержки клиентов на любом этапе пути продаж, даже если этот путь был начат в Интернете. Эти ведущие банки также могут предоставлять одобрение клиентам в режиме реального времени благодаря автоматизированному принятию решений о кредитном риске. На заднем этапе процесса они обеспечивают самообслуживание клиентов благодаря хорошо продуманным цифровым рабочим процессам, поддерживаемым современной архитектурой данных. Одним словом, цифровые преобразования выходят за рамки фронтального мобильного приложения, а также трансформируют маркетинг, продажи, обслуживание и управление рисками.
Важно отметить, что лидеры в области цифровых технологий гораздо быстрее перераспределяют мощности по продажам и обслуживанию, когда клиенты переносят свои банковские операции в интернет. Это кажется простым, но это не так. Это требует изменения стимулов и управления эффективностью работы всего банка. Такой уровень межфункциональной согласованности является основой того, что отличает победителей цифровых технологий в любой отрасли.
Лидеры в области цифровых технологий создают лучшие корпоративные возможности. Мы изучили основные методы работы лидеров и отстающих. Выявились четкие различия. Лидеры пошли дальше в создании качественного цифрового кадрового резерва, сосредоточившись на создании среды, в которой будут работать высококлассные инженеры. Они приняли новую операционную модель, которая объединяет людей из бизнеса, технологий и операционной деятельности для работы в небольших, гибких командах, которые постоянно улучшают качество обслуживания клиентов и снижают себестоимость продукции за счет автоматизации. Они создали современную и распределенную архитектуру технологий и данных, основанную на облачных технологиях, которая позволяет всей организации, а не только ИТ-отделу, разрабатывать цифровые решения и решения на основе искусственного интеллекта. Одним словом, они инвестировали в создание возможностей - талантов, операционной модели, технологий и данных, - которые, в свою очередь, используются их организацией для создания отличного цифрового опыта и его постоянного улучшения.
В конце концов, лидеры цифровых компаний-победителей смелее переосмысливают свой основной бизнес и более сплоченно объединяются в единую команду, выходя из традиционных функциональных силосов, чтобы реализовать свое видение. Они вкладывают больше стратегических средств в создание дифференцирующих возможностей - как организационных, так и технологических, - которые становятся источником их конкурентного преимущества. Со временем эти возможности создают все более совершенные впечатления у клиентов и приводят к снижению себестоимости единицы продукции. Таким образом, они перестраиваются на конкурентную борьбу, и за этим следует финансовое вознаграждение.
Мы убедились, что это справедливо для любой отрасли, будь то B2B или B2C, продукция или услуги. В каждом секторе есть возможность создать значительную ценность за счет цифровой трансформации. Вопрос только в том, как это сделать.
"Как"
Многие из них знакомы с основами цифровой трансформации и трансформации с использованием искусственного интеллекта и ее обещаниями. Некоторые добились значительных успехов на ранних этапах. Но цифровая трансформация и трансформация с использованием искусственного интеллекта в масштабах и темпах, способных изменить стоимость бизнеса, - это совсем другое дело.
Руководителям не хватало подробного описания того, как создать возможности предприятия для достижения эффекта масштаба. Эта книга отвечает на вопрос "как". Это руководство для лидеров, готовых засучить рукава и проделать тяжелую работу, необходимую для успешной трансформации. В ней рассматриваются уникальные проблемы и возможности, создаваемые такими технологиями, как смартфоны, Интернет вещей, искусственный интеллект (включая машинное обучение и глубокое обучение), дополненная и виртуальная реальность, большие данные и аналитика в реальном времени, цифровые двойники, API, облачные технологии и другие. Любая цифровая трансформация и трансформация с использованием искусственного интеллекта опирается на сочетание этих технологий для разработки цифровых решений.
Это руководство - то самое, которое используют наши команды McKinsey по всему миру, работая с нашими клиентами над их цифровой трансформацией и трансформацией с помощью искусственного интеллекта.
ВОЗМОЖНОСТИ ДОСТАВКИ
В книге "Rewired", созданной за последние пять лет, уроки McKinsey воплощены в проверенном на практике руководстве.
Эти уроки состоят из шести разделов, каждый из которых соответствует одной из возможностей предприятия: они начинаются с согласования ценностей и плана с высшим руководством; далее рассматривается создание возможностей для разработки конкурентно способных цифровых решений; и, наконец, рассматриваются аспекты управления изменениями для обеспечения внедрения сквозных бизнес-процессов и эффективного масштабирования в масштабах предприятия (Рисунок I.2).
ВЫРАВНИВАНИЕ ПО ЦЕННОСТИ
1. Под руководством бизнеса Согласование действий высшего руководства по преобразованию
цифровая дорожная карта видение, ценность и дорожная карта ...
... и переосмысление бизнес-сферы, чтобы
Обеспечьте превосходный опыт работы с клиентами Бизнес ... ... ...
и более низкая стоимость единицы продукции Домен
Бизнес-домен
2. Талант
3. Операционная модель
4. Технология
5. Данные
Обеспечить наличие необходимых навыков и возможностей для реализации и внедрения инноваций
Повышение скорости метаболизма в организации за счет объединения бизнеса, операций и технологий
Чтобы вашей организации было легче использовать технологии для внедрения инноваций
Постоянно обогащать данные и упрощать их использование в организации для улучшения качества обслуживания клиентов и совершенствования бизнес-операций.
6. Освоение и масштабирование
Максимальное увеличение стоимости за счет обеспечения внедрения и масштабирования цифровых решений в масштабах предприятия, а также жесткого управления ходом трансформации и рисками
ПРИЛОЖЕНИЕ I.2
УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
В каждом из шести разделов рассматривается одна из важнейших возможностей предприятия. Ни одна цифровая трансформация и трансформация с использованием искусственного интеллекта не может быть успешной без решения всех этих задач - таков главный вывод нашей собственной ретроспективы работы McK- insey с клиентами в этой области за последнее десятилетие.
Мы также включили раздел, в котором рассказывается о том, как три компании прошли путь цифровой трансформации и трансформации с помощью искусственного интеллекта. В общих чертах эти разделы охватывают:
Раздел 1: Создание дорожной карты трансформации
В этом разделе рассказывается о том, как сфокусировать и согласовать лидерскую команду на видении "Северной звезды" и как переосмыслить бизнес с помощью технологий. Принятые в результате решения воплощаются в подробную дорожную карту, которая одновременно основана на результатах и четко определяет новые возможности, необходимые для реализации. Оценивая застопорившиеся цифровые преобразования и преобразования с использованием искусственного интеллекта, мы обнаруживаем, что многие из возникших проблем можно отнести к ошибкам на этом этапе.
Раздел 2: Создание кадрового резерва
Вы не можете отдать на аутсорсинг свой путь к цифровому совершенству. Компании должны обладать возможностями для создания и развития собственных цифровых решений, а для этого необходимы качественные цифровые таланты. Устоявшиеся компании часто думают, что они не могут конкурировать с "цифровыми аборигенами" за таланты, но они могут и хотят. В этом разделе мы подробно расскажем о том, как разработать дорожную карту для талантливых сотрудников, которая будет такой же подробной, как и ваша цифровая карта, в том числе о том, как создать организацию, которая не только сможет нанять лучших, но и создаст среду, в которой они будут процветать.
Раздел 3: Принятие новой операционной модели
Пожалуй, самым сложным аспектом цифровой трансформации и трансформации с использованием ИИ является разработка операционной модели, способствующей клиентоориентированности и скорости. Это связано с тем, что она затрагивает суть организации, ее управленческие процессы и то, как работают многочисленные команды. В этом разделе рассказывается о различных вариантах операционной модели - от цифровой фабрики до организации, построенной на продуктах и платформах, - и даются рекомендации по выбору с учетом реалий вашей организации. В этом разделе также рассказывается о том, как создать и масштабировать такие важные или неважные возможности, как управление продуктами и проектирование пользовательского опыта.
Раздел 4: Технологии для скорости и распределенной инновации
В этом разделе рассматривается, как создать распределенную технологическую среду, которая позволит сотням, если не тысячам, команд предоставлять услуги, необходимые для быстрого создания цифровых технологий.
Мы расскажем о необходимых современных практиках разработки программного обеспечения, включая DevSecOps (разработка, безопасность и операции) и MLOps (операции машинного обучения), которые стали центральными для достижения высокой скорости разработки, качества кода и максимальной операционной производительности.
Раздел 5: Внедрение данных повсюду
В этом разделе рассматриваются критические решения, необходимые для продуманной архитектуры данных, обеспечивающей их качество, простоту потребления и повторное использование. Только в этом случае можно высвободить мощь искусственного интеллекта. Мы рассмотрим, как разрабатывать и внедрять продукты данных (данные, которые упаковываются в удобные для использования форматы для других приложений) таким образом, чтобы обеспечить наибольшую выгоду для бизнеса. В этом разделе также рассматриваются часто возникающие проблемы управления данными и организационные вопросы, которые могут свести на нет даже самые многообещающие продукты данных.
Раздел 6: Ключи к внедрению и масштабированию
Одним из самых удручающих аспектов цифровой трансформации и трансформации с использованием ИИ является то, что даже самые лучшие цифровые решения не оказывают должного влияния. Компании обычно вкладывают средства в первоначальную разработку решения, но хронически недоинвестируют в обеспечение его принятия пользователями и масштабирования в масштабах предприятия. В этом разделе рассматриваются проблемы управления изменениями с акцентом на то, как на достаточно детальном уровне решить технические, технологические и человеческие проблемы, которые мешают отличным решениям приносить максимальную пользу.
Раздел 7: Истории трансформации
В завершение книги мы подробно рассматриваем три компании - Freeport- McMoRan, DBS и LEGO Group, - которые мы считаем лидерами в области цифровой трансформации и трансформации с использованием искусственного интеллекта. В этом разделе показано, как шесть элементов, о которых идет речь в книге, объединяются в этих образцовых компаниях, начиная с того, как они создавали свои возможности, и заканчивая тем, как они работали в команде, чтобы достичь поставленных целей. Эти кейсы рассказывают о поворотах на их пути, проблемах, которые они преодолели, и о том, как им удалось создать отрыв от конкурентов.
В этом руководстве представлен комплексный взгляд на то, как эти элементы лучше всего сочетаются друг с другом. Например, цифровая дорожная карта в первом разделе согласуется с методом отслеживания стоимости в разделе 6. Цифровые таланты, представленные во втором разделе, согласуются с операционной моделью в третьем разделе. Такой комплексный подход является основополагающим для успешных цифровых преобразований и преобразований с использованием искусственного интеллекта, и это было одной из наших главных мотиваций для написания этой книги, поскольку мы обнаружили, что многие компании испытывают трудности с обеспечением общей согласованности преобразований.
Чем эта книга является... и не является
Не ждите от нас настольной книги с цитатами о цифровых и искусственных преобразованиях. Вместо этого мы предлагаем вам практические артефакты - рамки McK- insey, потоки процессов, схемы технологической архитектуры, рабочие планы, контрольные списки, модели комплектования команды и т. д., - которые являются необходимыми инструментами для успешной работы.
Эта книга предназначена для руководителей и практиков, которые отвечают за формирование и реализацию цифровой трансформации и трансформации с помощью искусственного интеллекта в своей компании. В их число входят генеральный директор и те представители высшего руководства, которые неизменно призваны играть главную роль в таких преобразованиях, а также все руководители, отвечающие за руководство изменениями в сфере технологий в своем подразделении или функции.
Мы также написали эту книгу для руководителей, которые разочаровались, прочитав десятки статей и книг на эту тему, и все равно чувствуют себя растерянными и неловкими в общении с технологиями. В этой книге рассказывается о том, что необходимо знать руководителям, чтобы эффективно внедрять цифровые технологии в своем бизнесе. Мы не фокусируемся на конкретной технологии, но исследуем широкий спектр технологий, необходимых для достижения цели цифровых преобразований.
В этой книге также не рассматриваются конкретные цифровые решения. Каждая отрасль и каждый процесс внутри этих отраслей будут использовать различные цифровые решения для улучшения обслуживания клиентов и снижения удельных затрат. Например, в индустрии потребительских товаров в упаковке решения по управлению доходами имеют решающее значение для коммерческой эффективности.
В горнодобывающей промышленности ключевое значение имеют решения, направленные на максимизацию производительности процессов. В этой книге рассматривается вопрос о том, как определить, какие цифровые решения следует создать, а затем как приступить к их созданию и внедрению.
Мы написали книгу Rewired, чтобы она последовательно развивалась в соответствии с тем, как компании обычно сталкиваются с каждой темой в процессе цифровой трансформации и трансформации с помощью ИИ. Но мы также написали каждый раздел и главу так, чтобы те, кто находится дальше на этом пути или отвечает за определенную его часть, могли использовать эту книгу в качестве справочника, консультируясь с главами, которые наиболее актуальны для стоящих перед ними задач.
Как мы все знаем, цифровые технологии - это быстро развивающаяся область, и современное состояние дел в ней постоянно меняется. Содержание этой книги основано на четвертом поколении нашего собственного внутреннего метода цифровой трансформации и трансформации с помощью искусственного интеллекта в McKinsey. Мы обновляем наш метод каждые 18 месяцев или около того, и мы намерены периодически обновлять эту книгу, чтобы дать вам четкое представление о том, как развивается эта область с точки зрения практиков. Мы надеемся, что эта книга станет для вас полезным и надежным путеводителем в этом увлекательном путешествии.
Для цифровой трансформации и трансформации с помощью ИИ все еще наступил
День 1
То, как компании ориентируются в цифровом мире для достижения устойчивого конкурентного преимущества, является определяющей бизнес-задачей нашего времени. Чтобы цифровые преобразования и преобразования с использованием искусственного интеллекта были масштабными и выполняли свои обещания, топ-команда должна быть готова и желать провести организационную "операцию", необходимую для перестройки бизнеса, чтобы он мог конкурировать с технологиями.
Цифровая трансформация и трансформация с помощью ИИ - это, в конечном счете, упражнение в постоянной эволюции и совершенствовании - это просто современный способ работы бизнеса. Если вы примете эту предпосылку, это изменит ваш взгляд на то, как вы подходите к текущей работе. По выражению Джеффа Безоса, для цифровой трансформации и трансформации с использованием ИИ все еще наступил первый день.
Примечания
Майкл Чуи, Роджер Робертс и Ларейна Йи, "McKinsey technology trends outlook 2022", McKinsey.com, 22 апреля 2022 г., https://www.mckinsey.
.com/capabilities/mckinsey-digital/our-insights/the-top-trends-in-tech.
Саймон Блэкберн, Джефф Галвин, Лаура ЛаБердж и Эван Уильямс, "Стратегия для цифрового мира", McKinsey Quarterly, 8 октября 2021 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ strategy-for-a-digital-world.
Лаура ЛаБердж, Кейт Смадже и Родни Земмель, "Три новых мандата для получения полной отдачи от цифровой трансформации", McKinsey, 15 июня 2022 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ three-new-mandates-for-capturing-a-digital-transformations- full-value.
Собственное решение - это решение, созданное с использованием готового и разработанного на заказ программного обеспечения, а также наборов данных для решения проблемы бизнеса/пользователя. Если собственное решение обеспечивает значительную разницу в производительности и его сложно воспроизвести конкурентам, то оно обеспечивает конкурентное преимущество.
Стивен Ван Куикен, "Технологические компании внедряют инновации на краю: Старые компании тоже могут", Harvard Business Review, 20 октября 2022 г.; https://hbr.org/2022/10/tech-companies-innovate-at-the-edge-legacy- companies-can-too.
Колин Брайар и Билл Карр, "Работать задом наперед: Познания, истории и секреты изнутри Амазонки", St. Martin's Press, 2021.
Внутреннее исследование, проведенное McKinsey на 200 разработчиках программного обеспечения, показало, что преимущества генеративного искусственного интеллекта превышают 25% производительности при разработке кода (результаты этого исследования скоро будут опубликованы).
Майкл Чуй, Брайс Холл, Хелен Мэйхью, Алекс Сингла и Алекс Сухаревский, "Состояние ИИ в 2022 году и полдесятилетия в обзоре", McKinsey.com, 6 декабря 2022 года, https://www.mckinsey.com/ capabilities/quantumblack/our-insights/the-state-of-ai-in-2022-and-a-half- decade-in-review.
Лаура ЛаБердж, Кейт Смадже и Родни Земмель, "Три новых способа получения полной отдачи от цифровой трансформации", McKinsey
.com, 15 июня 2022 г., https://www.mckinsey.com/capabilities/mckinsey- digital/our-insights/three-new-mandates-for-capturing-a-digital- transformations-full-value.
Ожидается публикация этого исследования в журнале Harvard Business Review.
Раздел 1
Оценивая застопорившиеся цифровые преобразования и преобразования с использованием искусственного интеллекта, мы приходим к выводу, что многие из проблем связаны с недостаточным планированием и согласованием.1 Непонимание со стороны руководства на этапе стратегического планирования неизменно приведет к запутанному исполнению ваших цифровых преобразований и преобразований с использованием искусственного интеллекта.
Как правило, мы видим пять серьезных грехов: у руководителей разное концептуальное понимание цифровых технологий, поэтому они говорят друг с другом мимо ушей; руководители концентрируют энергию на мелких проектах, которые не приносят особой пользы; они слишком много внимания уделяют технологическим решениям и упускают из виду важнейших людей и потребности в потенциале; масштабы трансформации слишком широки, поэтому инвестиции распределяются слишком тонко; и, наконец, генеральный директор делегирует ответственность другому руководителю в корпоративном блоке.2
Если одна из этих проблем поразила вашу компанию, объявите тайм-аут. Независимо от того, на каком этапе трансформации находится компания, никогда не поздно перезагрузиться. Прояснив, чего вы хотите достичь, и объединившись вокруг плана, вы сможете вызвать огромный энтузиазм и убежденность в предстоящем путешествии. В следующих главах вы узнаете, как разработать дорожную карту и заложить прочный фундамент для цифровой трансформации:
Глава 1: Вдохновите и согласуйте действия своей команды. Потратьте время на создание общего цифрового языка, изучите опыт других отраслей, разработайте общее видение и четко согласуйте набор обязательств, соответствующих вашим амбициям.
Глава 2: Выберите правильный размер трансформации. Первопричиной большинства неудачных преобразований является неправильное масштабирование усилий, которые либо слишком малы для достижения значимого эффекта, либо слишком велики и сложны для реализации.
Глава 3: Пусть бизнес-лидеры определят, что возможно. Когда бизнес-лидеры определяют амбициозные, но реалистичные цели преобразований в своих областях бизнеса, они приводят в движение маховик перемен.
Глава 4: Определите, какие ресурсы вам нужны для достижения желаемого. Agile-подразделения - это небольшие многопрофильные команды, которым поручено реализовать переосмысленный бизнес. Вам нужно определить, какие виды и в каком количестве вам нужны.
Глава 5: Создание возможностей на сегодняшний день и на следующее десятилетие. Вам предстоит кардинально обновить возможности своей организации, чтобы она могла конкурировать в эпоху цифровых технологий и искусственного интеллекта. Четко определите, что это за возможности и как их создать.
Глава 6: "Цифровая дорожная карта" - это контракт для руководства компании. В нем подробно описаны конкретные планы по преобразованию бизнес-областей с помощью инвестиций. В нем сформулирован план создания возможностей предприятия с измеримыми конечными показателями зрелости.
Глава 7: Командный вид спорта. Каждый руководитель высшего звена должен внести свой вклад в успех компании на пути цифровой трансформации.
Примечания
Деннис Кэри, Рам Чаран, Эрик Ламарр, Кейт Смадже и Родни Земмель, "Игровая книга генерального директора для успешной цифровой трансформации", Harvard Business Review, 20 декабря 2021 г., https://hbr.org/2021/12/ the-ceos-playbook-for-a-successful-digital-transformation; Селия Хубер, Алекс Сухаревский и Родни Земмель, "5 вопросов, которые советы директоров должны задать о цифровой трансформации", Harvard Business Review, 21 июня 2021 г., https://hbr.org/2021/06/5-questions-boards- should-be-asking-about-digital-transformation.
Жак Буген, Танги Катлин, Мартин Хирт и Пол Уиллмотт, "Почему цифровые стратегии терпят неудачу", McKinsey.com, 25 января 2018 г., https://www.
.mckinsey.com/capabilities/mckinsey-digital/our-insights/why- digital-strategies-fail.
Глава 1. Получите
вдохновение и согласованность действий вашей команды
Три элемента успешных цифровых преобразований являются основополагающими и универсальными: видение, согласование и приверженность. Хотя эти элементы важны для любой трансформации, цифровые преобразования и преобразования с использованием искусственного интеллекта часто не так строги, когда речь идет о постановке задач и целей. Это классический симптом бизнеса, который относится к цифровым технологиям либо как к побочной задаче, либо как к руководству, которое недостаточно хорошо разбирается в цифровых технологиях, чтобы понять, что возможно.
Поскольку преобразования в области цифровых технологий и искусственного интеллекта влияют на многие сферы бизнеса, инвестирование времени в создание правильной основы приносит значительные дивиденды в виде ясности и согласованности действий.1
Vision
Видение - это общее понимание конечной, высокоуровневой цели преобразований и их ценности. Видение - это не просто стремление, это основополагающее "почему", которое выступает в качестве Северной звезды компании в процессе преобразований и обеспечивает четкое направление для всех действий и решений, изложенных в "дорожной карте". Тактические цели и задачи команд, а также миссии, над которыми они работают, должны быть направлены на это общее видение. Некоторые компании выбирают другой термин, но какой бы термин ни использовался, он должен быть понятным и актуальным для всего бизнеса в области цифровых технологий и ИИ-трансформации.
Что делает хорошее видение? Сильные заявления о видении имеют некоторые общие ингредиенты: стремление, часто привязанное к клиенту, а также временное измерение и количественная оценка значительной ценности. Концепция должна вдохновлять и быть сформулирована так, чтобы сотрудники компании могли ее понять. Лучшие формулировки видения выходят за рамки просто вдохновляющих стремлений, таких как "Непревзойденное обслуживание клиентов", и содержат больше конкретики, например "Обеспечение персонализированной, проактивной работы с клиентами в нескольких точках на протяжении всего пути клиента". Для одной компании это было "Обеспечить бесперебойное обслуживание клиентов и сотрудников за счет использования искусственного интеллекта в наших основных операционных процессах, чтобы добиться лучших в отрасли показателей удовлетворенности клиентов и повысить EBIT на 15 % за три года".
На основе хорошего видения можно четко определить, как вы собираетесь переосмыслить бизнес, и определить возможности, необходимые для реализации этого видения (см. Рисунок 1.1). Один из ключевых моментов: увязывайте видение преобразований с общей бизнес-стратегией компании.
Выравнивание
Согласование означает не просто согласие, а понимание всеми своей роли и того, что им нужно делать. Это очень важно, поскольку цифровые преобразования и преобразования с использованием искусственного интеллекта всегда требуют тесного межфункционального взаимодействия. Например, продажи, маркетинг, ценообразование, обслуживание клиентов и выполнение заказов должны трансформироваться вместе
Пример цифрового видения
Пример для компании, производящей товары повседневного спроса
Бизнес-цели
Создать новые источники роста за счет персонализации прямого контакта с потребителем и стать лучшей CPG-компанией в обслуживании наших розничных клиентов
Финансовые цели
К 20XX году увеличить годовую прибыль до вычета процентов и налогов (EBIT) на $1 млрд.
Путешествие потребителя, основанное на анализе
Обеспечьте персонально релевантное взаимодействие с потребителями с помощью адаптированных сообщений, предложений и опыта.
Инновации
Используйте анализ данных, чтобы лучше понять неудовлетворенные потребности потребителей и ускорить обновление основных категорий.
Рост категории и числа клиентов
Разрабатывать идеи и реализовывать стратегии для прибыльного роста категорий и выступать в качестве идейного партнера для розничных сетей.
Преимущество цепочки поставок
Поддержка оптимального уровня сложности и обслуживания при минимальных затратах.
Талант
Формирование основной базы цифровых талантов и повышение уровня владения цифровыми технологиями среди более широкого круга сотрудников
Tech
Переход на современную, открытую, модульную облачную архитектуру; создание и настройка для конкурентного преимущества
Операционная модель Agile
Создание междисциплинарных команд с широкими полномочиями, которые будут направлены в бизнес и руководить им для разработки наших собственных цифровых решений.
Данные
Инвестировать в разработку собственных информационных активов, которые будут отличать наших клиентов и потребителей
ПРИЛОЖЕНИЕ 1.1
если компания хочет успешно перейти на онлайн-каналы. Такое комплексное взаимодействие процессов является правилом, а не исключением при цифровых преобразованиях.
Очень важно правильно организовать согласование. Исследования доказывают это: компании, успешно проводящие преобразования, почти в четыре раза чаще, чем неуспешные, отмечают "общее чувство ответственности за достижение целей преобразований "2.
На этом раннем этапе нередки случаи, когда руководители не согласны друг с другом, когда речь идет о цифровой трансформации и трансформации с использованием искусственного интеллекта. Руководители, входящие в команду лидеров, часто подходят к цифровой трансформации и трансформации с использованием искусственного интеллекта, имея за плечами различные знания и взгляды, которые могут противоречить друг другу. Во многих случаях у высшего руководства отсутствует как общее понимание цифровых технологий, так и понимание возможностей, которые открывают цифровые технологии для бизнеса. Даже на самом фундаментальном уровне у руководства может не быть общего понимания таких вопросов, как: Что такое искусственный интеллект? Чем занимается инженер по обработке данных? Почему DevSecOps имеет значение? Существуют десятки подобных вопросов, вокруг которых руководство должно выработать общий язык, общее понимание и реальную убежденность в том, какой потенциал цифровые технологии могут предложить их бизнесу, и что нужно сделать, чтобы его реализовать.
По этой причине в начале трансформации всегда полезно создать экспериментальную программу обучения руководителей, включающую посещение других компаний, которые продвинулись дальше в своем цифровом пути, обучение руководителей основам цифровых технологий и искусственного интеллекта, а также семинары по искусству возможного, позволяющие распознать закономерности и убедиться в том, как цифровые технологии могут преобразовать различные сферы бизнеса.
Вы должны запланировать, чтобы каждый топ-менеджер потратил минимум 20 часов на обучение, прежде чем он будет готов продуктивно участвовать в определении цифровой дорожной карты вместе со своими коллегами. По нашему опыту, это самое важное, что вы сделаете на ранних этапах трансформации.
Обязательства
Никакие преобразования невозможны без приверженности. Приверженность - это не просто выделение бюджета, которое необходимо, но не достаточно. Приверженность - это индивидуальная и совместная ответственность руководителей высшего звена за реализацию концепции и получение соответствующих выгод на основе вложенных ресурсов.
Обязательства руководства, которые должны быть твердо закреплены к моменту завершения работы над "дорожной картой", отражаются в четырех направлениях:
Цифровой бизнес-кейс, ради которого стоит встать с постели. Бизнес-лидеры должны быть готовы взять на себя обязательства по четкому повышению эффективности бизнеса в области клиентского опыта и/или окупаемости инвестиций. На этом этапе спросите себя: Сможет ли наш план действительно трансформировать бизнес? Соизмеримы ли инвестиции с возможностями? Что касается последнего пункта, будьте осторожны, чтобы не стать жертвой "цифровой магии", то есть вложить совсем немного средств, но ожидать, что они принесут огромную пользу. Не существует такого понятия, как "цифровая магия".
Реальные инвестиции в создание фундаментальных возможностей предприятия. В то время как одни инвестиции должны быть связаны с конкретными цифровыми возможностями, другие должны быть направлены на создание фундаментальных возможностей в области (а) цифровых талантов, (б) операционной модели, (в) технологического стека и (г) среды данных. На начальном этапе цифровой трансформации можно ожидать, что инвестиции будут распределяться 50/50 между созданием конкретных решений и наращиванием потенциала. Недавний анализ показывает, что по многим направлениям инвестиций в основополагающие технологии компании, находящиеся в первой декаде экономического рейтинга, значительно опережают своих коллег.3 Однако будьте осторожны, не разрабатывайте длительные сроки и не создавайте чрезмерную нагрузку на финансовый результат. Цифровые преобразования требуют реальных инвестиций, но эти расходы должны быть разделены на управляемые сроки с четко сформулированным фокусом на периоды окупаемости. После начального периода инвестиций вы должны наращивать стоимость по ходу дела, а не в какой-то отдаленный момент.
Управление преобразованиями под руководством генерального директора. Успешные преобразования спонсируются генеральным директором. Только генеральный директор может обеспечить межфункциональное согласование, необходимое для достижения успеха, и принять смелые решения по созданию цифровых возможностей предприятия. Создайте офис трансформации (TO) и укомплектуйте его наиболее способными сотрудниками (подробнее об этом в главе 30).
Решительность руководителей и подражание. Конечно, у генеральных директоров и других линейных руководителей много других обязанностей, но они все равно должны уделять значительное количество времени преобразованиям. Они должны быть примером того, как нужно ориентироваться на клиента, сотрудничать, быть технически подкованным и гибким - все это качества великих цифровых лидеров.
Они должны быть любознательными и постоянно изучать потенциал технологий. Они должны быть в поле зрения, наблюдая за успехами и проблемами, с которыми сталкиваются их команды при внедрении новых цифровых решений. В дорожной карте должно быть четко определено, что ожидается от старших руководителей (см. подробнее в главе 7).
Примечания
Кейт Смадже, Родни Земмель, "Цифровая трансформация на повестке дня генерального директора", McKinsey.com, 12 мая 2022 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/digital-transformation- on-the-ceo-agenda.
"Проигрыш с первого дня: Почему даже успешные преобразования терпят неудачу", McKinsey.com, 7 декабря 2021 г., https://www.mckinsey.com/capa bilities/people-and-organizational-performance/our-insights/ successful-transformations.
"Новый цифровой край: Переосмысление стратегии в постпандемическую эпоху", McKinsey.com, 12 мая 2022 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/the-new-digital-edge-rethinking
-Стратегия для постпандемической эпохи.
Глава 2.
Выберите правильную трансформацию "по размеру"
Многие компании с самого начала создают трудности при проведении цифровых преобразований и преобразований с использованием искусственного интеллекта, неправильно определяя масштаб изменений. Некоторые компании начинают с малого, полагая, что постепенный подход снизит риск. Это ошибка. Успешные преобразования должны изменить что-то значимое в бизнесе, где на кону стоит заметная стоимость и можно измерить эффект. Перекрашивая гостиную, вы не сможете далеко продвинуться в преобразовании дома; вам нужно взяться за что-то более существенное, например, переделать кухню.
Другие, руководствуясь самыми благими намерениями, слишком рано приступают к масштабным преобразованиям и пытаются сразу изменить всю компанию. Как правило, это слишком разрушительно, слишком дорого, чтобы сделать все правильно, или слишком сложно для первого проекта, и обычно это не удается. Чаще всего компании распределяют ставки и ресурсы слишком тонко по нескоординированному набору мероприятий и инициатив. Это приводит к тому, что активности много, а пользы мало.
Доменный подход
Правильный подход заключается в том, чтобы определить несколько важных и самостоятельных доменов в бизнесе и полностью переосмыслить их. До 80 % успешных мероприятий по цифровой трансформации основаны на перераспределении масштабов, чтобы направить согласованные усилия на четко определенный домен.1 Применение такого подхода начинается с определения доменов. Домен - это подмножество вашего предприятия, которое включает в себя целостный набор связанных между собой видов деятельности. Существует несколько способов определения доменов (см. Рисунок 2.1).
Компании могут сами определить, как лучше очертить круг вокруг набора видов деятельности, чтобы определить домен, который имеет наибольший смысл. Главное - определить домен, достаточно большой, чтобы быть ценным и заметным для компании, но достаточно маленький, чтобы его можно было трансформировать, не подвергая излишнему влиянию зависимостей с другими частями бизнеса. Сколько всего доменов в компании? Правильное число - около 10-15 для монолинейного бизнеса. Для конгломерата правильной единицей анализа будет стратегическая бизнес-единица, поэтому домены определяются на этом уровне. Однако для целей цифровой трансформации выберите от двух до пяти, чтобы в первую очередь сосредоточиться на преобразованиях. На начальном этапе можно пойти дальше и охватить больше доменов. Однако это потребует значительных краткосрочных инвестиций, большей координации и большего числа специалистов. Кроме того, это может быть связано с большим риском и почти наверняка потребует значительных внешних ресурсов, а также может лишить организацию некоторых ранних уроков. Поэтому вдумчиво выбирайте, за какие и сколько доменов браться.
Три способа определения домена
Рабочий процесс/Процесс
Высокоценные бизнес-процессы, такие как обслуживание активов, обслуживание клиентов или закупки и оплата.
Путешествия
Процессы, требующие интенсивного взаимодействия, такие как привлечение клиентов, консультирование клиентов или покупка товара в Интернете
Функция
Традиционные бизнес-функции, такие как продажи, финансы, маркетинг или цепочка поставок
Большинство компаний предпочитают организовывать свои домены по рабочим процессам или маршрутам, поскольку это, как правило, обеспечивает наибольшую ценность для клиентов и/или сотрудников.
Пример доменов в компании, производящей товары повседневного спроса
Логистика
Финансы
Выполнение в магазине
Люди
Интегрированное планирование цепочек поставок
Персонализированный маркетинг
ПЕРЕД ДОМОМ
ОПЕРАЦИИ
ВСПОМОГАТЕЛЬНЫЕ ФУНКЦИИ
ПРИЛОЖЕНИЕ 2.1
Управление доходами
Закупки
Инновации/Исследования и разработки
Производство
Юридическая
Цифровое взаимодействие
Расстановка приоритетов в доменах
Для определения приоритетов, на которые следует обратить внимание в первую очередь, необходимо провести оценку по двум широким параметрам: потенциал ценности и осуществимость (см. Рисунок 2.2). Руководители узнают этот простой способ определения приоритетности возможностей, но им следует обратить внимание на критерии, по которым проводится оценка.
Приоритетность доменов определяется их ценностью и осуществимостью
Пример компании, производящей товары повседневного спроса
ВЫСОКИЙ
Производство Выручка
управление Приоритетные домены
Логистика Закупки
Магазин Интегрированный
исполнение поставки Персонализированная цепочка маркетинг
планирование
Инновации/исследования и разработки Цифровое взаимодействие
СТОИМОСТЬ
Клиентский опыт
Финансовые выгоды
Скорость до значения
Синергия с другими доменами
ОСОБЕННОСТИ
ВЫСОКИЙ
Спонсорство руководителей - Простота внедрения
Готовность к работе с данными - Простота предприятия
Технологическая готовность масштабирование
На этом этапе достаточно оценить потенциал ценности на высоком уровне, основываясь на сочетании внешнего анализа и обсуждений с руководителями высшего звена и отраслевыми экспертами. Большинство компаний испытывают трудности с оценкой такого рода, поскольку им не хватает опыта в понимании того, что может быть возможно с помощью цифровых технологий. Чтобы решить эту проблему, рассмотрите возможность использования эталонных показателей успешных компаний (даже за пределами вашей отрасли). К числу ключевых факторов стоимости относятся:
Клиентский опыт. Улучшение клиентского опыта должно рассматриваться как "первое среди равных", когда речь заходит о его рассмотрении. Большинство успешных цифровых преобразований и преобразований с использованием искусственного интеллекта сосредоточены вокруг клиента и удовлетворения его потребностей. Это поможет сравнить текущий опыт с конкурентами и спрогнозировать, насколько он улучшится после преобразования области. Это должно выражаться в конкретных показателях повышения удовлетворенности клиентов, а также в росте числа клиентов и увеличении чистой стоимости в расчете на одного клиента.
Финансовые выгоды. На этом этапе вы хотите оценить финансовые выгоды, сосредоточившись на ключевых показателях эффективности деятельности (KPI), таких как рост числа новых клиентов, снижение оттока, увеличение стоимости одного клиента, повышение производительности процессов или снижение стоимости обслуживания. На этом этапе бывает сложно точно оценить, каких именно улучшений можно достичь, поэтому будет достаточно оценки, основанной на том, чего добились другие компании в аналогичных отраслях. Будьте осторожны и не преуменьшайте потенциал на этом этапе. Это только для определения приоритетов, и это еще не бизнес-кейс.
Скорость создания стоимости. Преобразования, основанные на домене, обычно приносят значительную прибыль в течение шести- 36 месяцев, в зависимости от домена. Это часто является важным фактором с точки зрения получения первых выгод и финансирования преобразований. Мы обнаружили, что в целом возможности, связанные с применением ИИ, окупаются быстрее.
Синергия. Если вы трансформируете несколько областей, синергия между ними является убедительным рычагом воздействия. Синергию можно оценить с точки зрения трех основных элементов: (а) повторное использование данных в разных решениях, (б) повторное использование технологического стека в разных решениях и (в) совместные усилия по управлению изменениями. Например, если вы одновременно разработаете новую платформу для продаж ипотечных кредитов и новую платформу для продаж кредитных карт, вам потребуется только один раз переобучить тысячи торговых представителей в филиалах.
Оценка осуществимости - это сочетание понимания технической готовности и готовности данных, необходимых усилий по управлению изменениями и способности руководства домена взять на себя обязательства.
Наиболее важными соображениями являются:
Сильное спонсорство руководителей. Вам необходимо убедиться, что руководители конкретного подразделения полностью поддерживают идею. Подразделение может быть готово к цифровой трансформации, но если есть конкурирующие приоритеты, например, внедрение новой ИТ-системы или завершение масштабной работы по устранению несоответствий, то время для преобразований может быть неподходящим.
Готовность данных и технологий. Если говорить о данных, то основными вопросами для оценки являются простота переноса необходимых полей данных в облако и качество базовых данных. На данном этапе необходим беглый анализ, но в случае выбора этой области потребуется более тщательная проверка. С технической стороны необходимо оценить качество облачной архитектуры, производительность базовых систем и простоту доступа к данным и приложениям с помощью интерфейсов прикладного программирования (API). Лучше всего с этой оценкой справятся архитекторы вашего предприятия. Обратите внимание, что унаследованные технологии или требования к крупным существующим базовым системам, таким как обновление ERP, часто используются в качестве оправдания отсутствия прогресса. Эти проблемы, конечно, необходимо понимать, но они не являются причиной для бездействия. Устаревшее мышление - это более серьезная проблема, чем устаревшие технологии.
Легкость внедрения. Понимая масштабы, интенсивность и риски, связанные с изменениями, компании могут выявить потенциальные препятствия для внедрения цифрового решения. Например, проведение изменений в профсоюзной среде может быть связано с переговорами, на эффективное проведение которых может потребоваться время.
Простота масштабирования. Предполагая, что вы успешно разработаете цифровое решение, оцените, насколько легко будет масштабировать его в масштабах предприятия? Насколько сложной будет задача управления изменениями? В скольких различных средах данных будет работать решение? Эти вопросы важны для получения полной отдачи.
В результате анализа экономической целесообразности необходимо выделить от двух до пяти областей, которые следует отнести к приоритетным. Важно, что на данном этапе вы не стремитесь к точности - неважно, будут ли измерения точно верными на данном этапе. Рассматривайте это скорее как способ структурирования разговор с командой менеджеров. Уточнение сметы произойдет на следующем этапе в рамках переосмысления домена.
По их словам: Избегайте фрагментации и лучше сотрудничайте
Врагом любой цифровой трансформации рынка является фрагментация, особенно в компании такого размера, как Sanofi.
Расставьте приоритеты и осознайте, что через полгода могут появиться новые блестящие объекты, которые разбавят ваши первоначальные цели и замедлят вашу способность добиваться больших побед.
Сегодня мы вкладываем в совокупность меньше средств, чем три года назад, но на выбранные приоритетные проекты выделяем больше ресурсов. Наши итеративные agile-циклы сборки проходят быстрее и вовлекают пользователей в процесс разработки, в результате чего решения становятся гораздо более актуальными и эффективными.
Второе препятствие на пути к успеху - это мы, руководство, команда менеджеров. Всем нравится иметь свою сферу влияния в бизнесе, которая в прошлом была связана с конкретным, часто разрозненным, P&L. Цифровое будущее не таково. Вам нужно быть более открытыми, уметь наделять полномочиями, делегировать и сотрудничать. Еще одним фактором является воспитание цифрового потенциала. Мы должны были подготовить критическую массу людей, которые разбираются в цифровых технологиях, чтобы привлечь и удержать талантливых специалистов. Раньше мы действовали недостаточно быстро и не принимали инновационные методы работы, предлагаемые новыми сотрудниками, что приводило к разочарованию и быстрому оттоку кадров.
В некоторых случаях руководство имеет четкое представление о том, где находится ценность, и решает сразу же заняться этим доменом, пропуская этап при- оритизации (см. пример такого подхода в примере Freeport-McMoRan в главе 33). Это может быть хорошим подходом, если руководство четко ориентируется на него и ценность домена является значимой. На практике это также может быть полезным способом формирования убежденности в организации путем четкой демонстрации ценности, которую компании могут получить или защитить с помощью цифровых технологий и ИИ.
Одна крупная сельскохозяйственная компания решила пойти по этому пути, сосредоточившись сначала на своей коммерческой сфере, поддерживая своих агрономов, чтобы они могли лучше обслуживать своих фермеров (клиентов) и упростить для того, чтобы эти фермеры продолжали работать с компанией. Генеральный директор и высшее руководство компании испытывали конкурентное давление со стороны новых цифровых компаний и считали, что существует ряд болевых точек клиентов, которые они могли бы быстро устранить, чтобы улучшить перекрестные продажи и удержать клиентов.
Несмотря на то что быстрое внедрение пробного домена может дать хорошие результаты, руководству компании необходимо уберечься от запуска очередного эксперимента, который вызовет интерес, но не изменит бизнес в корне. Именно поэтому так важно уделить время тщательной работе по переосмыслению домена, о чем говорится в следующей главе.
Примечание
1. Тим Фаунтейн, Брайан Маккарти и Тамим Салех, "Добиться масштабирования ИИ", Harvard Business Review, май-июнь 2021 г., https://hbr.org.
Глава
3.
Попросите руководителей компаний определить, что возможно
В каждой области, подлежащей преобразованию, необходимо найти несколько взаимосвязанных решений, которые, будучи реализованными, окажут существенное влияние на производительность в лучшую сторону. Обратите внимание на слово "значимо". Слишком часто компании стремятся к незначительным улучшениям по сравнению с текущими показателями, но это, как правило, ограничивает мышление традиционными рамками унаследованного бизнеса. Мелкое мышление приводит к мелким результатам, зачастую не стоящим усилий по преобразованию. Наше эмпирическое правило гласит, что надежная цифровая дорожная карта должна обеспечивать повышение EBITDA на 20 % и более. Мы рекомендуем следовать простому пятиэтапному процессу разработки надежного бизнес-обоснования для каждой области (см. Рисунок 3.1).
Пять шагов по переосмыслению домена
1
2
3
4
5
Проблема для решения
Сформулируйте бизнес-проблему, которую необходимо решить, - неудовлетворенные потребности пользователей или болевые точки процесса. Четко определите рычаг улучшения, который необходимо задействовать для решения проблемы.
Решения и примеры использования
Определите цифровые решения и базовые сценарии использования, необходимые для решения "проблемы, которую нужно решить".
Данные и технические требования
Оцените ландшафт данных и технологический стек в сравнении с архитектурой целевого решения. Понимание недостатков и необходимых инвестиций.
Влияние и инвестиции
Оцените эффект, который могут дать эти решения, указав, как можно улучшить каждый рычаг/показатель эффективности.
Примерно оцените необходимые инвестиции.
План реализации
Сформулируйте требования к управлению изменениями для реализации всех преимуществ и разработайте последовательность внедрения. Определите руководство и подотчетность.
ПРИЛОЖЕНИЕ 3.1
Шаг 1 - четкое формулирование бизнес-проблемы, которую необходимо решить. Каковы неудовлетворенные потребности клиентов/пользователей? Каковы болевые точки процесса? Как правило, существует два подхода к решению этой задачи:
При проектировании путешествий с нулевым результатом используется дизайн-мышление для определения персон конечных пользователей и выявления неудовлетворенных потребностей на протяжении всего путешествия с помощью интервью с пользователями и семинаров. Этот подход предпочтителен для отраслей с высоким уровнем сервиса, где ценится дифференциация на основе отличного клиентского опыта. Полученные карты путешествий служат отправной точкой для переосмысления пользовательского опыта. Совместная работа с дизайнерами помогает убедиться, что этот подход строится на основе неудовлетворенных потребностей клиентов или пользователей (подробнее о дизайне пользовательского опыта читайте в главе 16).
Картирование сквозных процессов предполагает разбиение основного бизнеса на набор процессов, выявление отходов, болевых точек или упущенных возможностей в процессе предоставления ценности. Такой подход часто предпочтителен в отраслях с интенсивным производством, где бесперебойная работа процессов и низкие удельные затраты являются основополагающими факторами конкурентоспособности.
На шаге 2 неудовлетворенные потребности пользователей или болевые точки процессов сопоставляются с конкретным рычагом ценности (см. Рисунок 3.2). Для каждого рычага ценности определите потенциальные цифровые решения (например, приложения или активы данных), которые пользователи или клиенты будут использовать как часть улучшенного опыта, который вы собираетесь предоставить. Например, это может быть новая платформа для продажи ипотечных кредитов для банковских служащих или оптимизатор уставки для операторов медных обогатительных фабрик. Каждое решение должно задействовать как минимум один рычаг ценности. Организация по рычагам помогает сформулировать четкое предположение об улучшении "от ... до ..." и обеспечивает измеримый ключевой показатель эффективности (KPI). Компании, борющиеся с цифровыми преобразованиями, часто выявляют решения, которые не имеют четкой привязки к бизнес-ценности через измеряемые улучшения KPI.
Каждое решение будет состоять из сценариев использования или активов данных, необходимых для его реализации. Например, в случае с платформой для продажи ипотечных кредитов одним из вариантов использования может быть ввод клиентов в систему или автоматическая проверка кредитоспособности. Как правило, для преобразования области требуется несколько решений, а каждое решение, в свою очередь, содержит несколько сценариев использования. Варианты использования поддерживаются оцифрованными рабочими процессами, аналитическими моделями и данными.
Шаг 3 углубляется в технологические и связанные с данными аспекты разрабатываемых решений. Какова целевая архитектура этих решений и лежащих в их основе данных? Сможет ли текущий технологический стек вместить их, и если нет, то что придется изменить? Аналогично с данными. Этот этап требует экспертного руководства со стороны архитекторов решений.
На этапе 4 оцениваются инвестиции и ожидаемые выгоды. Самая большая ошибка, совершаемая на этом этапе, - ложная точность. В мире цифровых технологий и искусственного интеллекта окупаемость инвестиций должна составлять 5× или более. Быть
Поэтому достаточно +/-30% на инвестиции и выгоды. Инвестиции в архитектуру технологий и данных должны быть правильно распределены, поскольку большинство из них будут повторно использоваться в других решениях. Часто компании управляют ими в рамках отдельных усилий по созданию общих технических средств и средств обработки данных.
На этапе 5 разрабатывается последовательность внедрения с указанием ожидаемых ресурсов и выгод, включая усилия по управлению изменениями, необходимые для реализации всех преимуществ. Этот шаг, как правило, является казусным.
Каскадный переход от бизнес-области к рычагам создания ценности, решениям и вариантам использования
Бизнес-домен
DOMAIN
Рычаги стоимости
ЛЕВЕР III
РЫЧАГ II
РЫЧАГ I
Решения
РЕШЕНИЕ 4
РЕШЕНИЕ 3
РЕШЕНИЕ 2
РЕШЕНИЕ 1
Примеры использования/ модели
Вариант использования 1.1
Вариант использования 1.2
Вариант использования 1.3
Вариант использования 2.1
Вариант использования 2.2
Вариант использования 3.1
Вариант использования 3.2
Вариант использования 3.3
Вариант использования 3.4
Вариант использования 4.1
Вариант использования 4.2
Вариант использования 4.3
Бизнес-домен
Путешествие клиента/пользователя или основной бизнес-процесс - достаточно большой, чтобы ценность от его преобразования была значительной
Рычаги стоимости
Основные бизнес-результаты, которые определяются трансформацией области, такие как количество новых клиентов, отток, стоимость обслуживания, NPS и т. д.
Решения Решения обеспечивают ценность для клиента или пользователя, например, приложение для прогноза погоды или платформа для продажи ипотечных кредитов.
Варианты использованияРешение обычно состоит из вариантов использования. В случае с погодным приложением это могут быть прогнозы температуры, влажности и ветра. В платформе для продажи ипотечных кредитов можно использовать такие сценарии, как регистрация клиента, проверка кредитоспособности клиента и калькулятор расчета цены ипотечного кредита.
ПРИЛОЖЕНИЕ 3.2
Пример из практики: Компания CPG улучшает свои возможности персонализации
Тематическое исследование: Персонализированный маркетинг
Домен персонализированного маркетинга в компании CPG
Бизнес-домен
ПЕРСОНАЛИЗИРОВАННЫЙ МАРКЕТИНГ
Рычаги стоимости
Решения
РЕНТАБЕЛЬНОСТЬ РЕКЛАМНЫХ РАСХОДОВ (ROAS)
ПОТРЕБИТЕЛЬ 360 ГИБКАЯ ПЕРСОНАЛИЗАЦИЯ
МАРКЕТИНГ
МАРКЕТИНГ
НЕРАБОЧИЕ РАСХОДЫ
ЭКОСИСТЕМА АГЕНТСТВО/КОНТЕНТ
Примеры использования/модели
Интегрированные профили потребителей 360
Аудитории/денежная карта
Определение возможностей аудитории Эффективность кампании
Анализ расходов на медиаканалы
Модель сетки контента
Инструмент производительности
(например, эффективность контента и медиа по всем каналам)
Прогнозируемый рост Модель оптимизации всей воронки
аналитика
Модель склонности к определенным аудиториям
Данные, не исчерпывающие Технологии, не исчерпывающий перечень
Данные о точках продаж
Данные электронной коммерции
Потоки данных Adtech
Данные по акциям/долевому участию
ПРИЛОЖЕНИЕ 3.3
Собственные медиаплатформы
Сенсорные/тестовые данные
Маркетинг RoI
Веб-сайты брендов
Данные социального прослушивания
Управление цифровыми активами
Веб-приложения
Пилотные кампании
Платформа управления данными
Рецепты
Электронная коммерция
Управление информацией о продукте
Электронная почта
Уход за потребителями
Данные карты постоянного покупателя
Компания, производящая потребительские товары, стремилась улучшить возможности персонализированного маркетинга, чтобы установить более тесные отношения со своими клиентами и повысить отдачу от рекламных расходов. Чтобы получить эту выгоду, компания разработала решения для предоставления подробной информации о клиентах и аналитики для персонализированного маркетингового взаимодействия с ними.
Затем они определили сценарии использования, данные и технологии, необходимые для реализации этих решений. Например, они создали инфраструктуру маркетинговых технологий для оптимизации и управления рассылкой сообщений по нескольким каналам, включая электронную почту, программную дисплейную рекламу, розничные сети и платную социальную рекламу. Архитектура преобразования домена показана на рисунке 3.3. В результате этих согласованных усилий рассылка сообщений привела к ощутимому росту вовлеченности целевых групп покупателей, часто в несколько раз превышающему существующие обычные уровни вовлеченности.
только в этом случае, но это является основополагающим фактором для достижения эффекта. Подробнее об этом читайте в разделе 6.
Как думать о новых технологиях, таких как генеративный ИИ
Быстрое развитие технологий создает уникальную проблему для цифровых преобразований и преобразований с использованием искусственного интеллекта: Как построить организацию, работающую на основе технологий, если сами технологии меняются так быстро? Существует тонкий баланс между внедрением технологий, которые могут принести значительную пользу, и растратой ресурсов и фокуса в погоне за каждой появляющейся перспективной технологией.
Компания McKinsey ежегодно публикует информацию о наиболее важных новых технологических тенденциях, основываясь на их способности стимулировать инновации и вероятном времени выхода на рынок. На момент написания этой статьи исследование выявило 14 технологических трендов, способных революционизировать методы ведения бизнеса и генерирования стоимости.1 Хотя предсказать, как будут развиваться технологические тренды, по-прежнему сложно, вам следует систематически отслеживать их развитие и последствия для своего бизнеса.
В этой книге мы не будем подробно рассказывать об этих тенденциях - для этого мы рекомендуем вам ознакомиться с ежегодным обзором технологических трендов McKinsey. Но мы хотим остановиться на генеративном искусственном интеллекте (GenAI), который, по нашему мнению, способен стать значительным разрушителем на уровне облачных или мобильных технологий. GenAI разрабатывает алгоритмы (такие как GPT-4), которые могут быть использованы для создания нового контента, включая аудио, код, изображения, текст, симуляции и видео. Технология использует полученные данные и опыт (взаимодействие с пользователями, которое помогает ей "выучить" новую информацию и понять, что правильно/неправильно) для создания совершенно нового контента.
Это еще только начало, и мы можем ожидать, что в ближайшие месяцы и годы эта область будет стремительно меняться. При оценке того, как лучше всего использовать модели GenAI, можно выделить три типа применения:
Генерация контента. Широкофункциональные модели, которые станут искусными в автоматизации, ускорении и улучшении существующей работы со знаниями (например, GPT-4, Google's Chinchilla, Meta's OPT). Например, маркетологи могут использовать модели GenAI для генерации контента, чтобы обеспечить целевой цифровой маркетинг в масштабе. Обслуживание клиентов может быть полностью автоматизировано или оптимизировано с помощью "помощника знаний", который будет следить за ходом разговора и подсказывать сотрудникам службы поддержки. GenAI может быстро разрабатывать и итерировать прототипы продуктов и строительные чертежи.
Новые открытия. Отраслевые модели, которые могут не только ускорить существующие процессы, но и разработать новые продукты, услуги и инновации. Например, в фармацевтике прикладные модели, использующие общие методы (например, OpenBIOML, BIO GPT), могут быть развернуты для обеспечения скорости и эффективности разработки лекарств или диагностики пациентов. Или модель GenAI может быть применена к массивной базе данных фармацевтических молекул, чтобы определить вероятные способы лечения рака. Потенциал воздействия и готовность к использованию генеративного ИИ будут существенно различаться в зависимости от отрасли и бизнес-сценария.
Кодинг (например, Copilot, Alphacode, Pitchfork). Эти модели обещают автоматизировать, ускорить и демократизировать процесс кодирования. Существующие модели уже способны грамотно писать код, документацию, автоматически генерировать или заполнять таблицы данных и тестировать проникновение кибербезопасности, хотя для этого требуется значительное и тщательное тестирование, необходимые для подтверждения результатов. По результатам недавнего исследования, проведенного нами в McKinsey, при использовании Copilot производительность труда разработчиков программного обеспечения повысилась более чем на 25 %.
В контексте цифровой трансформации важно учитывать несколько моментов, когда речь идет о GenAI. Во-первых, любое понимание ценности моделей GenAI должно основываться на четком понимании целей вашего бизнеса. Это может показаться очевидным, но по мере роста интереса к GenAI возникнет соблазн разработать сценарии использования, которые в итоге не принесут большой пользы бизнесу или будут отвлекать от усилий по цифровой трансформации.
Во-вторых, как и любая другая технология, извлечение масштабной пользы из GenAI требует сильных компетенций во всех возможностях, о которых рассказывается в этой книге. Это означает развитие целого ряда возможностей и навыков в области облачных вычислений, инженерии данных и MLOps, а также поиск специалистов по GenAI и обучение людей использованию этого нового поколения возможностей.
Учитывая эту необходимость, важно пересмотреть дорожную карту трансформации цифровых технологий и ИИ и проанализировать приоритетные цифровые решения, чтобы определить, как модели GenAI могут улучшить результаты (например, персонализация контента, чатботы-помощники для повышения конверсии сайта). Не поддавайтесь соблазну распространения пилотных проектов. Можно позволить людям экспериментировать, но реальные ресурсы должны быть направлены только на те области, которые имеют реальную связь с бизнес-ценностью. Потратьте время на то, чтобы понять потребности и последствия GenAI для возможностей, которые вы разрабатываете в рамках цифровой трансформации и ИИ, например, следующих:
Операционная модель: Для обеспечения ответственного подхода к разработке и использованию решений GenAI потребуются специализированные, ответственные agile-"капсулы", ориентированные на GenAI. Это, вероятно, будет означать более тесное сотрудничество с экспертами в области права, конфиденциальности и управления, а также с экспертами в области MLOps и тестирования для обучения и отслеживания моделей.
Архитектура и внедрение технологий: Архитектура системы должна быть адаптирована для включения мультимодальных возможностей GenAI в конечные рабочие процессы. Потребуется эволюция на нескольких уровнях технологического стека - уровень данных, уровень моделей, интерфейс UX - для обеспечения адекватной интеграции и отзывчивости цифровых решений.
Архитектура данных: Применение моделей GenAI к текущим данным потребует от вас переосмысления управления сетями и конвейерами данных, чтобы учесть не только объем данных, но и частоту изменений, которые можно ожидать по мере обучения и развития GenAI.
Принятие и изменение бизнес-модели: Практически в любом сценарии можно ожидать, что GenAI предложит частичную, а не полную замену деятельности. Нам по-прежнему будут нужны разработчики. Нам по-прежнему будут нужны сотрудники контакт-центров. Но их работа будет изменена. Это может стать гораздо большей проблемой, чем сама технология, особенно если учесть, что в моделях GenAI существует значительный "пробел в объясняемости". Это означает, что пользователи, скорее всего, не будут доверять им и, следовательно, не смогут использовать их должным образом (или вообще). Переподготовка сотрудников, чтобы они знали, как управлять моделями GenAI и работать с ними, потребует значительных усилий для достижения обещанного повышения производительности.
Цифровое доверие: GenAI создает серьезные проблемы с доверием, которые компаниям необходимо выявить. Учитывая, что национальные нормы, регулирующие конфиденциальность данных, отличаются по степени зрелости и степени ограничения, необходимо разработать политику, касающуюся использования служебной или конфиденциальной информации в сторонних сервисах и ответственности в случае утечки данных. Кроме того, компаниям необходимо продумать и отследить развитие интеллектуальной собственности (в частности, нарушение прав интеллектуальной собственности), а также предубеждения, которые могут проявиться в неотработанных моделях GenAI.
Также становится все более очевидным, что в мире, где все будут иметь доступ к "интеллектуальному" контенту, способность конкурентно выделяться будет все больше зависеть от собственных данных и возможностей исполнения.
Примечание
1. Майкл Чуй, Роджер Робертс и Ларейна Йи, "McKinsey technology trends Outlook 2022", McKinsey.com, 24 апреля 2022 года, https://www.
.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-top- trends-in-tech.
Глава 4. Разберитесь
, какие ресурсы вам нужны, чтобы достичь желаемого
Организационной единицей в цифровой трансформации и трансформации с использованием ИИ является agile pod (иногда его называют squad, scrum, agile team или cross-functional team). Подгруппа - это междисциплинарная команда из 5-10 человек, которая занимается проектированием, разработкой и производством определенного цифрового продукта или услуги в течение длительного периода времени. Создание цифровой дорожной карты - это, по сути, упражнение на определение количества и типа agile-подразделений, необходимых для выполнения работы.
Здесь мы не будем подробно рассказывать о том, как работают эти agile pods (об этом вы можете прочитать в главе 13).
Состав стручка
В Agile-подах есть владелец продукта (также иногда называемый менеджером продукта или владельцем подов), скрам-мастер1 , группа соответствующих цифровых технологов и экспертов по вопросам бизнеса (см. Рисунок 4.1). Большинство членов подгруппы на 100% посвящают себя работе в подгруппе, поскольку это наиболее эффективный способ достижения высокой скорости разработки (хотя есть исключения для некоторых общих ресурсов, таких как архитекторы решений и agile-коучи).
Недавние исследования показали, что совместная работа команды в одном месте предпочтительна, но не обязательно является решающим фактором эффективности работы agile pod, особенно если разница в часовых поясах приемлема.
Архетипы капсул
При принятии решения о штатном расписании капсулы необходимо учитывать два важных момента. Во-первых, какой тип решения вы хотите разработать? Например, решение, требующее интенсивной аналитики, требует глубоких знаний в области инженерии данных и науки о данных. С другой стороны, решение, ориентированное на клиента, требует больше навыков в области проектирования пользовательского опыта и разработки программного обеспечения. В целом, большинство компаний определяют от трех до шести различных архетипов стручков (см. Рисунок 4.2). Хотя на рисунке представлены три классических архетипа стручков, существуют и другие, например стручок цифрового маркетинга, стручок подключенных систем (т. е. IoT) или стручок интеграции основных систем.
Второе соображение - это жизненный этап разработки. На начальном этапе вам нужны специалисты для определения объема работ, разработки решения, определения приоритетности вариантов использования и подготовки бизнес-обоснования.
Типичные роли в agile pod
Не исчерпывающий
БИЗНЕС
Предоставление бизнес и функциональной экспертизы
Владелец продукта
Определяет и расставляет приоритеты в дорожной карте и бэклоге продукта
Эксперт в данной области
Приносит опыт и знания в области бизнеса, функций, операций, права, рисков и соответствия нормативным требованиям
Бизнес/процессный аналитик
Обеспечивает понимание сквозного бизнес-процесса, поддерживает разработку бизнес-проекта, отслеживание ОКР и усилия по управлению изменениями
ДИЗАЙН
Создание пользовательского опыта для решения
Ведущий дизайнер
Руководит разработкой дизайна, ориентированного на клиента, разрабатывает план привлечения пользователей и проводит их тестирование
Дизайнер UI/UX
Создает пользовательский опыт, который приносит пользу бизнесу и удовлетворяет потребности клиентов
ИНЖИНИРИНГ
Концептуализация технической архитектуры, разработка кода и запуск решения в производство
Инженер-программист1
Разработка кода, написание модульных тестов и интеграция.
Инженер по обработке данных
Построение конвейеров данных для создания аналитических решений на основе различных источников данных
НАУКА О ДАННЫХ/АЙ
Анализируйте данные, чтобы определить ключевые моменты для решения.
Специалист по изучению данных
Анализирует и добывает бизнес-данные для выявления закономерностей и построения прогнозных моделей
Инженер по машинному обучению
Внедрение ML-моделей в производство, обеспечивающее производительность и стабильность модели
ПОДДЕРЖКА2
Предоставление дополнительных рекомендаций команде
Скрам-мастер
Контролирует процесс scrum и помогает
Самоуправляемая команда достигает своих целей
Agile тренер
Поддерживает и обучает команду по методам agile-разработки
Примечание: список не является исчерпывающим.
Инженеры-программисты - это разработчики полного стека, архитекторы решений, облачные инженеры и инженеры DevOps.
Эти роли уменьшаются по мере созревания стручков.
Архетипы подборок и типичное штатное расписание по жизненному циклу решения
Примеры - зависят от отрасли и компании
ИНТЕНСИВНЫЕ ЦИФРОВЫЕ РЕШЕНИЯ
Стадии жизни решения
Discovery
1 Владелец продукта
1 Ведущий дизайнер
0,5 Инженер-программист1,2
1 Бизнес-аналитик/аналитик процессов
1 МСП
Проверка концепции/МВП
1 Владелец продукта
1 Скрам-мастер
1 Ведущий дизайнер
1 дизайнер UI/UX
2-3 инженера-программиста1,2
1-2 МСП
Производство
1 Владелец продукта
1 Скрам-мастер
1 Ведущий конструктор1
1 дизайнер UI/UX
2-3 инженера-программиста2
1-2 МСП
Управление изменениями
1 Владелец продукта
1-2 Агенты перемен3
1 Бизнес-аналитик1
РЕШЕНИЯ С ИНТЕНСИВНОЙ АНАЛИТИКОЙ
Discovery
1 Владелец продукта
0,5 Специалист по изучению данных
0,5 Инженер по обработке данных
1 Бизнес-аналитик
1 МСП
Проверка концепции/МВП
1 Владелец продукта
1 Скрам-мастер1
2 Специалисты по исследованию данных
2 инженера по обработке данных
1 Бизнес-аналитик
1 МСП
Производство
1 Владелец продукта
1 Скрам-мастер1
1 Агент перемен
1 UI/UX-дизайнер1
1 Инженер по обработке данных
2 инженера по машинному обучению
1 Бизнес-аналитик
Управление изменениями
1 Владелец продукта
1-2 Агенты перемен3
1 Бизнес-аналитик1
РЕШЕНИЯ ДЛЯ РАБОТЫ С БОЛЬШИМИ ОБЪЕМАМИ ДАННЫХ
Discovery
1 Владелец продукта данных 1 Архитектор данных
1 Инженер по обработке данных
1 Данные МСП
1 Бизнес-аналитик
Проверка концепции/МВП
1 Владелец продукта данных 1 Скрам-мастер
1 Архитектор данных
2-3 инженера по обработке данных
1-2 инженера-программиста2
1-2 МСП по работе с данными
Производство
1 Владелец продукта данных 1 Скрам-мастер
1 Архитектор данных
2-3 инженера по обработке данных
1-2 инженера-программиста2
Управление изменениями
1 Владелец продукта
1-2 Агенты перемен3
1 Бизнес-аналитик1
1. Необязательно/по необходимости. 2. Инженеры-программисты - это разработчики полного стека, архитекторы решений, облачные инженеры и инженеры DevOps. 3. Члены команды, активно продвигающие изменения, работающие над внедрением новых решений и созданием организационной поддержки путем внедрения новых процессов, решения вопросов и проблем, а также устранения трудностей внедрения.
На этапе производства вам понадобятся инженерные возможности для обеспечения безопасности, эффективной работы и масштабирования решения.
В то время как штат подразделений меняется в течение всего жизненного цикла решения, передача кадров из одного подразделения в другое никогда не происходит. На самом деле, сохранение преемственности ключевых ролей, таких как владелец продукта, является ключевым фактором обеспечения слаженной работы по разработке.
Определив эти архетипы, становится проще оценить потребности в ресурсах для цифровой трансформации и ИИ. Как минимум, вы должны планировать по одной капсуле на каждое решение в вашей цифровой дорожной карте. Если решение сложное, то можно создать несколько капсул, ориентированных на разные сценарии использования. Назначение архетипов решениям требует некоторого опыта и практики, но вскоре это станет второй натурой.
Оценка общих потребностей в талантах
После того как вы определили архетипы подборок для каждого из ваших цифровых решений, становится ясно, какие потребности в талантах необходимы для трансформации в целом или, по крайней мере, на первые 18 месяцев (см. пример потребностей в талантах на рис. 4.3). По сути, это станет походным приказом для вашей команды Talent Win Room (см. главу 9). Со временем эти потребности будут меняться по мере развития решений и добавления новых. К этому процессу следует возвращаться ежеквартально.
Примечание
1. В более зрелых agile-организациях роль Scrum-мастера часто выполняют владельцы продуктов.
Оценка общих потребностей в талантах
Архетипы для каждого случая использования в квартал
Q1
Q2
Q3
Q4
Q5
Q6
ДОМЕН: ПЕРСОНАЛИЗИРОВАННЫЙ МАРКЕТИНГ
Решение:
Создайте актив данных о потребителях 360
Пример использования:
Загрузка внутренних данных
Обнаружение данных
Обнаружение данных
Данные PoC
Данные PoC
Data Prod.
Data Prod.
Ввод внешних данных
Обнаружение данных
Обнаружение данных
Данные PoC
Данные PoC
Data Prod.
Data Prod.
Создание API и интерфейсов потребления
Обнаружение данных
-
Цифровой PoC
Цифровой PoC
Digital Prod.
Digital Prod.
Активируйте цифровую маркетинговую кампанию
Разработка персонализированных предложений
Аналитические открытия
Аналитика PoC
Аналитика Прод.
Аналитика Прод.
Аналитика Прод.
Аналитика Прод.
Активируйте платный поиск
-
Цифровое открытие
Цифровой PoC
Цифровой PoC
Digital Prod.
Digital Prod.
Активируйте собственный сайт электронной коммерции
-
-
Цифровое открытие
Цифровой PoC
Цифровой PoC
Digital Prod.
ОБЛАСТЬ: ЦЕПОЧКИ ПОСТАВОК
Создание цифрового двойника цепочки поставок
Создание двойника данных о входящих материалах
Обнаружение данных
Обнаружение данных
Данные PoC
Данные PoC
Data Prod.
Data Prod.
Построение двойника данных трансформации операций
Обнаружение данных
Обнаружение данных
Данные PoC
Данные PoC
Data Prod.
Data Prod.
Построение двойника данных об исходящей готовой продукции
Обнаружение данных
Обнаружение данных
Данные PoC
Данные PoC
Data Prod.
Data Prod.
Разработка цифровой диспетчерской вышки
Разработка показателей своевременной доставки
Цифровое открытие
Цифровой PoC
Цифровой PoC
Digital Prod.
Digital Prod.
Цифровое управление.
Разрабатывайте прогнозы на основе данных о близнецах
-
-
Аналитические открытия
Аналитика PoC
Аналитика Прод.
Аналитика Прод.
ОБЛАСТЬ: ЗАКУПКИ
Создайте прозрачность расходов
Консолидируйте данные о расходах
Обнаружение данных
Обнаружение данных
Данные PoC
Данные PoC
Data Prod.
Data Prod.
Создание данных для полей спецификации продукта
-
Цифровое открытие
Цифровой PoC
Цифровой PoC
Digital Prod.
Digital Prod.
Загрузка в инструменты аналитики расходов
-
-
Цифровое открытие
Цифровой PoC
Цифровой PoC
Digital Prod.
Разработка аналитических моделей, которые должны быть
-
-
Аналитические открытия
Аналитика PoC
Аналитика Прод.
Аналитика Прод.
Предполагаемые необходимые роли
Q1
Q2
Q3
Q4
Q5
Q6
Владельцы продуктов
3
6
14
20
16
16
Архитекторы данных и инженеры по данным
23
22
37
20
38
38
Ведущие дизайнеры и дизайнеры UI/UX
2
6
18
20
26
24
Инженеры-программисты
1
4
26
43
30
29
Технологические выводы
11
10
10
8
10
10
Ученые, изучающие данные, и инженеры ML
1
3
5
9
10
10
Скрам-мастера и тренеры по agile
11
13
32
15
24
24
МСП
3
7
16
27
16
14
Другие
14
14
10
20
11
14
Всего
69
85
168
182
181
179
Глава 5. Создайте возможности
на данный момент и следующее десятилетие
То, что вы определили в своей "дорожной карте" цифровых технологий и ИИ, должно быть ориентировано на ближайшие два-три года. Но вы также создаете возможности предприятия, которые позволят вашей компании внедрять цифровые инновации в течение следующих 10 или более лет.
Такой долгосрочный подход к созданию возможностей, по сути, отличает лидеров цифровых технологий от тех, кто ищет быстрого решения проблемы за счет использования нескольких вариантов использования.
Корпоративные возможности требуют плана и реальных инвестиций, которые будут отвечать не только насущным потребностям приоритетных областей, но и долгосрочным потребностям организации по мере внедрения инноваций в области цифровых технологий и ИИ.
Это начинается с выработки общей точки зрения на текущее состояние цифровых возможностей, чтобы понять, что возможно в данный момент и что потребуется для реализации долгосрочного видения. Есть ли у вас необходимые навыки разработки программного обеспечения? Может ли ваша операционная модель масштабироваться до сотен капсул? Легко ли использовать критически важные данные?
Когда у организаций есть общая база фактов о том, где они находятся с точки зрения возможностей, они могут строить реалистичные планы относительно того, что возможно в течение определенного периода времени.
Оценка базовых цифровых возможностей
Для реализации цифровых решений необходимы четыре основные возможности: таланты, операционная модель, технологии и данные. В разделах со второго по пятый этой книги подробно рассматривается каждый из них. Но понимание того, как компания соотносится с передовым опытом по этим возможностям, является необходимым условием для того, чтобы знать, что делать для их улучшения. Это можно сделать, сравнив свой бизнес с компаниями, которые идут дальше по этому пути, причем не только в своей отрасли, но и, желательно, в отраслях, опережающих вашу в плане цифровой трансформации.
Вы можете задаться вопросом, почему цифровые возможности банка могут быть хорошим ориентиром для ресурсной компании. Дело в том, что основные цифровые возможности в значительной степени не зависят от отрасли. Цифровые таланты во многом одинаковы. Agile-практики одинаковы. Современная технологическая архитектура и практика разработки программного обеспечения одинаковы (хотя эталонные архитектуры могут различаться в зависимости от отрасли). Другими словами, домены и способы их переосмысления зависят от отрасли, а основные возможности - нет.
Оценка цифровых возможностей
Результаты опроса по рейтингу возможностей в разбивке по категориям, по шкале 1-51
Пример компании CPG
В среднем по отрасли2
Лидер в области цифровых технологий и искусственного интеллекта average3
1 2 3 4 5
ДОРОЖНАЯ КАРТА
Смелое видение Связано с бизнес-стратегией Согласование с руководителями Деловое обоснование
Лидерство Стратегия талантов
ТАЛАНТ
Навыки Управление талантами
Agile методология Структура и роли Финансирование и управление
ОПЕРАЦИОННАЯ МОДЕЛЬ
Функции управления
Распределенная архитектура Облако/инфраструктура
ТЕХНОЛОГИЯ
DevSecOps
Безопасность
Видение и стратегия данных Архитектура данных Продукты данных Управление данными
ДАННЫЕ
Внедрение решений Масштабирование Управление производительностью Управление изменениями
ВНЕДРЕНИЕ И МАСШТАБИРОВАНИЕ
1. 1 = отстающие; 5 = лучшие в своем классе. 2. Среднее значение верхнего квинтиля компаний (из отрасли CPG) в базе данных McKinsey Digital Quotient (DQ) по всем географическим регионам. 3. Среднее значение квинтиля лучших компаний в базе данных DQ, по отраслям и географическим регионам.
ПРИЛОЖЕНИЕ 5.1
Бенчмаркинг проводится путем опроса сотрудников с использованием стандартизированного инструмента опроса. В Примере 5.1 приведен хороший пример результатов, полученных от компании, производящей потребительские товары.
Опросы имеют свои ограничения, поэтому также полезно пригласить независимых экспертов для проведения интервью с руководителями и менеджерами различных подразделений и функций. Это придаст дополнительные краски и перспективы при интерпретации результатов. Наконец, руководители должны найти время для посещения образцовых компаний, чтобы понять, как они шли к цифровым технологиям и как создавали свои цифровые возможности. Это поможет лучше оценить необходимые инвестиции и усилия.
Еще один полезный подход к оценке - "взгляд назад", анализ прогресса и препятствий, с которыми столкнулась компания при разработке и внедрении цифровых решений. Это особенно полезно для компаний, которые уже начали этот путь, но чувствуют себя заторможенными. Анализ должен начинаться с формирования портфеля решений, которые вы будете изучать. Затем с помощью интервью с заинтересованными сторонами вы можете классифицировать и разделить каждое решение по степени его продвижения на каждом этапе ценности в рамках воронки зрелости (см. Рисунок 5.2).
Это упражнение особенно полезно для выявления коренных причин, когда цифровая трансформация застопорилась. Пример 5.2 приведен на примере одного из мировых производителей продуктов питания. Проанализировав свои цифровые расходы в размере 130 миллионов долларов на 400 цифровых решений, компания поняла несколько важных вещей. Во-первых, общие расходы на цифровые технологии в размере 130 миллионов долларов были разумными, хотя и небольшими на фоне общих расходов на ИТ в размере 1 миллиарда долларов. Наше эмпирическое правило гласит, что расходы на цифровую трансформацию должны составлять около 20 % от расходов на ИТ или больше, хотя это зависит от конкретной ситуации.
Во-вторых, проекты были субмасштабными. При среднем расходе
США за проект, этот портфель был слишком перекошен в сторону пилотов и экспериментов.
Взгляд назад на инвестиции в цифровые технологии
Пример мирового производителя продуктов питания
ПРОГРЕССИЯ ПРОЕКЦИИ
КОЛИЧЕСТВО РЕШЕНИЙ
ПОТЕНЦИАЛ ПРОИЗВОДИТЕЛЬНОСТИ РЕШЕНИЙ НА ДАННОМ ЭТАПЕ
% от общего показателя EBITDA компании
IDEA
Идея, подтвержденная для решения бизнес-проблемы
160
<1%
ПИЛОТ / ТЕСТИРОВАНИЕ
Концепция проверена и готова к разработке бизнес-кейса
35
<1%
ПРЕДЛОЖЕНИЕ
Утверждение бизнес-проекта и начало создания решения
30
<1%
ВНЕДРЕНИЕ Частичное внедрение
35
<1%
ПРОДУКЦИЯ
Полное развертывание и масштабирование
20
<1%
Больше не активен 120 <1%
ОСТАНОВКА
ПРИЛОЖЕНИЕ 5.2
В-третьих, общий потенциал воздействия этого портфеля незначителен - даже в случае успеха 100 % проектов общий показатель EBITDA повысился бы менее чем на 1 % (как уже говорилось в предыдущей главе, еще одно наше эмпирическое правило - надежная цифровая дорожная карта должна обеспечивать повышение EBITDA на 20 % и более). Наконец, слишком много проектов было остановлено и слишком мало доведено до производства - опять же, признак того, что компания слишком много занималась пилотированием "снизу вверх".
В совокупности это симптомы компании, в которой руководители высшего звена не уделяют достаточно времени тому, чтобы заново представить себе, как они могут конкурировать с собственными цифровыми решениями и решениями на основе искусственного интеллекта.
Эти выводы стали открытием для высшего руководства компании. Они сразу же поняли, что для более эффективного управления расходами им необходим подход "сверху вниз". Первым шагом стало прекращение большинства текущих проектов и консолидация расходов на коммерческом и операционном направлениях. Затем они поручили высшим руководителям этих областей разработать действительно преобразующие цифровые дорожные карты и сконцентрировать инвестиции на разработке меньшего числа решений, оказывающих большое влияние, а также на создании кадрового и технологического потенциала для их дальнейшего совершенствования. Они также выделили достаточные средства для внесения необходимых изменений в рабочие процессы и обучения пользователей. В течение 18 месяцев они добились увеличения прибыли на 150 миллионов долларов в год.
Определение потребностей в наращивании потенциала
После проведения оценки базовых возможностей и разработки планов по переосмыслению домена становится относительно просто разработать план создания возможностей и соответствующие инвестиционные потребности. По сути, речь идет об определении объема работ и ресурсов, необходимых для создания необходимых возможностей, которые затем можно включить в общую цифровую дорожную карту (см. подробнее о дорожной карте в главе 6).
На рисунке 5.3 показаны конкретные элементы плана наращивания потенциала компании, производящей потребительские упаковочные товары, на первые 18-24 месяца трансформации.
Партнерство для ускоренного наращивания потенциала
При разработке планов по наращиванию потенциала вам, скорее всего, придется прибегнуть к услугам третьих сторон, чтобы дополнить или расширить имеющиеся возможности. При этом будьте осторожны и не передавайте из рук в руки основные цифровые возможности, которые будут играть ключевую роль в развитии конкурентных преимуществ. В краткосрочной перспективе вы можете привлекать партнеров для создания таких возможностей, но в средне- и долгосрочной перспективе необходимо сохранить в компании те возможности, которые являются основополагающими для создания стоимости.
Ключевые элементы плана наращивания потенциала
Типичные элементы для первых 18-24 месяцев
ТАЛАНТ
ОПЕРАЦИОННАЯ МОДЕЛЬ
ТЕХНОЛОГИЯ
ДАННЫЕ
УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
Потребности в кадрах: количество и тип необходимых технологов, как минимум, на 1 год
(гл. 4)
Поиск талантов: создание комнаты для поиска талантов (гл. 9) и плана поиска (гл. 10)
Программы обучения для руководителей, лидеров доменов и членов стручков (гл. 12)
Подход к обучению команд методологиям agile-работы (гл. 13)
Операционная модель будущего состояния и план перехода (гл. 14)
Архитектура технологического стека будущего состояния для поддержки приоритетных доменов (гл. 17)
Подход к решению задач миграции в облако для приоритетных доменов (гл. 18)
Подход к внедрению DevSecOps и поддержка разработчиков (гл. 18)
План доступа к ключевым элементам данных и их обработки для приоритетных областей (гл. 24)
Создание приоритетных продуктов данных (гл. 25)
Архитектура данных будущего состояния
(гл. 26)
Создание трансформационного офиса (гл. 30)
Система отслеживания стоимости, создаваемой цифровыми решениями
(гл. 30)
Широкомасштабное организационное обучение по цифровым технологиям (гл. 32)
Ресурсы и инвестиции, требуемые на квартал 
ПРИЛОЖЕНИЕ 5.3
Мы рассмотрели четыре типа партнерств, которые могут работать при правильном подходе и структурировании:
Зонтик: Как и в случае с генеральным подрядчиком при строительстве дома, вы можете сотрудничать с фирмой, которая помогает спланировать и организовать преобразования, возможно, подбирает кадры, а также помогает вам найти и организовать других поставщиков кадров, технологий и данных. Лучше всего работать с одним зонтичным партнером, чтобы избежать ошибок и сложностей с координацией.
Таланты: Использование партнеров для поиска талантов позволяет значительно увеличить скорость и гибкость. Правильный партнер может развернуть команду квалифицированных специалистов на вашем предприятии в считанные дни, а затем покинуть его, когда в них отпадет необходимость. Они также могут предоставить услуги по повышению квалификации и обучению. На первых порах такое партнерство может оказаться необходимым, но оно должно быть разработаны таким образом, чтобы со временем уменьшаться по мере того, как вы будете наращивать свои собственные возможности.
Технологии: Партнеры помогут разместить, обработать и защитить приложения и данные. Поставщики облачных услуг (CSP) предоставляют все более широкий спектр услуг и возможностей, особенно в области данных и аналитики (подробнее об этом читайте в главе 18). Другие поставщики программного обеспечения также могут быть актуальны в зависимости от решений, которые вы создаете (например, технологии маркетингового стека для цифрового маркетинга). Вам также могут понадобиться специальные технологические партнерства, связанные с такими специализированными возможностями, как геолокация или тестирование на проникновение.
Данные: Третьи стороны могут предоставить важные дополнительные данные. Публичные источники данных, брокеры данных и рынки данных - все они предлагают широкий спектр данных и услуг, связанных с ними. Компаниям необходимо тщательно продумать протоколы доступа к данным, интеллектуальную собственность и риски кибербезопасности.
Эффективность использования партнерских отношений в конечном итоге зависит от того, насколько хорошо компания знает, в чем заключаются пробелы в ее возможностях, и насколько хорошо она может выстроить партнерские отношения, чтобы заполнить эти пробелы в ближайшей перспективе, одновременно развивая их в долгосрочной перспективе.
Глава 6.
Цифровая дорожная карта - это контракт для вашего руководства
Конечным результатом процесса составления дорожной карты под руководством бизнеса является дорожная карта реализации и соответствующий финансовый план.
На рисунке 6.1 приведен реальный пример цифровой дорожной карты для компании CPG. Обратите внимание на конкретные домены (персонализированный маркетинг, цепочка поставок и закупки) и на то, как параллельно идет работа по наращиванию потенциала. Эта дорожная карта ограничивается первыми тремя областями. На втором и третьем годах трансформации в эти домены добавляются дополнительные решения для продолжения преобразований и запускаются новые домены.
Не стоит планировать дальше, чем на два-три года. Все неизбежно изменится, и вы многому научитесь в первый год. Четко определите цель, к которой вы стремитесь, и будьте гибкими в выборе пути к ней.
Существует пять признаков хорошей дорожной карты цифровой трансформации и трансформации с помощью ИИ:
Домены и лежащие в их основе цифровые решения выстраиваются таким образом, чтобы обеспечить значимую стоимость в краткосрочной и среднесрочной перспективе.
Трансформация домена четко привязана к улучшению операционных KPI, которые, в свою очередь, связаны с созданием стоимости. Бизнес-лидеры привержены дорожной карте домена, а ожидаемые выгоды включены в их бизнес-цели и план мотивации.
В общем плане четко прописано наращивание потенциала предприятия - талантов, операционной модели, технологий и данных - и указаны необходимые инвестиции и время, необходимое для достижения зрелости.
Общий финансовый план ясен и отражает реалистичный, но при этом прогрессивный временной и инвестиционный горизонт. Очень важно, чтобы финансовые показатели были такими же строгими, как при формировании обычных расходов или доходов, и чтобы прогресс измерялся месяцами, а не годами.
Управление изменениями для всей трансформации и для конкретных решений включено. Офис трансформации разработал программу управления изменениями и четкую модель управления, а также определил измеримые квартальные "мильные камни" (подробнее об этом в главе 30).
Цифровая дорожная карта - это момент, когда руководство "складывает руки" в знак согласия. По сути, дорожная карта становится контрактом, который руководство подписывает для выполнения.
Цифровая дорожная карта - это контракт для руководства компании 59
Стратегическая дорожная карта для всей трансформации
Пример для потребителя
ФАЗА 1
компания по производству упакованных товаров Разработка цифровых технологий
дорожная карта - 20ХХ
Преобразование доменов-маяков и создание цифровых возможностей - 20XY
ФАЗА 3
Удар по шкале - 20XZ
ФАЗА 2
Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2
ФУНДАМЕНТАЛЬНЫЕ ВОЗМОЖНОСТИ
Цифровая дорожная карта
Развитие цифровых талантов Обучение талантливых специалистов
ДИЗАЙН
ДИЗАЙН
ДИЗАЙН
ДИЗАЙН
Discovery
Доказательство концепции/производственное решение MVP
ДИЗАЙН
ДИЗАЙН
3
15
27
45
63
5
8
12
10
10
8
8
8
-5
-8 -12
-7
+5 +19 +37 +55
Agile операционная модель: Разработка и внедрение цифровой фабрики
Технологии: Облачная готовность Данные: Архитектура и всасывание
DOMAINS
ПЕРСОНАЛИЗИРОВАННЫЙ МАРКЕТИНГ
Создайте актив данных о потребителях 360
Активируйте цифровые маркетинговые кампании
ЦЕПОЧКА ПОСТАВОК
Создание цифрового двойника цепочки поставок
Повышение оперативности реагирования с помощью цифрового пульта управления
ПРОКУРАТУРА
Создайте прозрачность расходов Разработайте аналитику расходов, которые должны быть
УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
Коммуникация и взаимодействие Отслеживание этапов и стоимости
Управление рисками
ФИНАНСЫ
Повышение EBITDA Денежные инвестиции
Чистые денежные средства
ПРИЛОЖЕНИЕ 6.1
Глава 7.
Конечная корпоративная
Лидерство играет решающую роль в любой трансформации, но интенсивный, межфункциональный характер цифровой трансформации и трансформации с использованием искусственного интеллекта требует гораздо более тесного сотрудничества между всеми членами совета директоров. Каждый должен сыграть свою важную роль, и без этого успех преобразований будет под угрозой.
Генеральный директор
Поскольку цифровые и искусственные преобразования требуют интенсивного межфункционального взаимодействия и создания общих возможностей предприятия, генеральный директор (или руководитель подразделения, если речь идет о конгломератах) играет важную роль.
Важнейшая роль. Они отвечают за обеспечение согласованности действий на высшем уровне и разработку архитектуры новых возможностей предприятия, чтобы избежать недопонимания со стороны организации.
Генеральный директор играет особенно важную роль в созыве и сплочении руководства вокруг необходимости преобразований, а также в регулярном информировании о видении, согласовании и обязательствах по укреплению преобразований. Трансформация с помощью цифровых технологий и ИИ также может иметь далеко идущие последствия для сквозных процессов, например, сокращение количества обслуживающих мощностей в отделениях банка, когда клиенты все чаще используют банковские приложения для выполнения определенных задач. Поскольку эти побочные эффекты могут затронуть множество различных подразделений организации, генеральному директору необходимо постоянно проводить перекалибровку и перестройку всей бизнес-системы, чтобы получить максимальную выгоду.
Генеральный директор также играет важную роль в обеспечении подотчетности сотрудников за результаты преобразований: он постоянно следит за ключевыми показателями прогресса и жестко регулирует стимулы руководства. Как правило, генеральный директор тратит на обеспечение успеха преобразований от двух до четырех дней в месяц, а на начальном этапе - несколько больше.
Главный специалист по трансформации
В то время как генеральный директор участвует в цифровых преобразованиях и несет за них ответственность, за повседневную деятельность и управление преобразованиями отвечает специальный руководитель. Этот ответственный за преобразования, как правило, подчиняется непосредственно генеральному директору и является лицом цифровых технологий в организации, даже если этот человек временно исполняет свои обязанности. Обычно эта роль длится два-три года (в некоторых случаях эту роль выполняет главный специалист по цифровым технологиям или он является одним из руководителей). К этому времени преобразования должны превратиться из специальной инициативы в часть повседневной работы руководства.
Этот лидер должен уметь создавать и продвигать убедительную концепцию, иметь сквозное понимание того, как работает компания, и обладать сильной интуицией в отношении того, как цифровые технологии и искусственный интеллект могут ее преобразить. Это авторитетный руководитель, способный влиять на высшее руководство и внедрять жесткую дисциплину управления программой. По этой причине лидер преобразований, как правило, нанимается изнутри.
Типичные обязанности специалиста по трансформации на начальном этапе трансформации включают:
Разработка и руководство процессом обучения руководителей в области цифрового лидерства
Работа с командой руководителей по разработке дорожной карты цифровых технологий
Работа с HR и IT для обеспечения надлежащей оценки талантов, технологий и данных в приоритетных областях.
Разработка, в сотрудничестве с бизнесом, финансами, ИТ и HR, представления о необходимых инвестициях и ресурсах, а также об ожидаемых выгодах
Создание сильной вовлеченности в цифровую трансформацию на уровне исполнительного комитета и на один-два уровня ниже в организации, а со временем и во всей организации
На этапе выполнения преобразований обязанности лидера трансформации расширяются и включают в себя управление ходом преобразований, контроль за программами обучения и управления изменениями, а также решение конкретных проблем по мере их возникновения (подробнее об этом читайте в главе 30).
Технический директор, ИТ-директор и CDO
Эти три роли, связанные с техникой, могут существовать или не существовать в вашей организации. В некоторых компаниях есть все три. Другие могут объединять две или все из них в одну роль. Это может быть по-разному, и часто зависит от набора навыков сотрудников.
ИТ-директор (директор по информационным технологиям) обычно занимается улучшением внутренней работы компании с помощью технологий. Они контролируют основные системы и технологическую инфраструктуру компании. ИТ-директор обеспечивает критически важное архитектурное руководство и играет ведущую роль в определении/развитии облачной архитектуры целевого состояния.
CTO (Chief Technology Officer) обычно работает над улучшением предложений для клиентов с помощью технологий. Они контролируют приложения, которые непосредственно касаются клиента, например банковские банкоматы или программные приложения в автомобиле. Роль технического директора в трансформации может быть разной, в зависимости от того, какие именно обязанности он выполняет в вашей компании. Если его роль в значительной степени ориентирована на продукт, технический директор, естественно, сосредоточится на разработке или развитии цифровой дорожной карты продукта.
CDO (главный специалист по цифровым технологиям) в некоторых случаях выступает в роли соруководителя преобразований и, как правило, создает новый цифровой опыт для клиентов или внутренних пользователей. CDO играет центральную роль в поддержке каждой приоритетной области в определении архитектуры цифровых решений, определении потребностей в ресурсах для их реализации и контроле за их внедрением. В процессе реализации они следят за внедрением этих решений и создают соответствующие возможности.
Вы заметите некоторое совпадение между ролью CDO и ролями CIO и CTO. Однако основное различие заключается в том, что CDO привносит новый набор навыков, которых может не быть у ИТ-директоров или технических директоров. Они хорошо разбираются в разработке современного программного обеспечения и в передовых методах искусственного интеллекта и данных. Они живут и дышат agile и могут распознать хорошие agile-практики. Они могут составить план поставки сложного цифрового решения, определив необходимое количество подразделений, состав сотрудников, продолжительность и правильные OKR. Они также понимают, как создается современный стек технологий.
На самом деле эти три роли все больше смешиваются, поскольку ИТ-директора и технические директора становятся все более подкованными в современных цифровых технологиях и методах работы. Чтобы запустить цифровую трансформацию и трансформацию с использованием ИИ, вам потребуется вклад всех трех ролей. В четвертом разделе этой книги рассказывается о различных технологических аспектах, которые должны контролировать CDO/ CIO/ CTO.
Главный специалист по данным
Если в вашей компании есть главный специалист по данным, он будет руководить разработкой архитектуры данных, определением продуктов данных и внедрением эффективного управления данными (об этом говорится в пятом разделе).
CHRO (директор по персоналу) играет решающую роль на ранних этапах трансформации, чтобы привлечь необходимые цифровые таланты и внедрить методы управления талантами, которые помогут развивать и удерживать цифровые таланты (об этом говорится во втором разделе).
Финансовый директор
Финансовый директор (Chief Financial Officer) контролирует разработку бизнес-кейса трансформации, как описано ранее в этом разделе, и отслеживание реализации ценности (о чем вы можете прочитать в шестом разделе этой книги). Кроме того, он будет играть центральную роль в переосмыслении подходов к планированию и финансированию компании, чтобы сделать их более гибкими (об этом говорится в третьем разделе).
Главный специалист по рискам
Ответственный за управление рисками отвечает за то, как первая линия защиты и вторая линия защиты будут выполнять свои функции в условиях наличия нескольких команд гибких разработчиков. Ему также необходимо понять, как реагировать на новые риски, такие как конфиденциальность данных и кибербезопасность, которые может породить цифровая трансформация и ИИ (эти темы рассматриваются в разделах 3 и 6, соответственно).
Руководители бизнес-направлений и бизнес-функций
Руководители бизнес-направлений и функций (например, операций, маркетинга, продаж, закупок, цепочек поставок, НИОКР), занимающие места на уровне руководителей высшего звена, курируют важные сферы бизнеса, которые, скорее всего, будут иметь большое значение в цифровой дорожной карте. Например, директора по маркетингу играют важнейшую роль в разработке новых методов привлечения клиентов, которые могут быть заинтересованы в продуктах или услугах компании, персонализации предложений для них и измерения удовлетворенности клиентов в режиме реального времени на разных этапах работы в Интернете. Руководители направлений и бизнес-функций должны играть активную спонсорскую роль в переосмыслении своей сферы деятельности, а также проявлять любопытство в понимании искусства возможного. Они должны быть смелыми в формировании концепции преобразований и гибкими в принятии новых методов работы.
Готовность. Раздел первый
Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:
Способна ли ваша команда лидеров сформулировать видение бизнеса и то, как технологии будут способствовать его достижению?
Каковы основные бизнес-домены, на которых вы сосредоточились, - есть ли у них наилучшие шансы привлечь внимание и действительно ли они выполнимы?
Может ли ваша команда сформулировать ожидаемые выгоды и инвестиции, необходимые для преобразования ваших приоритетных областей? Ясно ли вам, как вы будете создавать устойчивые конкурентные преимущества?
Направлены ли ваши ресурсы на два-пять четко определенных и взаимосвязанных доменов, которые могут принести реальную пользу?
Ясно ли вам, какие новые цифровые возможности предприятия необходимы, и сделаете ли вы необходимые инвестиции для их создания?
Насколько хорошо ваши топ-менеджеры могут сформулировать свои роли и обязанности, а также обязанности своих команд в реализации цифровой дорожной карты?
Ни одна компания не может передать свой путь к цифровому совершенству на аутсорсинг. Быть цифровым - значит иметь собственную команду цифровых талантов - владельцев продуктов, дизайнеров опыта, инженеров данных, ученых данных, разработчиков программного обеспечения и т. д. - работающих бок о бок с вашими коллегами по бизнесу.1
По этой причине цифровые преобразования и преобразования с использованием искусственного интеллекта - это в первую очередь преобразования, связанные с людьми и талантами.2 И начать их нужно не скоро, потому что необходимо мобилизовать технологов на выполнение цифровых задач, а привлечение нужных талантов занимает больше всего времени по сравнению с другими приоритетами.
Руководители старых компаний не должны думать, что им нужно уступать лучшие цифровые таланты компаниям Кремниевой долины. Устоявшиеся компании с вдохновляющими программами и реальной заботой о людях успешно создают скамейку цифровых технологов. Многие из них доказали это.
Лучшие программы по развитию цифровых талантов выходят далеко за рамки найма: они создают и реализуют интересные ценностные предложения для сотрудников, разрабатывают более гибкие и цифровые HR-процессы и берут на себя обязательства по созданию среды, в которой лучшие таланты становятся лучше. В этом разделе мы расскажем вам, как это сделать.
Глава 8: Основные и неосновные возможности - стратегическое планирование талантов. Разработайте четкое представление о талантах, которые у вас есть, талантах, которые вам нужны, и план по устранению разрыва. Это может показаться простым, но это не так.
Глава 9: Команда талантов, которая может создать вашу цифровую команду. Создайте команду, которая понимает, как находить, нанимать и удерживать таланты в сфере цифровых технологий.
Глава 10: Нанимайте цифровых специалистов, когда они на самом деле интересуются вами. Вам не обязательно быть технологической компанией, чтобы завоевать лучшие кадры. Разработайте убедительное ценностное предложение для сотрудников, а также опыт найма и оформления на работу, основанный на том, что хотят и в чем нуждаются кандидаты и сотрудники.
Глава 11: Распознать отличительных технологов. Это легче сказать, чем сделать. Нужно уметь отличать людей с отличными техническими навыками от остальных и строить двойную карьеру для цифровых талантов, не меняя полностью систему управления талантами в вашей компании.
Глава 12: Воспитание мастерства. Поскольку технологии развиваются так быстро, талантливые специалисты в области цифровых технологий уделяют большое внимание обучению и развитию на рабочем месте, так же как и вы.
Примечания
Свен Блюмберг, Ранья Реда Куба, Суман Тареджа и Анна Визингер, "Технотоника талантов: Десять новых реалий для поиска, удержания и развития талантов", McKinsey.com, 14 апреля 2022 г. https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/tech-talent-tectonics- ten-new-realities-for-finding-keeping-and-developing-talent
"В разрушительные времена сила исходит от людей: Интервью с Эриком Шмидтом", McKinsey Quarterly, 5 марта 2020 года, https://www.
Основные и неосновные возможности – стратегическое планирование талантов
Есть ли у вас "дорожная карта" талантов, столь же подробная, как и "дорожная карта" технологий? Этот вопрос может застать многих руководителей врасплох. И если ответ не утвердительный, очень важно разработать продуманный и реалистичный план.1
Кадровое планирование - это процесс преобразования цифровой дорожной карты и видения - плана приоритетных решений и команд (или групп), необходимых для их создания, - в реальные потребности в кадрах. Это включает в себя инвентаризацию уже имеющихся у вас кадров и сопоставление их с теми, которые вам нужны для реализации "дорожной карты" цифровых технологий. На основе этого анализа вы можете разработать план действий по устранению пробелов. Вы можете подумать, что это слишком упрощенно, но на самом деле здесь много сложностей.
Какие таланты вам нужны в штате?
Каждая компания сталкивается с одним и тем же стратегическим вопросом, когда дело доходит до цифровых преобразований и преобразований с использованием искусственного интеллекта: "Нужно ли нам владеть этими талантами?". Руководители могут возразить, что технологии не являются их основным бизнесом - это предложение ипотечных кредитов или добыча ресурсов. Они также могут возразить, что в прошлом они в значительной степени передавали ИТ-возможности на аутсорсинг, так почему же в случае с цифровыми технологиями и ИИ все должно быть иначе?
Однако реальность такова, что если компания хочет конкурентно дифференцировать себя с помощью цифровых решений, ей необходимо иметь в своем штате таланты, которые обеспечат эту дифференциацию. Наш анализ компаний, которые являются цифровыми лидерами - будь то в сфере технологий или в более развитых отраслях - ясно показывает, что они всегда имеют основной резерв цифровых талантов. Мы еще не видели ни одной компании, которая бы на аутсорсинге достигла своего цифрового совершенства.
Причина, по которой так важно иметь собственный стенд, заключается в том, что он позволяет технологам тесно сотрудничать со своими коллегами по бизнесу и операционной деятельности для разработки и постоянного совершенствования цифровых решений. Такая близость обеспечивает быстрые циклы разработки. Кроме того, технологи получают ценное понимание бизнес-контекста. Специалист по изучению данных будет во много раз более продуктивен при разработке решения по управлению доходами для компании, производящей потребительские товары, если он понимает динамику потребительских цен, позиционирование брендов и информационную среду компании. Контекст имеет значение для разработки отличных цифровых решений.
Однако не все цифровое является конкурентным преимуществом. Многие возможности, например услуги, которые предлагают поставщики облачных вычислений, или узкоспециализированные навыки, такие как тестирование на проникновение, обеспечивающее кибербезопасность приложения, или геолокационные сервисы для отслеживания пользователя, все они могут быть важны для цифрового решения, но не могут быть источником конкурентного преимущества вашего бизнеса. В таком случае эти возможности следует найти в источниках.
Возможно, вам также потребуется со временем увеличивать или уменьшать численность вашей цифровой команды в соответствии с изменениями в бизнес-среде. Это также может стать причиной для заключения контракта на привлечение гибкого персонала, но следует понимать, что бесплатного обеда не бывает. Эти сотрудники могут обеспечить гибкость, но они не будут столь же эффективны, как ваши внутренние ресурсы, поскольку им не хватает контекста и они не так сильно вкладываются в работу. Как правило, следует стремиться к тому, чтобы 70-80 % ваших цифровых специалистов были штатными, а для остальных привлекать внешнюю поддержку.
Для создания качественного цифрового резерва требуется время. Компании, находящиеся на начальном этапе цифровой трансформации и трансформации с использованием искусственного интеллекта, часто в значительной степени полагаются на внешних подрядчиков и параллельно запускают машину по приобретению цифровых талантов и повышению квалификации своих сотрудников. Со временем они заменяют подрядчиков собственными сотрудниками. В зависимости от того, насколько смелыми являются амбиции, через один-два года они обычно достигают целевого уровня в 70-80 %.
Например, компания, производящая потребительские товары, начала свою цифровую трансформацию с создания пяти подразделений, укомплектованных в основном за счет ведущего партнера-консультанта, поскольку у нее не было собственных специалистов. В то же время она нанимала лучших технических специалистов со скоростью примерно 10-15 человек в месяц. Менее чем за год компания смогла в значительной степени заменить сотрудников своего партнера-консультанта своими собственными людьми.
Понимание того, какие цифровые таланты у вас есть
Узнать, какими цифровыми талантами вы располагаете, - задача гораздо сложнее, чем может показаться на первый взгляд. Это связано с тем, что вам необходимо определить навыки и квалификацию имеющихся специалистов - простым перечислением названий должностей вы не добьетесь результата (см. Рисунок 8.1).
Таксономия навыков цифровых талантов
УРОВЕНЬ 1: СЕМЬИ УМЕНИЙ
Agile
Облако
База данных/хранилище данных
Аналитика и отчетность
Инженерия данных
Дизайн
DevOps
Операционные/инфраструктурные услуги
Автоматизация
Тестирование
Управление продуктами
Наука о данных
~110
15 семей
УРОВЕНЬ 2: ПОДГРУППЫ НАВЫКОВ
Безопасность
Архитектура
Разработка
УРОВЕНЬ 3: НАВЫКИ
Веб-разработка
Облачные разработки
Разработка приложений
подгруппы
~650
Java
C++
.NET
навыки
ПРИЛОЖЕНИЕ 8.1
В большинстве организаций такой точный уровень сопоставления навыков существует редко. То есть, например, знать, что кто-то является "Java Web Developer", гораздо полезнее, чем просто знать, что кто-то является разработчиком. Аналогично, инженер по облачным технологиям значительно отличается от инженера по обработке данных, и хотя вам, скорее всего, понадобятся и те, и другие, вы должны четко понимать, чем они занимаются, чтобы наилучшим образом использовать их навыки. Не менее важно и то, что ландшафт технических навыков быстро меняется по мере того, как растет потребность в инженерах машинного обучения и инженеров генеративного ИИ, поэтому вам нужно будет следить за тем, как они развиваются.
Большинство организаций могут довольно легко определить численность персонала, занятого в различных должностных группах, путем сопоставления кадровых данных с упрощенной таксономией. Более важным шагом является понимание навыков и умений этих сотрудников, поскольку это позволяет понять, кто действительно может выполнять работу.
Как правило, у организаций нет надежного способа точно определить различия в уровне квалификации сотрудников, особенно технологов. Запуск запроса в системе управления персоналом едва ли даст вам отправную точку. Для оценки навыков существующих цифровых специалистов можно использовать четыре подхода:
Оценка менеджеров. Если вам нужно отобрать, скажем, 30-50 человек из нескольких сотен, полезно начать с быстрой оценки менеджера сверху вниз. Это поможет классифицировать имеющихся сотрудников по таксономии навыков и получить представление об уровне квалификации с помощью наблюдаемых моделей поведения. Например, инженер, которому поручают простые задачи и который нуждается в постоянном контроле, классифицируется как новичок. На другом конце шкалы инженер, который считается лидером в своей области, классифицируется как эксперт. Обратите внимание, что вам нужно будет контролировать суждения, основанные на собственных навыках каждого менеджера.
Индивидуальная самооценка. Для углубленной оценки всего ИТ- и цифрового персонала полезно провести опрос о навыках. Такой подход необходим, когда нужно провести инвентаризацию и оценку сотен, а то и тысяч сотрудников. Опрос поможет сотрудникам провести самооценку по подробной таксономии технических и функциональных навыков. Для этого существуют сторонние инструменты, которые относительно легко внедрить среди большого количества сотрудников. Эта методика страдает от присущих самооценкам предубеждений. Обратите внимание, что женщины традиционно оценивают себя ниже, чем мужчины, поэтому оценку необходимо корректировать.
Онлайн-тестирование. Сторонние компании, такие как Hackerank, Codility, CodeSignal и TestGorilla, предлагают специальные онлайн-тесты по кодингу, которые полезны для оценки конкретного базового уровня навыков
высокотехничных специалистов. Эти тесты, безусловно, наиболее точны в оценке технических навыков кодирования, но они могут нарушить работу организации и вызвать беспокойство или конфликт, поэтому важно продуманно управлять этим процессом.
Техническое собеседование. Для оценки навыков используется сочетание формального технического тестирования и личного собеседования. Эти виды оценки достаточно трудоемки и обычно проводятся только для ключевых ролей. Чтобы быть эффективными, эти собеседования должны проводиться старшими технологами, достигшими мастерства в конкретной дисциплине. Слишком часто компании путают старшего исполнителя в ИТ с человеком, обладающим техническими навыками. Это часто не так.
Пример из практики: Как одна компания выяснила, какими талантами она действительно обладает
Специализированная финансовая компания разработала новый цифровой инструмент поддержки продаж для своей крупной организации, занимающейся продажами на местах. Разработкой нового цифрового инструмента занималось цифровое подразделение компании, и, несмотря на то, что первый пилотный проект был успешным, приложение не смогло масштабироваться из-за проблем с репликацией данных и задержкой. Первопричиной стала неквалифицированная команда цифровых специалистов.
Используя Hackerank для тестирования цифровой команды из 100 человек, компания узнала, что только 20 % технологов имеют проходной балл 50 % (см. Рисунок 8.2). Неудивительно, что приложение компании было перегружено архитектурными и инженерными проблемами. Интересно отметить, что треть ресурсов была привлечена сторонними разработчиками, которые показали не лучшие результаты, и мы часто сталкиваемся с этой проблемой.
Не завершено
17
8
1-19%
24
8
20-39%
13
8
40-49%
9
3
50% плюс
5
6
70% плюс
8
1
Определение дефицита талантов
Тестирование возможностей кодирования для цифровой команды из 100 человек
Оценка возможностей кодирования, 0 = самый низкий уровень, 100% = самый высокий уровень
Тест
баллы
Внутренние ресурсы
Всего: 76 человек
Внешние ресурсы
Всего: 34
Примечание: каждый сотрудник проходил тестирование на знание кодирования по своему выбору, включая Python, Java, Android Kotlin и т. д.
ПРИЛОЖЕНИЕ 8.2
После того как оценка текущего состояния навыков завершена, вы можете сопоставить ее с будущими потребностями в кадрах, определенными цифровой дорожной картой. При этом важно учитывать два ключевых фактора, которые компании часто упускают из виду: первый заключается в том, что нанимать сотрудников по "описанию должности", а не по реальным навыкам, - это большой риск. Принято считать, что ценность отличного разработчика в 5-10 раз выше, чем ценность среднего разработчика. Во-вторых, не стоит забывать о таких важных для цифровой эпохи качествах, как
гибкость, умение общаться и сотрудничать и, возможно, самое важное - способность к обучению.
Пример из практики: Глобальная страховая компания восполняет пробел в талантах
Давайте посмотрим на анализ нехватки талантов в глобальной страховой компании (см. Рисунок 8.3). Это мероприятие охватывало всех ее внутренних технических специалистов. Сотрудники оценили свой уровень квалификации по шкале от 1 (новичок) до 5 (эксперт) для ключевых ролей, определенных в цифровом плане. Компания сопоставила текущее состояние с будущими потребностями, чтобы выявить пробелы. В результате было получено четкое представление о приоритетах в работе с талантами (в данном конкретном примере уровни компетенции 1 и 2 отнесены к новичкам, а от 3 до 5 - к специалистам).
Подход компании к восполнению нехватки талантов подчеркивает важные моменты, которые применимы ко многим компаниям, осуществляющим цифровую трансформацию и трансформацию с использованием искусственного интеллекта:
Больше внутренних сотрудников и меньше подрядчиков. Эта компания активно возвращает свои технические таланты в компанию, изменив соотношение 39 % внутренних/61 % внешних сотрудников на 70 % внутренних/30 % внешних. Это масштабно. Это не только разумный стратегический шаг, но и экономия средств (при условии отсутствия изменений в географическом положении).
Больше исполнителей и меньше проверяющих. Эта компания нанимает огромное количество инженеров по интеграции (также известных как full-stack инженеры) и специалистов по работе с данными, сокращая при этом количество сотрудников в категориях, которые исторически ассоциируются с водопадной разработкой, таких как управление программами и управленческие роли. По сути, им нужно больше людей, способных создавать код, и меньше тех, кто управляет и контролирует, что позволит увеличить эффективный потенциал разработки на 15 % и сократить численность персонала на 15 %. Это возможно только потому, что подходы agile-разработки позволяют создать более плоскую и наделенную большими полномочиями организацию.
Больше компетентных практиков и меньше новичков. Уровень компетенции имеющихся в компании сотрудников гораздо ниже необходимого. Пирамида талантов в цифровую эпоху должна иметь форму ромба, в центре которого находится больше компетентных специалистов-практиков, а внизу - меньше новичков. Даже если эти кадры будут стоить дороже, уровень производительности инженеров компетентного уровня будет значительно выше, чем разница в оплате труда, и приведет к росту производительности2.
Пример анализа нехватки талантов в сфере цифровых и технологических технологий
Международная страховая компания
N Новичок
C Компетентный
Ресурсы для выпуска
Ресурсы для добавления
Текущее состояние
Будущие потребности
Разница
Категория
Глава
N
C
N
C
N
C
Программное обеспечение
Фронтальное проектирование
Интеграционный инжиниринг
502
410
514
2,056
-12
-1,646
Полнофункциональное проектирование
Инженерия QA
44
36
27
108
+17
-72
Архитектура
Архитектура
33
80
26
103
+7
-23
Инфраструктура
SRE
47
78
27
108
+20
-30
DevOps
12
19
27
108
-15
-89
Облачный инжиниринг
6
10
11
43
-5
-33
Инженеры по инфраструктуре
113
184
66
263
+47
-79
Данные и аналитика
Данные и аналитика
74
91
54
216
+20
-125
Безопасность
Безопасность
84
102
34
136
+50
-34
Дизайн
Дизайн опыта
4
7
9
34
-5
-27
Управление продуктами
Владелец продукта
96 179
69
275
+27
-96
Agile
Практик Agile
15 55
11
44
+4
+11
Другие
Руководитель программы
58 217
3
14
+55
+203
Руководители (например, вице-президент+)
0 198
0
64
0
+134
Роли, не относящиеся к подгруппе (например, администратор)
0 362
0
274
0
+88
Внутренние ЭПЗ
1,088 2,028
878
3,846
+210
-1,818
Всего внутренних Всего внешних Внутренние; внешние
3,116
4,826
39%; 61%
4,724
2,024
70%; 30%
-1,608
+2,802
Примечание: Основано на опросе о навыках технических специалистов по шкале от 1 (новичок) до 5 (эксперт), где под новичком подразумеваются участники, получившие от 1 до 2 баллов, а под экспертом - участники, получившие от 3 до 5 баллов.
ПРИЛОЖЕНИЕ 8.3
Теперь у вас есть все необходимые данные, чтобы преобразовать цифровую дорожную карту в план найма (см. Рисунок 8.4). По сути, это приказ для команды талантов, отвечающей за формирование вашей цифровой базы (подробнее об этой команде в следующей главе). При определении того, как выполнить план и восполнить нехватку кадров, вам неизбежно придется найти правильный баланс в поиске людей, нанимая, заключая контракты или повышая квалификацию существующих сотрудников (подробнее об этом в главах 10 и 11). Необходимо учитывать сроки создания цифровых решений, важность основных и неосновных талантов для бизнеса, а также затраты. Приоритеты неизбежно меняются по мере развития цифровой трансформации, поэтому важно регулярно согласовывать план найма с дорожной картой.
Оценка общей потребности в кадрах и составление плана найма
Международная сельскохозяйственная компания
ПОТРЕБНОСТЬ В ТАЛАНТАХ
ПЛАН ПРИЕМА НА РАБОТУ (нарастающим итогом)
Роль
Спрос
Поставка
Gap
Нанять
Q1
Контракт
Повторное убийство
Нанять
Q2
Контракт
Повторное убийство
Владелец продукта
20
2
18
5
5
0
8
0
10
Скрам-мастер
10
3
7
5
2
0
7
0
0
Агент перемен
5
Много
-
0
0
0
0
0
0
Ведущий дизайнер
3
0
3
1
0
0
2
0
0
Дизайнер UI/UX
17
0
17
3
7
0
6
7
0
Специалист по исследованию данных
6
1
5
2
0
0
3
0
2
Инженер по обработке данных
18
5
13
5
7
0
10
3
0
Инженер-программист
43
12
31
8
13
0
12
15
2
Инженер по машинному обучению
3
0
3
0
0
0
1
0
0
Технический лидер
8
2
6
2
2
0
5
1
0
Архитектор данных
2
0
2
0
1
0
1
0
0
Agile тренер
5
0
5
2
2
0
4
1
0
Бизнес-аналитик
15
Много
-
0
0
0
0
0
0
МСП
27
Много
-
0
0
0
0
0
0
Всего
182
NA
110
31
39
0
59
27
14
70 100
ПРИЛОЖЕНИЕ 8.4
Примечания
Доминик Бартон, Деннис Кэри и Рам Чаран, "Повестка дня для руководителя, ориентированного на таланты", McKinsey Quarterly, 6 марта 2018 г., https://www.mckinsey.com/capabilities/people- and-organizational-performance/our-insights/an-agenda-for-the-talent-first-ceo.
Питер Джейкобс, Клеменс Хьяртар, Эрик Ламарр и Ларс Винтер, "Пришло время перестроить модель ИТ-талантов", MIT Sloan Management Review, 5 марта 2020 г., https://sloanreview.mit.
.edu/article/its-time-to-reset-the-it-talent-model/.
Глава 9. Команда талантов
, которая может создать цифровую команду
Многие HR-организации сталкиваются с относительно медленными процессами найма и адаптации, жесткими рамками компенсации и устаревшими программами обучения и развития цифровых талантов. Это проблема, если вы хотите сформировать кадровый резерв и удержать высококлассных специалистов.
Однако преобразование всей вашей HR-организации и базовых HR-процессов, чтобы сделать их готовыми к цифровым технологиям, может занять несколько лет. Вместо этого мы пришли к выводу, что создание специальной команды, занимающейся адаптацией текущих HR-процессов с акцентом на цифровые таланты - это наиболее прагматичный и успешный путь вперед. При правильном подходе этот подход помогает организациям быстро продвигаться вперед, решая фундаментальные HR-задачи, характерные для цифровых талантов. Мы называем это специальное подразделение Talent Win Room (TWR) ("комната" может быть физической или виртуальной, но главное, чтобы это была специальная команда). Основная задача TWR - создавать и постоянно улучшать все аспекты опыта кандидатов и сотрудников.
TWR требует наличия спонсора на уровне руководителей высшего звена, как правило, CHRO и/или CDO, а также штатного старшего HR-менеджера, выполняющего функции руководителя группы. TWR - это междисциплинарная команда, которая повторяет рабочие привычки и поведение agile pod. В ее состав входят технологические рекрутеры и HR-специалисты, обладающие соответствующим опытом в следующих областях: планирование талантов; подбор и привлечение талантов; управление талантами; развитие талантов; многообразие, справедливость и инклюзивность. При необходимости команда дополняется функциональными специалистами, работающими неполный рабочий день (например, в области права, финансов, коммуникаций, маркетинга). На рис. 9.1 показан типичный состав TWR и примеры показателей, которые она определяет.
TWR должен работать так же, как и agile pods, фокусируясь на "клиенте" - в данном случае на кандидате или сотруднике - и быстро и итеративно разрабатывая и внедряя новые HR-процессы, ориентированные именно на них (глава 13 посвящена agile-методам работы). С точки зрения кандидата, гибкая HR-команда - это первый признак того, что организация идет по жизни, демонстрируя скорость, актуальность и гибкость.
Пример из практики: Как крупный сельскохозяйственный бизнес создал TWR
Крупная сельскохозяйственная компания решила перенести ключевые цифровые возможности и роли внутрь компании. Они создали TWR и научили команду ориентироваться на кандидатов, а также внедрили гибкие методы работы. TWR модернизировала поиск талантов, используя контрактный найм и активные цифровые каналы (например, TopCoder, GitHub, Stack Overflow), расширила возможности собеседования, включив в него упражнения по кодингу, и внедрила систему отслеживания кандидатов для управления сквозным процессом. В течение шести месяцев они успешно создали цифровую команду из 80 человек.
Команда талантов, которая может создать вашу цифровую команду 85
Типичные роли в комнате поиска талантов (TWR)
Выделенное время Команда цифровых талантовСтаршее руководствоВнешняя поддержка (временная)
X%
Владелец продукта Talent Win Room 100%
10-20%
Исполнительный спонсор
Определение стратегического направления и приоритетов для TWR Повседневный руководитель, контролирующий выполнение
По мере необходимости проводите презентации для согласования с более широкой организацией и определения стратегических целей
Скрам-мастер
100%
Эксперты
Варьируется
Поддерживать команду в рабочем состоянии, организовывать и концентрировать внимание
Обеспечение правильного выполнения agile-практик
Предоставление экспертных знаний в ключевых областях влияния (например, ключевые роли, которые необходимо нанять, дизайн-мышление для переосмысления опыта кандидатов и сотрудников).
Руководитель отдела по привлечению талантов
Разработайте убедительные ценности для сотрудников
100%
предложение, основанное на отраслевом бенчмаркинге и соответствующее ценностям компании
Карьерные пути и производительность
Расширение штата рекрутеров
100%
Руководитель управления
100%
Консультанты, разрабатывающие
Формирование стратегии управления эффективностью работы, разработка карьерных путей, а также обеспечение многообразия и инклюзивности
система подбора персонала, включая мероприятия по привлечению, оценке и трудоустройству
Временная поддержка при наборе персонала
Руководитель отдела обучения и развития 100%
Разработка стратегии L&D и внедрение в практику процессов обучения
Выборочные метрики
& KPI, используемые TWR
Установите цели L&D/развития талантов по ролям
Цифровой рекрутер(ы)
100%
Время нанимать
% конверсии на каждом этапе
Управление процессом найма и связанными с ним процессами
метрики
Продемонстрируйте опыт рекрутинга, ориентированного на кандидата
Специалист по компенсациям
20%
Обеспечение конкурентоспособной компенсации для талантливых сотрудников
Процесс подбора персонала Доходность источников Удовлетворенность сотрудников
Показатели и цели DEI Показатели эффективности работы сотрудников
ПРИЛОЖЕНИЕ 9.1
TWR - это не то, что можно раскрутить и запустить. Например, типичной компании из списка Fortune 500 требуется 200-2000 цифровых технологов, на создание которых может уйти от одного до трех лет. Достигнув этого уровня, вы будете продолжать нанимать сотрудников, чтобы восполнить естественную текучесть кадров (обычно 5-10 % в год). Кроме того, активизируются другие виды HR-деятельности (например, разработка карьерного роста, управление эффективностью, стратегии карьерного роста и компенсации). Потенциал TWR должен стать постоянным, хотя его направленность будет меняться со временем, чаще всего становясь основным структурным элементом для формирования и интеграции лучших практик в обновленную HR-функцию, работающую с дополнительными кадровыми резервами. По мере того как эта команда становится постоянной и постепенно расширяет свой мандат, мы часто видим, как организации создают несколько TWR для решения других приоритетных задач в области талантов в организации аналогичным образом.
Глава 10.
Нанимайте цифровых специалистов, когда они на самом деле проводят собеседование с вами
Чтобы найти и удержать хороших сотрудников - как внутренних, так и внешних, - вам нужно заглянуть в головы ваших цифровых талантов и узнать, чего они хотят. Это связано с тем, что лучшие таланты имеют высокую планку в отношении того, что они ищут от работодателя - по сути, они также рассматривают вас. Вы победите в игре по найму, предлагая то, что ценят цифровые таланты, и создавая опыт найма и адаптации, который ставит их в центр внимания.1
Актуальное, убедительное и аутентичное ценностное предложение для сотрудников
В мире, где лучшие таланты оценивают вас так же, как и вы их, компаниям необходимо разработать убедительное ценностное предложение для сотрудников (EVP), в котором будет отражено то, что мотивирует лучших талантов, и то, что для них важно.2
По их словам: Повышение квалификации технических специалистов
Существует ограниченное число суперумных инженеров, которые знают, что нужно создавать. Эти люди идут в компании, которые относятся к ним наиболее серьезно. Они идут в компании, где, по их мнению, руководство действительно понимает, чем они занимаются, и знает, как создать первоклассную культуру разработки технологий. Они идут туда, где, по их мнению, они получат достойное вознаграждение, а также где к ним будут относиться серьезно, прислушиваться к ним и уважать их. И они хотят быть там, где такие же люди, как они сами, образуют критическую массу.
Проблема, с которой сталкиваются крупные, классические компании из списка Fortune 500, - это та же проблема, что и 20 лет назад. Я думал, что со временем эта проблема уменьшится, но я не уверен, что она уменьшилась. Эта проблема заключается в том, что настоящие технологи в очень многих крупных компаниях не являются основными сотрудниками компании. К ним не относятся как к гражданам первого сорта.
Просто взгляните на оргсхему. Долгое время компании относили своих технологов к ИТ-отделу. ИТ-отдел был настолько знаменит своей обособленностью и изолированностью, что вокруг идеи "ботаников в подсобке" построены целые телешоу, например замечательная британская комедия The IT Crowd. Затем, около 20 лет назад, крупные компании поняли, что, возможно, все их технологи не должны находиться в ИТ-отделе. Поэтому они создали так называемое цифровое подразделение, которое обычно возглавляет вице-президент по цифровым технологиям. Хорошая новость заключается в том, что программисты управляют цифровым подразделением и воспринимаются там серьезно. Но это все еще подразделение. Это все еще подразделение. Это проблема.
Приведу пример: в компании Tesla инженеры, работающие над созданием самодвижущихся автомобилей, - самые важные люди в Tesla. Элон постоянно говорит о них, он постоянно общается с ними, и они, по сути, являются лидерами компании. Люди, работающие над этими вещами в традиционных автомобильных OEM-производители не являются таковыми. Может, и должны, но не делают. Они все еще находятся в этом своеобразном "закулисье". Люди, которые руководили бизнесом в течение 40 лет, - это те же люди, что и сейчас.
Такова схема. Tesla управляется технологом, который все это придумал и знает все аспекты работы самодвижущегося электромобиля. Крупными автомобильными компаниями управляют люди с более классическим бизнес-образованием, которые по своей сути не являются технологами.
Одним из важнейших факторов привлечения талантливых специалистов в области цифровых технологий является создание рабочей среды с возможностями для развития, где они смогут оттачивать свое мастерство, работая на современном технологическом стеке с умелыми коллегами (см. Рисунок 10.1). По сути, они хотят быть уверенными в том, что через три года их навыки останутся столь же ценными, если не более, чем сегодня. Это не единственный фактор, который имеет значение, но он неизменно является самым важным.
У большинства организаций есть EVP, но ее, скорее всего, необходимо обновить и перевести в форму изложения, которая подчеркивала бы более широкую цель, важность технологий для выполнения миссии компании, а также ее обязательства в области многообразия и инклюзивности в целом. Хорошая EVP содержит как материальные, так и нематериальные аспекты, которые демонстрируют, чего стоит компания и что делает ее уникальной (см. Рисунок 10.2).
Хотя элементы EVP могут быть вдохновляющими, они должны быть подлинными. Новобранцы и сотрудники могут почувствовать несоответствие между заявленной EVP и реальностью на местах. Когда это происходит, они уходят и рассказывают об этом другим. Это может быть губительно, потому что люди, ищущие работу, чаще всего читают отзывы о компаниях на сторонних сайтах (например, Glassdoor, Blind). Эти сайты предоставляют важнейшую информацию о том, как ваша EVP воспринимается хотя бы некоторыми сотрудниками. Компании должны следить за своей репутацией на этих платформах с той же тщательностью и скрупулезностью, с какой они следят за отраслевыми или финансовыми аналитиками.
Важнейшие факторы, влияющие на работу специалистов в области программного обеспечения
Процент талантливых специалистов в области программного обеспечения, которые включили этот фактор в число трех основных причин, по которым они устроились на работу, планируют остаться на работе, планируют уйти с работы или ушли
ВЗЯЛ РАБОТУ
ПЛАНИРУЙТЕ ОСТАНОВИТЬСЯ
ПЛАН
УХОДИТЬ
ЛЕВЫЙ
Возможность карьерного роста и продвижения по службе
43%
34
33
34
Компенсация и финансовые факторы
40
34
30
30
Гибкость рабочего места
29
30
27
23
Осмысленная работа
28
29
22
21
Поддержка здоровья и благополучия сотрудников
8
20
21
19
Источник: Исследование McKinsey Software Talent Great Attrition, Great Attraction Survey, 2022 (N = 1 532)
ПРИЛОЖЕНИЕ 10.1
Опыт подбора персонала, ориентированный на кандидата
Мы обнаружили, что организации добиваются наибольшего успеха в найме, когда переходят от оптимизации пошагового процесса найма к созданию восхитительного опыта для кандидатов.
Примеры EVP - общие и цифровые
ДЖОНСОН И ДЖОНСОН ФАРМАСЬЮТИКАЛЗ
OVERALL EVP: Работа в компании Johnson & Johnson - это не просто работа. Каждый день мы создаем судьбоносные методы лечения инфекционных заболеваний, улучшаем глобальную справедливость в области здравоохранения, разрабатываем инновационные медицинские технологии, фармацевтические препараты и потребительские товары для здоровья, которые повышают качество жизни людей во всем мире. От 3D-печати и робототехники, преобразующих хирургические операции, до беспилотников, доставляющих вакцины в отдаленные регионы, - наша работа больше, чем каждый из нас.
DIGITAL EVP: Представьте себе, что вы наделяете искусственный интеллект накопленными человечеством медицинскими знаниями, создаете приложения для обработки естественного языка, чтобы сделать хирургию более безопасной, или используете машинное обучение, чтобы изменить методы диагностики редких заболеваний. Наука о данных не только делает возможными подобные прорывы, но и ускоряет наше воздействие - например, благодаря ей команды Janssen R&D сокращают сроки клинических испытаний. Являясь крупнейшей в мире компанией в сфере здравоохранения, мы используем наши обширные массивы данных для решения крупнейших проблем здравоохранения нашего времени - от ВИЧ до рака мочевого пузыря, волчанки и COVID-19.
ФРИПОРТ-МКМОРАН
ОБЩАЯ ЦЕЛЬ: Наша опытная и разносторонняя команда находит, добывает, перерабатывает и поставляет сырье, которое соединяет мир.
Медь. Молибден. Золото. Элементы, которые мы поставляем, играют решающую роль в создании технологий, которые движут будущим.
Мы считаем, что наша главная сила - это наши люди. Мы уважаем и ценим различные идеи, убеждения, опыт, таланты, навыки, взгляды, происхождение и культуру наших сотрудников. Мы стремимся к созданию, продвижению и развитию рабочего места, где каждый чувствует свою принадлежность, где к нему относятся с уважением и ценят его мнение.
DIGITAL EVP: В компании Freeport мы понимаем, что наши данные не реализуют свой потенциал в полной мере, пока они не будут проанализированы, а выводы эффективно доведены до сведения предприятия. Вы будете работать в тесном сотрудничестве с горнодобывающими предприятиями, профильными экспертами, учеными, изучающими данные, и инженерами-программистами над созданием передовых, высокоавтоматизированных продуктов данных. Вы будете сторонником DataOps, DevOps и agile-практик; будете руководить проектными группами и наставлять членов команды, чтобы они могли полностью реализовать свой потенциал.
Источник: Карьерные сайты компаний Johnson & Johnson и Freeport-McMoran
ПРИЛОЖЕНИЕ 10.2
На рис. 10.3 показан типичный для компаний процесс подбора персонала и множество проблем, которые его затрудняют. Обратите внимание, например, на то, сколько времени может занять процесс. Трудно конкурировать за таланты в сфере цифровых технологий, если срок от предварительного отбора до предложения превышает четыре недели. Если процесс занимает слишком много времени, кандидаты чувствуют, что имеют дело с медленно развивающейся компанией.
Текущее состояние рекрутинга Компания, предоставляющая финансовые услуги
ФАЗА ИССЛЕДОВАНИЯ / ПОИСКА (3-4 недели) СКРИНИНГ (1 неделя)
Шаг Шаг Шаг Шаг Шаг Шаг
1
2
3
4
5
: Создать заявку
: Заявка утверждена финансовым отделом/отделом кадров
: Команда по привлечению талантов передает заявку рекрутеру
: Опубликовать вакансию
: Цифровое приложение
: Оцените применение
: Запланируйте звонок для проверки
1
2
3
: Проведите отборочный звонок
Шаги
Точки соприкосновения
1 2 3
Система рекрутинга
4
LinkedIn и т.д.
5
Портал приложений
1
Электронная почта
2
Электронная почта, телефонный звонок
3
Видеоконф.
Кандидат
Мотивированный
Заполнение заявки заняло целую вечность
Взволнованный/
любопытный/ OK
Разочарованный график задерживается
OK
Скрининг-звонок
Опыт Действия, мысли,
чувствовать себя на высоте
моменты
Начинает искать новую должность или открыт для новых возможностей
неуверенно Читает вакансии
Подаёт заявку на должность
С нетерпением ждем ответа
Расстроенный вид в другом месте
Расстроенный отзывает заявку
Опыт работы рекрутером
Беспокойный
Не знает, что будет следующим в очереди,
не имеет
набор кандидатов
Не могу определить приоритетность своей роли
В поисках единорогов
Перегруженный
Новая заявка без предупреждения
Напряженное начало поиска поставщиков
Надеясь, ожидая
приложения
Основная информация о напряженных экранах
Стопка резюме кандидатов для просмотра
Стресс ожидает расписания
Расстроенные задержки: Кандидат потерян
Hopeful проводит отборочный конкурс
Опыт работы менеджером по найму
Стресс Пишет JD; процесс медленный и утомительный
Огорчает ожидание в процессе утверждения заявки
Стресс Встречи с рекрутером
обсудить
что требуется от работы
Надеющиеся посты в своем LinkedIn, чтобы увеличить воздействие на
его собственный
сеть
Разочарованный получает шифер от рекрутера
Разочарование Иногда не видно, что происходит.
ПРИЛОЖЕНИЕ 10.3
ИНТЕРВЬЮ (~2-4 недели) ПРЕДЛОЖЕНИЕ (~1-2 недели)
: Расписание собеседований
: Проведение 1-го раунда собеседований
: Проведите второй раунд собеседований
: Решение после собеседования
: Отправить устное предложение
: Обсудите устное предложение
: Окончательное утверждение предложения
: Официальное предложение
: Переговоры / подписание
1 2 3 4 1 2 3 4 5
Электронная почта
Видеоконференция Внутренняя
встречи
Телефонный звонок
Электронные письма, телефонный звонок
Общее вознаграждение
Электронная почта
Электронная почта, PDF
ПЕРЕД ВВОДОМ В ЭКСПЛУАТАЦИЮ
Множество изменений в расписании
Разочарованный
Интервью с надеждой на HM
Интервью с надеждой на HM
Совпадающие вопросы для собеседования
Разочарованный
Воодушевленный получает предложение
Напряженные
Переговоры
Ждать и ждать
Беспокойный
Ждет
Хэппи получает официальное предложение
Волнующие знаки окончательного предложения
Напряженные
В
Планирование занимает много времени
Расстроенный находит, что должность не подходит
Ждет ответа
Расстроенный
Отклонено
условия
предложение
период молчания
OK
Ожидает составления расписания
Потеря кандидатов из-за переноса сроков
Надеюсь, что собеседование пройдет успешно
Расстроенный кандидат на проигрыш
Возбужденный
Использует собственное интервью
Разочарован Слышал, что нужно больше кандидатов
Возбужденный
Найденный кандидат
Стресс Старается сохранить кандидата "теплым".
Как кандидат зашел так далеко?
Волнение Устное предложение сделано
Усталость Переговоры
Провал переговоров
Облегчение Письменное предложение введено в систему
Тревожное письмо с предложением
Воодушевленный Получил подписанное предложение
Возбужденный
Получает
Разочарованный
...если кандидат выбывает.
Стресс Готовится к собеседованиям, собирает группу
структура
Отсутствие стандартного руководства по проведению интервью и оценки
Разочарованный
Передано
Stressed Decides предлагается с панелью, других рекомендаций нет
Надежда
Говорит рекрутеру, что нужно сделать предложение
В состоянии стресса Работает с рекрутером, чтобы договориться об условиях
Облегчение
Получает уведомление о том, что предложение одобрено
подписано
предложение от отдела кадров
Разочарованный
...если кандидат выбывает.
не говоря уже о том, что в это время у них есть конкурирующие предложения, которые выбивают их из колеи. Помните, что то, с чем сталкиваются кандидаты в процессе рекрутинга, задает планку того, каково это - работать в вашей организации.
Мы видели, как организации добивались успеха в поиске и удержании талантов, когда переосмысливали свой подход к подбору персонала. Лучшие из них сосредотачиваются на создании опыта, ориентированного на кандидата, с акцентом на то, как сделать моменты, которые имеют значение, по-настоящему запоминающимися (см. Рисунок 10.4). Важно, чтобы опыт был продуман до мелочей и соответствовал ожиданиям кандидатов и отрасли. На рисунке 10.4 обратите внимание на особые моменты, которые дают кандидату понять, что это место, где его ценят.
Отличный опыт подбора персонала - это прекрасно, но толку от него мало, если вы не можете найти подходящих кандидатов. Хотя изменения в экономике, конечно, влияют на доступность талантов, поиск лучших специалистов, отвечающих специфическим потребностям вашего бизнеса, всегда будет сложной задачей.
Прежде всего, это означает, что вам нужны рекрутеры-технари, которые имеют опыт работы и могут говорить на языке кандидатов. Во-вторых, эти рекрутеры должны оперативно определять, где искать кандидатов, и взаимодействовать с различными платформами и сервисами, ориентированными на технологические таланты. Предприимчивые рекрутеры, например, переключают свое внимание с традиционных каналов, таких как общие доски объявлений о вакансиях, на репозитории исходного кода, где инженеры с гордостью размещают свои работы. Они ориентируются на такие сообщества, как GitHub и Reddit - места, где технологические таланты собираются по причинам, не связанным с поиском работы.
Некоторые компании проводят онлайн-конкурсы, позволяющие организациям и потенциальным кандидатам продемонстрировать свои технические навыки в партнерстве с цифровыми платформами, такими как популярные в настоящее время Topcoder и HireIQ. Платформы для поиска цифровых талантов, такие как Good&Co и Hacker- Rank, также помогают компаниям более эффективно оценивать соответствие потенциального сотрудника требованиям к навыкам и культуре компании. Для работы в этих направлениях требуются цифровые рекрутеры, хорошо разбирающиеся в технологическом рекрутинге.
Путешествие рекрутера в будущее Компания, предоставляющая финансовые услуги
ФАЗА ИССЛЕДОВАНИЯ / ПОИСКА (1-2 недели) СКРИНИНГ (2 дня)
Шаг Шаг Шаг Шаг Шаг
: Создание и планирование бренда
: Создание описания работы
1
2
3
4
: Размещение вакансий
: Цифровое приложение
: Оцените применение
: Запланируйте звонок для проверки
1
2
3
: Проведите отборочный звонок
Шаги
Точки соприкосновения
1
LinkedIn и т.д.
2
Система рекрутинга
3
LinkedIn и т.д.
4
Портал приложений
1
Рекрутинговый портал
2
Автоматическое/самостоятельное составление расписания
3
Видеоконференция
Привлечение талантливых специалистов в области технологий, отбор с помощью технологий для легкого старта
Прозрачный процесс и легкое планирование скрининга
Опыт работы с кандидатами
Действия, мысли, чувства в ключевые моменты
Поиск бренда, который привлекает кандидата
Заинтересованная часовая компания в новых вакансиях
Любопытный обнаруживает подходящую позицию
Возбужденный
Получает
предварительный отбор с помощью чатбота
Расслабленный Получает четкий обзор
процесс
Звонок от рекрутера компании Excited Schedules
Уважаемый Принимает скрининговый вызов
подключиться
Использует резерв кандидатов и репутацию фирмы, тесно сотрудничает с HM.
Проверка с помощью технологий ускоряет процесс
Рекрутер говорит на "техническом" языке
Опыт работы рекрутером
Подготовлено
Доступ к кандидату
Уверенный
Участие в собеседовании с HM
Уверенный
Формы планируют источник
Информированный
Мониторинг показателей
Ориентированный
Фокусируется на искусственном интеллекте
Подготовлено
Проходит обследование
Подключено
Оценивает кандидатов
Начиная с
бассейн
обучение
для
Предварительная проверка с помощью технологий
по расписанию
на скрининге
существующий список наблюдения
заявка
предварительный отбор кандидатов
кандидаты
автоматически
звоните
Создание JD на основе шаблонов, поддержка рекрутера при поиске и отборе кандидатов.
Видимость на общем портале обеспечивает информированность и вовлеченность ОМ.
Опыт работы менеджером по найму
Подготовлено
Планирует заранее и действует быстро
Подготовленный Остается активным самостоятельно
профессионал
сеть
Возбужденный
Использование надежных шаблонов JD с минимальными изменениями
Hopeful Предоставляет дополнительные
грохочение
руководство
Информированность Обеспечивает видимость скрининга
на цифровом
приборная панель
Регулярное обновление информации о состоянии воронки
ПРИЛОЖЕНИЕ 10.4
ИНТЕРВЬЮ (1 неделя) ПРЕДЛОЖЕНИЕ (1 день)
: Расписание собеседований
1
2
3
4
: Проведение 1-го раунда собеседований
: Проведите второй раунд собеседований
: Решение после собеседования
: Продлить устное предложение
: Обсудите устное предложение
1
2
3
4
: Окончательное утверждение предложения
: Официальное предложение / подписание
1 2 3 4 1 2 3 4
Электронная почта
Автоматическое/самостоятельное составление расписания
Видеоконференция
Внутренние совещания
Телефонный звонок
Электронная почта, телефонный звонок
Общее вознаграждение
ПЕРЕД ВВОДОМ В ЭКСПЛУАТАЦИЮ
Упорядоченный процесс с тщательно скоординированными собеседованиями
Быстрый процесс предложения и непрерывное выращивание
Контроль Планирует собеседование по телефону
Возбужденный
Интервью с несколькими интервьюерами
Надежда ждет решения
Воодушевленный Получил устное решение
Успокаивается Рассматривает и задает вопросы
Тревога, но облегчение Ждет окончательного предложения
Счастливчик получает окончательное предложение
Предварительный отбор
Воодушевленный Становится членом сообщества
до
приложение
Решение в тот же день
Предложения на следующий день
технология
предпочтения; доступ к инструментам и программному обеспечению
запустить
Общение на цифровом портале для наглядности и поддержки, отслеживание показателей на протяжении всего времени
Быстрый процесс предложения и непрерывное выращивание
Информированный
Поддерживает постоянную связь
Информирование Отслеживание прогресса, обратная связь
Воодушевленный Продлевает устное решение
Информирован, наделен полномочиями Общается на цифровом портале с разными сторонами
"Кандидат звонил, чтобы поблагодарить меня!"
Информированные, наделенные правами и возможностями Семена в ходе деятельности после предложения
Хорошо спланированный и задокументированный процесс собеседования, чтобы не запутаться.
Оставайтесь на связи во время предложения и после него, используя автоматические подсказки и личные прикосновения для поддержания вовлеченности кандидатов
Надежда готовится к интервью
Воодушевленный Проводит собеседования с четким процессом и активами
Надежда на каллибровку и решение
встреча
Взволнованный протягивает руку помощи после словесного решения
Надежда
Оставайтесь рядом во время шагов предложения
Воодушевленный обращается к кандидатам
Excited продолжает культивировать, приветствовать
новые члены команды
Процесс собеседования заслуживает особого внимания. Во многих случаях должностные инструкции расплывчаты, собеседования проводятся в плохой последовательности, интервьюеры не знают, на что обращать внимание, а сам процесс занимает слишком много времени - от 60 до 90 дней. Самым распространенным подводным камнем является попытка проверить истинную компетентность кодера. Упражнения по кодированию - важная часть процесса, и для их успешного проведения требуется серьезное планирование. Аналогично, интервьюеры должны приходить подготовленными, быть вовлеченными и относиться к интервью как к привилегии, а не просто к очередной встрече в календаре.
В процессе найма некоторые организации отдают предпочтение якорным сотрудникам и старшим руководителям в определенной технической дисциплине. Эти люди могут помочь привлечь других исключительных талантов благодаря своим личным связям и репутации в отрасли. Одна ведущая североамериканская промышленная компания, намеревавшаяся приступить к цифровым преобразованиям, отдала приоритет привлечению главного директора по цифровым технологиям (CDO), который пользовался авторитетом среди технологов, и в свою очередь смогла привлечь трех ведущих владельцев продуктов и дизайнеров из аналогичных организаций. Затем компания направила свои усилия по привлечению сотрудников на работу в крупные технологические компании и известные дизайнерские агентства. Используя этот подход, организация создала свою команду по разработке продуктов и дизайну с нуля до 30 человек примерно за шесть месяцев.
Однако поиск кандидатов может занять много времени, поэтому важно параллельно заниматься наймом основного персонала.
Поиск талантов внутри компании
По нашему опыту, многим компаниям приходится привлекать большую часть талантов извне, чтобы получить новые возможности, которые им необходимы. Однако внутренние трансферы имеют ряд преимуществ: их почти всегда легче, дешевле и быстрее найти, чем любой другой способ; они также обладают внутренней сетью и институциональными знаниями.
Оценивая внутренних кандидатов, остерегайтесь двух распространенных ошибок: переработки проблем с производительностью и переквалификации недостаточно квалифицированных кандидатов.
Установите квалификационные критерии и процесс отбора, чтобы убедиться, что сотрудники соответствуют требованиям. Знайте, как выглядит хороший сотрудник, и будьте готовы подождать, пока он подойдет.
Лучшая практика - проводить собеседование с внутренними переводчиками так же, как вы проводите собеседование с новыми сотрудниками, с четким описанием роли и ожиданий, включая установление планки мастерства для любой роли.
В процессе цифровой трансформации и трансформации с использованием искусственного интеллекта одна из ролей, которую почти всегда необходимо заполнить изнутри, - это владелец продукта (или менеджер продукта), поскольку их эффективность частично зависит от понимания бизнеса и организации. Хорошие владельцы продуктов являются основополагающими для успеха цифровой трансформации - больше, чем любая другая роль. Особенно важно проверить их способности и опыт управления продуктами и запланировать серьезную программу повышения квалификации для тех, кто не справляется с этой задачей (подробнее об управлении продуктами см. в главе 15).
Процесс адаптации новых сотрудников
В период между принятием кандидатом предложения и началом работы в день 1, как правило, происходит разрыв между рекрутером и нанимателем. Слишком часто новые сотрудники проводят первые несколько недель в ожидании доступа к нужным системам или хранилищам кода, а также распределения работы с новой командой. Это происходит потому, что подготовка новых сотрудников - процесс, которым занимаются многие подразделения организации.
Большинство компаний знакомят новых сотрудников с их ролью, обязанностями и ожиданиями от них. Представьте им план адаптации с четкими целями и объясните процесс управления эффективностью во время ориентации. Компании могут пойти дальше и предоставить обзор цифровых планов компании, а также рассказать о том, какой вклад будет вносить новый сотрудник. Контекст имеет значение. Мы часто говорим, что бизнесменам нужно изучать технологии, но верно и обратное. Технологи наиболее продуктивны, когда они понимают контекст бизнеса, поэтому обязательно включите это в план подготовки к работе.
Лучшие компании назначают контактное лицо, которое помогает новому сотруднику сориентироваться в компании. В идеале этот человек - коллега, который будет работать с новым сотрудником на его первом задании. Цифровые таланты хотят и ожидают немедленного вклада в работу, поэтому будьте готовы сразу направить их в реальный проект на первой неделе.
Аналогичным образом обратите внимание на технологические инструменты, предоставляемые новым сотрудникам. Дизайнеры могут рассчитывать на работу на Mac и использование определенных инструментов, обеспечивающих им наибольшую производительность, например Sketch, InVi- sion или Balsamiq. Многие организации позволяют будущим сотрудникам выбрать устройство при заполнении документов при приеме на работу. Разработчики должны иметь доступ к репозиториям кода в кратчайшие сроки, чтобы быстро приступить к работе. Специалисты по изучению данных будут ожидать доступа к Python. Рабочий стол" разработчика должен быть автоматизирован и понятен настолько, чтобы новые разработчики могли коммитить код уже к концу первой недели работы.
Разнообразие, равенство и инклюзивность
Наши исследования показывают, что компании, лидирующие в области многообразия, равноправия и инклюзивности (DEI), на 36 % чаще превосходят своих конкурентов по показателю рентабельности EBIT, на 27 % чаще создают долгосрочную стоимость и на 25 % чаще имеют рентабельность выше средней. Под разнообразием важно понимать широкий взгляд, включающий пол, этническую принадлежность, опыт и нейроразнообразие.3
Ведущие университеты быстро диверсифицировали свои курсы по информатике, науке о данных и другим STEM-технологиям, расширив тем самым круг талантливых специалистов, доступных работодателям. Помимо помощи компаниям в укреплении кадрового состава, такое развитие событий также открывает работодателям путь к достижению более широких целей в области разнообразия, что, в свою очередь, может сделать их более привлекательными для лучших талантов, которые все чаще рассматривают DEI в качестве основного фактора отбора.
Мы наблюдали успех, когда компании убеждались, что факторы DEI являются основными элементами EVP, например, рассказывая о механизмах поддержки DEI, которые есть в компании. DEI также должен быть отражен в процессе собеседования с кандидатами путем разработки инклюзивных описаний должностей, проведения тренингов по DEI, чтобы помочь сотрудникам избежать подсознательных предубеждений, и привлечения разнообразных людей для проведения собеседований. Подумайте о том, чтобы добавить амбиции DEI в панель цифровых преобразований. Наконец, DEI должна быть частью процессов оценки и планирования преемственности.
Примечания
Свен Блюмберг, Ранья Реда Куба, Суман Тареджа и Анна Визингер, "Тектоника технологических талантов: Десять новых реалий для поиска, удержания и развития талантов", McKinsey.com, 14 апреля 2022 г., https:// www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ tech-talent-tectonics-ten-new-realities-for-finding-keeping-and- developing-talent.
Винсент Берубе Сирил Дюжарден, Грег Кудар, Эрик Ламарр, Лаоп Мори, Жерар Рихтер, Тамим Салех, Алекс Сингла, Суман Тареджа и Родни Земмель, "Цифровые преобразования: Пять факторов таланта, которые имеют наибольшее значение", McKinsey.com, 5 января 2023 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/digital-transformations- the-five-talent-factors-that-matter-most.
Кэтрин Кун, Эрик Ламарр, Крис Перкинс и Суман Тареджа, "Добыча золота для технических талантов: Семь способов найти и сохранить разнообразные таланты", McKinsey.com, 27 сентября 2022 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/mining-for-tech-talent-gold- seven-ways-to-find-and-keep-diverse-talent.
Глава 11.
Распознавать отличительные технологи
Нереально ожидать, что устоявшаяся компания полностью изменит свой подход к управлению талантами, чтобы приспособить его к цифровым талантам. Однако большинство компаний считают, что они могут работать в рамках существующей системы управления талантами, чтобы учитывать специфику цифровых талантов. Две области, которые имеют наибольшее значение, - это компенсация и управление эффективностью.
Корректируйте вознаграждение с учетом навыков
Вознаграждение за технические навыки часто резко расходится с ценностью человека, потому что в традиционных компаниях вознаграждение часто привязано к стажу работы или количеству сотрудников в подчинении, а не к инженерным способностям. Это приводит к неудовлетворенности и дает высококлассным специалистам вескую причину для ухода.
В современных компаниях приветствуются технические карьеры, когда человек может оказывать огромное влияние на работу компании благодаря своему ремеслу. Это привело к появлению двойных карьерных путей, где технологи могут развиваться либо в традиционном управленческом направлении, либо в экспертном или инженерном (подробнее об этом в главе 12).
Размышляя над тем, как скорректировать систему вознаграждения для талантливых специалистов в области цифровых технологий, помните о следующем:
Компенсация сопоставляется с Большим технологическим институтом. Big Tech устанавливает планку, а большинство других компаний решают, к чему привязать свою компенсацию, в зависимости от местного рынка и качества талантов, за которые они конкурируют. Это еще более актуально в гибридном/удаленном мире, где талантливые сотрудники могут работать где угодно, и их всегда можно переманить или легче сменить работу. Планка компенсаций в Big Tech, конечно, будет меняться в зависимости от экономических подъемов и спадов в технологической отрасли, но, тем не менее, она, скорее всего, останется стандартом. В целом, большинство компаний согласятся на уровень компенсации, который будет на 30 % ниже уровня Big Tech, в зависимости от рынка и качества талантов.
В целом, структура вознаграждения ориентирована на более существенные бонусы, что обеспечивает механизм премиального вознаграждения для действительно выдающихся технических специалистов. Бонусы могут достигать 100 % от базового оклада для лучших сотрудников.
Платите за квалификацию на конкретном уровне. Инженеры MLOps в среднем зарабатывают больше, чем инженеры по обработке данных, потому что эти навыки дефицитны и пользуются большим спросом. Внутри каждого семейства навыков должна быть гранулярная сегментация уровней, определяемая квалификационными характеристиками. Например, в Big Tech будет до 10 уровней инженеров по обработке данных, каждый из которых будет иметь свои диапазоны вознаграждения. Чтобы определить эти маркеры навыков, можно воспользоваться бенчмарками, которые помогут понять, как обстоят дела на рынке талантливых специалистов, которых вы ищете, и предоставят данные, позволяющие убедиться в том, что вы конкурентоспособны по требуемым навыкам.
Затем вам придется потрудиться, чтобы выяснить, какие маркеры лучше всего подходят для нужных вам навыков. Это означает установление четких маркеров технологической компетентности (TCM) и лидерской компетентности (LCM) для различных семейств должностей (подробнее см. ниже). Поначалу это нелегко, и потребуется время, чтобы сделать все правильно. На рис. 11.1 показаны TCM для специалиста по исследованию данных и старшего главного специалиста по исследованию данных в McKinsey.
Немонетарные аспекты имеют значение. Возьмем, к примеру, названия должностей. Талантливые специалисты в области цифровых технологий хотят получить внешнее признание коллег. На вершине технической "пищевой цепочки" находится выдающийся инженер, тот, кто решил сложнейшие технические задачи компании и имеет широкую поддержку внутри и вне ее. Это звание что-то значит. То же самое можно сказать и о других титулах, связанных с цифровыми талантами, - признание на рынке имеет большое значение. Еще один важный неденежный аспект - кто будет их начальником, старшим сотрудником, который, по сути, будет помогать им развивать свое мастерство. Они захотят узнать, действительно ли этот человек способен стать их наставником. Если в компании нет сильных технических специалистов, у вас могут возникнуть проблемы с подбором персонала, даже если компенсация будет конкурентоспособной.
Другие неденежные поощрения - в том числе специальные задания, качество среды развития, возможность выступить с докладом перед внешним миром или посетить специальные мероприятия, высокое признание на рабочем месте, время для работы на общественных началах, эргономичная домашняя обстановка, доступ к инструментам для работы с сознанием и т. д. - также могут оказать убеждающее воздействие. Хотя вы, возможно, и не захотите соответствовать льготам и привилегиям крупных технологических компаний, вам следует вдумчиво подойти к вопросу о том.
Карьерный рост для специалиста по исследованию данных
Пример фирмы, оказывающей профессиональные услуги
Младший сержантский состав
Специалист по изучению данных
Старший сержант
Ведущий сержант
Директор ДС
Старший директор DS
Партнер
ИССЛЕДОВАНИЕ ДАННЫХ
Выполняет базовую оценку качества данных Выполняет базовый исследовательский анализ
Выявляет проблемы, связанные с недостаточностью данных, качеством данных или их смещением, и разрабатывает решения для их устранения
Продолжает разрабатывать новые технологии для получения новых данных
ОПРЕДЕЛЕНИЕ АНАЛИТИЧЕСКОГО ПОДХОДА
Имеет растущее понимание преимуществ и недостатков различных методологий, языков и активов
Понимает долгосрочные цели цифровой трансформации; как текущая работа вписывается в общую техническую дорожную карту
Сотрудничает с ведущими специалистами бизнес-сферы для разработки амбициозного видения на ближайшие 1-3 года и руководит техническим мышлением при определении и разработке технических дорожных карт.
Помогает выявить пробелы в технических навыках Объединяет последние достижения в литературе, чтобы
преодоление проблем, которые не могут решить готовые библиотеки DS/ML
РАЗРАБОТКА ФУНКЦИЙ
Может уверенно конструировать/кодировать функции, определенные самостоятельно или другими людьми, работая в сотрудничестве с коллегами по проектированию данных
Проверяет как бизнес-сферу, так и функциональные особенности прогнозных моделей, а также ключевые характеристики, определяющие ограничения оптимизации
ПРИМЕНЕНИЕ МЕТОДОВ АНАЛИТИКИ/
МЕТОДОЛОГИИ
Выполняет аналитические задачи с минимальным руководством
Хорошо разбирается в ряде ведущих методологий и может применить их надлежащим образом при ограниченном руководстве
Выявляет возможности для использования новых и инновационных методологий и становится их первопроходцем
Держит планку технической обоснованности подходов и отстаивает ее даже в условиях дефицита времени/ресурсов
Способны быстро осваивать новые методики и применять их под руководством
Участвует в НИОКР и внешнем сотрудничестве с целью выявления тенденций и возможностей
Начинает знакомиться с внутренними активами (например, Kedro).
ВЫВОД И ВИЗУАЛИЗАЦИЯ
Генерирует графики/выводы, оптимально отображающие соответствующие данные для решения проблем, с указаниями по выбору/оформлению вывода
Формирует сообщения, связанные с DS, для высшего руководства, переводя сложные технические материалы в убедительные, четкие и контекстуальные сообщения.
Устанавливает доверительные отношения с высшими руководителями бизнеса и технологий благодаря широте знаний и стратегическому мышлению
ИНЖИНИРИНГ
Пишет хороший, точный производственный код при ограниченном руководстве
Растет знакомство с библиотеками и активами
Следование передовому опыту разработки программного обеспечения и MLOps, а также руководство
Проактивно выявляет возможности для развития новых технологических активов и играет ведущую роль в их разработке
Знает и обеспечивает внедрение всех последних значительных достижений в области технологий и инструментария DS/ML
Является ответственным экспертом в нескольких подразделениях по передовым методам кодирования
СТАНДАРТЫ
ПРИЛОЖЕНИЕ 11.1
Управляйте перетоком данных в ИТ. Некоторые сотрудники вашей традиционной ИТ-организации скажут: "Я специалист по изучению данных. Почему мне не могут платить столько же, сколько ученым, только что нанятым для работы над цифровыми решениями?" Конечно, им следует платить столько же, но только если они соответствуют требованиям к технологиям и лидерским качествам. Убедитесь в том, что вы четко обозначили эти показатели, а для тех сотрудников вашего ИТ-подразделения, которые им соответствуют, обеспечьте их задействование в дорогостоящих работах. Если вы не справитесь с этой задачей, сравнение компенсаций станет неприемлемым и приведет к уходу сотрудников.
По нашему опыту, многие состоявшиеся компании обладают достаточной гибкостью в модели вознаграждения, чтобы привлекать и удерживать талантливых специалистов в области цифровых технологий. Главное - использовать четкие маркеры навыков, внешние ориентиры и продуманные неденежные стимулы.
Использование маркеров технологических компетенций в управлении эффективностью работы
Управление эффективностью работы в условиях динамичного и цифрового рабочего места происходит динамично. Хотя успешные цифровые компании часто проводят ежегодные письменные оценки, многие из них используют более частые, неформальные оценки. Согласно лучшим практикам, руководители должны часто обсуждать с сотрудниками вопросы развития. При таком подходе сотрудники устанавливают собственные цели вместе с коллегами и руководителем. Часто проводятся неформальные встречи, посвященные профессиональному развитию и, при необходимости, корректировке курса.
Важно, кто проводит оценку и откуда поступает обратная связь. Талантливые цифровые специалисты ожидают, что их работу будет оценивать тот, кто владеет своим ремеслом (или, по крайней мере, лучше их). Многие организации адаптировали ту или иную версию модели "глав", когда люди с похожими ролями и навыками слабо организованы в сообщество. Лидеры этих групп берут на себя множество обязанностей, включая подбор персонала, управление эффективностью работы, подбор кадров, развитие навыков и многое другое.
Роль руководителя очень важна, и ее часто упускают из виду во время цифровых преобразований и преобразований с использованием искусственного интеллекта. Руководители должны часто проходить обучение, особенно по вопросам постановки целей и бесед один на один с непосредственными подчиненными для обсуждения целей работы на год вперед. При проведении более формальных аттестаций следует учитывать отзывы из разных источников ("обратная связь 360°"). Менеджеры будут запрашивать отзывы у защитников и коллег сотрудника, оценивать его работу с помощью комиссии по оценке, а затем делиться отзывами с сотрудником.
Для эффективного управления эффективностью работы требуется модель компетенций, включающая технические навыки и области знаний, ожидаемые в рамках различных семейств должностей (включая маркеры навыков, как обсуждалось в предыдущем разделе). Эта базовая модель важна для того, чтобы процесс управления эффективностью оставался справедливым и прозрачным. Технологические таланты хотят знать маркеры успеха на каждом уровне. Например, каковы ожидания от навыков младшего специалиста по обработке данных, чтобы стать старшим специалистом по обработке данных? Такое выравнивание компетенций становится центром процесса управления эффективностью, независимо от того, как часто вы формально проводите этот процесс.
Лучшие модели компетенций определяют технические и нетехнические навыки и знания, необходимые для успешного выполнения работы, в терминах измеряемых и наблюдаемых характеристик и поведения. Нетехнические компетенции часто привязаны к ценностям компании. Кроме того, в них компетенции и уровни владения ими привязаны к конкретным ролям и группам, что позволяет определить ролевые требования и принять решения о планировании карьеры, продвижении по службе и найме.
В этой области продолжается множество экспериментов. Например, некоторые организации переходят к формальным обзорам ежегодно и неформальным в течение года, отделяют обзоры от про-движений, сохраняют годовые циклы повышения компенсаций или переводят обратную связь в цифровой формат. Успешные работодатели постоянно следят за развитием событий и готовы тестировать их и изучать, что работает.
Глава 12. Укрепление мастерства
Таланты в сфере цифровых технологий прекрасно понимают, что их ценность тесно связана с их навыками. По этой причине они особенно внимательно следят за тем, насколько хорошо они могут развивать свои навыки в процессе работы. Вы можете подумать: разве это не справедливо для всех профессий? Да, но это особенно актуально для талантов в сфере цифровых технологий, потому что мир технологий развивается гораздо быстрее. Компаниям, которые не могут выполнить это требование по развитию навыков, не стоит рассчитывать на то, что их лучшие сотрудники останутся надолго. Есть два аспекта развития талантов, в которых компании могут поддержать это стремление: гибкие карьерные программы, позволяющие развивать великих технологов, и обучение с учетом их потребностей.
Гибкие карьерные возможности
В то время как некоторые коллеги-цифровики хотят перейти на руководящие должности, более двух третей разработчиков не хотят становиться менеджерами. Вместо этого они предпочитают оттачивать свое мастерство и решать все более сложные цифровые задачи.
По этой причине в цифровых организациях часто встречаются карьеры как менеджеров, так и экспертов (см. Рисунок 12.1). Двойная траектория также снимает общее давление при продвижении по службе, включая наличие технических траекторий, которые менее конкурентоспособны, чем управленческие, и решает некоторые проблемы с компенсацией, позволяя тем, кто находится на вершине экспертной траектории, иметь уровень оплаты, сопоставимый с уровнем оплаты старших руководителей, как обсуждалось в предыдущей главе.
Для создания карьерной лестницы с двумя направлениями необходимо разработать комплексную архитектуру должностей, организованную по семействам профессий, таким как наука о данных или инженерия данных. Экспертный путь выигрывает от разработки сильной модели компетенций с четкими ожиданиями по продвижению на каждом уровне. Обратите внимание, что, хотя наличие большего количества уровней в архитектуре должностей обеспечивает людям более быстрое продвижение и ощущение прогресса, управлять ими сложнее.
Индивидуальные учебные маршруты
В общем и целом, есть два элемента в создании процесса обучения и развития (L&D) для цифровых талантов: первый - это разработка специального обучения для цифровых талантов, о котором мы поговорим ниже. Другой - создание институционального потенциала для поддержки широкомасштабных корпоративных тренингов, о которых мы рассказываем в главе 32 в рамках управления изменениями на предприятии.
Пример двойного карьерного роста
Архетип Описание
Экспертное руководство
Руководство персоналом
Исполнительное руководство
Для тех, кто ставит во главу угла разработку лучших в своем классе идей по теме, совершенствование своего мастерства и формирование ожиданий клиентов
Для тех, кто ставит во главу угла руководство большими командами, объединение усилий различных отделов и управление ожиданиями клиентов.
Для тех, кто хочет руководить как менеджерами по персоналу, так и экспертами, определяя структуру, приоритеты и работу всей организации.
ПРИМЕР СПЕЦИАЛИСТА ПО ИССЛЕДОВАНИЮ ДАННЫХ
IC - индивидуальный вклад
EL - Экспертное руководство
PL - руководство персоналом
EX - Executive
IC 1
IC 2
Младший специалист по исследованию данных Ассоциированный специалист по исследованию данных
IC 3
IC 4
IC 5
Специалист по анализу данных
Старший специалист по анализу данных Ведущий специалист по анализу данных
Заместитель директора, данные
Наука
Директор, данные
Наука
Старший директор, наука о данных
Главный специалист по науке о данных
Менеджер по науке о данных
Старший менеджер по науке о данных
PL 9
EL 9
PL 8
EL 8
PL 7
EL 7
PL 6
EL 6
EX 10
Директор по науке о данных
VP,
Наука о данных
Главный специалист по данным и аналитике (CDAO)
ПРИЛОЖЕНИЕ 12.1
Основной принцип современного подхода к обучению - непрерывность, индивидуальность и целенаправленность. Это далеко от традиционных программ обучения, которые слишком часто воспринимаются как "рутина", а не как возможность развить навыки.
В этой теме легко заблудиться. Многие HR-организации начинают с большими амбициями, но уже через несколько месяцев обнаруживают, что задача по разработке учебных маршрутов и программ обучения для множества цифровых ролей и уровней квалификации является непосильной. Здесь необходим настоящий прагматизм. Обычно мы советуем нашим клиентам сосредоточиться на следующих трех типах программ L&D для своих цифровых сотрудников, а для всего остального привлекать внешних провайдеров.
Создайте цифровой "буткемп на рампе".
Тысячи людей будут объединяться в группы для разработки решений в рамках вашей цифровой дорожной карты. Люди, присоединяющиеся к этим группам, являются представителями разных специальностей и имеют разный уровень понимания цифрового видения компании, ее гибких методов работы, основ дизайна пользовательского опыта, технологического стека компании и так далее. По этой причине разработка "цифрового пути" - это первый тренинг, который вы должны разработать.
Такое обучение, как правило, носит достаточно индивидуальный характер, поэтому его лучше всего разрабатывать внутри компании. Отдел цифровой трансформации часто составляет эту программу и опирается на команду L&D компании, чтобы помочь сформировать и управлять обучением. Как правило, такое обучение проводится в формате буткемпа (интенсивного, в течение всего дня, в течение недели), чтобы дать старт запуску капсул (см. пример типичного расписания буткемпа в Приложении 12.2).
Создайте учебные программы для талантливых специалистов в области цифровых технологий
Мы не можем не подчеркнуть, что навыки - это главная валюта для цифровых специалистов, а возможность развивать навыки - важный мотиватор для них. По этой причине крайне важно инвестировать в разработку долгосрочных программ обучения, которые помогут сотрудникам технологических компаний развить широту и глубину своих знаний, а также поведенческие навыки, которые также ценятся в организации.
Пример запуска стручка bootcamp
Командные рабочие сессии
Размышления
ДЕНЬ 1
ДЕНЬ 2
ДЕНЬ 3
ДЕНЬ 4
ДЕНЬ 5
Начало (приветствие руководства, почему мы здесь, более широкая история преобразований)
Определите рабочие соглашения/нормы для команды
Определение MVP (согласование определения MVP, составление сюжетной карты, проект MVP продукта)
Понять, что такое devops и как его использовать (конвейер CICD и платформа для разработчиков).
Поделитесь с руководством (демонстрация работы команды, сбор отзывов от руководства)
Ретроспектива учебно-тренировочного лагеря
Обзор и моделирование Agile (Согласование определения Agile, менталитета и поведения, Agile-практик для команд.
Моделирование)
Составление карты заинтересованных сторон (схема взаимодействия с заинтересованными сторонами, разработка карты заинтересованных сторон)
Создание бэклога (согласование определения бэклога, практика написания пользовательских историй)
Определите каденцию спринта
Создание дорожной карты продукта (согласование определения дорожной карты продукта, подготовка проекта дорожной карты продукта)
Определение миссии/видения (согласование миссии, разработка заявления о видении)
Планирование спринта 1 (пересмотр пользовательских историй для спринта 1, пересмотр оценки, уточнение критериев приемки)
Определение готового/определение сделанного
Доработка пользовательских историй для 2-3 спринтов (оценка историй, уточнение критериев приемки, планирование 2-3 спринтов)
Время командной работы (команда продолжает дорабатывать артефакты, внедряет модель взаимодействия с заинтересованными сторонами, планирует события спринта, настраивает инструменты командной работы)
Согласование OKR (Согласование определения OKR, OKR
практика письма, составление командных ОКР)
Оценка (Что такое точки рассказа? Методы оценки и планирование покера, практика оценки пользовательских историй)
Понимание нашей технологической среды и архитектуры данных (что важно для целевого цифрового решения).
Подготовка к демонстрации (артефакты, созданные в течение недели, формат демонстрации)
Ретроспектива
Ретроспектива
Ретроспектива
Ретроспектива
Примечание: Команды могут изменять это расписание в зависимости от наличия команды, часовых поясов и
очная/виртуальная/гибридная модель работы
Время командной работы (доработка артефактов, созданных в течение дня)
Время командной работы (доработка артефактов, созданных в течение дня)
Время работы в команде (настройка инструментов для совместной работы)
Время командной работы (сухой прогон демо-версии, настройка логистики демо-версии)
При разработке маршрутов обучения важно различать семейства навыков. Не поддавайтесь искушению рассматривать все технические роли как взаимозаменяемые ("они все инженеры") и предоставлять им одинаковое меню вариантов обучения. Пути обучения фронтенд-разработчика, владельца продукта или UX-дизайнера заметно отличаются друг от друга. Очевидно, что эту работу могут выполнять только самые старшие технологи. Пути обучения также должны быть организованы по уровню квалификации и согласованы с карьерным ростом и вознаграждением.
На рисунке 12.3 показано, каким может быть путь обучения облачного инженера. Обратите внимание, что такие учебные курсы для углубления мастерства длятся несколько лет - вы не можете рассчитывать на получение реальной экспертизы, особенно в высокотехнических областях, за несколько месяцев. Такие курсы должны включать в себя полный набор навыков, необходимых для создания глубокой экспертизы в соответствующей области.
Поскольку навыки, развиваемые в таких программах, как правило, не являются специфическими для вашей компании, лучше всего передать обучение на аутсорсинг таким организациям, как Coursera, Udacity, Cloud Academy и Udemy, которые предлагают широкий выбор программ. Многие компании предоставляют своим цифровым сотрудникам ежегодную стипендию на обучение и предоставляют им возможность самим найти лучшее предложение для своих конкретных нужд.
Короче говоря, сосредоточьте свои усилия на определении ожидаемых навыков для каждого семейства навыков и уровня квалификации, и пусть ваши сотрудники сами решают, какое предложение на рынке им больше подходит.
Переквалификация с помощью буткемпов
Переквалификация - это процесс переобучения человека для другой роли. Это может быть серьезным мероприятием, которое может занять от шести до 12 месяцев и более (в это время сотрудники не смогут выполнять свои повседневные обязанности). В связи с этим загрузочные курсы кодирования являются одним из наиболее эффективных способов развития технических навыков (например, JavaScript, CSS, C#, Ruby, Python) для различных ролей (например, front-end разработчик, back-end разработчик).
Примерный путь обучения инженера по облачным технологиям
Специфика ролиСпецифика платформы Способы работы
Повышение уровня компетентности
НОВИЧОК
КОМПЕТЕНТ
ЭКСПЕРТ
УЗНАТЬ
Что такое Контейнеры для ServerlessCloud riskEfficient Cloud Cloud? производство вычисления разработка
Стоимость облака
Виртуализация и Применение облачных Безопасность облачных управлениеГибридное развертывание облачных технологий с учетом особенностей бизнеса Модернизация моделей сценарии Эластичные CSP-приложения с
Облако Anthos
Введение в DevOpsCloud Cloud SREИнфраструктура и контейнерыРазработка
Ведение журнала, Надежность CSP CSP CloudEssential CSPmonitoring , andCloud fundamentals Облачная инфраструктура - наблюдаемость в инфраструктуре
масштабирование инфраструктуры и Облако CSP
автоматизация
Основные сведения о CSP Начало работы Привлечение
Инфраструктура Terraform для заинтересованные стороны
Фонд Начало работы Облако CSP
с Kubernetes
двигатель
Основные принципы CSP Scrum 101
Инфраструктура
Основные услуги Работа с
кросс-функциональные MVP-мышление
команды
Решение проблем
Принятие основ Agile
LY
Определите постановку бизнес-задачи для реализации
Создание и управление облачными ресурсами
Установка и настройка облачной среды в CSP Cloud
Развертывание и управление облачными средами с помощью CSP Cloud
Облачная архитектура: Разработка, внедрение и
APP
Облако Выполните Управление
основополагающий Автоматизация Оптимизация затрат Инфраструктура Инфраструктура для CSP
задачи Облако CSP с Kubernetes
Terraform Движок
Наиболее эффективным подходом является сотрудничество со специализированными компаниями, предлагающими подобные буткемпы, такими как Turing School, Hack Reactor, CODE и LeWagon. Лучшими кандидатами для участия в таких программах обычно становятся люди, обладающие эмпатией, смелостью и сильным мышлением роста, способные решать логические задачи и страстно любящие программирование. Некоторые из лучших инженеров-программистов McKinsey вышли из таких программ. Тем не менее, переквалифицировать большое количество людей сложно и дорого. Программы переквалификации обычно используются для талантливых людей, в которых компания хочет инвестировать. Они могут быть особенно эффективны для компаний с количественным или инженерным составом.
Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:
Достаньте свою "дорожную карту" талантов - такая же ли она подробная и всеобъемлющая, как и ваша технологическая "дорожная карта"?
Какие навыки являются ключевыми для вашего конкурентного преимущества, и ясно ли вам, какие изменения нужно произвести, чтобы найти таких специалистов?
Развились ли ваши HR-практики для поиска, найма и удержания лучших цифровых талантов (например, предварительный отбор и предложение за четыре недели, убедительная EVP и т. д.)?
Признана ли ваша компания местом, где хотят работать лучшие таланты?
Верят ли ваши лучшие сотрудники в то, что они смогут вырасти и построить многообещающую карьеру в вашей компании (проверьте показатели оттока лучших сотрудников - знаете ли вы риск "ключевых людей")?
Есть ли у вас карьерная лестница, в которой ценятся отличные технологи в той же степени, что и в той, в которой ценятся отличные менеджеры?
Что вы делаете, чтобы помочь своим техническим специалистам освоиться в бизнесе и продолжать развивать их мастерство?
Принятие новой операционной модели
Изменение архитектуры организации и управления для обеспечения быстроты и гибкости
Понятие "маневренность" уже настолько приелось, что стало почти клише, но оно по-прежнему является основой того, что требуется компаниям для работы в ритме цифровых технологий.1 Создание и масштабирование цифровых решений и решений на основе ИИ требует от компаний гораздо большей скорости и гибкости в разработке технологий, и маневренная операционная модель - это путь к достижению этой цели. Однако разработка такой операционной модели - это, пожалуй, самый сложный аспект трансформации цифровых технологий и ИИ, поскольку она затрагивает суть организации и то, как люди работают вместе.
Agile-команды - или "подсы", как мы предпочитаем этот термин - являются наиболее эффективным способом разработки программных решений, и это уже не подлежит обсуждению. Но, несмотря на то, что любая компания может собрать несколько команд для работы
Ну, а встать и поднять сотни, если не тысячи, из них - это уже другая история.
В этом разделе рассматриваются наиболее важные методы работы хорошо функционирующих капсул и, что более важно, то, что требуется для организации и управления большим количеством таких капсул.
Глава 13: От выполнения agile к тому, чтобы быть agile. Понимание того, что требуется помимо базовых изменений в процессах для того, чтобы agile pods работали с максимальной эффективностью и отдачей.
Глава 14: Операционные модели, поддерживающие сотни agile pods. Три ведущих варианта операционных моделей, которые появились, чтобы перейти от горстки гибких команд к поддержке сотен таких команд на всех уровнях предприятия: цифровая фабрика, продукт и платформа и гибкость в масштабах предприятия.
Глава 15: Профессионализация управления продуктами. Владельцы продуктов - эффективные руководители agile-подразделений. Они являются стержнем любой операционной модели и нуждаются в приоритетном внимании и инвестициях.
Глава 16: Дизайн клиентского опыта: Волшебный ингредиент. Те компании, которые действительно ориентированы на клиента, вкладывают средства в понимание мотивов пользователей и воплощают их в опыт, который удовлетворяет потребности и доставляет удовольствие.
Примечание
1. Daniel Brosseau, Sherina Ebrahim, Christopher Handscomb, and Shail Thaker, "The journey to an agile organization," McKinsey.com, May 10, 2019, https://www.mckinsey.com/capabilities/people-and- organizational-performance/our-insights/the-journey-to-an-agile- organization; "The drumbeat of digital: Как играют команды-победители", McKinsey Quarterly, 21 июля 2019 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/the-drumbeat-of-digital-how- winning-teams-play.
От
"делать
agile
" к "быть
agile
".
Наша цель - не повторять обширную литературу, посвященную agile. Но важно понять основные концепции, лежащие в основе agile-методов работы, и сосредоточиться на том, что компании должны сделать правильно, чтобы добиться успеха. Понимание того, как эффективно управлять agile-командами и извлекать пользу из нового способа работы, имеет решающее значение для масштабирования модели, о чем мы поговорим в главе 14.
Многие компании экспериментируют с agile в рамках ИТ-организации или за ее пределами. При правильном внедрении даже небольшое количество agile-команд может быстро принести пользу (см. Рисунок 13.1). Но компании сталкиваются с проблемами, когда они слишком много внимания уделяют agile как набору процессов и недостаточно - как новому способу определения приоритетов и концентрации ресурсов на главном. В таких ситуациях руководство Agile - это лучший подход к разработке
Сравнение эффективности работы опытных agile-команд с командами, использующими все остальные методы разработки
ДЕШЕВЛЕ
БЫСТРЕЕ
ЛУЧШЕ
Повышение производительности, единицы сложности1 на ЭПЗ/неделю
Уменьшите отставание от графика,
Проекты, не выпущенные в срок
Меньше остаточных дефектов,
Ошибки в программном обеспечении2
Agile:
+27%
Базовая линия без гибкости
Базовая линия без гибкости
Базовая линия без гибкости
Сбор и проверка данных для 1000+ выпусков ПО (технические характеристики, уровень персонала, этапы, уровень дефектов и т.д.).
Разработка исторического базового показателя эффективности на основе сложности и трудоемкости проекта
Ловкость: -30%
Сравнение с группой аналогов, состоящей из отдельных отраслевых проектов
Agile -70%
Единицы, обладающие большим количеством структуры или информации, часто в нескольких временных и пространственных масштабах
Проблема, приводящая к аварийному завершению работы программы или выдаче некорректных результатов
Источник: База данных отраслевого программного обеспечения Numetrics - 1 321 проект и аналитика с помощью запатентованного алгоритма нормализации (2021 год)
ПРИЛОЖЕНИЕ 13.1
внедряет ритуалы agile, но затем разочаровывается, когда результатов нет, и обвиняет agile. Простое внедрение ритуалов agile без внесения соответствующих изменений в постановку задач, формирование команд и обеспечение ответственности за результаты приведет к плачевным результатам.
Начнем с agile-методологий. Существует несколько разновидностей: scrum (по названию команды), kanban, SAFe (Scaled Agile Framework) и другие. Каждая из них имеет свой собственный язык, каденции и виды деятельности, что иногда приводит к жарким спорам о том, какая из них лучше.
Мы считаем, что все эти обозначения не имеют значения. Некоторые из лучших компаний, которые являются носителями цифровых технологий, даже не называют свои методы работы "agile". Большинство организаций получат пользу от использования фреймворка scrum, и мы используем его в этой книге, хотя признаем, что и другие подходы могут быть эффективными. Однако важно разработать четыре набора определяющих характеристик, которые отличают agile-подразделения от традиционных команд разработчиков ПО. К ним относятся:
Миссия с измеримыми результатами. Руководство дает каждому подразделению четкую миссию, основанную на общей цифровой "дорожной карте". Каждая миссия должна быть нацелена на конечные результаты (или ключевые результаты), которые можно измерить и которых группа может достичь в разумные сроки (в месяцах или кварталах, а не в годах).
Междисциплинарный подход с выделенными ресурсами. В состав групп входят специалисты по бизнесу, техническим и функциональным вопросам, каждый из которых привносит ценные возможности или навыки в процесс разработки решения. У группы должны быть все ресурсы, необходимые ей для выполнения своей задачи, и эти ресурсы должны быть выделены.
Автономность и ответственность за достижение результатов. Чтобы этот гибкий подход был успешным, подгруппы должны нести ответственность за работу, которую они выполняют. Эта ответственность распространяется не только на разработку решения, но и на реализацию ценности этого решения. Подразделения наделяются полномочиями принимать решения по разработке решений для достижения миссии. Владелец продукта - фактический руководитель подгруппы - постоянно определяет приоритетность функций разработки продукта в бэклоге.
Быстрое развитие и ориентация на потребности пользователей. Основной подход к работе agile pod - тестирование, обучение и постоянное совершенствование решения на основе четкого представления о том, что нужно конечному пользователю. Подгруппы работают над созданием чего-то нового и тестируют его с конечными пользователями каждые две недели, чтобы собрать прямую обратную связь и быстро адаптироваться. Члены группы получают немедленную обратную связь и выполняют ее.
По их словам: Освободите свои продуктовые отряды
Один из ключевых сдвигов заключался в том, чтобы сосредоточиться на том, какую ценность мы пытаемся создать. Изменение модели с целью сосредоточиться на опыте сотрудников, в отличие от сосредоточения на том, были ли проекты выполнены в срок и в рамках бюджета, было фундаментальным изменением.
Вторая вещь - это то, что основная операционная модель вращается вокруг отряда [т. е. капсулы], и то, что отряды получают все необходимое, чтобы обеспечить им успех. Это позволяет им быть самостоятельными, чтобы они могли сами определять направление своей деятельности и принимать решения.
Когда вы создаете такую команду, вам нужна роль владельца бизнес-продукта, роль владельца технического продукта, а также скрам-мастера. Это типичная модель отряда с точки зрения технологий. Но переход от проектно-ориентированной модели, в которой некоторые люди заняты лишь 20 % своего времени, - это фундаментальный и необходимый сдвиг.
Это не ракетостроение. Нужно просто собрать все вместе в модель, которая имеет смысл для работы, которую нужно сделать, и оставаться действительно сосредоточенным и преданным этой работе, вот почему вам нужна постоянная команда, которая существует и после первоначальной поставки продукта, который вы пытаетесь создать.
Мы, безусловно, выиграли от этой модели, и мне не звонили люди в любое время дня и ночи с вопросами: "Что мне делать с этим проектом? Как мне принять это решение?" Они могли самостоятельно принимать решения по своим продуктам, при этом отчитываясь, чтобы мы были в курсе происходящего.
Мы стараемся пропагандировать это движение в сторону продуктоориентированных технологий, указывая на то, что вы не станете выпускать на рынок медицинское оборудование или фармацевтический продукт, а затем просто от него откажетесь. Вы хотите постоянно инвестировать и поддерживать развитие этого продукта на рынке. Почему бы нам не сделать то же самое с технологиями? Я думаю, что использование этой аналогии иногда помогает людям понять и раскрыть часть этой ценности.
Том Век, ИТ-директор по корпоративным технологиям компании Johnson & Johnson
Три церемонии, которые имеют наибольшее значение для повышения эффективности agile
Существует ошибочное мнение, что agile - это свобода действий и отсутствие достаточного участия и контроля со стороны руководства. Это случается при плохом внедрении agile. На самом деле, если все сделано правильно, agile - это эффективный способ управления производительностью, поскольку он ориентирован на результат и частые проверки прогресса.
Для достижения этой цели наиболее важны три церемонии (термин, описывающий встречи с определенной частотой, продолжительностью и целями) (см. Рисунок 13.2). Правильно организуйте их, и вы добьетесь успеха в agile-внедрении.
Определение миссии и OKR
Это самая важная церемония, потому что именно тогда руководство задает направление и устанавливает ожидания (см. №1 на иллюстрации 13.2). Миссия - это работа, которую подгруппа выполняет в течение года или более длительного срока. Руководство и владелец каждого подразделения разбивают миссию на цели и ключевые результаты (OKR) и устанавливают конкретные квартальные задачи для подразделения. OKR, как правило, приписываемые детищу покойного генерального директора Intel Энди Гроува, доказали свою эффективность в том, чтобы сфокусировать команды на воздействии, а не на деятельности. На практике это сложнее, чем кажется, и часто является основной причиной неудач в agile-развертываниях1. Подразделение преобразует свои цели в дорожную карту продукта или решения, в которой подробно описывается, как оно будет достигать ожидаемых результатов.
Каждый OKR связан с бизнес-результатами, которые разделяют все члены команды. Цели должны быть четкими и конкретными. Количество целей должно быть разумным - лучше меньше (обычно от одной до трех). Изменять цели следует только после тщательного обдумывания.
По их словам: OKRs - согласование того, что важно
OKR - это способ согласовать то, что наиболее важно в данный момент, а затем итерировать это, потому что это не постоянно. Стартапы по праву рождения постоянно калибруют огромные амбиции, имея очень мало ресурсов.
Их возможности по отношению к их амбициям дико несопоставимы, что одновременно и восхищает, и ужасает, когда речь идет о стартапе. У них нет неограниченного времени, денег и ресурсов. Итак, если бы нам пришлось пойти на компромисс между тем, что имеет наибольшее значение, что бы мы поменяли, а что нет? OKR - это техника, позволяющая крупным компаниям работать с тем же понятием ограничений, и эти ограничения помогают сделать выбор.
Еще один важный момент, который сильно отличается от того, что было до них, - это то, что OKR делают акцент на том, что выглядит потрясающе, в отличие от того, что было бы безопасно и дало бы наиболее предсказуемый результат. Это перевернуло вопрос: "Хорошо, в течение следующих 90 дней, каких наилучших результатов мы могли бы достичь?"
Дело не в том, чтобы стараться выглядеть хорошо в своих KPI. Речь идет о стремлении быть удивительным. Мне нравится это сочетание: полностью реализовать амбиции, а затем, учитывая ограниченные возможности, решить, что мы будем делать в первую очередь? Что, по нашему мнению, двигает иголки, и какие иголки имеют наибольшее значение?"
-Дейдре Пакнад, соучредитель и генеральный директор компании WorkBoard
Ключевые результаты должны быть агрессивными, вплоть до того, что иногда они будут пропущены, и это нормально. На самом деле ключевые результаты, вероятно, установлены слишком низко, если капсулы всегда их достигают. Ключевые результаты должны легко отслеживаться, поддаваться количественной оценке и быть связаны с бизнес-ценностью (см. Рисунок 13.3).
В этом и заключается искусство разработки OKR, и, по нашему опыту, для того, чтобы у руководства это получалось, нужна практика.
Продвижение и тестирование в ходе спринта
Спринт - это, как правило, двухнедельная работа по разработке функций цифрового решения (см. № 2 на рис. 13.2). Несколько спринтов составляют фазу разработки (обычно три месяца). Владелец продукта (или менеджер) определяет приоритеты работы команды в спринте, составляя хорошо организованный список дел (также известный как бэклог), в который входят все работы, необходимые для завершения текущего спринта и последующих одного-двух спринтов.
Пример ОКР
Программное решение для поддержки корпоративных служб управления персоналом
ЦелиКлючевые результаты Сроки
1.1
1
Радовать наших клиентов и каждый раз дарить им положительные моменты, которые имеют значение
1.2
1.3
2.1
2
Сокращение прямых затрат, связанных с продуктом
2.2
2.3
3.1
3
Улучшение удержания клиентов за счет стабилизации продукта
3.2
3.3
Разработка целостного, согласованного пользовательского опыта для всех трех персон со 100% реализацией пользовательских маршрутов
Доведите показатель выпуска безошибочных отчетов для клиентов до 95% с ~80%.
Q1
Q2
Увеличьте среднюю NPS до ~40 с ~13 для продукта V
Q2
Внедрение и стимулирование использования функций самообслуживания для снижения количества звонков на 10%.
Q3
Автоматизируйте отчеты для запросов, которые получают более 100 запросов на обслуживание в квартал
Q3
Сократите расходы на хостинг на 20 %.
Q4
Соответствие времени безотказной работы продукта SLA (99,995%) в течение всего года
Q4
Сократите количество критических инцидентов до 63 (с 83), а количество "горячих" исправлений - на 50% (с 4 до 2).
Q3
Добивайтесь того, чтобы количество принятых дефектов было ниже, чем количество разрешенных дефектов
Q2
ПРИЛОЖЕНИЕ 13.3
Способность владельца продукта пересматривать и корректировать приоритеты, при необходимости эскалировать проблемы, планировать спринты и продумывать зависимости является основополагающей для функционирования команды. Большинство компаний сталкиваются с нехваткой способных владельцев продуктов (подробнее об управлении продуктами читайте в главе 15).
Двухнедельный спринт завершается обзором спринта, и это возможность для команды продемонстрировать артефакты своего прогресса и убедиться в том, что она выполняет поставленные задачи. Это также возможность для руководства - как правило, лидер домена - чтобы отметить команду и обеспечить руководство...
Под не готовит формальные, отшлифованные презентации для обзоров спринтов. Это было бы слишком обременительно. Вместо этого они делятся результатами проделанной работы. Для устоявшихся компаний это всегда непростое культурное изменение.
Конкретные церемонии спринта описаны на Рисунке 13.4.
Управление с помощью ежеквартальных обзоров деятельности (QBR)
QBR, или ежеквартальный обзор бизнеса, - это момент, когда руководство оценивает прогресс и достигнутые результаты и при необходимости перенаправляет команду. QBR - это официальная церемония, на которой присутствуют владельцы подсистем и лидер домена. На ней оценивается прогресс за последние три месяца, корректируются ОКР на следующие три месяца и обеспечивается четкая координация ОКР между подразделениями. После того как это сделано на уровне домена, вторая церемония на уровень выше объединяет всех руководителей доменов с руководителем бизнес-подразделения. Это возможность пересмотреть ОКР на уровне домена и общее финансирование домена.
Требуется время, чтобы продумать, как именно QBR будут встраиваться в цикл планирования компании - как QBR должны быть связаны со строгим планированием и бюджетированием? Как они должны быть скоординированы с ежеквартальными и ежемесячными заседаниями исполнительного комитета? Заменяют ли они обзоры инвестиционных комитетов?
QBR иногда критикуют за то, что они добавляют больше встреч в повестку дня руководства. При правильном применении это не так. На самом деле QBR могут сократить количество совещаний руководства на 75 %, как показано на примере одного из американских банков, приведенном в Примере 13.5.
Agile-церемонии
ЦЕРЕМОНИЯ
ОПИСАНИЕ
ОЖИДАЕМЫЕ РЕЗУЛЬТАТЫ
FREQUENCY
Бэклог
Элементы в бэклоге
Бэклог содержит ряд
Каждый спринт
рафинирование
приоритетны и
пользовательских историй, которые были
(2 недели)
отлажены, чтобы обеспечить
расставлены приоритеты, хорошо документированы
готовы к предстоящему
ed, и являются всеобъемлющими
спринт и 1-2
достаточно, чтобы потенциально сформировать
следующие спринты
бэклог следующего спринта
Планирование спринта
Используется для того, чтобы убедиться, что команда согласна с предложенным
Приоритетные эпосы и истории1 распределяются по спринтам
Каждый спринт
объем работы, который
состоит из нескольких элементов в спринте
Были определены допущения, риски и зависимости
отставание
Ежедневные посиделки
Служит для оценки хода спринта и определения
У каждого члена команды есть 1+ задачи на день
Ежедневно
возможные барьеры
Статус пользовательских историй/задач был обновлен
Блокирующие устройства, если таковые имеются, были подняты
Обзор спринта
Возможность для команд представить новые функциональные возможности, разработанные в недавно завершившемся спринте
Обратная связь предоставляется для обновления или добавления будущих пользовательских историй
Каждый спринт
Sprint
Используется для оценки спринта
Сильными сторонами команды были
Каждый спринт
Ретроспектива
производительность и определить
определены
возможности улучшения
Решение проблем для команды
а также сильные стороны для
улучшения были
команда
определены и назначены
Ежеквартальный обзор деловой активности
Выполняется на старте проекта и каждый квартал для согласования OKR и дорожной карты продукта
Приоритетные эпосы и истории распределяются по спринтам
Были определены допущения, риски и зависимости
Каждый квартал
Установлены OKR на следующий квартал
Эпики: большие куски работы, обеспечивающие полную функциональность (включают несколько историй и охватывают несколько спринтов) Пользовательские истории: функция с точки зрения конечного пользователя
Упорядочение работы управленческих форумов в связи с внедрением QBR
Пример американского банка,
ДО ВНЕДРЕНИЯ QBR
по характеру управления
Форум ликвидирован
Форум сохранен
Готовность к изменениям
Форум изменен
Технологическая и производственная готовность
Операционный и технический риск
Финансирование
Измерение воздействия
Форумы
Часы
От:
30+
~75,000
Для:
8
~50,000
Изменения:
-75%
-35%
Ежемесячная линия автобуса. Финансовый обзор
Обзор бизнес-кейсов (ИТ-компонент)
Совещание по утверждению технологических лидеров
Совещание по бизнес рискам и контролю
Комитет по технологическим продуктам (x12)
Комитет по рассмотрению новых инициатив
Комитет по обзору BAU
Форум профильных экспертов
Обзор бизнес-кейсов (ИТ-компонент)
Прием проектов (на основе каталога услуг)
Идентификация заинтересованных сторон
Ежемесячный инвестиционный комитет
Готовность производства
Архитектурный совет
Консультативный совет по изменениям (x2)
Прямой впуск (x5) (по индивидуальным запросам)
ПОСЛЕ ВНЕДРЕНИЯ QBR
Scrum@Scale Cadence
Консультативный совет по изменениям (x1)
Архитектурный совет
Готовность производства
Ежеквартальный деловой обзор
Надзор за рисками на второй линии защиты
Ежемесячный финансовый обзор по направлениям деятельности
Руководящий комитет по стратегии развития направления бизнеса
Примечание
Джон Дорр, "Измерять то, что важно", Penguin Random House, 2018; Мэтт Фитцпатрик и Курт Стровинк, "Как измерить успех в цифровых технологиях? Пять показателей для руководителей компаний", McKinsey.com, 29 января 2021 года, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ how-do-you-measure-success-in-digital-five-metrics-for-ceos.
Глава 14.
Операционные модели, поддерживающие сотни гибких подразделений
Один из самых больших камней преткновения при трансформации цифровых технологий и ИИ - это переход от управления горсткой подсистем к управлению сотнями подсистем. Если горсткой гибких подразделений относительно легко управлять в порядке исключения и с дополнительными усилиями, то при расширении до сотен или тысяч подразделений это невозможно.
Чтобы поддерживать такое количество команд, компаниям нужна более формальная операционная модель. Эта глава посвящена трем фундаментальным моделям:
(1) цифровая фабрика, (2) продукт и платформа и (3) корпоративная гибкость. Все эти три подхода зависят от контекста и цифровой зрелости компании, но они используют одни и те же строительные блоки.
Организационные строительные блоки
Любая цифровая операционная модель состоит из трех организационных блоков (см. Рисунок 14.1):
Подразделения, занимающиеся продуктами или опытом, разрабатывают и предоставляют технологичные предложения или услуги, используемые клиентами и сотрудниками. Их непосредственная и основная цель - дать пользователям возможность выполнять действия, создающие стоимость. Например, поисковая система ритейлера создает ценность для бизнеса, облегчая клиентам поиск товаров на сайте или в мобильном приложении.
Слово "продукт" было унаследовано от индустрии программного обеспечения. Разные компании используют разные термины, более подходящие для их контекста. Компании, предоставляющие финансовые услуги, называют их клиентским опытом; компании, производящие промышленные товары, называют их решениями для клиентов. Независимо от используемого термина, "продукты" вовлекают клиента или пользователя непосредственно через цифровые технологии.
Группа модулей продукта или опыта, работающих над одним и тем же сквозным путешествием (например, над приемом клиентов) или процессом (например, над оптимизатором доходности), называется доменом (как описано в главе 2). Домен обычно состоит из 10-20 подсистем и возглавляется владельцем домена.
Платформы - это внутренние технологии и возможности передачи данных, которые поддерживают продукты. Например, поисковая система для розничной торговли может опираться на платформу управления запасами, которая включает базы данных и интерфейсы для интеграции с дополнительными устройствами. Возможности платформы обеспечивают более эффективное масштабирование, предоставляя функциональные возможности, которые необходимы многим продуктовым капсулам для предоставления услуг.
Строительные блоки гибких операционных моделей
Клиенты/пользователи
Под
Практика или глава
Подборки продуктов (или путешествий)
Функции поддержки и управления
Платформенные капсулы
ЧТО МЫ ИМЕЕМ В ВИДУ
ПРИМЕРЫ
Под: Самодостаточная, кросс-функциональная команда, несущая сквозную ответственность за предоставление продукта, опыта или услуги.
Альтернативная таксономия: отряд, ячейка, agile-команда
(см. ниже)
Подборки продуктов (или путешествий): E2E-доставка услуги или решения клиенту или пользователю.
Оптимизатор урожайности
Рекомендации по ценообразованию
Совокупность продуктовых капсул называется группой продуктов, доменом, портфелем, племенем или городом.
Привлечение клиентов Поиск продуктов на сайте
Платформенные модули: Объединение схожих технологических активов и людей,
Продукт данных Customer 360
и финансирование для предоставления услуг (многоразового использования) продуктовым/путешественным капсулам.
Набор для машинного обучения Основная система
Совокупность платформенных капсул называется платформой, племенем или городом.
Обеспечение инфраструктуры
Практика или глава: Организационная конструкция, отвечающая за профессиональное развитие сотрудников (отдельно от
дневное направление, выполняемое капсулой).
Альтернативная таксономия: гильдии, практические сообщества
Инженеры по обработке данных Инженеры-программисты
Владельцы/менеджеры продуктов
Платформы также обычно содержат 15 подсистем или более, и возглавляются менеджером платформы. Типичные платформы включают (a) платформы данных, такие как Customer 360, (b) корпоративные системы, такие как ERP или CRM, (c) платформы как услуги (PaaS), такие как приложения для аутентификации пользователей или алгоритмы машинного обучения, и (d) платформы инфраструктуры (IaaS), предоставляющие такие услуги, как облачные вычисления и хранение данных.
Глава - это группа людей с одинаковой ролью (например, владельцы продуктов, специалисты по анализу данных, инженеры по обработке данных). Главы отвечают за накопление опыта и поддержание общих подходов к решению задач. Руководители глав управляют карьерным ростом, нанимают отдельных сотрудников и проводят оценку их работы. Роль руководителя отделения заключается в том, чтобы распределять людей по отделениям в зависимости от их потребностей. Глава также отвечает за обмен передовым опытом и разработку методов и стандартов. Например, глава по дизайну определяет стандартную методологию проектирования.
Главы пытаются компенсировать тот факт, что капсулы являются кросс-функциональными. Подгруппы отлично подходят для того, чтобы собрать всех необходимых специалистов для работы, но они по своей природе слабы в плане развития мастерства. Если вы единственный инженер по данным в группе, у вас нет возможности учиться у других, более опытных инженеров по данным. Главы помогают компенсировать этот недостаток.
Существует две версии глав: тяжелая и легкая. Тяжелая версия описана выше. Легкая версия - ее часто называют гильдией - представляет собой скорее неформальную сеть. Она ограничивается обменом передовым опытом, разработкой и стандартами работы. Набор, комплектование и оценка персонала возлагаются на руководителей доменов или платформ. Какая модель лучше - легкая или тяжелая - является предметом споров.
Варианты разработки операционной модели
По нашему опыту, существует три основных варианта построения гибкой операционной модели: (1) модель цифровой фабрики, (2) модель продукта и платформы и (3) гибкая модель в масштабах всего предприятия (см.
Рисунок 14.2). Каждая модель включает в себя элементы описанных выше строительных блоков продукта, платформы и раздела.
Три варианта конструкции операционной модели
ВАРИАНТ 1
ВАРИАНТ 2
ВАРИАНТ 3
Цифровая фабрика
Продукт и платформа
Ускорение в масштабах предприятия
Описание
Отдельное цифровое подразделение, которое создает цифровые
Модель объединяет бизнес, технологии и
Расширение преимуществ гибкости за пределы
решения для бизнеса
операции в капсулах, сосредоточенные
цифровые/технологические, как многие
устройства, использующие современные
по улучшению качества обслуживания клиентов
основные операции и
гибкие методы работы
пользовательский опыт
функции могут принести пользу
и междисциплинарный
(так называемые продуктовые капсулы)
от гибкого сотрудничества
стручки
и капсулы, посвященные
строительные услуги для повторного использования
(так называемые платформенные капсулы)
Типичный
10-50 стручков
50-1,000+ стручков
1,000+ капсул
конфигурация
Затрагивает менее 2% организации
Затрагивает 20-40% организации
Затрагивает 80 % организации
Главная
Самая простая модель
Интеграция бизнеса,
Создает в масштабах всего предприятия
преимущество
внедрить
Технологии и оперативное управление
внимательно и адресно
гибкая культура
эволюция платформ
Пререквизиты
Согласование БУ в финансировании и операционной деятельности
Требуется модернизация ИТ (например, талант,
Организационная готовность к полному
модель завода
архитектура, облако,
гибкое движение
DevSecOps)
ПРИЛОЖЕНИЕ 14.2
Эти три модели в значительной степени различаются по уровню интеграции между бизнес- и технологическими ресурсами и по тому, насколько широко модель развернута в организации. Все три модели хороши. Ваш выбор будет зависеть от того, как вы собираетесь использовать технологии в качестве конкурентного преимущества.
Многие компании начинают с цифровой фабрики, потому что ее легче внедрить. Это отличная модель, когда технология является "стратегическим усилителем" для поддержки основного бизнеса. Ресурсные компании часто попадают в эту категорию.
Модель продукта и платформы особенно актуальна, если технология является основным источником конкурентной дифференциации, как, например, в банковском деле и розничной торговле. Некоторые ведущие банки и розничные компании перешли или переходят в настоящее время от модели "цифровой фабрики" к модели "продукт и платформа".
Те, кто выбирает модель для всего предприятия, хотят распространить преимущества agile на весь бизнес, а не только на технологически интенсивные области. Мы видели, как банки, телекоммуникационные компании и розничные торговцы совершили такой переход. Это требует серьезных многолетних обязательств со стороны генерального директора.
Поскольку каждая из этих моделей построена из одних и тех же строительных блоков, вы можете перейти от одной модели к другой, и многие компании так и делают.
Обратите внимание, что многие организации часто используют центр передового опыта (CoE), чтобы привнести цифровой опыт в свои бизнес-подразделения. Однако опыт показывает, что эта модель не является жизнеспособным вариантом масштабирования, поскольку она не поддерживает междисциплинарные команды и дублирует усилия по разработке, так как отсутствует конструкция платформы.
Цифровая модель завода
Модель цифровой фабрики часто является правильным местом для начала, поскольку она автономна и относительно быстро внедряется (обычно 12-18 месяцев до полной готовности к работе, хотя можно начать работу за несколько недель).1 На крупных предприятиях цифровые фабрики создаются в рамках подразделений, в то время как в небольших компаниях одна фабрика обслуживает несколько бизнес-подразделений. И горнодобывающая компания BHP, и Scotiabank внедрили модели цифровых фабрик, когда начали свои цифровые преобразования. В каждой из них было от четырех до пяти цифровых фабрик, обслуживающих различные подразделения, с координационным наложением для максимального повторного использования и стандартизации кода2.
Цифровая фабрика - это, как правило, физическое место, где люди работают вместе и отдельно от основного бизнеса. Преимущества совместного размещения в плане производительности и креативности реальны: затраты на координацию снижаются, решения принимаются быстрее, а количество переделок уменьшается. Удаленные рабочие команды также могут работать эффективно, хотя для этого требуется более целенаправленное и структурированное общение. Постарайтесь ограничить разницу в часовых поясах между членами команды до трех часов или меньше, если вы используете удаленную или гибридную модель.
На рисунке 14.3 показано, как одна из ведущих мировых гостиничных компаний организовала свою цифровую фабрику, в которой работает более 400 сотрудников.
Цифровая фабрика - это, как правило, формальное организационное подразделение, подчиняющееся главному цифровому директору. Она состоит из продуктовых и платформенных подразделений, в ней собраны все соответствующие специалисты (за исключением владельцев продуктов), и она объединяет их в отделы, отвечающие за управление талантами и их внедрение.
Бизнес-подразделения выступают в роли спонсоров на фабрике, финансируя и возглавляя работу, выполняемую продуктовыми подразделениями. Они определяют, какие возможности будут приоритетными, устанавливают OKR и обеспечивают финансирование. Бизнес-подразделения также предоставляют владельцев продуктов и экспертов по предметной области. По сути, бизнес-подразделения обеспечивают фабричные мощности для своих цифровых нужд. В свою очередь, фабрика предоставляет им специалистов по цифровым технологиям для работы в своих продуктовых капсулах и услуги, связанные с платформой (например, облачные вычисления и хранение данных, инструменты разработчика, основные системные интерфейсы или API).
Цифровая фабрика отвечает за работу платформенных капсул. Они финансируются централизованно или на основе разделения расходов с бизнес-подразделениями. Как правило, две трети ресурсов фабрики обычно направляются в продуктовые капсулы, а одна треть - в платформенные капсулы.
Годовое бюджетирование ориентировано на команду, а не на проект, то есть оно основано на количестве подгрупп. Это часто называют постоянным финансированием в отличие от традиционного финансирования на основе проектов (см. Рисунок 14.4). Такая модель финансирования рекомендуется как для продуктовых и платформенных, так и для общекорпоративных операционных моделей гибкости (см. ниже).
Цифровая модель работы завода
Пример гостиничного бизнеса Предполагаемые ЭПЗ (внутренние и внешние)
XX
Discovery
25-30
PODS
15-20
45-50
25-30
-
Владельцы продуктов
Ведущие разработчики QA
Специалист по изучению данных Data eng.
Дизайнеры
Тренер по Scrum Agile
Архитектура
Бренды
DOMAINS
Конвертировать
Приложение И т.д.
CMS1 и DAM2
15-25
.com - содержание и домашняя страница
.com - Предложение
Страницы отеля
Основные бренды
Бренд, интегрированный с доменом .com
Конвертировать
Оставайтесь
Привлечь
И т.д.
И т.д.
Оплата
15-20
Система бронирования
1-10
API4
10-30
Данные
15-20
ТЕХНОЛОГИЧЕСКИЕ И ИНФОРМАЦИОННЫЕ ПЛАТФОРМЫ
1. CMS = система управления контентом; 2. DAM = управление цифровыми активами; 3. OTA = онлайновое туристическое агентство; 4. API = интерфейс прикладного программирования; 5. CDP = платформа клиентских данных
CMS
Средства массовой информации и контент для отелей
Оплата онлайн
Платежное решение для отелей
Ввод и вывод данных
Поиск, наличие и бронирование
OTA3 и каналы + D-Edge
Управление API и портал
Открытое распространение
Перекрестные продажи (услуги третьих лиц)
Управление данными
Платформа данных и CDP5
Продукты данных
На наш взгляд, модель "цифровой фабрики" останется актуальной для компаний, в которых технологии важны, но, возможно, не являются главным фактором конкурентной дифференциации. Для бизнес-подразделений это отличный способ быстро обеспечить цифровой потенциал мирового класса.
От финансирования проектов к постоянному финансированию
ФИНАНСИРОВАНИЕ ПРОЕКТА
ПОСТОЯННОЕ ФИНАНСИРОВАНИЕ
БЮДЖЕТИРОВАНИЕ
Составление бюджета по проектам на ежегодной основе
Целевой годовой бюджет устанавливается на уровне предприятия и домена (не по проектам)
ФОНДИНГ
До 50% финансирования уходит на незапланированные или менее приоритетные работы
Дополнительное финансирование выделяется по достижении вех/этапов
ОБЗОР
Проекты пересматриваются и определяются по приоритетности ежегодно или два раза в год
Ежеквартальный обзор и определение приоритетов во время QBR
ПРИЛОЖЕНИЕ 14.4
Модель продукта и платформы
Модель "продукт и платформа" (P&P) используется большинством компаний-разработчиков программного обеспечения, ведущими мировыми розничными сетями, такими как Amazon, и ведущими мировыми банками, такими как JPMorgan Chase.3 Каждая из них приняла свою версию этой модели, поскольку она сближает бизнес, операции и технологии для ускорения инноваций в сфере обслуживания клиентов и создания более масштабируемой модели с помощью услуг на основе платформы.
Модель P&P - это более развитая версия цифровой фабрики, и ее развертывание происходит в гораздо больших масштабах. Если в модели цифровой фабрики может быть от 10 до 50 капсул, то в модели P&P, как правило, несколько сотен, а иногда и более тысячи капсул для крупных компаний.4 Это связано с тем, что модель затрагивает все технологические ресурсы и значительную часть ресурсов бизнеса и операций. На рис. 14.5 показана схема размещения модели P&P на 1000 с лишним капсул для одного из ведущих международных банков.
Модель продукта и платформы
Пример для международного банка
Розничная торговля
банковское дело
Богатство
управление
Бизнес
банковское дело
Коммерческая
банковское дело
Оптовая торговля
банковское дело
Активы
управление
Инвестиции
банковское дело
Партнеры по сбыту
Стратегии предприятия
BU
Стратегии
Стратегии предприятия (общие, цифровые, технологические, клиентский опыт, операционная деятельность и т.д.)
Стратегии и OKR
Стратегии и OKR
Стратегии и OKR
Стратегии и OKR
Стратегии и OKR
Стратегии и OKR
Стратегии и OKR
Филиалы
Распространение
Консультанты, мобильный salesforce
Консультанты, прямые
RMs
RMs
RMs
Цельнозерновые салеры
Продажи
Путешествия
Сегментные операционные системы
Сегмент Сегмент
Опс Опс
Сегментные операционные системы
Сегментные операционные системы
Сегмент Сегмент
Опс Опс
Ассистирование (отделения, контактный центр, коллекторы, мошенничество)
Самообслуживание (банкомат)
ПРОДУКТЫ / ПУТЕШЕСТВИЯ
Платформы для выхода на рынок (ориентированные на бизнес)
Ежедневные банковские операции Карты для ипотеки и HELOC
Экономия, инвестиции
Ежедневные советы по инвестированию
Институциональное богатство Розничное богатство
Путешествие E2E 1
E2E Путешествие 2
E2E Путешествие 3
...
Путешествие E2E 1
E2E Путешествие 2
E2E Путешествие 3
...
E2E Путешествие 1
E2E Путешествие 2
E2E Путешествие 3
...
E2E Путешествие 1
E2E Путешествие 2
E2E Путешествие 3
...
E2E Путешествие 1
E2E Путешествие 2
E2E Путешествие 3
...
Корпорация.
Оплата как услуга
Управление данными.
Корпоративные услуги
Опыт коллег
Соответствие требованиям
Включение
Обеспечение
Платформа и практические инструменты
Инфраструктура
Данные как услуга (DaaS) Оплата как услуга
Защита (кибер, AML, мошенничество)
Операции и риски
CX
Вовлечение клиентов
Обслуживание
Основной продукт Кредит
Фронт-офис eTrading
Цифровой клиент
Операции жизненного цикла. Инновационная ликвидность
Общий
ПЛАТФОРМЫ
Обеспечение Предприятие
платформы
Модель P&P отличается от цифровой фабрики по трем параметрам:
Вся ИТ-функция реорганизуется: специалисты по разработке и сопровождению приложений обычно входят в состав продуктовых подразделений, а специалисты по инфраструктуре и основным системам - в состав платформенных подразделений.
Технологии подвергнутся серьезной модернизации, чтобы полностью раскрыть потенциал цифровых технологий. Это означает переход к более модульной архитектуре, использование новых возможностей, предоставляемых облачными технологиями, и внедрение современных методов разработки программного обеспечения (подробнее об этом читайте в четвертом разделе, посвященном технологиям).
По мере того как компании увеличивают число agile-подразделений, функции контроля, такие как управление рисками, кибербезопасность и обеспечение соответствия, становятся препятствующим фактором, поскольку они подключаются к процессу agile-разработки с опозданием, заставляя подразделения переделывать работу. Или, что еще хуже, компании пытаются обойти эти функции в стремлении к большей скорости, но ценой неконтролируемых рисков. В модели P&P продуманная интеграция функций контроля является неотъемлемой частью модели, иначе она не сможет масштабироваться (см. боковую панель).
Когда компании переходят на модель P&P, они принимают важное стратегическое решение о перестройке крупных подразделений организации для более эффективного использования технологий в своей основной деятельности. Переход на новую модель обычно занимает от одного до двух лет, в зависимости от размера компании, и еще от одного до двух лет для достижения полной операционной зрелости. Это серьезное обязательство, которое может взять на себя только генеральный директор - в тесном взаимодействии с руководством компании.
Основная задача при внедрении модели P&P - перейти на новую модель, продолжая вести бизнес. Для этого необходимо иметь четкий план целевой модели и хорошо отлаженный процесс мобилизации и запуска капсул с правильными ОКР, надлежащим персоналом, финансированием и гибким управлением. Это буквально случай управления самолетом во время его строительства.
Мы считаем, что модель P&P станет доминирующей в отраслях, где технология является основным фактором, определяющим производительность.
Как внедрить функции контроля в команды по разработке продуктов и платформ
Хотя в идеале в каждом agile-подразделении есть выделенные ресурсы функции контроля, на практике это невыполнимо. Первое, с чего следует начать, - это возложить на подразделения ответственность за свои риски в качестве первой линии обороны. Это позволит избежать проблемы "не моя работа", которая может привести к небрежной работе подразделений.
Умелые команды могут внедрить процесс комплексной оценки рисков. Эта оценка охватывает все риски (включая риски третьих сторон, соблюдения нормативных требований, юридические, нормативные и т. д.) и часто поддерживается, по крайней мере на начальном этапе, специалистами по управлению рисками, чтобы обеспечить ее правильное проведение (см. Рисунок 14.6). В зависимости от уровня и типа риска оценка автоматически приводит к привлечению специализированных контрольных функций (вторая линия защиты).
Как управление рисками встроено в гибкую операционную модель
Пример американского банка
Капсулы (первая линия обороны)
Функции контроля (вторая линия обороны)
Ведущий домен
Профессионалы в области управления рисками
Соответствие требованиям
Надзор за рисками
Главный специалист по соблюдению нормативных требований
Владелец продукта
Владелец продукта
Специалист по рискам
Владелец продукта
Владелец продукта
Владелец продукта
Кредит
Процентная ставка Ликвидность Цена
Операционная кибербезопасность
Главный кредитный директор
Руководитель отдела рыночных рисков
Надзор за ОУР
Проводит оценку рисков при планировании выпуска и при необходимости привлекает специалистов по рискам второй линии
Стратегические технологии борьбы с мошенничеством
Другие
ПРИЛОЖЕНИЕ 14.6
Обсуждение рисков должно быть частью регулярных agile-церемоний, чтобы обеспечить своевременное устранение рисков. В ходе этих церемоний команды обеспечивают четкое распределение ролей между подразделениями (первая линия защиты) и функциями контроля (вторая линия) в управлении конкретным риском (см. Рисунок 14.7).
Как оценка рисков включается в процесс разработки
МОНИТОРИНГ
Каждый квартал
1
Идентификация рисков
Первоначальная оценка
(при необходимости)
Оценка рисков на основе всеобъемлющей таксономии рисков для выявления рисков на гранулированном, эпическом уровне
Автоматические триггеры для привлечения
2
Назначение специалистов по рискам
специализированные функции управления
Специалисты по рискам назначаются для
совместная разработка/консультирование мер по снижению рисков
Во время спринта
3
4
Уточненная оценка рисков
Оценка риска может быть проведена повторно, чтобы обновить идентификацию и рейтинг риска по мере получения большей ясности в отношении эпической ситуации
Рабочий процесс по снижению рисков
Выявление и автоматическое формирование историй по снижению рисков в бэклог подсистемы
Приборная панель
Мониторинг уровня рисков и их снижение на протяжении всего жизненного цикла
5
Смягчение последствий выполнено
Истории, назначенные членам стручков, бизнесу или рискам
профессионалов для выполнения мер по снижению воздействия
После спринта
7
Отчетность и соблюдение требований
Документирование действий по снижению рисков для обеспечения соответствия требованиям и ретроспективное обсуждение спринта
Отчеты о соблюдении требований
Автоматически создаваемые и настраиваемые отчеты
ПРИЛОЖЕНИЕ 14.7
Лучшие компании не только оцифровывают процесс выявления рисков, но и автоматизируют контроль над ними ("безопасность как код"). Своевременное устранение существенных рисков - важная составляющая достижения скорости. Этот вопрос подробно рассматривается в главе 22.
Модель гибкости в масштабах предприятия
Преимущества небольших, разнообразных, ориентированных на клиента и наделенных полномочиями команд не ограничиваются разработкой цифровых решений. Практически любая бизнес-функция (например, продажи, НИОКР, маркетинг или разработка продукции) или функция поддержки (HR или финансы) может перенять и извлечь пользу из тех же менталитетов и методов работы для достижения большей производительности и удовлетворенности сотрудников.
Однако при внедрении agile за пределами цифровых/IT-команд требуются новые конструкции agile-команд, не ограничивающиеся междисциплинарными группами, а соответствующие специфике выполняемой работы (см. рис. 14.8). Например, самоуправляемые команды часто используются в контакт-центрах для обеспечения сквозной ответственности за результаты работы с клиентами и затраты, что способствует постоянному совершенствованию. Пул функциональных экспертов "от потока к работе" используется, когда функция (например, финансовая, кадровая, юридическая и т. д.) хочет гибко направить свои ресурсы на удовлетворение самых насущных потребностей, часто в бизнес (это называется "от потока к работе", потому что ресурсы "текут" туда, где есть "работа"). Наконец, "сетевые команды" часто используются в сетях дистрибуции и продаж/магазинов, чтобы обеспечить координацию и согласование на ежедневном уровне при меньшей иерархии и большем практическом руководстве.
Компании, перешедшие к полномасштабной корпоративной модели agile, такие как ING, Spark NZ или Walmart (Мексика), сосредоточились на переосмыслении всей организации как сети высокопроизводительных команд, каждая из которых стремится к четкому, ориентированному на конечный результат бизнесу и обладает всеми необходимыми навыками для его достижения.5
На рис. 14.9 показан планшетный вид корпоративной модели agile для оператора связи среднего размера. Он развернул команды сетевых элементов в дистрибуции каналов, чтобы выровнять организацию и ускорить обмен передовым опытом. В контакт-центрах были развернуты самоуправляемые команды для повышения ответственности за обслуживание клиентов, что дало впечатляющие результаты. В области корпоративных функций использовалась модель "поток - работа", позволяющая быстрее перераспределять ресурсы на критически важные проекты. Наконец, основной бизнес был организован в кросс-функциональные группы (или стручки), как мы описывали их ранее в модели P&P.
Четыре архетипа гибких подразделений
МЕЖФУНКЦИОНАЛЬНЫЕ ПОДРАЗДЕЛЕНИЯ
САМОУПРАВЛЯЕМЫЕ КОМАНДЫ
Пример: Продуктовые команды (pods)
Используется на цифровом заводе, а также в P&P
Пример: Контактный центр
Каждая команда отвечает за комплексное обслуживание определенной группы клиентов.
Руководство владельцем продукта
Маркетинг
Под 1
Под 2
Под 3
Под 4
Под 5
Наука о данных
Инженерия данных
Дизайн
FLOW-TO-WORK
Пример: Функциональные эксперты
Направлены в команды с наиболее острыми потребностями
Управление на основе KPI
Команда 1
Команда 2
Команда 3
СЕТЕВЫЕ ЭЛЕМЕНТЫ
Пример: Рассылка
(магазины, отделы продаж)
Координация света
Специальные проектные группыЭксперты по бассейнам
Команда 1
Ежедневные встречи
Команда 2
Команда 3
Проектная группа 1
Функциональные эксперты
Проектная группа 2
Проектная группа 3
ПРИЛОЖЕНИЕ 14.8
Эта модель позволила сократить общее количество сотрудников более чем на 20 %, при этом повысив уровень удовлетворенности клиентов и общий доход на одного клиента. Что немаловажно, этот результат был достигнут при одновременном повышении удовлетворенности сотрудников, которая достигла уровня NPS +78 через три года после преобразований (по сравнению с +22).
Ускоренная операционная модель в масштабах всего предприятия
Оператор связи среднего размера
Организационные блоки Agile
Многофункциональные капсулы
Самоуправляемые команды
Пулы "поток - работа
Элементы сети
Подразделения по распределению и доставке товаров по каналам
Каналы и подразделения доставки
Розничные магазины
Бизнес-центры
Продажи и продажи и
Сервис ЮгСервис Север
Профессионалы Полевые услуги ДоставкаДоставка
Сервис Выставление счетов и взыскание задолженности
Операции Операции
Контактные центры
Контактные центры: Регистрация/использование
Контактные центры: Премиум
Контактные центры: Аутсорсинг
Возможность выставления счетов
ИТ-путь к производству
Эволюция сети
Физическая инфраструктура
IT
Приложения
Безопасность
Сеть и инфраструктура
Данные и автоматизация
Функции
Домен канала
Мобильный
Сегментные домены
Домены продуктов
Широкополосная связь
Цифровые услуги
Голос и совместная работа
Управляемые данные
IT
Услуги
Оптовая торговля
Бизнес
Потребитель
Платформы Домены
Omnichannel
Домены
Управление стоимостью
Бренд и корпорация. Comms
Agile
Юридическая
Нормативные документы
HR
Финансы
ПРИЛОЖЕНИЕ 14.9
Одна из самых сложных задач при внедрении модели в масштабах предприятия - прояснить, как организация создает ценность и где и как agile может изменить ситуацию (например, обеспечить работу между функциями). Операционная модель agile в масштабах предприятия подходит не каждой компании. Мы считаем, что она может быть успешно внедрена в компаниях, где клиентоориентированность, сотрудничество и ресурсы, гибкость развертывания - это отличительная черта производительности для приложений, требующих больших технологических затрат.
Примечания
Сомеш Кханна, Надежда Константинова, Эрик Ламарр и Вик Сохони, "Добро пожаловать на цифровую фабрику: Ответ на вопрос, как масштабировать цифровую трансформацию", McKinsey.com, 14 мая 2020 г., https://www. mckinsey.com/capabilities/mckinsey-digital/our-insights/welcome- to-the-digital-factory-the-answer-to-how-to-scale-your-digital- transformation.
Раг Удд, "Повышение скорости создания стоимости с помощью цифровых фабрик", BHP, 4 мая 2020 г., https://www.bhp.com/news/prospects/2020/05/pushing- the-velocity-of-value-with-digital-factories; Уилл Эрнандес, "Почему Scotia- bank строит "цифровые фабрики"", American Banker, 18 октября 2019 г., https://www.americanbanker.com/news/why-scotiabank-is- building-digital-factories#:~:text=Мы%20хотели%20построить%20воспроизводимое,могли%20сделать%20реально%20хорошее%20программное обеспечение.
Таня Чхабра, "Бизнес-модель Amazon | Как Amazon зарабатывает деньги?", Feedough, 21 февраля 2023 г., https://www.feedough.com/ amazon-business-model/; Бьянка Чан и Картер Джонсон, "JPMorgan добавляет 25 "мини-директоров" в рамках масштабного плана по увеличению численности 50-тысячной технологической организации и переводу банка на работу, более похожую на стартап", Business Insider, 15 апреля 2022 г., https://www
.businessinsider.com/insider-jpmorgans-massive-shift-product-oriented-
Оливер Боссерт и Дрик Десмет, "Игра на платформе: Как работать как технологическая компания", McKinsey.com, 28 февраля 2019 г., https://www. mckinsey.com/capabilities/mckinsey-digital/our-insights/the- platform-play-how-to-operate-like-a-tech-company.
См. "Проворная трансформация ING", McKinsey Quarterly, 10 января 2017 г., https://www.mckinsey.com/industries/financial-services/our-insights/ ings-agile-transformation; "All in: От восстановления к гибкости в Spark New Zealand", McKinsey Quarterly, June 11, 2019, https://www.mckinsey. com/industries/technology-media-and-telecommunications/our- insights/all-in-from-recovery-to-agility-at-spark-new-zealand; "Финансовый отчет и отчет ESG за 2020 год", Walmart (Мексика), 31 декабря 2020 года, https://informes.walmex.mx/2020/en/pdfs/2020_Financial_and_ESG_ Report.pdf.
Глава 15.
Pr
профессионализация управления продуктами
Хотя внедрение гибкой операционной модели требует от компаний развития множества способностей (как описано в главах 13 и 14), две из них заслуживают более пристального внимания в силу своей важности: управление продуктами и проектирование клиентского опыта (о чем пойдет речь в главе 16). Решающим отличием многих технологических компаний от их коллег из других отраслей является степень внедрения этих возможностей - наряду с культурой разработки программного обеспечения и использованием данных и аналитики - в их работу.
Создание глубины управления продуктами обычно является одной из основных целей переквалификации в ходе цифровой трансформации и трансформации с использованием искусственного интеллекта. Есть две основные роли: владелец продукта, который руководит подсистемами, и старший специалист по продукту, владелец, который возглавляет группу подсистем или домен. Владельцы продуктов абсолютно незаменимы, поскольку сочетают в себе важнейшие операционные и стратегические навыки, в том числе: понимание потребностей бизнеса, глубокое понимание клиента и прочное знание технологий (см. Рисунок 15.1).
Навыки великого владельца продукта
Основы работы с клиентами
Ориентация на рынок
Деловая хватка
Технические навыки
Мягкие навыки
Способность разрабатывать ориентированный на клиента опыт на протяжении всего пути принятия решения покупателем
Способность глубоко понимать тенденции рынка, партнерские экосистемы и конкурентные стратегии
Удобство работы с бизнес-стратегией, приоритизация портфеля,
продвижение на рынок, ценообразование, отслеживание ключевых показателей эффективности и финансовых показателей
Способность глубоко вникать в технологические тенденции, архитектурные вопросы, контрольные точки стека, дорожные карты и управление жизненным циклом разработки.
Способность руководить командами, общаться с различными группами и влиять на изменения в организации.
ПРИЛОЖЕНИЕ 15.1
Многие называют эту роль "мини-CEO" с точки зрения широты обязанностей и требуемых навыков. По этой причине управление производством быстро становится новым местом для ротации лучших бизнес-талантов, а также местом, где многие нынешние руководители технологических компаний обретают свои зубы.
Но слишком мало компаний имеют необходимые возможности для управления продуктами. Около 75 % руководителей компаний, участвовавших в анализе McKinsey, ответили, что передовые методы управления продуктами не применяются в их компаниях, что управление продуктами - это только зарождающаяся функция в их организации или что ее вообще не существует.1
По их словам: Переход в мир управления продуктами
Для нас самой большой проблемой исторически был переход от мира финансовых продуктов к миру управления продуктами. Человек, который знает все о депозитных счетах, кредитных картах или займах, может прекрасно разбираться в тонкостях и требованиях конкретного продукта. Но это не значит, что такой человек всегда будет лучшим менеджером продукта или владельцем продукта, когда дело дойдет до работы с agile scrum-командой и вывода продукта на рынок, подготовки бэклога или определения приоритетов. Это эволюция.
Мы видели, как некоторые из этих людей принимали его, делали потрясающие повороты в карьере и становились фантастическими менеджерами по продуктам. Но, как и в любом другом деле, вы должны быть учеником игры, вы должны учиться и быть открытым для обучения. Те, кто воспользовался этой возможностью, добились больших успехов. Но нам также приходилось нанимать сотрудников, потому что нужно привносить в организацию примеры, на которых могли бы учиться другие. Также важно понимать разнообразие мышления и культуры.
-Кен Мейер, директор по информации и опыту компании Truist
Работая в тесном сотрудничестве с руководителями доменов и дизайнерами пользовательского опыта, владельцы продуктов несут полную ответственность за весь жизненный цикл продукта - от сбора информации о клиенте до разработки решения и его внедрения. Владелец продукта отвечает за выполнение конкретного набора четких OKR, которые он оценивает и пересматривает во время QBR, где приоритеты могут меняться. Они знают, как направлять разработку технически сложных решений, следить за тем, чтобы agile-подразделения работали над правильными проблемами клиентов/пользователей, и создавать инновационные решения этих проблем. Важно отметить, что владельцы продуктов отвечают за весь свой бэклог, включая базовые задачи по обслуживанию, такие как исправление ошибок, а не за создание новых функций продукта. Это обеспечивает их ответственность за качество создаваемых продуктов и помогает сократить технический долг.
Найти человека с широким спектром навыков, необходимых для менеджера продукта, может быть непросто, поэтому подумайте, как обеспечить нужный уровень поддержки. В случае, если владелец продукта чувствует себя менее комфортно. Например, если речь идет о глубоких технологиях, целесообразно укомплектовать группу сильными старшими инженерами, которые будут поддерживать его или ее.
Карьерный рост и профессиональное развитие
Профессионализация функции управления продуктами включает в себя создание ролей и уровней, соответствующих разрядов оплаты и сертификации. Особое внимание следует уделить разработке конкретной карьерной лестницы с расширяющимися обязанностями - отсутствие такой программы карьерного роста может привести к уходу перспективных владельцев продуктов. Как и в случае с карьерным ростом для технологов, о котором говорилось в главе 12, карьерный рост владельца продукта должен отличаться от карьерного роста менеджера и должен уточнять конкретные обязанности и необходимые возможности (см. Рисунок 15.2).
Количество уровней карьерной лестницы зависит от уровня зрелости управления продуктом и технического профиля бизнеса, и оно неизбежно варьируется в разных компаниях - в некоторых компаниях насчитывается до 10 уровней. Названия и обязанности ролей различаются - особенно в технологическом и других секторах - но в целом вводные роли (например, владелец продукта, помощник менеджера продукта) управляют и приоритизируют бэклог команды, основываясь на бизнес-целях, ограничениях команды и ожиданиях заинтересованных сторон. Эти люди помогают определить, над чем должна работать agile-команда.
Более высокие должности (главный директор по продуктам, старший директор, вице-президент) несут широкую ответственность за наиболее важные продукты или их совокупность. Они определяют стратегию для всего портфеля продуктов и несут ответственность за весь жизненный цикл всех продуктов. Их команды могут достигать 5 000 человек, а некоторые из них подчиняются непосредственно генеральному директору.
Продвижение по карьерной лестнице владельца продукта должно быть четко определено, а конкретные навыки должны четко передаваться между ролями. На рисунке 15.3 показан пример развития деловых навыков для владельца продукта.
Экспертные и управленческие карьеры в области управления продуктами
ПУТИ КАРЬЕРНОГО РОСТА
Индивидуальный вклад Менеджер по персоналу
Сотрудники ДО
Владелец продукта
Старший сотрудник отдела кадров
Экспертная трасса
Главный специалист
Заслуженный работник ДО
Управленческий трек
Вице-президент по продуктам
Группа PO
Директор по продуктам
Ассоциированный специалист
РОЛИ И ОБЯЗАННОСТИ
Экспертный трек: Заслуженный специалист
Руководящая должность: Директор по продукту
Сфера ответственности
Организационное влияние
Работает над передовыми технологиями, продуктами или клиентским опытом.
Работает над флагманскими или стратегическими продуктами, сталкивающимися с жесткой конкуренцией
Работает над стратегическими продуктами, важными для критически важных клиентов (B2B), руководителей и членов под
Способность заручиться поддержкой высшего руководства различных подразделений в отношении видения и идей, касающихся новых продуктов.
Способность создавать и возглавлять кросс-функциональную команду "рок-звезд".
востребован другими сотрудниками ДО и коллегами как наставник и педагог
Помогает в наборе, удержании и обучении коллег по ДО и инженеров
Работает над управлением рентабельностью флагманского продукта или группы продуктов (или маршрута).
Руководит работой над несколькими функциями или продуктами, обеспечивая видение и управление производительностью
Способность заручиться поддержкой старшего руководства в различных сферах деятельности
Способность управлять бюджетом для реализации конкретных проектов и идей
Способность создавать, обучать и управлять эффективностью работы команды ДО
Обучает своих коллег по ДО и других коллег передовым методам работы
Отвечает за набор, удержание и обучение сотрудников ДО
Влияние на рынок
Представляет идеи и является автором публикаций на технические темы
Развивает прочные отношения с экосистемой - разработчиками OSS, партнерами и т. д.
Легко доносит видение продукта до клиентов и партнеров и привлекает первых последователей
Служит внешним лицом продукта/продуктовой группы
Развивает отношения со стратегическими партнерами, влиятельными лицами и клиентами
Легко доносит видение продукта до клиентов и партнеров
Способность привлекать лучшие кадры путем создания привлекательного ценностного предложения для сотрудников
ПРИЛОЖЕНИЕ 15.2
Владелец продукта: система навыков
Важнейшие навыки для сотрудников ДО
КЛИЕНТСКИЙ ОПЫТ
Дизайн-мышление: Подход к решению проблем и принятию решений на основе эмпатии и дизайна
Клиентоориентированность: Фокус на изучении потребностей и болевых точек клиентов для повышения ценности
Вовлечение пользователей и обратная связь: Регулярное взаимодействие с конечными пользователями для получения и реализации отзывов
ОРИЕНТАЦИЯ НА РЫНОК
Тенденции развития отрасли и конкурентов: Знание актуальных рыночных и технологических тенденций, на основе которых разрабатывается стратегия развития продукта
Инновации: Выдвижение инновационных идей и внесение вклада в развитие бизнеса
ДЕЛОВОЙ ДОКУМЕНТ
Видение продукта и дорожные карты: Разработка концепции продукта и итеративной дорожной карты на основе потребностей пользователей
Выход на рынок: Помощь в разработке плана GTM для эффективного роста и внедрения продукта
Расстановка приоритетов: Поддерживайте приоритетность работ и определяйте разумные цели, ориентированные на ценность для пользователей.
Отслеживание воздействия: Определение и отслеживание показателей результатов, которые соответствуют стратегии продукта и бизнес-целям.
ТЕХНИЧЕСКИЕ НАВЫКИ
Планирование и реализация технологий: Совместно с экспертами разрабатывайте осуществимые решения для MVP и релизов
Способы работы: Сделать правильно
компромиссы с командами для непрерывного совершенствования
Управление рисками: Управление рисками, привлечение других людей для согласования результатов и потребностей бизнеса
Управление бэклогами: Создание и управление бэклогом совместно с командой (командами) для удовлетворения потребностей пользователей
ЛИДЕРСТВО В ПРОИЗВОДСТВЕ
Эффективное исполнение: Совместное владение, управление и приоритизация ориентированных на пользователя результатов продукта
Коммуникация: Управление коммуникациями с заинтересованными сторонами и спонсорами
Вдохновляйте и влияйте: Станьте идейным лидером, вызывающим последователей благодаря своим идеям
Развитие персонала: Создание высокоэффективной командной культуры на основе страсти, доверия и сотрудничества
Сотрудничество: Совместное создание функций и содействие согласованию зависимостей между командами для повышения ценности.
РАЗВИТИЕ НАВЫКОВ ПО ОБРАЗЦУ - ВОВЛЕЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ И ОБРАТНАЯ СВЯЗЬ
РАЗРАБОТКА ПРОФЕССИОНАЛ ЭКСПЕРТ
Способность собирать и учитывать некоторые отзывы, не обращая внимания на идеи, которые выбивают план из колеи
Регулярное взаимодействие с клиентами и конечными пользователями, а также анализ некоторых данных с последующим включением в бэклог.
Тесное и последовательное сотрудничество с конечными пользователями и дизайнерами на всех этапах, начиная с разработки идеи продукта и заканчивая его внедрением в эксплуатацию, обеспечивая влияние подтвержденного мнения клиентов на бэклог.
Учитывая важность понимания отрасли и самого бизнеса, владельцы продуктов часто привлекаются из маркетинга, операционной деятельности, НИОКР и ИТ. На самом деле, технические специалисты, интересующиеся бизнесом, являются хорошими кандидатами на роль менеджеров по продуктам. Однако слишком часто компании выбирают на эту роль либо менеджера проекта, либо человека из бизнеса без опыта управления продуктами, при этом его практически не обучают и не поддерживают.
Хорошего владельца продукта не так-то просто воспитать. Требуется время, поддержка и практика - управление продуктом - это ремесло, которому нужно учиться годами. Некоторые загрузочные курсы для владельцев продуктов, длящиеся около восьми недель, могут предложить интенсивное обучение для развития конкретных навыков (например, как разрабатывать опросы клиентов, как создавать OKR, как писать пресс-бриф и FAQ для планируемого продукта и т. д.). Лучшие программы сочетают аудиторные занятия с погружением в процесс обучения, в ходе которого моделируются реальные проблемы клиентов.
На рисунке 15.4 показано, как один банк подошел к проведению тренинга для 300 владельцев продуктов. Программа проводилась в три трехмесячные волны, по 100 владельцев продуктов в каждой. Владельцы продуктов получили возможность применить полученные знания на практике в рамках проекта, который был выполнен при поддержке практического тренера. Обучение включало в себя около 20 часов занятий на четырех аудиторных форумах и еще 20 часов обучения в рамках проекта при поддержке тренера владельцев продуктов.
Такие программы, ориентированные на продукт, могут быть полезны для создания фундамента навыков, но сами по себе они недостаточны. Мы часто видим, как люди, закончив эти программы по развитию навыков, возвращаются в привычную рабочую среду, где они не могут использовать свои новые навыки. Для создания настоящего ремесла управления продуктом необходимо, чтобы команды использовали одни и те же артефакты (например, инструменты и шаблоны), одинаково понимали, за что отвечает владелец продукта, и использовали схожие процессы анализа на встречах QBR.
Программа повышения квалификации по управлению продуктами на местах и в форумах
Пример для финансового учреждения США
Полевой проект (20 часов)
Когорта из ~100 человек; программа выполняется ~3 месяца
ФОРУМ 1
Фаза открытия
ФОРУМ 2
Фаза жизнеспособности I
ФОРУМ 3
Фаза жизнеспособности II
ФОРУМ 4
Этап строительства
Изучение Понимание
цель проблемное пространство и определение видения продукта
Сопереживание пользователю и определение "как" (инновационный, а не инкрементный подход)
Донесение информации о ценности и взаимодействие с клиентами и инженерами
Претворение идеи продукта в жизнь
Форум5 часов обучения Понимание
проблемное пространство
и возможности рынка
Документ о требованиях к рынку
Конкурентный анализ Определение видения продукта
Пресс-релиз и часто задаваемые вопросы
Холст бизнес-модели
Карта дорог
5 часов
Определение приоритетов портфеля (с опорой на данные)
Понимание потребностей пользователей и основных неудовлетворенных потребностей
Персона пользователя (включает методы исследования)
Путешествие как таковое
Определение того, как мы хотим решить проблему неудовлетворенных потребностей
Предстоящее путешествие
Прототип
5 часов
Определение и измерение успеха
Показатели успешности продукта
Цели и основные результаты
Общение и взаимодействие с клиентами
Заявление о позиционировании
Одностраничный продукт
Питч-дек для клиентов
Преобразование идеи продукта в требования
Документ с требованиями к продукту
5 часов
Обзор фазы сборки и подхода к непрерывной разработке
Мышление минимально жизнеспособного продукта
Постоянное уточнение и определение приоритетов
Бэклог продукта
Развитие лидерских качеств - Влияние без полномочий
Обзор и цели демонстрационного дня
Полевая подготовка
Ядро
Навыки ДО
Ориентация на рынок Деловая хватка
Основа для работы с клиентами
Деловая хватка
Основа для работы с клиентами
Технические навыки
Деловая хватка
Основа для работы с клиентами
Мягкие навыки Технические навыки
Мягкие навыки Технические навыки
Деловая хватка
ПРИЛОЖЕНИЕ 15.4
Навыки и возможности владельцев продуктов должны развиваться. Например, владельцы продуктов будущего будут гуру аналитики. Они смогут быстро создать кластер данных в облаке, получить данные об использовании, проанализировать их и сделать выводы. Они будут умело применять концепции машинного обучения и инструменты, специально разработанные для поддержки принятия решений владельцем продукта.
По нашим прогнозам, большинство современных владельцев продуктов будут тратить не менее 30 % своего времени на внешнюю деятельность, например на взаимодействие с клиентами и партнерской экосистемой. Такое взаимодействие не будет ограничиваться потребительскими продуктами - по мере того, как ИТ становится все более популярным, владельцы B2B-продуктов будут напрямую общаться с конечными пользователями, а не добывать обратную связь через многочисленные уровни торговых посредников.
Примечание
1. Чандра Гнанасамбандам, Мартин Харриссон, Джереми Шнайдер и Рикки Сингх, "Что отличает топ-менеджеров по продуктам от остальных", McKinsey.com, 20 января 2023 г., https://www.mckinsey.com/ industries/technology-media-and-telecommunications/our-insights/ what-separates-top-product-managers-from-the-rest-of-the-pack.
Глава 16.
Дизайн клиентского опыта
Вы можете планировать, разрабатывать, нанимать сотрудников и инвестировать, но если клиент - внутренний или внешний - не захочет использовать созданное вами цифровое решение, все это не будет иметь значения. Именно это противоречие - между тем, что нужно пользователям, и тем, что компании хотят запустить или знают, как создать, - делает дизайн клиентского опыта важнейшим компонентом цифровой трансформации и трансформации ИИ, способным стимулировать инновации, внедрение и ценность.1
Каждая компания стремится быть клиентоориентированной. Все они хотят предлагать продукты, опыт и услуги, которые нравятся клиентам или пользователям. Те, кто действительно выделяется на этом фронте, создают несоизмеримо большую ценность. Наши исследования показывают, что компании, ориентированные на дизайн, в течение пяти лет демонстрировали гораздо более высокие темпы роста доходов и TRS, чем их коллеги.2 Дизайн пользовательского опыта, как его чаще всего называют, действует как волшебный ингредиент, добавляемый в цифровой рецепт.
Эта ценность так же реальна для B2B-компаний, как и для B2C. Мы обнаружили, что в тяжелой промышленности дизайн пользовательского опыта (UX) так же важен для того, чтобы операторы на передовой приняли новые цифровые решения. Любой компании, серьезно относящейся к цифровой трансформации и внедрению ИИ, необходимо развивать потенциал UX-дизайна следующими четырьмя способами.
Сначала наймите отличных дизайнеров
Не откладывайте наем дизайнеров. Некоторые компании предпочитают направлять свой бюджет только на наем инженеров. Как правило, это ошибка. После года разработки они обнаруживают, что клиенты/пользователи не принимают разработанное ими решение, потому что оно неудобно в использовании.
Начните с небольшого ядра, возможно, 5-10 CX-дизайнеров, и развивайтесь дальше. Мы обнаружили, что отличных дизайнеров клиентского опыта можно нанять из других отраслей, дизайнерских фирм или даже из аспирантуры. Ведущие учебные заведения все чаще предлагают программы MBA, включающие дизайн-мышление.
Знайте, что вы ищете. Дизайнеры не все одинаковы. Роли дизайнеров, как правило, группируются вокруг четырех компетенций (см. Рисунок 16.1). Прежде чем нанимать и наращивать свой потенциал в области дизайна, четко определите, какие компетенции вам действительно нужны.
Различные компетенции в области дизайна
КЛЮЧЕВЫЕ КОМПЕТЕНЦИИ
ОСНОВНЫЕ МЕТОДЫ*
Дизайн услуг
Умение аналитически разбирать первопричины и вторичные эффекты, возникающие на переднем и заднем этапах предоставления продукта или услуги
Картина бизнес-модели Чертежи, карты экосистемы Матрица приоритетности функций
Умеет мыслить системно, т.е. системное мышление - рассматривать компоненты как часть большого целого
Основы решения проблем
Ведущие семинаров по дизайну
Способность вести переговоры между деловыми, техническими и пользовательскими потребностями и целями для достижения удовлетворительного решения.
Инструменты: Figma, Sketch, Adobe Creative Suite
Исследование дизайна
Навыки проведения качественных исследований, например, контекстных интервью, дневниковых исследований, лонгитюдных исследований работы и т.д.
Руководства по проведению интервью Опросы
Способность проводить опросы и тестирование юзабилити
Personas
Путешествия, карты рабочих процессов
Владение передовыми методами для обеспечения достоверности результатов и обобщения полученных знаний
Анализ путей, с аналитикой
Инструменты: Dovetail, UserTesting.com
Знание и расширение знаний в области аналитики и других методов количественных исследований
UX
дизайн
Опытные специалисты в области дизайна, ориентированного на человека, преимущественно для цифровых решений, но также включающего дизайн услуг
Концепции опыта, модели взаимодействия Информационная архитектура, навигация
Способность разрабатывать последовательные решения, отвечающие потребностям пользователей и соответствующие лучшим практикам
Картинки-прототипы
Инструменты: Figma, Sketch,
Adobe Creative Suite
Визуальный дизайн
Владеет навыками композиционного равновесия, теории цвета, иконографии и т.д.
Владеет шаблонами и системами визуального дизайна, включая, но не ограничиваясь архитектурой бренда
Знание передовых методов разработки визуальных систем и документации
Выражение и расширение бренда Доски настроения, библиотеки активов Рамки дизайна взаимодействия
Модели проектирования Omnichannel Визуальный дизайн
Инструменты: Adobe Creative Suite, Sketch, Invision
* Основные методы не являются исчерпывающими
ПРИЛОЖЕНИЕ 16.1
Инвестируйте в процесс разработки CX-дизайна
Подход к CX-дизайну можно четко определить как процесс, состоящий из двух частей: разработать правильную вещь, а затем разработать правильную вещь.
Создавать правильные вещи - значит выяснять, чего хотят пользователи. Дизайнеры проводят время с пользователями, чтобы выявить потребности так, как это не могут сделать никакие количественные или маркетинговые исследования. Надежные сведения о клиентах, полученные из первых рук путем наблюдения за пользователями в их собственной среде, могут стать мощным способом выявления как функциональных, так и эмоциональных потребностей. Конечно, используйте данные, но не забывайте об эмпатийной стороне уравнения.
Для проведения потребительских исследований существует все больше методик, но они требуют четкого представления о том, какой инструмент лучше всего подходит для той или иной цели (см. Рисунок 16.2).
Способы, с помощью которых дизайнеры получают информацию о неудовлетворенных потребностях клиентов, быстро развиваются. Вы должны быть уверены, что ваша команда дизайнеров в совершенстве владеет этими методами.
Правильное проектирование - вторая часть процесса - возможно только при наличии четкого понимания потребностей клиента и проблемы, которую нужно решить. Не поддавайтесь искушению забежать вперед. Создание прототипа без понимания и согласования первой части процесса неизбежно приводит к задержкам.
Процесс проходит пять этапов, как показано на рис. 16.3. На каждом из этих этапов дизайнеры используют набор инструментов проектирования для создания конечных продуктов. Набор инструментов должен быть стандартизирован для повышения производительности команды и повторного использования рабочих продуктов.
На ранних этапах этого процесса очень важно как можно раньше сделать идеи осязаемыми. Поэтому мы рекомендуем начинать с "быстрых и грязных" вариантов, часто макетов на листе бумаги. Затем быстро протестируйте их на реальных клиентах и переходите ко все более сложным версиям, например, поддельным приложениям, прежде чем остановиться на рабочем продукте для инженеров.
КОЛИЧЕСТВО
QUANTITATIVE
Ответы на вопросы "Почему"
Глубокое понимание поведения и эмоциональных потребностей пользователей
Выявление потребностей, о которых пользователи даже не подозревают Основано на наблюдениях; способность к совместному творчеству с пользователями
Ответы на вопросы "Сколько и как".
Количественная оценка данных и обобщение результатов на основе выборки населения
Основывается на мнениях и подтверждает гипотезы или решения статистически достоверными данными
Несмотря на то, что это отнимает много времени, это почти всегда приводит к ускорению разработки (потому что команды точно знают, что создавать) и улучшению результатов (потому что пользователь получает то, что хочет).
Такие инструменты, как Figma, позволяющие гораздо быстрее создавать прототипы для тестирования высокофункциональных продуктов или услуг без необходимости написания кода, предвещают ускорение проектирования за счет технологий. Новые технологии с низким/отсутствующим кодом и генеративный ИИ, такие как GPT-4, также быстро изменят характер этого процесса разработки. Функциональность Drag-and-drop, которая автоматически генерирует код в фоновом режиме, сокращает время разработки с недель до дней или с дней до часов. Это позволит командам, занимающимся разработкой опыта, получить больше времени для тестирования и доработки своих продуктов и услуг.
Одно из препятствий, с которым часто сталкиваются компании в процессе создания прототипа, - это чрезмерная сосредоточенность на функциях и функциональности при разработке MVP (минимального жизнеспособного продукта). Такой фокус может привести к тому, что прототип будет работать, как ожидалось, но пользователь не будет иметь хороший опыт работы с ним. Вместо этого разработчики должны сосредоточиться на создании "минимально любимого продукта", который фокусируется на том, насколько конечному пользователю нравится пользоваться продуктом или услугой. Например, это может означать, что вместо того, чтобы сужать окна прибытия, которые может предложить оператор (например, для прокладки кабеля), компания сосредоточится на том, чтобы сообщать клиенту о том, что сервисный специалист находится поблизости, что клиент оценит больше.
Ориентация на удовлетворение потребностей пользователей приводит к более широкому использованию созданных продуктов или услуг, упрощению приложений и опыта, значительному сокращению малозначимых функций и улучшению финансовых показателей.
Сделайте UX-дизайн частью вашей команды с самого начала
Специалисты по CX и дизайну должны быть основными участниками agile-подразделений с самого начала. Однако слишком часто бизнес-спонсоры думают, что они знают потребности клиентов, и поэтому считают, что дизайнеры им не нужны до тех пор, пока они не приступят к процессу разработки. Это ошибка. Лучшие в своем классе организации обеспечивают великолепные впечатления клиентов, внедряя дизайн в каждый аспект разработки продукта или услуги.
Дизайнеры направляют процессы разработки, например, обеспечивая участие клиентов на протяжении всех спринтов, разрабатывая концепции, создавая основные артефакты опыта, такие как персоны и пользовательские маршруты (серии взаимодействий для достижения цели), и обеспечивая их использование командой в процессе разработки продукта. Они составляют карту каждого пути клиента с упором на выявление болевых точек и потенциальных источников удовольствия, а не начинают с "копирования и вставки" технических спецификаций последнего продукта.
Увязывайте каждый элемент CX-дизайна с ценностью
Лучшие компании глубоко сосредоточены на том, чтобы связать клиентский опыт с ценностью. Разрабатывая карты путешествий, команды определяют и связают точки этих путешествий с ключевыми показателями эффективности бизнеса и генерируемой им ценностью. Например, улучшение взаимодействия банка с клиентами в рамках пути клиента приведет к улучшению качества обслуживания клиентов и, следовательно, к снижению оттока. Такой анализ позволяет разработчикам определить, где кроется наибольшая разница в ценности.
Эти показатели не для показухи. Вы должны оценивать эффективность дизайна с той же строгостью, с какой отслеживаете доходы и расходы. Теперь компании могут включать показатели дизайна (например, рейтинги удовлетворенности и оценки удобства использования) в спецификации продукции, так же как они включают требования к маркам материалов или целевому времени выхода на рынок.
Примечания
См. "Повышение влияния на бизнес за счет клиентоориентированности и цифровой гибкости", McKinsey.com, 30 июля 2021 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/driving-business-impact- through-customer-centricity-and-digital-agility.
Бенедикт Шеппард, Хьюго Сарразин, Гарен Куюмджян и Фабрисио Доре, "Бизнес-ценность дизайна", McKinsey Quarterly, 25 октября 2018 г., https://www.mckinsey.com/capabilities/mckinsey-design/ our-insights/the-business-value-of-design.
Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:
Согласны ли руководители высшего звена с операционной моделью, позволяющей сотням подразделений внедрять цифровые инновации?
Соответствуют ли OKR для каждого подразделения приоритетам бизнеса?
Являются ли "контрольные функции" (например, финансовые, юридические, регуляторные) частью вашего гибкого процесса наряду с бизнесом и технологиями?
Каким образом ваши финансовые и управленческие процессы согласованы для обеспечения более гибкой операционной модели?
Как вы оцениваете достижения в скорости и маневренности, которые делает ваша организация?
Сколько ваших команд и решений возглавляет высококлассный владелец продукта?
Входят ли специалисты по клиентскому опыту и дизайну в состав ваших agile-команд, и достаточно ли рано они вовлечены в процесс?
Технологии для скорости и распределенных инноваций
В самом простом виде цель технологии заключается в том, чтобы упростить для ваших подразделений постоянную разработку и выпуск цифровых и искусственных инноваций для клиентов и пользователей. Для достижения этой цели необходимо создать распределенную технологическую среду, в которой каждое подразделение сможет получить доступ к данным, приложениям и инструментам разработки программного обеспечения, необходимым для быстрого внедрения инноваций и предоставления безопасных и высококачественных решений.
Последние и зрелые технологические достижения - в том числе продуманное использование API для разделения приложений, доступность инструментария для разработчиков, выборочный перенос важных рабочих нагрузок в облако и автоматизация предоставления инфраструктуры - могут создать такую распределенную среду.
У тех, кто не имеет отношения к технологиям, может возникнуть соблазн пропустить этот раздел. Не стоит! Вам необходимо знать основы технологий, чтобы стать эффективным лидером в цифровом мире. Хотя этот раздел посвящен некоторым особенностям быстро развивающегося технологического ландшафта, в нем также освещены наиболее важные вопросы и темы, которые необходимо понять, чтобы стать эффективным цифровым лидером.1
Для создания технологической среды, способной поддержать цифровую трансформацию, необходимы семь широких возможностей:
Глава 17: Отсоединенная архитектура для гибкости разработки и операционной масштабируемости. Всеобъемлющие принципы проектирования и варианты построения развязанной архитектуры, которая позволит вашим подсистемам внедрять инновации за счет минимизации зависимостей - поздоровайтесь с API.
Глава 18: Более оперативный и ценностный подход к облаку. Сосредоточьтесь на значимых областях бизнеса при переносе приложений в облако, чтобы обеспечить максимальную рентабельность инвестиций в облако.
Глава 19: Инженерные практики для скорости и качественного кода. Автоматизация разработки и развертывания программного обеспечения является основой для создания и выпуска высококачественного программного обеспечения.
Глава 20: Инструменты, которые сделают ваших разработчиков высокопродуктивными. Создайте платформу для разработчиков, чтобы облегчить работу всех инженеров и избежать распространения инструментов.
Глава 21: Поставка цифровых решений производственного уровня. Создание условий для безопасной, контролируемой и масштабируемой среды производства с помощью автоматизации.
Глава 22: Встраивание безопасности и автоматизации с самого начала. Автоматизация проверок безопасности на протяжении всего процесса разработки программного обеспечения. Это ускоряет общую скорость разработки и гарантирует, что все цифровые решения будут безопасными и надежными.
Глава 23: MLOps, чтобы ИИ мог масштабироваться. Модели AI/ML - это "живые организмы", которые требуют мониторинга и постоянного переобучения данных. Именно поэтому для масштабирования ИИ необходимы инструменты автоматизации MLOps.
Примечание
1. Томас Элснер, Питер Майер, Герард Рихтер и Катя Цолпер, "Что нужно ИТ-директорам от руководителей компаний и советов директоров, чтобы сделать ИТ готовыми к цифровым технологиям", McKinsey. com, 1 декабря 2021 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/what-cios-need-from-their-ceos-and- boards-to-make-it-digital-ready; Steve Van Kuiken, "Boards and the cloud," McKinsey.com, November 18, 2021, https://www.mckinsey.com/ capabilities/strategy-and-corporate-finance/our-insights/boards-and- the-cloud.
Глава 17.
Раздельная архитектура обеспечивает гибкость разработки и масштабируемость операций
Архитектура платформы поддерживает системы взаимодействия (front end) и системы учета (back end), а также данные и аналитику, необходимые для разработки решений и управления цифровыми преобразованиями и ИИ. Лучшие архитектуры обеспечивают гибкость, стабильность и скорость, чтобы гибкие подразделения по всей организации могли создавать решения, необходимые для реализации цифровой дорожной карты. Ключевая концепция заключается в том, что распределенная и разрозненная архитектура необходима для того, чтобы команды могли собирать модульные и многократно используемые компоненты (см. Рисунок 17.1).
Четыре основополагающих изменения для модернизации архитектуры для цифровых технологий
Системы взаимодействия
Унифицированное ядро данных и аналитики
Системы учета
3 От фиксированного к эволюционирующему
Приложения
API и платформа управления
1
Данные
От точки к точке к развязке
Продукты данных
Хранилище данных (по доменам)
Аналитика
Хранилище необработанных данных
Потоковая передача в реальном времени
4
От пакетной обработки данных к обработке данных в режиме реального времени
Основные системы обработки данных
Физические каналы
CRM
Веб-сайт
Мобильный
2
ПРИЛОЖЕНИЕ 17.1
Команда по архитектуре предприятия определяет общую философию архитектурного проектирования и выбор для всех agile-подразделений предприятия, а также инженерные практики, которым должны следовать эти agile-подразделения.
Для создания такой архитектуры необходимо принять "облако" в качестве технологической основы (подробнее об этом в главе 18) и обеспечить следующие четыре ключевых изменения в его работы.
От точки к точке к развязке
С точки зрения архитектуры, развязка (буквальное разделение связей между точками одной системы и другой) позволяет организации развивать свои приложения независимо друг от друга, что повышает гибкость и способность организации к масштабированию. Для развязки используются следующие две техники.
Принять интерфейсы на основе API, но управлять их распространением
Интерфейсы прикладного программирования (API) позволяют капсулам предоставлять свои данные и функции приложений другим капсулам в рамках предприятия или внешним клиентам или партнерам. По сути, API позволяют разбить крупные монолитные приложения на микросервисы. Этот сдвиг является фундаментальным краеугольным камнем, позволяющим сотням капсул внедрять инновации, не сталкиваясь с постоянными зависимостями от других капсул.
Джефф Безос из Amazon известен своей служебной запиской, которая изменила Amazon и мир программного обеспечения1. По сути, в ней говорилось следующее:
Все команды будут предоставлять свои данные и функциональность через сервисные интерфейсы (т.е. API), и команды должны взаимодействовать друг с другом через эти интерфейсы.
Никакие другие формы межпроцессного взаимодействия не допускаются: ни прямое связывание, ни прямое чтение хранилища данных другой команды, ни модель общей памяти, ни какие бы то ни было бэкдоры. Единственное, что разрешено - это взаимодействие через вызовы сервисных интерфейсов по сети.
Неважно, какую технологию они используют. HTTP, Corba, Pub- sub, пользовательские протоколы - неважно. Безосу все равно.
Все без исключения интерфейсы сервисов должны быть с нуля спроектированы таким образом, чтобы их можно было использовать для внешних целей. Иными словами, команда должна планировать и проектировать так, чтобы иметь возможность открыть интерфейс для разработчиков во внешнем мире. Никаких исключений.
Тот, кто этого не сделает, будет уволен.
API упрощают интеграцию между приложениями, ограждая команды разработчиков от сложности различных уровней, что ускоряет выход на рынок и снижает вероятность возникновения новых проблем в существующих приложениях. Эти интерфейсы также позволяют легче заменять отдельные компоненты при изменении требований.
Однако, учитывая эти преимущества, компании склонны создавать слишком много API. Зачастую массовое распространение API столь же вредно, как и распространение веб-сервисов и даже интерфейсов "точка-точка" в унаследованных архитектурах. Сведите к минимуму количество API и оптимизируйте их использование. API - это абсолютный ключ к развязке, но ими нужно управлять2.
Представление и удобство использования API-интерфейсов имеют решающее значение для использования их преимуществ. Используйте платформу управления (часто называемую шлюзом) для создания и публикации API, внедрения политик использования, контроля доступа, измерения использования и производительности. Такая платформа также позволяет agile-подразделениям искать существующие API и использовать их повторно, а не создавать новые. Внедрите стандарты, рекомендации и таксономию, чтобы обеспечить последовательное создание и использование API.
Одна фармацевтическая компания, например, создала внутренний "рынок данных" для всех сотрудников с помощью API, чтобы упростить и стандартизировать доступ к основным информационным ресурсам, а не полагаться на собственные интерфейсы. Компания постепенно - в течение 18 месяцев - перевела наиболее ценные существующие потоки данных в структуру, основанную на API, и развернула платформу управления для предоставления API пользователям. Такая архитектура корпоративных данных позволила значительно ускорить разработку и внедрение инноваций, основанных на аналитике и искусственном интеллекте.
По их словам: Трансформация API
"[Сначала мы определили приоритетность наших API, структурировав] существующие сервисы в нашей корпоративной сервисной шине (ESB) по стандартным банковским доменам, таким как клиент и продукт. Мы также определили приоритетность некоторых небанковских
API как "общие" или "для взаимодействия с каналами", например, кампании, предложения и функции оптического распознавания символов (OCR).
Затем мы определили приоритетность сервисов, исходя из их актуальности для нашей трансформации - то есть когда нам нужно будет отсоединить каждую ИТ-платформу для модернизации, - а также уровня сложности. Основываясь на этих критериях, мы смогли лучше понять, каковы будут общие усилия по "API-зации" нашей ИТ-архитектуры. Затем мы приступили к описанию операционной модели и управления, а также к детализации таксономии API, стандартов и рекомендаций. Наконец, мы определились с технологическим решением для платформы управления API и другими соответствующими компонентами и приступили к первой пробной версии концепции.
Мы объяснили руководству важность и потенциал API как для технологий, так и для бизнеса и выделили на это значительную часть бюджета. Начального финансирования хватило, чтобы заложить технологическую основу, определить необходимые стандарты и политики и перевести все наши сервисы с устаревшего ESB на микросервисы, доступные через наши стандартные API. Сейчас у нас доступно около 800 микросервисов.
Эта основа позволила нам создать три agile-отряда, которые занимались исключительно созданием API в различных областях. Мы начали работу над API, проведя несколько информационных сессий по API в ИТ-отделе, а также распространили информацию среди наших коллег по бизнесу, чтобы помочь нашим сотрудникам понять возможности.
Чтобы стимулировать внедрение API, было очень важно создать удобный портал для разработчиков с хорошей документацией и достаточными функциями поиска. Мы изучили лучшие мировые практики. Кроме того, мы вложили средства в обучение наших разработчиков, чтобы с самого начала ознакомить их с порталом для разработчиков, а также с руководящими принципами и стандартами API. Мы хотели заложить правильный фундамент, чтобы в нужный момент можно было легко масштабировать компанию.
После первых небольших успехов в решении внутренних и внешних задач потребность бизнеса значительно возросла. Им нужны были дополнительные API, причем быстро, поэтому мы разработали гибкий процесс бюджетирования и определения приоритетов, чтобы удовлетворить возросший спрос.
Одной из наших главных задач было найти подходящих специалистов для работы с API. Полностью переработать архитектуру интеграции, создать платформу управления API и портал для разработчиков, а также постоянно расставлять приоритеты в первоначальном бэклоге API - это очень сложные задачи. С одной стороны, нам нужны были опытные инженеры, разбирающиеся в технологических деталях, а с другой - опытные владельцы продуктов, чтобы обеспечить лазерную фокусировку на правильных приоритетах.
Вначале было много опасений по поводу того, что в Дубае удастся сформировать необходимый кадровый резерв, поскольку технологические кадры не так легко найти. Однако нам удалось добиться этого благодаря сбалансированному сочетанию найма и развития имеющихся талантов. Одним из ключевых элементов нашего успеха стало создание специализированных учебных программ для различных необходимых нам ролей с сочетанием внутренних и внешних курсов, а также программ сертификации.
Позже мы столкнулись с проблемой повышения производительности наших agile API-отрядов. Когда мы начинали, для наших команд было приемлемо создавать один API за два-три недельных спринта. Однако, чтобы следовать нашей дорожной карте, нам нужно было значительно повысить производительность. Мы использовали инструменты автоматизации DevOps для оптимизации интеграции и обеспечения непрерывного развертывания и доставки и удвоили объем выпускаемых API".
-Сауд Аль Дхавиани, директор по технологиям, Emirates NDB
Использование облачной платформы данных. Платформа данных "буферизирует" транзакции вне основных систем. Она объединяет данные для аналитически интенсивных приложений и обеспечивает асинхронное использование данных. Такие буферы могут быть созданы с помощью озера данных или распределенной сетки данных, которая представляет собой экосистему, состоящую из оптимально подходящих платформ, созданных с учетом предполагаемого использования данных и рабочих нагрузок в каждой бизнес-области (см. главу 26 об архитектуре данных).
В более продвинутой архитектуре данных существует дополнительная буферизация с созданием продуктов данных, которые обеспечивают высокое качество данных и упрощенное потребление (см. главу 25 о продуктах данных).
На рисунке 17.2 представлен обзор современной архитектуры приложения, реализованной производителем медицинского оборудования для своего потребительского приложения. Шлюз на входе контролирует входящий трафик и обеспечивает безопасность. Уровень API определяет, какие сервисы приложения запрашиваются. Облачная платформа данных организована как хранилище больших объемов данных в озере данных и более специализированных продуктов данных, готовых к потреблению пользователем или приложением (например, данные о клиенте, медицинском изделии и местоположении для обеспечения соответствия местным нормам).
На рисунке 17.3 показана подробная схема, иллюстрирующая, как была собрана архитектура. Обычно на таком уровне детализации работают архитекторы решений и инженеры полного стека. Эта архитектура была построена в Azure с добавлением лучших в своем классе и/или открытых инструментов. Сопоставление один к одному между примерами 17.2 и 17.3 не должно вызвать затруднений. Все руководители компаний должны понимать архитектуру своего решения на уровне иллюстрации 17.2, а архитекторы и инженеры - на уровне иллюстрации 17.3.
От ручного к автоматизированному с помощью кода. Нельзя недооценивать стоимость ручного создания инфраструктуры или ручной сборки и развертывания программного обеспечения. Этот процесс не только медленный и громоздкий, но и чреват ошибками. Чтобы устранить эти проблемы, ведущие компании внедряют автоматизацию инфраструктуры и автоматизацию доставки программного обеспечения:
Автоматизация создания инфраструктуры. Использование инфраструктуры как кода (IaC) позволяет agile-подразделениям создавать облачные среды, инфраструктуру, хранилища и любые другие необходимые им сервисы повторяемым, экономически эффективным и надежным способом. Явно прописывайте все спецификации инфраструктуры в конфигурационных файлах, чтобы создать "единый источник правды". Это также создает полезный след всех изменений и упрощает возврат к исходному состоянию в случае необходимости.
Современная архитектура приложений1 - обзор
Пример архитектуры потребительского приложения для глобальной компании по производству медицинского оборудования
Места
GraphQL / слой API
Шлюз и входная дверь
Модель 1
Модель 2
Данные о потреблении
Продукты данных
Аналитика / модели искусственного интеллекта
Клиенты Продукция
Модель 3
...
Озерный дом данных
Основные системы / системы учета
Цепь поставок HRS
ERP
...
Сырые данные
...
Курируемые данные
Основные системы/системы учета Системы, обеспечивающие работу основных систем
деловые операции
компания
Чтобы способствовать повторному использованию кода и избежать дублирования, при написании инфраструктурных скриптов обязательно создавайте блоки кода. Создайте простой и удобный способ каталогизации этих высококачественных блоков кода в одном месте, чтобы разработчики могли легко их находить (см. главу 20). Примерами блоков кода IaC в Google Cloud Platform (GCP) может служить настройка службы Cloud Asset Inventory, которая обеспечивает видимость ресурсов для мониторинга, анализа и понимания всех активов в рамках проектов. Другой пример - настройка Compute Engine, сервиса для предоставления высокопроизводительных виртуальных машин в виртуальном частном облаке.
Автоматизируйте доставку программного обеспечения на производство
Автоматизация создания, тестирования, проверки и развертывания программного обеспечения - настолько важная тема, что мы посвятили целую главу обсуждению того, как это делается (см. главу 19).
От фиксированного к развивающемуся
Между строительной отраслью и компьютерной индустрией есть много общего, однако понятие идеальной, заранее спланированной архитектуры до начала разработки не является одним из них. Технологии меняются с огромной скоростью. Технология и архитектура, поддерживающая вашу организацию, будут меняться с течением времени, поэтому очень важно предусмотреть необходимую гибкость. Идея заключается в том, чтобы иметь возможность внедрять новые данные, аналитику и инструменты разработки программного обеспечения без необходимости менять все.
Для этого необходимо перейти к модульной архитектуре, использующей лучшие в своем роде и, зачастую, открытые компоненты, которые при необходимости могут быть заменены новыми технологиями без ущерба для других частей архитектуры. На практике это требует разработки четких стандартов, чтобы предотвратить распространение инструментов с более или менее одинаковой функциональностью, и наличия хорошо продуманных интерфейсов между компонентами, чтобы минимизировать изменчивость и сложность, возникающие из-за системных зависимостей.
Команда по архитектуре предприятия не должна сидеть в башне из слоновой кости вдали от agile-подразделений, а должна тесно сотрудничать с ними, чтобы понять потребности и адаптировать стандарты с течением времени. Это требует от корпоративных архитекторов обсуждения с agile-подразделениями последствий технологических решений для бизнеса. Нанимайте корпоративных архитекторов, которые понимают как эти передовые компоненты и инструменты, так и то, что требуется для создания современного программного обеспечения.
От пакетной обработки данных к обработке данных в режиме реального времени
Стоимость обмена сообщениями и потоковыми данными в режиме реального времени значительно снизилась, что открывает путь к более широкому применению. Эти технологии позволяют создавать множество новых бизнес-приложений. Например, транспортные компании могут информировать клиентов о приближении такси с точностью до секунды; страховые компании могут анализировать поведенческие данные смарт-устройств в режиме реального времени для индивидуализации тарифов; производители могут прогнозировать проблемы оборудования на основе данных датчиков в режиме реального времени. Хотя удельная стоимость обработки данных в режиме реального времени продолжает снижаться, общие затраты могут быть незначительными при работе с большими массивами данных, поэтому важно вдумчиво подходить к выбору цифровых решений, которые действительно нуждаются в таких возможностях.
При подходе к обработке данных в реальном времени необходимо определиться со стандартом обмена сообщениями между приложениями (т. е. платформой обмена сообщениями) и стандартом потоковой передачи данных. Платформы обмена сообщениями предоставляют цифровым приложениям возможность публиковать сообщения, на которые подписаны приложения, способные действовать по мере их получения. На уровне предприятия существует множество вариантов платформ обмена сообщениями (например, Apache ActiveMQ, Apache Kafka, RabbitMQ или Amazon Simple Queue Service). Выбор стандартной платформы обмена сообщениями позволяет цифровым приложениям отправлять и получать дискретные сообщения, не связывая их между собой.
Потоковая передача данных обычно используется для аналитики или обработки данных в реальном времени. Существуют различные виды потоков, например датчики или биржевые сводки, и для каждого из них должен быть свой стандарт. Например, при выявлении мошенничества потоковая передача данных может помочь вам проанализировать и интерпретировать группу транзакций по сравнению с каждой отдельной транзакцией (см. Рисунок 17.4). Как и в случае с платформами обмена сообщениями, существует множество вариантов потоковой передачи данных на уровне предприятия (например, Kafka, Amazon Kinesis, Apache Spark или Apache Flink).
Передача сообщений по сравнению с потоковой передачей
СООБЩЕНИЕ
Сообщение/событие Логика Действие
Входящее электронное письмо
Фильтр спама Отправкав папку нежелательной почты, если письмо распознано как спам.
СТРИМИНГ
Группа сообщений/событий
Логика Действие
Группа сделок
Алгоритмы обнаружения мошенничества
Блокируйте кредитную карту при обнаружении мошенничества
ПРИЛОЖЕНИЕ 17.4.
Команда по архитектуре предприятия должна на ранних этапах вместе с группами agile pods решить, какие возможности необходимы для обмена сообщениями и потоковой передачи данных в организации. Стандартизация на ранних этапах позволит гибким группам сотрудничать более эффективно.
Глава 18. Более
хирургический и ценностный подход к облачным технологиям
Откровения находятся в облаках.
-Сердж Кинг
Какой объем работ по миграции в облако вы должны выполнить в рамках цифровой трансформации? Это сложный вопрос, который усложняется зачастую ограниченным пониманием экономики облачных вычислений и эффективных стратегий миграции. Правда заключается в том, что результаты масштабных работ по миграции в облако слишком часто не оправдывают надежд и во многих случаях приводят к неожиданно высоким инвестициям и затяжным внедрениям1.
Успешная интеграция облака в цифровую трансформацию и трансформацию с помощью ИИ требует подхода, основанного на том, где находится ценность.
Какие бизнес-домены вы решили сделать приоритетными в своей цифровой дорожной карте и какой подход к миграции в облако - если таковой имеется - потребуется для существующих приложений в этих доменах? Более хирургический подход к облаку позволяет быстрее достичь ценности.
Одновременно переосмысливайте бизнес-сферу и базовые технологии
Большая часть выгоды от облачных вычислений связана с повышением гибкости, инновационности и устойчивости бизнеса, а не с более дешевой заменой традиционной инфраструктуры в центре обработки данных.
Начиная с приоритетных бизнес-доменов, не забудьте одновременно переосмыслить домен и лежащую в его основе технологию. Это позволит вам составить четкое представление о приложениях, которые необходимо перенести, чтобы получить максимальную отдачу, и при этом избежать ловушки переноса множества приложений, которые слишком связаны между собой, чтобы в полной мере использовать преимущества облака.
Например, одна страховая компания, которая хотела перестроить процесс привлечения клиентов, запустила два направления работы: одно - переосмысление и упрощение всего процесса привлечения клиентов, а другое - модернизация базовой технологии в облаке. Две команды, работая вместе, смогли модернизировать платформу omnichannel и технологию в облаке, что позволило им преобразовать набор разрозненных, бумажных, специфических для каждого канала процессов в бесшовный omnichannel опыт с использованием цифровых технологий.
По мере создания технологической дорожной карты для приоритетных областей уточняйте архитектурные решения для каждого из цифровых решений, включенных в дорожную карту, сразу (а не по частям). Это позволит вам получить полное представление о зависимостях и оптимальной последовательности действий, чтобы получить выгоду.
На рисунке 18.1 показаны наиболее распространенные варианты архитектурных решений и связанные с ними инженерные соображения, касающиеся облачных вычислений. Они могут варьироваться от оставления приложения "как есть" до переноса его в облако и вывода из эксплуатации.
Типовые варианты архитектуры для создания цифровых решений
Типичный
архитектурные решения
Создание нового облачного приложения
Используйте основное системное приложение "как есть" (с оберткой)
Повышение сложности
Создание новых "облачных" функций для замены части основного системного приложения.
Перенос и рефакторинг основных системных приложений в облако для повышения производительности инноваций
Изменение всей основной системы для повышения производительности и снижения стоимости единицы продукции
Примеры банковских операций
Создайте мобильное приложение для оформления кредитной карты с минимальным количеством кликов
Используйте приложение "KYC - Знай своего клиента" в основной банковской системе
Создание нового механизма принятия кредитных решений для замены основной системы оценки кредитных рисков
Перенос и рефакторинг всего приложения для оценки кредитных рисков в облако для ускорения вывода на рынок
Изменение всей основной банковской системы с целью снижения себестоимости и создания широкого набора новых функций
Инженерные соображения
Обеспечьте передачу данных из основных систем в приложение для онбординга и кредитную аналитику
Использование API для доступа к приложению системы KYC и обеспечение производительности в режиме реального времени
Создайте новую систему принятия кредитных решений с доступом к данным о клиентах в режиме реального времени
Примите решение о выборе оптимального варианта миграции (см. варианты миграции в облако)
Параллельно запустить старую и новую базовую систему и разработать стратегию миграции данных
ПРИЛОЖЕНИЕ 18.1
Определите возможности использования облаков и подход к миграции
Если данное решение необходимо перенести в облако (в отличие от вывода из эксплуатации или замены на SaaS-решение), то вторичным решением будет "перевести" приложение в облако, "рефакторить/реархивировать" или что-то среднее, например "переплатформировать" (см. Рисунок 18.2).
Шесть вариантов утилизации/миграции унаследованных приложений
Уйти на пенсию
1
Приложения, которые больше не нужны и могут быть выведены из эксплуатации в течение ближайших 1-2 лет
Выкуп
2
Приложение, которое устарело с технической или деловой точки зрения и нуждается в замене на облачный SaaS1
Rehost ("поднять и сдвинуть")
3
Приложение, которое поднимается и переносится в облако, позволяет быстро осуществить миграцию более крупного наследия, что дает возможность отказаться от центров обработки данных
Реплатформа
Изменение платформы приложения с целью получения ощутимых преимуществ без изменения основной архитектуры
4
Рефактор/архитектор
5
Изменение архитектуры, добавление функций, масштаба или производительности, которые в противном случае было бы сложно реализовать в текущей среде приложений.
Сохраните
6
Приложения, которые не готовы к миграции или миграция которых не имеет смысла с точки зрения выгоды
1. При замене приложения вы можете создать приложение на заказ или настроить приложение SaaS в зависимости от зрелости рынка SaaS и потребностей бизнеса.
ПРИЛОЖЕНИЕ 18.2
Рехостинг ("поднять и перенести") предполагает перенос приложения в облако без изменений кода или архитектуры. Этот вариант выбирают компании для быстрого прогресса. Однако опыт показывает, что простой перенос приложений в облако не приносит большой пользы. Чтобы воспользоваться преимуществами облака, необходимо переплатформировать или рефакторизовать приложения.
Реплатформинг предполагает относительно более простые изменения по сравнению с реархитектурой, такие как изменение взаимодействия на уровне данных и быстрое получение выгоды за счет использования некоторых возможностей облачных вычислений.
Рефакторинг/реархитектура подразумевает переход в публичное облако и перестройку архитектуры для использования возможностей cloud-native. Хотя это требует изменения кода и инвестиций, зачастую это лучший вариант, если приложения необходимо значительно улучшить, чтобы они соответствовали новым бизнес-требованиям.
Ведущие организации обычно используют несколько подходов для своих приложений бизнес-домена. Часто рехостинг или реплатформинг являются первым шагом на пути модернизации, чтобы быстро получить отдачу (снижение затрат и некоторые облачные возможности) перед перестройкой архитектуры. Однако очень важно оценить и модернизировать сразу все необходимые приложения
бизнес-сферы, а не использовать подход, основанный на отдельных приложениях, что, как правило, обходится дороже.
Перенос приложений часто требует устранения проблем безопасности и соответствия требованиям, а также оптимизации систем в облаке. Перенос с последующей оптимизацией может помочь выйти из тупика, в котором оказались многие компании, работающие с облачными программами. Однако такой подход требует признания того, что некоторые приложения могут стоить дороже в краткосрочной перспективе и обеспечивать меньшую производительность.
Выбор поставщика облачных услуг
Избегайте того, чтобы отдельные команды сами выбирали поставщика облачных услуг (CSP). Если оставить за agile-подразделениями право самостоятельно решать, какие сервисы использовать, это в конечном итоге приведет к фрагментации, сложности и отсутствию сотрудничества в организации. Навыки, во многих случаях, не будут переноситься между CSP. Аналогичным образом, команда по архитектуре предприятия должна рассмотреть вопрос о том, какие службы должны быть стандартизированы, чтобы избежать сложностей и технического долга (например, какие службы баз данных или технологии обмена сообщениями должны быть приняты предприятием в качестве стандарта). Каждый CSP предлагает сотни собственных услуг и рыночных площадок, обеспечивающих доступ к экосистеме услуг сторонних производителей.
Создайте облачную основу
Многие облачные решения не удается масштабировать, потому что компании не вкладывают средства в создание прочного облачного фундамента. Для создания этих фундаментальных элементов вам понадобится несколько высококвалифицированных облачных архитекторов:
Базовые возможности облака. Эти возможности включают сетевые подключения и маршрутизацию, централизованные межсетевые экраны и прокси-серверы, стандартизацию идентификационных данных, корпоративную регистрацию, мониторинг и аналитику (ELMA), общие корпоративные службы, конвейеры "золотого образа" (или "первичного образа"), а также обеспечение соответствия и безопасности. Компании могут создать базовые возможности один раз и повторно использовать их во всех зонах изоляции.
Зоны изоляции. Зоны изоляции (иногда называемые посадочными зонами) - это облачные среды, в которых живут приложения. Каждая зона содержит службы CSP, управление идентификацией и доступом (IAM), изоляцию сети, управление мощностями, общие службы, специфичные для данной зоны изоляции, и контроль изменений, в которых выполняются одно или несколько связанных приложений. Зоны изоляции обеспечивают избыточность в случае сбоя одной из зон. Поэтому необходимо иметь более одной зоны изоляции для создания избыточности, но не так много, чтобы не создавать сложности.
Согласование количества зон изоляции - критически важное решение. При наличии одной зоны изоляции изменения конфигурации для поддержки одного приложения могут непреднамеренно повлиять на другие. Впадение в другую крайность - одна зона изоляции для каждого приложения - препятствует эффективному развертыванию изменений конфигурации, требуя выполнения одной и той же работы во многих зонах изоляции.
Шаблоны приложений. Это артефакты кода, автоматизирующие безопасную, совместимую и стандартизированную конфигурацию и развертывание приложений со схожими функциональными и нефункциональными требованиями. Шаблоны приложений могут отвечать за конфигурирование общих ресурсов, стандартизацию конвейеров развертывания, а также за обеспечение качества и соответствия требованиям безопасности. Примерами шаблонов приложений являются шаблоны обработки данных, такие как SQL DB, NoSQL DB, data mart/warehouse; веб-приложения, такие как статический веб-сайт или трехуровневое веб-приложение; API и т. д. Количество шаблонов, необходимых для поддержки перечня приложений, должно быть небольшим, что позволяет добиться максимальной рентабельности инвестиций. Например, один крупный банк успешно использовал всего 10 шаблонов приложений, чтобы удовлетворить 95 % необходимых сценариев использования.
Эти основополагающие элементы позволяют в восемь раз ускорить темпы миграции и внедрения облачных технологий и на 50 % сократить расходы на миграцию в долгосрочной перспективе.3
Наращивайте потенциал FinOps
Наиболее эффективная экономика облачных вычислений заключается в том, чтобы платить за мощности только тогда, когда они вам нужны, а не платить за мощности, которые вы не используете. Этого можно достичь, выбирая облачные сервисы, которые наилучшим образом соответствуют текущие требования к рабочим нагрузкам. Это может привести к экономии расходов на облачные вычисления до 20 %.
Наиболее успешные предприятия развивают эту способность, объединяя технических, финансовых специалистов и специалистов по поиску поставщиков в команды FinOps для управления расходами на облачные вычисления. Эта команда должна определить потребности предприятия в вычислительных и сетевых ресурсах, часто используя передовую аналитику для прогнозирования спроса, а затем преобразовать эти потребности в оптимальные облачные предложения и ценовые схемы. Они используют облачные инструменты для создания автоматизированных информационных панелей, чтобы отслеживать использование облака и перераспределять ресурсы для оптимизации расходов. Команда FinOps также отслеживает расходы на облачные технологии в масштабах всего предприятия, чтобы обеспечить финансовую дисциплину.
Облако - это огромный мультипликатор силы. Для цифровой трансформации вам понадобятся облачные возможности, но это не обязательно означает перенос всех рабочих нагрузок. Высококлассная команда облачных архитекторов и специалистов по FinOps поможет сориентироваться в необходимых вариантах и компромиссах (и многократно окупит себя).
Примечания
Абхи Бхатнагар, Бейли Колдуэлл, Альхарит Хуссин и Абдалла Салеме, "Облачная экономика и шесть самых вредных ошибок, которых следует избегать", McKinsey.com, 3 мая 2022 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/cloud-economics-and-the-six-most- damaging-mistakes-to-avoid.
Аамер Байг и Джеймс Каплан, "Пять шагов для поиска ценности в облаке", CIO, 2 февраля 2022 г., https://www.cio.com/article/304106/5- steps-for-finding-value-in-the-cloud.html; см. "Семь уроков о том, как технологические преобразования могут обеспечить ценность", McKinsey.com, 11 марта 2021 г., https://www.mckinsey.com/capabilities/mckinsey-digital/ our-insights/seven-lessons-on-how-technology-transformations- can-deliver-value.
Аарон Бауком, Себастьян Бекерра, Бо Беннетт и Билл Грегг, "Основы облачных технологий: Десять заповедей для более быстрой - и более прибыльной - миграции в облако", McKinsey.com, 21 апреля 2022 г., https://www.
Глава 19.
Инженерные практики для обеспечения скорости и высокого уровня кода качества
Инженеры воплощают мечты в реальность.
-Хаяо Миядзаки
Раньше выпуск нового программного обеспечения был похож на выпуск новой крупной модели автомобиля: годы проектирования, разработки и тщательных испытаний, за которыми часто следовало большое маркетинговое мероприятие и вечеринка по случаю запуска. Однако на первый план вышли более совершенные методы и инструменты - в том числе растущие преимущества программного обеспечения с открытым исходным кодом, - позволяющие командам разработчиков проходить различные этапы разработки программного обеспечения и выпускать новые функции быстро и итеративно. Это изменило игру - теперь каждая компания должна стать компанией-разработчиком программного обеспечения.1 В основе этой революции лежит автоматизация жизненного цикла разработки программного обеспечения (SDLC), о которой пойдет речь в этой главе (см. Рисунок 19.1).
Жизненный цикл разработки программного обеспечения (SDLC)
РАЗВИТИЕ
ПРОДУКЦИЯ
Непрерывная интеграция Непрерывная
развертывание
Код
Построить
Пакет
Работайте на сайте
Тест
Развернуть
ПРИЛОЖЕНИЕ 19.1
Автоматизация SDLC позволяет agile-командам вносить небольшие изменения, быстро проверять их (с помощью механизмов быстрой обратной связи), часто тестировать и непрерывно итерировать - что резко отличается от распространенного подхода, при котором команды вносят большие изменения партиями во время окон выпуска, а затем выпускают их в производство. Из-за размера этих изменений и количества изменяемых вещей может возникнуть любое количество проблем, которые замедлят способность agile-команды к быстрой итерации.
Компания Netflix создала облачную ИТ-архитектуру, которая позволяет ее разработчикам запускать сотни изменений в программном обеспечении в день. Сайт компании состоит из сотен микросервисов, размещенных в облаке, и каждый сервис разрабатывается и поддерживается специальной командой. Разработчикам не нужно запрашивать ресурсы у команды ИТ-операторов, вместо этого они могут автоматически собирать части кода в развертываемые веб-образы. По мере обновления этих образов новыми функциями или сервисами они могут быть интегрированы в существующую инфраструктуру Netflix с помощью специально разработанной веб-платформы, на основе которой создаются кластеры инфраструктуры. Тестирование тщательно проводится в производственной среде с подмножеством пользователей.
Как только веб-образы начинают работать, технология балансировки нагрузки перенаправляет часть трафика на них с более старых версий. Автоматизированный мониторинг гарантирует, что если что-то пойдет не так при развертывании новых образов, трафик будет перенаправлен обратно на старые версии, а новые образы будут откачены. Благодаря такому уровню автоматизации Netflix может развернуть новый код в своей производственной среде в течение нескольких часов, в то время как большинству компаний потребовались бы месяцы.2
Хотя Netflix может представлять собой более высокоразвитое состояние, чем требуется большинству компаний, эти методы могут быть использованы в любой современной разработке программного обеспечения. В основе этих успешных "малых и быстрых" практик разработки на протяжении всего SDLC лежат следующие три потребности:
Основание для быстрой доставки программного обеспечения в DevOps
DevOps стремится применить принципы бережливого производства к тому, как организации передают программное обеспечение в руки пользователей. DevOps - это сокращенный способ сказать: "Мы собираемся объединить всех людей, которые разрабатывают приложения, со всеми людьми, которые эксплуатируют и защищают эти приложения, в интегрированные рабочие команды". Чтобы было понятно, операционная деятельность никуда не исчезает, она становится частью разработки.
К настоящему времени многие компании слышали о DevOps и пытаются внедрить его. Но многие все еще пытаются внедрить DevOps в масштабах компании, склоняясь к тому, что это инструмент или специалист, который добавляется к существующим командам. Чтобы внедрить DevOps, вам необходимо принять три принципа и связанные с ними практики:
Поток. Ускорьте процесс передачи результатов разработки, чтобы они быстро и эффективно попадали в руки пользователей. Начните с составления карты потока создания ценности в рамках SDLC, то есть с того, какие этапы включает в себя кодирование, сборка, тестирование, упаковка и развертывание программного обеспечения в среде. Изначально это ручной процесс. Затем определите время, которое требуется между этапами, и все ручные процессы, которым следуют инженеры в ходе SDLC. Например, можно определить, что инженерам в agile pod приходится просить другую команду, чтобы выполнить определенную работу от их имени. Наконец, систематически сокращайте или удаляйте все выявленные ручные шаги путем автоматического спаривания (см. ниже о CI/CD). Начните с тех этапов, которые больше всего отнимают времени, чтобы расставить приоритеты.
Обратная связь. Обеспечьте множественные петли обратной связи в потоке создания ценности SDLC, чтобы помочь agile-подразделениям диагностировать проблемы по мере их возникновения, чтобы их можно было быстро решить. Это достигается путем создания dash-досок для визуализации потока создания ценности, принимая живые данные с различных этапов SDLC.
Непрерывное обучение. Создайте культуру обмена опытом, обучения и постоянного совершенствования. Периодически анализируйте и ищите улучшения на протяжении всего SDLC, чтобы обеспечить эффективную передачу программного обеспечения пользователям, не прибегая к ручным процессам.
Обычно компании создают команду DevOps для выполнения этой специализированной работы. Эта команда также будет работать с различными подразделениями, обучая их и обеспечивая последовательное внедрение.
Заложив прочный фундамент DevOps, компании распространяют эти возможности на другие практики разработки кода, такие как DevSec- Ops, MLOps и DataOps (см. Рисунок 19.2). Суть этих возможностей заключается в постоянном продвижении автоматизации, машинного обучения и задач управления данными для увеличения скорости разработки, повышения безопасности и снижения затрат.
DevSecOps внедряет безопасность в процесс разработки и выпуска, а не ставит ее в конец. Как и в случае с DevOps, компании могут увеличить частоту выпуска программного обеспечения с ежеквартальных до еженедельных или даже ежедневных релизов, не снижая при этом уровень риска. Обеспечение безопасности и соответствия требованиям с самого начала является обязательным, поскольку растущая зависимость компаний от цифровых технологий делает их более уязвимыми для кибератак.3 Во многих случаях DevSecOps заменил DevOps, и эти два понятия используются как взаимозаменяемые. Мы подробно рассмотрим тему безопасности в главе 22.
MLOps основан на DevOps, но для моделей машинного обучения (ML) и искусственного интеллекта. Любая компания, которая пытается разрабатывать, поддерживать и улучшать сотни моделей ML/AI в производстве, понимает, насколько сложно обеспечить стабильность и точность моделей прогнозирования, а также их калибровку в условиях изменяющейся среды данных. Именно здесь на помощь приходит MLOps. Мы подробно рассмотрим MLOps в главе 23.
Семейство практик xOps
Каждая практика и связанный с ней процесс обеспечивают различные преимущества на этапах разработки, производства и управления данными
Обеспечьте среду (среды) "песочницы" для исследований и экспериментов
Обеспечьте стабильную среду 24 часа в сутки,
7 дней в неделю,
52 недели/год
Обеспечивает доступ к данным как на платформах разработки, так и на производственных платформах
MLOps
DevOps/DevSecOps
DataOps
ДАННОЕ ОЗЕРО
ПРОДУКЦИЯ
РАЗВИТИЕ
DevOps/DevSecOps
Ускорьте безопасную доставку новых функций с момента разработки до
конечные пользователи
MLOps
Разработка, поддержка и мониторинг производительности моделей машинного обучения и связанных с ними конвейеров обработки данных.
DataOps
Ускорение процесса создания новых информационных ресурсов за счет автоматизации качества и надежности данных
ПРИЛОЖЕНИЕ 19.2
DataOps - это также относительно новая и быстро развивающаяся область. По сути, это возможность ускорить создание новых и обновление существующих информационных ресурсов, а также повысить качество данных. Мы рассмотрим DataOps в главе 26.
Повышение качества благодаря стандартам кодирования и удобству сопровождения кода
По мере роста числа agile-подразделений и увеличения объема генерируемого ими кода - типичное приложение для смартфона содержит 50 000 строк кода организациям стало необходимо уделять особое внимание стандартам кода. Генеральный директор компании по производству электромобилей включает качество кода в свою приборную панель.
При отсутствии внимания к стандартам кода время, необходимое для внесения изменений в код, увеличивается, код становится сложнее, инженеры все больше расстраиваются, а технический долг растет.
Технический долг: Что это такое и как его измерить
При огромном количестве цифровых решений и команд, поддерживающих цифровую трансформацию, существует значительный риск возникновения технического долга. Технический долг - это "налог", который компании платят за любые разработки для устранения технологических проблем. Технический долг возникает в результате накопления плохих практик кодирования, таких как использование коротких путей, предоставление плохо написанного кода, внесение временных исправлений (которые неизбежно становятся постоянными) и реализация одноразовых решений. Технический долг, скрытый в архитектуре, может стать причиной возникновения проблем, из-за которых проекты выходят за рамки бюджета и не укладываются в сроки. При слишком большом техническом долге большая часть времени ИТ-сотрудников уходит на управление сложностями, а не на инновационное мышление о будущем.
Технологический долг продолжает расти в большинстве исследованных нами организаций. Более того, почти половина компаний, завершивших программы модернизации, не добились успеха в сокращении технологического долга. Для того чтобы внести ясность в этот вопрос, технологическим руководителям необходимо дать количественную оценку этой проблемы с точки зрения соотношения затрат и выгод. По сути, это вопрос понимания стоимости времени, потерянного разработчиками на решение проблем, вызванных технологическим долгом (т. е. процентов), по сравнению с затратами на погашение самого технологического долга (т. е. основной суммы).
Разработка анализа затрат и выгод - задача нетривиальная. Во-первых, получить такую детализацию можно только на уровне приложений. Во-вторых, компании должны понимать, с каким типом технического долга они имеют дело (мы выделили 11 различных типов).4 Это движущие силы технического долга, поэтому знание их типа необходимо, чтобы затем знать, как устранить каждый из них. Например, техническая задолженность по данным отличается от технической задолженности по инфраструктуре.
Компании используют этот анализ для разработки анализа затрат и выгод, который выявляет, какие приложения дают наибольшую отдачу с точки зрения решения проблемы технологического долга.
Мы обнаружили, что компании, находящиеся в 80-м процентиле по уровню поддержания технического долга на низком уровне, имеют рост доходов на 20 % выше, чем компании, находящиеся в 20-м процентиле.
Хорошее качество кода имеет десятки характеристик, включая тестируемость, надежность, возможность повторного использования, переносимость и сопровождаемость. Обеспечение высокого качества кода требует, чтобы вы:
Выберите и используйте систему контроля версий для всего кода
Контроль версий и его дисциплинированное использование являются основными факторами, способствующими созданию высокопроизводительных групп разработки. Организации используют контроль версий для хранения сценариев инфраструктуры как кода (IaC), исходного кода приложений, а также любых конфигураций, тестов и сценариев развертывания. Это обеспечивает воспроизводимость и прослеживаемость - два ключевых требования, с которыми сталкиваются организации, особенно те, в которых существует множество обременительных ручных процессов.
Системы контроля версий включают Git, CVS, SVN и многие другие. Эти системы также предоставляют такие важные возможности, как аудит кода, и позволяют agile-подразделениям внимательно изучать, как уязвимости могли попасть в систему, и вносить необходимые исправления.
Решите, какую программную основу использовать
Программный фреймворк предоставляет рекомендации по написанию кода для конкретной цели. Например, если цель - создание веб-приложений, а язык - JavaScript, эффективными могут быть такие фреймворки, как React или Angular. Если цель - создание микросервисов, которые имеют малый вес и хорошее оповещение об ошибках, то хорошими вариантами могут быть Python или TypeScript. Аналогично, существуют программные фреймворки, такие как Kedro, для написания конвейеров данных и моделей машинного обучения.
Программные фреймворки представляют собой способ организации кода и облегчают повторное использование функциональных возможностей кода, что позволяет ускорить разработку.
Обеспечьте последовательность в написании кода
Линтер кода - это инструмент статического анализа кода, используемый для выявления ошибок программирования, багов, стилистических ошибок и подозрительных конструкций. Различные языки кода часто имеют свои собственные инструменты (Super Linter на GitHub поддерживает несколько языков). Например, для языка программирования Python есть такие инструменты, как Pylint, а для языка программирования JavaScript - JSLint. Эти инструменты могут запускаться agile-подразделениями для проверки соответствия создаваемого ими кода единым стандартам качества.
Определитесь с фреймворком тестирования для проверки кода
Agile-подразделения используют тестовый фреймворк для написания модульных тестов для кода, который они пишут. Различные языки программирования поддерживают свои собственные тестовые фреймворки: в языке Python есть pytest или unittest, а в языке программирования JavaScript - Jest. Независимо от выбранного тестового фреймворка (их существует множество), ключевым моментом является стандартизация фреймворка и обеспечение того, чтобы все подгруппы использовали его.
Существуют различные типы тестирования, которые пишут инженеры в agile pods (см. Рисунок 19.3).
Для решений, где надежность и производительность особенно важны (например, сайт электронной коммерции, соответствие нормативным требованиям), рассмотрите возможность выделения отдельной функции инженера по надежности сайта (SRE) для работы над сценариями производительности и надежности. В то время как инженеры DevOps сосредоточены на решении проблем конвейера разработки, инженеры по надежности сайта решают проблемы эксплуатации, масштабирования и надежности. Команды SRE - это высококвалифицированные инженеры, которые сосредоточены на решении проблем в течение определенного периода времени, а затем переходят к другому решению.
Минимизация сложности кода
Очень важно, чтобы сложность кода была минимальной. Система метрик кода анализирует код с помощью различных математических методов, в основном для того, чтобы определить, насколько он сложен. Различные сторонние продукты, такие как SonarQube, изучают код, хранящийся в системе контроля версий, чтобы понять его сложность и сообщить о его состоянии. Эти инструменты (некоторые с открытым исходным кодом, некоторые платные) также ищут уязвимости в коде или уязвимости в зависимостях, используемых кодом.
Стратегии тестирования - определения
Тестирование на проникновение
Регрессионное тестирование
Проверка устойчивости приложения к кибернетическим атакам
Обеспечивает отсутствие негативных последствий для существующих программных приложений при добавлении новой функциональности
Увеличение стоимости и времени тестирования
Тестирование производительности/нагрузки
Приемочное тестирование
Сплошное тестирование (системы)
Обеспечивает работоспособность приложения в различных условиях, имитируя одновременный доступ к приложению нескольких пользователей
Обеспечивает корректную работу приложения с точки зрения пользователя
Убедитесь, что все приложение в целом ведет себя так, как ожидается
Интеграционное тестирование
Проверка путей связи и взаимодействия между компонентами для выявления дефектов интерфейса
Модульное тестирование
Тестирует отдельные блоки (модули, функции, классы) в изоляции от остальной части приложения
ПРИЛОЖЕНИЕ 19.3
Автоматизируйте создание документов для обеспечения соответствия нормативным требованиям
В некоторых отраслях необходимо документировать код и API до того, как код будет запущен в производство. Многие языки предоставляют механизм для встраивания документации в сам код (в виде комментариев). Затем инструменты могут сканировать код и автоматически генерировать документацию в удобочитаемую форму. Эта документация может храниться в системе контроля исходных текстов вместе с кодом и использоваться в качестве аудита кода в данный момент времени.
Генерировать документацию из кода предпочтительнее, чем заставлять разработчиков писать ее вручную, поскольку это более эффективно по времени и более точно (хотя разработчику все равно придется подтверждать, что документация точна на 100 %). В некоторых отраслях такая документация может помочь соблюдению нормативных требований и регуляторам "подписать" то, что выпускается в производство.
Обеспечьте сквозную автоматизацию с помощью непрерывной интеграции и непрерывного развертывания (CI/CD)
По мере усложнения программного обеспечения простые на первый взгляд изменения могут привести к непредвиденным побочным эффектам. Сложность может возрастать, когда над одним и тем же программным обеспечением работают несколько разработчиков из разных команд. Непрерывная интеграция/непрерывное развертывание (CI/CD) - это подход, который решает эту проблему. Вот краткий обзор процесса CI/CD (пример см. в Примеч. 19.4):
Непрерывная интеграция (CI) решает проблему координации и проверки изменений программного обеспечения в процессе разработки автоматизированным способом для обеспечения высокого качества. Для реализации CI существует множество инструментов.
В одной глобальной фармацевтической компании agile-подразделение, разрабатывающее новую функциональность API, выбрало CircleCI в качестве инструмента CI. Жизненный цикл кода описан ниже:
Инженеры, работающие по принципу agile pod, вносили изменения в код, которые затем сохранялись в GitHub (система контроля версий).
CircleCI обнаруживает изменения кода, внесенные в систему контроля версий.
CircleCI проверяет соответствие кода стандартам, запуская Pylint (инструмент для линтинга).
CircleCI проверяет правильность поведения кода, запуская связанные с ним тесты - в данном случае с помощью Pytest.
CircleCI проверяет соответствие кода стандартам качества, выполняя метрики кода - в данном случае с помощью SonarQube.
Документация к коду генерируется автоматически с помощью инструмента - в данном случае с помощью Sphinx (инструмент с открытым исходным кодом, который извлекает документацию из кода и генерирует человекочитаемую документацию для веба).
CircleCI упаковывает пройденный код в модульный строительный блок, который хранится в репозитории пакетов - в данном случае пакет хранится в контейнере (Docker) и хранится в Amazon ECR (хранилище образов Docker, управляемое Amazon). Контейнеры позволяют запускать приложения в любой среде, однако использовать их следует с умом.
Конвейер кода Python - непрерывная интеграция и развертывание - пример
КОД
Python
GitHub
1
2 CircleCI Обнаружение изменений в коде
3 Pylint Проверка соответствия кода стандартам
4 Pytest Проверьте поведение кода, запустив тест
5 SonarQube Проверка качества кода
6 Sphinx Автогенерация документации
7 Docker Код упаковывается и хранится в репозитории
Amazon ECR
8 Selenium Запуск интеграционных тестов
Инженеры вносят изменения в код
Контроль исходных текстов/сохранение кода
НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ
НЕПРЕРЫВНОЕ РАЗВЁРТЫВАНИЕ
ПРИЛОЖЕНИЕ 19.4
3 Argo Обнаружение изменений в коде
4 Checkmarx Проверка на наличие уязвимостей
5 Argo Скопируйте образ Docker на производственную платформу Kubernetes
6 Kurbenetes Представьте в виде API для тестирования поведения кода
7 Selenium Убедитесь, что API работает
8 Kurbenetes Активируйте API для пользователей
Затем CircleCI проводит интеграционные тесты, проверяя, работает ли новый модульный блок при интеграции со всем остальным программным обеспечением и любыми другими изменениями, внесенными другими членами команды - в данном случае с помощью Selenium (инструмента автоматизации веб-программ с открытым исходным кодом для автоматического написания тестов).
Поскольку весь этот процесс автоматизирован и выполняется часто (по мере изменения кода), он дает разработчикам быструю обратную связь о качестве кода и уверенность в том, что выпускается высококачественное программное обеспечение.
Непрерывное развертывание - это следующий этап процесса, являющийся естественным продолжением CI. Оно берет программное обеспечение, успешно прошедшее все этапы CI, и доставляет его в производство, устраняя все ручные шаги в этом процессе, так что программное обеспечение автоматически становится доступным для конечных пользователей.
Фармацевтическая компания, о которой шла речь выше, выбрала инструмент Argo CD для развертывания в производстве (кластер Kubernetes). Процесс компании включал в себя следующие шаги (см. рисунок 19.4. Обратите внимание, что следующее перечисление отличается от приведенного на рисунке для наглядности).
Argo CD обнаруживает изменения в GitHub (контроль версий), сделанные с помощью непрерывной интеграции (указывающие на то, что нужно развернуть что-то новое).
Argo CD проверяет пакет на наличие уязвимостей с помощью Checkmarx, который используется для обнаружения векторов атак безопасности в пакете или написанном коде. Это дополнительный шаг, гарантирующий, что то, что ставится в производство, безопасно для работы в производстве.
Затем Argo CD копирует с Amazon ECR образ Docker на производственную платформу Kubernetes. Платформа Kubernetes упрощает управление контейнерами и делает приложения более переносимыми.
Затем Argo CD гарантирует, что у этого нового контейнера есть частный API, который можно использовать для проверки правильности поведения пакета.
Argo CD запрашивает Selenium (инструмент тестирования) для проверки правильности поведения API.
Наконец, если до этого момента все было в порядке, компания Argo CD может использовать одну из своих стратегий для раскрытия API конечным пользователям безопасным способом, который не нарушит работу пользователей, использующих API.
Таким образом, развертывание конвейера CI/CD помогло фармацевтической компании сократить время развертывания с нескольких часов до всего лишь 10 минут, а также существенно снизить технический долг и риски безопасности.
Дисциплинированный подход CI/CD позволяет выпускать надежное и качественное программное обеспечение за несколько дней (даже часов), а не месяцев или кварталов. По сути, CI/CD - это конвейер, в котором новые программные функции проходят различные этапы от начального кодирования до выпуска для пользователей в производственной среде.
Примечания
Чандра Гнанасамбандам, Джанаки Паланиаппан и Джереми Шнайдер, "Каждая компания - это софтверная компания: Шесть "обязательных условий" для достижения успеха", McKinsey.com, 13 декабря 2022 г., https://www.mckinsey. com/capabilities/mckinsey-digital/our-insights/every-company-is-a- software-company-six-must-dos-to-succeed.
Оливер Боссерт, Крис Ип и Ирина Старикова, "Beyond agile: Reorganizing IT for faster software delivery", McKinsey.com, 1 сентября 2015 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ beyond-agile-reorganizing-it-for-faster-software-delivery.
Сантьяго Комелла-Дорда, Джеймс Каплан, Линг Лау и Ник Макнамара, "Проворные, надежные, безопасные, отвечающие требованиям ИТ: Выполнение обещания DevSecOps", McKinsey.com, 21 мая 2020 г., https://www.mckinsey. com/capabilities/mckinsey-digital/our-insights/agile-reliable-secure- compliant-it-fulfilling-the-promise-of-devsecops.
Вишал Далал, Криш Кришнакантан, Бьорн Мюнстерманн и Роб Патенге, "Технологический долг: Восстановление технологического капитала", McKinsey.com, 6 октября 2020 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ tech-debt-reclaiming-tech-equity.
Глава 20.
Инструменты для повышения квалификации ваших разработчиков
Если вы дадите людям инструменты, а они будут использовать свои природные способности и любопытство, они разработают такие вещи, которые удивят вас гораздо больше, чем вы могли бы.
ожидали.
-Билл Гейтс
GitHub, как известно, в течение многих лет пытался предоставить своим инженерным командам возможность использовать локальные среды для ноутбуков (на macOS). Несмотря на все усилия, локальные среды разработки оставались хрупкими. Невинные изменения могли привести к тому, что локальная среда становилась бесполезной, а на ее восстановление уходили часы драгоценного времени. Часто случались сбои из-за несогласованных конфигураций локальной среды. GitHub решил эти проблемы, перейдя на виртуальные среды, которые стандартизированы, имеют предустановленные инструменты и доступ к любым необходимым данным.
По мере масштабирования организации и перехода от пяти agile-подразделений к 20, 100 или даже 1 000+ подразделениям разработки следует переходить к средам самообслуживания (sandbox), которые самомасштабируются и предоставляют все современные и стандартизированные инструменты, необходимые agile-подразделениям для разработки решений. Это позволит избежать необходимости нагружать ИТ-отдел запросами на предоставление инфраструктуры и инструментов, а командам разрабатывать код, который будет работать в производственной среде.
Специальная команда инженеров, которую иногда называют командой платформы разработчиков, внедряет инструменты и технологии, обеспечивающие соблюдение стандартов, разработанных командой архитектуры предприятия. Эта команда также предоставляет инструменты, ориентированные на пользовательский опыт, для оптимизации работы agile-подразделений, помогая им сосредоточиться на быстром предоставлении ценности, а не на том, чтобы зацикливаться на управлении и поддержке инфраструктуры и инструментария.
По их словам: Пересмотр способов создания сервисов в облаке
Мы поняли, что нам нужно использовать совершенно новый подход к управлению и предоставлению услуг в облаке. Мы сформулировали три принципа, которых мы собирались придерживаться:
Услуги, которые мы предлагали командам разработчиков, должны были быть полностью стандартизированы и автоматизированы... чтобы больше не было нестандартных/случайных запросов.
Любые услуги, предлагаемые нами в "облаке", должны были с первого дня соответствовать требованиям безопасности, конфиденциальности и нормативных актов. Больше никаких разовых исключений или ручных обходных путей. Кроме того, любые приложения, созданные на основе этих сервисов, также должны были соответствовать требованиям с первого дня.
И наконец, нам пришлось придумать креативный способ обучения команды разработчиков тому, как создавать свои приложения с помощью этих сервисов; слишком долго они привыкли отдавать индивидуальные запросы команде инфраструктуры.
Так зародилось то, что мы сегодня называем платформой Atlas. Мы разработали план, в котором рассмотрели наиболее востребованные облачные сервисы, и создали продукт, в котором шаблонизировали большинство сервисов и обеспечили их совместную работу. Мы также обеспечили их совместную защиту и подключение ко всем нашим внутренним системам регистрации безопасности.
Для этого мы полностью прекратили работу нашей команды по созданию облачной инфраструктуры и привлекли владельца продукта, который в партнерстве с нами полностью изменил наше представление об облаке. Затем мы переобучили персонал, ориентируясь на концепцию создания продукта, который разработчики приложений могли бы получать и использовать в режиме самообслуживания, а не просто создавать инфраструктуру. Конечный продукт, Atlas, позволяет команде разработчиков приложений начать работу с извлечения кода в конвейер непрерывной интеграции и непрерывного развертывания (CI/CD). Он сам себя обеспечивает.
-Мартин Кристофер, бывший старший вице-президент и директор по информационным технологиям CUNA Mutual Group
Создание эффективной среды для развития включает в себя два элемента, о которых пойдет речь далее.
Гибкие и масштабируемые песочницы разработки
Раньше на запрос, создание и доступ к среде разработки у команды уходили недели, а иногда и месяцы. Теперь это уже не так. Среды разработки, или "песочницы", могут быть созданы за несколько минут или максимум часов с помощью автоматизации инфраструктуры как кода (IaC). Это быстро позволяет agile-подразделениям создавать свои собственные "песочницы" разработки (см. Рисунок 20.1). Каждая команда получает свою собственную "песочницу" в рамках более широкой облачной среды со стандартизированными инструментами, выделенной памятью и вычислительными возможностями, а также доступом к данным (либо тестовым данным, которые копируются автоматически, либо, в некоторых случаях, доступом к подмножеству производственных данных).
Пример платформы для разработчиков
Создайте командную атмосферу для под
Доступ к панели управления песочницы
Доступ
Все инструменты доступны через один верстак
Упрощение применения в строительстве
Облегчение выполнения общих действий из рабочего стола (без необходимости быть экспертом непосредственно в базовых инструментах)
Расширяемый
Со временем возможно добавление новых инструментов/функций
Портал для разработчиков
Agile Pod
(100% автоматизация)
1a
Создайте песочницу
2a
Открытие/доступ к данным
1b
Развертывание готовых шаблонов
2b
Инструменты для написания кода
1c
Настройте контроль исходных текстов
2c
Поиск существующего кода
1d
Настройка CI
2d
Эксперименты на дорожках
1e
Настройте инструменты для совместной работы
2e
Код сборки
1f
Автоматизируйте сканирование системы безопасности
2f
Опубликовать
2g
Монитор
2h
...
ПРИЛОЖЕНИЕ 20.1
Запуск сценариев IaC, способных создавать такие среды за секунды или минуты, может показаться некоторым инженерам несколько пугающим. А что, если в этих сценариях есть элементы, которые вы хотите, чтобы команды могли контролировать, например память, вычисления или даже приложения для предварительной загрузки? Разработка эффективной возможности самообслуживания в песочнице, способной удовлетворить множество потребностей, привела к появлению внутренних платформ разработчика (IDP) - легкого слоя пользовательского интерфейса (UI), который абстрагирует все сложности обеспечения инфраструктуры, безопасности и инструментов, но при этом предоставляет единый пользовательский интерфейс (UX) для настройки этих сред.
Пример из практики: Spotify решает проблему производительности разработчиков
По мере того как Spotify расширялась до множества agile-подразделений, а используемые компанией технологии становились все сложнее, выяснилось, что не все ее инженеры хорошо разбираются в этих технологиях, таких как Terraform для инфраструктуры, GCP/AWS/Azure CLI для различных облачных провайдеров, GitLab CI для контроля версий, Prometheus для мониторинга, Kubernetes и Docker для контейнеров и многие другие инструменты. Все усложнялось тем, что разным agile-подразделениям требовались разные инструменты для разработки внутренних API, внешних мобильных приложений и т. д.
Чтобы решить эту проблему, Spotify создала UX-инструмент под названием Backstage (который впоследствии был открыт). Backstage избавил инженеров от необходимости изучать огромное количество технологий и инструментов. Вместо этого инженеры могли нажать одну кнопку на простом веб-портале, чтобы добавить больше вычислительных мощностей на машину, над которой они работали, или получить доступ к журналам отладки. Со временем Spotify добавила дополнительные функции, чтобы помочь agile-командам обнаружить библиотеки, приложения и сервисы, разработанные другими agile-подразделениями, и дать им возможность двигаться быстрее - и все это на едином портале, что упрощает и улучшает работу разработчиков.
В нашей компании команда разработчиков платформы создала индивидуальный, легкий, самообслуживающийся веб-портал для разработчиков под названием Platform McKinsey, чтобы дать возможность сотням agile-команд McKinsey создавать цифровые и искусственные продукты, не заботясь о базовой инфраструктуре или инструментах. Веб-портал выполняет две задачи (см. Рисунок 20.1):
Действует по запросу команды на создание среды "песочницы", автоматически выполняя следующие действия:
Создайте "песочницу" с правильным контролем доступа для членов команды и правильными инструментами.
Установите все необходимые средства контроля версий, чтобы команде не приходилось делать это вручную.
Настройте любые инструменты для совместной работы, например вики, где команда может сотрудничать и хранить документы по продукту/проекту.
Установите и настройте инструмент CI, чтобы команда могла сосредоточиться только на своем продукте.
Предоставляет команде все необходимые инструменты для разработки продуктов через веб-портал, включая:
Инструменты для обнаружения и доступа к данным
Инструменты для написания кода
Инструменты для поиска неконфиденциального кода, который уже был написан другими командами (для экономии времени за счет повторного использования)
Инструменты, позволяющие отслеживать результаты экспериментов (особенно важно для разработки моделей машинного обучения)
Инструменты для просмотра статуса CI-сборки (например, повлияли ли изменения кода на качество продукта в целом?)
Простой способ публикации кода в продакшн одним нажатием кнопки
Инструменты для мониторинга состояния решений, которые они создают в процессе разработки и производства
В своих "песочницах" каждая команда может индивидуально использовать память и вычислительные мощности. Это особенно важно при разработке аналитических и информационных продуктов, когда в процессе разработки присутствует элемент экспериментирования, например, определение правильного алгоритма или объема данных для обработки.
Современная и стандартизированная оснастка
В песочницах инженерам необходим доступ к современным и стандартизированным инструментам. Эти инструменты используются на протяжении всего SDLC для разработки, тестирования, упаковки и хранения кода, который создают agile-подразделения (перед развертыванием). Многие поставщики облачных услуг также начали упаковывают инструменты, которые можно использовать как часть их предложения по предоставлению услуг на основе платформы как услуги (PaaS).
Существует пять основных категорий инструментов, связанных с разработкой, которые важны для любого agile-команды, разрабатывающей цифровые решения. Следует отметить, что выбор инструментов в первых двух категориях во многом зависит от того, какой продукт создает agile pod (например, front-end, back-end, API, data-pipeline или модель).
Инструменты разработчика. Это инструменты, используемые для экспериментов и создания кода, к которым также относятся интегрированные среды разработки (IDE). Набор инструментов зависит от языка (например, Python, R, JavaScript и т. д.). Хорошие инструменты разработчика обеспечивают проверку синтаксиса и валидацию кода, а также позволяют нескольким инженерам сотрудничать и работать над одним и тем же файлом в одно и то же время.
Инструменты для упаковки программного обеспечения (для производства). Для рабочего решения, которое должно упаковывать несколько блоков кода, например, webpack, который упаковывает js, css и html, этот код должен быть связан с другими версиями другого кода вокруг него и другими зависимостями. Это позволяет разработчикам лучше модулировать программное обеспечение и легче выпускать обновления.
Инструменты для хранения пакетов. Это инструменты для хранения пакетов кода. Такие инструменты, как Nexus, Docker Hub и JFrog Artifactory, позволяют хранить пакеты, готовые к производству.
Инструменты для разработки программного обеспечения. Эти инструменты обеспечивают интеграцию и доступ к контролю версий и непрерывной интеграции для agile-подразделений, используя среду "песочницы" и не заботясь о том, как все настроить и установить. Это позволяет команде сосредоточиться на создании высококачественного программного обеспечения.
Инструменты мониторинга. Среды песочницы необходимо контролировать, чтобы убедиться, что они работают должным образом и не сжигают деньги (например, многие инструменты лицензированы без пользователей, или люди используют инфраструктуру для добычи биткоина без выходных - да, такое случается). Примерами таких инструментов являются Grafana и Graphite.
Команда разработчиков платформы предоставляет набор стандартизированных общих инструментов, которыми могут воспользоваться все песочницы. Некоторые разработчики предпочитают выбирать те инструменты, с которыми им удобно работать. Организациям следует придерживаться подхода core/common/custom, то есть определить, что является "ядром", от которого нельзя отступать; что является "общим", то есть необязательным для использования и предоставляется всем; а что является "пользовательским", которое приобретается/загружается/устанавливается для конкретного пользователя или группы. Последнее следует делать только в том случае, если от этого есть реальная польза для бизнеса.
Глава 21. Цифровые решения производственного уровня
Пока мы не установим надежность, нет никакого смысла тратить время на то, чтобы заставить машину работать быстрее.
-Кэрролл Смит
Трансформационные продукты данных, модели искусственного интеллекта и цифровые путешествия пользователей должны быть развернуты для людей или приложений, которые их используют, в условиях, когда это имеет значение, например в сделках по продаже, управлении поставщиками и принятии решений по ценообразованию. Производственные среды должны быть надежными и доступными. Надежность этой производственной среды гораздо важнее, чем среды обнаружения и разработки.
Команда инженеров платформы - это те, кто создает среду для всех agile-подразделений, в которой они развертывают свои продукты. Команда отвечает за проектирование, создание и управление инфраструктурой, базовым технологическим стеком и сервисами, включая интеграцию с нижестоящими системами. Среда соответствует стандартам, установленным командой по архитектуре предприятия, и должна создаваться не вручную, а в соответствии со стандартными инженерными практиками. Любой код, который agile-подразделения хотят развернуть в про-дукционной среде, должен быть развернут в рамках строгого процесса непрерывного развертывания.
Существует три важных аспекта создания надежной и эффективной производственной среды, о которых пойдет речь далее.
Стремитесь к высокой степени контроля и проверяемости
Учитывая, что производственная среда обслуживает критически важные для бизнеса приложения, необходима высокая степень контроля и проверяемости. Это необходимо не только для обеспечения надежности, но и для соответствия требованиям, например, SOC 2, ISO 27001, PCI и т. д. Эти возможности должны быть сосредоточены в двух областях (см. Рисунок 21.1):
Сама производственная среда, в частности то, как она была настроена, какие политики безопасности были применены, какие (ограниченные) пользователи имеют доступ, какой входящий (ingress) доступ разрешен, какой исходящий (egress) доступ разрешен и т. д. Указывая эти производственные задачи в сценариях IaC и сохраняя их в системе контроля версий, организации могут получить полную видимость и возможность аудита изменений, вносимых в среду. Изменения в среде могут вноситься только командой инженеров платформы и только с использованием CI/CD.
Что выполняется в среде, в частности, как планируется запуск развернутого приложения или API, кто может его развернуть и т. д. Agile pods применяют непрерывное развертывание, чтобы гарантировать, что то, что попадает в производство, поддается аудиту и легко обратимо. Благодаря тому, что все состояние среды задается в виде кода внутри
Контроль версий позволяет при необходимости откатить код к предыдущему состоянию среды.
Контроль и возможность аудита производственной среды
CI/CD
ПРОИЗВОДСТВЕННАЯ СРЕДА
Въезд/выезд
Контроль доступа
Политики безопасности
Конфигурация
Контроль версий
Цифровое решение
ПРИЛОЖЕНИЕ 21.1
Обеспечьте безопасность, масштабируемость и доступность среды.
Для того чтобы производственная среда могла соответствовать требованиям цифровой трансформации, она должна обеспечивать три возможности:
Безопасность. Большинство данных, которые хранятся или передаются в среде про- дукции, должны быть зашифрованы. Шифрование гарантирует, что только авторизованные пользователи или приложения могут получить доступ к данным с помощью ключа. Поставщики облачных услуг предоставляют управляемые сервисы для управления ключами, например AWS Key Management Service, Azure Key Vault или Google Cloud Key Management Service.
Прямой доступ к среде должен быть ограничен и подвергаться аудиту. Каждый поставщик облачных услуг имеет богатые возможности контроля доступа, например IAM.
Масштабируемость. Базовая инфраструктура должна иметь возможность масштабироваться по мере необходимости в зависимости от спроса. Облачные провайдеры обладают подобными возможностями масштабирования, но компаниям необходимо настроить специальные сервисы для определения нагрузки на приложения, которые могут нуждаться в масштабировании. Например, Amazon предоставляет услугу AWS Auto Scal- ing, которая отслеживает нагрузку на приложения и масштабирует мощности для поддержания производительности. Компаниям необходимо четко продумать, какие сервисы они используют, поскольку каждый из них имеет свой собственный набор зависимостей.
Доступность. Несмотря на то что поставщики облачных услуг отличаются устойчивостью и надежностью, в их среде могут происходить сбои. Важно обеспечить возможность переключения с одной географии на другую без перебоев. Для этого существует множество механизмов, включая наличие отдельной посадочной зоны или вторичной производственной среды, работающей в другой географии, т. е. зеркальной производственной среды. Вторичная производственная среда использует тот же IaC, что и основная производственная среда. Компаниям необходимо настроить мониторинг на поиск сбоев и при их обнаружении переключиться с первичной среды на вторичную.
Включить мониторинг и наблюдаемость
Мониторинг кажется сухой темой, но он очень важен и часто неправильно понимается. Компаниям нужен хороший способ понять состояние и активность инфраструктуры, среды, решений, которые они создали, и пользователей этих приложений. Мониторинг основывается на знании того, что вы ищете, поэтому вы можете определить приборные панели для предупреждений, когда происходит то, что вы ищете:
Мониторинг приложений. Решения, которые разрабатывают agile pods, нуждаются в мониторинге для обеспечения надежности, а также для сбора обратной связи и телеметрии о том, как бизнес-пользователи взаимодействуют с решением. Обычно используются такие инструменты, как Datadog, New Relic или Dynatrace.
Мониторинг облаков и инфраструктуры. Сюда входит информация о том, какие данные поступают в ваше облако, кто его использует и какова производительность. Для этого можно использовать такие инструменты, как New Relic или Zabbix. Например, если вы используете традиционные виртуальные серверы в облаке, то понимание их поведения и нагрузки очень важно, особенно при диагностике проблем с производительностью приложений. Виртуальные серверы обычно имеют фиксированный размер, поэтому скачки нагрузки могут повлиять на производительность и скорость отклика для конечных пользователей. Мониторинг надежности потока данных и их качества - менее развитая область. Помимо упомянутых ранее инструментов, существуют и другие, например, инструменты мониторинга в Azure Data Factory, которые позволяют следить за поступлением данных.
Обратите внимание, что не существует единого инструмента мониторинга, который позволил бы организациям понять сквозной поток информации. Для целей производства команда разработчиков платформы должна определить, какие инструменты ей нужны, чтобы не только обеспечить надежность среды, но и быстро диагностировать проблемы, если они возникнут. На рис. 21.2 показана панель мониторинга производительности для решений McKinsey по аналитике корпоративных финансов. Эти решения доступны клиентам через веб-интерфейс или API.
Приборная панель, созданная с помощью инструментария New Relic, предоставляет типичную информацию о производительности приложений, которую должна отслеживать команда разработчиков решений. В верхней части приборной панели отслеживается время отклика, предоставляемое пользователям, включая показатели Adpex (соотношение удовлетворенных запросов к общему количеству запросов). Средняя часть помогает команде разработчиков определить функции (или транзакции, в данном случае), которые отвечают наименее оперативно, и таким образом подсказывает инженерам по облачным технологиям и программному обеспечению, какие функции следует улучшить в первую очередь. Наконец, нижняя часть помогает оптимизировать использование облачного хранилища и вычислений с течением времени, лучше согласуя потребности в эластичности рабочей нагрузки с приобретенным облачным сервисом.
Образец панели мониторинга для цифрового решения
30
15K
0
0
0K
5pm
7 вечера
9 вечера
5pm
7 вечера
9 вечера
11 вечера
5pm
7 вечера
9 вечера
11 вечера
ТРЕУГОЛЬНИК
30K
ФИЗИЧЕСКАЯ ПАМЯТЬ
60
ЗАГРУЗКА ПРОЦЕССОРА
9
6
3
ОБЗОР VM 1/31-2/7
20.7 61.5
Avg. CPUОбщее физическое использование память
Февраль 7 Февраль 8 Февраль 9 Февраль 10 Февраль 11 Февраль 12 Февраль 13
ОПЕРАЦИИ ПО ДНЯМ
ПОСЛЕДНЯЯ ОШИБКА
С 1 недели назад
О сайте
5 часов назад
TOP FAILED TRANSACTIONS Since 1 week ago
WebTransaction/Go/POST/run_binary 0.36%
WebTransaction/Go/POST/run/:section/:template 0.13%
WebTransaction/Go/POST/calculate 0.049%
WebTransaction/Go/POST/calculate/batched 0.012%
1.56 k
Неудачные транзакции
ОБЗОР ОШИБОК С 1 недели назад
0.017%
Неудачные транзакции в %
11 вечера
9 вечера
5pm 7 вечера
Продолжительность Предыдущая продолжительность
ОЦЕНКА ADPEX СЕГОДНЯ ПО СРАВНЕНИЮ С 1 НЕДЕЛЕЙ НАЗАД
С 7 часов назад по сравнению с 1 неделей назад
1.0
0.5
0
0.211
Самые медленные 10%/
продолжительность (90%)
ПРИБОРНАЯ ПАНЕЛЬ ПРИЛОЖЕНИЯ CPAT
ОБЗОР ТРАНЗАКЦИЙ С 1 недели назад
9.43M 0.124
Всего Среднее
транзакции продолжительность
САМЫЕ ПОПУЛЯРНЫЕ ОПЕРАЦИИ
WebTransaction/Go/POST/Calculate 2.74M Webtransaction/Go/POST/data 2.74M Webtransaction/Go/POST/batchgeo 1.05M Webtransaction/Go/GET/curencies 42.8K
ПРИЛОЖЕНИЕ 21.2
Каждое живое цифровое решение должно иметь панель мониторинга, которая отслеживает наиболее важные характеристики пользовательского опыта и производительности решения.
Глава 22. С самого начала создайте
для обеспечения безопасности и автоматизации
Почти все нарушения безопасности в облаке происходят из-за человеческих ошибок и неправильной конфигурации, а не из-за атак, нарушающих базовую облачную инфраструктуру.1 Облако требует безопасной конфигурации приложений и систем. Кроме того, традиционные механизмы кибербезопасности не рассчитаны на работу в требуемом темпе. В результате компаниям приходится применять новый подход к обеспечению безопасности, основанный на автоматизации.
Сдвиг влево в вопросах безопасности
"Сдвиг влево по безопасности" - это движение индустрии программного обеспечения, направленное на внедрение безопасности на более ранних этапах SDLC, а не на последнем (см. Рисунок 22.1). Этому есть два обоснования.
Во-первых, команды разработчиков быстрее решают проблемы безопасности в процессе написания кода. Любая проблема безопасности может быть решена agile-подразделением сразу же в процессе работы, не дожидаясь, пока она будет обнаружена позже (часто совершенно другой командой). Время цикла обнаружения и устранения проблем резко сокращается.
Во-вторых, каждый этап SDLC добавляет проверки безопасности в данный момент времени. Например, на этапе кодирования можно проверить уязвимости в сторонних компонентах, используемых при разработке. Если уязвимость будет обнаружена, это позволит команде найти альтернативные сторонние компоненты, которые можно использовать в качестве обходного пути.
Этот переход начинается с составления схемы ручного контроля и процессов управления, используемых для управления рисками и безопасностью на протяжении всего SDLC - как для инфраструктуры, так и для приложений. Сюда же относятся все обзоры рисков и безопасности. Как только это будет сделано, ищите инструменты и технологии, которые можно использовать для минимизации или устранения ручного (человеческого) контроля. Например, использование IaC (которые хранятся в системе контроля исходных текстов) дает дополнительное преимущество - возможность использовать инструменты для анализа уязвимостей безопасности или неправильной конфигурации до того, как они будут использованы другими командами. Статический анализ кода на IaC может гарантировать отсутствие уязвимостей в коде инфраструктуры (например, tfsec, checkov). Аналогично, многие команды используют модульные и многократно используемые компоненты с открытым исходным кодом для создания этих решений. Хотя открытый исходный код имеет много преимуществ, он также может создавать уязвимости безопасности, которые могут быть встроены в эти цифровые решения. Вы можете выявить и устранить эти уязвимые компоненты на ранних этапах SDLC с помощью таких инструментов, как Synk.
Повышение безопасности путем "сдвига влево"
От: Оставляем безопасность напоследок - Проверка безопасности после развертывания программного обеспечения
Тест
Пакет
Построить
Развернуть
Безопасность
Работайте на сайте
Код
Обнаружение проблем безопасности на ранней стадии может иметь большие репутационные и финансовые последствия
Для: "Смещение влево" в вопросах безопасности - проверки и процедуры безопасности включены в каждый этап SDLC
Безопасность
Развернуть
Работайте на сайте
Тест
Безопасность
Безопасность
Пакет
Безопасность
Безопасность
Построить
Код
Заблаговременное устранение последствий может помочь избежать катастрофических проблем в дальнейшем
ПРИЛОЖЕНИЕ 22.1
Внедрение безопасности в SDLC с помощью DevSecOps
Реализация подхода "сдвиг влево" требует DevSecOps, который встраивает безопасность в подход DevOps. Это означает интеграцию экспертов по безопасности в команды DevOps и внедрение средств обеспечения безопасности на протяжении всего процесса SDLC. Автоматизация - один из основных принципов этого подхода. В рамках одного и того же сквозного процесса CI/CD команда разработчиков платформы внедряет инструменты для проверки и устранения рисков безопасности (см. Рисунок 22.2). Цель состоит в том, чтобы со временем перейти к 100 % автоматизации проверок безопасности.
Внедрение DevSecOps в процесс доставки
Примеры тестирования безопасности, выполняемого в течение всего жизненного цикла разработки программного обеспечения
Непрерывная интеграция и непрерывная доставка
Код Build
Тест Пакет
Развернуть Эксплуатировать
Обнаружение вредоносных плагинов интегрированной среды разработки или сторонних компонентов, а также проверка на наличие конфиденциальной информации в коде
Обеспечение контроля доступа, сканирование на наличие недокументированных портов и проведение автоматизированного тестирования на проникновение.
Проверка уязвимостей в технологии упаковки перед развертыванием на производстве
Проведение динамического тестирования безопасности приложений для обнаружения уязвимостей в создаваемых приложениях
Устранение уязвимостей в компонентах сторонних разработчиков с помощью анализа компонентов программного обеспечения
Запустите Runtime Application Security Protection для выявления угроз во время выполнения и отслеживания необычного поведения приложений.
ПРИЛОЖЕНИЕ 22.2
Реализация проверок безопасности в CI/CD:
Код
С помощью таких инструментов, как Synk, проверьте, не были ли установлены разработчиками вредоносные плагины интегрированной среды разработки (IDE), которые вносят уязвимости в код. Проверьте, не хранятся ли в системе контроля исходных текстов секреты (например, с помощью git-секретов от AWS или встроенных инструментов проверки секретов, которые есть в некоторых системах контроля исходных текстов, например, сканирование секретов GitHub). Наконец, запустите статическое тестирование безопасности приложений (SAST), которое анализирует написанный код. Это зависит от языка; для IaC можно использовать инструмент типа tfsec, а для кода на Python - инструмент типа semgrep.
Построить
Проведите динамическое тестирование безопасности приложений (DAST), которое ищет уязвимости в создаваемых приложениях. Для этого можно использовать такие инструменты, как appcheck или инструмент OWASP Zed Attack Proxy с открытым исходным кодом. Проведите интерактивное тестирование безопасности приложений (IAST), которое ищет уязвимости во время работы цифрового приложения. Для этого можно использовать такие инструменты, как Synopsys или Veracode.
Тест
Проверьте, соблюдаются ли традиционные средства контроля доступа к цифровому приложению. Проверьте, применяются ли средства контроля доступа (роли или политики) и ограничьте доступ соответствующим образом. Проверьте, открыты ли недокументированные порты (кроме необходимых и защищенных).
Пакет
Убедитесь, что уязвимые компоненты сторонних разработчиков не были внедрены, используя анализ компонентов программного обеспечения (SCA).
Развернуть
Проверьте все уязвимости, которые могли быть устранены до развертывания в производстве. Это может быть технология упаковки (например, Docker) или поиск внутри пакета с помощью SCA.
Работайте на сайте
Запустите защиту безопасности приложений во время выполнения (RASP), которая ищет внутренние данные цифрового приложения, чтобы идентифицировать угрозы во время выполнения. Отслеживайте необычное поведение приложений с помощью традиционных инструментов мониторинга/наблюдения, таких как Datadog.
По их словам: Правильное мышление и сдвиг влево
Служба безопасности может показаться властной, но у нас очень тесные отношения. У нас есть программа, которую мы называем "security maven", для обучения и сертификации людей по безопасности во всем нашем бизнесе, будь то разработчики, владельцы продуктов или инженеры. У них также есть спонсоры в команде безопасности, и когда они выполняют проекты и находят вещи, требующие исправления, они представляют свою работу высшему руководству, и мы отмечаем эти победы. Таким образом, мы закрепляем эти навыки в наших командах, потому что невозможно быть везде.
Мы также пытаемся "сдвинуться влево", создавая систему безопасности в начальных проектах всего, что мы создаем в облаке. Поскольку "облако" движется так быстро, если вы не сместитесь влево, то упустите возможность, и потом вам придется постоянно заниматься уборкой.
Кейси Сантос, ИТ-директор Asurion
Внедрение автоматизации безопасности должно быть частью мандата команды DevSecOps при разработке конвейера CI/CD, включая обучение подгрупп ее использованию.
Примечания
Арул Элумалай, Джеймс Каплан, Майк Ньюборн и Роджер Робертс, "Обеспечение безопасного перехода к публичному облаку", McKinsey.com, 1 января 2018 г., https://www.mckinsey.com/capabilities/mckinsey- digital/our-insights/making-a-secure-transition-to-the-public-cloud.
Джим Боэм, Чарли Льюис, Кэтлин Ли, Дэниел Уолланс и Деннис Диас, "Тенденции кибербезопасности: Заглядывая за горизонт", McKinsey
.com, 10 марта 2022 г., https://www.mckinsey.com/capabilities/risk- and-resilience/our-insights/cybersecurity/cybersecurity-trends-looking-over-the-horizon.
Глава 23.
MLOps
, чтобы ИИ мог масштабироваться
Для того чтобы AI/ML внес значительный вклад в итоговый результат компании, организации должны масштабировать технологию по всей организации, внедряя ее в основные бизнес-процессы, рабочие процессы и путешествия клиентов для оптимизации принятия решений и операций в режиме реального времени. Это особенно сложно в случае с моделями AI/ML, поскольку они представляют собой "живые организмы", которые меняются вместе с базовыми данными. Они требуют постоянного мониторинга, переобучения и дебилизации, что является сложной задачей даже для нескольких ML-моделей, но просто непреодолимой для сотен.
Определение ключевых терминов
Искусственный интеллект (ИИ) охватывает широкую концепцию создания умных интеллектуальных машин.
Машинное обучение (ML) - это подмножество искусственного интеллекта. Это метод, который "учится" на данных, чтобы повысить эффективность выполнения некоторого набора задач.
Глубокое обучение - это подмножество машинного обучения. Оно использует огромные объемы данных и сложные алгоритмы для обучения модели.
В последние годы масштабное совершенствование инструментов и технологий ML значительно изменило рабочие процессы ML, ускорило жизненный цикл приложений и позволило последовательно и надежно масштабировать AI в бизнес-области. Однако, несмотря на все эти новые возможности, необходимо помнить, что эффективная работа с ML (MLOps) требует сосредоточения на всем комплексе работ по разработке приложений, а не только на самих моделях. По нашим оценкам, до 90 % неудач в разработке ML связаны не с разработкой плохих моделей, а с неэффективной практикой продуктивизации и проблемами интеграции модели с производственными данными и бизнес-приложениями, которые не позволяют модели масштабироваться и работать как положено. Эффективная продуктизация требует разработки интегрированного набора компонентов для поддержки модели (или, зачастую, набора моделей), таких как активы данных, алгоритмы ML, программное обеспечение и пользовательский интерфейс.
MLOps - это набор практик, которые применяются на протяжении всего жизненного цикла модели ML (см. Рисунок 23.1):
Данные: Создание систем и процессов, позволяющих непрерывно собирать, хранить, анализировать, маркировать и поддерживать высококачественные данные в масштабе для приложений ML.
Разработка моделей: Профессионализация разработки моделей, чтобы гарантировать, что высококачественные алгоритмы могут быть объяснены, не являются предвзятыми, работают так, как ожидается, и постоянно контролируются и регулярно обновляются с использованием свежих данных.
Конвейеры данных и моделей: Максимальное увеличение ценности для бизнеса и снижение затрат на проектирование за счет создания интегрированных конвейеров приложений, которые принимают данные или события, обрабатывают и обогащают их, запускают модель, обрабатывают результаты, генерируют действия, отслеживают различные компоненты и бизнес-показатели.
Разработка и масштабирование: Усовершенствование компонентов обработки данных и обучения моделей для работы в масштабе, включая добавление тестов, проверку, безопасность, CI/CD и переобучение моделей.
Оперативная работа: Активный мониторинг ресурсов, производительности и бизнес-показателей.
Это непрерывный процесс, требующий от вас создания надежных инженерных решений и практик применения ML для непрерывной разработки, тестирования, развертывания, обновления и мониторинга комплексных приложений AI. MLOps опирается на концепции DevOps и сквозной автоматизации, о которых говорилось ранее, и учитывает уникальные особенности ИИ, такие как вероятностный характер результатов ML и зависимость технологии от базовых данных.
Когда компании внедряют лучшие практики MLOps, это позволяет значительно повысить планку достижений. Это разница между экспериментами с искусственным интеллектом и преобразованием конкурентной позиции вашей компании с помощью искусственного интеллекта. Эффективная MLOps основывается на внедрении четырех ключевых практик:
Обеспечение доступности, качества и контроля данных для питания системы ML
ML-модели зависят от данных. Без качественных и доступных данных модели ML будут неточными и непригодными для использования. Поэтому необходимо внедрить проверку качества данных. Сейчас доступны инструменты для оценки качества данных и выявления аномалий, чтобы найти ошибки. Это полезно в сценариях с высокой пропускной способностью, таких как мониторинг финансовых транзакций.
Чтобы обеспечить доступность данных для ML-моделей, необходимо извлечь из исходных данных те характеристики, которые будут использоваться в ML-модели.
Жизненный цикл модели AI/ML
Импорт соответствующих наборов данных (извлечение из общих данных) Понимание структуры и статистики данных
Очистка и дезинфекция
Маркировка, изучение и обогащение данных для выявления потенциальных закономерностей и особенностей Анализ характеристик
Перекрестные связи между признаками и корреляционный анализ Создание прототипов моделей и оценка важности признаков
Обучение и проверка модели с различными параметрами и комбинациями алгоритмов Оценка и тестирование модели
Интеграция с API и источниками данных в режиме реального времени Предварительная обработка и обогащение данных
Прогнозирование модели Постобработка
Начало действий или ответных мер
Автомасштабирование
Контейнеризация моделей
Добавление фреймворков автоматизации
Мониторинг
Сопровождение модели Валидация производительности Непрерывное совершенствование Поддержка пользователей
Операции в реальном времени
Обратная связь
Модель данных и конвейеры
Разработка модели
Данные
Производство и масштабирование
ПРИЛОЖЕНИЕ 23.1
Эти характеристики являются топливом для ML-моделей. Например, барометрическое давление измеряется атмосферными датчиками, но в модели прогнозирования погоды функцией является изменение барометрического давления. Хранилище признаков - это центральное хранилище этих признаков. Хранилища признаков
управлять, поддерживать и контролировать функции, обеспечивая постоянный доступ к топливу, необходимому для моделей ML.
Предоставление инструментария для оптимизации разработки ОД
Написание воспроизводимого, поддерживаемого и модульного кода для науки о данных не является тривиальной задачей. Программные фреймворки, такие как Kedro (на языке Python), призваны облегчить эту задачу. Они заимствуют концепции из программной инженерии, включая модульность, разделение проблем и версионирование, и применяют их к коду ML.
Специалисты по исследованию данных любят экспериментировать, пробуя различные данные/функции и различные алгоритмы, чтобы разработать модель, удовлетворяющую бизнес-результатам. Эти эксперименты необходимо где-то хранить вместе с любыми связанными с ними метаданными (например, использованные функции или дополнительные конфигурации модели). Такие инструменты, как MLflow и MLRun, обеспечивают управление моделью и возможность воспроизведения этих экспериментов, а также отслеживают, какие эксперименты привели к лучшему бизнес-результату.
Внедрите платформу доставки ML, чтобы максимально автоматизировать процесс.
Переход от небольших исследований в области науки о данных и разработки моделей к крупномасштабному производству часто связан с рефакторингом кода, сменой фреймворков и значительными инженерными работами. Эти шаги могут привести к существенным задержкам или даже к отказу от всего решения.
Очень важно разработать и внедрить платформу непрерывной доставки приложений ML. Эта платформа должна выполнять масштабируемые и автоматизированные конвейеры для обработки данных, обучения, валидации и упаковки высококачественных моделей для производства. Кроме того, платформа ML должна развертывать конвейеры онлайн-приложений, которые включают обученную модель, выполняют задачи предварительной или последующей обработки данных, интегрируются с источниками данных и другими приложениями, а также собирают важные данные, модели, приложения и бизнес-метрики для наблюдения.
Мониторинг производительности модели для постоянного совершенствования
ML-модели не похожи на программное обеспечение. Когда программное обеспечение развертывается в производство, оно должно работать так, как ожидается (при условии, что внимание было сосредоточено на качестве и тщательном тестировании). С другой стороны, ML-модели "обучаются", а это значит, что люди должны следить за тем, как работает каждая модель, и со временем корректировать ее для улучшения результатов. Кроме того, ML-модели чувствительны к условиям реальных данных и могут со временем деградировать, поэтому важно следить за их правильным поведением.
Например, когда мы были заблокированы во время всемирной пандемии, поведение клиентов изменилось в одночасье. ML-модели, которые были обучены на исторических моделях расходов клиентов (до пандемии), больше не могли делать эффективные прогнозы, например модели, рекомендующие клиенту посетить ресторан, несмотря на то что рестораны были закрыты. Вот почему мониторинг производительности моделей и возможность быстро диагностировать причину отклонений имеют решающее значение.
Мониторинг модели должен выходить за рамки поиска дрейфа. Он должен также проверять качество и соответствие данных, измерять точность и производительность модели в соответствии с бизнес-показателями. Такой более широкий взгляд на мониторинг особенно важен для того, чтобы компании не просто зацикливались на производительности модели, а оценивали, насколько она помогает бизнесу.
MLOps - это быстро развивающаяся область. На момент написания этой статьи более 60 поставщиков предлагают различные программные инструменты MLOps - от готовых платформ до нишевых инструментов.
Пример из практики: Сокращение времени разработки приложений ИИ
Азиатская компания, предоставляющая финансовые услуги, смогла сократить время разработки новых приложений искусственного интеллекта более чем на 50 %. Она создала общий слой данных поверх исходных систем, который обеспечил высококачественные, готовые к использованию продукты данных для использования в многочисленных клиент-ориентированных приложениях ИИ.
Компания стандартизировала инструменты и процессы управления данными, чтобы создать устойчивый конвейер данных, и создала активы для стандартизации и автоматизации трудоемких этапов, таких как маркировка данных и отслеживание их происхождения. Это разительно отличалось от прежнего подхода компании, при котором команды структурировали и очищали необработанные данные из исходных систем, используя разрозненные процессы и инструменты каждый раз, когда разрабатывалось приложение для искусственного интеллекта. Такой подход приводил к длительному циклу разработки ИИ.
Примечание
1. Джакомо Корбо, Дэвид Харви, Найюр Хан, Николас Хон, Киа и Джаванмардиан, "Масштабирование ИИ как технарь: Роль генерального директора", McKinsey
.com, 13 октября 2021 г., https://www.mckinsey.com/capabilities/ quantumblack/our-insights/scaling-ai-like-a-tech-native-the-ceos-role.
Раздел 4
Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:
Есть ли у вас технологическая среда, способная привлечь и вдохновить современных специалистов, работающих с облачными технологиями?
Сколько компаний могут разрабатывать и непосредственно выпускать новые версии своих цифровых решений для клиентов/пользователей?
Каково время цикла выпуска (и уверены ли вы, что измеряете его правильно)?
Как узнать, что вы строите хорошо/ответственно, а не просто быстро?
Каково соотношение инвестиций в фундамент и новых функций, необходимых для достижения успеха, и есть ли у вас процесс, позволяющий это сделать?
Какая часть ваших инженерных разработок использует подход непрерывной интеграции/непрерывной доставки?
Какова доля ваших рабочих нагрузок в облаке и какой должна быть цель?
Насколько хорошо функция безопасности интегрирована в процесс разработки и автоматизирована?
Хорошо ли откалиброваны ваши модели AI/ML, находящиеся в производстве? Как вы узнали об этом?
Встраивание данных
Везде
Что нужно, чтобы сделать данные удобными для использования в организации
В крупных компаниях данные часто становятся источником разочарования. По нашему опыту, до 70 % усилий по разработке решений на основе искусственного интеллекта приходится на работу с данными и их согласование. Многие из этих проблем могут быть связаны с унаследованными, изолированными друг от друга системами, поэтому очень важно продумать архитектуру данных для удобства их потребления и повторного использования; в противном случае масштабирование становится проблематичным. Цель состоит в том, чтобы иметь чистые, актуальные и доступные данные, чтобы agile pods могли использовать их для принятия лучших решений и создания лучших решений на основе данных.
Основной единицей для достижения этой цели является продукт данных - набор элементов данных, которые собраны и упакованы таким образом, что любая команда или приложение в организации может легко их использовать.1
Какие продукты данных вам нужны и какие элементы данных они должны содержать? Этот вопрос всегда является первым, с которого следует начать, и ответы на него. Чтобы сосредоточить усилия на самых ценных данных, следует руководствоваться "дорожной картой" цифровых технологий.
Чтобы упростить разработку продуктов данных, ведущие компании внедряют надежную архитектуру данных, которая позволяет данным эффективно "перетекать" из места их получения в место их использования. Они также внедряют федеративную модель управления данными, в которой бизнес-лидеры выступают в качестве спонсоров данных и продуктов данных, которыми они владеют. В этом разделе мы расскажем вам, как превратить ваши данные в конкурентное преимущество2.
Глава 24: Определите, какие данные важны. Оцените, какие части вашего хранилища данных нуждаются в исправлении, исходя из того, какую ценность они могут создавать, и разработайте план, как привести их в соответствие с полезным стандартом готовности.
Глава 25: Продукты данных: Многоразовые строительные блоки для масштабирования. Реализуйте как краткосрочную, так и долгосрочную ценность инвестиций в данные, управляя ими как продуктами. Специальные команды делают эти продукты данных удобными для безопасного использования любым подразделением.
Глава 26: Архитектура данных, или система "труб" данных. При построении целевой архитектуры данных учитывайте потребности вашей организации как в BI (бизнес-аналитике), так и в AI (искусственном интеллекте). Используйте существующие эталонные архитектуры, чтобы снизить сложность реализации.
Глава 27: Организуйте работу, чтобы получить максимальную отдачу от данных. Разъясните принципы управления данными и убедитесь, что у вас есть необходимые специалисты и инструменты для работы с данными, чтобы постоянно улучшать их состояние.
Примечания
Вирал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Как раскрыть всю ценность данных? Управляйте ими как продуктом", McKinsey.com, 14 июня 2022 года, https://www.mckinsey.com/capabilities/quantumblack/our-insights/ how-to-unlock-the-full-value-of-data-manage-it-like-a-product.
Верал Десаи, Тим Фаунтейн и Кайбаун Роушанкиш, "Лучший способ заставить ваши данные работать", Harvard Business Review, июль-август 2022 года, https://hbr.org/2022/07/a-better-way-to-put-your-data-to-work; "Предприятие 2025 года, управляемое данными: Семь характеристик, определяющих новое предприятие, управляемое данными", McKinsey.com, 28 января 2022 г., https://www.mckinsey.com/capabilities/quantumblack/our-insights/ the-data-driven-enterprise-of-2025?linkId=150307929.
Определите, какие данные важны
Стратегия работы с данными определяет, какие данные вам нужны и как их подготовить для выполнения приоритетных задач бизнеса. Результатом является план по очистке данных и обеспечению легкого доступа к ним.
Определение и приоритизация данных
Начните с определения данных, необходимых для реализации цифровых решений и базовых сценариев использования, прописанных в "дорожной карте" цифровых технологий. Дорожная карта часто определяет потребности в данных на высоком уровне, но их необходимо перевести в конкретные потребности в данных.
Определение ключевых терминов
Элемент данных: Базовая единица информации, имеющая уникальное значение, например, имя клиента, адрес клиента, название продукта, дата.
Домен данных: Концептуальная группировка связанных данных, часто используемая для организации усилий по управлению данными и архитектуры данных.
Продукт данных: Высококачественный, готовый к использованию набор данных, к которому могут легко получить доступ и использовать люди в организации. Обычно это подмножество домена данных.
Почти в каждом случае вы обнаружите, что у вас больше данных, чем нужно для начала работы. Определите приоритетность доменов данных, исходя из их важности для бизнеса в реализации цифровой дорожной карты, а также других соображений, таких как риск и нормативные требования.
Такая расстановка приоритетов должна распространяться и на элементы данных в каждом домене данных, чтобы определить, что имеет наибольшее значение. Например, в домене данных о клиенте могут быть сотни или тысячи элементов данных, таких как имя, адрес и номер кредитной карты. Определите элементы, которые наиболее важны для реализации сценария использования (обычно это ~10-15 % всех элементов данных), и сосредоточьте на них большую часть своих усилий. Для одной американской страховой компании, желающей предложить своим клиентам рекомендации по усиленной защите имущества, процесс расстановки приоритетов означал сосредоточение внимания на данных о катастрофах и безопасности (например, данные о риске бедствий, полученные от Национального управления океанических и атмосферных исследований, Геологической службы США и Федерального агентства по управлению чрезвычайными ситуациями), а также на данных о рынке активов, таких как исторические цены на недвижимость, история покупок и индексы района (см. Рисунок 24.1).
Пример решения, сценарий использования и связанные с ним потребности в данных
Пример страховой компании
Советники
Внутренние функции
БИЗНЕС-ДОМЕНЫ
Продажи
Обслуживание клиентов
Решения
Примеры использования
Домены данных
Цифровое хранилище
Обеспечение микрополитики и предоставление услуг
Подробная документация
Атрибуты внешнего потребителя
Индекс соседства
История приобретения недвижимости
Данные о ценах на недвижимость
Вероятность наводнения по данным FEMA
Советы по защите имущества
Индекс риска землетрясений Геологической службы США по округам США
Данные о рынке активов
Индекс риска ураганов NOAA по округам США
Данные о катастрофах и безопасности
Помогите защитить активы
Цифровой след клиента
Размещение на случай жизненных событий
Помощь в управлении учетной записью и политикой
Общие активы и послужной список
Система отслеживания рисков
Помогите подготовиться к чрезвычайным ситуациям
Помогите оптимизировать покрытие
Рекомендовать дополнительные услуги
Консультант по дополнительным услугам
Консультант с оплатой за услуги
Профиль застрахованного лица и демографические данные
Данные о стоимости автомобильного рынка
Рекомендации по микрополитике
Страховые предпочтения
Консультант по комплексному обслуживанию
Каналы взаимодействия
Советы по защите
Быстрая связь
Оценка готовности данных
Нередко данные, необходимые для решения, могут быть низкого качества. Это создает классическую проблему "мусор в дом, мусор из дома", когда некачественные данные подрывают прогресс в области цифровых преобразований и ИИ. Прежде чем исправлять или очищать данные, необходимо определить, что с ними не так, тщательно оценив их (иногда это называют "опросом данных"). Девять аспектов оценки качества данных показаны на рисунке 24.2.
Девять параметров для оценки качества данных
Точность
1
Степень соответствия данных согласованному источнику
Своевременность
Временные рамки, в течение которых данные должны обновляться, и допустимое "запаздывание" системы при изменении значений
2
Последовательность
Степень, в которой идентичные данные должны иметь одинаковое значение, где бы они ни хранились или отображались
3
Полнота
4
Степень заполнения поля, а также необходимая широта, глубина и история.
Уникальность
Степень, в которой данные должны храниться в одном месте и быть уникальными для одного клиента
5
Когерентность
Степень, в которой определения данных остаются одинаковыми с течением времени, так что исторические данные имеют одинаковый контекст
6
Доступность
7
Степень доступности текущих и исторических данных для анализа
Безопасность
Степень надежности хранения данных, ограничение доступа к ним и возможность восстановления
8
Взаимозаменяемость
Степень четкости определений данных, позволяющая легко их понимать
9
ПРИЛОЖЕНИЕ 24.2
Оценка данных по этим параметрам включает три этапа для каждого элемента данных. Во-первых, учитывая известные и вероятные будущие потребности бизнеса в данных, определите набор правил качества данных. Например, возьмем элемент данных "адрес клиента": Правило, актуальное для многих B2C-организаций, гласит: "Адрес клиента должен быть точным".
Во-вторых, для каждого правила установите целевой показатель, отвечающий потребностям бизнеса. Например, целевой показатель точности для правила "адрес клиента точен" может составлять >95 %. Более высокая точность важна, если компания отправляет клиенту посылку, но менее критична, если компания предлагает цифровые услуги. Избегайте внесения изменений в целевые показатели, которые выходят за рамки области применения, так как они стимулируют внутренние усилия по управлению данными.
В-третьих, измеряйте качество данных и составляйте отчеты о результатах работы в соответствии с установленными правилами качества данных. Большинство компаний используют программные пакеты (например, Talend Open Studio, Ataccama ONE, Informatica Data Quality) для измерения производительности в соответствии с правилами и проведения более широкого сканирования для выявления проблем с качеством данных. Независимо от того, используется программное обеспечение или нет, процесс определения правил качества данных и целевых показателей остается критически важным.
При правильном подходе этот процесс может выявить целый ряд проблем, включая неточные значения данных, приводящие к неправильным расчетам, различия в определениях бизнес-подразделений, приводящие к неправильному использованию данных, и задержки в интеграции данных, приводящие к тому, что данные не успевают к сроку сдачи отчетности.
Одна из самых больших проблем, с которой сталкиваются компании в ходе этого процесса, заключается в том, что оценка качества данных и их очистка могут отнимать много времени и стоить дорого, хотя мы видим, что появляются инструменты искусственного интеллекта, которые помогают в этом процессе. По этой причине важно сосредоточиться на наиболее важных данных для ваших приоритетных сценариев использования. Например, в страховой компании, о которой идет речь в Примере 24.1, важно было иметь данные, которые были бы менее трех месяцев назад и были легко доступны, а также отвечали строгим требованиям конфиденциальности и секретности. Но они не должны были быть на 100 % точными. Или в случае с компанией, занимающейся недвижимостью, актуальность данных была крайне важна, но только на рынках Нью-Йорка и Лос-Анджелеса.
Разработка минимального жизнеспособного продукта (MVP) с использованием менее совершенных данных может быть успешной, если имеется необходимая критическая масса данных и команда четко понимает, какую ценность они хотят получить. Кроме того, компании все чаще обращаются к инструментам машинного обучения и искусственного интеллекта, таким как Talend, Trillium Quality, Sypherlink, Syncsort и AI4DQ1, чтобы очистка существующих данных (хотя некоторые проблемы всегда требуют определенных ручных усилий, например, выравнивание иерархии продуктов в регионах для согласованной глобальной отчетности).
Во многих случаях качество и тип данных, которыми располагает компания, можно улучшить с помощью процесса, называемого "обогащением данных". Вы можете использовать несколько способов улучшения имеющихся данных, например, привлекая внешние источники или добавляя новые источники данных (например, датчики, веб-сайты). Обогащение данных происходит постоянно. На практике это означает, что ваши бизнес и функциональные руководители должны отчитываться о своих планах по улучшению активов данных с течением времени и делать необходимые инвестиции. Хорошая идея - сделать такую отчетность частью ежегодного планирования.
Разработка дорожной карты данных
После определения приоритетного набора данных и их текущей готовности следующий шаг - создание дорожной карты данных. По сути, это план последовательности работ, необходимых для того, чтобы данные могли поддерживать цифровые решения, определенные в стратегической "дорожной карте". Эта работа имеет решающее значение для определения и выделения необходимых ресурсов для подготовки данных.
По нашему опыту, вы будете работать на трех разных уровнях параллельно:
Уровень 1 сосредоточен на создании капсул данных, которые будут выполнять конкретную работу по обеспечению готовности приоритетных элементов данных и созданию путей потребления этих данных (подробнее об этом в следующей главе).
Второй уровень посвящен разработке архитектуры каналов передачи и хранения данных, которые будут обслуживать ваши приоритетные домены данных и последующие (см. главу 26).
Уровень 3 закладывает основу для здорового управления данными, чтобы все ваши усилия по очистке и обработке данных не пропали даром, обеспечивая правильный сбор будущих данных (см. главу 27).
Примечание
1. AI4DQ - это продукт компании QuantumBlack AI by McKinsey.
Глава 25.
Продукты для работы с данными: Многоразовые строительные блоки для масштабирования
Чтобы получить как краткосрочную, так и долгосрочную отдачу от инвестиций в данные, управляйте ими как потребительским продуктом. Продукт данных - это высококачественный, готовый к использованию набор данных, отформатированный таким образом, чтобы люди и системы в организации могли легко получить к нему доступ и применить для решения различных бизнес-задач. Например, продукт данных может предоставлять 360-градусный обзор важного объекта, такого как клиенты, сотрудники, продуктовые линейки или филиалы. Одним из новых направлений является использование продукта данных в качестве основы цифрового двойника, который воспроизводит работу реальных активов.
Подробнее о цифровых двойниках
Цифровой двойник - это виртуальное представление физического актива, человека или процесса. Благодаря огромному количеству данных, получаемых от встроенных датчиков и IoT-устройств, телематике и моделям искусственного интеллекта, которые постоянно обучаются, технология цифровых двойников быстро становится важным компонентом цифровых преобразований и преобразований с использованием искусственного интеллекта.
Цифровые двойники состоят из двух основных частей: эмуляторов и симуляторов. Эмуляторы - это продукты данных, которые объединяют разрозненные наборы данных для мониторинга реальных систем. Эмуляторы обеспечивают возможность захвата, хранения и воспроизведения данных в масштабе (например, мониторинг сбоев в работе сети, выявление узких мест на производственной линии). С другой стороны, симуляторы - это программные приложения, основанные на реальных данных, которые позволяют компаниям экспериментировать с гипотетическими сценариями "что-если", такими как перенаправление запасов через логистическую сеть и изменение конструкции двигателя.
Наиболее зрелые организации, ориентированные на данные, начали объединять эти два элемента для создания цифровых двойников, которые постоянно предупреждают, анализируют, прогнозируют и самообучаются. Такой подход позволяет со временем обогащать данные, что дает возможность проводить дальнейшие моделирования или сценарии использования, в результате чего создается цифровой двойник, способный решать многие бизнес-задачи со значительной рентабельностью инвестиций.
Появляются успешные приложения цифровых двойников. Классическим примером цифрового двойника является 360-градусное представление о клиентах, включающее все данные, которые собирают о них бизнес-подразделения и системы компании - например, поведение при покупке в Интернете и в магазине, демографические данные, способы оплаты и взаимодействие со службой поддержки. Варианты использования ИИ на основе этого двойника могут включать модели склонности клиентов к оттоку или корзину следующих товаров, которые клиент, скорее всего, купит.
В качестве альтернативы двойник может воспроизводить работу реальных активов или процессов (например, всей производственной линии на заводе или критически важных частей оборудования) и генерировать информацию о среднем времени простоя оборудования или среднем времени на завершение работы.
сборка изделий. Варианты использования ИИ могут включать прогнозирование технического обслуживания, автоматизацию и оптимизацию процессов.
Для успешных проектов по созданию цифрового двойника требуются специализированные многопрофильные гибкие команды, включающие специалистов по изучению данных, инженеров по данным, дизайнеров, разработчиков и экспертов в данной области, которые работают в унисон для решения конкретных задач.1
Это представляет собой фундаментальный сдвиг в том, как компании думают о данных и управляют ими (см. иллюстрации 25.1 и 25.2).
Таким образом, продукты данных становятся секретным соусом для масштабирования. Преимущества такого подхода могут быть значительными. Новые бизнес-показатели могут быть реализованы на 90 % быстрее. Общая стоимость владения, включая затраты на технологию, разработку и обслуживание, может снизиться на 30 %. И наконец, можно существенно снизить риски и нагрузку на управление данными.
Продукты данных включают в себя проводку, необходимую для "потребления" данных различными бизнес-системами, например цифровыми приложениями или системами отчетности. У каждого типа бизнес-систем есть свой набор требований к хранению, обработке и управлению данными; мы называем их "архетипами потребления".
Примеры продуктов данных
Продукт данных, представляющий собой 360-градусный обзор телекоммуникационной сети, включает в себя данные датчиков сети (например, данные с вышек сотовой связи, домов или оптоволокна) и описательные данные (например, спецификации элементов сети или данные о потребителях и затратах) и создает цифровое представление всей сети. Полученные данные позволяют использовать их в различных операционных и потребительских целях - например, оценить, что произойдет с качеством обслуживания клиентов, если та или иная часть сети выйдет из строя, и определить улучшения сети, чтобы уменьшить это влияние.
Например, продукт данных для инвестиций, ориентированных на экологические, социальные и управленческие показатели (ESG), мог бы принести
объединяет такие сведения об активах, как углеродоемкость, внешние оценки ESG и данные о владении портфелем, чтобы понять общую инвестиционную подверженность данному активу. Этот продукт позволяет управляющему активами рассчитать, насколько благоприятны с точки зрения ESG текущие и потенциальные будущие инвестиционные продукты его организации, и выделить действия, которые организация должна предпринять для выполнения своих внешних обязательств (например, для достижения нулевого воздействия на углерод).
Унаследованная система данных во многих организациях может быть сложной и неэффективной.
Конвейеры данных, предназначенные для пакетной доставки и доставки в режиме реального времени, фрагментированы и дублируют друг друга.
Для каждого случая использования применяются разные технологии, что увеличивает расходы и усложняет работу.
Озеро необработанных данных
Основные системы обработки данных
Внешние данные
Неструктурированные данные
Хранилище данных
Поток данных
Системы учета
Хранилище оперативных данных
Цифровое банковское приложение
Инвестиционный портал
Предиктивная модель перекрестных продаж
Предиктивная модель оттока
Финансовый отчет
Отраслевая экосистема данных
Примеры использования
технологии
наборы данных
Использование в зависимости от конкретного случая Использование в зависимости от конкретного случая
Платформа данных
Данные для каждого домена, например клиента, неэффективно перерабатываются для каждого случая использования; качество, определения и форматы различаются.
Источник: Верал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Лучший способ использовать данные в работе", Harvard Business Review, июль-август 2022 г.
Подход, основанный на использовании продуктов данных, приводит к стандартизации, что экономит время и деньги
Поток данных 
Системы учета
Поставщик
Цифровые приложения
Цифровое банковское приложение
Инвестиционный портал
Клиент
Расширенная аналитика
Филиал
Предиктивная модель перекрестных продаж
Отчетность
Продукт/услуга
Предиктивная модель оттока
Обмен внешними данными
Финансовый отчет
Работодатель/ Данные по отрасли
агент экосистема
Discovery Песочница данных исследование
Платформа данных
Продукты данных
Архетипы потребления
Примеры использования
Основные системы обработки данных
Хранилище данных
Внешние данные
Озеро необработанных данных
Неструктурированные данные
Хранилище оперативных данных
Источник: Верал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Лучший способ использовать ваши данные в работе".
Harvard Business Review, июль-август 2022 г.
ПРИЛОЖЕНИЕ 25.2
Хотя в "дорожной карте" организации могут быть сотни вариантов использования, обычно она потребляет данные одним из пяти способов, которые мы называем архетипами потребления (см. Рисунок 25.3). Продукты данных, созданные для поддержки одного или нескольких таких архетипов потребления, могут быть легко использованы в нескольких бизнес-приложениях с аналогичными архетипами.
Не каждый элемент данных должен быть упакован в продукт данных. Сосредоточьтесь только на тех, которые имеют высокую степень многократного использования в различных случаях применения. Например, в продукте данных "Клиент-360", возможно, информация о геолокации зданий клиента необходима как часть решения для оценки риска безопасности, но эта информация не имеет смысла использовать другие решения. В этом случае имеет смысл получать данные непосредственно из платформы данных или исходных систем с помощью специального конвейера данных, созданного специально для этих целей.
Архетипы потребления продуктов данных
ARCHETYPE ТРЕБОВАНИЯПРИМЕР ИСПОЛЬЗОВАНИЯ
Цифровые приложения
Очистка и хранение специфических данных в определенном формате и с определенной периодичностью (например, предоставление доступа в режиме реального времени к потокам данных GPS или датчиков)
Приложение для маркетинговых трендов или приложение для отслеживания транспорта
Передовые аналитические системы
Очистка и предоставление данных с определенной периодичностью, а также их обработка системами машинного обучения и искусственного интеллекта
Механизмы моделирования и оптимизации
Системы отчетности
Высокоуправляемые данные с четкими определениями, тщательно контролируемые с точки зрения качества, безопасности и изменений.
агрегированные на базовом уровне и представленные в аудированной форме
Панели управления и контроля за соблюдением нормативных требований
Песочницы открытий
Сочетание необработанных и агрегированных данныхСпециальный анализ для поиска новых вариантов использования
Внешние системы обмена данными
Соблюдение строгих политик и соглашений о местонахождении данных, а также процессов управления и защиты данных
Банковские системы, которые обмениваются информацией о мошенничестве
Источник: Верал Десаи, Тим Фаунтейн и Кайваун Роушанкиш, "Лучший способ использовать ваши данные в работе".
Harvard Business Review, июль-август 2022 г.
ПРИЛОЖЕНИЕ 25.3
Создание продуктов данных требует инвестиций. Вы должны выбирать их с умом.
Определение продуктов данных, приносящих прибыль
Создание продуктов данных - важнейшее условие цифровых преобразований и преобразований с использованием ИИ. Хотя существует широкий спектр продуктов данных, которые могут создавать компании, это может быть дорогостоящим и трудоемким занятием, поэтому очень важно составить четкое представление о конкретных потребностях в данных, как описано в предыдущей главе. Во многих случаях компании не справляются с этим процессом, полагаясь на неточное понимание необходимого набора данных или неверное представление о требованиях к цифровому решению. Это может привести к покупке набора данных или инвестированию миллионов в большую команду и месяцы работы, которая на самом деле не приносит особой пользы.
Понимание потребности бизнеса в том или ином продукте данных сводится к тщательному анализу, который отвечает на следующие вопросы:
Является ли продукт данных уникальным? Аналогичные данные могут уже существовать в организации или на рынке.
Является ли продукт актуальным для людей и систем, которые будут его использовать? В случае с недвижимостью это может означать, что у компании есть отличные данные, но только для определенных рынков, которые не интересуют маркетинговую команду и клиентов.
Как выглядит "хорошо"? Четко определите минимальную планку качества. Например, для данных по коммерческой недвижимости может быть важно иметь данные в течение месяца для приоритетных рынков, в то время как для других рынков такие свежие данные могут быть не нужны. Аналогично, важно определить, насколько точными должны быть данные. В этом же примере с недвижимостью необходимо, чтобы данные были на уровне квартала, района или почтового индекса?
Сколько вариантов использования может поддерживать этот продукт данных, и какова ценность этих вариантов? Продукты данных должны обслуживать несколько сценариев использования, чтобы актив имел наибольшую пользу. Для многих компаний таким продуктом может стать продукт Customer-360, который могут использовать несколько команд - маркетинг, продажи, НИОКР - для разработки собственных продуктов и решений.
Цель этого процесса - сузить круг возможных вариантов и определить элементы данных, которые являются отличительными, ценными и общедоступными. После этого компании могут определить, какие именно продукты данных необходимо создать, разработать план их создания и нанять необходимое количество сотрудников.
Настройка стручков продуктов данных
Продукты данных требуют специальных подразделений и финансирования. У каждого продукта данных должен быть владелец продукта (данных) и межфункциональная группа.
который финансируется для создания и постоянного совершенствования продукта и создания новых вариантов использования. На владельца продукта данных возлагается множество обязанностей: определение направления, понимание возможностей и потребностей организации и клиентов, оптимизация стоимости инвестиций, разработка и руководство выполнением дорожной карты, управление зависимостями и измерение успеха.
Каждая группа состоит из четырех-восьми человек с определенными навыками, которые зависят от характера исходных данных и того, как будет использоваться продукт (см. Рисунок 25.4). Наилучшей практикой является привлечение в группу бизнесменов, чтобы они могли высказать мнение пользователей (включая обратную связь), что поможет улучшить продукт и выявить новые варианты использования. Также имеет смысл привлекать экспертов по правовым вопросам, соблюдению нормативных требований и рискам, чтобы разрабатывать продукты данных, соответствующие нормативным требованиям и социально ответственные.
В структуре операционной модели подсистемы данных часто являются частью платформ данных, поскольку они производят услуги, которые используются подсистемами, обращенными к клиентам/пользователям (подробнее о платформах читайте в главе 14).
Руководитель службы данных должен разработать стандарты и передовые методы документирования происхождения данных, аудита их использования и измерения качества данных. Эти стандарты также должны охватывать то, как необходимые технологии должны сочетаться для каждого архетипа потребления, чтобы их можно было повторно использовать во всех продуктах данных. Для разработки таких практик и шаблонов часто полезен центр экс- плуатации.
Чтобы подтвердить, что их продукты отвечают потребностям конечных пользователей и постоянно совершенствуются, команды разработчиков продуктов данных должны измерять ценность своей работы. Соответствующие показатели могут включать количество ежемесячных пользователей данного продукта, количество случаев повторного использования продукта в бизнесе, оценки удовлетворенности по результатам опросов пользователей данных и окупаемость инвестиций в реализованные сценарии использования.
Пример стручка, разрабатывающего продукты данных
Владелец продукта данных
Возглавляет работу по разработке продукта данных
Техническое обеспечение (инженеры, ИТ-руководители)
Предоставляет экспертные знания в области инфраструктуры и DataOps
ТД
DPO
Управляющий(ие) данными
Управление соответствующими доменами данных
DS
D DPA
Дизайнер
Создает легкую для
Аналитик(и) продуктов данных
потребление опыта для пользователей (если это рассматривается как модель потребления)
DA
Приносит голос пользователей/клиентов
DE
Архитектор данных Инженер(ы) по данным
Разрабатывает общую архитектуру данных для продукта
Выполняет работы по проектированию данных
ПРИЛОЖЕНИЕ 25.4
Поскольку проблемы с качеством могут подорвать доверие конечных пользователей и их использование, команды, занимающиеся производством данных, тщательно контролируют определения данных (например, ограничиваются ли данные о клиентах активными клиентами или включают активных и бывших клиентов), доступность и контроль доступа.
Разработка продуктов данных
Процесс разработки продуктов данных является итеративным, требующим от подразделений постоянного тестирования и адаптации продукта до тех пор, пока он не будет готов к использованию. Обычно на создание MVP-версии продукта данных уходит от трех до шести месяцев. После этого команда дорабатывает продукт на основе отзывов пользователей (внутренних или внешних).
На самом высоком уровне подгруппы продуктов данных работают в рамках итеративного процесса определения требований к данным, принятия решения о том, какие данные использовать, и приведения их в надлежащий вид, а затем обмена этими обработанными данными через различные потенциальные архетипы потребления. Например, продукт данных может предоставлять API для легкого доступа и потребления, обеспечивая прямую интеграцию с ключевыми операционными системами. Он также может предоставлять набор динамических информационных панелей со встроенной аналитикой для принятия бизнес-решений. См. Рисунок 25.5 и следующий пример передового шестиэтапного процесса разработки продукта данных.
Подход к разработке продуктов данных
Рецепт продукта "6S" - пример
Структурирование данных для создания сценариев использования, например, архитектура
4
Обмен данными и создание необходимых отчетов, информационных панелей и т.д.
5
Поиск данных
3 и измерить его текущее состояние
1
2
6
Определение направлений развития для создания стоимости
Выбор данных для хранения в течение долгого времени
Управление продуктом путем утверждения ролей и процессов
Предварительное планирование - "спринт 0"
для разработки бэклога продукта
Agile-спринты для итеративной разработки продукта
Разработка плана для следующего выпуска
Пример из практики: Компания по выпуску кредитных карт создает "единый источник правды" о своих клиентах
У крупного мирового эмитента кредитных карт было около 200 различных приложений, управляющих данными клиентов. Обслуживание каждого из этих приложений обходилось в среднем в 300 000 долларов в год. Хуже того, такое распространение приложений привело к проблемам с регулирующими органами, которые утверждали, что в приложениях не было единого "источника истины" для информации о клиентах, необходимой для оценки рисков и других факторов.
Чтобы решить эту проблему, компания сопоставила свои сценарии использования с продуктами данных и присвоила каждому из них определенную ценность. Таким образом, они определили и разработали восемь конкретных продуктов данных о клиентах (например, Customer 360, Merchant 360), что дало дополнительные преимущества в виде открытия новых способов поддержки своих приложений. Они создали набор общих активов (например, озеро данных, каталог данных, общий репозиторий аналитического кода), что позволило сократить усилия по поддержке среды, быстро внедрить новые возможности и снизить сложность обеспечения соответствия требованиям. Приведение в порядок данных о клиентах позволило им предоставлять информацию всем подразделениям компании из единого источника. В итоге компания сэкономила примерно 300 миллионов долларов в год на расходах, обеспечив при этом более качественное обслуживание и соответствие нормативным требованиям.
Примечание
1. Джошан Чериан Абрахам, Гильерме Круз, Себастьян Кубела, Томаш Лахус, Кайваун Роушанкиш, Санчит Тивари и Родни Земмель, "Цифровые близнецы: От одного близнеца к метавселенной предприятия", McKinsey
.com, октябрь 2022 года, https://www.mckinsey.com/capabilities/mckinsey
-digital/our-insights/digital-twins-from-one-twin-to-the-enterprise
-метаверс.
Глава 26.
Архитектура данных, или система "труб" данных
Если представить данные как воду, то архитектура данных - это система "труб", по которым вода доставляется от места хранения к месту использования. Архитектура данных - это основная среда для управления хранением, преобразованием, анализом и потреблением данных пользователями или приложениями. Без продуманной архитектуры данных компаниям приходится нелегко, поскольку данные часто разбросаны и заперты в десятках информационных силосов (например, в унаследованных базовых системах).
При правильной реализации архитектура данных позволяет быстрее создавать многократно используемые и высококачественные продукты данных.
Обеспечьте доступность данных для команд. Это приводит к улучшению результатов при принятии решений, повышению интеллектуальности приложений, ориентированных на клиентов, и улучшению внутреннего доступа к данным и контроля над ними.
По их словам: Платформа данных для обеспечения гибкости
Для большинства компаний традиционный подход к управлению ИТ заключается в формировании бюджета на основе крупных проектов по созданию приложений. Большинство заказчиков осознают, что им необходимо перейти к более гибкой модели, при которой разрабатываемые приложения будут модульными и более компактными. Переходу к гибкой модели очень способствует наличие платформы данных, которая может поддерживать различные приложения.
Создав независимую платформу данных, вы сможете сделать разработку приложений гораздо более гибкой. Платформа должна быть основана на метаданных, чтобы вы могли понять и иметь настоящий каталог данных. Она не должна хранить все данные. Это просто место, где данные обрабатываются в нужных приложениях. Это создает слой абстракции.
Подумайте о том, что данные поступают из внутренних систем и старых систем, которые могут двигаться очень быстро. А потребление данных меняется гораздо быстрее. Создавая уровень абстракции с помощью платформы данных, вы позволяете новым приложениям двигаться гораздо быстрее без необходимости создавать соединения "точка-точка".
-Анил Чакраварти, президент подразделения Digital Experience Business, Adobe
Архетипы архитектуры данных
Существует пять архетипических архитектур данных для создания современной платформы данных (см. Рисунок 26.1). Каждая из них построена на базе облачного масштабируемого хранилища, предлагаемого ведущими поставщиками облачных услуг, но базы данных и технологии доступа к данным, построенные на их основе, отличаются друг от друга.
Платформа данных должна удовлетворять потребности цифровых решений на основе искусственного интеллекта, которые вы планируете создать, но она также должна отвечать потребностям бизнес-аналитики (BI), например, создавать управленческие отчеты и контролировать операции. Эта двойственность по-прежнему находит свое отражение в том, как компании строят свою платформу данных, используя как озеро данных
Архетипы архитектуры данных
ОБЛАЧНОЕ НАТИВНОЕ ОЗЕРО ДАННЫХ
Централизованная бессерверная архитектура, использующая объектное хранилище и вычисления, которые могут масштабироваться независимо друг от друга
Оптимизирован для (очень) крупномасштабных карт данных для SQL-аналитики и современных приложений AI/ML
Гибкая основа для добавления возможностей (например, DWH,
в режиме реального времени), но начинает рассматриваться как "унаследованная" архитектура
ОБЛАЧНОЕ ХРАНИЛИЩЕ ДАННЫХ
Высокомасштабируемая и гибкая платформа на базе SQL с независимо масштабируемыми системами хранения и вычислений
Реализует современное преобразование данных с помощью SQL или
Ориентированные на пользовательский интерфейс инструменты ETL (например, dbt, Matillion)
Очень хорошая производительность в подавляющем большинстве корпоративных аналитических нагрузок
Очень хорошо поддерживается инструментальными средствами, а необходимые навыки работы с SQL имеются у пользователей данных, аналитиков и экспертов по данным.
LAKEHOUSE
Сочетает в себе преимущества
Использование nextgen
Справляется с самыми
Менее развитая инструментальная база, но
Озеро данных и DWH
технологии хранения
сложные пакетные данные
быстрые темпы технического прогресса
в интегрированную платформу для аналитики (например, BI, SQL) и использования AI/ML
(например, Delta Lake или Iceberg), поддерживающие ACID-транзакции поверх объектных хранилищ.
задания и большие объемы потоковых данных (например, IoT).
инновации
ДАННАЯ СРЕДА
Возникающий архетип;
Децентрализованный
Продукты данных
Создание продуктов данных
фундаментальное отступление
архитектурный подход
проверено на качество,
используя любой из
от централизованных ИТ и
сосредоточен на данных
каталогизированы, и
архитектура данных
функции данных
продукты, полностью принадлежащие бизнес-доменам
доступ через четко определенные службы данных
архетипы, определенные выше
ДАННАЯ ТКАНЬ
Новая стратегия для
Ткань сшита
Предназначен для решения
Отсутствие существующей оснастки
создание единой системы данных
вместе через
многооблачные сценарии
В настоящее время позволяет использовать истинный
среда по всему
метаданные в защищенном виде,
для неоднородных
Data Fabric, он должен
Ландшафт данных предприятия
унифицированный уровень управления данными
источники данных и инфраструктура
лучше строить своими силами
ПРИЛОЖЕНИЕ 26.1
сосуществуют архетип (для искусственного интеллекта) и архетип облачного хранилища данных (для BI). Это были два доминирующих архетипа для
в последнее десятилетие. В начале 2020-х годов появился новый архетип - "дом у озера", который стремится объединить технологический стек данных для обслуживания как BI, так и AI.
Последние два архетипа, перечисленные на предыдущей иллюстрации, появились недавно в связи с тенденцией к децентрализации управления данными (data mesh) и потребностью крупных корпораций в управлении данными в многооблачных средах (data fabric).
Ниже мы опишем, для чего лучше всего подходит каждый архетип и каковы его ограничения:
Озеро данных - это самый простой архетип, который имеет хорошо понятные эталонные архитектуры, доступные на всех основных облачных платформах. Оно лучше всего подходит для рабочих нагрузок, связанных с наукой о данных, особенно для работы с неструктурированными данными, и является хорошей отправной точкой для организаций, которые только начинают погружаться в передовую аналитику и AI/ ML, и поэтому нуждаются в простой архитектуре, способной масштабироваться в соответствии с их потребностями.
До недавнего времени озера данных располагались в локальных сетях в виде сложной платформы Hadoop. Облако изменило ситуацию: основные возможности Hadoop предоставляются через масштабируемые и надежные сервисы данных, управляемые облачным провайдером в виде объектного хранилища (например, S3, ADLS), Spark (например, AWS Glue, Azure Synapse Analytics) и распределенного механизма запросов (например, Amazon Athena, BigQuery).
Недостатком этой архитектуры является то, что она не подходит для типичных SQL-нагрузок BI-аналитики, требует больших затрат на проектирование и приводит к централизации данных, что в конечном итоге может стать узким местом в организации.
Облачное хранилище данных (например, Snowflake, Synapse, BigQuery) - это доминирующий дизайн для создания BI для оперативной и управленческой отчетности, а также пользовательских BI-отчетов. Эта архитектура радикально упрощает технологический стек для быстрого предоставления сложных возможностей бизнес-анализа и аналитики. Эта конструкция ставит SQL в центр работы по проектированию данных, которые все еще могут быть организованы в современные, хорошо протестированные конвейеры данных, используя DBT, инструмент для преобразования данных. Эта архитектура особенно привлекательна для организаций, ориентированных на облачные технологии, и крупных организаций, переходящих на облачные технологии.
Главный недостаток этой архитектуры в том, что она пока не очень хорошо поддерживает продвинутую аналитику и разработку AI/ML. SQL также не всегда является наиболее эффективным подходом для работы с данными высокой сложности. И наконец, простота использования может привести к взрыву любительского использования, которое, если его тщательно не регулировать, может в итоге замедлить создание стоимости, а не ускорить его.
Lakehouse - это инновационная разработка компании Databricks, которая объединяет возможности озера данных и хранилища данных в единую интегрированную платформу. Она представляет собой значительный шаг вперед по сравнению с озером данных, особенно при работе с крупными структурированными данными, без ущерба для возможностей работы с неструктурированными данными (например, транзакций ACID2, поддержки реального времени, версионирования данных, управления данными, поддержки SQL).
Несмотря на расширенный набор возможностей, он требует значительных инженерных навыков для разработки и эффективного управления. Наибольший финансовый смысл она имеет для больших массивов данных (100+ ГБ). Все крупные облачные провайдеры и новые нишевые игроки, такие как Tabular (Apache Iceberg), Onehouse (Apache Hudi) и Dremio (Arctic), продвигают архетип Lakehouse, подтверждая, что Lakehouse - это современный паттерн архитектуры данных, а не просто собственная разработка одного вендора.
Сетка данных - это децентрализованный подход к данным, который призван открыть следующую фазу роста для крупных организаций, достигших высокой степени зрелости в своих возможностях работы с данными и пытающихся удовлетворить растущий спрос.
При подходе с использованием сетки данных данные предоставляются в виде курируемых, многократно используемых продуктов данных под непосредственным контролем бизнес-доменов (например, маркетинга и продаж, региональных операций, производственного предприятия), которые используют инструменты данных, предоставляемые ИТ. Сетка возникает по мере того, как несколько доменов создают свои собственные возможности работы с данными и получают данные друг от друга, предпочтительно с использованием инструментов федерации данных, как общий уровень обслуживания данных, чтобы минимизировать ненужное перемещение данных. Домены отвечают за свои собственные данные, что означает, что они должны решать проблемы доступности и качества данных для себя и других доменов, получающих свои данные через сетку.
Решение о переходе к сетке данных может легко эволюционировать по сравнению с "озером данных", поскольку оно в большей степени связано с операционной моделью данных, чем с выбором технологий обработки данных. Для большинства организаций, начинающих с высокоцентрализованных данных и ИТ-возможностей, а также с низким уровнем зрелости и владения бизнес-данными, путь к сетке данных может оказаться неподходящим. Однако сетка данных не является предложением "все или ничего". Крупные организации могут найти преимущества в работе в гибридной модели, где наиболее зрелые бизнес-домены присоединяются к модели сетки данных, владеют своими данными и создают продукты данных для удовлетворения своих потребностей, а менее зрелые домены продолжают использовать централизованную экспертизу данных.
Ткань данных - это модернизированный, централизованный подход к данным, "инь" по отношению к "янь" data mesh. Отличительной чертой data fabric является обещание значительно ускорить и удешевить интеграцию за счет виртуализации для подключения источников данных к data fabric без лишних перемещений данных. Это решает проблему, с которой сталкиваются крупные организации, работающие в мультиоблачных средах. Хотя у архетипа data fabric большой потенциал на будущее, возможности, необходимые для автоматической связи и интеграции данных в рамках большой и сложной организации, только начинают появляться. На момент написания этой статьи, возможно, еще слишком рано рассматривать архетип data fabric.
При выборе архетипа необходимо учитывать текущий путь развития облачных технологий и дорожную карту цифровых технологий. Если вы планируете использовать множество приложений с интенсивным искусственным интеллектом в дополнение к основным BI-приложениям, рассмотрите возможность создания хранилища данных. С другой стороны, если ваша "дорожная карта" цифровых технологий предполагает наличие большого количества BI-приложений, рассмотрите возможность создания облачного хранилища данных.
Облачная и локальная инфраструктура данных
Использование облачной инфраструктуры от крупнейших провайдеров публичных облаков может стать значительным ускорителем успешного внедрения и недорогой эксплуатации крупномасштабных возможностей работы с данными. Облачные сервисы дают огромные преимущества с точки зрения производительности ваших команд по работе с данными, которые больше не вынуждены управлять чрезмерно сложными системами данных и могут вместо этого сосредоточить свое время на реализации сценариев использования, обеспечивающих ценность бизнеса.
Появилось множество технологий облачных данных, которые облегчают создание цифровых решений и решений на основе искусственного интеллекта. Путь к использованию современных возможностей облачных данных постоянно упрощается, что делает технологии, которые раньше были отличительными, доступными для каждой компании.
Некоторые организации предпочитают создавать локальные системы или гибрид локальной и облачной. Обычно такое решение принимается по двум причинам: опасения по поводу использования "облака" для особо конфиденциальных данных или критически важных рабочих нагрузок или уверенность в том, что организация может разработать и создать современные возможности работы с данными, сопоставимые с возможностями поставщиков "облака".
Успевать за темпами инноваций и возможностями поставщиков облачных услуг очень сложно, поэтому выбор в пользу локального или гибридного подхода обычно делают только крупные организации с богатой историей технологических инноваций. Но будьте осторожны. Для достижения успеха необходимы передовые инженерные навыки, инвестиции в строительство и обслуживание современных центров обработки данных, а также готовность поддерживать эти инвестиции в течение длительного времени. Современные облачные платформы обычно требуют меньших инвестиций и обеспечивают регулярный поток инноваций, с которым организациям будет сложно сравниться, особенно для рабочих нагрузок ИИ, где инновации происходят особенно быстро и где потребности в инфраструктуре являются наиболее сложными.
Принятие решения о возможностях работы с данными и внедрение эталонных архитектур
Каждая архитектура, описанная в этой главе, включает в себя набор необходимых возможностей, таких как потоковая передача событий, хранилища данных и API данных, которые позволяют данным эффективно "перетекать" из места их получения (в нижней части рис. 26.2) в место их использования (в верхней части рис. 26.2). Какие именно возможности работы с данными вам нужны, зависит от сценариев использования. Проблема заключается в том, что существуют буквально сотни технологий обработки данных, которые помогают создавать и эксплуатировать архитектуру данных. Такая ситуация отражает быстрые темпы инноваций в этой области, но она также усложняет выбор и интеграцию этих технологий данных.
Обычно организации рассматривают внедрение архитектуры данных как многолетний проект "водопада", в котором каждый этап, от создания озера данных и конвейеров до внедрения инструментов потребления данных, рассматривается только после завершения предыдущих. Вы можете добиться более быстрых результатов, если будете руководствоваться подходом, основанным на вашей цифровой дорожной карте, и примете эталонную архитектуру - набор технологий, доказавших, что они хорошо работают вместе для реализации выбранного вами архетипа.
При таком подходе ваш ведущий архитектор данных сначала разработает высокоуровневый план необходимых возможностей данных - вариант рисунка 26.2, - ориентированный на создание "минимально жизнеспособной архитектуры данных" для удовлетворения потребностей ваших приоритетных цифровых решений (включая решения, требующие как BI, так и искусственного интеллекта). Эта карта возможностей данных поможет добиться согласованности действий и станет хорошей базой для сравнения при анализе архитектуры текущего состояния. Хотя ведущим архитектором данных и проводится эта оценка, очень важен вклад специалистов по работе с данными, менеджеров/администраторов данных, а также владельцев продуктов и приложений данных, которые могут рассказать о необходимых технических возможностях.
Возможности данных
ПОТОК ДАННЫХ
каталог, мониторинг моделей и
Качество данных, наблюдаемость и централизованность
ПОТРЕБЛЕНИЕ ДАННЫХ
АНАЛИТИКА ADVANCED ПРИМЕНЕНИЯ
(BI и отчетность) АНАЛИТИКА (Операционные системы)
Разработка BI иDSВнутренняя операционная
Визуализация Окружающая среда системы
Специальный анализ SQLПроизводство моделейМобильные и веб-приложения
Окружающая среда приложения
ДАННЫЕ СЕРВИСЫ
Конечные точки API данных Публикация/Метрика и функция и API подпискиКонечные точки Хранилища(например, Transform, Management (RESTstore , serve, monitor, and and/or GraphQL). Аналитика управление многократно используемыми функциями
оптимизированные данные для BI и искусственного интеллекта)
(например, Parquet) в федерации данных и конечных точках SQL, уточненная зона и/или виртуализация
(JDBC и/или ODBC) DS Sandbox
ХРАНИЛИЩА ДАННЫХОБРАБОТКА ОБЪЕКТОВХРАНИЛИЩА ДАННЫХ ИИ/МЛ
(структурированный или неструктурированный)
Реляционные (например, SQL) Обучение и оптимизация
DS Sandbox Сервер, Oracle, ML-модели (например,
(для Analytics/ML) Postgres) Распределенный
NoSQL (например, KVS, обучение, БД документов, графооптимизация , БД GPU) вычисления)
Хранилище данных STREAM
(например, магазин ПРОЦЕССИНГ
структурированный, интегрированный
Хранение данных на дешевых, надежных носителях для поддержки BIT-трансформации и "бесконечно" масштабируемых медиаактивностей , аналитика) анализ данных
в режиме реального времени
ВЛИВАНИЕ ДАННЫХ
БАТЧ СОБЫТИЕ ЧУВСТВИТЕЛЬНЫЙ ПАКЕТНЫЙ ПРИЕМ ПОТОКОВАЯ ПЕРЕДАЧА ДАННЫХ ОБРАБОТКА ДАННЫХ ОБРАБОТКА
Ввод в системуВвод в систему в режиме реального времениУправление ПИИОчистка , планирование Потоки данных (например, обнаружение, преобразование и пакеты) Изменение данныхСохранение и обогащение данных в
Захватывайте потоки, управлять чувствительными партии,
датчики, трансак-данные ) обычно ежедневные данные о событиях)
СОЗДАНИЕ КОНВЕЙЕРОВ ДАННЫХ Создание конвейеров данных с помощью Планирование процессов обработки данных в
И ОРКЕСТРОВКА SQL или код (например, Python) надежный и интеллектуальный способ
Управление моделью Master DataML: Модель Управление данными: Каталог, Линейка данных,
GOVERNANCE (MDM) централизованные метаданные для MLOpsметаданные для DataOps
Защита данных: Авторизация, расширенные инструменты: Контроль доступа к данным, аутентификация, шифрование и аудит Предотвращение потерь, конфиденциальность данных, сохранение данных и др.
Инфраструктура как код (IaC), DevOps и автоматизация, администрирование, ведение журналов, мониторинг
БЕЗОПАСНОСТЬ ДАННЫХ
ИНФРАКРАСНЫЕ РАБОТЫ
ИСТОЧНИКИ ДАННЫХ
Структурированные данные
Транзакционные и событийные данные
Структурированные основные и справочные данные
Другие третьи лица
Структурированные данные
Неструктурированные данные
Машина и звук , сенсорное изображение и
ДанныеВидеоданные
Неструктурированные текстовые данные
Данные о контенте социальных сетей
После того как вы выбрали необходимые вам возможности работы с данными и определили последовательность построения, можно приступать к выбору конкретных технологий работы с данными. Именно здесь важна эталонная архитектура. В целом, основные технологические компоненты будут определяться выбранным архетипом и выбранным поставщиком облачных услуг (CSP). На рисунке 26.3 показан выбор технологии для архитектуры Lakehouse, построенной с использованием Databricks на Azure. В данном конкретном случае дизайн максимально использует возможности Databricks. В качестве альтернативы можно было бы использовать программное обеспечение с открытым исходным кодом, чтобы минимизировать привязку к поставщику, снизить стоимость и/или обеспечить лучшие в своем классе возможности. Аналогичные архитектуры Lakehouse существуют и для других облачных сред.
В общем, не изобретайте колесо, а лучше воспользуйтесь проверенной эталонной архитектурой, чтобы ускорить разработку и минимизировать риски внедрения.
Лучшие практики проектирования архитектуры данных
Начните с малого. Если у вас нет многих возможностей для работы с данными, определите минимально жизнеспособную архитектуру для удовлетворения наиболее приоритетных потребностей и начните с нее. Создайте и разверните минимально жизнеспособную архитектуру, которая обеспечивает конкретные компоненты данных, необходимые для каждого желаемого варианта использования. Например, компания среднего размера, занимающаяся управлением активами, определила облачную платформу данных и создала ее начальную версию, которую можно было использовать для структурирования данных в течение всего нескольких месяцев.
Эталонная архитектура: Lakehouse с использованием Databricks в Azure
Ведение журнала и мониторинг:
Мониторинг Azure
Интеллектуальные приложения и другие операционные системы, основанные на данных
ПРИЛОЖЕНИЯ
ПОТРЕБЛЕНИЕ ДАННЫХ
Среда моделирования лаборатории DS
Azure ML
Azure ML Studio DS Notebooks Kedro ML pipelines
BI и визуализация
Power BI, QlikView, DB Notebooks
SQL Analytics
Блокноты Databricks
РАСШИРЕННАЯ АНАЛИТИКА
АНАЛИТИКА
Конечные точки API данных: Azure API Manage- ment, собственные API
ДАННЫЕ СЕРВИСЫ
Конечные точки SQL:
Databricks SQL
Конечные точки публикации/подписки: Темы Kafka на Azure EventHubs
Аналитические оптимизированные данные: Дельта-таблицы на ADLS
Azure Data Lake Gen 2
(исходные данные)
ОЗЕРО ДАННЫХ DATABRICKS DATA LAKEHOUSE
ХРАНИЛИЩА ДАННЫХ
Озеро Дельта
Песочница (для лаборатории DS)
ПОТОК ДАННЫХ
Хранилище метрик и характеристик: Databricks Feature Store, Tecton
Федерация данных / виртуализация: Denodo, Trino/ Starburst, Dremio
Databricks (pySpark, Spark SQL)
ПАКЕТНАЯ ОБРАБОТКА
Системы обработки данных (потоковая передача данных Spark)
ПОТОКОВАЯ ОБРАБОТКА
Databricks ML Runtime Azure ML
ИИ/МЛ
ПРОЦЕССИНГ
Создание конвейеров данных:
Python, ADF, DB Notebooks
Оркестровка конвейера данных:
Вакансии Databricks, ADF, Airflow
Управление моделями: Каталог данных:
БД mlFlow или Azure Purview, Datahub
Наблюдаемость Линейность инадежность данных: МонтеМетаданные : Данные Маркеса Карло, Datafold и OpenMetadata
OSS, Collibra, Alation
Реестр ML
Управление идентификацией: Azure Active Directory
Управление секретами: Azure Vault
Инфраструктура как код: ARM DevOps: Azure DevOps,
шаблоны, Terraform, Pulumi
Github, GitLab
Золото
Серебро
Бронза
Зона высадки
ИСТОЧНИКИ ДАННЫХ
Структурированные данные
Неструктурированные данные
Транзакционные Структурированные
Другие третьи лица
Машина и Звук,
Неструктурированные
Социальные сети
& Event DataMaster &
Структурированный
SensorImage , и
Текстовые данные
Содержание
Справочные данные
Данные
ДанныеВидеоданные
Данные
Обеспечьте зрелость всего жизненного цикла данных, а не вкладывайте слишком много средств только в один этап потока данных. Архитектура будет настолько сильна, насколько силен самый слабый компонент. Например, если необходим поток и обработка данных в режиме реального времени, то одних инвестиций в обеспечение возможности приема данных в режиме реального времени будет недостаточно - данные будут поступать быстро, а затем их обработке будут мешать пакетные процессы в хранилище или других точках.
Создавайте гибкие модели данных. Чтобы добиться большей гибкости при исследовании данных или поддержке цифровых сценариев использования, создавайте модели данных с меньшим количеством физических таблиц (часто это называют "схемно-легким" подходом). Такой подход облегчает изучение данных, обеспечивает большую гибкость при хранении данных и снижает сложность за счет упрощения запросов к данным.
Создайте высокомодульную и эволюционную архитектуру данных, использующую лучшие компоненты, которые при необходимости можно заменить новыми технологиями, не затрагивая другие части архитектуры данных. Сосредоточьтесь на интерфейсах, основанных на конвейере данных и API, чтобы упростить интеграцию между разрозненными инструментами и платформами. Создайте платформу управления API (часто называемую шлюзом API) для создания и публикации API, ориентированных на данные, внедрения политик использования, контроля доступа, измерения использования и производительности. Аналитические верстаки, такие как Amazon SageMaker и Kubeflow, упрощают создание комплексных решений в высокомодульной архитектуре данных.
Создайте семантический слой данных, согласованный с доменами бизнес-данных, как единый источник истины для данных и управляйте им как основополагающим продуктом данных. Такой подход позволяет повысить качество и надежность данных для всеобщего блага. Графовые базы данных идеально подходят для этой цели, в частности для цифровых приложений, требующих огромной масштабируемости и в реальном времени, а также для слоев данных, обслуживающих приложения искусственного интеллекта. Графовые базы данных позволяют мощно и гибко моделировать взаимосвязи внутри данных.
Примечания
Свен Блюмберг, Хорхе Мачадо, Хеннинг Соллер и Асин Таваколи, "Выход из тупика архитектуры данных для масштабирования ИИ", McKinsey
.com, 26 января 2021 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/breaking-through-data-architecture- gridlock-to-scale-ai; Antonio Castro, Jorge Machado, Matthias Roggendorf, and Henning Soller, "How to build a data architecture to drive innovation - today and tomorrow", McKinsey.com, June 3, 2020, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ how-to-build-a-data-architecture-to-drive-innovation-today-and- tomorrow.
ACID обозначает свойства транзакций: атомарность, согласованность, изолированность и долговечность. Транзакции ACID обеспечивают наивысшую возможную надежность и целостность данных, гарантируя, что данные никогда не перейдут в противоречивое состояние из-за операции, которая завершилась лишь частично.
Глава 27. Сделайте сайт
, чтобы получить максимальную отдачу от данных.
Операционная модель данных - это общий подход к тому, как организация должна управлять данными. Она состоит из четырех основных компонентов: организация, таланты и культура, инструментарий и DataOps, а также управление и риски (см. Рисунок 27.1).
Некоторые компании опасаются, что создание таких возможностей может показаться развитием еще одной бюрократии или, возможно, актуально только для крупных банков. Но, по нашему опыту, правильная организация управления данными и операционной модели имеет решающее значение для превращения в предприятие, интенсивно использующее данные. Легко пренебречь наличием сильной операционной модели.
Если вы имеете дело с одним или двумя случаями использования данных, то часто можно обойтись без модели. Но получить отдачу от сотен, а то и тысяч вариантов использования данных просто невозможно без эффективной и хорошо организованной операционной модели. Добившись ясности в этих областях, компании смогут избежать конфликтов, путаницы и задержек, которые обычно мешают работе с данными.1
Компоненты эффективной модели работы с данными
Организация
Степень централизации
Структура руководства
1 2 Роли и карьерные пути
Культура, основанная на данных
Талант и
культура, основанная на данных
Повышение квалификации (Академия данных)
Процессы управления
Управление и риски
Стандарты политики
4 3 Автоматизация процессов и расширение возможностей
DataOps
Передачи и точки интеграции
Организация
Многие компании сталкиваются с проблемой, как организовать эффективное управление данными и аналитику. Кто должен владеть данными? Должна ли у нас быть организация по работе с данными? Как она должна быть связана с бизнесом? А с ИТ? Кто должен заниматься разработкой данных? Следует ли разделять конфиденциальность данных и соответствие нормативным требованиям? Эти вопросы сложны, поскольку данные затрагивают каждую часть организации.
Необходимо принять два основных решения: степень централизации и то, какие роли высшего руководства и управленческие форумы необходимы.
Степень централизации
Некоторые компании используют преимущественно централизованные модели, в рамках которых группы специалистов по работе с данными обслуживают все предприятие. Другие используют преимущественно децентрализованную модель, когда каждое подразделение и функция развивают возможности для удовлетворения своих собственных потребностей. Обе модели могут работать на ограниченной основе, но, как правило, они недостаточно оперативны и не способны масштабироваться для удовлетворения более широких потребностей бизнеса.
Ведущие компании используют федеративную модель, в которой центральный орган (часто называемый управлением данных, главным управлением данных или управлением корпоративных данных) устанавливает политику и стандарты, обеспечивает поддержку и надзор, а бизнес-подразделения и функции управляют деятельностью, связанной с данными, такой как повседневное управление данными, определение и управление продуктами данных, а также создание конвейеров данных для обеспечения их потребления.
Правильный баланс между центральными и местными обязанностями при таком федеративном подходе должен быть достигнут на функциональном уровне. На рисунке 27.2 описана типичная настройка функциональных областей данных в лучшей практической федеративной модели.
Структура руководства и управленческие форумы
Все больше организаций назначают главного специалиста по данным (CDO) или его эквивалента для руководства функциями, связанными с данными. Такой руководитель часто подчиняется ИТ-директору, но это существенно зависит от более широкой организационной структуры, потребностей и целей в области данных (например, подчинение COO, CRO или, в некоторых случаях, даже непосредственно генеральному директору). Иногда эту роль объединяют с руководством по аналитике и называют главным специалистом по данным и аналитике (CDAO). Это часто делается для того, чтобы усилия по работе с данными были тесно увязаны с реализацией аналитических сценариев и их результативностью. Это менее распространено в отраслях с существенным регулированием данных (например, в банковской сфере), где управление данными и управление рисками, связанными с данными, имеют повышенное значение.
Типичная настройка для всех областей возможностей данных в передовой федеративной модели
Степень централизации1
Отчет о возможностях
Что предоставляет центр2
Что поставляется федеративным способом
Стратегия работы с данными
Управление продуктами данных
Архитектура данных
Инженерия данных
Управление данными
Операции с данными
Главный офис данных
Главный офис данных
>50-
75%
<25%
Руководитель отдела данных или ИТ
>75%
Руководитель отдела данных или ИТ
25-
50%
Главный офис данных
<25%
Руководитель отдела данных или ИТ
50-
75%
Общеорганизационная стратегия в области данных, обеспечение ценности данных для всех подразделений
Стандарты продуктов данных, инструментальные средства и игровые программы; управление некоторыми корпоративными продуктами.
Архитектура корпоративных данных, архитектурные ограждения и обзор
Глубокая экспертиза, объединенный потенциал для реализации практических решений
Политика и стандарты управления данными, метрики и информационные панели, управление некоторыми доменами предприятия
Группа по работе с данными, которая занимается решением проблем и запросами данных (например, выписки, новые наборы данных)
>75%
Стратегии использования данных на уровне бизнес-подразделений, сценарии использования, а также возможности и проблемы
Управление большинством продуктов данных с помощью кросс-функциональных команд, состоящих из представителей бизнеса, данных и технологий.
Владение и управление исходными системами; определение потребностей во внешних данных
Команды инженеров по обработке данных, согласованные с бизнес-направлениями (в частности, по мере повышения уровня зрелости данных)
Повседневное управление доменами данных (например, определение метаданных, измерение и улучшение качества данных)
Устранение проблем, характерных только для данного подразделения или требующих глубоких знаний в области бизнеса
Риск, связанный с данными (включая конфиденциальность данных)
Руководитель отдела по работе с данными или юридического отдела/отдела нормативно-правового соответствия
Таксономия рисков в данных; интерпретация нормативных актов; политики, стандарты и средства контроля для управления рисками
Риски, характерные для конкретного подразделения, и нормативные требования. Руководство по допустимым рискам для бизнеса.
Талант и культура работы с данными
>75%
Типичный % ЭПЗ в центре
Руководитель отдела данных или HR
Создание потенциала данных, стратегия и управление талантами, управление изменениями
Ролевое моделирование целевой культуры и поведения. Оценка эффективности работы ресурсов. Наращивание потенциала конкретного подразделения.
Обычно в офисе корпоративных данных, но некоторые области обычно принадлежат ИТ-отделу, юридическому отделу, отделу рисков и другим.
ПРИЛОЖЕНИЕ 27.2
В сферу деятельности CDO всегда входят стратегия управления данными и управление данными. Обычно они также контролируют управление продуктами данных, архитектуру данных, операции с данными, риски, связанные с данными, а также таланты и культуру работы с данными. Масштаб организации может быть разным. Например, некоторые крупные банки с высокой степенью контроля со стороны регулирующих органов и преимущественно централизованной моделью имеют организации по работе с данными с сотнями сотрудников. С другой стороны, в розничных компаниях среднего размера, только начинающих работу над организацией данных и аналитики, в этой функции может работать менее 20 человек.
В федеративной организационной модели важно создавать форумы для объединения команд и руководителей всего предприятия, чтобы обеспечить согласованность действий. Как правило, организации делают это на двух уровнях: форум на уровне домена данных и форум на уровне высшего руководства. Форум домена данных часто возглавляется руководителем отдела управления данными (прямой подчиненный CDO) и объединяет всех владельцев доменов данных. Этот совет отслеживает прогресс и проблемы в доменах данных, согласовывает любые изменения в стандартах или направлениях (установленных CDO) и работает над устранением препятствий.
Форум по данным на уровне высшего исполнительного руководства часто возглавляет CDO, и в нем принимают участие руководители высшего звена (часто генеральный директор и его непосредственные подчиненные), которые определяют стратегию развития данных и принимают важнейшие решения по инициативам, персоналу и финансированию. Они также решают все нерешенные вопросы, возникшие в ходе форума по данным на уровне домена.
Таланты и культура, основанная на данных
Для эффективного управления данными необходимы новые роли на стыке данных и бизнеса. К ключевым ролям относятся управляющий доменом данных, владелец продукта данных и аналитик качества данных (см. Рисунок 27.3). В некоторых случаях эти роли могут быть заняты текущими сотрудниками при условии достаточной подготовки и поддержки. Более технические роли, такие как архитектор данных, инженер данных и владелец платформы данных, также очень важны (как описано в первом и третьем разделах этой книги).
Роли, связанные с доменом данных, часто выполняются на неполный рабочий день (особенно владельцы домена данных) или следуют модели "взорвать, а затем поддерживать", когда роль на полный рабочий день и команда укомплектовываются в течение трех-шести месяцев для быстрого создания домена данных (например, определение метаданных, установление правил качества данных, устранение высокоприоритетных проблем качества данных). Затем управление доменом осуществляется на условиях частичной занятости владельцем домена данных и стюардом(ами).
Ключевые роли данных
Категория Роль Обязанности
Роли, согласованные с доменом данных
Управляющий доменом данныхРуководит работой по управлению данными для определенного домена данных,
работа по повышению качества и удобства использования данных
Владелец домена данных окончательную ответственность за качество данных в домене . (иногда называется Должен"подписать", что данные точны; частопо совместительству "владелец данных") ответственность, или следуйте модели "взорвать, затем поддерживать"
Роли, согласованные с продуктом данных
Владелец продукта данныхОпределяет направление и контролирует разработку
продукт данных - т.е. минимальный набор данных для решения конкретной бизнес-задачи (часто с использованием данных из нескольких областей данных)
Архитектура данных - согласованные роли
Владелец платформы данныхУстанавливает направление и контролирует развитие
платформа данных - т.е. набор технологий, которые используются для обеспечения потребления, манипулирования и анализа данных
Архитектор данных Разработкастратегии информационной архитектуры для данных и помощь инженеру по данным в процессе ввода данных.
Роли, которые охватывают
возможности
Инженер по данным Созданиеконвейеров данных многократного использования, как для ввода данных в архитектуру, так и для структурирования данных по доменам, продуктам и сценариям использования.
Аналитик качества данныхОценка качества данных в соответствии с потребностями бизнеса, определение
проблемы, а также предлагать и реализовывать решения для улучшения
ПРИЛОЖЕНИЕ 27.3
Инструментарий DataOps
DataOps использует принципы и технологии agile для сокращения времени, необходимого для разработки новых и обновления существующих активов данных.
Как и DevOps, DataOps состоит из фаз непрерывной интеграции и развертывания с акцентом на устранение "малоценных" и автоматизируемых действий, таких как автоматическое внедрение нового кода инженеров по обработке данных в производство или автоматическая проверка качества данных и мониторинг производительности. Хотя ведущие компании все еще формируют представление о том, как выглядит настоящий лучший в своем классе DataOps, он требует перестройки процесса по трем направлениям:
Полностью интегрированная деятельность по работе с данными в рамках капсулы на каждом этапе жизненного цикла решения, включая разработку, тестирование, развертывание и мониторинг (в отличие от того, что на более поздних этапах процесса этим занимается отдельная команда).
Максимальная автоматизация с использованием специальных конвейеров DataOps и сценариев для полной автоматизации развертывания, а также контроля безопасности и рисков, связанных с данными, включая соответствующие аспекты конфиденциальности данных. Управление выпуском полностью автоматизировано.
Надежный набор инструментов для автоматизированного тестирования, сквозного анализа данных и автоматизированного развертывания инфраструктуры с полномасштабным мониторингом.
Управление и риски
Управление данными, по сути, является "воротами", которые позволяют предприятиям уверенно ускорять инновации, обеспечивая многократное использование данных и их соответствие соответствующим требованиям по рискам и нормативным требованиям. Исторически сложилось так, что управление данными рассматривается в основном с точки зрения рисков, однако современные методы управления данными могут также обеспечивать скорость и масштабирование (некоторые организации даже проводят ребрендинг управления данными, чтобы подчеркнуть этот факт). Управление данными устанавливает надежные определения для данных, контролирует и улучшает качество данных, а также помогает направить усилия на решение наиболее серьезных проблем с данными с учетом требований бизнеса. Управление данными также помогает обеспечить надежность и надлежащую защиту данных, поступающих в организацию (например, от третьей стороны) и выходящих из нее (например, для клиентов).
Управление по управлению данными должно создать совет по управлению данными, состоящий из ответственных за область данных в организации, часто с участием руководителей высшего звена. Совет должен взаимодействовать с руководством компании, чтобы понять ее потребности, выявить текущие проблемы и ограничения в работе с данными, объяснить роль управления данными и согласовать ее с текущими приоритетами бизнеса.
Офис управления данными должен описать границы и ответственность для доменов данных и совместно с руководителями подразделений предложить и утвердить ответственных за домены данных. Эти распорядители ежедневно направляют усилия по управлению, определяя приоритеты элементов данных для очистки и устанавливая стандарты качества. Они должны понимать, какую пользу принесут эти роли, и быть вооружены необходимыми навыками, включая понимание соответствующих нормативных актов и основных элементов архитектуры данных.
Важно создать осязаемые способы отслеживания прогресса и создания ценности. Например, измерьте количество времени, которое тратят специалисты по изучению данных и аналитики бизнес-аналитики на поиск, обработку или предоставление данных для приоритетных цифровых решений, или долларовые потери, связанные с некачественными данными и сопутствующими бизнес-ошибками.
Отслеживание таких показателей воздействия помогает обеспечить внимание и постоянную поддержку со стороны высшего руководства. Эти показатели должны поступать на простую приборную панель, к которой руководство может легко получить доступ, что поможет точно определить, где возникают проблемы с данными, и даст организации возможность быстро их решить. В Примере 27.4 показан пример приборной панели, используемой в крупном банке.
Ведущие организации используют подход, основанный на потребностях, когда речь идет об управлении, принимая уровень сложности, подходящий для их организации, а затем регулируя уровень строгости в зависимости от набора данных. Дизайн их программ должен соответствовать уровню регулирования, с которым они сталкиваются, и уровню сложности данных.
Пример системы управления данными и приборной панели исполнительного уровня
Пример глобального банка
Определение
Название метрики
Результаты метрики
Данные Данные
Имя
Тренд
лидер спонсоров
Данные
Отслеживание
Процент выполнения этапов
96%
Джон Джейсон
соблюдение политики и стандартов
соответствие политикам и стандартам управления данными
требуется для управления данными в обычном режиме
Качество данных
Оценка качества данных с точки зрения бизнес-процессов и поставщиков данных
Количество дефектов открытых данных
Вопросы открытых данных
Кейт Кевин
Навыки работы с данными и талант
Оценка состояния навыков и талантов, необходимых для реализации программы данных
Приоритетный набор на руководящие должности и на должности ниже по уровню заполнения данных
87%
95%
Кейт Марвин
Риск для данных
Отслеживание снижения рисков при использовании данных
Процент VaR, на который повлияли корректировки (скользящая средняя за 3 месяца)
69%
Джон Сьюзен
Сокращение разницы в общих расходах в рамках Примера 1
21% ($12.1B)
Сокращение на
Джон Сьюзен
ПРИМЕРНЫЕ ПОКАЗАТЕЛИ ОТСЛЕЖИВАНИЯ
FRAMEWORK
Проблема
Под угрозой
По плану
Завершено
Ход выполнения программы
прогресс программы управления данными
подотчетная команда (владелец)
Процент вех в прошлом
(47/49)
4%
Джон
Джейсон
реализация
Выполняется подотчетной командой (владельцем)
(2/49)
Данные
Мера
Запуск форумов по управлению данными
100%
Кейт
Кейт
ПРИЛОЖЕНИЕ 27.4
Например, организации могут применять облегченное управление для данных, которые используются только в исследовательских целях и не выходят за пределы команды разработчиков. Маскировка данных может быть уместна для обеспечения конфиденциальности, а также строгие внутренние соглашения о неразглашении (NDA). Однако как только такие данные начинают использоваться в более широком контексте, например при взаимодействии с клиентами, необходимо применять более жесткие принципы управления.
Инструменты и платформы управления данными помогают организациям отслеживать все свои данные, повышать их качество и управлять основными данными, а также многое другое. На рынке представлено большое разнообразие инструментов, включая как новые платформы (например, Alation, Tamr, data.world, Octopai или erwin), так и уже зарекомендовавшие себя решения (например, Informatica и Collibra)2.
Важнейшим элементом этого процесса является необходимость установить защитные ограждения для использования (и неиспользования) данных и донести их до сотрудников, клиентов и других заинтересованных сторон. Программа по работе с данными должна выходить за рамки простого соблюдения правил защиты конфиденциальности клиентов и использования их данных. Она также должна быть направлена на обеспечение прозрачности в отношении того, какие данные и каким образом собираются, как используется информация и целесообразно ли такое использование. Эта задача еще более усложняется при создании моделей искусственного интеллекта, и компаниям необходимо уделять особое внимание тому, чтобы не допустить непреднамеренного закладывания предвзятости в свои модели. Кроме того, компаниям следует регулярно анализировать данные и их использование с точки зрения соответствия меняющимся нормам и законам.
Рассмотрите возможность создания совета по этике данных - межфункционального комитета, в состав которого входят представители бизнеса, отдела по соблюдению нормативно-правовых требований, операционной деятельности, аудита, ИТ и высшего руководства компании. (Подробнее о доверии к цифровым технологиям читайте в главе 31).
Примечания
Брайан Петцольд, Матиас Роггендорф, Кайваун Роушанкиш и Кристоф Шпорледер, "Проектирование управления данными, обеспечивающее ценность", McKinsey.com, 26 июня 2022 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/designing-data-governance- that-delivers-value.
Метаданные: "Метаданные - это информация, которая описывает различные аспекты информационного актива для улучшения его пригодности на протяжении всего жизненного цикла". Источник: Gartner, "Линейка данных включает в себя происхождение данных, то, что с ними происходит, и то, куда они перемещаются со временем. Линейка данных обеспечивает видимость и значительно упрощает возможность отследить ошибки до их первопричины в процессе анализа данных". Источник: Натали Хоанг, "Линейность данных помогает повысить ценность бизнеса", Trifacta, 16 марта 2017 г.
Раздел 5
Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:
Направляете ли вы свои усилия по очистке и обработке данных на те области и элементы данных, которые принесут пользу?
Понимаете ли вы, какие продукты данных необходимы вашей организации для достижения успеха?
Есть ли у вас специальные команды по работе с данными?
Вы четко представляете, где объединение внутренних данных с внешними позволит создать конкурентное преимущество?
Как вы делаете данные более доступными для большего количества людей в вашей организации и непосредственно для ваших цифровых решений?
Измеряете ли вы потребление данных?
Существует ли у вас операционная модель управления данными, в которой все ключевые участники четко определяют свои роли и задачи?
Кто является распорядителями данных в вашей организации и какую пользу они приносят?
Раздел 6. Ключи к разблокировке принятия и масштабирования
Как заставить пользователей принять ваши цифровые решения и масштабировать их в масштабах предприятия
Разработка хорошего цифрового решения может быть сложной и трудной задачей. Но при всей необходимой концентрации усилий и внимания это лишь первый шаг. Заставить клиентов или бизнес-пользователей принять это решение в качестве части их повседневной деятельности, а также масштабировать его по всей клиентской базе, рынкам или организационным подразделениям - каждое из которых имеет свои особенности - зачастую является самой сложной задачей.
Получить инвестиции на разработку цифрового решения обычно проще, чем на его внедрение. Но это гарантированный рецепт того, что вы не увидите отдачи от своих цифровых инвестиций. Как правило, на каждый 1 доллар, потраченный на разработку цифрового решения, планируйте потратить еще как минимум 1 доллар (а иногда и больше, в зависимости от решения) для обеспечения полного внедрения и масштабирования. Эти дополнительные $1 пойдут на внедрение изменений в процессы, обучение пользователей, инициативы по управлению изменениями, а иногда даже на выплату выходного пособия, если речь идет о повышении производительности.
Основная задача по стимулированию внедрения и масштабирования заключается в решении на достаточно детальном уровне технических, технологических и человеческих проблем, которые мешают отличному решению приносить максимальную пользу.
Этот раздел посвящен специфическим сложностям управления изменениями, возникающим при трансформации цифровых технологий и ИИ (мы не будем затрагивать общие темы управления изменениями, такие как коммуникации). Хотя мы рассмотрим вопросы внедрения и масштабирования в конце книги, вам необходимо продумать эти проблемы в самом начале трансформации.
Глава 28: Принятие пользователями и изменение базовой бизнес-модели. Для получения выгоды необходимо не только удовлетворить потребности пользователей, но и изменить базовую бизнес-модель - важнейшая дисциплина, которую многие упускают из виду.
Глава 29: Разработка решений для легкого тиражирования и повторного использования. Разработайте возможность тиражирования, позволяющую легко делиться цифровыми решениями и повторно использовать их в разных сегментах потребителей, на разных рынках или в разных организационных подразделениях.
Глава 30: Обеспечение воздействия путем отслеживания того, что имеет значение. Эффективное отслеживание требует жесткой архитектуры управления эффективностью, которая связывает OKR с операционными KPI, а также сильного процесса поэтапного отслеживания, подкрепленного инструментарием.
Глава 31: Управление рисками и построение цифрового доверия. Остерегайтесь новых рисков, возникающих в результате трансформации цифровых технологий и ИИ в таких областях, как кибербезопасность, конфиденциальность данных и предвзятость ИИ. Управляйте ими, внедряя функции контроля в процесс разработки.
Глава 32: А как же культура? Обратите внимание на "цифровые" лидерские качества 300 лучших сотрудников и инвестируйте в развитие навыков в масштабах всего предприятия.
Примечание
Майкл Чуй и Брайс Холл, "Как высокоэффективные компании разрабатывают и масштабируют ИИ", Harvard Business Review, 19 марта 2020 г., https://hbr.org/2020/03/how-high-performing-companies-develop- and-scale-ai.
Глава 28.
Принятие пользователями и изменение бизнес-модели
Мы часто слышим от обескураженных руководителей такие комментарии, как: "Кажется, мы навсегда застряли в чистилище пилотов", или "У нас большая инерция и сопротивление изменениям", или "Компания предложила хорошее решение, но бизнес его не принял". Эти жалобы - типичный результат того, что мы можем назвать проблемами "последней мили". Это проблемы, которые возникают, когда компания хочет внедрить разработанное ею решение, но обнаруживает, что оно не нужно пользователям или работает не так, как планировалось.
Определение принятия и масштабирования
Принятие: Использование цифровых решений сотрудниками и/или клиентами
Масштабирование: Подход к получению всех преимуществ цифровых решений по мере их распространения на сегменты клиентов, рынки или организационные подразделения
Решение этих проблем требует решительности и постоянных усилий, да, но самое главное - приверженности управлению цифровыми решениями на протяжении всего процесса, от разработки до внедрения.
Возьмем пример Freeport-McMoRan, глобальной горнодобывающей компании, которая разработала семейство решений для оптимизации заданных параметров на медных обогатительных фабриках. Вместо того чтобы просто поставлять решения, команда разработчиков работала бок о бок с непосредственными пользователями в течение восьми месяцев после того, как решения были первоначально внедрены. Они организовали контрольные встречи каждые три часа, 24 часа в сутки 7 дней в неделю, собрав вместе операторов, инженеров и металлургов, чтобы обсудить рекомендации по заданным значениям, полученные с помощью передовых аналитических моделей, и внести оперативные изменения в режиме реального времени.
Такой подход позволил убедиться в том, что сотрудники передовых подразделений знают, как использовать решения, научились доверять им, вносят свой вклад в их совершенствование и становятся их настоящими сторонниками. Такая концентрация внимания на всех этапах процесса принесла свои плоды. Всего за один квартал производительность одного из рудников превысила 85 000 тонн руды в день - на 10 % больше, чем в предыдущем квартале, - при этом коэффициент извлечения меди вырос на один процентный пункт, а работа стала более стабильной. (подробнее об этом случае читайте в главе 33).
Полезно рассматривать принятие решения в двух аспектах. Первая - это принятие решения клиентами или пользователями, которые являются целевой аудиторией, бенефициарами решения. По сути, речь идет о том, чтобы убедиться, что само цифровое решение работает так, как ожидается, и что люди заинтересованы и хотят его использовать. Во-вторых, это понимание влияния внедрения решения на другие элементы бизнеса и их адаптация по мере необходимости.
Двустороннее внедрение пользователей
Обеспечение принятия клиентами или пользователями - это одновременно и проблема пользовательского опыта, и проблема управления изменениями. Если цифровое решение не разработано так, чтобы быть нужным пользователю, или не вписывается естественным образом в его рабочий процесс, оно потерпит неудачу, и никакое управление изменениями этого не исправит. Это итеративный процесс с частыми циклами тестирования и обучения, основанный на данных о том, как конечные пользователи взаимодействуют с решением (подробнее о клиентском опыте и дизайне читайте в главе 16).
Если решение улучшает пользовательский опыт, вам, возможно, придется провести программу управления изменениями, чтобы обеспечить его принятие. Управление изменениями заключается в оказании влияния на конечных пользователей с помощью ряда конкретных мероприятий, чтобы они действительно использовали решение. Эти мероприятия по изменению отражены в хорошо известной и проверенной модели влияния1 , состоящей из четырех элементов (см. Рисунок 28.1):
Вовлечение руководства и подражание лидерам и коллегам, чтобы продемонстрировать поддержку, энтузиазм и поощрение новых решений, которые внедряются.
Убедительная история изменений, объясняющая, почему решение важно для конечных пользователей, клиентов и компании в целом.
Измерения и показатели эффективности (опережающие и запаздывающие показатели эффективности) для отслеживания запланированного поведения и результатов, а также для соответствующего поощрения с помощью правильных стимулов.
Обучение на основе ролей и развитие навыков, чтобы гарантировать, что пользователи обладают необходимыми знаниями и повышают квалификацию для успешного применения решения.
Модель влияния в действии
Пример: Внедрение решения по управлению доходами для грузового бизнеса авиакомпании для 250 торговых представителей по грузовым перевозкам.
Вовлечение лидеров и ролевое моделирование
Убедительная история изменений и коммуникации
Привлечение руководителя грузового бизнеса к участию в ключевых этапах разработки решения
Продемонстрируйте решение на ежегодной конференции по продажам
Расскажите в информационном бюллетене компании о ценности нового решения по управлению доходами для клиентов, авиакомпании и сотрудников
Ролевые тренинги и развитие навыков
Измерение и производительность
Обучение 250 торговых представителей по всему миру работе с новым приложением
Обеспечьте поддержку по вызову в течение первых 3 месяцев после развертывания.
Измерьте степень внедрения решения через частоту использования приложения
Включение показателя внедрения в анализ эффективности работы руководителей высшего звена отдела продаж
ПРИЛОЖЕНИЕ 28.1
Важным моментом при разработке программы изменений является объединение всех соответствующих решений в единую программу вмешательства в процесс изменений для конечного пользователя (вместо того чтобы несколько раз обращаться к одному и тому же конечному пользователю, чтобы заставить его использовать каждое отдельное решение). Например, если продавцу грузовых авиаперевозок необходимо понять, как использовать три новых решения: одно для оценки доступных грузовых мощностей, другое для оптимизации ценообразования на эти мощности, а третье для выставления счетов клиентам, то разумнее объединить все эти решения в единую программу вмешательства в изменения. Это одна из причин, по которой цифровые преобразования и преобразования с использованием ИИ более эффективны, когда преобразуется сразу весь домен, а не отдельные решения или сценарии использования.
Адаптация бизнес-модели
Многие компании относятся к цифровому решению как к добавлению ингредиента в рецепт и ожидают, что блюдо станет вкуснее. Более точная аналогия заключается в том, что развертывание решения - это как пристройка к
дом. Он не будет работать, если не изменить фундамент, стены, электрическую и водопроводную системы дома, чтобы они могли выдержать пристройку. Это выходит далеко за рамки обучения людей тому, как пользоваться новым инструментом. Это требует от компаний анализа всех взаимозависимостей, связанных с самим решением, и определения последствий для бизнес-модели, которая будет работать в будущем.
Эти инновации на уровне системы становятся все более понятными, особенно в контексте внедрения принятия решений на основе искусственного интеллекта.2 На рисунке 28.2 показаны изменения в бизнес-моделях, которые мы часто наблюдаем в нашей работе.
Например, страховая компания разработала аналитическое решение, помогающее агентам повышать продажи полисов клиентам. Однако для того, чтобы это решение заработало в полевых условиях, необходимо было внести изменения в алгоритм ценообразования, стимулы для полевых сотрудников, модель распространения, модель привлечения клиентов, а также метрики и показатели эффективности. Работа над этими изменениями включала создание бизнес-модели будущего состояния и обновление всего спектра связанных с ней бизнес-процессов, чтобы решение могло приносить максимальную пользу.
По сути, речь идет о работе со всеми соответствующими вышестоящими и нижестоящими функциями бизнеса (дистрибуция, цепочка поставок, маркетинг, продажи и т. д.) для определения критических изменений в процессах, управлении производительностью, организации и навыках, необходимых для того, чтобы цифровое решение принесло максимальную пользу. Подобное широкое межфункциональное воздействие - это природа цифровых преобразований и преобразований с использованием искусственного интеллекта и их отличительная особенность по сравнению с любым другим типом преобразований. Именно поэтому для обеспечения межфункционального согласования необходимо участие генерального директора или руководителя подразделения (подробнее об этом читайте в главе 7).
На рис. 28.3 показан пример того, как коммерческая авиакомпания, внедрявшая новый комплекс решений по управлению доходами для грузового бизнеса на своих пассажирских авиалиниях, охватила целый ряд проблем, связанных с предшествующей и последующей деятельностью.
Смена бизнес-моделей, вызванная внедрением новых цифровых решений
Примеры
ПРОДАЖИ
Прямые продажи на местах Электронная коммерция
Последствия для бизнес-модели
Правильное определение размера штата продавцов на местах с течением времени
Увеличение численности группы по работе с клиентами
Интеграция ИТ внутри
команда электронной коммерции
МИКС ДОХОДОВ
Продукт Услуги
Последствия для бизнес-модели
Потребность в сервисной поддержке на местах
Увеличивается продолжительность и сложность контрактов с клиентами
ОПЕРАЦИИ
Ручная сборка Сборка Cobot1
Последствия для бизнес-модели
Сокращение количества прямых трудозатрат и контроль качества с течением времени
Новое сотрудничество между командами по проектированию коботов и производственными операциями
СООТНОШЕНИЕ КАПИТАЛЬНЫХ И ОПЕРАЦИОННЫХ ЗАТРАТ
Низкие капитальные вложения, высокие эксплуатационные расходы
Последствия для бизнес-модели
Высокие капитальные затраты, низкие эксплуатационные расходы (например, за счет инвестиций в новые цифровые решения и последующей автоматизации)
Капиталоемкость растет Требуются инвестиции в обслуживание(могут быть инвестиции в людей, аналитику или и то, и другое)
1. Кобот: совместный робот, способный обучаться нескольким задачам, чтобы помогать людям, в отличие от автономного робота, который жестко запрограммирован на многократное выполнение одной задачи, самостоятельную работу и неподвижность.
ПРИЛОЖЕНИЕ 28.2
Оценка влияния сквозного процесса
Пример авиакомпании
Авиакомпания разработала комплекс решений на основе искусственного интеллекта, чтобы помочь своей организации по продаже грузовых перевозок максимально эффективно использовать и устанавливать цены на грузовые места для пассажирских авиалиний.
ПРИМЕР ВОЗДЕЙСТВИЯ НА ВОСХОДЯЩИЙ ПОТОК
ПРИМЕР ВОЗДЕЙСТВИЯ НА ПОСЛЕДУЮЩУЮ ДЕЯТЕЛЬНОСТЬ
Сквозные процессы: Как влияет на процесс?
Торговые представители должны знать, на каких рейсах есть свободные места и по какой цене.
Увеличение времени в аэропортах для погрузки/разгрузки большего количества грузов
Управление эффективностью: Как отслеживать эффективность?
Сбросьте план продаж, поскольку можно продать все больше и больше грузов
Новые цели и стимулы для дополнительного пассажирского багажа
Организация и навыки: Как влияют на людей?
Торговые представители должны понимать, как использовать новое решение для управления доходами
Операторам грузовых перевозок в аэропортах необходимо пройти обучение оптимальным процедурам паллетирования
Установки и поведение: Как привлечь людей к работе?
Торговые представители должны принять изменения Улучшение межфункционального взаимодействия междукомандами по управлению доходами от грузовых и пассажирских
ПРИЛОЖЕНИЕ 28.3
Задача состоит в том, чтобы заранее предусмотреть как можно больше таких проблем, но реальность такова, что выявить все соответствующие "дроссельные точки", как выше, так и ниже по течению, довольно сложно. Некоторые из них неизбежно будут выявлены, когда решение окажется в полевых условиях и люди смогут увидеть, как оно работает на самом деле. Поэтому процесс внедрения носит итеративный характер и требует постоянного анализа и доработки.
Создание команды по усыновлению
Уровень поддержки внедрения может сильно варьироваться в зависимости от сложности решения, размера и географической распределенности базы конечных пользователей, а также масштаба изменений, лежащих в основе бизнес-модели. Как правило, за успешное внедрение решения отвечает лидер домена. В его обязанности входит мобилизация необходимых ресурсов для поддержки усилий по внедрению.
В тех случаях, когда процесс усыновления особенно сложен и требует долгосрочной поддержки, подумайте о создании команды по усыновлению. В команду по внедрению входят люди с различными навыками, включая управление изменениями и коммуникации. Эта команда работает в режиме agile и участвует в разработке на ранних этапах, где она может выявить проблемы внедрения и оценить потребности в поддержке внедрения.
Четко сформулировав эти потребности, команда определяет соответствующие цели, наборы инструментов и технологий - некоторые из них используются в других проектах, а другие создаются заново, чтобы поддержать запуск и полное внедрение решения.
Примечания
Скотт Келлер и Колин Прайс, "За пределами производительности" (Hoboken, NJ: Wiley, 2011).
Аджай Агравал, Джошуа Ганс и Ави Голдфарб, Сила и предсказание
(Бостон: Harvard Business Review Press, 2022).
Глава 29.
Разработка решений для легкого воспроизведения и повторного использования
Часто бывает так, что когда вы думаете, что закончили что-то, вы оказываетесь в начале чего-то другого.
-Фред Роджерс
Масштабирование - это тиражирование внедрения решения в различных средах для достижения эффекта в масштабах предприятия. Классические ситуации, в которых требуется тиражирование, включают масштабирование по сети производственных мощностей, различным географическим рынкам, сегментам клиентов или различным организационным группам. В этой главе мы будем называть эти цели репликации просто "подразделениями".
Масштабирование требует разработки наиболее эффективного подхода к тиражированию для внедрения в каждом подразделении и создания эффективного метода повторного использования и адаптации цифрового решения к специфике различных подразделений.
Разработка эффективного подхода к тиражированию
Начните с определения того, какие решения необходимо масштабировать и где. Обычно это требует, чтобы руководители различных подразделений согласились с ценностью для своего конкретного подразделения, поняли, что от них ожидается, высвободили необходимые финансовые и человеческие ресурсы и договорились об ответственности за ожидаемые выгоды. Далее необходимо определить последовательность подразделений, в которых будет развернуто решение. При определении последовательности обычно учитываются три важных фактора: время получения выгоды, простота внедрения и готовность подразделения. В Примере 29.1 показано, как одна горнодобывающая компания использовала эти соображения при определении последовательности действий по масштабированию.
Далее необходимо выбрать архетип масштабирования. Выбор правильного архетипа зависит от общей сложности решения, готовности организации принять изменения и срочности масштабирования преобразований в масштабах предприятия. В разных решениях могут использоваться разные архетипы (см. Рисунок 29.2). Три основных варианта:
Линейные волны. Этот подход предполагает последовательное масштабирование от одного подразделения к другому, при этом центральная команда наращивает потенциал в каждом новом подразделении. Этот подход более медленный, но он позволяет добиться устойчивого прогресса, обеспечивая получение прибыли на каждом подразделении, прежде чем переходить к следующему. Такой подход наиболее целесообразен при работе с небольшим количеством подразделений с высокой стоимостью, таких как шахты или нефтеперерабатывающие заводы.
Экспоненциальные волны. Этот подход заключается в запуске все более крупных волн. В первой волне может быть два блока, во второй - четыре, в третьей - восемь и так далее. Часто для этого требуется использовать модель "обучение-обучение". Например, руководители подразделений, включенных в план развертывания, могут быть включены в процесс внедрения первых двух подразделений, чтобы они могли учиться и быть готовыми к предстоящей работе по внедрению.
Влияние на результат достигается быстрее, но качество реализации может быть сложнее поддерживать. Этот подход лучше всего работает с большим количеством (менее значимых) подразделений.
Определите последовательность масштабирования
Пример горнодобывающей промышленности
Бизнес-подразделение А Бизнес-подразделение Б
Сайт E
Сайт A
Сайт G
Сайт B
Сайт F
Сайт C
Сайт H
Сайт D
Сайт D
Сайт E
Сайт C
Сайт B
Сайт F
Сайт G
Сайт A
Сайт J
Сайт I
Сайт H
Сайт I
Простота внедрения
Расчетная годовая экономия
Существующий
Возникающие 
Критический пробел
(6 измерений вправо)
Сайт J
Tech
технико-экономическое обоснование
Возможности
и ресурсы
Готовность
меняться
Сходство
с другими сайтами
Открытость для
сотрудничать
Подходит для организации
цели
ПРИЛОЖЕНИЕ 29.1
Большой взрыв. Этот подход предполагает одновременное развертывание решения во всей организации. Например, решение для составления расписания маршрутов авиакомпаний имеет смысл развернуть сразу везде. Этот архетип требует одновременного создания возможностей для всех критически важных ролей, часто с использованием скоординированных групп внедрения, развернутых по всей организации. Такой подход лучше всего работает в сетевых компаниях.
Различные способы продвижения по пути масштабирования
Пример типа
Определите, какие
решения для масштабирования и где
Определите
последовательность модулей
Выберите
архетип масштабирования
Подход
Горная промышленность
Горнодобывающая компания разработала решение по оптимизации заданных параметров для своих обогатительных фабрик
Оптимизатор заданного значения
Масштабирование по всем 12 концентраторам
Упорядочить концентраторы по потенциальному воздействию, зрелости ИТ и доступности данных датчиков
Линейные волны
Внедрять на каждом участке
Начните с каждого сайта: оценка данных, настройка, обучение, а затем запуск.
Постройте индивидуальное решение для сайта 1 и передайте модель данных на сайты 2 и 3, чтобы обеспечить более быстрое внедрение на сайте 3+
Автомобили
Автомобильная компания разработала семейство решений по контролю качества для различных продуктов (т.е. систем и компонентов)
Масштабный пакет решений
Масштабирование по платформам транспортных средств
Упорядочить растения по потенциальному воздействию и схожести платформ
Экспоненциальные волны
Развертывание на заводах, производящих один и тот же продукт, с ведущим заводом, за которым следуют волны из 2, 4, 8+ заводов.
Создайте индивидуальное решение для одной продуктовой платформы, стандартизируйте подход для продуктовых платформ 2 и 3, чтобы подготовиться к масштабированию.
Авиакомпания
Авиакомпания разработала решение для управления доходами, чтобы помочь своим 250 представителям по продаже грузовых перевозок по всему миру максимизировать доходы от грузовых перевозок в сети коммерческих авиалиний.
Решение для управления доходами
Масштабирование всех 1200 сетевых маршрутов
Все маршруты имеют одинаковый приоритет
Большой взрыв
Проведите тренинг для всех торговых представителей по грузоперевозкам
Разработка производственной версии решения для всех маршрутов
"Переключение" с помощью решения, интегрированного в внутреннюю систему планирования грузоперевозок
ПРИЛОЖЕНИЕ 29.2
Создание метода повторного использования решений - концепция активизации
Что, если бы компания создавала каждый компонент своего продукта с нуля при каждом заказе, без каких-либо стандартизированных или согласованных деталей,
процессов и протоколов обеспечения качества? Есть все шансы, что любой руководитель расценит такой подход как серьезный тревожный сигнал, предвосхищающий экономию на масштабе и вводящий неприемлемый уровень риска, и немедленно примет меры по его устранению.
К сожалению, когда дело доходит до масштабирования цифровых решений и решений на основе искусственного интеллекта, компании часто сталкиваются с необходимостью переделывать множество дел. Это - убийца масштаба. Эффективное масштабирование зависит от возможности повторного использования как можно большей части решения при его развертывании на предприятии.
Чтобы воспользоваться преимуществами многократного использования, цифровое решение и решение на основе искусственного интеллекта должны быть упакованы в виде набора модулей или активов (отсюда термин assetiza- tion). Это облегчает его адаптацию к неизбежным различиям в условиях работы подразделений. Например, у горнодобывающей компании могут быть медные обогатительные фабрики, построенные по разным технологиям переработки руды. В то время как цифровое решение для оптимизации производительности может иметь общий механизм машинного обучения, конвейеры данных для получения данных от оборудования по переработке руды, скорее всего, будут специфическими для каждой фабрики.
Первое, что необходимо сделать при разработке подхода к повторному использованию решений, - это признать, что цифровые решения имеют разные уровни возможности повторного использования (см. Рисунок 29.3). Некоторые решения являются узкоспециализированными и специализированными и вряд ли могут быть использованы повторно. Другие полностью стандартизированы и могут быть упакованы в программные приложения. Где-то между ними находится широкий класс решений, в котором 60-90 % решения может быть использовано повторно. Большинство собственных цифровых и аналитических решений, которые разрабатывают компании, попадают в эту категорию.
Основной принцип эффективной активации - возможность повторного использования для достижения эффективного и быстрого внедрения. Эффективная активация требует управления тремя элементами (см. Рисунок 29.4):
Этапы процесса внедрения. Это пошаговые инструкции по внедрению и эксплуатации, необходимые для того, чтобы команды могли использовать цифровое решение. По сути, это стандартизированный способ обучения людей использованию и управлению решением, включая использование конкретных модулей для нужд конкретного подразделения.
Типы цифровых решений и решений на основе ИИ в зависимости от степени стандартизации
ИНДИВИДУАЛЬНОЕ РЕШЕНИЕ
АССЕТ
СТАНДАРТИЗИРОВАННЫЙ ПРОГРАММНЫЙ ПРОДУКТ
ОПИСАНИЕ
Решение для решения конкретной задачи. Пользовательские решения иногда используют фрагменты кода, но обычно строятся с нуля
Решение проблемы, которая является общей для нескольких подразделений (например, заводов, рынков или ДЕ), но требует
настройка под конкретные подразделения. Основная база кода, пользовательский интерфейс и рецепт доставки используются и поддерживаются на уровне предприятия
Автономное корпоративное программное приложение, обслуживающее множество конечных пользователей и не требующее практически никакой настройки
ПРИМЕР
Специфический анализ для выявления первопричины ухудшения состояния оборудования
Консультационная система на основе ИИ для оптимизации урожайности растений
Набор инструментов для статистического анализа
СТЕПЕНЬ СТАНДАРТИЗАЦИИ
10%
60-90%
>90%
КОМПОНЕНТЫ
Данные (обычно в автономном режиме)
Данные (часто в режиме онлайн)
Данные (часто в режиме онлайн)
Модель (часто разрабатывается в блокноте и редко запускается в производство)
Основная кодовая база, фреймворк моделирования, пользовательский интерфейс
Рецепт поставки и глубокая поддержка SME
Стандартный пакет программного обеспечения
Внедрение на предприятиях и обучение пользователей
Обучение и поддержка пользователей
Управление корпоративными продуктами
Поддержка "службы технической поддержки"
Управление корпоративными продуктами (внутреннее или 3P)
MLOps и постоянный контроль эффективности
Рецепт эффективной активации
ПРОЦЕСС
ТЕХНОЛОГИЯ
ЛЮДИ
Руководство по диагностике
Пошаговое руководство по выявлению, определению размера и приоритетности возможностей развертывания. Включает стандартный подход к оценке воздействия
Руководство по эксплуатации и поддержке
Пошаговые инструкции по запуску и обслуживанию актива, роли и обязанности, протоколы эскалации
Руководство по доставке
Пошаговая методология развертывания актива - включая стандартные и специализированные компоненты
Не исчерпывающий
Строительные блоки кода
Модульные и многократно используемые компоненты (могут применяться для многих вариантов использования)
Аналитический конвейер
Готовый, легко конфигурируемый, сквозной код для конкретного случая использования
Стандарты для создания кодексов и сотрудничества
Документ, определяющий межпрограммные стандарты и рекомендации по сотрудничеству для разработки аналитических приложений
Документирование знаний о домене
Описание варианта использования, где находится ценность, и выводы о моделировании процесса (например, описание процесса, операционные KPI, деревья проблем).
Инфраструктура MLOps
Стек технологий для развертывания приложений, мониторинга, управления производительностью
Эксперты по доставке/масштабированию
Эксперты по предмету, специалисты по анализу данных, бизнес-переводчики
Программа наращивания потенциала
Определение ролей и обязанностей, программа обучения для создания или укрепления потенциала
Люди для поддержания/инноваций
Владелец продукта, инженеры ML, владелец корпоративного продукта
Организационные структуры
Управление, как формируются команды и взаимодействуют роли, а также взаимосвязь с другими организационными подразделениями
ПРИЛОЖЕНИЕ 29.4
Модульные технологические компоненты. Речь идет об использовании блоков кода, которые могут быть использованы через API и легко заменены без ущерба для остальной части решения. Это ускоряет адаптацию к конкретной ситуации при масштабировании. В примере, приведенном в Примере 29.5, горнодобывающая компания использовала модульную архитектуру, разбитую на несколько слоев, для максимального повторного использования кода на других горнодобывающих объектах, несмотря на то, что технологии и среда передачи данных на этих объектах были разными.
Пример модульной архитектуры для решения по оптимизации уставки
Базовый слой
Горизонтальные платформенные сервисы Как правило, 30% от общего объема решений Полностью многократно используемые сервисы
Менеджер конвейера данных, инструмент для исследования данных, пакет ML
Платформа, инфраструктура как код, конвейер DevOps
Уровень вариантов использования
Компоненты, созданные для решения конкретных задач
Как правило, 20% от общего объема решения
Команды доставки подстраиваются под конкретное подразделение
Пользовательский интерфейс для конкретного случая Оптимизатор уставки
Особенности конкретного случая использования
Анализатор первопричин
Слой, характерный для конкретного устройства
Конфигурация инструментария
Как правило, 20% от общего объема решения Некоторые настройки
Обученные модели и ограничения
Особенности, характерные для устройства/процесса
Основной слой
Компоненты, не зависящие от конкретного случая использования Как правило, 30% от общего объема решения Мало или совсем не настраивается
Приборная панель и отчеты Коннекторы приборной панели
Библиотека оптимизаторов, компоненты трубопроводов, механизм моделирования
ПРИЛОЖЕНИЕ 29.5
Специалисты по поддержке решения. Вам понадобится команда экспертов предметной области (например, инженеры ML, владельцы корпоративных продуктов), которые понимают, как развернуть решение и адаптировать его к различным средам. Эти люди должны знать, как обучать пользователей и внедрять организационные изменения.
Продуманный подход к активации может привести к существенному увеличению скорости и эффективности развертывания. На рис. 29.6 показано развертывание оптимизаторов уставки в двух разных отраслях промышленности, а также увеличение скорости развертывания за счет эффективной активации. Чем более стандартизированы агрегаты, тем больше преимуществ, что отражено на рис. 29.6, где парк электрогенераторов получает еще больше преимуществ от актизации, поскольку большинство решений являются общими для всех заводов (в отличие от операций по переработке минералов, которые, как правило, в большей степени зависят от конкретного объекта и руды).
Сокращение времени развертывания за счет использования активов
Примеры переработки полезных ископаемых и производства электроэнергии Количество недель на внедрение решения
Усиление
Разработка
POC 
Подготовка
Применение оптимизации заданного значения при обогащении полезных ископаемых
Применение оптимизации уставки для всего парка электростанций
36 20
-65%
10
7
1
2
2
4
10
4
4
4
6
12
-39
28
8
22
8
10
3
19
12
6
5
2
%
Сайт 1
Сайт 1
Сайт 2
1
Сайт 3
Участок 1Участок 2Участки 3-10
Чтобы повторное использование решений стало частью общего корпоративного подхода к масштабированию, рассмотрите возможность создания модели финансирования и стимулирующей структуры, поощряющей повторное использование. Обычно это означает: (а) выделение явных инвестиций в актирование решения после того, как оно прошло стадию MVP; (б) создание централизованного финансирования и ресурсов для поддержки развертывания; (в) измерение уровня внедрения в подразделениях и соответствующее стимулирование их руководителей.
Пример из практики: Обеспечение внедрения и масштабирования 400 моделей искусственного интеллекта
Vistra, ведущая энергетическая компания, инвестировала в подход к быстрому масштабированию решений на основе искусственного интеллекта, разработанных для оптимизации парка электростанций. Эти решения состояли из 400 моделей ИИ, настроенных на оптимизацию различных частей работы электростанций.
С самого начала процесса разработки решения дизайнеры работали с операторами, чтобы понять, как выглядит их повседневная деятельность. Инструменты ИИ должны были облегчить жизнь операторов, поэтому, например, экран, на котором отображались решения и рекомендации ИИ, был интегрирован в интерфейс, которым операторы уже пользовались, чтобы им не нужно было следить за дополнительным экраном. Сами дисплеи были спроектированы так, чтобы их было легко читать. Решение отображает зеленый сигнал, если завод работает оптимально, и красный, если не работает, с соответствующими рекомендациями, включающими стоимость выполнения рекомендации.
Когда решение продемонстрировало свою ценность на пилотной площадке и было одобрено для масштабирования, команда инженеров по программному обеспечению и ML сразу же взялась за рефакторинг, модулизацию и контейнеризацию кода. Таким образом, для каждого развертывания был создан единый пакет программного "ядра", который можно было обновлять и улучшать. При этом всегда требовалась некоторая кастомизация, поскольку каждый завод имеет свои уникальные характеристики.
Специальные команды по настройке, состоящие из специалистов по обработке данных, инженеров, операторов и экспертов в области энергетики, работали с каждой станцией, чтобы адаптировать решение к ее уникальным условиям. Команда создала инфраструктуру MLOps, чтобы свести данные с каждого энергоблока Vistra в единую базу данных (подробнее о MLOps читайте в главе 23). Она использовала программное обеспечение GitLab для управления контролем версий кода и контейнеризации кода, чтобы его можно было легко развернуть в любой среде. Команда также создала информационные панели для мониторинга производительности и использования моделей и управления непрерывным совершенствованием каждой модели.
Наконец, в рамках проекта было организовано три уровня обучения: для рядовых сотрудников (чтобы научиться использовать модели), для технической команды (чтобы научиться разрабатывать и поддерживать модели ИИ) и для руководящего состава (чтобы понять, как использовать модели ИИ и трансформировать работу бизнеса).
Глава 30.
Обеспечение воздействия путем отслеживания того, что имеет значение
Удивительно, но многие руководители компаний не имеют четкого представления о том, как проходит их цифровая трансформация и трансформация с помощью искусственного интеллекта.1 Продвигаемся ли мы к более цифровой бизнес-модели? Создаем ли мы цифровые возможности, как мы говорили? Окупается ли это с точки зрения удобства для клиентов и влияния на конечный результат?
Никто не будет спорить о необходимости измерения прогресса в области трансформации. Но вопрос в том, что и как измерять. Отслеживание эффективности может быстро разрушиться под собственным весом, если оно плохо продумано и не имеет правильных вспомогательных инструментов.
Качественная инфраструктура производительности включает в себя (1) разработку правильных KPI для управления производительностью, (2) отслеживание с помощью stage-gate процесс и вспомогательные инструменты документооборота, и (3) создание эффективного офиса трансформации.
Архитектура управления производительностью и KPI
Четко определить, какие показатели эффективности необходимо измерять, - это уже половина успеха. При трансформации цифровых технологий и ИИ ключевые показатели эффективности (KPI), как правило, делятся на три группы: показатели создания стоимости, показатели здоровья стручка и показатели управления изменениями (см. Рисунок 30.1).
Архитектура управления эффективностью цифровой трансформации и ИИ
СОЗДАНИЕ СТОИМОСТИПОДДЕРЖАНИЕ ЗДОРОВЬЯ УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
ЦЕЛЬ
Оценка влияния цифровых решений на основные бизнес/операционные KPI
Измерьте здоровье и зрелость стручков
Оценка прогресса в создании новых возможностей и мобилизации организации
МЕТРИКИ
Операционные КПЭ
KPI зрелости
Наращивание потенциала и управление изменениями KPI
ПРИМЕРЫ
Принятие клиентов (%) Онлайн-продажи (% от продаж) Доходность процесса (%)
Коэффициент перекрестных продаж (%)
Достаточность штатного расписания OKR Достижения Agile/DevOps зрелости Частота выпуска релизов
# Количество мобилизованных капсул Вовлеченность сотрудников Наем/повышение квалификации талантов Достижения по этапам
ЕДИНИЦА АНАЛИЗА
Решения и домены
Стручки
Конкретные возможности, лидерство, вовлеченность сотрудников
АКТУАЛЬНО ДЛЯ
Руководители высшего звена, руководители подразделений
Лидеры доменов и владельцы капсул
Руководители высшего звена и лидеры в области трансформации
ПРИЛОЖЕНИЕ 30.1
Отслеживание создания стоимости с помощью бизнес/операционных КПЭ
Цифровые решения, как правило, нацелены на один или несколько бизнес/операционных KPI, которые обычно можно перевести в финансовые или клиентские преимущества.
Эти показатели важны для лидеров домена и руководителей высшего звена. Для инвесторов они также являются убедительным доказательством прогресса цифровой трансформации.
В Примере 30.2 приведен пример международного банка, который каждый квартал отчитывается перед инвесторами о ключевых показателях цифровой трансформации, а именно о внедрении клиентами мобильных приложений, цифровых продажах, выводе транзакций из филиальной сети и сокращении численности персонала в филиалах.
Дерево факторов стоимости - полезный инструмент для определения того, какие цифровые решения и решения в области искусственного интеллекта должны улучшить основные операционные КПЭ. Дерево также используется для увязки ОКР подразделений, работающих над данным решением, что позволяет создать единое представление о том, как будут достигнуты улучшения.
На рисунке 30.3 показан пример компании, занимающейся пенсионным страхованием. Доход такого предприятия зависит от количества компаний, заключивших договор на пенсионное страхование, среднего количества сотрудников, участвующих в плане, и среднего дохода на одного участника.
По мере декомпозиции дерево переходит к операционным KPI, таким как количество предложений, сделанных потенциальным клиентам, и процент побед. Как правило, именно на этом уровне цифровые решения влияют на эффективность бизнеса. В данном примере руководитель коммерческого направления решил разработать три цифровых решения, как показано на рис. 30.3. Решение 2 в этом примере направлено на упрощение регистрации участников. Над этим решением будут работать две группы. Первая группа будет работать над оптимизацией приложения, а вторая - над разработкой API для предварительного заполнения информации о сотруднике.
Руководитель коммерческого направления должен отслеживать прогресс на уровне операционных KPI. Для решения 2 это будет процент завершенных приложений и уровень удовлетворенности пользователей (не показаны в дереве факторов ценности). С другой стороны, владельцы подсистем должны отслеживать ключевые результаты, которые непосредственно контролируются подсистемами, и где прогресс может быть достигнут за несколько недель или максимум за несколько месяцев. Хорошим примером в этом случае является сокращение количества шагов для завершения приложения, которое обычно достигается за несколько месяцев.
Классические KPI бизнес-операций, отслеживаемые в ходе цифровых преобразований в банковской сфере
Пример из отчетности для инвесторов одного из ведущих международных банков, 2016-2020 гг.
0
100
50
22
40
2019 2020
2017
20
14
2020
Используют ли мои приложения клиенты?
26
2018
20
60
2016
2017
92
2018
72
20
40
36
60
78
36
0
43
Выводятся ли транзакции из сети филиалов?
100
80
23
40
80
16
2019
80
2019 2020
2016
60
20
2018
80
11
0 0
2016 2017 2018 2019 2020 2016
26
28
2017
15
60
40
100
29
Автоматизируются ли процессы?
100
100
84
Легко ли купить мои банковские продукты онлайн?
20
ПРИЛОЖЕНИЕ 30.2
Дерево факторов стоимости для определения того, как цифровые решения влияют на KPI
Пример пенсионного страхования
ДЕЛОВЫЕ KPI
ОПЕРАЦИОННАЯ KPI
POD OKR
Решение 1: планы по завоеванию/сохранению
Размещение в PGIM
Дополнительные сборы
Комиссионные за регулярное поступление денег
# предложений
Коэффициент выигрыша (%)
# необходимые документы
# Количество планов, отправленных на повторные торги
Плата на уровне плана
Стабильное размещение ценностей
# Количество потерянных планов
ВОЗВРАТ
Под 1: упрощение процедуры подачи заявления на зачисление
Средняя #
участников по каждому плану
Бод 2: предварительное заполнение информации о сотрудниках
% охвата информации о сотрудниках
Удержание %
Шаги для заполнения заявки
Время заполнения заявки
# сотрудников, имеющих право голоса
% одобрен
% план с учетом данных до населения
Плата за ведение учета
Комиссионные при переводе средств в IRA
Доля фонда имущества
Всего планов
# сотрудников, имеющих право голоса
Доход на одного участника
% заполненного заявления
Продажи нового бизнеса
# планов на начало года
# участников
Решение 2: Регистрация на диске
Под 1 и 2 ОКР
Решение 3: соотнесите плату с увеличением затрат
Отслеживание и отчетность по сферам деятельности
Отслеживание и составление отчетов о результатах цифровой трансформации.
За ними следуют под и можно отслеживать цифровые преобразования производительности mgmt.
На рисунке 30.4 показано, как организованы ОКР для каждого блока, а также поэтапное достижение ожидаемых ключевых результатов и конечных целей улучшения. Здесь также показаны основные предположения о том, как решение позволит снизить количество отказов от заявок и увеличить число участников.
Сформулировать эти предположения может быть непросто. Трудно заранее определить, насколько снизится процент отказов от услуг благодаря упрощенному приложению и заранее заполненным данным о сотрудниках. Это требует суждения. Поэтому очень важно поэтапно получить ключевые результаты и проследить, как версия 1 решения влияет на показатели отказа от услуг, что позволит убедиться в необходимости продолжения усилий в версии 2 и, в конечном итоге, в версии 3, или переключиться на более перспективные направления.
Разработка дерева драйверов и отслеживание соответствующих KPI является основополагающим фактором для общего успеха цифровой трансформации. Оно обеспечивает четкую "Северную звезду", позволяет сосредоточиться на создании стоимости и создает четкую систему подотчетности.
Оценка здоровья стручков
Подразделение - это "боевая единица" в цифровой трансформации и трансформации с помощью ИИ. Невозможно успешно провести цифровую трансформацию без здоровых, зрелых стручков.
Многие цифровые преобразования продвигаются медленнее, чем планировалось изначально, потому что их подразделения плохо сконфигурированы (например, члены подразделения работают неполный рабочий день, не обладают достаточными навыками), не внедрили современные методы работы (например, agile, DevOps) или не имеют критически важных возможностей (например, управление производством, дизайн пользовательского опыта). По нашему опыту, разница в производительности между низкоэффективным и высокоэффективным подразделением может составлять 5× и более. Измерение и управление состоянием капсулы действительно имеет значение.
Оценка здоровья капсул производится с помощью трех линз:
Метрики конфигурации бодов. Это позволяет ответить на простой вопрос: Правильно ли укомплектована капсула? Это кажется достаточно очевидным, но каждая компания имеет ограничения по ресурсам, и капсулы могут работать долгое время без надлежащего обеспечения ресурсами. Вы действительно хотите ответить на два основных вопроса: Выделены ли ресурсы капсулы? И заполнена ли каждая роль человеком, обладающим необходимыми навыками? Эту оценку лучше всего проводить владельцу стручка и лидеру домена. QBR - отличная возможность оценить это в рамках отчетности QBR.
Бизнес/операционные KPI, связанные с под OKR
Пример из практики: Составление карты OKR - стимулирование привлечения клиентов к пенсионному страхованию
Экономическое обоснование решения
400 000Решение позволит сократить
заброшенный заявление
Уровень оставленных заявоксравнению с прошлым годом и 20% до 5% дополнительному набору 300 000 человек.
NPS из 10 приложений и промышленности
Ведущий NPS 50
2/3 заполненных заявок обычно зачисляются, что позволяет получить 200 000
дополнительные слушатели
Средняя маржа млн на участникаEBITDA
$500
NPS = 50
ЦелиКлючевые результаты
V1 - год 1V2 - год 2
Цель путешествия V3 - год 3
Под 1
Сократите время заполнения заявки на 60 %.
Ключевой результат 1.1:
Сократите количество необходимых документов
8
5
5
2
2
Ключевой результат 1.2:
40
30
30
20
10
Сократите количество этапов применения
Под 2
Включение функции предварительного заполнения данных о сотрудниках для 50% планов
ПРИЛОЖЕНИЕ 30.4
Ключевой результат 2.1:
% планов с API-связью с системой управления персоналом
0
30
30
50
50
Ключевой результат 2.2:
Информация о супруге и иждивенцах
Информация о предыдущем плане
Основная информация о сотрудниках
Предварительно заполненная информация о типе сотрудника
Показатели производительности стручка. Здесь речь идет о функционировании стручка. Эти показатели обычно извлекаются из инструментов управления бэклогом, например, Jira, Azure DevOps, Digital.ai (поэтому важно обучать подгруппы последовательному использованию этих инструментов). Хотя в отрасли ведутся споры о том, какие показатели лучше отслеживать, мы рекомендуем отслеживать следующие показатели. Первые четыре известны как стандартные метрики DORA (DevOps Research and Assessment). (Рисунок 30.5):
Частота развертывания - измерение среднего времени между успешными выпусками кода в производство для каждого приложения. Если релизы ограничены бизнес-причинами, то в качестве косвенного показателя можно использовать частоту развертывания до приемочного тестирования (UAT).
Время подготовки к изменениям - время от окончания цикла разработки до развертывания в производстве. Эта метрика показывает, насколько эффективен (и автоматизирован) процесс от момента проверки кода до момента интеграции, тестирования и развертывания нового решения.
Среднее время восстановления (MTTR) - это среднее время, необходимое для восстановления после сбоя продукта или системы. Оно показывает, была ли система спроектирована с учетом отказоустойчивости, и насколько быстро вы решаете проблемы, связанные с простоем, чтобы вернуть системы в рабочее состояние.
Показатель отказов изменений - измерение процента развертываний, которые приводят к отказу в производстве. Показатель отказов изменений берет все ваши рабочие процессы за определенный период и вычисляет процент, который закончился неудачей или потребовал исправления (например, потребовал исправления, отката, исправления вперед, патча).
Velocity - для расчета времени выполнения пользовательских историй в конкретном спринте по сравнению с их оценкой. Velocity можно использовать для измерения того, сколько работы может быть завершено в каждой итерации, и помогает предсказать, сколько времени потребуется для завершения будущих спринтов или всего проекта.
Отток кода, также называемый переработкой, показывает, как часто редактируется данный кусок кода - например, файл, класс, функция. Например, вы можете измерить, какой процент кода переписывается в течение трех недель с момента его первого слияния.
Измерение производительности стручков
Пример глобальной компании по управлению благосостоянием
Elite
Высокий 
Средний
Низкий
СРЕДНЯЯ ПРОИЗВОДИТЕЛЬНОСТЬ
ЕЖЕМЕСЯЧНАЯ ТЕНДЕНЦИЯ
ПРОИЗВОДИТЕЛЬНОСТЬ ПО ГРУППАМ
За последние 30 днейЗа последние 30 дней
ЧАСТОТА РАЗВЕРТЫВАНИЯ
Среднее время между успешным выпуском кода в производство для каждого приложения
33,1 дня
40
30
20
Дни 53
41 45
45
35
31
22 21
23
24
27
Мар
Апр
Май
Jun Июль Август
Группы продуктов и платформ 
ВРЕМЯ РАЗВЕРТЫВАНИЯ
Среднее время, которое требуется для фиксации кода, чтобы он попал в производство
14.2 дня
20
15
10
5
Дни
33.6
23.9
19.8
19.8 20.0
16.1
12.0
14.8 13.1 15.2
5.0
Мар
Апр
Май
Jun Июль Август
Среднее время, необходимое для восстановления после сбоя в производстве
94
116
132
10
35
97
166
СРЕДНЕЕ ВРЕМЯ ВОССТАНОВЛЕНИЯ
203
382
249
123
149 мин
160
140
120
100
Протоколы
Мар
Апр
Май
Jun Июль Август
ЧАСТОТА ОТКАЗОВ
Средний процент развертываний, приводящих к сбоям в производстве
1.22%
4 %
2 1.9
0.2
0
1.7
0 0
4.0
2.4
1.4
0.4
0.5 1.1
Мар
Апр
Май
Jun Июль Август
Группы продуктов и платформ
ПРИЛОЖЕНИЕ 30.5
Показатели зрелости стручков. Речь идет о базовых практиках, которые определяют производительность и общую эффективность стручков. Для измерения зрелости стручков существуют различные инструменты опроса.
В идеале эти различные показатели автоматизируются в рабочем процессе стручка, но на это требуется некоторое время, и делать это имеет смысл только после достижения определенного масштаба (например, более 20 стручков).
Прогресс в управлении изменениями
Эти показатели измеряют прогресс в создании новых возможностей и здоровье самой трансформации. Мобилизуем ли мы подразделения в соответствии с планом? Вовлечены ли люди? Продвигаемся ли мы в создании благоприятных возможностей и талантов? По нашему опыту, совершенство - враг добра (и завершения) при построении измерений управления изменениями. Внедрите основные принципы и развивайте их дальше:
Мобилизация руководства. Проводите периодические опросы 200-300 руководителей высшего звена компании, чтобы понять, насколько важны цифровые технологии для их управленческой программы, каков их прогресс и как они оценивают собственную эффективность в руководстве изменениями. Дополните их интервью.
Прогресс в создании возможностей. Мы определили несколько основных показателей, которые вполне отражают прогресс, достигнутый в создании четырех возможностей доставки, рассмотренных в разделах со второго по пятый. Что касается талантов, добиваетесь ли вы прогресса в создании своей цифровой базы (т. е. наборе или повышении квалификации) и удерживаете ли вы своих лучших технологов? Что касается операционной модели, мобилизуете ли вы капсулы в запланированном темпе и насколько хороши владельцы продуктов в этих капсулах? Что касается технологий, сколько подразделений способны выпускать код в производство и каково время их цикла выпуска? А что касается данных, то сколько подсистем решений ограничены в данных и не могут продвигаться вперед, и сколько подсистем потребляют данные из каждого конкретного продукта данных?
Измерение зрелости стручков
стручок
лучшая/худшая капсула
Очень низкий (50% или менее)
Низкий (51-60%)
Средний (61-70%)
Высокий (71-80%)
Очень высокий (81%+)
Средства для масштабного развертывания agile
Средний балл
Диапазон
30% 40 50 60 70 80 90 100
СТРАТЕГИЯ
Общее видение
Динамическое распределение ресурсов Клиентоориентированность
73%
65%
62%
СТРУКТУРА
Структура отчетности Управление
Роли и обязанности
Размер и расположение рабочей силы
67%
67%
70%
75%
ЛЮДИ
Лидерство
Управление талантами Культура
Неформальные сети и коммуникация
76%
68%
80%
73%
ПРОЦЕСС
Механизмы связи
Командные процессы/методология доставки
Процессы планирования и принятия решений
Управление производительностью
78%
77%
71%
73%
ТЕХНОЛОГИИ
Поддержка
системы и инструменты
Конвейер доставки/ DevSecOps
Эволюция архитектуры
ИТ-инфраструктура и операции
80%
73%
70%
69%
ПРИЛОЖЕНИЕ 30.6
Вовлеченность сотрудников. Ежегодное исследование вовлеченности сотрудников - хорошая возможность оценить общее воодушевление, развитие навыков и личностный рост. Также может быть хорошей идеей сегментировать опрос для тех, на кого преобразования оказывают непосредственное влияние - например, для тех, кто работает над капсулами, или для пользователей, получающих выгоду от новых разрабатываемых решений.
Отслеживание с помощью процесса stage-gate
Надежные программы трансформации обеспечивают поэтапное внедрение решений. Мы пришли к выводу, что каждое выявленное решение полезно прогнать через процесс, состоящий из пяти этапов. Это те же пять ворот, которые наша фирма успешно использует в общих преобразованиях. Их описание приведено в Примере 30.7.
Врата L1 - L3 - это, по сути, врата инкубации решения, которые являются частью усилий по переосмыслению домена. По мере того как решение проходит формальные проверки, бизнес-обоснование и требования к поставке становятся более точными. Ворота L3 - это ворота "годен/не годен", которые ведут к полной мобилизации группы доставки.
Ворота L4 часто совпадают с поставкой MVP решения. L5 соответствует этапу внедрения и/или масштабирования, когда версия 1 (V1) принята клиентами/пользователями и достигнута значимая ценность. В ходе годового планирования (или планирования QBR) определяются специфические требования к V2, и начинается новый цикл. Решение продолжает развиваться, совершенствоваться и приносить все больше пользы. В какой-то момент решение может достичь зрелости. Тогда команда разработчиков сокращается, и остается только основная команда поддержки.
Не стоит недооценивать дисциплинированность этого процесса. По мере того как цифровая трансформация и трансформация с использованием ИИ охватывают все больше областей, этот процесс выстраивает последовательный язык и инвестиционную дисциплину, которыми можно управлять с помощью ежегодного планирования и/или QBR. По мере того как компании узнают, что работает (и что не работает), наращивают потенциал и находят новые источники ценности, они динамично обновляют свою цифровую дорожную карту, бизнес-кейсы и потребности в ресурсах.
Отслеживание трансформации через ворота стадии
Этап переосмысления домена
ИНКУБАЦИЯ РАСТВОРА
СПРИНТИНГ/ДОСТАВКА
Решение
Решение
Годовое планирование + процесс QBR
идеализированный
L0
квалифицированные Деловое предложение
идти/не идти MVP
V1 завершен
Решение
идея L1
L2 L3
L4 L5
Реализовать ценность
Валидация
Планирование
Разработка
Освоение и масштабирование
Ясность в определении бизнес-задачи, которую необходимо решить
От L0 до L1
Идеи решений появляются в рамках дорожной карты переосмысления домена
От L1 к L2
Построение дерева драйверов бизнес-ценностей
Стоимость решения с ключевыми допущениями для определения размера воздействия Предполагаемые сроки L3 и L4
Качественная оценка осуществимости (например, технологии, данные, управление изменениями) Завершена подготовка предположений об улучшении дерева ценности операционных КПЛ
Из L2 в L3
Выполнение технико-экономического обоснования и технических требований (технологический стек, данные, управление изменениями для обеспечения движения
внедрение и масштабирование)
Необходимый состав команды, включая последующие расходы
Бизнес-обоснование (уточнение финансовой стоимости и инвестиций; "фиксация" кривой OKR) Определение ключевых вех для обоснования ожиданий релиза (например, циклов спринтов, дат запуска MVP) Завершение разработки OKR для капсул и определение дорожной карты
Выполнение работ в рамках спринтерских циклов
От L3 до L4
Pod управляет выполнением в Jira, а руководитель домена/решения периодически (например, ежемесячно) делится изменениями KPls и KRs в Wave.
MVP-решение завершено Принятие заказчиком/пользователем доказано
QBR проводится по мере завершения кварталов Достижение отслеживаемых КПЭ/финансовых результатов
От L4 до L5
Масштабирование/развертывание: в масштабах всей организации
Дальнейшее развитие дорожной карты продукта и его масштабирование по мере необходимости
V1 завершен - начинается новый цикл для V2...
ПРИЛОЖЕНИЕ 30.7
Крупномасштабные цифровые преобразования мобилизуют сотни подразделений и предоставляют столько же цифровых решений. Хотя на первых порах отслеживание и отчетность можно вести в электронных таблицах и слайдах, это быстро становится неприемлемым.
В своей работе мы часто используем два программных пакета для отслеживания трансформаций и отчетности. Наш первый инструмент - это универсальный инструмент для отслеживания трансформации, который позволяет отслеживать этапы создания решений и основные сценарии использования, а также основные KPI. По сути, он отслеживает инвестиции и стоимость, созданную цифровыми решениями. Мы предпочитаем использовать WAVE2 , но на рынке доступны и другие инструменты. Наш второй инструмент (LINK) предназначен для отслеживания состояния капсул и поддержки agile-церемоний, включая управление зависимостями между командами.
Офис трансформации
Для управления всеми цифровыми инициативами на постоянной основе всегда необходим офис трансформации (TO). ТО - это головная команда, которая контролирует все элементы более широкой трансформации цифровых технологий и ИИ в масштабах всего бизнеса - от обеспечения качества дорожных карт домена до отчетности о результатах и здоровье трансформации.
В зависимости от масштаба преобразований в состав ТО часто входят специалисты по финансам, персоналу, коммуникациям, ИТ и профильные эксперты (например, юристы, закупщики). В его основные обязанности входит: запуск преобразований; поддержка разработки цифровой дорожной карты; отслеживание фактического получения целевой ценности; выявление ранних признаков потенциальной утечки ценности; устранение препятствий; пересмотр и обновление дорожной карты на основе достигнутого прогресса; обеспечение прогресса в создании возможностей; управление изменениями на протяжении всего процесса.
ТО наделен полномочиями принимать важные решения (например, утверждать этапы, распределять команды и бюджеты) и подталкивать организацию, задавая сложные вопросы и возлагая на людей ответственность.
ТО гораздо более перспективен, чем традиционный офис управления программами (PMO). Он предвидит узкие места и активно их устраняет. Его внимание сосредоточено на решении проблем, подотчетности и поддержании темпов.
На рисунке 30.8 показана классическая структура управления трансформацией, включающая в себя структуру ТО.
Обустройство офиса трансформации
Офис трансформации (TO)
Рабочие направления трансформации
Домен №1
Дополнительные домены
Спонсор домена
Стручки
Стручки
Генеральный директор/исполнительная команда
Спонсор домена
Разработка и обновление дорожной карты
Ведущие аналитики по стратегии
Управление производительностью
Финансовый директор
Финансовые аналитики
Управление изменениями Ведущий специалист по управлению изменениями Ведущий специалист по коммуникациям
Руководитель отдела кадров
Ведущий специалист по управлению рисками
Административная поддержка
Главный специалист по трансформации
ПРИЛОЖЕНИЕ 30.8
Ответственный за преобразования должен понимать бизнес, пользоваться уважением и быть готовым надавить на людей и "потратить" свой капитал отношений, чтобы стимулировать преобразования. По этой причине ТО часто является внутренним руководителем.
По мере того как цифровая трансформация и ИИ становятся обычным делом, необходимость в ТО будет уменьшаться, и в конечном итоге он будет расформирован. На этом этапе цифровые усилия интегрируются в новую операционную модель (см. раздел 3).
Примечания
Мэтт Фитцпатрик и Курт Стровинк, "Как измерить успех в цифровых технологиях? Пять показателей для руководителей компаний", McKinsey.com, 29 января 2021 г., https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ how-do-you-measure-success-in-digital-five-metrics-for-ceos.
Более подробную информацию о WAVE можно найти на сайте mckinsey.com/capabilities/ transformation/how-we-help-clients/wave/overview
Глава 31.
Управление рисками и создание цифрового доверия
Риски случаются. А цифровые преобразования и преобразования с использованием ИИ порождают совершенно новый и сложный набор взаимосвязанных рисков. Быстрые цифровые преобразования и внедрение ИИ происходят в условиях повышенного внимания со стороны регулирующих органов, когда потребители, регулирующие органы и руководители компаний все больше беспокоятся об уязвимостях в области кибербезопасности, конфиденциальности данных и систем ИИ.
От непреднамеренных результатов, таких как неявные предубеждения в алгоритмах ИИ, до трагических аварий с участием самоуправляемых автомобилей и утечек личной информации - ни один бизнес, отрасль или правительство не застрахованы от рисков, связанных с цифровыми технологиями и ИИ.
Именно поэтому потребители и регулирующие органы ожидают от компаний создания и применения эффективных практик цифрового доверия. Цифровое доверие означает уверенность в том, что организация защищает данные потребителей, обеспечивает эффективную кибербезопасность, предлагает надежные продукты и услуги на базе ИИ, а также обеспечивает прозрачность использования ИИ и данных.
Лидеры, установившие высокий уровень доверия к цифровым технологиям, реже сталкиваются с рисками, связанными с негативными данными и инцидентами, связанными с искусственным интеллектом, и, по статистике, чаще добиваются высоких результатов.1 Многие потребители, особенно те, кто разбирается в цифровых технологиях, считают надежность и защиту данных почти такими же важными, как цены и сроки доставки.
В рамках данной книги мы сосредоточимся на четырех возможностях цифрового доверия, которые наиболее непосредственно поддерживают цифровую трансформацию, о чем пойдет речь далее.
Учет рисков
Это похоже на классическую процедуру сортировки рисков, которую вы проводите в рамках корпоративного управления рисками, но на этот раз она сосредоточена на цифровых решениях, моделях и активах данных, которые входят в дорожную карту цифровой трансформации и ИИ. В процессе оценки этих рисков вы будете выявлять их, классифицировать в таксономии рисков и "оценивать" их в зависимости от того, какое воздействие они окажут в случае возникновения. Регулирующие органы уже требуют от организаций проводить оценки воздействия обработки данных (APIA) и, все чаще, оценки воздействия алгоритмов (AIA).
Результатом этой работы является простая для понимания тепловая карта рисков. Оценка вызывает дополнительные вопросы и сигнализирует о том, где больше всего нужны эксперты по рискам и праву. Это поможет вам определить приоритеты, в которых необходимо пересмотреть политику.
Пересмотр политики
Всеобъемлющие политики цифрового доверия касаются использования данных, ана-литики и технологий и служат "Северной звездой" для организации. Эти политики должны быть шире, чем традиционная политика конфиденциальности данных, и затрагивать такие темы, как использование и обработка персональных данных, ограждения для использования технологий, справедливость моделей, основанных на коде, а также протоколы, касающиеся программного обеспечения, систем IoT, облачных решений и прототипов дизайна.
Ожидайте пересмотра вашей политики в следующих областях:
Данные: Четкие, понятные политики сбора конфиденциальных данных, четко сформулированные политики хранения данных, тщательная проверка персонала и/или поставщиков третьих лиц и постоянные аудиты.
Технологии и облака: Стратегия приоритизации ИТ-рисков, непрерывное кибернетическое обучение всего персонала и программа реагирования на инциденты
ИИ/МЛ и аналитика: Четкие стандарты и пороговые значения для рисков ИИ, включая прозрачность и объяснимость, автоматизированные системы мониторинга моделей ИИ, а также проверки предвзятости и справедливости моделей ИИ
Например, если решение включает в себя возможность таргетирования различных демографических групп или использования различных цен, предприятию необходимо внедрить специальные протоколы, обязательные для всех сотрудников предприятия, для предотвращения предвзятости. Это должно быть указано в вашей политике в области ИИ.
Пересмотр всего набора политик с учетом новых рисков требует времени. Попросите команду по управлению рисками или юристов разработать структурированный подход, чтобы сделать это в течение 12-24 месяцев.
Оперативное внедрение политики рисков
Самая лучшая политика в мире не сработает, если у команд не будет возможности быстро и последовательно проверять и внедрять практики цифрового доверия. Просто существует слишком много источников данных, цифровых систем и систем искусственного интеллекта, которые необходимо проверить и подтвердить.
Компании должны сосредоточиться на создании трех операционных возможностей:
Встроенные функции управления. Мы знаем множество случаев, когда команды разработчиков тратили значительное время и деньги на создание и развертывание новых решений, но вынуждены были возвращаться к чертежной доске или, что еще хуже, откладывать свою работу на потом, когда сталкивались с проблемами риска (например, отсутствием согласия клиентов на использование их данных). Такие проблемы часто возникают из-за традиционных моделей работы, в которых специалисты по правовым вопросам, управлению, обеспечению качества и другим рискам работают изолированно, внося свой вклад только в определенные "ворота" процесса разработки, многие из которых наступают уже после завершения основной работы над решением.
Чтобы решить эту проблему, необходимо разработать контрольный список рисков, который под руководством профессионала по рискам будет использоваться для выявления рисков, требующих дополнительной экспертизы со стороны юристов, специалистов по кибербезопасности, защите данных, конфиденциальности, соблюдению нормативных требований или других контрольных служб, которые могут быть в компании. После того как оценка и меры по снижению рисков согласованы, группа включает их в план работы. Например, можно прийти к выводу, что перед построением ML-модели необходимо закрыть данные клиентов для определенных полей демографических данных.
Этот процесс сортировки рисков, экспертной оценки и принятия мер по снижению рисков обычно строится в виде цифрового рабочего процесса, который облегчает отслеживание и масштабирование (глава 14 предлагает более подробную информацию об этом).
Специализированные таланты. Это узкоспециализированная область на стыке регулирования, этики и технологий. Вам следует рассмотреть возможность назначения всеобъемлющего руководителя предприятия по вопросам цифрового доверия, который будет отвечать за создание и управление потенциалом цифрового доверия в компании. Некоторые компании даже назначают главного специалиста по доверию.
Как правило, требуется углубление экспертизы в области "privacy engi- neering" - людей, которые умеют управлять и поддерживать приложения для защиты данных, разрабатывать автоматизированные тесты на безопасность и соответствие требованиям, а также рефакторить приложения, чтобы привести их в соответствие с требованиями.
Автоматизация контроля рисков. Автоматизация доверия - это процесс превращения политики доверия в код ("политика как код"), такой как требования к соблюдению ("соответствие как код") и стандарты риска ("безопасность как код"). Эти автоматизированные средства контроля рисков активируются каждый раз, когда кто-либо представляет новый код. Такой подход радикально ускоряет разработку и развертывание и снижает риски. Для систем искусственного интеллекта это может включать инструменты MLOps, автоматизирующие соблюдение новых нормативных требований.
Повышение осведомленности и распознавание образов
Каждый сотрудник предприятия несет ответственность за цифровое доверие. В ведущих компаниях это уже стало предметом веры. Чтобы сформировать культуру ответственности, идея доверия должна исходить с самого верха. Руководители должны спонсировать, поощрять и демонстрировать практику цифрового доверия во всей организации. К таким практикам можно отнести реализацию программ обучения, ориентированных на цифровое доверие; публикацию основных ценностей, связанных с использованием данных, цифровых технологий и технологий искусственного интеллекта; включение показателей цифрового доверия в оценки эффективности работы.
Чтобы клиенты были уверены в том, что организация защищает их данные, они должны быть осведомлены об этих усилиях и политике. Иногда такие сообщения требуются регулирующими органами. Например, в штате Нью-Йорк есть положение, требующее от компаний публиковать на своем веб-сайте результаты аудита процесса подтверждения справедливости систем трудоустройства и найма, основанных на искусственном интеллекте, в том числе информацию о том, какие инструменты используют специалисты по анализу данных для выявления предвзятости в искусственном интеллекте. Лидеры в области цифровых технологий также будут регулярно и проактивно информировать рынок о своей работе, чтобы создать конкурентное преимущество и изменить ландшафт потребительских ожиданий.
Наконец, важно рассказать о мерах по управлению цифровыми рисками соответствующим регулирующим органам, чтобы помочь им понять новые методы работы и связанные с ними преимущества. Таким образом, компании могут заверить регулирующие органы в активных шагах, предпринимаемых для обеспечения соответствия требованиям, и собрать отзывы для принятия дальнейших мер.
По их словам: Баланс между ценностью для пользователя и цифровым доверием
ИИ сейчас есть практически во всем, и он делает много вещей, которые большинство из нас находят восхитительными. Например, мне нравится, когда YouTube или Spotify рекомендуют то, о чем я никогда бы не подумал, или когда мой телефон угадывает, что я хочу сделать, и выдает подсказку. Но, торопясь создать полезные для пользователей продукты и вывести их на рынок, некоторые компании не уделили должного внимания побочным эффектам, которые могут создать эти инструменты.
Это похоже на то, как автомобильная промышленность начинала задумываться о средствах безопасности для автомобилей. Тогда рассуждали так: "Ну, ремни безопасности работают в 20 % случаев. В конце концов, мы разберемся с этим". А реакция клиентов и других людей была такой: "Нет. Придумайте, как сделать так, чтобы ремни безопасности работали сейчас". То же самое происходит и с технологиями. Компании знают, как внедрять инновации, но они должны инвестировать в эти области и работать над этим усерднее.
-Марк Сурман, президент и исполнительный директор Mozilla
Фонд
Примечание
1. Джим Боэм, Лиз Греннан, Алекс Сингла и Кейт Смадже, "Почему цифровое доверие действительно имеет значение", McKinsey.com, 12 сентября 2022 года, https://www.
.mckinsey.com/capabilities/quantumblack/our-insights/why- digital-trust-truly-matters.
Глава 32. А как же культура?
Нам постоянно задают этот вопрос: А как же культура?
Руководители компаний признают важность культуры, но часто не понимают, что нужно для создания цифровой культуры - образа мышления и поведения, которые поддерживают и ускоряют переход к цифровым технологиям и ИИ. По нашему опыту, это часто происходит потому, что люди рассматривают культуру в расплывчатых терминах, как набор ментальных установок и моделей поведения, которые необходимо развивать, не имея четкого представления о том, как это делать или даже зачем.
На самом деле, культура - это результат совокупности действий, стимулов, новых навыков и лидерских качеств.
Вся книга сводится к действиям, необходимым для создания цифровой культуры: формирование у руководителей представления о возможностях цифровых технологий и искусственного интеллекта, найм новых технических специалистов, сближение ИТ с бизнесом, обучение новым методам работы, создание удобных для потребления технологий и данных для стимулирования инноваций в компании, развитие владельцев продуктов и т. д.
Хотя цифровая культура является результатом всех этих усилий, целенаправленное развитие цифровой культуры начинается с четкого определения лидерских качеств, которые вы ожидаете от своих руководителей, и отслеживания прогресса в их достижении (см. Рисунок 32.1).1
Атрибуты лидерства на цифровых предприятиях
Клиентоориентированность
Ставит клиента в центр всей своей деятельности, не жалея сил для обеспечения выдающихся впечатлений
Тестируйте, учитесь и развивайтесь
Способен идти на риск, чтобы проверить новые инновации, и рассматривает ошибки как источник знаний
Сотрудничество
Хорошо сотрудничает с различными функциями и бизнес-подразделениями в интересах клиентов и предприятия
Ориентированные на данные
Использование данных для принятия решений в режиме реального времени
Чувство срочности
Действует/реагирует быстро и чутко реагирует на потребности каждой ситуации
Расширение прав и возможностей
Предоставляет сотрудникам возможность принимать решения и создает для этого благоприятные условия
Внешняя ориентация
Постоянно учится у других компаний, партнеров и клиентов
Постоянная доставка ценностей
Приоритет отдается быстрой доставке ценностей клиенту и постоянному совершенствованию продуктов и решений
ПРИЛОЖЕНИЕ 32.1
В ходе цифровой трансформации и трансформации с использованием искусственного интеллекта компания уделяет пристальное внимание организационной культуре, которая требует изменений в мышлении и поведении, необходимых для успешного проведения трансформации в течение длительного времени. Установление базового уровня и периодическое измерение с помощью культурных опросов - это хороший способ понять, как продвигаются приоритетные культурные атрибуты.
Цифровая трансформация и трансформация с использованием искусственного интеллекта требуют больше навыков, чем любой другой вид трансформации. Это связано с тем, что масштабы и скорость изменений оказывают значительное давление на всю организацию. Без хорошо структурированных и устойчивых инвестиций в обучение и воспитание новых талантов гравитационное притяжение унаследованной организации может создать реальное сопротивление изменениям.
В конечном итоге успешные компании фокусируются на трех основных направлениях развития навыков: повышении квалификации руководителей, широких программах управления изменениями и интенсивной переподготовке сотрудников, занимающих ключевые роли.
Первоначально инвестируйте в команду лидеров
Цифровая компания работает по-другому, и от лидеров требуется другое руководство. Бизнес-лидеры цифровых предприятий - фанатики клиентов, они понимают цифровые технологии (по крайней мере, основы) и процесс разработки цифровых решений, они знакомы с agile и знают, как играть свои роли в agile-процессе, они воплощают лидерство в сотрудничестве и являются примером отношения "могу-делать".
По их словам: Оценка лидеров на предмет новых навыков
Недавно мы пересмотрели критерии оценки руководителей, добавив к ним ряд атрибутов. Раньше мы отбирали руководителей по трем характеристикам: умение мыслить, исполнять и руководить командой. Это, если хотите, жесткие навыки. В прошлом году мы добавили еще шесть атрибутов, которые относятся к более мягким навыкам. Это очень важно, особенно в такой агрессивной среде, как у Ping An.
Сейчас мы рассматриваем такие вещи, как коэффициент неблагополучия человека, его способность быть открытым и восприимчивым. Эту работу мы начали со 150 человек высшего руководства, и со временем она распространится на всю организацию. Это изменение, которое должно произойти, особенно потому, что многие технологические инновации носят междисциплинарный характер и требуют сотрудничества различных команд. Все больше и больше людей должны уметь работать с другими людьми.
Звучит очень просто, но это огромные изменения, потому что эти более мягкие факторы трудно измерить.
-Джессика Тан, исполнительный директор компании Ping An
Многие руководители крупных компаний не обладают этими качествами. Но лидеры могут развить их с помощью целенаправленной и дисциплинированной программы. По нашему опыту, наиболее полезными являются три конкретные практики:
Посетите и посмотрите. Одна из самых мощных инвестиций на раннем этапе - это двух- или трехдневный визит руководства (и даже совета директоров) в соответствующие компании. Типичный визит включает в себя посещение нескольких "цифровых аборигенов" Big Tech, нескольких традиционных компаний, которые далеко продвинулись в своем цифровом и искусственном интеллекте, и, возможно, нескольких стартапов в отрасли. Цель состоит в том, чтобы узнать, как работают компании, ориентированные на цифровые технологии.
Digital 101. Чтобы стать эффективными лидерами в цифровую эпоху, руководители должны понимать хотя бы основы цифровых технологий и новых методов работы. Большинству руководителей не хватает как минимум 10 часов обучения основам цифровых технологий, либо в классической "классной" модели, либо в формате самостоятельного онлайн-обучения, чтобы они могли адаптировать процесс обучения к своим потребностям. Содержание этой книги отражает то, что руководители должны знать. Со временем следует рассмотреть программу, направленную на дальнейшее развитие технических навыков руководства.
Лидерство в цифровую эпоху. После начала цифровой трансформации многие компании вкладывают средства в программу, в рамках которой их топ-менеджеры исследуют свой стиль руководства и то, как он должен измениться в условиях перестройки предприятия. Обычно акцент делается на внедрении культуры "учись всему" (а не "знай все"), культуры сотрудничества (а не "мои ресурсы и мой P&L") и настоящей культуры, ориентированной на клиента (а не на то, чтобы говорить, что вы ориентированы на клиента, но на деле этого не делать). Как правило, эти курсы проводятся в течение четырех-шести полудневных сессий, организованных для групп из 10-15 человек, с последующим индивидуальным коучингом.
Как правило, программа подготовки руководителей ориентирована на два-три верхних уровня в организации.
Пример из практики: Инвестиции в цифровых лидеров в компании Roche
Чтобы сформировать гибкую культуру в рамках программы цифровой трансформации, фармацевтическая компания Roche запустила интенсивный процесс изменений среди руководителей высшего звена. Более 1000 руководителей были приглашены для изучения нового, более гибкого подхода к руководству в рамках четырехдневной программы, которая ознакомила их с мышлением и возможностями, необходимыми для руководства гибкой организацией.
В течение шести месяцев после окончания программы для старших руководителей многие участники запустили эксперименты по внедрению agile в своих командах руководителей и организационных подразделениях, вовлекая тысячи людей в совместное создание инновационных способов внедрения agility в организации. По сравнению с первоначальными ожиданиями, когда 5-10 % участников проводили последующие сессии со своими командами, 95 % решили это сделать2.
Даже при всех этих инвестициях в повышение квалификации руководящего состава, суровая реальность такова, что многие руководители не готовы к этому путешествию. Например, если вспомнить зрелые цифровые преобразования в банковской сфере и розничной торговле, то, как правило, около 30 % из 300 ведущих компаний требуют смены руководства, отдавая предпочтение руководителям с более подходящим профилем лидера.
И наконец, если вы не внесете явные изменения в стимулы для руководства и критерии продвижения для этих 300 лучших руководителей, вы будете постоянно бороться с трудностями в рамках своих программ повышения квалификации. Мы видели, как компании продвигали только тех руководителей, которые продемонстрировали глубокое понимание потребностей и болевых точек клиентов, а также постоянное внимание к измерению и повышению удовлетворенности клиентов. Другие подчеркивают важность межфункционального сотрудничества, оцениваемого с помощью 360-градусной обратной связи с коллегами.
Создавайте широкие программы обучения, которые можно масштабировать
Чтобы вовлечь в этот процесс большую часть организации, многие организации разрабатывают специальные программы обучения, которые могут масштабироваться. Они часто вкладывают средства в создание корпоративной "академии", которая является движущей силой для разработки и реализации учебных программ и программ обучения, направленных на повышение уровня осведомленности, навыков и моделей поведения в организации.
Например, сингапурский многонациональный банк DBS поставил перед собой цель создать сильную культуру экспериментов и стать стартапом со штатом в 30 000 сотрудников. Он вложил значительные средства в развитие инфраструктуры обучения, чтобы сформировать в организации менталитет, ориентированный на данные, создав множество программ, таких как учебная программа, которая вооружает сотрудников навыками переводчика данных (человека из бизнеса, который знает достаточно о данных и аналитике, чтобы разрабатывать концепции и внедрять новые высокоэффективные цифровые решения); инновационный центр, организовавший 300 с лишним хакатонов и семинаров; программа "взломай и найми", в результате которой было нанято более 200 сотрудников; программа "назад в школу", способствующая развитию культуры взаимного обучения (подробнее об этом примере вы можете прочитать в главе 34).
Благодаря этим программам банку удалось обучить более 5 000 сотрудников различным цифровым и аналитическим возможностям. Из них 1 000+ сотрудников повысили квалификацию и перешли на более ключевые роли в цифровой трансформации. Вовлеченность сотрудников выросла на шесть процентных пунктов, а удержание персонала увеличилось на 40 %.
Пример из практики: Строительство "школы" для 40 000 сотрудников
Компания Majid al Futtaim (MAF), конгломерат недвижимости и розничной торговли, расположенный на Ближнем Востоке, разработала "школу" аналитики и технологий (SOAT), чтобы повысить потенциал 40 000 сотрудников для поддержки преобразования компании в области аналитики.3 MAF определила приоритетные цели обучения для пяти сегментов: высшего руководства, технических экспертов и бизнес-практиков, менеджеров среднего звена, рядовых сотрудников и практиков начального уровня. Затем для достижения этих целей были разработаны учебные программы и маршруты обучения (см. Рисунок 32.2).
Школа аналитики и технологий
Пример Majid al Futtaim
Введение в аналитику и Понимание и применение Сила технологийАналитические примеры использованияПонять, как технологии могутПонять важность Привести к более глубокому использованию улучшить то, как мы делаем вещи
аналитики и технологий аналитики и технологий и познакомиться с новейшими технологиями и преимуществами, которые они могут принести технологическиетенденции и угрозы
Школа" поощряет сотрудников...
Принять Требуйте ВызовыПоощряйте гибкость и новые методы работы с данными аналитики , когда речь идет о применении методов работы, поддерживающих подход и аналитику, и последние тенденции в аналитике
предположения анализы технология и технология
ПРИЛОЖЕНИЕ 32.2
MAF определила приоритеты для руководителей высшего звена, технологов и менеджеров среднего звена, которые работали над решениями в области аналитики и ИИ, чтобы учебные программы SOAT были направлены на удовлетворение наиболее важных потребностей бизнеса. Руководители SOAT были укомплектованы в межфункциональные группы для быстрого проектирования, создания, тестирования, развертывания и итерации учебных программ. Школа также привлекала технологов из организации, чтобы дополнить содержание соответствующим опытом. Программы включали в себя здоровое сочетание симуляций и игр, чтобы воплотить навыки в реальных сценариях и сделать контент доступным для всех.
Показатели продемонстрировали положительные результаты по нескольким векторам, включая опыт обучающихся, развитие индивидуальных знаний и их применение через месяц после завершения программы. Положительные изменения были также обнаружены в наблюдаемых и устойчивых изменениях навыков и поведения (на основе обратной связи 360 градусов) через шесть месяцев после завершения программы, а также в достижении бизнес-результатов (например, успешное выполнение сценариев использования).
Самый важный урок, который мы извлекли из широкомасштабных программ обучения, - сделать их актуальными и легко масштабируемыми. Мы слишком часто видим, как компании начинают с амбициозных планов, а затем отказываются от них из-за сложности реализации.
Перераспределите ключевые бизнес-роли
Сосредоточьте интенсивные программы переквалификации на ключевых бизнес-ролях, которые необходимо радикально изменить, чтобы получить отдачу от цифровой трансформации и ИИ. Программы переквалификации ролей требуют значительного времени - от трех до девяти месяцев - и, как правило, ориентированы на конкретную отрасль: продавцы в розничной торговле, андеррайтеры в страховании, продуктовые маркетологи в банковской сфере, агрономы в сельском хозяйстве, сетевые планировщики в транспорте и логистике и т. д. Эти роли претерпевают значительные изменения благодаря внедрению данных и использованию искусственного интеллекта.
Например, крупной американской продовольственной компании пришлось переквалифицировать 400 продавцов, имевших более чем 20-летний опыт работы в сфере мерчандайзинга, что позволило им распознавать номенальные модели для принятия решений по ассортименту, ценообразованию и продвижению. Но им требовались новые навыки, чтобы выполнять свою работу в условиях интенсивного использования данных и искусственного интеллекта. В течение шести месяцев компания обучала их использованию нового интегрированного рабочего процесса для планирования рекламы, привлечения поставщиков, финансирования поставщиков и проведения рекламных акций. Они также научились использовать новый механизм рекомендаций по продвижению для оптимизации рекламных мероприятий и доверять ему. Наконец, их научили планировать национальные категории с помощью портала поставщиков в режиме реального времени, который служит отправной точкой для планирования на местах, что позволяет максимально расширить сотрудничество между сетями.
Переход к повышению квалификации не обошелся без проблем. Не все продавцы смогли пройти этот путь повышения квалификации, что привело к 20-30 % текучести кадров в течение двух лет. При этом компания также обнаружила, что с новыми инструментами и обучением стало легче вводить в эксплуатацию новых продавцов. Более того, автоматизация, новые инструменты и переработка процессов (включая новые данные) подняли продавцов с низкими показателями в верхний квартиль по производительности. Другими словами, новая технология позволила поднять производительность любого продавца до уровня лучших продавцов с 20+-летним опытом работы.
Примечания
Джордж Вестерман, Дебора Л. Соул и Ананд Эсваран, "Создание культуры, готовой к цифровым технологиям, в традиционных организациях", MIT Sloan Management Review, 21 мая 2019 г., https://sloanreview.mit.edu/ article/building-digital-ready-culture-in-traditional-organizations/; Роуз Холлистер, Кэтрин Текоски, Майкл Уоткинс и Синди Вольперт, "Почему каждый руководитель должен сосредоточиться на изменении культуры сейчас", MIT Sloan Management Review, 10 августа 2021 г., https://sloanreview. mit.edu/article/why-every-executive-should-be-focusing-on-culture- change-now/; Julie Goran, Laura LaBerge, and Ramesh Srinivasan, "Culture for a digital age," McKinsey Quarterly, July 20, 2017, https:// www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ culture-for-a-digital-age.
Ларри Эмонд, "Как "Рош" помогает руководителям достичь силы гибкого мышления", Gallup, 29 апреля 2019 г., https://www.gallup.com/workplace.
/248714/roche-helps-leaders-achieve-power-agile-mindset.aspx.
Джемма Д'Аурия, Наташа Валия, Хамза Хан, "Новая формула роста Majid Al Futtaim: Инновации быстро, опережение, работа с экосистемой", McKinsey.com, 20 апреля 2021 г. https://www.mckinsey.com/capabilities/ growth-marketing-and-sales/our-insights/majid-al-futtaims-new-growth-formula-innovate-fast-stay-ahead-work-the-ecosystem.
Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:
Создает ли ваша цифровая трансформация и трансформация с использованием искусственного интеллекта ту ценность, на которую вы рассчитывали, и если нет, то знаете ли вы, где кроются проблемы?
Тратите ли вы (по крайней мере) столько же времени/ресурсов/инвестиций на внедрение и масштабирование, сколько на разработку решения?
Кто отвечает за внедрение? Подотчетны ли бизнес-лидеры?
Какая доля разработанных цифровых решений постоянно используется на предприятии? Какую часть из них не удалось масштабировать?
Есть ли у вас набор показателей и целей для цифровой трансформации, которые были бы столь же четкими, как и для традиционной трансформации затрат или продаж?
Отражают ли ваши презентации для инвесторов или советов директоров достаточно глубокое понимание того, как цифровые технологии и искусственный интеллект влияют на клиентов и операции?
Может ли ваш топ-коллектив четко сформулировать прогресс, достигнутый с помощью 10 лучших цифровых решений, и сколько пользы было создано?
Каковы новые риски и проблемы доверия к цифровым технологиям и искусственному интеллекту, и справляетесь ли вы с ними, чтобы повысить доверие клиентов?
Какую "цифровую" культуру вы хотели бы иметь через три года? Как вы узнаете, когда достигнете этого?
В этой книге предпринята попытка проникнуть глубоко под поверхность, чтобы раскрыть и собрать самые важные детали того, что требуется для планирования и осуществления успешной цифровой трансформации и трансформации с использованием ИИ. Подробно описывая, что требуется для развития соответствующих шести основных возможностей - разработка дорожной карты, таланты, операционная модель, технологии, данные, внедрение и масштабирование, - читатель, однако, рискует упустить более широкую картину того, как каждый из этих аспектов должен работать в целом.
Рассматривая общую картину, важно сосредоточиться на двух ключевых аспектах. Во-первых, это необходимая интеграция между элементами трансформации - нельзя ожидать, что лучшие цифровые таланты будут работать, если они не смогут эффективно работать в рамках операционной модели, обеспечивающей им достаточную автономию и гибкость, то и вы не сможете рассчитывать на то, что отличное цифровое решение принесет пользу, если бизнес не примет и не масштабирует его. И, во-вторых, есть элемент базовых возможностей, которые вам необходимо достичь. Например, если вы сильны в нескольких из них, но слабы в остальных, это приведет к гибели бизнеса в области цифровых технологий.
Эту историю интеграции и совершенствования возможностей лучше всего рассказать, показав, как это сделали компании. Итак, в этом заключительном разделе мы расскажем о том, как три разные организации провели свои собственные цифровые преобразования и преобразования в области ИИ. Это ведущие компании в соответствующих отраслях, и они также являются лидерами в области цифровых технологий. Каждая из них находится на пути цифровых преобразований уже несколько лет, а некоторые даже десятилетие, и ни одна из них не скажет, что они уже на этом пути. Напротив, чем больше они продвигаются вперед, тем больше возможностей открывают для себя.
Глава 33: Freeport-McMoRan превращает данные в ценность
Глава 34: DBS - транснациональный банк становится цифровым банком Глава 35: Будущее игры обретает форму в LEGO Group
Путь компании по добыче меди к трансформации ИИ
Компания Freeport-McMoRan имеет репутацию опытного оператора в горнодобывающей промышленности. Компания управляет парком относительно зрелых, крупномасштабных медных рудников в Северной и Южной Америке, что означает высокую зависимость показателей компании от мировых цен на медь: в условиях высоких цен они генерируют значительные денежные средства, но в нижней части ценового цикла некоторые рудники с трудом выходят на безубыточность.
Ожидаемый рост компании требовал значительного капитала и длительных разрешительных и строительных работ. В поисках другого пути Freeport обратилась к искусственному интеллекту (ИИ), чтобы узнать, можно ли получить больше от уже имеющихся активов.
В течение пяти лет компания успешно разработала и реализовала программу "Американская обогатительная фабрика", которая позволила увеличить годовое производство меди за счет использования больших данных, искусственного интеллекта и гибкого подхода. Никаких новых капиталовложений не потребовалось.
О компании Freeport-McMoRan
• Описание компании: Freeport-McMoRan Inc. (FCX) - металлургическая и горнодобывающая компания, осуществляющая производство меди, золота и молибдена. Она была зарегистрирована в 1987 году.
• Количество сотрудников и подрядчиков: Более 60 000
• Рыночная стоимость: 60 миллиардов долларов
• Доходы: 22 миллиарда долларов в 2022 году
• Географическое распределение: В портфель активов компании входят минеральный район Грасберг в Индонезии и горнодобывающие предприятия в Северной и Южной Америке, включая крупномасштабный минеральный район Моренси в Аризоне и предприятие Серро-Верде в Перу.
Руководители Freeport обеспечили успех программы искусственного интеллекта. Ключевыми в этом путешествии были:
Дальновидный руководитель североамериканских операций, который был уверен, что Freeport необходимо развиваться, чтобы выжить и процветать, и хотел перенять передовой опыт, используемый в других отраслях.
Смелый лидер в области непрерывного совершенствования, чье любопытство, стремление и глубокие знания в предметной области заставляли объединенную команду постоянно задавать вопрос "Что возможно?", а затем стремительно двигаться к цели.
Умный сотрудник по вопросам информации и инноваций, который предусмотрительно создал общую инфраструктуру и архитектуру данных для поддержки всех операций по обработке данных и для быстрого развертывания инструментов ИИ на всех объектах с незначительной адаптацией. Это позволило сконцентрировать внимание на уровне объектов на методах гибкого управления, обучении, наращивании потенциала и управлении изменениями.
Открытый генеральный менеджер в пилотной трансформационной площадке, который обладал творческим подходом и уверенностью в себе, чтобы пробовать новое и учиться на том, что получилось.
Главный исполнительный директор и финансовый директор, которые представляли программу внешним аудиториям, что заряжало энергией и поддерживало многопрофильную команду.
В качестве первоначального тестового примера Freeport выбрала зрелую шахту с энтузиастом-руководителем, желающим опробовать программу трансформации ИИ. Демонстрируя ценность ИИ в Багдаде, штат Аризона, компания стремилась узнать, как машинное обучение (ML)/ИИ может улучшить существующие уже развернутые системы алгоритмической аналитики и усовершенствованного управления технологическими процессами (APC). Полученные в результате улучшения заставили руководство Freeport задуматься о капитальных затратах, необходимых для запланированной серии усовершенствований, и привели к сокращению более половины запланированных капитальных затрат.
В течение шести месяцев небольшая команда металлургов, операторов и инженеров работала над созданием и обучением модели искусственного интеллекта, чтобы рекомендовать изменения в настройках для безопасного увеличения скорости переработки на мельнице. В течение следующих нескольких месяцев производство меди увеличилось на 5 %. В течение одного квартала производительность предприятия в Багдаде превысила 85 000 тонн руды в день - на 10 % больше, чем в предыдущем квартале, - при этом коэффициент извлечения меди вырос на один процентный пункт, а работа предприятия стала более стабильной. Повышение производительности и извлечения меди - труднодостижимая цель в металлургическом производстве, и компания Freeport добилась этого на предприятии, которое эксплуатируется уже более 50 лет.
Руководство компании осознало, что масштабирование потенциала ML/AI на рудниках в Северной и Южной Америке позволит увеличить производительность всей системы на 125 000 тонн в день, что даст 200 миллионов фунтов меди в год и составит 350-500 миллионов долларов EBIDTA.1 Это было бы сопоставимо с вводом в эксплуатацию новой обогатительной фабрики, но без затрат в 2 миллиарда долларов и ожидания в течение 8-10 лет, которые обычно требуют такие крупные капитальные проекты.
Приняв решение о создании новых возможностей, руководство Freeport запустило программу "Американская обогатительная фабрика", чтобы внедрить эти возможности искусственного интеллекта на своих шахтах. Ключевой задачей в этой работе было промышленное внедрение возможностей, разработанных на предприятии в Багдаде, с тем чтобы их можно было масштабировать.
У Freeport был прочный фундамент знаний о том, на чем следует сосредоточиться, на основе недавно завершенного контрольного показателя эффективности работы. Компания также имела преимущество в работе с данными, поскольку предварительно стандартизировала данные по измерению и отчетности о производительности рудника и обогатила их, установив дополнительное сетевое оборудование и датчики производительности на грузовиках, лопатах и стационарных машинах компании. Кроме того, для хранения этих данных было создано центральное хранилище данных, что позволило компании получать и коррелировать посекундные показания производительности в режиме реального времени.
Установив контрольные показатели операционной деятельности и создав прочный фундамент данных, компания обратила внимание на развитие аналитических и инженерных навыков. Они добились значительного прогресса, сформировав первый класс из 16 специалистов по анализу данных, которые пришли в компанию из инженерных или металлургических специальностей, и дополнив их внешними экспертами по анализу данных из партнерской компании. Привлечение лучших тренеров по agile, владельцев продуктов и инженеров по данным и аналитике было непростой задачей, поэтому они обратились к стратегии привлечения талантов "купить (нанять), построить (повысить квалификацию), одолжить (заключить контракт)". Такой подход позволил им сформировать кадровый резерв, который помог бы им быстро продвигаться вперед, и одновременно развивать основные навыки внутри компании, что обеспечило бы им долгосрочное конкурентное преимущество.
Один из подходов к привлечению и удержанию талантов, который применила компания Freeport, заключался в том, чтобы ученые и инженеры, занимающиеся изучением данных, работали над главными приоритетами управления, чего часто не могут сделать лучшие специалисты в компаниях Больших Технологий. Например, одна из стажеров, занимающаяся изучением данных, пришла в Freeport всего за год до этого в качестве младшего металлурга, работавшего на руднике в Аризоне. В колледже она уже имела некоторый опыт программирования на компьютере и была рада возможности приобрести новые навыки. Менее чем через три месяца она представляла свою работу по моделированию и оптимизации обогатительных фабрик президенту компании.
Новый подход к талантам распространился и на операционную модель. Для ускоренной разработки моделей ИИ требовалось изменить методы работы компании. Культура планирования и развития, построенная на комплексе мер предосторожности, хорошо служила компании, но у нее были свои недостатки, прежде всего в плане темпов. Для экспериментального внедрения ИИ в Багдаде шахта перешла на операционную модель, в которой особое внимание уделялось оперативности, постоянному совершенствованию и быстрым испытаниям с низким уровнем риска без ущерба для безопасности. Ключевым элементом успеха этого изменения стало создание межфункциональной группы экспертов с рудника и центральной группы по изучению данных, которая могла бы оценивать и реализовывать инициативы по изменению.
Для быстрого наращивания команд и развития навыков Freeport привлекла тренеров, которые обучили людей методам гибкой работы, начиная с основ формирования бэклога и заканчивая созданием "минимально жизнеспособных продуктов", которые были бы достаточно хороши для начала, а не для доведения продуктов до совершенства перед их запуском. Команды быстро научились работать в двухнедельных спринтах, разрабатывая функции моделирования данных или операционные изменения, тестируя их, обучаясь и добавляя обновления в бэклог.
Руководители компании приняли принципиальное решение включить металлургов и операторов заводов в состав команды разработчиков на каждом участке. Когда на этапе тестирования появлялся каждый новый набор рекомендаций, разработчики ИИ, операторы и металлурги в составе команды оценивали эти рекомендации: Почему они были сделаны? Имеют ли они смысл? Будут ли они работать? Таким образом, команды выявляли недостатки, которые разработчики ИИ быстро устраняли, что, в свою очередь, помогало команде agile быстрее обучаться. В ходе этого процесса команда обучала инструмент ИИ, а доверие металлургов и операторов к нему росло, поэтому они с большей готовностью приняли его, когда инструмент был готов.
Новая модель искусственного интеллекта и взаимодействие способствовали диалогу и более глубокому пониманию процесса между операторами и металлургами. Модель искусственного интеллекта стала барометром того, что возможно при трехчасовом увеличении, в отличие от работы установки на одном режиме в течение дня для среднего количества получаемого материала.
Первоначально команда разработала модель ML, которую они назвали TROI, то есть Throughput-Recovery-Optimization-Intelligence. Этот продукт помогал предсказать, как поведет себя обогатительная фабрика и сколько меди можно извлечь при любом наборе условий. Алгоритм оптимизации, известный как генетический алгоритм, использовал принципы естественного отбора для разработки параметров, которые позволят получить наибольшее количество меди при определенном типе руды, и выдавал рекомендации каждые один-три часа в зависимости от условий работы.
Однако, чтобы заставить TROI работать на других предприятиях, Freeport должен был "активизировать" модели. По сути, это означало рефакторинг и переупаковку моделей, чтобы их можно было легче адаптировать для других предприятий. Модульный принцип построения инструмента позволил легко использовать 60 % основного кода, а оставшиеся 40 % пришлось бы адаптировать под новый объект, например, обучить модели на основе данных конкретного объекта. Чтобы еще больше упростить работу по локализации, компания вложила средства в разработку централизованной базы кода, к которой могли бы обращаться модули для конкретного объекта, вместо того чтобы заново создавать необходимый код для каждого конкретного модуля.
Эффективный запуск и масштабирование этих моделей стали возможны благодаря тому, что Freeport перенесла свою архитектуру данных в облако. Они использовали инструменты и практики DevOps, MLOps и CI/CD, основанные на четких стандартах, для быстрой разработки и контролируемого развертывания. Freeport смогла воспользоваться преимуществами облака, автоматизировав многие процессы, например разработку конвейера данных, который представлял собой трудоемкий процесс извлечения данных из десятков вручную обновляемых электронных таблиц.
По мере роста числа agile-команд компании необходимо было совершенствовать управление общим процессом. Например, при параллельной работе нескольких agile-команд было сложно получить ресурсы. Freeport решила эту проблему, назначив старшего владельца продукта, который помогал координировать работу команд и улучшать распределение ресурсов. Финансовому директору было поручено управлять отслеживанием воздействия и отчетностью по всему процессу.
В рамках программы "Устойчивое развитие", а также помогая сайтам управлять запросами на финансирование и оценивать прогресс. И наконец, они внедрили систему ежеквартального генерального планирования (подобную ежеквартальным обзорам бизнеса), в рамках которой высшие руководители компании собираются вместе, чтобы определить цели и ключевые результаты и сосредоточить ресурсы на наиболее приоритетных направлениях.
Имея на руках проверенный рецепт трансформации и достигнув большей части цели программы "Американская обогатительная фабрика", компания Freeport обратилась к другим областям своей деятельности, где можно применить возможности искусственного интеллекта. Они определили несколько перспективных областей, включая реализацию капитальных проектов, техническое обслуживание и операции по выщелачиванию, где они применяют эволюцию игрового сценария, обеспечившего успех программы "Американская обогатительная фабрика".
Примечание
1. Исходя из цены меди $4/фунт и себестоимости единицы продукции ниже $2/фунт.
Глава 34.
DBS
- транснациональный банк становится цифровым банком
Путь трансформирования цифровых технологий и искусственного интеллекта в транснациональном банке
В быстро развивающемся цифровом мире руководство DBS осознало, что для удовлетворения потребностей нового поколения клиентов, подкованных в технологиях, необходимо стать по-настоящему цифровым банком. Генеральный директор DBS сформулировал задачу банка на удивление просто: Думайте как стартап, а не как банк.
Чтобы начать мыслить как стартап, руководство DBS обратилось за вдохновением не к другим банкам или финансовым учреждениям, а к технологическим гигантам. Генеральный директор и его руководители посетили и изучили лучшие технологические компании по всему миру и привнесли то, что мы получили новые знания, чтобы сформировать "будущее DBS". Эти знания выкристаллизовались в четкое видение "Сделать банковское дело радостным". Это видение отражало цель сделать клиентов счастливыми, сделав банковское обслуживание легким и сделав DBS "невидимым". DBS четко определила, что больше не будет сравнивать себя с другими банками, а скорее с ведущими мировыми технологическими компаниями.
О компании DBS
• Описание компании: DBS Group Holdings Ltd - крупнейшая по размеру активов банковская группа в Юго-Восточной Азии. Она предоставляет услуги розничного, малого и среднего бизнеса, корпоративного и инвестиционного банкинга, в основном в Азии. Компания была основана в 1968 году, ее штаб-квартира находится в Сингапуре.
• Количество сотрудников: 36,000
• Рыночная стоимость: 91 миллиард SGD (69 миллиардов долларов США)
• Доходы: SGD16,5 миллиардов (12,5 миллиардов долларов США) в 2022 году
• Географическое распространение: Работает на 19 рынках, включая Сингапур, Китай, Гонконг, Индию, Индонезию, Малайзию, Тайвань, ОАЭ и Японию.
Команда приняла эти знания близко к сердцу, взяв на себя обязательство применить уроки, полученные в лучших мировых технологических компаниях, и сделать DBS лидером в области технологий. Это стремление было отражено в мнемонике GANDALF, которая расшифровывалась как: G - Google; A - Amazon; N - Netflix; A - Apple; L - LinkedIn; F - Facebook. D в середине означало DBS с дерзким стремлением войти в лигу культовых технологических компаний. Заимствованное из фильма "Властелин колец" слово GANDALF стало кличем для амбициозной цифровой трансформации DBS.
Разрабатывая дорожную карту цифровой трансформации для выполнения этого обязательства, руководство DBS изначально сосредоточилось на наиболее важных клиентских процессах, которые, как показал глубокий анализ, окажут наибольшее влияние или устранят самые сильные болевые точки. Например, одной из них было открытие текущих счетов, а время ожидания у банкоматов. Эти "иконические путешествия", как их называли, заложили основу для обучения и развития возможностей, что позволило быстро перейти ко второму этапу, на котором DBS запустил 100 путешествий в различных сферах бизнеса, включая финансы, опыт сотрудников и дополнительные путешествия по клиентам. Каждое из них возглавлял один из самых высокопоставленных руководителей организации.
Чтобы не отвлекаться на клиента, DBS создала руководящий комитет под названием Customer Experience Council (в него вошли генеральный директор и ключевые руководители, такие как главы бизнес-подразделений и руководители служб) для отслеживания прогресса и управления эффективностью. Группа собиралась раз в квартал, чтобы проанализировать ход реализации всех маршрутов, уделяя особое внимание показателям клиентского опыта и показателям EATE (раннее вовлечение, приобретение, заключение сделок и углубление вовлечения).
Стремясь расширить свои возможности, компания DBS обратилась к операционной модели, построенной на платформах - разновидности операционной модели "продукты и платформы", которую DBS адаптировала к своим условиям. DBS создала 33 платформы, соответствующие бизнес-сегментам и продуктам, где "размещались" все 100 клиентских или пользовательских маршрутов. Каждая платформа имела модель руководства "2 в одном", что означало, что каждая из них совместно возглавлялась руководителем от бизнеса и руководителем от ИТ. Такой платформенный подход позволил DBS более эффективно масштабировать компанию, поскольку устранил исторически сложившуюся изоляцию между бизнесом и технологическими функциями, которая не позволяла поддерживать по-настоящему кросс-функциональные agile-команды.
Многие руководители платформ были внутренними сотрудниками, обладающими опытом в соответствующей области. Вместе руководитель платформы и технический руководитель отвечали за достижение целей данной платформы в плане роста, доходов или клиентского опыта. У каждой команды путешествий был менеджер путешествий (как владелец продукта), который управлял agile-командой, состоящей обычно из 8-10 человек. Они создавали формулировку путешествия, включающую цель, ценность, на которую они ориентировались, и сроки достижения цели. Основой работы команд был фокус на проектировании клиентского опыта. Руководство, например, настаивало на совершенствовании процессов, которые приносили пользу клиенту.
В результате процесс оформления кредитной карты, занимавший 21 день, сократился всего до четырех дней.
Чтобы обеспечить эффективное функционирование этих команд в долгосрочной перспективе, руководство компании осознало, что им необходимо сформировать более глубокий кадровый резерв. В DBS было принято важное стратегическое решение привлечь 70 % технических специалистов к работе внутри компании (по сравнению с 20 % в прошлом). Они обратились к нетрадиционным способам поиска необходимых им талантов, включая хакатоны, которые были неотъемлемой частью первых лет трансформации DBS. DBS также использовала эти хакатоны как возможность для обучения старших руководителей DBS, чтобы они познакомились с передовыми технологиями и методологиями, такими как дизайн, ориентированный на человека. Чтобы привлечь талантливых специалистов в другие регионы, DBS также создал три технологических хаба. Благодаря этим и другим усилиям DBS может похвастаться наличием более 10 000 технологов, что составляет около трети ее персонала и вдвое превышает число банковских работников.
Набирая штат технических специалистов и внедряя платформенную операционную модель, компания DBS решила создать инженерную культуру, состоящую из исполнителей, которые могли бы свободно заниматься своим ремеслом на передовых технологиях. Ключевым компонентом достижения этой цели стал переход в облако, инвестиции в автоматизацию и разработка микросервисов для поддержки платформ. К 2021 году 90 % технологических услуг компании были переданы на аутсорсинг (по сравнению с 15 % в 2015 году). Около 99 % приложений теперь работают в облаке, а агрессивная автоматизация позволила значительно оптимизировать операции: один системный администратор может управлять 1 200 виртуальными машинами.
На основе этой технологической базы было принято обязательство стать организацией, управляемой данными. Поэтому DBS запустила комплекс инициатив по работе с данными, включая модернизацию управления данными, внедрение новой платформы данных (SWLWTE) и изменение культуры в организации. DBS отказалась от слайд-досок и стала использовать информационные панели для принятия решений на основе данных, отслеживания эффективности и оценки воздействия. Глубокие изменения в управлении данными позволили DBS радикально изменить подход к обслуживанию клиентов. Например, потребительский банк внедрил искусственный интеллект для обеспечения "интеллектуального банкинга", который ежедневно предоставляет потребителям более 50 000 персонализированных подсказок. В области управления персоналом, решения AI/ML помогли лучше предсказать, когда сотрудник может задуматься об уходе, чтобы HR мог вмешаться (в результате DBS имеет самый низкий показатель текучести кадров в отрасли в Сингапуре - 10 % по сравнению со средним показателем по отрасли в 15-20 %).1
Переход на облачные технологии обеспечил DBS масштаб и скорость использования ИИ и ОД со своими данными в различных областях, например: в маркетинге - для предоставления персонализированных решений в контексте; в отделе кадров - для более точного прогнозирования того, когда сотрудник может задуматься об уходе. Например, команда DBS, отвечающая за соблюдение нормативных требований и борьбу с мошенничеством, использовала ИИ и аналитику для разработки комплексного сквозного процесса наблюдения для борьбы с отмыванием денег и финансированием терроризма. Эта инициатива объединила несколько моделей, использующих правила, анализ сетевых связей и машинное обучение, с рядом внутренних и внешних источников данных, чтобы быстрее и лучше понять угрозы отмывания денег.
По оценкам, только за последний год благодаря инициативам в области искусственного интеллекта DBS получил 150 млн сингапурских долларов дополнительного дохода и еще 25 млн сингапурских долларов за счет предотвращения убытков и повышения производительности труда. В DBS работает более 1000 экспертов по данным, которые продолжают внедрять инновации.
Компания DBS смогла увеличить стоимость своих цифровых решений и решений на основе искусственного интеллекта, инвестировав в программу институционального обучения для формирования целого ряда необходимых навыков. Команда трансформации из 60-70 человек разработала, среди прочего, "DigiFy" - модульную программу обучения, которая позволила сотрудникам понять и применить такие концепции, как гибкие методы работы, большие данные, путешествие, а также цифровые технологии. Будучи "живым" учебным планом, который постоянно обновляется, "DigiFy" обеспечил всю организацию базовыми цифровыми навыками и позволил им быть в курсе быстро меняющегося цифрового ландшафта.
Команда трансформации управляла вспомогательными инструментами, чтобы отдельные сотрудники и команды могли выполнять работу в стиле agile. Чтобы удовлетворить потребности в техническом обучении более чем 10 000 технологов банка, DBS создал Академию DBS Tech Academy. В ней технологам предлагалась разработанная собственными силами учебная программа по таким направлениям, как проектирование надежности объектов, кибербезопасность и машинное обучение. В то время как DigiFy обеспечила базовые знания в области цифровых технологий для всех сотрудников DBS, Технологическая академия DBS создала глубокие инженерные знания, что позволило банку широко и глубоко развивать свои цифровые возможности.
Стремление к масштабированию заставило DBS взять на себя обязательство стандартизировать и упаковать как можно больше активов - от учебного модуля, программы обучения, методологии составления маршрута до продукта ана-литики. Этот фокус был центральным для способности "индустриализировать ИИ", например, путем оцифровки рабочих процессов (включая сквозное управление проектами ИИ с помощью стандартных шаблонов и руководств по лучшей практике), разработки набора лучших практик для руководства аналитикой, создания репозитория аналитики, где команды могли бы легко получить доступ к многократно используемому коду, и разработки мата данных/функций, который хранит общие функции, которые могут быть использованы для других аналитических разработок. DBS дополнила эти формальные инициативы по обучению и масштабированию более неформальными усилиями по формированию цифровой культуры, такими как редизайн рабочих мест для поощрения сотрудничества и инноваций, частые экспертные оценки и рассказ об успехах и неудачах (т. е. об извлеченных уроках).
На сегодняшний день результаты впечатляют. Около 65 % клиентов DBS пользуются цифровыми инструментами и услугами. Для потребительского и малого и среднего бизнеса банка в Сингапуре и Гонконге доля цифровых клиентов выросла на 27 процентных пунктов за последние семь лет и составит 60 % в 2022 году. Благодаря более разнообразным продуктам и большему количеству операций цифровые клиенты постоянно приносят в среднем более чем в два раза больший доход, чем традиционные. В результате соотношение расходов и доходов цифровых клиентов вдвое ниже, чем у традиционных. Рентабельность капитала цифровых клиентов составляет 39 %, что на 15 процентных пунктов выше, чем у традиционных клиентов. Кроме того, в течение пяти лет подряд (2018-2022 гг.) DBS удостаивался нескольких высших мировых наград2.
Путешествие не закончено. DBS продолжает искать новые возможности для бизнеса, развивая свои технологические возможности, в том числе участвуя в трансграничных финансовых перемещениях, а также создавая ряд предприятий с поддержкой блокчейна. Все эти инициативы для раскрытия новых источников стоимости и выполнения своих обещаний сделать банковское обслуживание радостным для клиентов.
Примечания
"DBS: трансформация, движимая целью", Гарвардская школа бизнеса, 29 июля 2022 года, https://www.hbs.edu/faculty/Pages/item.aspx?num=62948.
"DBS назван лучшим банком мира пятый год подряд", DBS.com, 25 августа 2022 г., https://www.dbs.com/newsroom/DBS_named_Worlds_ Best_Bank_for_fifth_year_running#:~:text=Piyush%20Gupta%2C%20 DBS%20CEO%2C%20said, customers%2C%20employees%20and%20 the%20community.
Глава 35. Будущее игр
формируется в
LEGO
Group
Цифровая трансформация глобального бренда игрушек
Путь LEGO Group к цифровой трансформации начался с фундаментального вопроса: Как мы можем сохранить наследие одного из самых любимых брендов в мире в эпоху цифровых технологий?
В условиях, когда дети все чаще обращаются к экранам, поведение покупателей становится цифровым, а логистика зависит от технологий, компания LEGO Group разработала концепцию, согласно которой будущее игр должно принадлежать ей. Для этого нужно было стать цифровым до мозга костей и технологическим лидером.
Первый этап пути был сосредоточен на технологиях. ИТ-служба модернизировала свои системы, чтобы технологии лучше работали вместе, внедрила agile-программы для своих технических команд и начала перенос рабочих нагрузок в облако. Но генеральный директор и топ-команда понимали, что им нужны более радикальные и фундаментальные изменения - технологии были крайне важны, но сами по себе они не могли реализовать их видение. Они должны были использовать технологии для изменения всего - от обслуживания клиентов до управления глобальной цепочкой поставок. Эта более масштабная цель потребовала от LEGO Group изменения архитектуры, операционной модели, кадрового состава, а также компетенций в области технологий и аналитики, чтобы стать технологическим лидером.
О группе компаний LEGO
• Описание компании: LEGO Group - датская компания по производству игрушек, расположенная в Биллунде, Дания. Она производит игрушки под брендом LEGO, состоящие в основном из взаимосвязанных пластиковых кирпичиков. LEGO Group также построила несколько парков развлечений по всему миру, каждый из которых известен как LEGOLAND, и управляет многочисленными розничными магазинами.
• Количество сотрудников: 25,000+
• Рыночная стоимость: N/A (частная компания)
• Доходы: 64,6 миллиарда датских крон (9,3 миллиарда долларов США) в 2022 году
• Географическое распространение: Европа, Северная Америка, Южная Америка, Азиатско-Тихоокеанский регион, Ближний Восток и Африка
Уже на ранних этапах было важно осознать, что столь фундаментальное видение нельзя передать на аутсорсинг или передать руководителю в качестве проекта. Руководство LEGO Group решило, что им необходимо с самого начала коллективно возглавить процесс цифровой трансформации. В напряженный период почти 100 бизнес-лидеров и вся группа руководителей сформулировали пятилетнее стремление стать компанией, производящей потребительские товары с использованием цифровых технологий.
Чтобы воплотить это стремление в "дорожную карту", лидерская группа определила бизнес-возможности, которые в корне зависят от технологий, данных и аналитики и которые можно улучшить, инвестировав в более чем 90 определенных инициатив. Для каждой из них они определили потенциальное влияние, способы измерения этого влияния и объем инвестиций, необходимых для получения такого влияния.
Чтобы разобраться в этих возможностях, руководство LEGO сгруппировало эти бизнес-возможности в 10 доменов по признаку релевантности (например, возможности, связанные с потребительским опытом, были отнесены к потребительскому домену). На основе этих данных руководство составило схему базовых решений и соответствующих технологий, данных и потребностей в талантах для каждого из них.
Этот процесс имел ряд преимуществ. Во-первых, он помог сплотить руководство, обеспечив им общее понимание возможностей и требований к их реализации. Еще одно преимущество заключается в том, что он вызвал у руководства настоящий восторг и убежденность в том, что многое возможно.
Команда определила приоритетные области, в которых они в первую очередь хотели создать отличный цифровой опыт: потребители (те, кто играет с продукцией LEGO, в основном дети); покупатели (те, кто покупает продукцию LEGO непосредственно у LEGO); клиенты (те, кто продает продукцию LEGO, то есть розничные партнеры); и коллеги (те, кто работает в LEGO Group). Эти приоритеты были положены в основу комплексной дорожной карты, в которой были определены приоритеты и последовательность ключевых цифровых решений для каждой группы пользователей или области. Это включало в себя определение потребностей в технологиях, данных и командных ресурсах для каждого решения, а также оценку инвестиций и требуемой отдачи для каждого из них. Совет директоров компании принял решение о значительных инвестициях в течение пяти лет для создания необходимых цифровых решений и вспомогательных технологий и аналитических возможностей.
Для реализации этого плана руководство компании знало, что им нужен лидер, имеющий реальный опыт работы со сложностями цифровой трансформации.
Поэтому они наняли главного директора по цифровым технологиям (CDTO) Атула Бхардваджа, который руководил цифровыми преобразованиями в Tesco и Media- MarktSaturn. Одним из важнейших решений, принятых им, стало внедрение операционной модели, в которой команды назначались и отвечали за каждый продукт, необходимый для реализации конкретного решения (разновидность модели продукта и платформы). Одни продуктовые команды занимались разработкой решений, ориентированных на пользователя, а также базовых приложений и рабочих процессов, например оптимизацией работы веб-сайтов. Другие сосредоточились на данных и технологических системах для поддержки этих команд разработчиков, например, на переносе приложений в облако, чтобы ускорить их разработку. Еще одна группа продуктовых команд занималась разработкой продуктов данных, которые используются в различных областях, таких как данные о клиентах, идентификационные данные и основные данные о продуктах.
Важнейшим компонентом этой операционной модели было наличие четкого руководства. У каждого домена был спонсор из команды руководителей и лидер из бизнеса и ИТ, которые несли совместную ответственность за достижение результатов в своем домене. Работая в партнерстве с этими лидерами, спонсор создавал дорожные карты и согласовывал последовательность решений и их дизайн. На уровне продуктовой команды, или подгруппы, бизнес-лидер брал на себя роль владельца продукта и, работая в тесном сотрудничестве с инженером, отвечал за управление бэклогом и расстановку приоритетов для достижения конкретных KPI. Такой акцент на интеграции бизнеса в структуру управления продуктами был крайне важен для обеспечения принятия бизнесом решений, которые будут разрабатывать продуктовые команды.
Владельцы продуктов из бизнеса работали в кросс-функциональных командах с ведущим инженером и командой из 8-10 человек, включая инженеров, тренеров agile, технических менеджеров программ, специалистов по анализу данных, дизайнеров и экспертов по аналитике. Конечной целью такой структуры команды было стирание различий между "бизнесом" и "технологиями". Все члены продуктовых команд имели общие KPI и стимулы, но технические специалисты подчинялись в конечном итоге CDTO, который управлял их карьерным ростом, обучением и развитием.
Чтобы управлять этой ориентированной на продукт операционной моделью, генеральный директор, технический директор и "спонсоры" доменов ежегодно распределяли бюджеты и ресурсы. Однако руководители доменов ежемесячно, а затем ежеквартально (или ежеквартальные бизнес-обзоры) анализировали прогресс продуктовых команд. Эти обзоры были направлены на отслеживание результатов и четко сформулированных KPI, которые определяли эти результаты, например, изменения в реализации технологических факторов (например, доля современных API, внедренных на поддомен/продуктовую команду) и доля приложений, перенесенных в облако.
Эти продуктовые команды также держали в руках ключ к тому, что CTDO называет сутью цифровой трансформации: данные. Ведь именно данные являются ключом к обеспечению расширенного пользовательского опыта, совершенствованию операций и снижению удельных затрат. Каждый домен владел своими данными и отвечал за их поддержание, а также за то, чтобы другие домены могли легко их использовать. Таким образом, бизнес устранил путаницу в данных и обеспечил, чтобы каждый продукт данных был единым источником истины. Такой подход к владению данными также позволил LEGO Group создать свою платформу данных, которая одновременно содержала эти объекты и предоставляла их другим командам через модель самообслуживания, включая специалистов по анализу данных, которые могли проводить на их основе расширенную аналитику и искусственный интеллект.
Реализация цифровых решений в сжатые сроки, определенные дорожной картой, потребовала от LEGO Group привлечения талантливых инженеров. Это было особенно актуально, поскольку в штате компании было менее 30 % инженеров, а около 70 % кода разрабатывалось внешними ресурсами. Нехватка старших инженеров на уровне директора/старшего директора усугубляла проблему. Чтобы привлечь талантливых специалистов, LEGO Group посещала конференции разработчиков и запустила кампанию в социальных сетях, чтобы рассказать о новейших технологиях, которые используют разработчики, и о глубоких технических проблемах, которые они решают. Они также открыли цифровую студию в Шанхае, которая выросла с семи до 75 специалистов по цифровым технологиям и аналитике, и студию в Копенгагене, где работают 200 новых специалистов по цифровым технологиям и аналитике. В кратчайшие сроки они увеличили число должностей системных инженеров и инженеров-программистов в 2,5 раза, причем большинство из них обладают навыками работы с облачными технологиями.
Привлечение талантливых инженеров помогло LEGO Group решить две конкретные задачи. Одна из них заключалась в агрессивной модернизации приложений и систем с целью создания более гибких, быстрых и самостоятельных сервисных возможностей. Это включало в себя погашение технического долга, автоматизацию инфраструктурных операций, таких как конвейеры, перенос до 80 % ключевых рабочих нагрузок в облако и развитие возможностей платформы как услуги и SaaS для радикального сокращения использования монолитных приложений. Вторая - внедрение передовых инженерных практик, таких как DevSecOps для интеграции безопасности в процесс разработки с самого начала (с постоянным измерением показателей Национального института стандартов и технологий), практики CI/CD для ускорения и повышения качества кодирования, а также MLOps для разработки и управления моделями искусственного интеллекта.
Основное внимание уделялось тому, чтобы пользователи принимали решения, которые разрабатывали команды, и чтобы эти продукты могли масштабироваться. Поэтому LEGO Group ввела политику, согласно которой все технологические решения должны быть с самого начала разработаны и спроектированы для глобального использования. Это означало использование предписанных стандартов API и специальной таксономии данных для всей компании, которая включала в себя четкие определения доменов данных и объектов, четкое отображение связей и документацию, а также четкую ответственность за эти домены данных. У CDTO были полномочия, и он часто использовал их, чтобы наложить вето на "локальные" усилия, которые не соответствовали этим принципам. Такой подход позволял командам работать параллельно, не застревая и не замедляясь в регрессионном тестировании и общении между командами.
Спустя несколько лет после начала этапа цифровой трансформации LEGO Group видит улучшения и понимает, что находится на правильном пути. LEGO Group назвала сильную электронную коммерцию и омниканальное партнерство с розничными сетями важными факторами, способствующими достижению результатов. Согласно отчету о прибылях и убытках LEGO Group, выручка выросла на 17 %, а операционная прибыль - на 5 % по сравнению с аналогичным периодом прошлого года. Компания также отметила, что ускоренные инвестиции в ее цифровую трансформацию принесли широкие выгоды, включая улучшение онлайн-опыта для покупателей и партнеров и расширение возможностей строительства для потребителей.
Сайт был перестроен в соответствии с масштабом, а количество загрузок приложения LEGO Builder увеличилось на 42% по сравнению с 2021 годом.
Новые цифровые возможности, созданные LEGO Group в масштабах предприятия, открывают новые пути роста для компании. LEGO Group осваивает новые сферы деятельности, в том числе сотрудничает с Epic Games, чтобы исследовать будущее игр на цифровой арене и в метавселенной. Эти игровые амбиции сочетаются с желанием создать добродетельную экосистему точек соприкосновения с потребителем, начиная с физического опыта в магазине и заканчивая активным взаимодействием на нескольких социальных платформах, где все чаще появляются дети. Группа LEGO инвестирует в создание целого ряда новых возможностей, включая разработку игр и игровой дизайн.
Примечание
1. "LEGO Group обеспечивает уверенный рост в 2022 году и инвестирует в будущее", LEGO.com, 7 марта 2023 года.