Часто международными стандартами ISO становятся британские разработки, носившие раньше наименование BS с соответствующими индексами. С этого же острова пришла к нам и ITIL. Нужны ли России собственные наработки по стандартизации управления ИТ‑услугами, аналогичные ITIL? И как переводятся и утверждаются западные стандарты? Об этом в интервью нашему журналу рассказал председатель комитета по переводам и публикациям русского ITSM‑форума (itSMF) Александр Жилинский.

Intelligent Enterprise: Существует ли отечественный стандарт по управлению ИТ-услугами? Нужен ли он в принципе?

Александр Жилинский: У меня нет информации о том, что в каких‑либо коммерческих или государственных организациях существуют проекты по разработке любого вида стандартов, связанных управлением ИТ-услугами. ГОСТа, который охватывал бы ИТ-услуги, пока не существует. Я могу не знать о каких‑то маленьких проектах, но о серьезных крупных разработках наверняка бы знал.

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

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

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

Тогда необходимы переводы западных стандартов и библиотек, как обстоят дела с ними?

Проекты переводов, находящиеся сейчас в активной фазе, легко можно пересчитать по пальцам одной руки. В основном пока это только некие части библиотек и стандартов. Перевод глоссария третьей версии ITIL находится на стадии одобрения финансирования, выход одной из книг библиотеки на русском языке планируется в начале 2009 года. Как обычно, в подобных проектах сложен не сам перевод — это довольно стандартная задача, — а одобрение (quality assurance) и прочие танцы с бубном вокруг компании — владельца прав (OGC), которая обязательно будет внимательно смотреть получившийся текст. К любой локализации, переводу на национальные языки они предъявляют глобальные требования вплоть до качества бумаги, на которой книга будет напечатана. Есть переведенное введение в ITSM («белая книга») под редакцией Михаила Потоцкого (IT Expert), в работе над которой принимало участие большое число людей. Компания «Ай-Теко» перевела «синюю книгу» Service Support ITIL v.2.0. Причем обещания по срокам были значительно более оптимистичными, чем получилось в итоге, — о том, что книга вот-вот выйдет, я слышал как минимум два года. На самом деле переводили они две книги, то есть еще и Service Delivery, но пока перевели первую, пока одобрили, провели контроль качества, уже вышла третья версия библиотеки, и не было смысла продолжать работу над выпуском в печать книги по Service Delivery из второй версии. Еще есть слухи о том, что существуют русскоязычные книги ITIL v.2.0, переведенные в прибалтийских республиках, но я их не видел, поэтому не верю в их существование.

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

Кроме ITIL cуществует перевод стандарта ISO 20000, работу над ним сейчас продолжает та же ИТ-компания. В этом случае она переводит стандарт не для себя, а для Федерального агентства по техническому регулированию и метрологии. Цель этой работы — на основе перевода международного стандарта создать наш государст­венный (ГОСТ Р ИСО/МЭК 20000). Точно так же, как уже было сделано с ISO 9000. Этот проект национального стандарта прошел публичное обсуждение и в настоящее время теоретически уже должен был пройти экспертизу в техническом комитете 22 Федераль­но­го агентства по техническому регулированию и метрологии. Стандарт включен в проект «Перспективной программы развития национальных стандартов, обеспечивающих их гармонизацию с международными стандартами в научно-технической и производственной сферах, на 2008—2012 годы» России.

Кроме того, есть перевод COBIT 4.1, выполненный группой ISACA. Здесь, условно говоря, было переведено только ядро стандарта, оболоч­ка — практические руковод­ства — пока осталась без перевода. Также существует перевод семейства стандартов 27000, которые у нас продвигает BSI. Вот и все по крупным переводам, как обещал, хватило пальцев одной руки.

Совершенно понятно, что стандарты рано или поздно будут признаны, и пе­­ревести их будет нужно. К со­жа­ле­нию, я не знаю никаких конкретных сроков окончания подобных работ. Я всегда очень хорошо относился к ГОСТам российского производства, и до сих пор есть множество людей, как ста­рой закалки, так и молодых управ­ляющих, которые это отношение разделяют — хотя и не делают из ГОСТов культа. В том случае, если либо будет разработан собственный ГОСТ для ИТ-услуг, либо ISO 20000 будет переведен и удачно встроен в систему ГОСТов, вопросов по необходимости использования не возникнет.

Если в таких всеохватных вещах, как стандарты и библиотеки, как вы говорите, национальной специфики нет, то давайте перейдем к более детальным вещам. Например, существуют ли отечественные методики оценки эффективности ITSM-проектов?

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

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

Есть ли методика оценки стоимости предоставляемых ИТ-услуг?

Когда‑то я принимал участие в одном из первых проектов по внедрению каталога услуг и базы процесса управления уровнем обслуживания (SLM) для аутсорсинговой ИТ-компании. Как это часто бывает, работы затронули часть управления финансами, и у компании встал вопрос, каким образом обосновывать стоимость ИТ-услуг. Работающим на свободном рынке подрядчикам проще, с ценообразованием им помогает сам рынок. Тем не менее часто такая задача вызывает довольно много вопросов у компаний-аутсорсеров, ко­торые недавно выделились и находятся на обеспечении материнской компании. Сейчас количество таких проектов взрывообразно растет. Компания‑аут­сорсер выделилась, бывшая материнская компания поработала с ней год, потом аутсорсер изменяет цены. Возникает вопрос: как понять, насколько обоснованно она их изменяет? Одним из ответов может быть наличие утвержденных авторитетным источником норм времени на выполнение различных ИТ-задач. Есть постановление Министерства труда и социального развития РФ, но, к сожалению, последняя редакция этого документа датирована 1998 годом (http://linux.nist.fss.ru/hr/doc/gtk/met28. htm), а подобные вещи очень быст­ро устаревают. В постановлении, например, могут быть нормы времени по обслуживанию рабочих станций Windows или Unix, но в него тогда не могло попасть обслуживание нового телекоммуникационного оборудования или современных сложных программных систем. Если бы такое ГОСТирование операций поддерживалось в актуальном состоянии, то можно было бы достаточно легко доказать свои контрактные цены. Представьте, у вас есть утвержденная сетка нормативов, согласованные ставки сотрудников разной квалификации, и достаточно привязать их к нормативам — и ценообразование проведено. Я знаю, что некоторые компании разрабатывали подобные нормативы, заказывая их в том числе и у бывших государственных институтов, которые в прошлом сами занимались разработкой ГОСТов.

Если актуального документа нет, то как ИТ-директорам выходить из этой ситуации?

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

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

В itSMF существовала группа, пытавшаяся продвинуть разработку такого проекта, но, увы, — его сложность в разы превышает сложность того проекта обоснования стоимости проектов, о котором мы уже говорили.

Что может ускорить разработку или переводы стандартов и библиотек по управлению ИТ-услугами?

Требования регулятора. Как только Нью-Йоркская биржа (NYSE) ввела требования SOX (Sarbanes-Oxley Act), компаниям, чьи акции торгуются на ней, пришлось проходить аудит, а перед этим проводить внедрения. И один из вариантов, когда возникнет жесткая необходимость в разработке собственных стандартов, — это требование рынка. Если один из наших регуляторов (не обязательно связанный с фондовым рынком) или, допустим, лондонская биржа, на которой торгуются акции наших компаний, введет требования, связанные в том числе и с управлением ИТ-услугами, то количество связанных с аудитом проектов вырастет в разы. Хотя в связи с текущей ситуацией на фондовых рынках регуляторам есть чем заниматься и кроме этой задачи.

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