Управление ИТ-услугами

Финальным аккордом форума [it]MF 2021, проведенного издательством «Открытые системы», стал круглый стол «Сциллы и харибды стратегии цифровизации», в рамках которого участники обсудили рецепты успешной цифровизации. Приглашенные эксперты попытались дать советы, на что обращать внимание и как сделать цифровую стратегию компании реально работающей, чтобы это не был пустой документ, который пылится на полке.

Как отметил Михаил Петров, директор департамента цифровой трансформации Счетной палаты РФ, в госструктурах применяются абсолютно коммерческие подходы к выстраиванию работы с цифровыми стратегиями. Главные критерии успеха стратегии – краткость, понятность и доказуемость пользы изменений. Именно так можно вербовать своих сторонников. Это должен быть не толстый и зачастую «мертворожденный» документ, к которым привыкли многие айтишники, а живой рабочий процесс, который «с колес» воплощается в жизнь.

«Цифровые революционеры» в МЧС

Госструктуры в последнее время оказались охваченными процессами цифровой трансформации ничуть не меньше, чем коммерческие компании. Практически у всех органов исполнительной власти уже есть свой взгляд, каждый прошел определенный путь, и МЧС России не является исключением. И хотя МЧС «не светится» в публичном поле, их подходы вызывают серьезный интерес.

Как подчеркнул Виктор Ничипорчук, заместитель министра МЧС России, создать цифровую стратегию не так уж и сложно, а вот запустить ее и заставить работать – целое искусство. По его словам, между стратегией и тактикой – инструментами и способами реализации стратегии в конкретных условиях – гигантская пропасть, и именно поэтому в управлении есть термин «оперативное искусство».

«Мы поступаем подобно революционерам. У Ленина, изложившего стратегию группы государств в нескольких десятках томов сочинений, на самом деле была небольшая команда, которые эти идеи обсуждала и внедряла», — отметил Ничипорчук. В МЧС на первом этапе большого готового документа не было – был лишь один слайд презентации с несколькими тезисами, отражающими видение реформаторов. Затем появился второй слайд с целями, и третий – с измеримыми показателями.

Виктор Ничипорчук: «Создать цифровую стратегию не так уж и сложно, а вот запустить ее и заставить работать – целое искусство»

«После нескольких попыток внедрить нашу цифровую стратегию по стране, а МЧС – это около 350 тыс. сотрудников – мы поняли, что относиться к стратегии следует как к самому обычному продукту, который необходимо рекламировать, продавать, доказывать его пользу», — продолжил Ничипорчук. Бесполезно заставлять людей следовать стратегии, гораздо эффективнее применять маркетинговые подходы.

Как заставить людей поверить в «цифру»? Для этого нужен простой пример – надо выбрать архаичный процесс, чтобы его наглядно трансформировать и показать всей стране, как он может выглядеть. В МЧС таким процессом стало «Определение термических аномалий», в рамках которого спутники несколько раз в сутки фотографируют территорию страны в тепловом режиме, а анализ температур показывает места потенциальных возгораний. Раньше снимки со станций приема уходили в центр разбора, где снимки анализировались вручную, а результаты заносились в электронные таблицы и рассылались по почте в десятки тысяч муниципальных образований.

Для пилотного проекта была собрана небольшая (но весьма дорогая) команда хороших специалистов в области искусственного интеллекта. Им удалось оперативно создать нейросеть, распознающую температурные аномалии, и простейшее приложение, которое по любой аномалии рассылает push-уведомления ответственным сотрудникам. В результате, помимо 45-кратного сокращения времени и прочих эффектов, МЧС в течение месяца получило около 18 тыс. клиентов, занимавшихся этой проблематикой. Этот проект стал «фейерверком», который показал всем, насколько радикальными могут быть изменения. И потенциал для этого в ведомстве огромный.

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

Культура: давление «сверху» и популяризация «снизу»

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

«Работа с культурой организации – важнейшая часть управления изменениями. А цифровая трансформация – это именно изменения, которые как правило, большинству не нравятся», — отметила Мария Шклярук, генеральный директор Центра перспективных управленческих решений. Здесь методы известны: искать сторонников, привлекать на свою сторону лидеров, и это обязательно нужно делать. Наиболее ощутимый прорыв происходит, когда люди, научившись работать с новыми инструментами, начинают рассказывать остальным о практике их использования и полученной пользе. Именно так удается преодолеть сопротивление внедрению новых инструментов.

