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

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

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

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

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

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

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

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

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

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

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

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

Игорь Баринов: Я считаю, что бизнес продолжает предъявлять такие же требования к уровню качества, хотя и сократил определенную часть бюджета. Высшее руководство ведь не думает в терминах SLA — договоренностей об уровне обслуживания. Для них нормально сократить бюджет, с одной стороны, а с другой — требования оставить прежними.

Марина Аншина: Я снова не соглашусь. Сначала об определении текущей фазы кризиса. Организации разные, и фазы кризиса все проходят по‑своему, тут нельзя всех стричь под одну гребенку. Я считаю, что подход «сидим и ждем, когда кончится кризис» — совершенно неправильный, если все будут ждать, то ситуация будет только ухудшаться.

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

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

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

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

Кому, когда и зачем нужна формализация

Илья Садовенко
ИТ-директор компании «Монди Сыктывкарский лесопромышленный комплекс»

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

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

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

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

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

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

Intelligent Enterprise: Из нашего исследования «ИТ в условиях кризиса» (октябрь 2008 года) следует похожий вывод. Порядка 50% респондентов указали на то, что нужно усилить стандартизацию и методическое обеспечение ИТ-процессов. Косвенно это свидетельствует и о понимании необходимости этого со стороны бизнеса.

Мы переходим ко второму вопросу, который касается изменения целей проектов по постановке и автоматизации процессов управления ИТ-услугами. Цели сейчас неминуемо должны стать немного другими. Хотя бы потому, что чуть ли не главная задача — сокращение затрат, а не, например, повышение качества ИТ-услуг. Фокус смещается в сторону сокращения затрат. Как меняется целеполагание проектов по постановке и автоматизации процессов управления ИТ-услугами в тех изменившихся условиях, о которых мы только что сказали? Что движет этими проектами сейчас?

Марина Аншина: Мы сейчас определенные ИТ-процессы пытаемся выстроить именно для сокращения затрат. У нас холдинговая структура, и сегодня усилились требования к централизации ИТ. Чаще стали обращаться директора заводов, они стремятся к централизации ИТ потому, что трудно управлять накладными расходами. Для меня это было неожиданно, но стремление к централизации, большей управляемости ИТ со стороны бизнес-руководства очень заметно. Больше управляемости и прозрачности — вот важнейшие изменения приоритетов и целей проектов постановки управления ИТ-процессами.

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

Владимир Ананьин: Давайте подумаем, действительно ли ITSM необходим в данной ситуации. Ведь он не так широко распространен, как принято считать. Летом прошлого года на заседании itSMF представители Gartner Group докладывали результаты исследования использования ITSM. Так вот, не более 20% крупных компаний в мире ответили, что они планируют с этим работать и движутся в сторону управления ИТ-услугами. Остальные 80% с ITSM не работают, не рассматривают его как что‑то существенное. Ну а если посмотреть на средний бизнес, то там уже остается только порядка 10% планирующих использовать ITSM.

Почему это происходит? Потому что у сервисного подхода в области ИТ на конкретных предприятиях есть естест­венные пределы: они могут охватить лишь отдельные задачи. Из приведенных Gartner Group данных понятно, что есть другие формы управления. Они были хорошо известны задолго до появления ITSM — это работа по исполнению функциональных обязанностей. В этом случае никто ни с кем не договаривается, а есть задачи, которые должны быть решены, и они описаны в должностных инструкциях. Это весьма распространенная схема, которая не исчезла. Еще один метод управления — работа по прямым поручениям, особенно распространенная в мелком бизнесе. Он сосуществует с сервисным подходом, каждый из них занимает свою область.

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

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

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

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

