12:35 20.04.2017
ИТ-службы, для того чтобы удовлетворять требованиям бизнеса эпохи цифровой трансформации, должны измениться сами.
Для того чтобы способствовать цифровой трансформации бизнеса, корпоративные ИТ-структуры должны изменить и свой подход к работе, и методы взаимодействия с внутренним заказчиком. О том, как ИТ-службам начать трансформацию с себя, рассказывает Олег Скрынник, управляющий партнер компании Cleverics, одного из партнеров предстоящего форума IT Management Forum 2017, который издательство «Открытые системы» проведет 25 мая.
- В последнее время много говорится о цифровой трансформации бизнеса, но мало — о том, как должен при этом меняться стиль работы корпоративных ИТ-структур...
Безусловно, изменения в управлении информационными технологиями необходимы, чтобы поддержать бизнес-трансформацию. Одно из средств для этого — набор практик DevOps. Еще буквально год-два назад у большинства ИТ-специалистов и менеджеров не было четкого понимания, что же это такое и зачем нужно. При том что само движение зародилось лет пять-шесть назад, только сейчас этот набор практик находит свое применение. В 2016-2017 годах в вопросе «Что такое DevOps?» наконец наступает ясность. Ограниченные точки зрения, например: DevOps — это про автоматизацию конвейера поставки ПО, сменяются более общей концепцией: DevOps — логическое развитие идей гибкой разработки ПО и бережливого производства, примененное к полной цепочке создания ценности и позволяющее добиваться большего от современных информационных технологий посредством культурных, организационных и инструментальных изменений.
Надо признать, что большинство идей DevOps не новы. DevOps объединяет, впитывает в себя практики Agile и других течений, привнося новое именно на стыке разработки и эксплуатации.
- Почему идеи DevOps стали популярны именно сейчас?
Мне кажется, есть два значимых фактора. С одной стороны, гибкие методики разработки программного обеспечения применяются довольно давно, во многих компаниях разных секторов экономики. Но довольно серьезное препятствие, мешающее получить полноценную отдачу от них, заключалось в том, что, когда разработка заканчивается, не очень понятно, как эксплуатировать созданный продукт. При том что отдача от вложений может быть реализована только на этапе эксплуатации.
В компании возникает существенное противоречие: с одной стороны, она настраивает процесс разработки так, чтобы быстро получать новые релизы своих информационных систем, усовершенствования, новые функции. А с другой — имеется сопротивление подразделений эксплуатации, которые считают, что изменение — зло, и если инфраструктура работает, то ее лучше лишний раз не трогать. И если каждые две недели или, не дай бог, каждый день выкатывать новые релизы и изменения, то стабильного функционирования инфраструктуры не добиться. Риски что-то испортить достаточно высоки. Поэтому вы, разработчики, готовьте код каждые две недели, но разворачивать его давайте, как раньше новые релизы, раз в квартал... То есть значительное «ускорение» разработки программного обеспечения дает весьма скромный результат, если смотреть на общую длину цикла «от идеи до бизнес-результата».
Назрела необходимость «продолжить» методологию Agile в область эксплуатации, чтобы она вписалась в общую цепочку, а не была сама по себе. Я сейчас использую термин Agile в широком смысле — как синоним быстрого и современного способа разработки программных систем. Это первое.
Второй фактор — появилась возможность по-новому организовать ИТ-инфраструктуру и ее поддержку. Теперь не обязательно покупать свое аппаратное обеспечение — месяцами выбивать бюджет, выбирать поставщика, покупать, ждать, когда купленное привезут, установят и настроят. Можно приобретать ресурсы в облаке по требованию. Не всегда, но довольно часто это оказывается дешевле, особенно при тестировании новых разработок. Именно это дает возможность не только быстро разрабатывать, но и быстро тестировать и вводить новые функции в эксплуатацию.
К слову, термин «облако» тоже появился давно, и действительно доступные надежные облачные технологии существуют уже лет пять. Но «сошлось» все недавно, и ключом к изменению стала доступная возможность управлять инфраструктурой как программным кодом. То есть инженеры ИТ могут с помощью условного скрипта «создать» всю необходимую инфраструктуру, включая серверное и сетевое хозяйство, системы хранения данных и т. д. Это дает возможность совершенно иначе строить эксплуатацию ИТ. Например, хранить все данные о конфигурациях в системах контроля версий, автоматически отслеживая изменения. Или разворачивать инфраструктуру в момент, когда она потребовалась, а не за несколько месяцев до этого. Или устранять неисправности, не тратя время на выяснение причины, а просто пересоздав требуемый участок инфраструктуры тем же условным скриптом, и многое другое.
Таким образом, в настоящее время появилась возможность строить эксплуатацию иначе. Обозначенная ранее необходимость получила свою ответную часть в виде возможности.
- Но мы пока говорим только про изменения в работе ИТ-подразделения?
Существенные изменения в ИТ-отделах, как правило, не делаются ради самих ИТ-отделов. ИТ работают для бизнеса.
Я считаю, что описанный выше подход является ключом к цифровой трансформации бизнеса, которая на практике означает весьма существенное изменение отношения как бизнес-структур, так и ИТ-отделов к качественным и количественным результатам применения информационных технологий.
Например, теперь не обязательно запускать огромный проект, чтобы года через полтора большая новая полнофункциональная ИТ-система наконец заработала, чтобы стало очевидно, что половина замечательных функций устарела. Напротив, можно начать с малого, запустить готовый продукт с минимальной функциональностью и посмотреть, куда дальше его развивать. Следить за откликами пользователей, за спросом, они подскажут, как развиваться.
Само по себе применение облачных технологий не является трансформацией: какая разница, где покупается инфраструктура? Важно другое: с помощью этой инфраструктуры и DevOps бизнесу обеспечивается оперативность, возможность проверять идеи, прежде чем реализовать их в промышленном масштабе. Скажем — предлагать несколько вариантов нового продукта или услуги, проводить их тестирование на целевых аудиториях, оперативно корректировать сами продукты и свои представления об их целевых группах, соответствующие бизнес-схемы.
На качественном уровне бизнес получает новые инструменты взаимодействия с клиентами, маркетинга, продаж, предоставления услуг и монетизации. На количественном уровне бизнес получает ИТ-продукты, создаваемые со скоростью движения бизнеса (необходимый бизнесу и очень быстрый time-to-market), а также ИТ-продукты, обладающие большей стабильностью и доступностью по сравнению с традиционными системами.
По мнению экспертов, для некоторых отраслей, таких как финансовые услуги, страхование, ретейл, не заниматься цифровой трансформацией означает подвергаться риску, что конкуренты, а также совершенно новые бизнесы будут постоянно отнимать завоеванную долю рынка и клиентов, а войти в новые ниши будет все сложнее.
- Есть ли сопротивление «трансформации через DevOps» со стороны бизнес-подразделений?
Думаю, правильнее говорить не о сопротивлении бизнеса, а о непонимании, что именно и как менять. Путь цифровой трансформации не выглядит простым. Во-первых, мало кто может толком рассказать, как по нему пройти, что связано с очень небольшим пока числом первопроходцев. Во-вторых, трансформация очень сильно затрагивает ключевые постулаты, на которые опиралось построение управления как информационными технологиями, так и бизнесом в последние 15-20 лет. В-третьих, цифровая трансформация ИТ отдельно от бизнеса, похоже, имеет не много смысла.
- Возможна и обратная ситуация: бизнес распробует прелесть быстрых изменений и начнет заваливать разработчиков заказами, руководствуясь соображением «отчего бы не попробовать»…
Ответ простой: пожалуйста, заказывайте, но помните, ресурс как был, так и остается ограничен, нужно понимать, что каждую задачу все равно придется сравнить с другой задачей и одну из них пустить вперед, а другую — поставить в очередь. Вопрос расстановки приоритетов никуда не делся. Кроме того, если бизнес с помощью ИТ начинает «нащупывать» новые возможности, продукты, ниши – это же прекрасно! Ценность от применения информационных технологий повышается, что выгодно обеим сторонам — и ИТ-подразделению, и бизнесу.
- Ваша компания будет одним из партнеров IT Management Forum 2017. О чем вы собираетесь рассказать участникам форума, какие из заявленных тем кажутся вам наиболее интересными, о чем бы вы хотели сами услышать на форуме?
Собственно, ровно по обсуждаемой теме мы проведем демонстрационную деловую игру «Проект Феникс – DevOps на практике». Это совершенно новая бизнес-симуляция, разработанная в прошлом году голландской компанией GamingWorks. Ее сюжет основан на популярной книге «Проект Феникс», а на самой игре участники могут на своем опыте изучить и опробовать основные идеи, техники и практики DevOps, такие как поток создания ценности, визуализация задач, минимальный рабочий продукт, быстрое устранение препятствий, ранняя обратная связь, непрерывное улучшение и др.
