[Хостинг, Service Desk, Законодательство в IT, IT-компании] Как написать регламент, чтобы клиентов не тошнило, а бизнес получал сарафанку

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
25-Июн-2021 18:38

Цитировать

Мы уже разбирали, как написать одностраничный Устав единственного учредителя, короткий договор, а теперь поговорим про регламент оказания услуг. С регламентами сложилась ужасная ситуация:

прочитать и понять их почти невозможно;
непонятно кем, для кого и зачем они пишутся, если можно написать в одном предложении: «Банк, хостер, Исполнитель всегда прав»;
регламенты не несут пользы клиентам.

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

Чего не должно быть в регламенте:
- словаря общеизвестных терминов – не надо определять Интернет, сеть, ЛК и т.п.;
- неизмеряемых критериев типа «в кратчайшие сроки»;
- ни на что не влияющих тупых фраз, которые заведомо никто не будет даже читать;
- страшилок и кабальности, что мы порвём клиента, если он оступится;
- дублирования императивных норм законов и подзаконных актов – они действуют независимо от того, что написано в договоре и регламенте.

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

Далее – большой лонгрид про написание полезного регламента и примеры, как делать не стоит.Зачем писать регламент и как его писали мыЗаказчику регламент нужен, чтобы получить качественную услугу и отстаивать свои права, если исполнитель косячит. Исполнителю же регламент нужен не затем, чтобы иметь 100500 поводов нагнуть требовательного и придирчивого клиента, а чтобы сотрудники не халявили, оказывали услуги качественно и в компанию шли клиенты по сарафанному радио.Регламент – редкий зверьПричина такого заголовка сводится к тому, что как показала практика, встретить простой и/или понятный регламент практически невозможно, а порой в открытом доступе на сайте его вообще может не быть. Еще одна причина – у регламента может быть масса других названий. Например, «Соглашение об уровне обслуживания» или «Условия использования…», но все это об одном и том же.Пришли мы к этому, когда искали и смотрели, как сделано у других. Схожий опыт уже был – он описан в статье про то, как написать простой и понятный договор.Как и в прошлый раз, изучение чужих регламентов показало, что у других написано сложно, скучно, непонятно, о чем мы уже сказали в начале статьи, но давайте подробнее разберем, чего же не должно быть в регламенте.Сразу оговорюсь, для примера взяли наиболее яркие примеры, большая часть которых нашлась на сайте у коллег из reg.ru и selectel, за что им спасибо, так как в отличии от некоторых, на их сайте документы есть и их много :)«Многобукв» (с)Ощущение, что документ(ы) писал фрилансер, которому за количество символов платили. Вот «Условия использования …» и там всего 8 страниц, но это условия для одной единственной услуги! А таких на сайте > 20. Больше услуг – больше чтива на ночь, смиритесь!А вот тут уже 17 страниц – из-за растянутых формулировок и текста ради текста.Выяснилось, что есть такой прикольный параметр, как «тошнота» текста – измерить его можно, например, тут.В данном случае он составляет 16.6, что более чем в 2 раза превышает допустимую «норму».По рейтингам, Россия на втором месте среди «самых читающих стран», не находите взаимосвязи? ЛавируемМаксимально расплывчатые понятия и неизмеримые параметры – это уже не классика, а издевательство!Например:«2.6.7. По завершении установки оборудования в Дата-центре, Исполнитель информирует Заказчика через Тикет-систему и/или по электронной почте о подключении» (с). Там же:«5. Заказчик не имеет права пользоваться Услугами, если своевременно не устраняет уязвимости, обнаруженные при проверке требований безопасности» (с). Своевременно – это час? День? Месяц? Год?Уязвимости какого характера? Microsoft практически в каждом обновлении на своих продуктах уязвимости закрывает – выходит, они там по умолчанию есть и сервером с виндой пользоваться запрещено? Или тут:«8. Исполнитель может предоставлять разные виды услуг расширенной технической поддержки на платной основе» (с) Может, но не обязан. А слово «разные» – верх точности и определенности.Списки и словари, которые мы так любим…Списка литературы в конце не хватает, но не будем подкидывать плохих идей. Большая часть определений - очевидные и общедоступные понятия, а если наоборот, то зачем их использовать?Примеры:«Служба поддержки (СП) – команда специалистов Исполнителя, ответственная за оказание услуг клиентской поддержки Пользователей» (с);«Правила – условия оказания технической поддержки, описанные в настоящем документе» (с);«Панель управления – веб-интерфейс, представленный Заказчику Исполнителем для управления услугами» (с);«Стеллаж – конструкция, для размещения оборудования не предназначенного для крепления в Серверной стойке» (с).Спасибо, что разъяснили… Обратная ситуация:«Мягкий грейс период – период оказания услуги после завершения оплаченного периода, в течение которого услуга оказывается Исполнителем Заказчику в полном объеме» (с). Там же есть еще «Жесткий грейс период»... При этом существует простое и известное/доступное понятие – льготный период, а судя по отсутствию в википедиипонятий как “мягкий” и “жесткий” – это какое-то изобретение, очевидно, велосипеда.Цитаты из законов и подзаконных актов и прочие сложные юридические выкладкиВ ряде случаев предполагается, что документы должны изучить юристы, но какое это отношение имеет к клиенту, который не имеет юридического образования или юриста в штате?Много таких пунктов нашлось у hostkey. Например, в документе «Согласие на обработку персональных данных» (редакция от 30 декабря 2020 года) в пункте 7.6 зачем-то продублированы полные названия законов, постановлений и приказов:

