Какие показатели закрепить в SLA с ИТ-подрядчиком

Какие показатели закрепить в SLA с ИТ-подрядчиком — Изображение AI

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

Елена Суховей, генеральный директор цифровой платформы быстрых закупок «Максмарт» рассказала, почему хороший «уровень сервиса» определяется отсутствием споров о цифрах.

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

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

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

Уровни и различные показатели SLA. Зачем нужна детализация?

Первый уровень SLA определяется показателями работоспособности системы. Основными показателями работоспособности являются: 1. доступность системы 24/7 и 2. скорость исправления критических ошибок, таких как ошибки в работе системы или, в случае использования интегрированного маркетплейса, ошибки в работе интеграции, которые могут блокировать передачу заказов на маркетплейс или не давать передать, например, заказы на поставку из маркетплейса в ERP клиента. Использование данных двух параметров SLA гарантирует компании-клиенту, что пользователи платформы будут получать круглосуточный доступ к сервису и процесс закупок будет проходить без технических ошибок. При этом сами параметры могут зависеть от частоты использования клиентом системы. Если клиент пользуется системой в выходные дни, то служба поддержки вендора, которая предоставляет ПО, должна работать в выходные и принимать входящие заявки и сообщения. Скорость реакции на заявки должна составлять в среднем не более двух рабочих часов. Срок исправления технических ошибок также должен оговариваться часами, а не сутками. При этом с учетом разного уровня критичности внедренного ПО данные цифры могут измеряться не часами, а минутами. Если возникает критическая ситуация, например, падение системы, то срок поднятия системы, конечно, должен исчисляться не более, чем одним часом, но чаще минутами. Если это более простые сбои системы, серьезно не влияющие на операционную деятельность, то они могут решаться в течение нескольких часов.

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

Таблица усредненных показателей по КПЭ (Стороны могут устанавливать собственные временные сроки на каждый из показателей)

Какие показатели закрепить в SLA с ИТ-подрядчиком. Рис. 1

Второй уровень SLA определяется непосредственно направленностью ИТ-продукта.

У нас, например, платформа маркетплейса является сложной структурой не только с точки зрения ИТ-продукта, но и в рамках операционного управления. Мы берем на себя аутсорсинг-закупок, которые идут с помощью интеграции через наш продукт. Закупки должны быть выполнены в срок, поставлены в нужном объеме и с требуемым качеством. Для контроля обеспечения необходимых SLA по закупкам используются такие показатели, как OTIF, % рекламаций, сравнение цен с предыдущей ценой закупок или плановой ценой, конкурсность на платформе. Это одни из основных SLA, которые фиксируются в договоре.

Приведу пример взаимодействия платформы и одного из наших клиентов – промышленного холдинга как раз по показателю OTIF. У нас был ни один случай влияния клиента на данный показатель. OTIF считался клиентом от даты формирования заказа, а не от даты согласования клиентом подтвержденного заказа. Между формированием заказа и дальнейшем согласованием заказа внутри клиента прошло 15 дней, после этого ждали подтверждения наличия товара и даты поставки от поставщика, что заняло еще сутки. В результате заявленный OTIF был не выполнен с точки зрения клиента, так как отсчет по дате был произведен некорректно. Во избежание таких ситуаций мы, как платформа, с такими клиентами, которые настаивают на том, чтобы учитывать дату согласования, занимаем позицию, что OTIF считается только после даты, согласованной со стороны клиента. Иначе, как в приведенном случае, происходит манипуляция, и клиент может долго согласовывать заказ, а потом выставлять штраф. Это нужно учитывать в операционной работе. Такие кейсы мы проходили неоднократно с несколькими крупными холдингами и далее корректировали SLA.

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

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

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

Таблица усредненных показателей по КПЭ (Стороны могут устанавливать собственные договорные КПЭ на каждый из показателей, так как не существует установленных нормативов)

Контроль и ожидания бизнеса

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

В качестве примера, можно привести наш опыт работы с одним из крупнейших угледобывающих российских холдингов. У них есть отдельное юрлицо, у которого есть определенные KPI по отслеживанию SLA по нашим поставкам, в том числе по срокам. Как это работает и в чем риск для B2B-маркетплейса, например? Ответственное подразделение берет все заказы, которые размещены с датами поставки на платформе. Далее сравнивают сроки поставки и если есть превышение срока по условиям, то выставляют штраф за недопоставку в срок. Риск может быть в том, что поставка с задержкой может быть по разным причинам, которые зависят не только от подрядчика, но и от бизнеса, а в числе причин могут быть даже неправильно выгруженная статистика и данные, некорректное отражение статуса поставки в системе и другие причины. Обычно после этого начинается долгий анализ и разбор и со стороны бизнеса, и со стороны вендора действительно ли это недопоставка или некорректные данные, что приводит к дополнительным транзакционным издержкам обеих сторон, влияет на коммуникацию и удлиняет операционные процессы. При этом некоторые компании сознательно идут на такую рабочую модель с подрядчиком, чтобы в том числе иметь возможность оказывать влияние и дополнительно зарабатывать на показателях SLA.

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

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

Первый и важный критерий – измеримость показателя, то есть, действительно ли данный критерий измерим в цифрах или процентах.

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

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

Разработка и поддержка. Как разделять SLA при использовании ИТ-услуг

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

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

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

Также необходимо четко формулировать задачи и учитывать SLA по разработке, что в будущем поможет четко разделить разработку и поддержку.

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

Ответственность за SLA

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

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

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