#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Нормативы Трудового кодекса, или как грамотно управлять техподдержкой исходя из законов

При организации техподдержки важно учесть все нюансы Трудового кодекса РФ, это в первую очередь для своего спокойствия. Всегда и всё надо делать правильно, в том числе с точки зрения правового аспекта.

График работы – если не офисный, значит Суммированный учёт рабочего времени (СУРВ) (ТК РФ статья 104). Учётный период лучше ставить год, так удобней. Важно не допускать переработок по итогу года, но если допустили, то максимальное количество 120 часов в год. ВАЖНО, эти 120 часов должны быть оплачены в двойном размере, т.е. вы сначала оплатили эти часы в месяце, в котором был выход за пределы, а уже после окончания года за все часы переработок ещё одна оплата должна быть. Это обязательно, иначе вы рано или поздно наткнётесь на сотрудника, который будет об этом знать, а далее трудовая инспекция, бунт на корабле и т.к.

График составляется на весь учётный период или помесячно, но в любом случае всегда подписывается у сотрудников. Менять смены в СУРВ можно хоть накануне, главное подписать его вместе с сотрудником.

Все праздники в двойном размере оплачиваются сразу при расчёте за месяц.
Ночные часы оплачиваются +20%.
Если выводите людей по приказу, то двойная оплата сразу (либо доп.выходной).

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

Все проступки фиксируйте официально через приказы о замечании, выговоре и увольнении. 3 замечания – можно увольнять по статье. Всё должно быть оформлено грамотно и по чётким и ясным формулировкам. Уважайте себя, и не выдумывайте липовые обвинения, если вы уволите по статье и при этом формулировки будут прямо скажем не очень, сотрудник очень быстро восстановится обратно по суду.

Заранее составьте цели и задачи сотрудников на испытательный срок, оформите это документально и давайте под роспись новичкам – впоследствии будет законный повод отказать в прохождении испытательного срока. Это важно, могут быть кейсы, когда даже на испытательном сотрудник отказывается увольняться, а при невыполнении цели вы просто издаёте приказ о непрохождении ИС.

Если подытожить – всегда соблюдайте ТК РФ, это обезопасит вас полностью в вопросах кадровой дисциплины.

15.09.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Целевой режим работы техподдержки

График работы всегда строится исходя из специфики бизнеса. Могут быть различные варианты от 24*7 до офисного 8*5. Надо смотреть исходя из работы вашей компании, какие услуги она предоставляет, какая требуется поддержка.

Для качественного принятия решения вы должны понимать нагрузку на техподдержку по часам. Исходя из этого выстраивать графики. Вариантов уйма, и 2/2, и 5/2 с чередующимися неделями и выходные в разные дни недели (но при этом выходные всегда парные и постоянные), например, 1я неделя 07-16, 2я неделя 13-22. И вот уже 2 сотрудника могут закрыть рабочую сетку 07:00-22:00. Добавьте сюда 2 человека на 2/2 08-20, и вот уже у вас есть возможность ежедневно закрывать как минимум 08-20, даже если сотрудник 5/2 уйдёт в отпуск.

Но кстати график 2/2 я не очень люблю, дело в том, что эффективность таких сотрудников как правило меньше, причин много, в основном, что они работают всего 2 дня, и половина их рабочих часов приходится на небольшую активность от пользователей.

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

Если у вас целевой режим 24*7, то значит вам нужны ночные смены – возможно стоит закрыть отдельными сотрудниками, т.к. работа в ночь для всего коллектива (по очереди, даже раз в месяц) окажется для многих непосильной ношей.

Немного примеров дневных графиков скидываю. Если надо обсудить, приходите в чат, будем обсуждать, мне есть чем поделиться, каких графиков у меня только не было =)

11.09.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Каналы обращений пользователей

Подумайте, как вы будете принимать обращения от пользователей. Вариантов много:
1. Портал самообслуживания (в том числе возможно мобильная версия)
2. Телефон (регистрация заявки вручную сотрудником техподдержки)
3. Почта (интеграция с ServiceDesk и заведение заявки автоматически при получении письма)
4. Мессенджеры (интеграция с ServiceDesk и заведение заявки автоматически при получении сообщения)
5. Интеграция SD с другими информационными система и создание заявок по API
Как минимум вот такие варианты. Если с мессенджерами можно придумать ботов, которые грамотно зарегистрируют заявку по определённому виду работ, то вот с почтой надо быть аккуратным, все обращения будут регистрироваться в SD под одним шаблоном и потому сотрудникам техподдержки придётся менять классификатор вручную.

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

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

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

