Детальное описание действий IT-отдела — базовый набор документации

Во многих западных странах IT-аутсорсинг регулируется либо отраслевыми стандартами, либо вообще на госуровне. У нас такого нет. Поэтому за несколько лет был собран документ, который детально определяет термины в IT-аутсорсинге и расписывает, что в какой тип работ конкретно входит. С его помощью мы документируем работы, а потом чётко и прозрачно считаем, что сколько стоит.

Вот глоссарий терминов ^[1], а вот каталог IT-услуг ^[2]. Эти документы можно свободно скачивать и использовать. Особенно рекомендую это руководителям IT-подразделений.

Ниже я расскажу, зачем мы всё это сделали, и для каких случаев документ будет очень полезен.

В каких случаях чётко понятно, что стандарт нужен?

Например, недавно к нам пришла задача организовать IT-поддержку открытия филиалов одной компании. Заказчик определил, казалось бы, совершенно четкие задачи – нужно было расставить оборудование в офисах, подключить его к сети и убедиться, что всё работает.

Достаточно просто, правда? Но есть один момент — на стадии заключения договора выяснилось, что мы говорим о совершенно разных вещах. Например, в его понимании «подключиться к сети» — это не, условно говоря, «воткнуть вилки в розетки», а смонтировать сами эти розетки, да и вообще всю СКС. С нуля.

Думаю, вам прекрасно знакома такая ситуация. Проблема в том, что нет единого стандарта того, что входит в те или иные работы. Мы такой стандарт очень долго собирали. Получился каталог, который точно описывает каждый тип работ. Чтобы и вы, и заказчик говорили на одном языке.

Почему важно точно понимать, что входит в услугу?

Вот, например, вы договариваетесь с клиентом о том, что обеспечиваете сетевую печать (среди всего прочего). У него небольшой офис, 50 рабочих мест, три принтера. Поначалу всё просто и понятно. Через год клиент расширяется, снимает ещё одно большое помещение в другом здании. Вам уже нужно разграничивать доступ к принтерам. Затем приходит понимание, что не все сотрудники имеют право печатать на всех принтерах поблизости — и нужно уже более жесткое разграничение прав. Ещё через полгода ваш клиент переезжает, и вам предлагаю перетащить все принтеры на новое место. Почему? Потому что вы обеспечиваете сетевую печать (вот договор), а без принтера это сделать сложно.

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

Зачем нужен такой стандарт?

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

Что можно сделать с помощью каталога?

• Чётко определить, что входит в каждую услугу и как всё это называется. Это важно для составления договора между компаниями, например.
• Понять какие работы в какую услугу входят. Это важно для подсчёта стоимости. Кстати, бухгалтерия клиента будет спокойна: наконец-то ей объяснят, за что именно идёт оплата. Найти общий язык с бухгалтерией — бесценно.
• Сформировать требования к услуге. Каталог в данном случае — это фреймворк, где можно пользуясь едиными принципами описать комплексный проект любой сложности.

Когда каталог не нужен

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

Как бывает обычно при заключении договора на IT-аутсорсинг

Есть три основных варианта:

• Первый, запущенный: сидит большой IT-отдел, в котором совершенно непонятно кто и за что отвечает. Обязанности не делятся, приоритеты расставляются по непонятным признакам, долговременного планирования чаще всего нет. Для структурирования работы открываем каталог и выписываем все процессы, которые выполняются отделом. Бардака после этого становится в разы меньше. При необходимости из этого «клубка» процессов можно «выпутать» часть работ, например, только по поддержке железа в исправном состоянии — и отдать их на аутсорсинг внешней компании.
• Второй вариант, нейтральный. Руководство компании когда-то вложилось в консалтинг, и им поставили процессы как надо. Например, есть грамотное управление инцидентами, есть распределение обязанностей, есть чёткое понимание, кто и что делает. При этом после 2005 года ничего не менялось. Я встречал случаи, когда полностью менялась прикладная система, но процессы поддержки остались теми же самыми, что и раньше. При этом любая новая задача воспринимается как добавление «костыля». Такими «костылями» стремительно обрастает весь отдел. Как правило, после обновления процессов и документации отдел начинает работать куда эффективнее.
• Третий вариант, позитивный. Обычно — западные компании, у которых всё разложено по полочкам. Западная модель просто завозится в наш филиал, IT-отдел работает в рамках этой модели, все довольны. Иногда нужно отдавать часть работ на аутсорсинг. В этом случае точное описание того, кто, как и что делает, очень помогает.

Как это выглядит со стороны заказчика?

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

Как это выглядит со стороны ИТ-директора?

Для руководителя крупного IT-подразделения есть ещё одна вечная головная боль — пересечение ответственности команд или контрагентов. Когда косяк появляется там, где непонятно, кто отвечает за участок, одна команда валит на другую. Знаете, когда у строителей идёт трещина, они думают: «Да ладно, потом за нами штукатуркой закроют». Приходит вторая команда, и думает: «Да ладно, потом сайдингом закроют».

В IT-отделе чёткое распределение обязанностей между командами и контрагентами позволяет чётко же понимать, кого и за что пинать. И насколько сильно или дорого. Проще говоря, каждая ошибка обзаводится фамилией и, если надо, стоимостью.

Кто делал этот документ?

Комитет по стандартам и методологиям аутсорсинга Некоммерческого партнёрства «АСТРА» (задача — правовая поддержка IT-аутсорсинга) и КРОК (№1 в России по услугам системной интеграции по отчётам IDC 2002-2012). При подготовке учитывались обширная практика КРОК и международный опыт крупнейших профессиональных объединений IAOP (США) и NOA (Великобритания).

Автор: Alexander_Fineboym

Источник ^[3]