Pull to refresh

Comments 11

Как-то сумбурно.
Начнем с того, что SLA – Service Level Agreement, что есть Соглашение об уровне сервиса.
Что мешает пойти таким путем:
1. Получаем полный перечень сервисов
2. Описываем тип запроса: сбой, запрос на обслуживание, запрос на изменение инфраструктуры
3. Определяем с заказчиком критичные сервисы и ВИП пользователей
4. Расписываем возможные типы работ по сервисам.
5. Описываем в документе уровень доступности каждой услуги и максимальное время производство работ по ним, а также время реакции.
6. Заводим все это в свою тикет систему
7. Радуемся и не нарушаем SLA по договору.
8. Profit!

P.S.: Описанный метод — большой труд, но этот труд не оставляет разночтений и досконально опиcывает необходимый заказчику уровень доступности сервисов.
При этом разный уровень доступности означает разные деньги для заказчика и затраты для исполнителя соответственно.

Что касается сумбурности — может быть поторопился, правда.


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


Если же идти от оферты, и выбрать уровень сервиса, который заведомо превосходит требования большинства, то практически того же результата можно добиться ничего не согласовывая т.к. основные востребованные сервисы, типа "рабочее место", "телефония", "печать", "интернет", требуются основному количеству пользователей в ± одном высоком качестве.
При этом SLA потребуется заключать (Ваши шаги 1..8) применяются не ко всему множеству: "заказчик-сервис-уровень сервиса", а только к тем кому действительно необходимо получать нестандартный сервис, а таких, обычно, меньшинство.


Прозрачность же можно получить — через публикацию отчётов по заявкам на интранет-портале, чтобы всем было видно объективное качество работы поддержки.

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

В общем все зависит от уровня бюрократии и ее необходимости.

P.S. наша команда держит SLA > 99%

Кстати такой вопрос на счет оферты:
Вот есть сервис телефония. Конкретный заказчик требует SLA > 99%, время реакции не более 30 минут и время на решение 4 часа. И готов за это платить деньги.
Другой заказчик не так требователен и требует SLA > 94%, время реакции 4 часа и 3 дня на решение проблемы и готов платить гораздо меньше, чем первая компания.

Ну и к примеру у вашей аутсорсинговой компании 20-30 клиентов, которые готовы платить разные деньги за разный уровень сервиса.

Как быть в таком случае?

Круто, что больше 99%


Тут несколько вопросов/ответов, основной — что делать с вариативностью


  • если клиенты просят одного и того же, за исключением сроков реакции и устранения, то с вашей стороны предполагаю, что есть интерес полностью загрузить своих, а со стороны клиента получать качественный сервис, тогда можно сделать не 2, а 3 базовых уровня сервиса (оптимизировав загрузку персонала) и идентифицировать клиента по компании, предполагая, что если клиент анонимен — то уровень сервиса базовый, если не анонимен, то соответствующий указанному в SLA, либо явно запрошенному при обращении (но тут надо будет прописывать подтверждение полномочности обращения в SLA, например сканом гарантийного письма)
    • если клиенты хотят не совсем одного и того же в смысле доп. услуг при более или менее одинаковых параметрах реакции, то есть два варианта:
      1. если вариаций сервиса немного — структура сервиса может включать себя подсервисы с соответствующими тарифами;
      2. если вариаций много, то лучше сделать структуру сервиса состоящего из базового сервиса и опций, по аналогии с тем, как это делают сотовые операторы (условно — звонки внутри региона базовая ставка, а межгород или, скажем, + 10Гб трафика — отдельные опции) — в этом случае в SLA надо будет прописать процедуру, оповещения исполнителем заказчика по почте о выбранных им опциях .
В теории — все верно. А на практике мы сталкиваемся с различными подводными камнями, например, с нежеланием заказчика идти на компромиссы или вовсе заключать SLA (дескать — и так все устраивает). В этом случае оферта — сильный ход со стороны IT-подразделения.
Самая большая проблема, которая почти нигде не описывается — это то, что бизнес крайне редко даёт вам список сервисов и отмечает что из них критично. Из всех случаев, с которыми сталкивался лично — лишь дважды бизнес это понимал и ещё один раз понимал, но «не отвечал за базар» (сиречь, к примеру, было заявлено «лишь бы сайт работал 24/7», а на деле «если не работает телефон, который написан на сайте — считай, сайт не работает»).

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


Это к тому, что бизнес должен знать, что сервис сайт в себя включает и что (для особо упорных случаев) не включает, а также сколько людей на эти задачи работает.


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


В реальности у бизнеса есть те же вопросы — обосновать бюджет и кол-во персонала, поэтому и говорить с ними после того, как займёте позицию понятную им (вот сервис, стоит столько) — будет база для договорённостей т.к. всегда можно будет обосновать затраты в ответ на дополнительные требования.

Простите, я не понимаю сути.
Как это делаю я («на пальцах»): сперва рассказываю про влияние (affected). Мол, есть сервисы, которые влияют на весь Ваш бизнес вообще. Ну, у кого это инет, у кого рабочий сервак бухгалтерии, у кого телефон. Есть то, что сильно затрудняет. Тут примеры про, например, упавший 1С в случае, если всё в принципе-то работает, но страдает целый отдел/филиал/служба. Далее — понятно же?
На этом этапе важно не приступить к перечислению сервисов по категориям.
Лучше разъяснить, что-де высокую доступность инета обеспечить можно, но это будет стоить столько-то, потому как два провайдера, 10 км оптики с рытьём траншеи и блаблабла.
То же и с, например, принтером.

Ну а дальше — веселье, ибо сложно заранее предсказать тот или иной расклад, если у бизнеса нет даже примерных цифр, какие он тратит на ИТ. Обычно — на моей практике — их нет.

Тут лучше пойти с другой стороны:


  • зафиксировать в форме каталога сервисов все активности по поддержке и задекларировать это как каталог => базовая ставка — все заняты и понятно на какие сервисы;
  • посчитать кто сколько и каких сервисов потребил => база для расчёта метрик качества по сервисам;
  • понять какого качества реально достичь без увеличения кол-ва людей => те метрики качества которые стоит обсуждать с бизнесом и, при превышении которых просить доп. штат.

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


Что касается требований выходящих за рамки каталога и параметров, то вариантов опять же два:


  • либо повышение качества сервиса решается доп. людьми;
  • либо повышение качества сервиса решается проектом с бюджетом, планом и сроками, если не верят Вашим утверждениям в этом случае, то проще получить 2-3 ТКП на решение — это будет вполне убедительным.

Не думаю, что ответ Вас полностью удовлетворит, но у меня такой опыт: сначала объект (сервисы и их цена в людях) — потом дискуссия по нему с заказчиком, на предмет лучше/хуже/пойдёт — почему так — в кризис проходили попытки сокращения и наличие нормального учёта и дружественных заказчиков приводит к тому, что сокращают не твоих людей, а тех у кто не может обосновать затраты.

а, ну у Вас иной подход. Я же выступаю в роли HeadOps`а. Свои сложности, свои особенности.

Sign up to leave a comment.

Articles