"От информационных технологий к информационным сервисам"

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

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

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

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

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

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

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

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

— Как, на ваш взгляд, сегодня обстоят дела в области ITSM в России?

У наших компаний пока весьма ограниченный взгляд на ITSM, несмотря на то что с выходом ITIL 2011 (ITIL v.3.1) сделан очень большой шаг вперед. Во многом это вопрос времени, ведь прошло всего полтора года после того, как ITIL v.3 была переписана в более прикладных понятиях, в первую очередь книга Service Strategy, и новаторские идеи стали доступны для понимания широкому кругу читателей. Но это, повторяю, вопрос времени.

Пока еще большинство видят в ITSM три-пять базовых процессов. Почему так происходит? Ответ очень простой. Причина в том, что предмет сервиса у многих компаний весьма низкоуровневый: техническое обслуживание серверов, рабочих мест, принтеров, то есть базовый труд специалистов. Это не значит, что он не важный! Это основа построения сервисов, имеющих большую ценность! Но такие инфраструктурные сервисы не требуют создания развитой системы управления. Для них самый актуальный процесс – это управление заявками и нештатными ситуациями (внеплановыми событиями). Зачем нужен процесс управления доступностью сервиса, если под сервисом понимается просто техобслуживание оборудования? Этот процесс реализуется на более высоких организационных уровнях. Доступность — понятие, применимое как минимум для ИТ-систем, а вообще говоря, для информационных сервисов. Очень часто информационный сервис на рабочем месте пользователя агрегирует несколько ИТ-систем. Если так понимать сервис, то, конечно, начинает возникнет необходимость целого пласта процессов, включая управление доступностью, управление непрерывностью, управление мощностями, не говоря уже о базовых операционных процессах ITIL.

— Как изменить эту ситуацию?

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

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

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

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