Много бесполезного текста.Или тут:«в случае обнаружения информации, выражающей в неприличной форме, которая оскорбляет человеческое достоинство и общественную нравственность, явное неуважение к обществу, государству, официальным государственным символам Российской Федерации, Конституции Российской Федерации или органам, осуществляющим государственную власть в Российской Федерации, Генеральный прокурор Российской Федерации или его заместители обращаются в федеральный орган исполнительной власти, осуществляющий функции по контролю и надзору в сфере средств массовой информации, массовых коммуникаций, информационных технологий и связи» (с). И такого много…Не забываем пугать клиента«1.14. Абоненту запрещается изучение технологии, декомпиляцию и деассемблирование программного обеспечения за исключением и только в той мере, в какой это прямо разрешено применимым законодательством» (с). А теперь сиди и разбирайся, где «та мера» и «применимость» законодательства.«2.2.2. Заказчик обязан оказывать содействие Исполнителю при расследовании причин незапланированных перерывов в обслуживании, нарушения требований безопасности и при подозрении на нарушения условий Соглашения» (с).Вам не кажется, что тут что-то не так?Что должно быть и что многие упускаютЧто вам, как клиенту хочется видеть в регламенте?Классификацию объектов предметной областиКакие услуги оказываются?Какие события могут произойти? А что, если произойдет авария?Если с услугами в большинстве случаев проблемы возникают редко, то возможные события и тем более аварийные ситуации никак не прописаны.Измеряемые критерииКакие объемы услуг и в какие сроки должны быть предоставлены?Сколько минут / часов / дней требуется для того или иного события?С какой скоростью должна отвечать техническая поддержка?Точных значений и того, что действительно можно измерить, многие избегают по понятным причинам. Алгоритмы, которые реально важныБез лишних слов, просто и понятно – написать, как и куда обратиться, как оценить качество, в какие сроки ждут реакции от вас.Этому тоже мало где уделяют внимание. Гарантии качестваЭто важнейший момент, который либо не прописан, либо прописывается с большим количеством сносок и оговорок.А почему? Когда речь заходит про дата-центр, особенно сертифицированный, разве это не накладывает ряд обязательств на исполнителя? Ответственность за нарушениеЭтот пункт связан с предыдущим, так как в случае нарушения гарантий должна наступить ответственность, прописанная в документах.Многие и этого избегают, но если нет гарантий – за что ответственность? Удобно.А ведь регламент бывает необходим!Если вы уже «обжигались», то будете требовать регламент.Вот пример статьи в которой автор (со стороны клиента) сам писал SLA при заключении договора. Очевидно, в этом была необходимость и именно так он решил «мотивировать» своего поставщика. Но имеет ли это смысл? Предположим, регламент у поставщика уже есть, но вам он не нравится.Тут стоит задаться вопросом: станет ли поставщик менять его ради одного клиента? Подписать-то могут любую редакцию, но найдет ли это отражение в реальных рабочих процессах?Чтобы разобраться в этом, стоит обратить внимание на то, как и зачем пишется должен писаться регламент.Как мы писали регламентТут мы повторимся, так как отталкивались от того, что должно быть в регламенте:

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

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

