Возьмем торговую компанию со штатом в 100 человек, которую благополучно обслуживает ИТ-аутсорсер. Но благополучие это сохраняется лишь до тех пор, пока компания не начнет расти, и у нее не появятся новые ИТ-сервисы, от которых будет зависеть ее основная деятельность. Например, CRM-система, которая сразу поднимает количество запросов и инцидентов, скажем, на 10%.

Чтобы обработать их, организации придется докупить у своего поставщика ИТ-услуг полное время еще одного сотрудника, ведь другие занятые на проекте специалисты до отказа загружены работой (в этом аутсорсер кровно заинтересован). В лучшем случае заказчику предложат «половину человека», но она обойдется ему удельно дороже на 20-30%, т.к. аутсорсеру нужно будет покрыть свои затраты (на дорогу специалиста к клиенту и др.). При этом приобретенный втридорога сотрудник, благополучно закрыв все заявки по CRM, скорее всего, остальное время будет простаивать. А купить не 50–100%, а нужные ему 10% времени специалиста заказчик, по условиям договора, не может.

Ресурсная модель преимущественно используется компаниями с невысокой зрелостью ИТ
или претерпевающими ряд непрерывных изменений

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

Все ниже и ниже: ресурсная модель вместо сервисно-ориентированной

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

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

Более выгодной в этой ситуации для заказчика оказываются сервисная или сервисно-ориентированная модели ИТ-аутсорсинга. В них клиенту не нужно покупать сервис «большими кусками» — по 50% или 100% времени от специалиста на полный день. Заказчик просто добирает необходимый объем услуг в 10-20%, и получает их. Причем, с заданным уровнем качества. Затраты возрастают пропорционально. Причем заказчик может скомпенсировать этот рост за счет контролируемого снижения SLA или перехода к схеме SmartSLA, если провайдер ИТ-аутсорсинга располагает соответствующей технологией.

Качество ИТ-обслуживания: как получить нужное

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

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

Три модели обслуживания: главные характеристики и отличия

Сервисная модель: супер-стандартизация как главный принцип

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

Также у услуг в этой модели есть понятный принцип ценообразования. Например, 800 руб. в месяц за поддержку одного рабочего места. 50 руб. за одно решенное обращение. Штраф исполнителю 1000 руб. за каждый час просрочки.

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

Допустим, крупный заказчик — западная фармацевтическая или FMCG-компания, представленная в России, — покупает услуги первой линии техподдержки (прием и диагностику обращений и ИТ-инцидентов по почте, их решение в рамках SLA, установленных глобальным офисом), а также эскалацию более сложных проблем на вторую линию. В услугу входит и база знаний, к которой обращаются ИТ-специалисты. Там очень мало или почти нет опыта глубокого экспертного уровня. Но его достаточно, чтобы решать 50–70% запросов и придерживаться согласованных с заказчиком параметров качества, оставаясь в жестких рамках бюджета, а также максимальной стандартизации обслуживания — с помощью понятных регламентов и инструкций. В этой схеме уровень качества стабилен и не «завязан» на конкретного исполнителя — если они меняются, ИТ-сервис от этого не страдает.

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

Совсем не редкость, когда на решение заявки с высоким приоритетом, если она не относится к общекорпоративным сервисам (ERP или электронная почта), отводятся часы или даже дни, и это будет «ОК» с точки зрения SLA. Есть даже примеры, когда стандарты сервиса процветающей международной компании вовсе не регламентируют время решения запроса.

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

Сервисно-ориентированная модель: рождение нового на стыке парадигм

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

Новая парадигма в действии: как это работает и что получает заказчик

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

В этом случае генеральный директор уже через 20 минут получит новый аккумулятор для ноутбука, а не будет ждать стандартные 8 часов, отведенные SLA. А команда, вернувшись в «сервисный режим», начинает планомерно общаться с сервисным центром, системно решая задачу.

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

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

Выбор модели ИТ-обслуживания: заключение контракта или скрытые ИТ

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

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

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

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

Итого: три способа решения ИТ-задач

На практике все три модели ИТ-обслуживания сегодня мирно сосуществуют на нашем ИТ-рынке. Но распределение популярности ресурсной, сервисной и сервисно-ориентированной моделей для разных сегментов рынка сильно различается. Так, около 50% средних сервисных и производственных компаний, особенно если уровень их ИТ-зрелости ниже среднего, склоняются к ресурсной модели, «арендуя» нужных специалистов. Почти 80% крупных международных компаний, например, фармацевтических или FMCG с представительствами в России — склоняются к явной сервисной или замаскированной сервисно-ориентированной. Аналогичным образом обстоят дела у розничных сетей: крупный ритейл тяготеет к сервисной и сервисно ориентированной моделям, а средний, развивающийся — к ресурсной.

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

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