Кроме того, общеизвестен такой мощнейший фактор, как позиция руководителя. Как подчеркнула Шклярук, очень важным решением стало развитие института руководителей цифровой трансформации на государственной службе, потому что это первый подобный опыт ведения системной работы. Сначала все претенденты проходили оценку компетенций и оценку «360 градусов», затем проводился их рейтинг по конкретным поручениям правительства, а в конце года Минцифры сформировало интегрированный рейтинг. Все это в совокупности начало сильно менять отношение к проектам цифровизации, потому что появилась ориентированность на результат – за него стали спрашивать. Большое внимание стало уделяться развитию компетенций – у многих налицо сильный прогресс.

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

Между четырьмя скалами

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

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

«Компании приходится лавировать между этими четырьмя «скалами». Без стратегии этого сделать не получится: надо понимать, какое место хотим занимать на рынке, как дифференцироваться от конкурентов, за счет чего быть эффективным», — уверен Иван Мельник, директор по инновациям X5 Retail. Цифровая трансформация является инструментом поиска этой эффективности. Например, если вчера прогнозирование пополнения товара на полке выполнялось обычными регрессиями и прочими классическими методами, и точность была 75%, то инвестировав в современные инструменты, можно построить нейросети, существенно усложнить алгоритмы и получить точность 85%. Это означает сокращение резервов и площадей, снижение перевозок. Сэкономленное можно перенаправить на снижение цен и взаимодействие с покупателем.

Иван Мельник: «Конечно, динамика изменений на рынке высокая, но не до такой степени, чтобы отказаться от долгосрочных целей. Трехлетний горизонт должен быть обязательно»

Далее, можно захотеть, чтобы покупатели совершали покупки на 10 минут быстрее, при том, что количество кассовых узлов ограничено. «Цифра» помогает реализовать новые требования в физически ограниченном пространстве. По словам Мельника, в 70% случаев получается, что на новые задачи можно найти ответ, создавая цифровые инструменты. Сумма этих инструментов превращается в цифровую стратегию, у которой есть четкий драйвер, экономическая цель и понимание, к чему это приведет компанию на рынке.

«Конечно, динамика изменений на рынке высокая, но не до такой степени, чтобы отказаться от долгосрочных целей. Трехлетний горизонт должен быть обязательно», — считает Мельник. Но каждый год должен проводиться пересмотр и уточнение стратегии. Суть за три года поменяться не успевает, а вот инструментарий – успевает, да и конкуренты не дремлют.

Архитектура предприятия – не препятствие, а помощь

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

«Если понимать архитектуру по-старому – как стандарты, правила и создание сложных схем – то она больше направлена на предотвращение рисков. На мой взгляд правильнее и эффективнее, когда архитектура предприятия по сути становится цифровой стратегией без излишней детализации», — рекомендует Петр Подымов, архитектор предприятия в команде стратегии «Леруа Мерлен». В этом случае архитектура становится описанием стратегии не как единого монументального документа, а именно в новой ее ипостаси: как вектора развития.

Не надо превращать архитектуру в самоцель. Ее надо использовать чтобы понять, как попасть в целевое состояние, следуя вектору развития.

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

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

***

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

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

Предприятия все чаще обращаются к FinOps (financial operations), дисциплине управления бизнесом, нашедшей воплощение в соответствующем аналитическом программном обеспечении, предназначенном для расчета стоимости обслуживания в публичных облаках. Такой подход должен помочь предприятиям лучше планировать, рассчитывать финансирование и прогнозировать требования к расходам при потреблении облачных сервисов.

Эксперты называют FinOps инструментом оптимизации затрат, которая приобретает критически важное значение по мере того, как компании переводят все больше своих ключевых ИТ-функций из самостоятельно контролируемых ЦОДов с постоянными затратами в облака с затратами переменными. По оценкам Gartner, до 2022 года рынок публичных облачных сервисов будет ежегодно расти почти на 17%, и к концу этого периода достигнет 360 млрд долл.

Как ни удивительно, именно в этом сегменте аналитики обнаруживают исключительное расточительство с точки зрения как расходования драгоценного бюджета, так и использования ресурсов. Из 300 руководителей финансовых и ИТ-служб, опрошенных 451 Research, 80% отметили, что слабое управление финансами в облачной сфере негативно отражается на их бизнесе; 57% ежедневно выражают обеспокоенность управлением облачными затратами, а 69% регулярно превышают заложенный облачный бюджет на 25% и более.

Экономика облака