Цифры 10—20% до обидного маленькие и не соответ­ствуют моему личному опыту. Я знаю многие компании на разных стадиях развития ИТ, но чтобы кто‑то из них сказал «зачем нам нужен ITSM?» — таких практически нет. Должностные инструкции есть на любом более-менее развитом предприятии. Система поручений тоже. Однако руководство, формулируя требования к ИТ, не может учесть специфику этой области. Поэтому некий договорной процесс, а в области поддержки это управление SLA, — необходим. Представим гениального руководителя, который прекрасно понимает ИТ и может сказать: «Ребята, не забудьте сделать резервную копию, потому что сейчас будут большие изменения». Таких практически нет, с такой детализацией задачи бизнесом не формулируются. Хотя и в такой постановке для системного администратора задача определена не до конца. Ему самому придется решить, какой тип копирования выбрать, как хранить копию, надо ли сделать пробное восстановление и т. д. Нормальные руководители это понимают, поэтому и внедряется ITSM. Библиотека ITIL основана на определенных правилах, проверенных международным опытом и временем. И самое главное в ней — трансляция прин­ципов специалистам, которые осуществляют процессы поддержки. Если это нарушено, то перестают работать процессы. Вы обнаруживаете, что Service Desk буксует, регистрируются только отдельные заявки. Так что вроде бы всё то же самое, все работают по инструкциям, но содержание совсем другое.

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

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

Конечно, линейное управление, тем более в России — это основной вид управления. Все знают, кто платит зарплату, а владелец процесса никогда ничего никому не оплачивал. Он только пытается договориться с начальниками отделов, чтобы они позволили своим подчиненным участвовать в работе процесса. Но это не всегда получается. И здесь надо понимать, что линейный элемент является основным (начальники всегда говорят со своими подчиненными языком поручений), а процессный, управление ИТ-услугами, — только дополнительным.

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

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

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

Если говорить о том, кто платит, то, например, у нас мотивация ИТ‑специалистов привязана к сервисной модели. Зарплата рассчитывается по выполнению должностных обязанностей, а премия выдаётся за качество сервисов. А это немало — порядка 30% от общей оплаты.

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

Самой значимой частью сервисной модели и отправной точкой является каталог услуг

Владимир Павлов
Эксперт центра исследований «Итилиум»

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

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

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

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

Intelligent Enterprise: Хоть мы и не пришли к единому мнению, но тем не менее нам надо двигаться дальше. Давайте переведем разговор в более практическую плоскость. На каких процессах (или обеспечении исполнения каких поручений) сейчас стоит концентрироваться в наибольшей степени? Где те точки, на которые нужно обращать внимание сегодня? Существует ли компактная серебряная пуля, позволяющая заметно повысить эффективность управления ИТ-услугами в нынешней ситуации? Можно ли говорить о том, что в кризисное время возрастет удельный вес каких‑либо отдельных процессов управления ИТ и управления ИТ-услугами? Если да, то каких и почему? Насколько велик набор этих процессов и можно ли говорить о сведении методологии к небольшому подмножеству процессов?

Игорь Баринов: Да, методологию нужно сжать. Не стоит заниматься внедрением ITSM по принятым правилам. Сейчас надо искать в ИТ‑департаменте узкие места («бутылочные горлышки») и ликвидировать их за счет «подкручивания» процессов управления. Эти узкие места, как правило, касаются одновременно нескольких таких процессов, вот ими и надо заниматься. При этом не важно, слышали в компании об ITSM раньше или нет, они все равно будут заниматься повышением операционной эффективности, а значит, идти по пути ITSM.

Марина Аншина: Я бы, наоборот, не советовала производить такие точечные вмешательства. В сфере процессного управления считается, что малоэффективно искать точечные проблемы в бизнес-процессе и пытаться их устранить. Решите в одном месте — проблема появится в другом. Весь процессный подход восстает против этого. Надо подняться над бизнес-процессом, взглянуть на него со стороны, увидеть его неэффективность, проанализировать, договориться с высшим руководством о цели и только после этого выстроить оптимальным образом. Или другой подход: посмотреть на существующий бизнес-процесс, выявить, что в нем неэффективно, и построить его заново. Именно он с точки зрения процессного управления и считается оптимальным.

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

