Место цифровой трансформации — у вас в голове

В докладах о цифровой экономике и цифровой трансформации чаще всего говорят о том, как применение информационных технологий может ускорить развитие бизнеса. Это не удивительно — если взглянуть в Википедию, можно прочитать следующее:

«Цифровая трансформация — это трансформация бизнеса путем пересмотра принятия цифровых технологий, что влечёт за собой пересмотр бизнес-стратегии, моделей, операций, продуктов, маркетингового подхода. Она призвана ускорить продажи и рост бизнеса».

Предполагается, что причиной это роста станет именно применение цифровых технологий. «Мы поставим программу А, применим технологию Б и будем управлять компанией по-новому!» Но, как нам кажется, цифровая трансформация так не работает.

Сегодня, в День знаний, мы хотим сжато изложить своё видение того, как же должна работать цифровая трансформация: маленький урок внеклассного чтения.

Оффлайн и онлайн: сравниваем траектории развития

Если для компании-ритейлера из оффлайнового мира попробовать новую линейку товаров означает проработать линейку, выпустить продукцию, разработать ценообразование и доставить эту продукцию по магазинам, подождать и выяснить результаты продаж, то для IT-компании, чтобы проверить новую линейку программного обеспечения, достаточно создать демо-версию этого ПО, лендинг, попробовать закупить рекламу на нужную аудиторию и уже на основании результатов — принять решение об инвестициях в новое направление.

Означает ли это, что оффлайн обречен на методы развития бизнеса прошлого? Не обязательно. Как и не означает это того, что для существенных изменений ему обязательно надо применять информационные технологии. Главные изменения, которые должны произойти, — изменения в понимании организациями своих подходов к развитию бизнеса.

Возвращаясь к IT-бизнесу: постоянное развитие и изменение информационных технологий привело к тому, что он сам был вынужден так же динамически развиваться. Мало того, ряд идей и концепций, которые пришли в IT, изначально появились не в IT. Принципы популярных в последние годы Agile и гибких методологий (популярных даже в больших организациях) родом из принципов бережливого производства в японской промышленности.

Но один методологический подход возник именно в IT — и его можно применить и в других видах бизнеса. Это DevOps.

«И это всё о нём»: несколько слов про DevOps

Попытаемся сформулировать кратко: если гибкие методологии говорят о разработке программного обеспечения, то DevOps говорит о доставке программного обеспечения. Что это значит?

В 1995 году, чтобы организовать продажи Windows 95, компании Microsoft приходилось организовать производство дискет и компакт-дисков, упаковки, обеспечить дистрибуцию операционной системы по всему миру — это огромная работа. При этом любая ошибка в создаваемом тогда ПО практически фатальна — ее исправление требовало прохождения той же цепочки: чтобы «доставить» исправление бага до конечного пользователя, нужно было разработать исправление этого бага, проверить, что он гарантированно ничего не сломает, организовать производство и распространение носителей с исправлением.

С развитием интернета доставка программного обеспечения упростилась: фактически, у нас есть «сервер», один «клиент», на который надо «доставить» ПО. Теперь IT-бизнесу значительно проще управлять всем процессом доставки, и вместо многих месяцев код обновляется за минуты. Что это означает? — Что компаниям теперь можно рисковать для проведения экспериментов: при наличии надежной системы доставки ПО можно снизить время на контроль качества — в случае ошибки просто «откатим» изменения ДО выкладки новой версии. Можно пробовать на потребителях новые методы маркетинга и предлагать новые функции, а если они им не понравятся — опять же, быстро сворачивать эксперименты. Главное — в IT-компаниях изменилось мышление: вместо детальной многолетней проработки нового продукта стало возможным быстро и дешево проверять гипотезы и либо развивать их, либо быстро от них отказываться. Таким образом, развитие информационных технологий снижает цену ошибки в результате эксперимента — и это в текущих реалиях самое важное для бизнеса.