«Облако – не только технологический феномен XXI века, но и экономическая модель, движимая цифровой трансформацией, – указывает автор облачной стратегии компании Capital One Бернард Голден. (Capital One Financial Corporation — американская банковская холдинговая компания, специализирующаяся на кредитных карточках, ипотечных кредитах, автокредитах, банковских и сберегательных продуктах. — Прим. перев.) – Облако – новая эпоха фабричного производства. Способность облаков автоматизировать функции и повышать эффективность работы компаний аналогична революции Генри Форда, которую тот устроил в автомобильной отрасли путем организации фабричного производства и автоматизации некоторых процессов, позволившей ускорить выпуск автомобилей. Подобно тому, как Форд сократил расходы на производство автомобилей за счет использования средств автоматизации, предприятия должны минимизировать свои затраты на облачное программное обеспечение путем их оптимизации и управления ими».

Многие крупные предприятия вводят должности разработчиков облачных стратегий, которые должны помочь анализировать и управлять облачными ресурсами. Роль Джозефа Дейли в качестве директора по облачной оптимизации в Nationwide заключается в том, чтобы определять характер операций компании в облаке. (Nationwide — одна из крупнейших в мире компаний в области страховых и финансовых сервисов. — Прим. перев.)

По мере перемещения вычислительных ресурсов в Amazon Web Services и Azure компания Nationwide столкнулась с вопросом выбора оптимальной облачной платформы. Сложность выбора «правильного» облачного сервиса является общей проблемой при переходе в облако. То же самое относится и к «черному ящику» облака в части понимания затрат на конкретные облачные сервисы. Счета за облачные сервисы, выставляемые AWS, Microsoft и другими провайдерами, становятся слишком подробными и громоздкими. FinOps помогает предприятиям отслеживать свои затраты на ресурсы процессора, памяти и хранения, внося соответствующие корректировки, связанные с выбором серверов, которые лучше подходят им с точки зрения ресурсов и требований.

Главное же, наверное, заключается в том, что FinOps помогает Дейли обсуждать с коллегами стоимость запуска в облаке конкретных бизнес-процессов. Коллегам его предстоит решить, что следует изменить, для того чтобы уменьшить сумму счета за потребление облачных сервисов. «С этого начинается корректировка операционной модели, которая способствует повышению прозрачности затрат», – замечает Дейли.

Прозрачность расходов имеет решающее значение и для Алекса Ландиса, финансового менеджера проекта разработки платформ AWS в AutoDesk. С его помощью компании удалось добиться серьезного прогресса в области перехода от продаж традиционных программ для построения чертежей к предоставлению аналогичных SaaS-сервисов в AWS и других облаках. Будучи бизнес-аналитиком по образованию, сегодня Ландис учится выстраивать платформу публичных облачных программных сервисов.

Благодаря централизации и внедрения политик управления AutoDesk уже удалось сэкономить на облачных затратах сотни тысяч долларов.

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

Затраты на использование серверов в модели без серверов

Сопоставление потребленных услуг с выставленными за них счетами в «отчетах об использовании сервисов», генерируемых AWS, всегда вызывает немало трудностей у руководителей финансовых и ИТ-служб. Многие из них вынуждены прибегать к своеобразному реверс-инжинирингу в попытках выяснить, насколько запрашиваемые деньги соотносятся с реальными обращениями к API.

«Объемы обработки данных настолько велики, что вам приходится иметь дело со списком транзакций в сотни миллионов строк», – отмечает Джейсон Фуллер, возглавляющий направление операций и управления облаком в компании Here Technologies, разрабатывающей навигационные программы для автомобильной отрасли и других секторов.

Провайдеры облачных сервисов все чаще исключают из счетов упоминания о серверах, предлагая в качестве замены функции в виде сервиса (functions-as-a-service, FaaS). В этих условиях компании платят только за использование программного кода, который обеспечивает функционирование их приложений. Эти транзакции выполняются за доли секунды, генерируя еще больше строк еще быстрее, что приводит к значительному увеличению объемов и сложности выставленных счетов. «Когда вы пишете код для новой функции, обращение к сервисам происходит очень быстро, и массу людей можно обслужить за совсем небольшие деньги, – пояснил Фуллер. – Но при выполнении миллиардов транзакций количество таких обращений стремительно растет. И это вызывает у клиентов уже серьезные трудности».

С этим согласен и Дж.Р. Стормент, соучредитель компании Cloudability, выпускающей программное обеспечение FinOps для составления прейскурантов на потребленные предприятиями облачные сервисы.

"Каждый месяц мы видим счета за потребленные облачные сервисы, размеры которых в несжатом виде могут достигать 450 гигабайт, – говорит он. – Таков счет в текстовой форме только для одной компании за один месяц. Посекундный биллинг в сочетании с расширением ассортимента предлагаемых сервисов (у AWS он насчитывает более 200 тыс. единиц) и ростом популярности публичных облаков, обороты которых исчисляются уже девятизначными числами, порождают для крупных предприятий огромное количество данных".