Состав услуг.
Классификация заявок.
Время реакции и режим работы.
Оценка качества услуг.
Характеристики дата-центра.
Гарантии.
Порядок посещения дата-центра.
Порядок приемки-передачи оборудования.
Доставка.
Методы и порядок коммуникаций.
Ответственность.

Каркас получился типовой + мы не стали дублировать то, что и так определено в договоре – зачем лишние пункты.Шаг 2:Наполняем каркас контентом.Состав услугТут все очевидно: главное, не забыть про дополнительные услуги.Классификация заявокТребуется понять, по каким вопросам обращаются клиенты, сгруппировать ряд обращений, выписать все необходимые. Нам помогло то, что ранее мы уже писали SLA и KPI для инженеров дата-центра, в рамках чего эта работа и была проделана. Время реакции, срок выполнения заявок и режим работыРежим работы – очевидный параметр, не будем на нем останавливаться.Со временем реакции уже сложнее.У нас есть время реакции, которое мы прописываем в инструкции для инженеров, есть статистика, которая говорит о том, что они в это время укладываются. А значит, можем смело ставить эту цифру в регламент. Например, время реакции с нашей стороны мы указали 30 минут, однако статистика на данный момент говорит о том, что средний максимум –17 минут. Запас оставляем, но можно и снизить показатель, для красивых цифр.Расписывать детально по всем типам не стали, выделили лишь типовое обращение, нестандартное обращение, инцидент, аварию и исходящее обращение.Срок выполнения заявки – тут тоже нужна статистика, которая показывает, в какие сроки и какие обращения были закрыты, на что и стоит ориентироваться.Тут важно отметить, что мы не забыли и про пункт, который регламентирует сроки получения обратной связи от клиента, так как в ряде ситуаций, молчание клиента стопорит выполнение задачи. Например, выделение IP-адреса или консультация – типовые обращения, среднее время закрытия подобных заявок составляет 63 и 86 минут соответственно. Срок выполнения типовых обращений мы прописали 2 часа, так что укладываемся.Оценка качества услугТут ничего сложного – перечисляем, как клиент может оценить качество.В нашем случае – это:

Поставить оценку в переписке по электронной почте, в тикет-системе, в чате Telegram.
Позвонить техническому или исполнительному директору (контакты есть на сайте).

Вот так может выглядеть статистика у инженеров, чьи показатели выше 97%:

Все минусы и недочеты учитываются и тщательно подсчитываются.Характеристики дата-центраНичего сложного, особенно когда он сертифицирован, а значит, можно смело ссылаться на параметры, актуальные для сертификации.Сертификатов должно быть три:

Если же их нет, то можно отталкиваться от параметров резервирования по нашей таблице. ГарантииЧасть гарантий перекрывается параметрами дата-центра и сроками реакции/закрытия инцидента, поэтому, в нашем случае описывать все в этом пункте не стали.Закрыли частый (и очень важный) вопрос: в какие сроки мы можем подготовить сервер? Опять же, отталкиваясь от статистики, пишем реальные сроки.Например, изрядно выбились по срокам подготовки сервера –подарили месяц бесплатной аренды, сами виноваты. Хоть и без пофигизма поставщиков не обошлось, за что им отдельное спасибо… Нужно ли здесь многоточие?Порядок посещения дата-центраКак ни странно, но с этим регулярно возникают вопросы и даже курьезные ситуации – так что, вынесли в отдельный пункт и описали все требования, но тут стоит отталкиваться от вашей локации.Порядок приемки-передачи оборудованияОчень важный пункт, в котором стоит в очередной раз вспомнить, какие косяки имели место быть и все их описать.ричем обратите внимание: требования тут идут именно к клиенту.Например, чтобы исключить любые вопросы по «внутренностям» сервера, мы требуем указывать его подробную конфигурацию и проверяем сервер на ее соответствие по факту размещения. К счастью, в краже комплектующих из сервера нас еще ни разу не обвиняли :)Более жизненная ситуация – простой (причем регулярный, к сожалению) пример: приезжает курьер (само собой, без доверенности) и настойчиво требует выдать ему сервер ООО «Ромашка». После отказа курьеру с нами связывается разгневанный клиент и требует все же отдать сервер курьеру. После подобных ситуаций мы добавили КУДА ДОБАВИЛИ? пункт 8.3., в котором явным образом прописали, кому мы выдаем сервер – само собой, курьерам без оригинала доверенности не выдавали и выдавать не будем.Или еще один важный пункт в том же разделе:«8.6. Датой прекращения оказания услуги размещения оборудования считается дата выдачи оборудования Заказчику».Почему так? А потому что написал клиент заявку – отключите, снимите, съезжать буду. Ок, но зачастую это “съезжать буду” может затянуться на неделю, две, месяц… Да, сервер не в стойке, да, не кушает электричество, но хранить-то его тоже нужно. Один – ладно, но если таких 10? 100? ДоставкаТоже пункт, который был специально вынесен отдельно, чтобы избежать недоразумений, которые периодически возникают и мы с ними сталкиваемся.Методы и порядок коммуникацийПункт немного сложнее, чем может показаться. Да, тут мы перечисляем все способы с нами связаться, но при этом уделяем внимание и вопросу идентификации клиента, что бывает камнем преткновения во многих конфликтах.ОтветственностьБезусловно, самый интересный пункт! Пункт про деньги – и да, мы тоже считаем что 1/720 это смешно, потому что не брать денег за время, которое услуга не предоставлялась,– логично, но ответственностью и не пахнет. Так что у нас иные цифры: 100 часов не работал по нашей вине – месяц не оплачиваешь. Туда же занесли и возмещение за факт нарушения регламента. И эти цифры тоже не из головы – тут снова статистика, подсчеты «сколько это в рублях» и выводы: готовы ли мы? Мы не рассчитываем брать эти деньги из воздуха, потому что регламент – это зеркальное отражение KPI и SLA сотрудников, договоров и оговоренных уровней качества услуг с поставщиками. Как говорится, бизнес никогда не перекладывает на себя новые расходы – тут ситуация немного схожая, вот только клиента эти внутренние разбирательства беспокоить не должны.Например, в конце января по нашему недосмотру в дата-центре Тушино ночью у клиента отключился один из двух серверов. Не авария, но инцидент, по нашему регламенту время на его устранение – 2 часа.Усугублялась ситуация еще и тем, что на тот момент круглосуточных инженеров в дата-центре не было (с марта ситуация исправлена, теперь работаем круглосуточно).Завести оборудование удалось в районе двух часов дня, что даже при учете рабочего времени – сильно за рамками.Как итог, весь февраль клиент размещался у нас бесплатно, все еще с нами и больше жалоб не поступало.Еще пример: накосячили при настройке VLAN (позиционировали как аварию), клиент получил простой 68 минут, что опять же, вышло за рамки регламента. Компенсация – неделя бесплатно.Шаг 3:Проводим этап согласований и правок на их основе.Тут важно понимать, что регламент обязательно нужно показать:

тем, кто должен его соблюдать;
тем, кто должен следить за его соблюдением;
тем, кто будет его подписывать с другой стороны (некоторым клиентам, например).

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

понимания своих же бизнес-процессов и услуг;
не из головы взятых и прописанных SLA / KPI внутри компании;
договоров с поставщиками и их обязательств;
обширной статистики обращений, сроков, косяков и иных ситуаций.

А значит, если регламента у компании нет, то стоит задуматься: отсутствие какого из вышеперечисленных пунктов мешает его написать?Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_hosting (Хостинг), #_service_desk, #_zakonodatelstvo_v_it (Законодательство в IT), #_itkompanii (IT-компании), #_reglament (Регламент), #_garantii (гарантии), #_dokumentatsija (документация), #_klienty (клиенты), #_klientskij_servis (клиентский сервис), #_zakonodatelstvo (законодательство), #_datatsentr (дата-центр), #_podderzhka (поддержка), #_blog_kompanii_itsoft (
Блог компании ITSOFT
), #_hosting (
Хостинг
), #_service_desk, #_zakonodatelstvo_v_it (
Законодательство в IT
), #_itkompanii (
IT-компании
)

Профиль ЛС

Ответить на тему

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

Текущее время: 22-Ноя 18:53
Часовой пояс: UTC + 5