Любой современной организации необходимо осваивать новые технологии, чтобы реагировать на изменения рыночных условий и не отставать от конкурентов. Цифровой конвейер меняет подход к внедрению инноваций и позволяет поставить их реализацию «на поток». Как изменить операционную модель при запуске цифрового конвейера, рассказывает Глеб Комолов, эксперт по цифровой трансформации Axenix.
Цифровой конвейер — это процесс создания инноваций: от генерации идей и до внедрения/получения эффектов от реализации инициатив. Для его запуска необходимы три составляющие:
- Непрерывное рассмотрение инициатив — это процесс, позволяющий предприятию постоянно генерировать идеи, тестировать их, внедрять и масштабировать лучшие на постоянной основе.
- Технологическая платформа — это набор систем и сервисов, упрощающий и ускоряющий разработку и внедрение инноваций.
- Операционная модель — определяет, кто и как «регулирует режим работы» цифрового конвейера.
В этой статье подробнее остановимся на том, почему важна операционная модель, какие этапы надо выполнить для ее проектирования и реализации и на что стоит обратить внимание в рамках этих работ.
Почему важна операционная модель
Одна из типичных проблем крупных предприятий — разрозненность команд, которые занимаются цифровизацией. Это приводит к дублированию покрываемого функционала, различию в применяемых технологиях и существенной нагрузке на бизнес-экспертов, которым требуется участвовать как в разъяснении постановки задачи, так и в тестировании продуктов.
Простой пример — две независимые команды: одна занимается разработкой системы для управления складскими запасами, а другая — созданием системы для планирования производства. Обе команды решают задачу учета материалов, но из-за отсутствия взаимодействия каждая из них разрабатывает собственный модуль, который фиксирует движение сырья на складе. В результате предприятие сталкивается с удвоением затрат, сложностями интеграции решений и перегрузкой экспертов.
Другой проблемой могут стать нестандартизированные процессы. Это может повлечь множество проблем — не только во время разработки, но и на других этапах цифрового конвейера. Например, во время проверки концепции (Proof of Concept, PoC), когда тестируют жизнеспособность гипотезы до начала полноценной реализации будущего продукта. В начале этого этапа важно правильно определить цель проведения PoC, метрики завершения, а также проверить, нужно ли вообще проводить этот этап процесса для текущей инициативы. Пропуск одного из этих шагов либо неверное привлечение специалистов может существенно повлиять на итоговые срок и стоимость решения.
Кроме того, важно обеспечить вовлечение бизнес-пользователей на каждом этапе реализации инициатив. Каждый участник команды должен понимать свои задачи и их влияние на смежные функции на каждом этапе проекта. Например, команда разработки несколько месяцев работала по ТЗ, написанному в начале проекта, без согласования промежуточных результатов с бизнесом.
В результате, когда наступит время перевода разработанной системы в ОПЭ (опытно-промышленная эксплуатация), окажется, что за время разработки в бизнес-процессе произошли изменения, которые никак не учтены в системе. Поэтому необходимо постоянное согласование промежуточных результатов работы с представителями бизнеса, например через проведение демонстрационных сессий (демо-дни), иначе в конце реализации система будет никому не нужна.
Барьером в инновационной деятельности может становиться и неоптимальная организационная структура офиса цифровой трансформации предприятия. Важно правильно спроектировать ее с учетом цифровой стратегии, чтобы на самых ранних этапах понимать, какие задачи будут выполняться внутренними сотрудниками офиса трансформации, обеспечивая их полную загрузку, а на какие целесообразно привлечь смежные подразделения или внешнего подрядчика.
Также для оценки работоспособности команд офиса цифровой трансформации и цифрового конвейера нужны система КПЭ и метрик, которые обеспечивают мониторинг и позволяют управлять эффективностью конвейера.
На уровне предприятия неправильная настройка операционной модели может привести к снижению операционного ритма внедрения продуктов, сложностям при их тиражировании и масштабировании, а также низкому уровню приживаемости новых решений.
Этапы проектирования и реализации операционной модели
Операционная модель, если упростить, — это процессы, люди и технологии.
Процессы
Необходимо предусмотреть реализацию процессных моделей всего жизненного цикла продукта. Он начинается с воронки идей — важно определить, как именно собираются идеи, кто и как их может подавать, как они будут оцениваться и приоритизироваться.
Далее начинается этап фрейминга — проработка гипотез до уровня детального расчета эффектов, описания функционала предполагаемого продукта и оценки сроков и приоритета реализации. Детализация должна выполняться до уровня, достаточного для рассмотрения инициативы на инвестиционном комитете компании.
Потенциально успешные идеи переходят на этап PoC (Proof of Concept), где отсеивается еще какое-то количество инициатив.
Важно отметить, что не все идеи требуют проверки гипотез, поэтому идея может сразу перейти на следующий этап жизненного цикла — MVP (Minimum Viable Product), создание минимально жизнеспособного продукта. Если инициатива успешно прошла этот этап, она переходит на внедрение, а после — на масштабирование и тиражирование.
Каждый из описанных этапов должен быть разбит на простые и понятные шаги, с обязательным разделением ответственности в соответствии с ролевой моделью, например по матрице RACI или ее аналогам.
Одной из важнейших составляющих реализации проекта является правильная и своевременная трансляция идей и результатов между бизнесом и ИТ командой. Эта задача относится к ролям бизнес-аналитика и системного аналитика, которые могут перевести задачи будущих пользователей на технический язык, а вопросы технической команды — на язык бизнеса. При этом нужно понимать, что ролевая модель не транслируется напрямую в организационную, она лишь задает необходимых участников процесса, которые в реальном мире могут совмещать несколько ролей.
Помимо процессов управления непосредственно инициативой на этапе разработки в рамках крупного предприятия, когда количество инициатив измеряется десятками и сотнями и находится на разных стадиях своего жизненного цикла (фрейминг, PoC, MVP, тираж и т.д.), необходимо зафиксировать и процессы управления портфелями. Идеи в них можно объединять по технологическому принципу или по бизнес-задаче.
Из преимуществ управления портфелями можно отметить, что зачастую защита портфеля на инвестиционном комитете компании проходит проще, чем защита инициатив по отдельности, так как видна взаимосвязь проектов для достижения общей цели. Также портфель позволяет более взвешенно подойти к оценке эффектов, когда общий эффект не является суммой эффектов от каждого проекта, а рассматривается каннибализация либо наоборот — синергия в зависимости от конкретного случая. Управление портфелями инициатив позволяет учесть комплексность бизнес-процесса, разделить логику между инициативами и обеспечить реализацию сложных взаимосвязей в рамках достижения бизнес-задачи.
Отдельное внимание стоит уделить процессам, которые, казалось бы, не входят в цепочку реализации проектов. Например, формированию единой базы знаний по предложенным инициативам. Если отбросили идею на каком-то этапе, важно понять — почему и определить ее дальнейшее движение: отдать в архив, вернуть на этап фрейминга для доработки, отложить до определенного времени и т. д. Эта информация должна лечь в основу дальнейшего анализа при реализации целевой бизнес-задачи, а не потеряться.
Когда инициатива запущена в промышленную эксплуатацию, стоит помнить о командах поддержки и развития, которые будут аккумулировать пожелания бизнес-пользователей, реализовывать изменения в продукте и поддерживать его работоспособность.
Люди (организационная структура, метрики и КПЭ)
Ролевая модель транслируется на все уровни организационной структуры — начиная от топ-менеджмента и заканчивая командами разработки, поддержки и сопровождения. При этом не стоит ограничиваться ИТ-направлением — важно определить роли бизнес-подразделений в процессе реализации цифрового конвейера.
Роли необходимо распределить между конкретными людьми, в соответствии с очерченными зонами ответственности и набором компетенций, сгруппировать людей (по функциональным направлениям, доменам, центрам компетенций и т.д.) и задать верную иерархию подчинения. На этом этапе важно показать, какие сотрудники должны постоянно быть в структуре трансформации, а кого можно привлекать эпизодически (на проекты), например, производственных экспертов или подрядные организации.
Для развития внутренних команд необходимы Центры компетенций (ЦК). Они могут быть техническими (например, по данным, разработке, data science, BI-аналитике и т.д.) или функциональными (например, по производству, логистике, финансам и т.д.). Лидер каждого Центра компетенций должен не только управлять развитием компетенций команды, но и распределять задачи исходя из уровня и опыта своих сотрудников.
У каждой команды должны быть метрики успеха.
Примером KPI технической команды может быть количество выпущенных цифровых продуктов, но подобные количественные показатели не всегда бывают информативны. Например, есть две команды разработки: одна выполняет за спринт 100 задач, другая — 50. Кто более эффективен? Важно оценить конечный результат. Возможно, у «медленной» команды продукт запущен и прижился, а у другой — вернулся на доработку или вовсе не взлетел.
Метрики важны и для оценки эффективности всего цифрового конвейера — не каждого отдельного продукта, а реализации всего набора инициатив. Например, у двух компаний есть цифровой конвейер: один конвейер выпускает 10 продуктов в год, а другой — 100. Какой конвейер лучше? При проработке КПЭ и метрик важно учитывать трудоемкость реализации продуктов, эффекты от их внедрения, возможности их масштабирования и приживаемость этих продуктов. Если реализованные 100 цифровых сервисов «пылятся на полке», то такой цифровой конвейер нельзя назвать эффективным.
Ещё одним примером КПЭ может быть четкое следование процессам — без пропусков и отклонений. Очень часто при запуске новой системы откладывают «на потом» разработку или актуализацию технологической документации и инструкций, а также информирование, инструктаж и обучение всех сотрудников, которым теперь придется взаимодействовать и работать по-новому.
Технологии
Для реализации процессов нужны инструменты — системы управления проектами, ведения документации и решения для совместной работы всей команды в едином виртуальном пространстве. До недавнего времени наиболее популярными решениями были Jira, Miro и Confluence. На сегодняшний день компании выбирают российские аналоги, например, вместо Jira — «Яндекс Трекер», EvaProject, Kaiten и YouGile, вместо Miro — «Эсборд», Pruffme и «МТС Линк», вместо Confluence — «Яндекс Вики», Teamly и Wiki.js. При выборе аналогов надо исходить из потребностей и ограничений конкретной команды/компании и выбирать инструменты с учетом их специфики.
Технологии могут значительно повысить эффективность операционных процессов. Автоматизация рутинных задач позволяет освободить время сотрудников для более стратегических и креативных задач.
Современные коммуникационные технологии (Zoom, MS Teams, Skype, VK Teams, «Яндекс Телемост» и др.) улучшают сотрудничество между командами, особенно в условиях удаленной работы. Это позволяет более эффективно выполнять поставленные задачи.
Также для удобства управления жизненным циклом инициатив не стоит забывать о возможности внедрения систем управления Stage Gate, которые позволяют принимать управленческие решения и планировать бюджет на основе детальной аналитики по портфелям инициатив.
Игнорирование технологий при проработке операционной модели может привести к утрате конкурентоспособности, снижению эффективности и упущенным возможностям для роста.
На что сделать фокус
При проектировании операционной модели цифрового конвейера важно обратить внимание на несколько важных особенностей.
Во-первых, как запустить воронку инициатив? Для этого нужно продумать мотивацию сотрудников — как стимулировать их выдвигать гипотезы и делиться идеями для наполнения воронки. Это может быть небольшая единоразовая премия за любую идею или более существенный бонус по итогам реализации успешной инициативы.
Также важно информировать людей о такой возможности, создавать среду, в которой сотрудникам комфортно делиться своими идеями. Кроме этого, воронкой нужно управлять — следить за статусом и продвижением идей. Важным аспектом постоянного функционирования воронки является повышение цифровой грамотности всех сотрудников компании — от генерального директора до рабочего в цехе. Только развитие цифровой грамотности позволит сотрудникам видеть новые возможности с учетом развития современных технологий.
Во-вторых, необходимо предусмотреть возможности для кроссфункционального взаимодействия команд разработки, поддержки и сопровождения. Это позволит выпускать продукты, которые органично и бесшовно будут встраиваться не только в ИТ-ландшафт предприятия, но и в общую операционную модель работы компании.
В-третьих, важно сквозное целеполагание — чтобы весь механизм цифрового конвейера работал на общий результат. На каждом этапе жизненного цикла инициативы нужно задавать вопрос: «Не уходит ли команда от той цели, которая определена в стратегии цифровизации и в целях самой инициативы?».
Например, если заявлена цель снижения участия человека в производственном процессе и рассматривается роботизация какого-то действия, то стоит обратить внимание на то, какими силами будет обслуживаться данный робот и не приведет ли его появление, наоборот, к повышению численности или увеличению количества требований к квалификации персонала.
Другой пример — приоритизация инициатив на этапе формирования дорожной карты реализации портфеля должна происходить с учетом потенциального эффекта от взаимодействия нескольких инициатив и соответствия этого эффекта конечной цели цифровой трансформации. Верхнеуровневая цель всех команд и каждого сотрудника — принести ценность компании. И все остальные цели должны быть подчинены именно ей.
И, конечно же, важно управлять изменениями. Это значит — адаптировать требования, задачи, сроки, бюджет и команду под обновленные вводные для разрабатываемого продукта — это может быть новое бизнес-требование, потребность в изменении смежного бизнес-процесса, изменение состава участников проектной команды и заинтересованных лиц и т.д. Правильный подход к управлению изменениями позволяет повысить приживаемость отдельных решений и увеличивает эффективность всего цифрового конвейера.
Операционная модель цифровых изменений — это скелет и мускулы всего организма цифровизации, поэтому требуется пристальное внимание, чтобы в нем не появилось перекосов.