В целях систематизации практик FinOps компания Cloudbility объединила усилия с Nationwide, AutoDesk, Here Technologies и прочими, сформировав некоммерческую ассоциацию FinOps Foundation (F2), которая сосредоточена на продвижении передового опыта и стандартов управления финансированием облачных сервисов.

Лучшие практики FinOps

Независимо от того, придерживаются ли компании рекомендаций F2 или же разрабатывают собственные методики, Голден выделяет четыре ключевые стратегии управления облачными затратами.

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

— Не запрашивайте газонокосилку там, где подойдет триммер. Является ли инстанс EC2 оптимальным для вас или же он избыточен? Используйте и платите только за то, что вам действительно нужно.

— Оптимизируйте расходы. Рассмотрите возможность использования зарезервированных экземпляров, резервирования ресурсов и мощностей в определенной зоне. Это позволит закупать вычислительные ресурсы, которые вам понадобятся, дешевле, чем при их потреблении по требованию.

— Создавайте приложения, которые «готовы для облака». Проектируйте свои приложения с учетом их горизонтального масштабирования. В этом случае вы сможете добавлять или убирать ресурсы по мере необходимости.

«Таковы на сегодняшний день лучшие практики в части управления облачными затратами, – подчеркивает Голден. – Что же касается поиска подходящего кандидата на роль менеджера по облачной стратегии или оптимизации облачных затрат, это должен быть человек, который хорошо соотносит бизнес-требования с тем, что предстоит построить компании. Никого с десятилетним опытом управления облачными затратами на рынке вы не найдете».

Гибкие методологии управления ИТ находят все большее признание в страховом бизнесе. Одной из организаций, успешно применяющей эти методики, является государственная страховая компания «Югория». Она обслуживает сегодня свыше 40 тыс. юридических лиц и около 2 млн граждан, предоставляя широкий спектр услуг по 21 виду страхования и перестрахования с использованием более чем 60 различных правил страхования. Особое внимание компания уделяет развитию филиальной сети, которая сейчас состоит из 73 филиалов, более 200 агентств и точек продаж в 50 регионах России. Виталий Шишаев, руководитель отдела внедрения и сопровождения сервисов ГСК «Югория», рассказывает, как с помощью гибких методологий управления ИТ-услугами удается оперативно адаптировать инфраструктуру для удовлетворения запросов бизнеса. Силами объединенных команд, включающих бизнес-пользователей и ИТ-специалистов, обеспечивается развитие компании на высококонкурентном рынке страховых услуг, при этом гармонично сочетаются надежность государственного предприятия и динамичность коммерческой структуры. Виталий Шишаев - один из докладчиков форума ITMF-2018.

– Насколько необходимы сегодня методики Agile в страховом бизнесе?

В страховом бизнесе сейчас требуются быстрые и решительные шаги по привлечению клиентов и снижению убыточности. Возьмем, к примеру, добровольное автострахование (КАСКО), где, с одной стороны, очень большая конкуренция, а с другой – растет стоимость ремонта автомобиля и вследствие этого увеличивается средняя выплата. Чтобы заполучить клиента, нужно предложить ему конкурентный продукт по рыночной цене, оставаясь в зоне рентабельности, а это влечет за собой постоянные изменения в бизнес-процессах, которые необходимо проводить быстрее конкурентов. Методы Agile здесь очень хорошо подходят.

– Как вообще бизнес воспринимает сегодня методологии Аgile?

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

– В чем главные преимущества коммуникаций внутри объединенных команд?

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

– Каковы главные уроки процесса объединения команд разработки, эксплуатации и бизнеса?

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

– Каков ожидаемый или уже полученный эффект от перехода на Scaled Agile Framework?

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

– О чем вы планируете рассказать 22 мая на IT Management Forum 2018 ?

Об истории трансформации системы управления ИТ нашей компании: о бизнес-контексте и предпосылках принимаемых решений, проблемах, с которыми мы столкнулись, и способах их решений, о командах и организации их взаимодействия. Особо остановлюсь на том, что бы я стал делать по-другому, если бы мы в ГСК «Югория» заново начали проект перестройки работы по методике Agile.

Выступление Антона Исанина, руководителя центра качества «Альфа-Банка», набрало максимальное число позитивных отзывов участников конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной издательством «Открытые системы». Сокращение вывода новых продуктов на рынок до пяти дней с помощью подходов DevOps – результат, заслуживающий уважения.

Основная проблема водопадной модели заключается в том, что процессы проходят ужасно медленно. Между участниками команд порождается множество недопониманий, и конечный результат ухудшается. В случае Agile изменения происходят по-прежнему медленно – они занимают пусть и не месяцы, но все равно десятки дней. А главное – команда по-прежнему не чувствует рынка, остаются «стены» между владельцем продукта и разработчиками. Сочетание подходов Agile и DevOps позволяет обеспечить максимальную чувствительность к рынку и минимизировать длительность пути к удовлетворению потребностей клиента в некоторых случаях до пяти дней.

