Принятие и изменение бизнес-модели: Практически в любом сценарии можно ожидать, что 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
Не исчерпывающий
БИЗНЕС
Предоставление бизнес и функциональной экспертизы
Определяет и расставляет приоритеты в дорожной карте и бэклоге продукта
Эксперт в данной области