08.09.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Телефонная поддержка

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

Если до создания ServiceDesk у вас была вся поддержка по телефону, то будет сложно отучить пользователей. В любом случае, надо меняться в лучшую сторону, поэтому нужно хотя бы регистрировать все обращения в обязательном порядке в виде заявок. Даже если вы сразу решаете заявку (First Call Resolution – решение проблемы пользователя с первого звонка) – всё равно регистрировать в 100% случаев. При этом надо рассматривать конкретные задачи и ситуации: надо ли вам сокращать количество звонков или всё нормально. Если надо – при каждом звонке проговаривать пользователям о возможности самостоятельного решения, о возможности создания запроса через портал самообслуживания, написания письма и пр. Регулярно выпускать рассылки на пользователей с краткими инструкциями, что делать при сбое в ИС.
Если вы решаете в том числе проблемы по телефону (например, сброс сессии, сброс пароля и пр.), то:
1. Обязательно регистрировать запрос в ServiceDesk;
2. Рассчитывать показатель FCR (First Call Resolution – решение проблемы пользователя с первого звонка) по конкретным сервисам, в дальнейшем это вам пригодится. Например, по некоторым сервисам невозможно решить проблему по звонку, а звонков по этой теме немало – сделайте объявление при звонке; регулярно выпускайте информационные письма; работайте по направлению снижения ненужных звонков (по которым вы или сами регистрируете запрос, или отправляете пользователя регистрировать самостоятельно).

Важно помнить, однажды приучив пользователей звонить – они сами не перестанут это делать. С другой стороны, мы также помним, что наша цель – минимизировать потери бизнеса вследствие технических проблем, а телефон — это самый быстрый способ сообщить о проблеме.

Подведём итог: важен разумный баланс звонков и ресурсов, затрачиваемых на приём этих звонков. Действуйте грамотно и аккуратно.

04.09.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Приоритет / влияние

Рассмотрим такие важные вещи, как приоритет и влияние.
Приоритет – это насколько быстро данный инцидент должен быть обработан (или уйти в работу). Важно: запросы на обслуживание не приоритезируются.
Обычно приоритетов бывает 4: Критический, Высокий, Средний и Низкий. Можно конечно и до 6 расширить, тут уж зависит от количества ваших сервисов и реальной необходимости так широко расставлять приоритеты. Что определяет приоритет? – насколько сильно бьёт по карману компании тот или иной инцидент. Критический – условно, сломалось всё, нужно бросать всё и чинить. И, например, Низкий – это маловлиящая на ключевую функциональность ошибка, потери денег нет, но есть некоторое неудобство для пользователей.

Влияние - это на какое количество пользователей влияет данная ошибка.

Зачем нужно это? Обычно, используется для расчёта максимального времени выполнения: строятся матрицы по степени влияния и приоритета запроса, и из этого выходит срок выполнения. Например:
Приоритет / Влияние 1 человек Вся компания
Низки
й 8 часов 4 часа
Критический 6 часов 2 часа


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

01.09.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Инциденты / Запросы на обслуживание

Важно сразу в каталоге услуг предусмотреть деление всех заявок на инциденты и запросы на обслуживание.
Простыми словами:
Инцидент – это нарушение штатного процесса работы услуги.
Запрос на обслуживание – это просто запрос пользователя на что-либо, например, на консультацию, изменение или доступ и т.п.

Почему надо делить обращения на типы?
1. Разные приоритеты. В первую очередь должны быть решены инциденты, ведь мы помним, что цель службы поддержки в том, чтобы минимизировать потери бизнеса вследствие технических проблем.
2. Разные сроки решения. Конечно, на инциденты разумно ставить наименьшие возможные сроки.
3. Отчётность. Например, вас попросили снять отчёт по заявкам по сервису печати. Если не делить на типы запросов, то может оказаться, что у вас очень много заявок, что конечно должно вызвать вопросы у менеджмента, почему так? Но если посмотреть детализацию по типам, то окажется, что 90% заявок – это заправка картриджа, и следовательно с самим сервисом всё в порядке.

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

30.08.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Инциденты / Запросы на обслуживание

Важно сразу в каталоге услуг предусмотреть деление всех заявок на инциденты и запросы на обслуживание.
Простыми словами:
Инцидент – это нарушение штатного процесса работы услуги.
Запрос на обслуживание – это просто запрос пользователя на что-либо, например, на консультацию, изменение или доступ и т.п.