По мнению Исанина, DevOps дает ответы на вопросы, о которых молчит ITSM: как быстро давать клиенту то, что он хочет, и как понять, за что клиент готов платить. «DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха. Вторая половина успеха – максимально быстро удовлетворить эти потребности», – подчеркнул он в ходе конференции.

Успеть за возможностями

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

Российский финансовый рынок не очень развит, масса ниш на нем не заняты, и возможностей для развития бизнеса чрезвычайно много, главное – быстро эти возможности реализовать, пока не появились конкуренты или не изменились потребности клиентов. На это и нацелена модель гибкого бизнеса (business-agility), и не проходит и дня, чтобы очередной бизнес-гигант не признался в любви к ней.

Антон Исанин, руководитель центра качества «Альфа-Банка»: «DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха. Вторая половина успеха – максимально быстро удовлетворить эти потребности»

«Если мы хотим не просто удержаться на плаву, но и развиваться, отвечать требованиям акционеров, нам тоже приходится меняться», – говорит Исанин.

Первым шагом в эволюции «Альфа-Банка» стала попытка добавить процессам оперативности путем итеративного подхода, для этого были применены гибкие методики. Часто проблема заключается именно в том, что, зная о длительности водопадного проекта, на начальных этапах в продукт пытаются впихнуть максимальную функциональность – в дальнейшем такой возможности уже не будет. И объем работы, взваливаемый на разработчиков, сильно растет. Решение получается монолитным, в других системах приходится делать доработки. Кроме того, мало кто может угадать, что будет реально нужно клиенту через год, когда продукт будет выведен на рынок.

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

«Есть нюанс: при таком подходе команда готова оперативно внедрять решения, но между ней и отделом продаж по-прежнему стена», – констатирует Исанин. Люди уже готовы к изменениям согласно agile-манифесту, который говорит, что изменения приветствуются, что они важнее следования изначальному плану. Тем не менее расстояние до рынка все равно остается существенным, между владельцем продукта и скрам-командой есть непонимание. Отдельно следует отметить отношения со службой сопровождения, с которой возникают трения относительно архитектурных вопросов и ответственности за надежность.

Разрушение стен и объединение людей в рамках единой команды – необходимый шаг для перехода к DevOps. Такая конфигурация хороша тем, что расстояние от команды разработчиков до клиента заметно сокращается. Чем больше посредников между разработчиками и клиентом, тем сложнее понять, что ему нужно, на каждом этапе возникает эффект испорченного телефона. Гораздо лучше дать возможность всей команде «слушать» рынок и думать, как принести клиенту пользу.

«Команда должна быть целиком сфокусирована на рынке. Чем больше барьеров мы устраним между рынком и командой, тем больше вероятность коммерческой состоятельности банка», – говорит Исанин.

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

«Мы минимизируем путь к удовлетворению клиента, меняемся быстро – за дни. В случае agile-команд время создания продукта сокращается до 20 дней. Подход DevOps сокращает цикл разработки до 5 дней», – подчеркивает Исанин. Когда все необходимые действия зависят от единой команды, заинтересованной в результате, удается избежать потери времени на самых разных этапах проекта.

Необходимо создать цельные независимые продуктовые команды с полноценным сопровождением. Это важный вопрос: DevOps подразумевает не только совместную работу различных администраторов в agile-командах; вместе со специалистом в команду «переезжает» и ответственность, а за стабильность продукта отвечает его владелец. Кроме того, в команду уходят второй и третий уровни поддержки.

Мельче, но быстрее

«Чтобы быстро выпустить продукт на рынок, задачу надо раздробить. Есть простая связь: чем лучше удается дробить ценность, доставляемую клиенту, тем ощутимее эффект. И чем мельче получаются кусочки, тем лучше работает автоматизация», – уверен Исанин. DevOps превращается в непрерывный поток маленьких кусочков продуктов, которые едут по автоматическому конвейеру.

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

В «Альфа-Банке» автоматизация процессов разработки была начата с процессов тестирования.

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

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

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

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

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

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

1. Изменение характера инцидентов и запросов на обслуживание

Появление портала самообслуживания приводит к тому, что из очереди заданий службы поддержки исчезают многие «легкие» заявки (как об инцидентах, так и о запросах на обслуживание). Перечислим последствия.

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

Что делать: пересмотреть роль службы поддержки пользователей.

