Содержание
В сегодняшней статье мы хотим хочу поделиться с Вами основными причинами возникновения абсолютного большинства проблем в проектах по цифровизации и цифровой трансформации.
И в самом начале мы озвучим Вам основную идею.
Главные причины неуспешности или проблемности до 84% всех инициатив – недостаточная подготовка, иллюзии о «простоте» и акцент на технологиях, а не на культуре компании: ее людях и процессах.
По разным оценкам, от 70 до 84% проектов по внедрению цифровых технологий, цифровизации и проведению цифровой трансформации либо неуспешны, либо проблемные: срываются сроки, превышаются бюджеты, не достигаются критерии успешности, достигаются эффекты только внутри 1-2 бизнес-процессов или подразделений, приводят к повышению текучки персонала.
Мы не будем погружаться в общие причины проблем всех проектов.
Но мы попробуем разобраться с проектами по нашей теме. Опустится на уровень конкретных проблем и причин, что надо сделать, чтобы локальными действиями добиться системного эффекта.
И, как часто бывает, почти все проблемы являются следствием небольшого перечня типовых причин. Мы, на основе своего опыта и общения с множеством партнеров, постарался для Вас структурировать эти причины и подготовить для Вас рекомендации, что делать.
Причина №1. Нет глобального понимания сути, целей и технологий цифровизации и цифровой трансформации
Как Вы думаете. Понимают ли ТОПы в компаниях, что такой цифровизация, цифровая трансформация? В чем между ними разница? В чем суть? Какая конечная цель? Каков масштаб «беды»?
Я отвечу, что в 70-80% процентах случаев, а может и чаще - нет. Для них это черный ящик.
И к чему это приводит?
Первое: неверная постановка целей, искаженные ожидания
Правильная цифровая трансформация – долго и дорого. В очень хорошем случае 2-3 года. А первых результатов следует ожидать не ранее чем через 9 месяцев или даже год. И в мировых компаниях это понимают, финансируют как исследовательские лаборатории. В нее вкладывают без гарантий. Все готовы к тому, что может и не взойти. Но если получится – окупит все вложения.
У нас же, например, большинство предпринимателей и руководителей хотят увидеть ощутимые результаты и завершить трансформацию в течение 6 месяцев и с гарантиями и пониманием кого увольнять в случае неудачи.
Еще один фактор - все ожидают, что придет волшебник и все им цифровизирует, принесет все счастье даром. А главное, им не придется вникать в проекты, формулировать запросы и т.д.
Также типичной ошибкой является фокусировка на технологиях и «прямых» эффектах внутри одного бизнес-процесса – сэкономили 30 млн рублей, снизили время на 50% на оформление бумаг, сократили 15 человек. Это безусловно важно, но в цифровизации и тем более цифровой трансформации важно смотреть в масштабах всего бизнеса: использовать сквозную аналитику, устанавливать кросс-функциональные показатели эффективности, устранять потери в бизнес-процессах и снимать ограничения системы
Например, внедрение дополнительных показателей, для оценки производственного подразделения по данным от ИТ-системы HR, изменение ритма производственного цикла, динамика изменения рентабельности производства и производительности в млн рублей чистой прибыли на 1 сотрудника и т.д., создание нового продукта или создание новой бизнес модели.
Цифра и цифровая трансформация не только и не столько про технологии, сколько изменение подходов к работе, мышлению, культуре.
И важно понимать – цифра лишь инструмент, она не выведет Вас автоматически на новый уровень. Придется меняться всем, в том числе генеральному директору и собственникам.
Второе: некорректно сформированная команда
РАНХиГС подготовило хороший отчет, по рекомендациям к компетенциям участников цифровой трансформации. И для проведения трансформации надо исполнение обязательных ролей:
CDTO (ChiefDigitalTransformationOfficer, руководитель по цифровой трансформации). Ключевая роль в команде цифровой трансформации принадлежит ее руководителю и главному идеологу, который выбирает цели и направление движения, согласовывает бюджет и руководит реализацией трансформации, координируя все проекты с подразделениями, взаимодействуя с внешними сторонами, вдохновляя свою команду.
Главный архитектор (CA). Отвечает за практическое воплощение трансформации в виде стыковки всех «слоев» архитектуры компании (бизнес-процессов, программных приложений, хранилищ данных, интерфейсов обмена и т. д.). Обеспечивает изменчивость систем для построения платформы цифровизации. Нежелательно совмещение одним человеком ролей главного архитектора и руководителя проекта, поскольку их функции и полномочия в рамках проекта сильно различаются.
CDO (ChiefDataOfficer, руководитель по работе с данными) Отвечает за своевременное предоставление необходимых данных и аналитики, координирует их сбор, хранение и обработку, формирует подразделение по работе с данными. В госсекторе CDO также отвечает за интеграцию и консолидацию данных разных органов и ведомств.
CTO (ChiefTransformationOfficer, руководитель по цифровому проектированию и процессам) Отвечает за внедрение процессного подхода и проектирование новых цифровых сервисов, изучение процессов, потребностей и «клиентов» госорганов в организации межведомственных взаимодействий.
Кроме того, рекомендуется ввести в команду такие роли, как:
юрист (отслеживает изменения, нововведения и нюансы законодательства, прежде всего, в сфере интеллектуального права и права на данные);
специалист по взаимодействию с внешними организациями (устанавливает контакты с владельцами данных, используемых в проекте);
специалист по информационной безопасности (отвечает за защиту данных, которые неизбежно привлекают повышенный интерес сразу после информирования внешней среды).
Это необязательно речь про людей, это РОЛИ, которые надо предусмотреть.
Третье: неэффективное использование «дорогих» технологий.
В итоге – разочарование и убытки, преждевременный отказ от развития.
Скажите, а за что у Вас отвечает директор по ИТ? Какие ключевые показатели эффективности у него и его людей? Какие компетенции являются доминирующими, по которым Вы их набираете? И главное, какое мнение внутри компании об ИТ департаменте в целом? Как отзываются люди, и что говорят между собой?
Как показывает практика, делегирование вопроса цифровой трансформации классическим специалистам из ИТ нередко приносит ряд проблем.
Но почему?
Классическое ИТ делает надежные системы. Для CIO важны стабильность работы ИТ систем, соблюдения бюджетов, процессов, регламентов, снижение рисков и оптимизация затрат. У них нет задачи думать о повышении прибыльности бизнеса, ориентироваться на клиента, в том числе на внутреннего, общаться с ним.
В противовес ему, для руководителя CDTO важна оптимизация бизнес-процессов в целом и повышение эффективности всего бизнеса, в том числе в интересах клиента, поиск новых возможностей для повышения доходности, работа с данными, а не «железом», сохранение гибкости и принятие рисков.
Это принципиально разные люди с точки зрения психологии. И чем выше уровень профессиональных компетенций классических ребят из ИТ, тем, как правило, хуже обстоят дела с компетенциями для цифровизации и цифровой трансформации.
Если попробовать сравнить на бизнесовом языке, то CIO это операционный директор, а CDTO это директор по развитию.
Для CDTO ключевые компетенции это:
Нацеленность на результат
Коммуникативность
Эмоциональный интеллект
Управление цифровым развитием
Управление организационным развитием
Критичность
При этом развитие ИТ-инфраструктуры, применение цифровых технологий, управление базами данных и т.д. должны быть, но это не основополагающие компетенции.
Нам нравится описание психологических качеств в теории Адизеса. И по ней, для для CIO важны А (администрирование) и Р (производство) функции, то есть «что надо» и «как надо», а для CDTO – Е (предпринимательство) и I (коммуникация), то есть понимать для кого надо, кем надо, и когда надо.
Путей решения проблемы здесь 2:
1.Выделять функцию проведения цифровой трансформации на отдельного менеджера, который будет координировать, продвигать. У которого будет своя команда
2.Учить и развивать своего СIO, прививать новую культуру – клиентоцентричную, ориентированную на расширение бизнеса, управлению на основе данных
Вопросы наличия описанных процессов и инвентаризации данных, обеспечения их качества в цифровизации и автоматизации краеугольные.
Без наличия описанных процессов вы быстро столкнетесь с проблемой понимания того, а что именно нужно автоматизировать и цифровизировать. Если цифровизация еще это может простить, то автоматизация нет.
Без качественных данных и понимания того, а какие данные и где есть, вы довольно быстро упретесь в сложности интеграции между ИТ-системами, невозможности выстраивать аналитику и мониторинг. Например, как только Вы решите создать дашборд, то столкнетесь с вопросом откуда будете брать данные. А вручную собирать эксельки, чтобы затем готовить аналитику затея так себя. Цена такой аналитики чуть меньше нуля.
И без понимания процессов вам будет трудно определить Ваши KPI, которые отталкиваются от них. То спроектировать сами дашборды будет уже затруднительно. Ну а ключевое, как вы будете перестраивать процессы (а это ключевая задача цифровизации), если не понимаете, что именно нужно перестраивать.
Поэтому цифровизация и невозможна без специалистов по процессам и качеству данных, или CDO (руководитель направления работы с данными) - один из ключевых участников команды цифровизации.
А сколько компаний осознают роль процессов и данных?
Большинство компаний игнорируют эти вопрос на ранних стадиях. Вопрос работы с процессами мы рассмотрели в этой статье. Следствие этого простое - проекты автоматизации и цифровизации даже не могут стартовать. А если и стартуют, то затягиваются в 3-4 раза от плана. И бюджет превышается также - в несколько раз. Мы это видели на практике многократно. Тут нужно отметить еще один факт. Обязательная задача любого проекта - выделить заинтересованные стороны. А как их выделять, если нет процессов?
Если коснуться вопроса работы с данными, то здесь мы видим следующее:
не прорабатывают политики и правила сбора данных
не обучают персонал, почему и как работать с данными
не проводят инвентаризацию данных и их источников
не моделируют сценарии применения уже имеющихся данных
нет канонической модели данных
не установлены критерии качества и не ведется работа по проверке данных на соответствие критериям.
Следствие:
невозможно использовать сквозную аналитику между различными бизнес-процессами и подразделениями. А если, возможно, то необходимы «костыли» и ручной труд дорогих специалистов. То есть растет стоимость каждого принятого решения;
невозможно создать качественные и часто обновляемые индикаторы, что приводит к запоздалым, некачественным, и опять же дорогим решениям;
необходимость вкладывать значительные ресурсы на модернизацию и переделку проектов;
невозможно заниматься интеграцией различных ИТ-систем;
невозможно развивать решения на основе искусственного интеллекта;
идет дублирование данных между ИТ-системами и растет нагрузка на ИТ-инфраструктуру.
Как итог - торможение на пути цифровой трансформации, то есть потери потенциальной прибыли. В мире начинает распространение подход к управлению данными (CDO) 3.0 и 4.0, в России актуален 1.0 и 2.0.
Уровни работы с данными (CDO)
CDO 1.0 – создание единой корпоративной модели данных.
Ключевые роли: архитектор данных, команда качества данных.
Ключевые задачи: разработка политик работы с данными, правила сбора и контроля качества данных, определение владельцев и потребителей данных, создание хранилища данных.
CDO 2.0 – использование бизнес-аналитики для управления и принятия решений
Ключевые роли: группа бизнес-аналитики и методики расчета бизнес-показателей / метрик.
Ключевые задачи: выработать единые метрики и понимание этих метрик у разных бизнес-подразделений, правила подготовки управленческой отчетности и аналитики, сформировать культуру принятия решений на основе данных.
CDO 3.0 – исследования и выдвижение гипотез на основе данных для поиска новых источников прибыли, развития продуктов.
Ключевые роли: исследователи и аналитики данных.
Ключевые задачи: научиться ставить гипотезы, анализировать и визуализировать данные, внедрить инструменты обработки данных.
CDO 4.0 – создание новых продуктов и сервисов на основе данных, стратегия компании на основе данных.
Ключевые роли: группа по разработке стратегии.
Ключевые задачи: интегрировать анализ данных и продуктовое управление, поиск новых взаимосвязей.
Уровни 1.0 и 2.0 позволяют реализовать стратегию защиты - увеличить скорость реагирования на изменения, реализовать проактивный подход, минимизировать риск ошибок, повысить качество принимаемых решений
Уровни 3.0 и 4.0 – стратегию нападения - создание новых продуктов, новых бизнес-моделей, монетизация опыта и т.д.
Ценность модели защиты в том, чтобы снижать риски, ценность модели нападения в том, что Вы увеличиваете выручку и ваш бизнес растет, продажи растут, конверсии растут, и все клиенты довольны.
Но для того, чтобы процесс масштабировался, нужно обеспечить базовые условия. Если стратегия защиты не реализована, в стратегию нападения переходить бессмысленно. Патронов - качественных данных у Вас не хватит. Нужно, чтобы кто-то их подавал. У Вас не будет карты местности, и Вы просто заблудитесь, потратите ресурсы зря. Поэтому подумайте о том, чтобы реализовать качественно CDO 1.0 и 2.0, не прыгайте сразу в CDO 3.0.
Массовое желание сразу прыгнуть в CDO 3.0 понятно. Это безумное чувство, что нужно зарабатывать деньги и не сидеть на месте, но без базы это невозможно. Любой шаг создаст новые риски. Эти риски будут нарастать, как снежный ком. И в какой-то момент Вам придется просто переделывать все, что Вы сделали для того, чтобы выйти на новый уровень развития.
Давайте приведем практический пример.
Допустим, вы наняли гениального разработчика и решили разработать собственную ИТ-систему. Разработчик сделал классное решение и вы начали собирать информацию. Но спустя полгода вы коснетесь вопроса принятия решений на основе данных из системы, однако сделать этого не сможете. Выясниться, что данные "грязные" и задублированные, принимать решения на их основе невозможно. В итоге придется или все удалять и начинать сбор заново, или искать тех, кто вручную будет все приводить в порядок.
Вторая проблема будет в том, что как только захотите делать интеграцию между системами, вы просто не будете понимать, откуда и какие данные брать, в каком виде. Или окажется, что данных для достижения целей проекта не хватает. В итоге проект будет стартовать долго и при реализации будут срывы сроков и стоимости.
Аналогичные проблемы будут если не заниматься бизнес-процессами.
В результате ваш разработчик выгорит и уволиться, а вы останетесь с "черным" ящиком, ИТ-системой, которая и не работает, и изменить вы ничего не сможете.
Решение:
1. Оцифруйте ваши основные бизнес-процессы и проведите инвентаризацию данных.
2. Определите, какие источники данных есть в процессах, чего не хватает, какие данные генерируются в результате исполнения процессов. Подумайте, какие метрики можете использовать уже сейчас и какие процессы приоритетны для цифровизации и автоматизации.
3. Проведите моделирование сценариев, где и какие данные можете применять, определите метрики. Проводите мозговые штурмы за круглым столом. Как, например, использовать данные HR, чтобы дополнительно оценивать эффективность отдела эксплуатации?
4. На основе встреч проработайте модель данных и стейкхолдеров
5. Определите критерии качества, которым должны соответствовать эти данные
6. Определите, как Вы будете хранить данные? Что Вам надо, хранилище данных или озеро данных?
7. Начните внедрение MDM системы и проведите обучение Ваших сотрудников работе с данными. Они собирают и вносят первичные данные и НСИ, от них зависит очень многое. Прививайте культуру работы с данными.
8. Активно применяйте визуализацию перед сбором данных в шаблоны. Это поможет избежать 70-80% ошибок, которые совершают сотрудники при заполнении Ваших шаблонов. Вы сэкономите кучу времени и денег.
Например, визуализируйте структуры компании, на примере типовых подразделений. Какие данные на какой уровень справочника пойдет.
8. Регулярно ведите контроль качества данных, встречайтесь и обсуждайте возникшие проблемы и причины, необходимые изменения.
И определитесь с вопросом: Вы будете принимать решения на основании данных, или с учетом данных? Вы Data Driven или Data Informed?
Data-driven подход Управление основанное на данных. Cначала получают цифры, а потом на их основе принимают решения. Команда выбирает метрики и считает показатели. Полученные числа — первое, на что они посмотрят, решая, куда двигаться дальше.
Data-informed подход Управление с учетом данных. Метрики только частично влияют на принятые решения. Показатели — это важно, но не главное. На них можно ориентироваться в одном случае и не учитывать в другом.
Data-inspired - анализ рынка и трендов, поиск неочевидных связей в разрозненных данных служит для принятия стратегических решений и поиска новых возможностей.
Статья про стратегии работы с данными доступна по ссылке.
Также делимся ссылкой на статью по оценке уровня зрелости компании по работе с данными.
Как Вы считаете, существующие и предыдущие поколения ИТ-систем удобны для пользователей и администраторов? Они интуитивны? Не заставляют делать лишних действий и движений? Легко интегрируются между собой?
Мы все еще находимся в том периоде, когда промышленные ИТ-системы проектируются не с ориентацией на удобство пользователя, как внешнего, так и администратора, а с ориентацией на ТЗ и функциональные характеристики.
Мы с партнерами работали, в том числе и как администраторы, не с 1-й, не с 2-мя и не с 3-мя ИТ-системами абсолютно разных направлений. Это и было управление активами, и оценка знаний, и системы промышленной безопасности. Я даже и не вспомню всех. При этом практически никто из разработчиков не оптимизирует свои продукты через принципы бережливого производства, не старается делать продукт максимально удобным и простым.
Дополняем это «зоопарком» систем, интеграцию которых в единую информационную среду никто изначально не планирует.
В итоге мы получаем:
функциональные, но требующие долгого освоения системы. Тем самым ограничиваем свои возможности при найме нового персонала, а значит должны им больше платить или тратить больше времени на обучение и ввод в должность. Что все равно не гарантирует, что такие сотрудники будут формировать больше добавленной стоимости
высокий уровень потерь и затрат при работе в системе и их сопровождении
Например, в нашем опыте есть кейс, когда внесение 2-х небольших изменений в интерфейсе и механике работы для администратора позволяли снизить трудозатраты на 50-60%.
Нужно было лишь выполнить типовую задачу, проанализировать ее и выявить потери. При этом, когда Вы внедрите и увидите все эти минусы, структурируете и сформулируете своих пожелание - договор с интегратором будет закрыт, а все доработки будут за отдельную плату. Или изначально, они дают Вам "коробку", определяют количество "бесплатных" человеко-часов на доработку, все остальное за Ваш счет.
Очень немногие интеграторы и разработчики стремятся собирать обратную связь и делать лучший продукт, расширяя пул заказчиков. Для многих эти доработки – источник прибыли.
высокие издержки на работу по обработке данных. Об этом мы говорили ранее.
сопротивление персонала. Мало того, что это дополнительная нагрузка на них для изучения, так еще это и усложняет их работу: зачастую это неудобно, куча лишних действий, дублирование процессов в цифре и на бумаге.
Решение:
1. Играйте по возможности в бесплатные сервисы. Вы научитесь понимать, что Вам надо, поймете как писать ТЗ и какие требования закладывать. А грамотное ТЗ - 50% успеха
2. Обучайте своих администраторов и актив, 10% пионеров, основам бережливого производства. Что такое потери, какие бывают, на что влияют? Вы сможете сразу отлавливать все недоработки и направлять "внедренцам".
3. Регулярно собирайте обратную связь от пользователей и администраторов об УДОБСТВЕ системы, где можно улучшить, доработать. И желательно не только через опросы, но и через сбор неформальной связи.
4. Повышайте в компании компетенций в работе с данными и держите в фокусе конечную цель – создание единого информационного пространства. А значит – закладывание в ТЗ возможности интеграции с действующими системами или хранилищем данных.
5. Отправляйте своих сотрудников на конференции. Учитесь на чужом опыте, изучайте новые продукты. Есть мнение, что полностью обновлять Ваш софт надо каждые 5 лет
Во многих компаниях существуют регламенты и стандарты управления проектами, создаются проектные офисы.
Но как Вы думаете, много ли руководителей на местах понимают что такое проекты, продукты, управление изменениями?
Спросите их:
Что такое PMBoK, а что такое Agile? Что такое спринт? Почему и для чего он длится 1-4 недели?
Из каких 5 стадий/процессов состоит весь проект и каждый этап?
Когда лучше водопадный подход, а когда гибкий Agile?
Что такое цикл PDCA?
Чем проект отличается от продукта?
Какова конечная цель их конкретного проекта?
Какие типы сопротивления могут быть у персонала? Как с ними работать?
Каков процент работников с радостью будут принимать изменения, на кого можно опереться? А сколько до последнего будут в оппозиции?
Многие из Вас уже понимают, какую картину они увидят.
Это один из факторов, почему многие проекты сталкиваются с проблемами: руководители не знают как организовать работу в рамках проекта, как отработать сопротивление персонала, зачем создавать недоработанный продукт и тестировать на людях, зачем соблюдать цикл «планируй – делай – проверяй – корректируй».
В итоге мы встречаем хаос, проблемы с коммуникацией, отсутствие единого понимания конечной цели, а порой и саботаж.
Для повышения шансов на успех, Вам не обязательно, даже вредно обучать всех сотрудников и проводить сертификацию, писать регламенты. Это НЕ РАБОТАЕТ и это дорого.
Вам необходимо создавать простые и доступные для среднего сотрудника обучающие программы и формировать культуру работы над изменениями, новыми продуктами и проектами. Надо виртуализировать навыки и дать людям понимание об основных инструментах и их различиях.
И уже в качестве помощи готовить не регламенты, а памятки. Куда Ваши сотрудники смогут быстро погрузиться и освежить свои знания.
Мы будем рады, если наши другие статьи Вам в этом помогут. Пользуйтесь.
Давайте поймем, кто в итоге работает в новых системах, чью работу мы подвергаем изменениям?
Каков уровень цифровых навыков у этих людей?
У меня был проект, где внедрялась система управления активами. Но оперативный персонал не умел печатать на ПК.
И первое что пришлось делать – учить их набирать текст. Чтобы запись о дефекте не вносилась 3 часа с 30-ю опечатками.
Другой пример. Мастер на производстве, к слову 27 лет, не знал как составить таблицу в экселе.
А как думаете, какой самый частый запрос в тех поддержку при внедрении любой ИТ-системы?
Некоторые из Вас уже догадались – 80-90% запросов идут из категории «забыл пароль», «не могу зарегистрироваться».
Это проблема в чем-то схожа с проблемой сопротивления изменениям по техническим причинам. Но отличается тем, что часто люди неосознанно тормозят весь процесс, не потому что не хотят, не знают, а потому что не умеют.
А сможет ли человек разобраться в логике и специфичном интерфейсе новой системы, если он не сможет сделать простую сводную табличку в экселе? Даже если под рукой есть доступ в интернет
Решение одно – обучение.
Но тех кто готов учится сам, вне работы и за свой счет – единицы. Тут мы Америку точно не открываем.
Новые цифровые технологии выдвигают требование нового уровня знаний и компетенций как от людей, которые будут эти технологии внедрять, так и от тех, кто будет ими пользоваться.
И поверьте, даже среди молодого поколения не так много людей, которые могут соответствовать всем необходимым требованиям по работе с новыми инструментами и в новых реалиях.
Требуются масштабные мероприятия по обучению и переобучению, формированию мотивации, преодолению сопротивления инновациям.
Пройти оценку цифровых навыков можно по этой ссылке.
В первую очередь изменения отразятся на сотрудниках трансформируемых организаций. Далеко не все окажутся готовы к новациям, это зависит от образования, опыта, личностных качеств. Обязательно найдутся те, кто болезненно воспримет изменения и технологические нововведения.
При реализации цифровых проектов затрагивается большое количество пользователей, и их уровень базовой IT-подготовки бывает сильно различен. Накопленная статистика показала, что «подтягивание» базовых навыков использования ПК заметно увеличивает вероятность успешного внедрения цифровых решений в целом.
Тестирование около 2500 пользователей, затронутых изменениями по одному проекту, показало желательность обучения навыкам владения компьютером для 850 из них. Обучение было проведено в объеме 32-часовой программы и стало одним из факторов общего успеха в реализации комплексной трансформации.
Виртуализация цифровых навыков в условиях все больших изменений становится обязательным требованием.
Виртуализация компетенций - когда нет больше единого ответственного, например, за Microsoft Office внутри компании, а каждый умеет пользоваться этим инструментом.
Если Вы хотите строить конкурентоспособную организацию, то каждый Ваш сотрудник должен заниматься созданием добавленной стоимости.
А может ли создавать сотрудник добавленную стоимость, если он не может самостоятельно сделать выгрузку данных или сделать сводную таблицу чтобы посмотреть информацию и принять решение? И отправляет этот запрос какому-то единичном «гуру»? А насколько продуктивно Вы используете труд этого гуру?
А как Вы думаете, сможет ли единый ответственный проверить все загрузочные шаблоны, присланные с полей?
Ответ – нет. Сотрудники должны понимать, например, что такое данные? Как их собирать, что такое чистые и нормализованные данные.
А это значит, что необходимо переходить на распределенную модель управления.
Немного о моделях управления.
Централизованный метод, когда Вы пытаетесь нанять одного человека, поставить его в центре всей общей ответственности, вокруг него организовать центр компетенций. И именно этот человек будет определять то, как эта функция развивается, как она интегрируется внутри компании и что происходит в этот момент.
Второй метод – федеративный. Придумали его эксперты из Экономического форума в Давосе. Метод, при котором у вас не один лидер, а несколько лидеров. Хороший пример в этом отношении, например, институт бизнес-партнерства.
Возможно, Вы знаете, что есть такие люди, как HR бизнес-партнеры. Они занимаются тем, что представляют интересы той или иной функции, например, корпоративного банка, или корпоративного бизнеса, или Digital-бизнеса внутри или вне HR-департамента. Они управляют ожиданиями этих стейкхолдеров для того, чтобы внутри компании все ощущали счастье от того, что HR работает очень круто. Данные, в принципе, как функция существуют по схожей схеме. Функция данных тоже должна сделать людей счастливыми внутри, дать чувство зачем-то они этим занимаются.
И федеративная модель – по сути, создание таких маленьких федераций, которые общаются между собой. Над ними по-прежнему есть главный «папа», который помогает разруливать конфликты и распределять ресурсы. Но федерации сами внутри себя развивают функцию данных:
определяют, что для них нужно;
какие инструменты и подходы использовать;
пытаются договориться между собой про единое взаимопонимание вокруг данных;
определяют стратегии в отношении того, что делать, а что нет в отношении данных.
Распределенная модель. Представьте себе Excel или Microsoft Office целиком. Когда он вышел, многие считали, что использовать и писать макросы требует достаточно высокой компетенции от сотрудника (такое мнение существует до сих пор). То есть внутри компании должен быть специальный человек, который знает макросы. К нему можно обратиться за помощью, и он их напишет. Так внутри компании организуется центр компетенций Microsoft Office. Но на самом деле Microsoft Office сделан для того, чтобы каждый мог использовать эту функцию, каждый мог работать с офисом, каждый мог создать свою собственную табличку или написать свой собственный макрос.
Что это означает? Это означает виртуализацию компетенций, когда нет больше единого ответственного за Microsoft Office внутри компании, а каждый умеет пользоваться этим инструментом. Так вот, распределенная модель управления подразумевает, что Вы не нанимаете одного человека, который отвечает за данные внутри компании. Вместо этого функция виртуализируется и становится обязательной компетенцией у каждого сотрудника, который соприкасается и работает с данными. Взамен Вы получаете сильную компанию, которая самостоятельно масштабируется, развивается.
Вот мы и пришли вопросу культуры. Если у вас в компании все друг к другу относятся с позиции «мне должны», если вы ждете, что придет цифровизатор, который принесет счастье и все за всех сделает, то у у нас для вас плохие новости. В такой культуре даже самый талантливый цифровизатор выгорит за 3-4 месяца. И вместо клиенториентированного специалиста станет типичным ИТ-шником, который не хочет никого видеть. Ни о какой распределенной модели цифровизации тут не будет речи.
Цифровизация и цифровая трансформация с минимальными издержками возможно только если подразделения, то есть бизнес-заказчики, вовлечены, заинтересованы в изменениях, понимают базовое управление проектами. А цифровизаторы помогают выбрать технологии и поставщиков, координируют проекты и выбирают бизнес-модели, сопровождают бизнес как партнеры. Отсюда и появился новый термин – ИТ бизнес-партнер. И в целом цифровизация - это про умение договариваться и работать сообща. В противном случае будут внедрятся инструменты, но даже самыми качественными пользоваться не будут и все будет отторгаться через 3-6 месяцев.
Вообще для выбора правильной ролевой модели поведения нужно изначально определять тип организационной культуры компании и отдельных подразделений. Ниже небольшая табличка с рекомендациями.
Определить глобальную цель цифровой трансформации - что это, к чему идем, какую конечную цель должны преследовать все проекты. В общем подготовьте стратегию цифровизации, на основе общей стратегии развития. И сделайте эту информацию доступной для всех. Поможет в этом дорожная карта. Простая, обобщенная, но с крупными вехами и примерными сроками, чтобы все понимали конечную цель Ваших преобразований.
Сформируйте команду с выполнением основных ролей.
Развивайте клиентоцентричность. Спросите лояльных клиентов, как они видят вас цифровыми, в каких услугах есть необходимость сократить цикл процессов до минут и секунд посредством «цифры». И помните, клиенты бывают внутренними. Поэтому клиентоцентричность нужна и ИТ подразделениям.
Проведите инвентаризацию и оцифровку бизнес-процессов, структурируйте данные, которые уже есть и которые будут генерировать после внедрения технологий.
Разрабатывайте простые и понятные для «среднего» сотрудника программы обучения и памятки.
Выделяйте 10% активных новаторов. Опирайтесь на них и обучайте. Сначала простыми программами, а затем цифровым технологиям, управлению проектами, управлению данными, бережливому производству (виды потерь), КРИТИЧЕСКОМУ и системному мышлению, теории ограничения систем, работе с сопротивлением персонала. Создавайте в ваших командах пространство, свободное от наказаний: обсуждайте ошибки не в терминах «а кто виноват», а в парадигме «чему мы можем научиться». Отправляйте их на конференции и обсуждения – ОНИ СТАНУТ ВАШИМ АКТИВОМ И ИСТОЧНИКОМ КАПИТАЛИЗАЦИИ, БУДУТ НАХОДИТЬ ЛУЧШИЕ РЕШЕНИЯ И БУДУТ АГЕНТАМИ ИЗМЕНЕНИЙ
Повышайте уровень цифровой грамотности рядовых сотрудников и виртуализируйте цифровые навыки (проводите обучение и демонстрируйте использование цифровых инструментов).
Создайте механизм сбора обратной связи от сотрудников, администраторов. Огромное количество знаний и идей живет внутри компании. Менеджменту надо научится ее собирать. Регулярно проводите обзор трендов, «очистку от хайпа» и отвечайте на вопрос «что из этого мы можем взять себе».
Ведите диалог, давайте обратную связь, начните говорить «спасибо», когда с вами поделились информацией о крупной и серьезной проблеме. Результат не заставит себя ждать: вскоре вы будете прекрасно информированы о рисках в проекте.
Проводите встречи и обсуждения, по тому, как использовать новые данные. А KPI ЗГД привяжите к эффективности этих встреч и получаемым результатам. Формируйте кросс-функциональные команды между отделами и разными уровнями иерархии под управлением модератора. Поощряйте разные взгляды на проблему и конструктивное обсуждение сложных тем с различными точками зрения, творческий подход и дизайн-мышление.
Отслеживайте, что делают лидеры цифровой трансформации в вашей отрасли и в мире.
Используйте бесплатные инструменты и сервисы везде, где это возможно. Создавайте и поощряйте зоны цифровых экспериментов и применения новых технологий, делитесь историями успеха и позитивными эмоциями. Поиграйтесь, наработайте компетенции, получите результаты, практический опыт взаимодействия с современными цифровыми сервисами, что решит следующие проблемы:
компания будет понимать, какие требования необходимо закладывать к комплексным решениям и подойдет к полноценной трансформации более осознанно
будут получены эффекты уже в краткосрочной перспективе;
команда предприятия повысит свои цифровые компетенции, что снимет ограничения и сопротивление по техническим причинам;
будут выявлены ограничения существующих бизнес-процессов и «узкие» места.
Двигайтесь маленькими системными шагами, демонстрируйте успехи и результаты. PR проекта не должен заменять успехи, но и полное молчание является ошибкой.
Используйте проектные методологии и оптимизируйте цифровые процессы, чтобы устранить хаос и люди увидели эффекты.
Это позволит в короткие сроки повысить эффективность и эффективнее провести реинжиниринг процессов.
Эти вполне конкретные решения и меры, позволяют изменить Вашу культуру организации. А это главное условие успешного внедрения цифры и проведения трансформации.
Цифровая трансформация - сложная комплексная задача. Там никогда не будет людей со всеми компетенциями. Помимо знания цифры, нужны навыки в проектном и продуктовом менеджменте, работы с мотивацией и сопротивлением, реинжинирингом процессов. Компании должны менять себя изнутри и нарабатывать компетенции изнутри. Найм классных ИТ кадров, разработка стратегий, внедрение технологий без изменения культуры работы - пустая трата денег.
Залог успешной цифровизации и цифровой трансформации такой же, как при реализации любых проектов и любой операционной деятельности - умение сесть и договориться, услышать друг друга, работа со своими кадрами. Все компетенции у Вас есть внутри компании. Ваша задача - выделить необходимых людей, обучить их и дать полномочия, ресурсы, ответственность. Ну и бонус. Ссылка, по которой Вы можете перейти на статью, где представлен небольшой и простой алгоритм, основанный на:
Теории ограничения систем
Бережливом производстве
Проектном и продуктовом управления
Теории мотивации и внедрения изменений.
Его цель – помочь Вам начать путь в цифре и получить быстрый эффект, наработать первичные компетенции и дальше пойти уже осознанно.