Популярность сервисного подхода по построении информационной поддержки бизнеса выдвигает на одно их первых мест задачу формирования каталога ИТ-услуг. Но чтобы все описанные в каталоге сервисы могли быть предоставлены с гарантированным качеством и по минимальной цене, необходимо выстроить и оптимизировать массу иных управленческих процессов. Об этом мы беседуем с заместителем CIO компании «Лаборатория Касперского» Харланом Волдом.
Intelligent Enterprise: Подходы к построению ИТ-сервисов и управлению ими в компании «Лаборатория Касперского» наверняка фундаментальные. Насколько важно само понятие ИТ‑сервиса для вашего бизнеса, каким образом развивалось его осознание, и какие конкретные шаги были предприняты для перехода к сервисному подходу?
Харлан Волд: В первой половине 2009 г. было решено выделить ИТ‑департамент в самостоятельное подразделение — до этого он был частью департамента исследований и разработки. После чего была поставлена задача перевести его на сервисную модель. Конечно, было бы неправильно говорить, что понятия ИТ‑сервисов в компании не существовало. ИТ-подразделение все же предоставляло услуги внутренним заказчикам. Однако систематический подход к их разработке и последующему развитию, пожалуй, отсутствовал.
Выбирая методологию, мы ориентировались на мировые практики и проверенные стандарты — прежде всего, ITIL/ITSM и спецификации ISO. В качестве информационной системы технической поддержки было выбрано решение assyst компании Axios. Наш график развертываний ITIL-процессов можно, наверное, назвать консервативным: внедрение в глобальном масштабе рассчитано на 24 месяца. Помимо уже развернутых процессов Incident, Knowing и Problem Management, мы собираемся внедрить Asset Management, Change Management, Capacity Management, Knowledge Management, Service Level Management и некоторые другие. В настоящее время мы активно занимаемся развертыванием каталога услуг.
При переходе на сервисную модель мы прежде всего поставили перед собой задачу продемонстрировать, что ИТ-подразделение — не центр затрат, оно способно генерировать прибыль и повышать эффективность деятельности компании.
Одним из самых интересных направлений в контексте развития российского рынка ИТ-услуг нам представляется внедрение каталога сервисов. Во-первых, с точки зрения ИТ-поддержки он напрямую связан с развитием популярного ныне сервисного подхода в сфере ИТ. Во-вторых, сейчас на российском рынке практически ни у кого нет полноценного каталога сервисов вместе с программными средствами автоматизации их жизненного цикла. Хотя о его наличии действительно заявляют многие. Что бы вы могли сказать по этому поводу?
Конечный результат формирования каталога ИТ-услуг трудно вычислить. Методически «нарезать» функционал ИТ‑систем на некий набор ИТ‑сервисов в принципе довольно просто. Так же несложно определить, какие сервисы действительно востребованы со стороны бизнеса сейчас и какие будут пользоваться наибольшей популярностью в будущем: для этого необходимо определить, кто с ними работает, какова степень их критичности для бизнеса, каковы возможные соглашения об уровне предоставления сервисов (SLA) различным категориям пользователей. Далее в принципе можно создавать «интернет-витрину» или «интернет-магазин» услуг, в котором пользователи могут выбирать и заказывать ИТ‑сервисы. Однако это лишь малая часть работы: нам важно не только создать адекватный задачам бизнеса каталог ИТ-услуг и качественно их предоставлять по минимальной цене, но и стремиться к тому, чтобы ИТ-подразделение не было затратным.
Чтобы вычислить стоимость владения сервисом, необходимо знать, какие компоненты инфраструктуры или прикладных решений связаны с его предоставлением, а также иметь представление о его операционной и финансовой моделях функционирования. Также надо понимать, что исполнение ИТ-услуг неразрывно связано со сторонними рабочими процессами, которые не имеют ничего общего с ИТ-подразделением. Объясню на жизненном примере.
Когда, скажем, вы приходите в «Макдональдс» и заказываете некий набор из меню, через определенное время вам приносят готовые блюда — должного качества и по заранее оговоренной цене. Все это означает, что у ресторана есть каталог сервисов, которые не просто описаны, но и реально предоставляются. Ингредиенты, которые используются в приготовлении каждого блюда, также входят в каталог услуг. Однако и это еще не все. Чтобы блюда «перекочевали» из меню на поднос, необходимо исполнение четко отлаженных процессов на кухне ресторана — на этот этап человек, который составлял список блюд, повлиять не может. Это отдельная, самостоятельная проблема. И для ее решения необходимо, чтобы на кухне работали без лишних издержек при обычной загрузке, но имели возможность оперативно увеличить производительность в час пик. Или же понимали, что приготовление разных блюд может требовать одинаковых операций, и за счет их совмещения в ряде случаев можно добиться серьезного повышения эффективности. Да и оборудование имеет свойство выходить из строя или меняться на более совершенное — в связи с этим могут возникнуть простои, что тоже необходимо принимать во внимание. Где‑то автоматизация процессов может привести к хорошим результатам, где‑то пока целесообразнее управлять в «ручном режиме».
Примерно такого же рода проблемы должны решать и мы, предоставляя ИТ-услуги определенного качества по минимально возможной цене. Вопрос о целесообразности автоматизации процессов, лежащих в основе ИТ‑сервисов, необходимо решать в каждом конкретном случае. Как и в примере с рестораном, мы можем совмещать выполнение каких‑либо операций, если, скажем, в данный момент похожие ИТ-услуги затребованы несколькими пользователями. Иными словами, большой кусок работ сводится к очень тщательному документированию ИТ‑сервисов.
В настоящее время в нашем каталоге около 80 услуг, которые мы уже можем качественно предоставлять. Пока это совсем немного. Однако речь здесь идет если не о полностью автоматизированных, то уж точно о полностью документированных процессах.
Действительно, есть много нюансов, учет которых крайне важен для предоставления качественных ИТ‑сервисов при адекватной цене на них. Хотелось бы знать, какие процессы (входящие в спецификацию ITIL или нет) или методические приемы больше всего связаны с созданием полностью работоспособного каталога сервисов.
Я уже говорил о том, что мы наметили внедрение большого числа ITIL-процессов в течение ближайших двух лет, и большинство из них так или иначе имеют отношение к нашим планам по развертыванию ИТ‑сервисов. Вместе с тем, здесь мне представляется важной следующая логика. Наш бизнес постоянно развивается, и в контексте этого развития необходимо постоянно совершенствовать качество ИТ-услуг, чтобы их структура соответствовала будущим потребностям бизнеса. Существующий ИТ‑сервис вполне может породить несколько более мелких «субсервисов» или быть существенно модифицированным. Так появляются требования к изменениям или к инициации нового проекта: Request for Change или Request for Project.
Далее мы приходим к необходимости управления внутренним спросом на сервисы, или к процессу Demand Management.
В реальности требований много, удовлетворить все запросы сразу невозможно из‑за ограниченности ресурсов. Значит, мы должны расставлять приоритеты, учитывая, в частности, многочисленные взаимосвязи между сервисами через их компоненты (которые, кстати, тоже отражаются в каталоге). Эти задачи приводят уже нас к процессу Portfolio Management. В итоге ключевыми для нас оказываются Demand Management и Portfolio Management.
Есть также возможность изменять услуги, основываясь на запросах, которые генерируют пользователи, и на непрерывном мониторинге систем, которым занимается наше подразделение. Здесь уже становятся очень важными процессы Incident Management и конфигурационная база данных CMDB. С ее помощью появляется возможность оперативно установить соответствие между претензией пользователя и компонентом инфраструктуры, который некорректно функционирует, а также между диагностируемым нами недостатком функционирования ИТ-инфраструктуры и ИТ‑сервисом из каталога.
Сейчас мы сказали больше о методике, позволяющей начать работу над новыми сервисами и совершенствовать существующие. Можно ли также говорить о некоем проактивном предсказании необходимости разработки новых сервисов? Насколько важна тут активная роль ИТ‑департамента?
Безусловно, мы должны понимать, куда движется бизнес и какие ИТ-услуги ему, скорее всего, потребуются в перспективе. Если говорить о методической стороне этого вопроса, то здесь мы опять приходим к необходимости Demand Management, но не только. Как известно, наш бизнес основан на постоянном выпуске новых версий программного обеспечения в области информационной безопасности. Условно говоря, каждый год выходит новая версия продукта, что, конечно же, требует строго определенной трансформации ИТ‑сервисов, которыми различные подразделения нашей компании будут пользоваться как в процессе работы над новым релизом, так и после его выхода. Не надо забывать и о том, что мы ответственны за предоставление актуальных ИТ‑сервисов, в том числе и пользователям нашего продукта (например, интернет-регистрация, загрузка, обновление и т. д.). Вовлечение ИТ-подразделения в эту работу, тем более на глобальном уровне, опять‑таки трудно осуществимо вне методологической поддержки, и здесь нам помогают процессы Release Management. Резюмируя сказанное, еще раз подчеркну, что Demand Management и Release Management для нас играют фундаментальную роль при планировании новых сервисов, нацеленных на решение будущих бизнес-задач.
Важность данных процессов означает необходимость их автоматизации. Пока мы делаем это за счет внутренних разработок, но в будущем планируем перейти на промышленное программное обеспечение.
В приведенном выше примере с рестораном посетители с точки зрения их потребностей наверняка приблизительно одинаковы. Насколько важно то, что в случае с ИТ‑сервисами мы сталкиваемся с пользователями из разных направлений бизнеса, при этом отвечающими за свое направление на различном уровне? К тому же они могут быть из разных стран…
Верно, одна и та же услуга может использоваться, скажем, и финансистами, и специалистами в области продаж, и копирайтерами. Это штатная ситуация. Все они будут использовать сервис по‑разному, в контексте различных бизнес-процессов, и качество его предоставления с нашей стороны опять‑таки зависит от того, как он прописан.
Глобальность проекта ставит перед нами задачу оптимизации территориальной структуры предоставления ИТ-услуг. Для ее решения мы в первую очередь выделяем типичные сервисы, которые будут использоваться примерно одинаковым образом, и за счет этого максимально централизуем как их разработку, так и предоставление. В случаях, когда ИТ‑сервис специфичен и связан с местными особенностями (как, например, при составлении некоторых видов финансовой отчетности), его предоставление целесообразно концентрировать на региональном уровне.
Вместе с тем бизнес развивается, и не исключено, что какой‑либо ИТ‑сервис через определенное время может перейти в категорию глобальных. Возможна также обратная ситуация, поэтому обе упомянутые формы предоставления ИТ-услуг, очевидно, будут существовать и в будущем.
Каталог ИТ‑сервисов с «боекомплектом»
Михаил Кудряшов,
эксперт по управлению сервисными решениями департамента «Сименс АйТи Солюшенс энд Сервисез»Постоянные изменения в бизнесе, а также повышение требований к эффективности ИТ со стороны бизнеса влекут за собой необходимость трансформировать ИТ-инфраструктуру и локализовать области, требующие изменений и оптимизации. При этом каталог сервисов должен превратиться из простого перечня предлагаемых ИТ‑сервисов в инструмент, представляющий услуги как сервисы, часто называемые «облачными», с учетом мощностей, уровня сервиса, информационной безопасности и т. д. Тогда современный каталог ИТ‑сервисов действительно становится источником дополнительной ценности для бизнеса и работает вне зависимости от того, растет бизнес или претерпевает сокращения.
В боекомплект к каталогу ИТ‑сервисов должна быть включена еще и методология, отражающая трансформацию сервисов из активных в проактивные, направленные на качество и непрерывное совершенствование. Ее цель также — повышение продуктивности ИТ-инфраструктуры за счет использования инновационных решений. Работоспособность такой методологии обеспечивается применением стандартных процессов из ITIL, гибкостью используемых сервисориентированных ИТ-решений и направленностью на соответствие требованиям бизнеса.
Сервисы — это формализация отношений
Андрей Орлов,
директор стратегических проектов НЦИТ «ИНТЕРТЕХ»Вряд ли стоит спорить, что сосчитать и описать что‑то всегда стоит дороже, чем не считать и не описывать. Всякий учет становится осмысленным только в случае, когда он сопровождается определенными управляющими воздействиями. Поэтому и нечасто можно встретить ИТ‑службу, все сервисы которой были бы формально описаны на уровне ITIL.
Положение меняется, если одна организация оказывает другой ИТ-услуги на договорной основе. При заключении договора на техподдержку или сопровождение заказчик заинтересован в точном понимании, что ему должны предоставить по договору, а исполнитель предпочитает ограничить желания заказчика четкими рамками. Как раз в этот момент чаще всего появляются и формальные описания сервисов, и SLR («хотелки» заказчика), и SLA (условия, тщательно прописанные в приложении к договору), формируется цена каждого сервиса, сроки обработки любых обращений и даже штрафы за нарушение этих сроков. Тем интересней изучить опыт по организации, каталогизации и формализации описаний ИТ‑сервисов в подразделении, обеспечивающем поддержку не сторонних, а именно внутренних пользователей.