Но технологии производства, технологии маркетинга тоже не стоят на месте — и не только в IT. Организовать рекламную кампанию стало предельно просто, и для этого больше не нужно нанимать специализированное агентство. А благодаря глобализации организовать даже высокотехнологическое производство становится несложно. Мы можем найти проектировщиков в Европе, а само производство минимальным тиражом организовать в Китае. Мы можем проверять гипотезы на цифровых моделях. Цена ошибки также снижена.

Краткий курс счастливых изменений

Так что в основах DevOps можно применить для бизнеса в целом?

Метрики изменения компании как основа изменений. В основе любых изменений должны быть понятные метрики, на которые можно ориентироваться для анализа прогресса. В основе анализа DevOps-трансформации обычно лежат следующие параметры:

  • частота релизов (как часто мы выкладываем новые функции), для оффлайн-компаний — частота новых экспериментов, запуска новых продуктов, проверки новых гипотез;
  • среднее время для внедрения новых изменений (как быстро после проработки мы можем "доставить" новую функцию для пользователей);
  • среднее время для восстановления в случае аварии; для оффлайн-компаний — как быстро мы можем отменить проведение эксперимента;
  • частота ошибок во время изменений — несколько исследований приходят к выводам, что чем реже компания меняется (частота релизов), тем чаще изменение приводит к возникновению проблем. Компания, которая меняется каждый день, меньше подвержена проблемам в момент изменений, чем компания, которая подготавливалась к изменению целый год.

Кросс-функциональные командные практики. Долгая основательная проработка продукта представляла собой «водопадную» модель работы — когда сначала группа разработчиков разрабатывает продукт, затем это передается в отдел тестирования, затем в отдел безопасности и затем людям, отвечающим за доставку ПО. На последнем этапе могло вполне оказаться так, что решения, принятые в начале разработки продукта, неприменимы для доставки продукта — и всё надо начинать заново. Само понятие DevOps возникло из идеи объединить Development (разработка) и Operations (эксплуатация) — двух групп, существовавших всегда раздельно, в один взаимодействующий коллектив на ранних этапах разработки продукта. Это сходно с идеей проектной группы, главным принципом которой является не передача продукта от одной группы профессионалов к другой, а совместная работа небольшой кросс-функциональной команды с самого начала. К примеру, для разработки новой услуги юридической компании в такую группу имеет смысл объединить маркетолога, юриста, представителя бизнеса и менеджера продаж — чтобы менеджер продаж смог ограничить продукт рамками спроса и помог сформулировать предложение маркетингу, маркетинг понимал бы, про что продукт, бизнес передавал бы видение по продукту в целом, а юристы объясняли, возможно вообще такую услугу запустить или нет.

Технологии в основе производства. Современные технологии дают возможность максимально быстро изменяться компаниям и пробовать новые эксперименты. И вот только здесь стоит говорить о цифровизации как об использовании программного обеспечения — исходить необходимо из задачи изменить компанию, чтобы потом понять, какие доступные технологии есть в её распоряжении для того, чтобы поддержать это изменение.

Резильентность и обеспечение безопасной культуры. Постоянные изменения создают риск выгорания сотрудников и небезопасное окружение. Поскольку именно люди меняют компанию — риск потерять людей, помимо этических проблем, означает потерю возможностей развития. Поэтому, даже исходя из «капиталистических» принципов, предлагается пересмотреть подходы к пониманию «человеческой ошибки». Человек, который ожидает наказания за ошибку (а они, так или иначе, случатся), проявит меньше инициативы к экспериментам, меньше инициативы доносить идеи. Задача бизнеса состоит в том, чтобы обеспечить "жизнеспособность компании": как организм стремится к самоизлечению, так и культура компании должна предполагать гибкость и дальнейшую устойчивость организации к повторяющимся ошибкам.

Урок окончен, или вместо вывода

Основой изменений в компании должны стать изменения мышления — и только лишь потом, по «ТЗ на изменение мышления», должны подбираться решения в области информационных технологий.

0
Комментарии
-3 комментариев
Раскрывать всегда