Время «упрощенной» службы поддержки, для работы в которой достаточно было читать сценарии, прошло. Прежде всего потому, что портал самообслуживания «съест» большую часть простых заявок об инцидентах и сервисном обслуживании, а сотрудники службы поддержки будут получать в основном заявки посложнее. Вторая причина — рост ожиданий конечных пользователей, обусловленный опытом их работы с сервисами потребительского класса.

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

2. Повышение расходов на оплату труда специалистов по поддержке пользователей

Расширение и изменение набора навыков сотрудника службы поддержки приведет к следующему:

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

Что делать: приучиться больше ценить сотрудников службы поддержки пользователей.

Согласно исследованию Service Desk Institute, сегодня сотрудники служб поддержки получают недостаточную финансовую компенсацию за лояльность, то есть работу на своей должности в течение двух или более лет.

Опросы, целью которых является оценка морального духа персонала, в службах поддержки обычно не проводятся.

Здесь явно надо что-то менять. Учитывая усложнение задач сотрудника службы поддержки, нанимать и вводить новый персонал в курс дела станет труднее, важность удержания работников повысится.

3. Сокращение численности персонала приведет к тому, что службы поддержки будут менее гибкими

Со снижением числа заявок исчезнет и потребность в большом штате службы поддержки, даже несмотря на повышение сложности решаемых задач. Перечислим вероятные результаты.

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

Что делать: работать умнее, а не интенсивнее.

С сокращением численности персонала и ростом сложности задач службам поддержки необходимо улучшить управление знаниями, а конкретнее — их использование.

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

Чтобы работать умнее, а не интенсивнее, нужно изучить возможности автоматизации самообслуживания, службы поддержки и управления эксплуатацией ИТ (IT Operations Management, ITOM), а также использования метода инцидентов, решаемых на нулевом уровне (Level Zero Solvable, LZS).

Разъяснить его меньше чем в 100 словах сложно, поэтому, если есть время, лучше ознакомиться с документом http://www.thinkhdi.com/~/media/HDICorp/Files/Library-Archive/Insider%20Articles/WhatIsLZS.pdf. Говоря упрощенно, LZS — это показатель количества поступивших в службу поддержки заявок, которые можно выполнить, пользуясь информацией из портала самообслуживания.

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

4. Влияние на операционную деятельность компании

Здесь все дело в уровне автоматизации. Если автоматизация отсутствует, проблема конечного пользователя будет решаться через портал самообслуживания медленнее, чем при обращении в службу поддержки. Кроме того, при этом снижается продуктивность работы конечного пользователя и, возможно, всей операционной деятельности компании. Если клиенту после обращения через портал приходится ждать ручного внесения исправлений или выделения ресурсов, у него может пропасть само желание пользоваться порталом самообслуживания.

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

Что делать: изучать возможности автоматизации самообслуживания, работы службы поддержки и управления эксплуатацией ИТ.

Автоматизация дает тройную выгоду службам поддержки:

• повышение скорости/результативности,
• снижение затрат,
• улучшение качества обслуживания.

Когда есть возможность что-то автоматизировать, можно получить и другие преимущества:

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

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

• Улучшение функций поиска — интеллектуальный поиск выдает релевантные результаты с высокой точностью.
• Предоставление персональных рекомендаций — наподобие тех, что получают пользователи Amazon и Netflix.
• Создание интеллектуальных автоответчиков — высококачественное выполнение заявок автоматизированными системами без участия человека.
• Выявление и устранение пробелов в знаниях — обнаружение случаев нехватки информации в базе знаний и преобразование задокументированных процедур выполнения заявок в новые знания.

5. Существенное изменение метрик и целевых показателей

Метрики и целевые показатели службы поддержки пользователей придется пересмотреть.

• С внедрением портала самообслуживания объемы заявок должны снизиться.
• Число выполнений заявок при первом обращении (first contact resolution, FCR) может резко упасть; возможно, данный показатель вообще потеряет смысл.
• Среднее время работы по заявке увеличится, сами заявки станут в целом более сложными.
• Понадобятся новые метрики.

Дополнительное изменение метрик и контрольных показателей будет зависеть от доли конечных пользователей, которые принципиально не пожелают обращаться к порталу самообслуживания.

Что делать: пересмотреть и перекалибровать метрики.

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

6. Успех портала самообслуживания может привести к снижению ценности отдела ИТ в глазах бизнес-руководства

Оценивать результативность отдела ИТ и его восприятие в глазах бизнеса всегда сложно. И здесь на ум приходит такой показатель, выведенный довольно давно одной из аналитических компаний: служба поддержки пользователей на 50% определяет отношение бизнеса к корпоративному отделу ИТ. Если это так, оценка бизнесом отдела ИТ в целом может легко упасть при снижении объема непосредственных контактов с сотрудниками службы поддержки.