Почему надо делить обращения на типы?
1. Разные приоритеты. В первую очередь должны быть решены инциденты, ведь мы помним, что цель службы поддержки в том, чтобы минимизировать потери бизнеса вследствие технических проблем.
2. Разные сроки решения. Конечно, на инциденты разумно ставить наименьшие возможные сроки.
3. Отчётность. Например, вас попросили снять отчёт по заявкам по сервису печати. Если не делить на типы запросов, то может оказаться, что у вас очень много заявок, что конечно должно вызвать вопросы у менеджмента, почему так? Но если посмотреть детализацию по типам, то окажется, что 90% заявок – это заправка картриджа, и следовательно с самим сервисом всё в порядке.

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

30.08.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Классификатор / тематики обращений

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

Для каждого вида обращения надо определить:
1. Название (тематика, категория, классификатор, шаблон, путь или как угодно можно это назвать).
2. Регламентный срок выполнения. Превышение этого норматива будет считаться несоблюдением SLA.
3. Приоритет, влияние (об этих параметрах поговорим позднее).
4. Команда, ответственная за выполнение.
5. Обязательные поля, которые должен заполнить пользователем при составлении обращения.
6. Подсказки для пользователя, о чём шаблон, по каким вопросам обращаться, подсказки по заполнению обязательных полей и пр.
И вот у нас уже вырисовывается минимальный набор требований для каждого из шаблона обращений.

Давайте на примере. Предположим, хотим создать шаблоны обращений по услуге печати, или, если иначе, по печатающему оборудованию.
1. Название или путь шаблона (можно делать какие угодно иерархии, лишь бы это было логически обусловлено и удобно):
IT – Оборудование – Печатающее оборудование – Не печатает
IT – Оборудование – Печатающее оборудование – Не сканирует
IT – Оборудование – Печатающее оборудование – Замена картриджа
2. Регламентный срок: 4 рабочих часа
3. Приоритет и влияние: Высокий
4. Команда поддержки пользователей
5. Обязательные поля: Модель МФУ, Скриншот
6. Подсказки: как посмотреть модель МФУ, как сделать скриншот
Примерно так, с этим уже можно работать. Составьте такие составляющие по каждой из услуг. Можно добавить также технологические шаблоны, которые не будут использоваться пользователями, но будут использоваться ИТ, например, обновления ПО. Это очень важный момент, это невидимая для бизнеса, но обязательная и необходимая работа, которую надо показывать. А раз мы говорим об SD, то глупо не использовать её возможности. Вся ваша работа должна быть зафиксирована в SD в виде заявок и запросов.

20.08.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ

Деление по линиям / командам

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

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

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

В любом случае, работу стоит начать с определения, кто и чем будет заниматься, дальше логически определиться с объединением в команды. Деление на команды уместно даже в том случае, если в этих командах будут одни и те же люди. Конечно, по всем услугам делать разные команды не надо, но, например, софт от железа отделить, почему бы и нет. Это конечно легко делается и в процессе использования SD, так что не беда если сейчас не получается разделить, значит достаточно будет поделить пока как минимум на 2 команды: кто отвечает за рабочие места и кто отвечает за информационные системы.

19.08.2020 Комментарии Telegram

#ServiceDesk #HelpDesk #техподдержка #ITIL #ITSM #УправлениеИТ #каталогуслуг

Создаём каталог услуг

Что такое каталог услуг? Это все услуги, которые ИТ оказывает бизнесу (и за которые бизнес платит ИТ). Сюда входит всё, от предоставления АРМ (автоматизированное рабочее место, читай ПК) и сервисов печати на МФУ, до сложных сервисов, использующих несколько информационных систем одновременно.

Важно: не путать с информационными системами! 1С – это ИС, сама по себе она не может быть услугой. А вот то, что делают внутри 1С, это уже услуга, например: кадровый учёт, инкассация, инвентаризация товаров и т.п., это всё услуги.

Для чего это нужно:
1. По каждой услуге в каталоге прописана вся информация о ней: время оказания услуги, время поддержки (24/7 или 8*5 и т.п.), владельцы со стороны бизнеса и ИТ, регламент обновления, доработок, технологические окна, как оказывается поддержка и с каким SLA и пр.информация. В интернете можно легко найти примеры.
2. Все услуги, оказываемые ИТ для бизнеса, должны быть обязательно зафиксированы каталогом. Все новые сервисы должны обязательно передаваться на поддержку и заноситься в каталог, заключаться SLA.
3. Всё должно быть оформлено документально: данные есть в каталоге, по каждому сервису заключены официальные СУС (соглашение об уровне сервиса или SLA), подписаны бумаги о промышленной эксплуатации.

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

13.08.2020 Комментарии Telegram