Для того чтобы способствовать цифровой трансформации бизнеса, корпоративные ИТ-структуры должны изменить и свой подход к работе, и методы взаимодействия с внутренним заказчиком. О том, как ИТ-службам начать трансформацию с себя, рассказывает Олег Скрынник, управляющий партнер компании Cleverics, одного из партнеров предстоящего форума IT Management Forum 2017, который издательство «Открытые системы» проведет 25 мая.

— В последнее время много говорится о цифровой трансформации бизнеса, но мало — о том, как должен при этом меняться стиль работы корпоративных ИТ-структур…

Безусловно, изменения в управлении информационными технологиями необходимы, чтобы поддержать бизнес-трансформацию. Одно из средств для этого — набор практик DevOps. Еще буквально год-два назад у большинства ИТ-специалистов и менеджеров не было четкого понимания, что же это такое и зачем нужно. При том что само движение зародилось лет пять-шесть назад, только сейчас этот набор практик находит свое применение. В 2016–2017 годах в вопросе «Что такое DevOps?» наконец наступает ясность. Ограниченные точки зрения, например: DevOps — это про автоматизацию конвейера поставки ПО, сменяются более общей концепцией: DevOps — логическое развитие идей гибкой разработки ПО и бережливого производства, примененное к полной цепочке создания ценности и позволяющее добиваться большего от современных информационных технологий посредством культурных, организационных и инструментальных изменений.

Олег Скрынник считает цифровую трансформацию бизнеса невозможной без обновления методов управления ИТ-подразделениями

 

— Почему идеи DevOps стали популярны именно сейчас?

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

В компании возникает существенное противоречие: с одной стороны, она настраивает процесс разработки так, чтобы быстро получать новые релизы своих информационных систем, усовершенствования, новые функции. А с другой — имеется сопротивление подразделений эксплуатации, которые считают, что изменение — зло, и если инфраструктура работает, то ее лучше лишний раз не трогать. И если каждые две недели или, не дай бог, каждый день выкатывать новые релизы и изменения, то стабильного функционирования инфраструктуры не добиться. Риски что-то испортить достаточно высоки. Поэтому вы, разработчики, готовьте код каждые две недели, но разворачивать его давайте, как раньше новые релизы, раз в квартал… То есть значительное «ускорение» разработки программного обеспечения дает весьма скромный результат, если смотреть на общую длину цикла «от идеи до бизнес-результата».

Назрела необходимость «продолжить» методологию Agile в область эксплуатации, чтобы она вписалась в общую цепочку, а не была сама по себе. Я сейчас использую термин Agile в широком смысле — как синоним быстрого и современного способа разработки программных систем. Это первое.

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

К слову, термин «облако» тоже появился давно, и действительно доступные надежные облачные технологии существуют уже лет пять. Но «сошлось» все недавно, и ключом к изменению стала доступная возможность управлять инфраструктурой как программным кодом. То есть инженеры ИТ могут с помощью условного скрипта «создать» всю необходимую инфраструктуру, включая серверное и сетевое хозяйство, системы хранения данных и т. д. Это дает возможность совершенно иначе строить эксплуатацию ИТ.

— Но мы пока говорим только про изменения в работе ИТ-подразделения?

Значительные изменения в ИТ-отделах, как правило, не делаются ради самих ИТ-отделов. ИТ работают для бизнеса.

Я считаю, что описанный выше подход является ключом к цифровой трансформации бизнеса, которая на практике означает весьма существенное изменение отношения как бизнес-структур, так и ИТ-отделов к качественным и количественным результатам применения информационных технологий.

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

 

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

На качественном уровне бизнес получает новые инструменты взаимодействия с клиентами, маркетинга, продаж, предоставления услуг и монетизации. На количественном уровне бизнес получает ИТ-продукты, создаваемые со скоростью движения бизнеса (необходимый бизнесу и очень быстрый time-to-market), а также ИТ-продукты, обладающие большей стабильностью и доступностью по сравнению с традиционными системами.

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

— Есть ли сопротивление «трансформации через DevOps» со стороны бизнес-подразделений?

Думаю, правильнее говорить не о сопротивлении бизнеса, а о непонимании, что именно и как менять. Путь цифровой трансформации не выглядит простым. Во-первых, мало кто может толком рассказать, как по нему пройти, что связано с очень небольшим пока числом первопроходцев. Во-вторых, трансформация очень сильно затрагивает ключевые постулаты, на которые опиралось построение управления как информационными технологиями, так и бизнесом в последние 15–20 лет. В-третьих, цифровая трансформация ИТ отдельно от бизнеса, похоже, имеет не много смысла.

— Возможна и обратная ситуация: бизнес распробует прелесть быстрых изменений и начнет заваливать разработчиков заказами, руководствуясь соображением «отчего бы не попробовать»…

Ответ простой: пожалуйста, заказывайте, но помните, ресурс как был, так и остается ограничен, нужно понимать, что каждую задачу все равно придется сравнить с другой задачей и одну из них пустить вперед, а другую — поставить в очередь. Вопрос расстановки приоритетов никуда не делся. Кроме того, если бизнес с помощью ИТ начинает нащупывать новые возможности, продукты, ниши — это же прекрасно! Ценность от применения информационных технологий повышается, что выгодно обеим сторонам — и ИТ-подразделению, и бизнесу.