К тому же у каждого может быть своя точка зрения на успех внедрения портала самообслуживания. К примеру, утверждение «отдел ИТ предлагает отличный портал самообслуживания» пессимист может воспринять так: «если в отделе ИТ что-то сломается, то чинить придется самим пользователям» — либо рассматривать как сигнал к тому, что штат персонала отдела ИТ теперь можно сократить.

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

7. Ухудшение и утрата взаимоотношений с бизнес-заказчиками

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

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

Что делать: инвестировать в улучшение управления взаимоотношениями.

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

• Если говорить о компании в целом и ее бизнес-подразделениях, то нужны должности, которые подразумевают личный контакт: менеджеры по доставке услуг, по контролю уровня обслуживания и управлению взаимоотношениями с бизнесом.
• Что касается конечных пользователей, необходимо понимать, что любой прямой контакт со службой поддержки отныне должен проходить идеально.

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

8. Самообслуживание — это «юбилей с отложенной датой»

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

Пример — доступ к средствам самообслуживания с мобильных устройств. Это стало привычным в повседневной жизни, но, согласно исследованию HDI 2015 года, только в четверти компаний, предлагающих портал самообслуживания, предоставляют к нему мобильный доступ. Кроме того, в потребительских сервисах повсеместно применяется машинное обучение, тогда как в порталах самообслуживания это пока не практикуется.

Что делать: планировать развитие систем самообслуживания и выделять соответствующие средства в бюджете.

Важно осознавать, что на ожидания конечных пользователей от портала самообслуживания будет влиять опыт, полученный ими в повседневной жизни.

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

Итак, мы рассмотрели, как может сказаться на работе службы поддержки внедрение портала самообслуживания, и предложили способы противодействия негативному влиянию этого шага. Сталкивались ли вы в своей практике с вышеназванными и другими проблемами?

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

Разумеется, в проекты самообслуживания инвестировали не все участники опроса: по данным SDI, внедрили соответствующие технологии около 80%, то есть, судя по количеству жалующихся на низкий уровень их использования, это примерно половина тех, кто провел внедрение; при этом возможно, кто-то просто не признал, что страдает из-за неиспользования.

Считать, что корпоративные проекты порталов самообслуживания автоматически достигнут успеха по примеру аналогов из потребительского мира наподобие Amazon, было бы необоснованным. Служащие не будут пользоваться таким порталом по той причине, что они уже пользуются средствами самообслуживания вне работы, особенно если корпоративные системы по своему удобству уступают потребительским.

Не сравнивайте несопоставимое

Сотрудников, возможно, устраивают сервисы самообслуживания, которыми они пользуются в повседневной жизни, но на работе вступают в силу другие факторы и обстоятельства.

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

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

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

Шесть рекомендаций по внедрению средств самообслуживания

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

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

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

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

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

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

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

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

В одной из своих заметок на freshserviceblog я обрисовал, что представляет собой «управление сервисами предприятия» (Enterprise Service Management, ESM), чем объясняется его растущая популярность и в чем его преимущества.

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

Конечно, есть рекомендации, которые зачастую выдают за лучшие или по крайней мере хорошие практики. Сегодня «сценарии» управления корпоративными сервисами рекламируют и продают многие поставщики инструментов ITSM, а их знания и опыт, накопленные в процессе реализации предыдущих клиентских инициатив, воплощаются в «наилучшие советы» по правильному управлению корпоративными сервисами.

Однако откладывать планирование процесса управления сервисами предприятия из-за недостатка имеющихся ресурсов нельзя.

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

Опрос, проведенный HDI в 2014 году, показал: 51% респондентов уже внедряют принципы ITSM вне сферы ИТ или же планируют в скором времени заняться этим. Согласно результатам опроса, организованного Service Desk Institute в 2015 году, 55% респондентов планировали «управление совместно используемыми сервисами», то есть управление сервисами предприятия.

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

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

Итак, процессы управления корпоративными сервисами объективно существуют. Что же организации следует делать, чтобы повысить свои шансы на успех?

1. Не относитесь к управлению корпоративными сервисами как к ИТ-проекту.

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

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

2. Учитывайте различия.

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

Учитывайте различия задействованных групп. Речь может идти об относительном потенциале изменений или даже о вкусе к переменам. Возможно, различия в бизнес-процессах приводят к тому, что передовой опыт ITSM не всегда подходит для наилучшей реализации тех или иных функций бизнеса. Не стоит форсировать встраивание бизнес-функций в инструменты ITSM – это лишь замедлит (а то и сорвет) выполнение проекта и вряд ли приведет к оптимальным решениям.

