Александр Налетов, заместитель начальника управления ИТ-инфраструктуры ОПО "ГМК Норильский никель": В основе работы — ИТ-сервис

Сервисный подход в ИТ сейчас очень часто ассоциируется с моделью ITIL/ITSM. Эти ассоциации вполне объяснимы и в целом справедливы. Но вместе с тем данный подход - еще и вопрос профессиональной культуры, формируемой в организации. Здесь предполагается, что собственное видение проблемы специалистами предприятия и внедряемая методология органично сочетаются. Об этом мы беседуем с заместителем начальника управления информационной техники и связи "Норильского никеля" Александром Налетовым.

Александр Налетов родился в 1970 году. В 1993 году окончил Московский инженерно-физический институт по специальности «Инженер-физик». В ОАО «ГМК Норильский никель» (ранее РАО «Норильский никель») начал карьеру в 1995 году в качестве ведущего специалиста. За последние годы занимался преимущественно технологиями корпоративной информационной поддержки и предоставления ИТ-сервисов, неоднократно повышал квалификацию в области ITIL/ITSM в компаниях HP и Pink Roccade. Имеет сертификат «ITIL Foundation». Также специализировался в области менеджмента качества и экологического менеджмента по стандартам серии ISO, проходя соответствующие курсы в Bureau Veritas. В настоящее время работает в должности заместителя начальника управления ИТ-инфраструктуры ОАО «ГМК Норильский никель». Женат, имеет сына.

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

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

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

Пока, еще раз подчеркнем, мы не трогали никаких стандартов и методологий, а только описывали схему, которая, как мне кажется, в некоторой структурированной форме определяет взаимоотношения ИТ и бизнеса. Наверно, она универсальна для большинства компаний. Имея в основе данную схему, можно говорить и о применении каких-либо спецификаций. Это и объемная серия международных стандартов серии ISO, посвященных жизненному циклу информационных систем, управлению качеством ПО, безопасности и прочего, или группа стандартов ГОСТ 34, ориентированная на создание и документирование ИС. На ту же канву ложатся уже популярная на российском рынке модель управления ИТ-сервисами ITIL/ITSM, а также относительно новая для него спецификация управления процессами в ИТ COBIT. Нельзя забывать и о нормативно-справочной информации в области управленческой деятельности.

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

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

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

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

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

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

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

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

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

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

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

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

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

Причем когда у вас N сервисов и М заказчиков, и при этом N и M - немалые числа, то проблема сильно усложняется. Иными словами, становится очень сложно непосредственно соотносить между собой те или иные информационные и бизнес-сервисы. Их, в свою очередь, необходимо детализировать методически обоснованными метриками в виде уже упомянутых SLA и OLA (operational level agreement). Для учета данного соответствия необходимо применять специализированные программные продукты, а впоследствии еще и тщательно анализировать результат. То есть и методические, и технические знания здесь очень пригодятся.

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

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

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

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

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

Поскольку мы говорим уже в значительной мере о предоставлении сервисов, то и проблему аутсорсинга я рассмотрю конкретно в применении к процессу поддержки пользователей. Здесь целесообразно сосредоточиться на известной классификации различных уровней поддержки, где каждый последующий уровень отличается от предыдущего большей глубиной и экспертизой. Самая первая линия поддержки, с которой сталкивается пользователь, - уровень операторов Service Desk. Аутсорсить эту службу в каких-то случаях выгодно, в каких-то - нет. Если у вас большая территориально распределенная компания и значительную роль в ее бизнесе играет эффективно действующий Call-центр, то, скорее всего, есть смысл применить схему аутсорсинга. Но вообще многое зависит и от емкости того же call-центра, конкретного спектра задач, стоящих перед ним, и пр.

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

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

И наконец, специалистов еще одного уровня поддержки (назовем его четвертым), наоборот, аутсорсить можно и в большинстве случаев нужно. Речь идет о профессионалах высокого уровня, "гуру" по одному из технологических направлений. Например, в области СУБД. Такой специалист нужен далеко не каждый день, но периодически будет требоваться обязательно. Оптимально здесь приобрести часть ресурсов данного специалиста, но обязательно вместе с гарантированным уровнем сервиса, то есть с предусловием, что проблемы будут устраняться с должным качеством и в нужный срок.

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