Если говорить о компаниях, которые еще ничего не внедрили с точки зрения ITSM, то на мой взгляд наибольший быстрый выигрыш для них может принести Help Desk. Вы никак не учитываете инциденты и вообще не знаете, что у вас происходит? Тогда берите обычный Excel, сажайте человека на первую линию поддержки и начинайте фиксировать заявки и инциденты. Через три месяца созреете для внедрения более серьезной системы. Может, и быстрее, по моему опыту такие таблицы жили от двух до четырёх недель. Вы начинаете управлять тем, что у вас происходит, начинаете видеть картину, можете проанализировать, как работать эффективнее, объяснить бизнесу, куда вы тратите деньги.

Игорь Баринов: Марина, возможно, у вас сейчас болевая точка именно в области управления изменениями. Но усредненная ситуация другая. Первая волна ITSM-внедрений прошла. В каком‑то виде у всех есть Service Desk, управление изменениями и другие процессы второй версии ITIL. И вот это усредненное предприятие подошло к кризису. У ИТ-отдела два портфеля: сервисный и инвестиционный, затраты на эксплуатацию и на развитие. На развитие в 2009 году ничего не дали, поэтому можно забыть про управление изменениями и заняться совершенствованием эксплуатационных процессов. Я рекомендую развивать управление проблемами исходя из того, что управлять инцидентами все уже умеют.

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

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

Intelligent Enterprise: Но построение каталога ИТ-услуг очень не простая задача. Её рекомендуется решать в несколько итераций, постоянно контактируя с бизнесом. Время ли сейчас для этого?

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

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

Владимир Ананьин: Я тоже думаю, что сейчас необходимо заниматься каталогом ИТ-услуг. Среди того, что нужно сейчас, во‑первых, уже называвшийся Help Desk. Это первая и самая простая вещь, с нее все и начинают в большинстве случаев. Главная цель при этом — создать единое окно взаимодействия с бизнесом на уровне пользователей. А на уровне менеджмента единым окном как раз служит каталог услуг. Мне тоже кажется, что полезно составить этот каталог.

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

Марина Аншина: Я считаю, что на самом деле готовность бизнеса договариваться — это и есть задача ИТ-директора. Если договариваться невозможно, то я просто не буду работать в этой компании. Что там делать, если я как ИТ-директор не могу договориться с бизнесом? Значит, я не справляюсь со своими обязанностями. Совершенно не эффективно работать в командно-приказной системе, и особенно в условиях кризиса. Это моя принципиальная позиция. Мне кажется, что любой представитель бизнеса скажет: если у меня есть кадровые проблемы и я не могу договориться с ИТ-подразделением, то эти кадровые проблемы надо решать известным образом. Это все равно что не договариваться со своим маркетинговым подразделением, которое не может запланировать продажи. Если не можешь договориться, то меняешь либо подразделение, либо руководителя. А ITSM как раз и является способом эти договоренности сформулировать, проконтролировать и сделать понятными для бизнеса.

Игорь Баринов: В конце нашей встречи я хочу заявить, что кризис — это повод. Делайте ITSM правильно, нанимайте консультантов‑практиков, а не консультантов‑теоретиков и вместе с ними, избегая тактики фронтальных наступлений, наносите точечные удары по беспорядку и разгильдяйству, наводите порядок. Когда кризис закончится — а он обязательно закончится, — у вас будет крепкий операционный конвейер, и тогда вы с увлечением займетесь инвестиционными проектами, на которые вам дадут денег во второй половине 2010 года.

Отсутствие грамотного управления необходимыми изменениями — проблема общая

Александр Жилинский
Председатель комитета по переводам и публикациям русского ITSM‑форума, консультант департамента консалтинга и интеграции «ИНЛАЙН ГРУП»

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

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