Относительно недавно вышёл фреймворк Digital Practitioner Body of Knowledge. Эта работа освещает крайне актуальную тему — запуск цифрового продукта и бизнеса. Моя статья — краткий обзор этого материала. В нём упоминаются популярные техники, которые применяются в различных аспектах деятельности цифрового предприятия.
По DPMBoK я готовил внутренний методологический материал. По-моему, этой весной всем стало понятно, что сегодня почти не осталось бизнеса, которому не требуется осуществить цифровую трансформацию, а данный пост может ввести в курс дела всех интересующихся этой темой или открыть интересную дискуссию в комментариях.
Источник
Любое предприятие, имеющее в своей основе элементы цифрового бизнеса (цифрового продукта или услуги, платформы, экосистемы) в процессе роста сталкивается с моментами необоснованного с точки зрения «классического» менеджмента замедления или отсутствия планируемой экспансии. Эти моменты могут быть обусловлены множеством факторов (препятствий, ограничений): внешних или внутренних, технических или организационных, решаемых или, на первый взгляд, непреодолимых. Некоторые препятствия типичны для отдельной отрасли, где можно попробовать найти решения. А могут возникать ограничения, не имеющие привязки к бизнес-модели или отрасли. Объяснение подобной ситуации заключается в том, что цифровые продукты, имеющие значительную ИТ-составляющую, являются социально-техническими системами, обладающими высокой комплексностью. Это означает, что небольшие изменения в их компонентах или взаимодействиях могут существенно повлиять на их общее поведение и ценность.
Самое неприятное, что такие ограничения сродни зубной боли – узнали бы раньше, не пришлось бы сверлить или удалять. Пытаться делать диагностику своего предприятия с помощью интернет-форумов, профессиональных площадок зачастую действенный, но весьма трудозатратный способ. Обратиться к профессиональным консультантам и экспертам — дело хорошее и, скорее всего, правильное. Но в этом случае хорошо уже «быть в теме» или предварительно подготовиться, изучив чужой опыт.
Мы с коллегами в центре стратегического развития и цифровой трансформации (он действует в компании «ЛАНИТ-Интеграция») занимаемся проблематикой создания и деятельности цифровых предприятий и уже давно сформировали методологическую основу наших консультационных проектов. Тем не менее, мы были приятно удивлены комплиментарностью и полнотой данного свода знаний. Чтение современной бизнес-литературы на сегодняшний день занятие часто неблагодарное – материалов слишком много, найти то, что нужно, тяжело. Отдельные издания, смысл которых можно сформулировать в восьми строках текста, на 95% процентов наполнены историческими и персональными экскурсами, изложенными в виде эссе (как и данный текст).
Многие издания имеют фокус на отдельных проблемах создания цифрового продукта, командного взаимодействия или на решении технических вызовов.
Долгое время на рынке не присутствовало изданий, охватывающих все аспекты существования цифрового предприятия. Но, как говорится, «свято место пусто не бывает», и в середине 2019 года группа авторов The Open Group представила первую версию свода знаний цифрового практика Digital Practitioner Body of Knowledge, куда постаралась уместить все актуальные подходы к решению наиболее типовых и значимых вызовов, возникающих перед владельцами и сотрудниками цифрового предприятия.
Свод представляет собой не просто онтологию методик и терминов, а последовательно изложенный путь цифрового предприятия, с раскрытием практического опыта применения описываемого инструментария реальными командами и компаниями.
Сам свод доступен в двух форматах:
- интернет-портал (будет удобен тем, кому тяжело знакомиться с материалом на английском и можно воспользоваться функцией перевода браузера, но лучше параллельно знакомиться с оригиналом),
- pdf-версия, доступная для скачивания после регистрации.
Кстати, наличие портала – не прихоть The Open Group. Один из принципов, который авторы заложили в основу DPBoK, гласит: «Сам свод знаний должен существовать и развиваться как цифровой продукт. У разработчиков должно быть четкое понимание структуры аудитории, эффективности каналов доставки, сама разработка должна осуществляться в определенном темпе, а содержание изменяться благодаря обратной связи и взаимодействию с аудиторией».
Свод состоит из шести разделов, первые пять из которых, по сути, вступительные. Они раскрывают причины и цели создания, а также содержат руководство по применению.
Авторы приводят достаточно понятные аргументы, почему наступление цифровизации заставляет компании переосмыслить собственные бизнес-модели и стратегии.
Многие элементы свода построены на ранее созданных материалах The Open Group. Одним из ключевых материалов является принцип семи рычагов изменения организации – базовых элементов, необходимых для построения цифрового предприятия:
- трансформация бизнес-процессов;
- клиентский опыт и взаимодействие;
- цифровая трансформация продукта;
- трансформация ИТ и процессов реализации продукта;
- организационная культура;
- стратегия;
- экосистема и бизнес-модель.
Забегая вперед, стоит отметить, что DPBoK содержит множество ссылок на другие наиболее известные стандарты и своды знаний, что подчеркивает нежелание авторов изобретать колесо для каждой изложенной проблемы, сохранив при этом полноту и охват.
Авторы отмечают, что на практике современные методы создания цифрового продукта не должны противопоставляться классическим. Любой проверенный временем и сообществом инструментарий может быть полезен в определенный период времени на соответствующем масштабе предприятия.
Шестая, она же основная и самая объемная часть свода знаний построена по схеме масштабирования цифрового предприятия: от задач основателя стартапа к проблемам цифровых компаний.
Каждый из этапов, в которых оказывается цифровое предприятие, содержит разделы знаний наиболее актуальных проблематик и подходов к их решению.
| Устойчивое предприятие | Архитектурный подход |
| Управление информацией | |
| Руководство, управление рисками, информационная безопасность, соответствие требованиям регуляторов | |
| Команда команд | Культура и организация |
| Финансирование продуктовый портфель | |
| Процессный подход и управление | |
| Команда | Управление техническими операциями |
| Управление работами | |
| Управление продуктами | |
| Основатель | Доставка приложений |
| Инфраструктура цифрового продукта | |
| Основы цифровых продуктов |
Первый контекст («Основатель») представляет базовый набор знаний и навыков, необходимых для создания цифрового продукта. В значительной части изложенный материал согласуется с Lean startup принципами: генерацией идей, сбором и тестированием гипотез, пользовательской обратной связью, созданием цикла plan-build-run. В разделе «Цифровые основы» приведена схема, которая будет крайне полезна для понимания механизмов создания ценности для клиента, в том числе концепция жизненного цикла цифрового продукта (идея > инвестирование > разработка > изменение > доставка > использование > поддержка > восстановление > улучшение / вывод).
В контексте приведены актуальные способы организации технической инфраструктуры, необходимой для запуска цифрового продукта, включая вопросы виртуализации, использование облачной и гибридной инфраструктуры, контейнеров и механизмов Infrastructure as Code.
На десерт данный контекст предлагает ознакомиться с инструментарием agile-разработки и доставки приложений. Навряд ли постоянные читатели Хабра найдут здесь что-то новое, хотя исторический экскурс в причины развития итерационных моделей разработки и DevOps может оказаться полезным.
Второй контекст содержит набор методик и инструментов, необходимых для эффективной работы небольших команд, создающих свой продукт, включая управление продуктом, работами и операциями («инфраструктурщиков» не забыли).
С момента прихода тотальной мобильности стало понятно, что командам, сфокусированным на технической части создания продукта, необходимо иметь компетенции по управлению его потребительской ценностью. Понимание рынка, постоянный поиск потребности пользователей и реакция на обратную связь важны не меньше, чем реализация и доставка продукта.
Данным вопросам посвящён раздел основ управления продуктом. Здесь можно найти множество полезных методик. Например, DIBB-модель, выстроенная по цепочке «данные > понимание > убежденность > ставка» покажет важность механизма проверки гипотез. Также полезно будет ознакомиться с подходом к исследованию продуктов Jobs-to-be-Done и концепцией Design Thinking.
Источник: Jobs-to-be-Done
Авторы свода не обошли стороной и классические подходы, связанные с выявлением требований к будущему продукту, которые были сформулированы в другом специализированном своде знаний BABoK.
Несмотря на общую приверженность бережливым методам разработки продукта, авторы указывают и на существующие ограничения в применимости данных методов. Не все продукты являются социальными сетями (flowers), в которых отлично работает A/B-тестирование. Все еще велика доля продуктов, построенных по канонам системной инженерии (cogs), которым нужна проработка требований.
Логичным продолжением вопроса разработки продукта является тема управления работами: тот момент, когда ваш продукт начинает требовать выполнения разноплановых, но связанных между собою задач.
Здесь авторы DPBoK осуществили важное действие — привели объяснение взаимосвязи продуктовых понятий с понятиями разработки всех актуальных agile и lean-методик: определение понятия «done», управление очередями задач, снижение «незавершенки», приоритизация задач на основе показателя стоимости отставания (финансовая сторона которого может быть полезна как инженерам, так и продуктологам) и т. д.
Не менее ценным материалом является раздел бережливой разработки продуктов. Извечное мнение программистов, что «разработка – это творческий процесс, чьи временные рамки определить нельзя», нашло свое опровержение в подходе Lean Product and Process Development — наборе эффективных методов, помогающих не терять ценное время на всех этапах разработки, построить прозрачный и предсказуемый процесс. Многие из методик проистекают из опыта японской автомобильной промышленности, прошедшего проверку временем и рынком.
Касательно «операций» (можно сказать «службы эксплуатации инфраструктуры», правда, такой перевод не полностью отразит смысла термина operations), второй контекст не только дает определение, но и описывает взаимосвязь «операций» с жизненным циклом продукта и пользовательским опытом. Также здесь дано определение понятию уровня сервиса, системных конфигураций, конвейера сред и телеметрии. Все это изложено языком, понятным человеку, далекому от системного администрирования, и может послужить подспорьем в создании целостного видения цифрового продукта.
Полезность ознакомления с принципами технического масштабирования (CAP и AKF) тяжело переоценить: будучи поглощенными процессами разработки и реализации продукта, в определенный момент вы можете оказаться весьма озадаченными вопросом нагрузки систем.
Переходя к третьему контексту «Команды команд», хотелось бы отметить, что данный уровень свойственен всего лишь нескольким десяткам находящихся на слуху отечественных компаний. Но несмотря на амбициозность контекста, его содержание будет полезно для специалистов и предпринимателей, которые начали задумываться о развитии не только отдельного цифрового продукта, но предприятия в целом.
На данном этапе на первое место еще в большей степени претендуют процессы координации команд, управления финансами, а также вопросы культурного и организационного характера. По сути можно сказать, что это основные вопросы управления не только цифрового предприятия, но и классического менеджмента. Невозможно обойти стороной работы Фредерика Тейлора, Эдварда Деминга, Питера Друкера и других ученых-практиков в области организации труда. Но в данном случае авторы The Open Group не мучают читателя длинными исследованиями, а приводят компактное и логичное объяснение значимости научной организации труда на успешность цифрового предприятия.
Введение в финансовые аспекты не помешает никому. Авторы не ставят финансовую составляющую на передний план. Да, коммерческие предприятия должны приносить прибыль своим владельцам. Но это правило не идет вразрез с видением и развитием цифровых продуктов.
Планирование затрат, принятие решений на основе оптимальных требований, способы привлечения инвестиций, ценообразование, а также приобретение внешних сервисов и услуг, – все это не праздные вопросы, они требуют понимания и подходов к решению.
В данном разделе достаточно часто фигурирует один из наиболее известных подходов масштабируемого Agile – SAFe, который сам заслуживает целой серии статей и где целеполагание и определение работ основано на финансовой эффективности.
Организационный раздел контекста построен в следующем порядке: от организационных структур и их заполнения в процессе найма до самых сложных вопросов организационной культуры.
Четвертый контекст, по сути, описывает актуальную проблематику существования высшей лиги цифровых предприятий: Яндекс, Google, Facebook. Значит ли это, что данный раздел не содержит ценности для организаций меньшего масштаба? Ни в коем случае! Все дело в том, что предприятия данного масштаба уже не существуют как изолированные системы. Они предоставляют площадки и экосистемы для развития других цифровых предприятий. Ознакомившись с контекстом «Устойчивого предприятия» вы сможете понять (и простить) требования «крупняка» которые вы ранее считали прихотью и бюрократией, адаптировать свои ожидания к ним и наладить более продуктивное взаимодействие.
Так почему же все-таки стоит ознакомиться с DPBoK
Во-первых, это красиво. Во-вторых, DPBoK предоставляет понятную и ценную выжимку знаний, связанных с созданием и ростом цифрового предприятия, к которым можно оперативно обратиться для решения возникающих вызовов. И, в-третьих, вы получаете набор лучших референсов на актуальные хорошие практики, с полезными выводами и необходимыми историческими справками, дающими более полное понимание настоящего момента.
Надеюсь, данный материал окажется полезным на пути создания вашего цифрового предприятия. Если у вас появятся вопросы, буду рад ответить на них в комментариях.
Автор: YALC