3. Не пытайтесь помогать другим поставщикам корпоративных сервисов, не решив сперва собственные задачи

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

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

4. Не думайте, что управление сервисами предприятия интересно кому-то само по себе, обосновывать все необходимо в бизнес-терминах.

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

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

5. Тщательно и без спешки продумайте реализацию проекта управления корпоративными сервисами.

Управление корпоративными сервисами в масштабах всего предприятия – очень объемная задача, поэтому подход «большого взрыва» представляется слишком сложным и рискованным. Рекомендуется начать с малого, сосредоточившись на каком-то одном бизнес-подразделении или нескольких новых функциях.

Затем, как и в любом другом многоэтапном проекте, следует отталкиваться от ранее достигнутых успехов, перенося достижения одного бизнес-подразделения на другие. Впрочем, в управлении корпоративными сервисами можно добиться и быстрого выигрыша (ведь все построено на базе ITSM), поэтому аккуратно планируйте, что и когда вы намерены делать.

Итак, я изложил пять своих рекомендаций по планированию процесса управления сервисами предприятия. А что бы добавили или изменили вы?

- Стивен Манн, руководитель и директор по контенту аналитической компании ITSM.tools. Помимо работы в ней он занимается подготовкой маркетинговых материалов по ИТ и управлению ИТ-сервисами. Ведет регулярно обновляемый блог, является автором ряда книг, выступает на отраслевых мероприятиях с докладами, посвященными проблематике управления ИТ-сервисами.

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

ИТ-активы любят счет

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

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

«Главной проблемой был недостаточный объем информации о состоянии ИТ-активов. Это порождало множество проблем при планировании ИТ-бюджетов и реализации проектов», – констатирует Вячеслав Корчуганов, директор по ИТ финансовой группы «БКС». Каждый год выяснялось, что забыли заменить или докупить очередную систему хранения данных или что группа серверов снимается производителем с гарантии. Пришло осознание того, что нужно управлять не только количественными показателями активов, но и дополнительными характеристиками, позволяющими принимать управленческие решения. Например, если известно, каков износ оборудования или когда подходит срок окончания гарантии на него, необходимо принимать меры заранее, а не в момент верстки бюджета. А значит, нужно выработать единые правила, разработать стандарты и постепенно реализовать их на общекорпоративном уровне.

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

Это сказывалось как на управляемости огромным парком техники и ПО, так и на взаимоотношениях с внешним миром. Кроме того, для любого CIO важна прозрачность ИТ для бизнеса, потому что чем выше сложность ИТ, тем больше к нему возникает вопросов: куда уходят бюджетные деньги и зачем надо закупать новое оборудование.

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

Когда практика важнее теории

Любой проект приходится «продавать» как внутри ИТ, так и вовне – руководителям бизнес-направлений. Например, предложение «внедрить CMDB» (Configuration Management Database, хранилище информации обо всех ИТ-объектах компании) бизнес просто не поймет и отнесется к идее скептически.

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

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

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

В итоге партнерами по проекту стали специалисты компании «Инфраменеджер». «Общаясь с ними и уточняя методологию, мы жарко спорили: у нас – свое видение, у них – проектный опыт. Они отстаивали свою методологию, привнося свои взгляды, что было очень полезно», – говорит Корчуганов.

Бюджет в разрезе сервисов

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

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

Сейчас в компании обсуждается бюджет 2016 года, и ИТ-департамент уже чувствует принципиальные изменения. Раньше бюджет составлялся по типам затрат, и их влияние на реальное качество ИТ-сервисов не просматривалось. Теперь появилась возможность создавать бюджет именно в разрезе сервисов – не затрат на оборудование и лицензии, а стоимости владения той или иной системой. Это становится основой для принятия взвешенных решений. На инфраструктуру надо тратить ровно столько средств, сколько она заслуживает. «Я надеюсь, в следующем году мы не будем приобретать дорогостоящие сервисные контракты на оборудование, которое поддерживает работу некритичных систем», – выражает свой оптимизм Алексей Шлепнев, начальник управления методологии ИТ-процессов финансовой группы «БКС».

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

«Многим ИТ-директорам не хватает инструментов управления: кроме телефонного справочника и вороха разрозненной и не всегда актуальной документации, у них зачастую ничего нет», – сетует Шлепнев.

Нужна ли прозрачность ИТ-департамента

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

«Если топ-менеджмент понимает, на что тратит деньги, он начинает сам принимать решения. И это не всегда означает исключительно экономию», – уверен Корчуганов. Бывает и другой эффект: бизнес видит, что он получает адекватное качество сервисов, и начинает инвестировать в них, понимая, что за это получает.

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