Несколько последних лет показали очевидную необходимость в цифровых преобразованиях. Она вызвана тем, что подавляющее число пользователей «перебралось» в онлайн — там они читают новости, совершают покупки, играют, смотрят видеофильмы и т. д. Возникает вопрос: как компании строить бизнес, чтобы удовлетворять эти онлайн-потребности? Руководитель группы технических консультантов GlobalLogic Джо Уэлш полагает, что на этот вопрос есть только один ответ: программно-центрическая (software-centric) модель бизнеса. «Что такое эффект Интернета? Это когда ваши клиенты живут в онлайне — новой виртуальной реальности, поэтому там самое место и для вашего бизнеса», — пишет он в блоге компании.
По его словам, сам рынок подвел почву под эту модель: стоимость входного билета в бизнес снизили мощные технологии с открытым исходным кодом, а также публичные и частные облачные провайдеры. Последние в разы сократили необходимость в капитальных инвестициях. Известно, что новые условия порождают новые возможности, поэтому не стоит забывать, что к разделу пирога будет много охочих. Возьмем, к примеру, Uber или Airbnb — это яркие представители software-centric, но подобными путями двигаются не только софт-ориентированные компании, но и производственные и медицинские фирмы, банки, страховщики и др.
Каждой компании, которая встает на рельсы цифровизации, предстоит пройти нелегкий путь. Уэлш дает 12 советов, которые помогут новичкам сгладить острые углы.
1. Не накапливайте «технологические долги». Характерна ситуация, когда та или иная компания вынуждена обслуживать несколько программных продуктов, в случае больших предприятий — это десятки систем, включая ERP, CRM, EMM и др. Чтобы поддерживать их на плаву, инженерам приходится устанавливать патчи безопасности, обновления. Эти процедуры чреваты различного рода сложностями, знакомыми каждому администратору, — выходом из строя сети, системными сбоями, «зависаниями», поэтому требуется время на отладку или тестирование софта. Если он пишется собственными инженерами компании, то не исключено, что для приведения его в работоспособный вид потребуется процедура рефакторинга (перепроектирование кода, дизайна или архитектурного решения без изменения его бизнес-функциональности).
Известно, что после рефакторинга нужно убедиться в том, что поведение софта не изменилось и все работает как раньше. Для этого нужны тесты, которые на предприятиях часто игнорируют. Это происходит под давлением отделов маркетинга — они не готовы мириться с проволочками, ожидая от инженеров немедленной состыковки предложенных ими идей с уже имеющимся софтом. Идя на поводу маркетологов, компания накапливает т. н. «технологический долг». Уэлш советует искоренить подобную практику, потому что со временем ошибки будут расти экспоненциально. Для исправления ситуации потребуется ввести постоянный мониторинг качества кода и проводить тесты в модульном репозитории без оглядки на чьи-либо желания.
2. Цифровая трансформация без идеи не имеет смысла. GlobalLogic при консультировании клиентов практикует следующий эксперимент. Собравшися в комнате для совещаний инженерам клиента должны ответить на вопрос: какой бы софт они выбрали, если бы покинули текущее место работы и основали стартап? В подавляющем большинстве случаев в качестве эталона приводится системная архитектура следующего поколения, которая проще, быстрее и дешевле в разработке, чем та с которой инженерам приходится иметь дело. Задумка эксперимента — взглянуть на вещи с неожиданной стороны.
Предполагается, что организация будет постепенно расти и развиваться, допускать ошибки и по мере возможности исправлять их. На деле все по-другому: есть ошибки, которые бизнес не прощает — безыдейность. На рыночном поле возникает множество стартапов, которые не привязаны ни к софту, ни к клиентам. Spotify, Netflix — примеры того, как быстро из вооруженных идеей стартапов вырастают мультимиллиардные корпорации, сметая на своем пути благополучные бизнесы. Принимаясь за цифровое преобразование, берите пример с них, советует эксперт.
Ссылаясь на свой опыт, он говорит, что в ходе реализации проекта трансформации у его клиентов практически всегда появляются новые идеи и открываются дополнительные возможности для бизнеса, причем происходит все это спонтанно. Главное — начать.
3. Выбирайте лидирующие Open Source-технологии. Не стоит метаться между десятками программных продуктов, затрачивая на это месяцы (именно столько выбирал между двумя самыми известными технологиями контейнеризации один клиент GlobalLogic) — на это должно хватить несколько дней или даже часов и тому есть разумное объяснение: в большинстве случаем выбор сводится к ведущим технологиям с открытым кодом. Что касается блокчейн, то это Hyperledger и Ethereum, для крупномасштабной контейнерной оркестровки — Kubernetes и Docker, если выбор стоит между PaaS-платформами, то это Cloud Foundry или OpenShift.
Выбор зависит от целей организации, но помимо него нужно учитывать и другие моменты: насколько сплоченное сообщество поддерживает проект и готово ли оно оказать техподдержку; неплохо проследить, как та или иная Open Source-технология принимается рынком. Впрочем, выбор почти любого крупного открытого проекта не должен вызывать опасений — обычно его поддерживают ИТ-гиганты и все необходимые изменения в продукте появляются довольно оперативно.
4. Поставьте себя на место клиента. Некоторые ошибочно полагают, что цифровизация — это чисто техническое решение, но компания, которая, например, пишет софт для мобильных платформ, должна рассуждать более конструктивно, поставив себя на место клиента. На эту роль можно задействовать самих разработчиков, но работающих над другими проектами: программисты, разрабатывающие платформенные сервисы, веб-клиенты и мобильные приложения являются «клиентами» API-разработчиков и поэтому могут заняться оценкой удобства API, тогда как API-разработчики могут оценить качество базовых систем API, платформенных и микросервисов и так вплоть до микрокода.
Уэлш приводит случай с одним из его клиентов. Тот работал над портфельным проектом для переоснащения частично устаревшей программной платформы, но то, что должно было вылиться в незначительный объем работ, превратилось в настоящий квест. Чтобы выяснить, какие типы объектов поддерживает система, разработчику пришлось прибегнуть к обратному реинжинирингу: выяснять на каждом этапе разборки кода, какие типы объектов система поддерживает, находить индивидуальные вызовы для каждого из пользователей, определять атрибуты для всех типов данных, и только затем ему удалось эти объекты извлечь. Компании пришлось столкнуться с такими сложностями, потому что ее устаревшая система разрабатывалась несколькими инженерами и они не мыслили категориями удобства для клиентов-программистов, а наслаивая код слой за слоем, занимались решением технических задач. Вместо этого им следовало бы добавить в API системные вызовы createAssetType, getAssetTypeList, CRUD Asset — это бы значительно упростило разбор кода.
5. Качество продукта определяется скоростью внедрения новых функций. Одно из основных отличий между компаниями, которые еще не встали на путь преобразований от тех, которые уже освоили этот процесс, — методология разработки продукта или ПО, используемого для последовательного управления бизнесом и доходами компании. И если первые думают о нем как о проекте, который рано или поздно нужно будет завершить, то вторые — постоянно совершенствуют его. Собственно, этот принцип положен в основание методики Agile-разработки. Продукт разрабатывается на протяжении многих лет, у него есть дорожная карта для внедрения базовых конфигураций, проведения плановых работ, но настоящее испытание начинается тогда, когда дорожную карту нужно адаптировать под требования клиента.
Чтобы избежать нестыковок, лучше всего доверить поддержку и интеграцию вашей основной системы с клиентской отдельной команде, которая будет осуществлять конфигурирование и поддержку клиента по требованию (через плагины или другие каналы) и, скорее всего, делать это часто и максимально быстро. Уэлш считает, что компаниям, стремящимся войти в эру цифровых технологий, следует воспринимать свое ПО не как периферийную вспомогательную инфраструктуру, а как ключевой элемент бизнеса.
6. Документируйте переход на цифровые рельсы. Отчеты о состоянии системы, отслеживание дефектов и прогресса, автоматизация сборки и развертывания, платформы автоматизации тестирования, мониторинг производительности системы и т. д. — это те контрольные функции, которыми компании часто пренебрегают. Стоит помнить, что не отработанные должным образом элементы контроля уже похоронили не одну крупную инициативу.
7. Цифровая трансформация может быть краткосрочной, но она должна быть последовательной. Как правило, частные или публичные компании проводят цифровизацию в сжатые сроки, тогда как семейный и венчурный бизнес выбирает долгосрочные инициативы. Понятно, что быстрые стратегии трансформации реализуются в сжатые сроки (но профилируются по рискам), здесь важно другое — независимо от выбора модели развертывания она должна быть последовательной, иначе предприятие рискует оказаться в сложной ситуации.
8. Трансформация должна проходить прозрачно. Любой процесс, кардинально меняющий привычные условия, связан с неизбежным риском, и цифровая трансформация — не исключение. Учитывая, что в ней принимают участие многие отделы, это часто рождает дискуссии по поводу распределения обязанностей. Наиболее эффективная стратегия, которая поможет определить роли каждого участника коллектива, — прозрачность принятия решений. Трансформация — это своего рода творческий процесс, поэтому имеет смысл прислушиваться к мнению критиков. Однако стоит помнить, что чрезмерное внимание к нему часто может использоваться в качестве предлога, чтобы избежать изменений.
Эксперт называет несколько причин, которые тормозят цифровое развертывание. В первую очередь это касается опасений сотрудников или отдельных топ-менеджеров, которые боятся потерять свою значимость или должность, других пугает неопределенность ситуации, тогда как третьи развивают кипучую деятельность там, где ей не место. Всегда найдется небольшой контингент, желающий пожертвовать долгосрочными интересами компании в целях личных выгод. Может возникнуть вопрос: зачем руководству компании идти на какие-то ухищрения и завязывать дискуссии с подчиненными?
Дело в том, что даже директивный стиль управления не является гарантией успешной трансформации. Руководству лучше объяснить сотрудникам, какие действия оно готово предпринять и чего ждет от коллектива. В этом случае оно сможет рассчитывать на отдачу, а не следование «линии партии».
9. Есть сомнения, как правильно «оцифроваться»? Наймите консультантов. Многие компании не рискуют приступать к изменениям без помощи консультантов. Этот подход может оправдать себя, поскольку профессионалам со стороны лучше видны точки соприкосновения, прогресс (или регресс). Говоря о роли коучера, Уэлш приводит аналогию с инструктором по лыжному катанию — теорию можно изучать до бесконечности, но для того, чтобы овладеть практическими навыками, нужно несколько раз съехать с холма.
В качестве других преимуществ задействования сторонней помощи называются снижение рисков, сокращение времени, уменьшение долгосрочных затрат, наставничество и руководство для сотрудников. В конце концов, если фирмы при цифровизации ставят на карту судьбу бизнеса, почему бы эту ответственность не разделить с кем-либо еще?
10. Иногда нужно отступать. Уэлш выделяет несколько признаков, которые указывают, что затея с цифровым преобразованием или затухает, или не удалась. Об этом говорит угасший энтузиазм сотрудников. Лучший выход в этой ситуации — дать им несколько недель на отдых, вернувшись в привычную среду, затем возобновить усилия по трансформации. В практике Уэлша бывали случаи, когда ему приходилось отступать под натиском «оппозиции» — иногда по конструктивным соображениям (компания была не готова к трансформации), иногда сталкиваясь с откровенным саботажем.
11. Кризис цифровой трансформации — не помеха. Парадоксально, но отдельные компании запускали трансформацию в ответ на неблагоприятную ситуацию с бизнесом будь то давление конкурентов или необратимые изменения в рыночном секторе. Так или иначе, но паника — не лучший советчик и нужно запастись терпением, чтобы изменения начали приносить плоды — поэтапные изменения могут занять от нескольких месяцев (для небольших фирм) до
Важно вообще не поддаваться панике, говорит эксперт. По его словам, в мировой практике неоднократно бывали случаи, когда компании выводили на рынок продукт спустя несколько месяцев или даже лет после конкурентов, но опора на лояльную клиентскую базу, бренд оставляла конкурентов «с носом». Ярким примером, конечно же, является Apple. В конце
Упредить кризис поможет понимание, что обычно разработка программного продукта — пускай даже при помощи прогрессивных методик Agile или Lean — требует больше времени, чем изначально предполагается. При этом проблема может быть совершенно не связанной с самим ПО, а с финансированием проектов, анализом требований, пересмотром нормативных документов, зависимостью от третьих сторон и т. д. После долгих лет практики Уэлш пришел к выводу, что форс-мажор — это природа сложных систем, и это нужно воспринимать как должное.
12. План успеха — поэтапная реализация проекта. Самый важный совет из всех — нужно верить в собственный план трансформации. И, как уже говорилось, к изменениям не нужно приступать с шашкой наголо, они должны быть плановыми, чтобы можно было оценить их экономическую эффективность. Для реализации изменений на операционном уровне необходимо создать кросс-функциональную команду, состоящую из сотрудников подразделений, которые отвечают за отдельные аспекты процесса.
Нередко для этого формируется отдельный центр компетенций, состоящий из сотрудников различного профиля, — проектировщики клиентского опыта и дизайнеры, маркетологи, представители ИТ и т. д. Важно, чтобы члены этой команды были открыты новым идеям, обладали требуемыми навыками и не боялись экспериментировать. Подобный центр может функционировать на регулярной основе, транслируя лучшие практики внутри компании.
