Создание техподдержки. Служба технической поддержки для операторов связи

12.08.2023

Краткое описание курса

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

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

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

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

Цели обучения

получение уникального практического опыта по созданию комплекта документации, включая регламент процесса, необходимый для описания деятельности поддержки пользователей;
углубленное изучение основных процессов поддержки пользователей - управление инцидентами и управление проблемами с целью создания Единой Точки Контакта (SPOC);
изучение принципов построения и организации работы службы Service Desk: организация, выполняемые функции, методы грамотного подбора персонала;
знакомство с методами и подходами по планированию и настройке процессов с целью обеспечения их результативности, рациональности и согласованности, следствием чего является повышение качества услуг, оказываемых ИТ-подразделением;
краткое знакомство с сопутствующими процессами: управление событиями, управление запросами, управление доступом.

руководителям и сотрудникам, перед которыми поставлена задача по планированию и внедрению службы технической поддержки;
сотрудникам и руководителям служб поддержки пользователей, таким как Service Desk, Help Desk, Hot Line, Call Centre;
сотрудникам, задействованным в технической поддержке пользователей;
руководителям подразделений, являющихся потребителями ИТ-услуг.

В результате обучения слушатели

получат уникальный практический опыт создания комплекта документации для описания процесса поддержки пользователей на примере управления инцидентами;
приобретут необходимые знания для построения службы технической поддержки;
сформируют понимание принципов управления ИТ-инфраструктурой в целях осуществления поддержки пользователей;
получат практические навыки построения службы поддержки пользователей Service Desk;
получат необходимые знания по планированию, настройке и внедрению процесса;
приобретут необходимые знания для управления процессом Problem Management;
познакомятся с такими процессами как: управление событиями, управление запросами, управление доступом.

Обязательный уровень знаний

Рекомендуется пройти обучение на курсе «ITIL ® Foundation v3. Базовый курс»;
Желателен опыт работы в ИТ-подразделении, в частности, в одном из рассматриваемых в рамках обучения процессе или в службе технической поддержки.

Предоставляемые материалы

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

Продолжительность и условия обучения

Длительность курса - 16 академических часов (2 дня). В стоимость курса включены обед и два кофе-брейка в течение каждого дня обучения.

Тренеры

Курсы проводят преподаватели, сертифицированные компанией EXIN и APMG. Преподаватели имеют большой практический опыт по внедрению процессов ITIL ® в компаниях различного масштаба.

Программа курса «Организация службы поддержки пользователей: создание документации и структура службы».

Часть 1. Теория

. Вводная часть курса
o Цели курса
o План занятий и выделение рабочих групп
. Стандарты и методологии, применяемые для создания единой точки контакта
o ISO 9001 и ISO 20000
o ITIL® и MOF
. Выбор методов описания процесса
o Многообразие возможных вариантов описания процессов
o Наиболее часто используемые методы и инструментарии
. Рассмотрение взаимосвязанных процессов в поддержке
o Роли и задачи процессов управления событиями, запросами и доступом
o Входы-выходы и взаимодействие с другими процессами
. Управление инцидентами - как основа построения единой точки контакта
o Основные принципы и понятия управления инцидентами.
o Портфолио услуг
o Service Desk - самая важная функция для работы с пользователями
o Схема процесса поддержки пользователей
o Основные активности
o Возможные проблемы внедрения
o Роли и ответственности в процессе
o Оптимизация процесса
. Управление проблемами
o Цель и задачи управления проблемами
o Основные определения
o Схема процесса - реактивный и проактивный подход
o Сложности при внедрении
o Выгоды от организации процесса

Часть 2. Практикум

. Проработка кейса
o Изучение компании
o Выделение проблемных зон
o Составление схемы взаимодействия процессов и активностей внутри
. Составление списка необходимых документов
o Политика процесса
o Регламент процесса
o Рабочие инструкции
o и др.
. Разработка документации
o Структура каждого документа
o Основные элементы внутри каждого документа
o Создание готовых документов по условиям кейса
. Заключительная часть курса

*ITIL ® is a Registered Trade Mark of AXELOS Limited.

Вообще техническая поддержка — это боль и слёзы рынка веб-разработки. Самые слёзные жалобы к нам поступают с просьбой забрать какой-то проект на доделки.

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

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

Внутренняя кухня

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

Свои проекты мы делаем по гибкой методологии scrum. Это значит, что в процессе работы клиенту не обязательно придерживаться толстого и нудного ТЗ, а можно добавлять/удалять/изменять любые хотелки прямо по ходу работы. Плюсы: гибкость и прицел на постоянное развитие проекта сразу. Минусы — постоянно неактуальная документация.

Грозовая туча: старые и новые проекты.

Над каждым проектом работает КОМАНДА разработчиков. Это важно, потому что после запуска проекта как минимум два-три человека причастны к коду и могут его поддерживать. На практике это сильно лучше, чем если бы всю разработку делал бы один «незаменимый» гений.

С незаменимостью также помогают бороться две вещи: строгие стандарты кодирования и регулярные code review, которые мы проводим на своих проектах.

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

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

Мне нужно ввести нового человека в проект, чтобы он занимался им дальше на постоянной основе.
Для развития новичков под присмотром куратора.
Очень-очень редко (и рискуя получить за это минусов в карму), но все же: как мера воспитания слишком честолюбивого разработчика с задатками гурмана. Я имею в виду тех редких людей, которые на любую задачу начинают разглагольствовать, что она им не интересна, все технологии — го%но, весь чужой код — вообще го%но и даже свой, который он писал неделю назад — тоже устарел. Он вполне может схлопотать себе на ближайшие 2-3 месяца (или пока не угомонится или пока не станет ясно, что не сработаемся) проекты только на техническую поддержку (это в то время, как его коллеги получают новые, интересные проекты).

При планировании нагрузки на разработчиков мы рассчитываем, что их рабочий день состоит из двух частей: работа над основным проектом (закладываем 6 часов) и технической поддержки (оставшиеся два часа). Как правило, часы техподдержки наступают с 16:00 и до 18:00. Это время хорошо подходит для решения мелких и простых задач. Обратная сторона медали — деплой на продуктивные сервера происходит в конце рабочего дня, и в случае чего целую ночь на продуктиве может висеть кака. На критичных проектах деплой или часть саппорта мы переносим на утро. Если в какой-то день нет задач на техническую поддержку — программист занимается основным проектом.

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

Итак, мелкие и срочные задачи мы вклиниваем в эти два часа в день, с 16 до 18 (ну фактически, с учетом командной работы это может быть и 4 и 6 часов, в зависимости от того, параллелятся ли задания). Крупные задачи, которые можно делать в спокойном режиме, мы запускаем в работу спринтами (минимум по 40 часов), в основные часы. Работа спринтами стоит для клиента дешевле (в пересчете на стоимость часа), чем экстренные и срочные задачи, которые нужно сделать еще вчера.

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

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

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

Что в идеале хотели бы от нас

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

Все остальное, скорее, экзотика.

Проактивных предложений по улучшению проекта

Здесь я должен рассказать, какие проекты попадают нам на поддержку. Всего три типа:

Бесплатная техническая поддержка наших проектов.
Это все проекты на этапе ввода в эксплуатацию и в гарантийный период. Это закреплено договором. Поддержка ввода в эксплуатацию (когда менеджер проекта на горячем старте и готов ответить на любой возникающий вопрос у клиента), как правило, это три месяца. Гарантийный период (как правило, это год) — в течение года мы готовы поправить любые найденные клиентом скрытые дефекты, которые не были обнаружены при запуске проекта. Принципиальные различия между первым и вторым в том, что при вводе в эксплуатацию проект находится в «оперативной памяти» менеджера и многие вопросы решаются проще и быстрее. В гарантийном же периоде мы исправляем бесплатно только явные баги. В спорных случаях мы оставляем за собой право, чтобы клиент обосновал нам, почему это баг. Если на диагностику требуется время и по факту баг оказался не багом — мы так же оставляем за собой право выставить счет на затраченное на диагностику время. Формально это честно, но к таким мерам мы прибегаем в единичных случаях, т.к. это создает неминуемо конфликтную ситуацию.
Развитие проектов, разработанных у нас.
Проекты, которые реализовали в нашей компании часто остаются с нами на многие годы. Развиваются и эволюционируют. Обычно мы добавляем новые функции спринтами (от 40 часов). Нам удобнее и дешевле делать один большой блок работ, чем 100500 мелких-срочных задач: экономится время менеджера, меньше рисков допустить ошибки, значительно меньше требуется контроля, и процесс идет более гладко. Однако срочные и мелкие задачи, когда ГОРИТ, клиент не должен накапливать (это плохо для его здоровья). Поэтому такие задачи тоже могут попасть на разработку, но с наценкой за срочность.
Проекты, которые делали не мы.
Мы очень редко берем на поддержку сторонние проекты. Много мелких проектов не соответствует глобальным целям и идеологии нашей компании. Жизнь за счёт саппорта IMHO, более стабильный, но скучный бизнес. Нет драйва и надрыва, что ли. Поэтому сторонние проекты берем крайне редко и неохотно. Критерии здесь такие (перечисляю в порядке приоритета):

проект должен быть (или потенциально может стать) № 1 или № 2 в своей нише. Или он должен понравиться нам.
код проекта должен быть грамотным.
по проекту есть достаточный объем задач.
клиент адекватно понимает наши принципы и ограничения технической поддержки и принципиально согласен с ними.

Еще раз повторюсь, что такие критерии мы отобрали абсолютно сознательно и отсекли очень много заявок. Если вы готовы работать на поддержке сторонних проектов и сумеете это грамотно организовать — у вас, я уверен, выстроится большущая очередь. Мы же заточены под большие проекты а много маленьких расхерачит нам весь конвейер.

Так вот, про проактивность.

По проектам в активной фазе поддержки, проактивную позицию должен занимать менеджер проекта. Он замотивирован в получении % от проектов. По проектам, по которым нет никаких работ, мы системно проходимся несколько раз в год и стараемся их разбудить. Это хорошая практика, приносящая свои плоды. Будит спящих клиентов, как правило, аккаунт-менеджер. Не всегда спящего клиента нужно будить:)

Ставить задачу в любой, даже в самой безумной формулировке

Это важный момент, который касается ответственности. Ответственность — штука обоюдоострая. Здесь есть несколько принципов, о которых мы договариваемся с клиентом. Как правило, с самими принципами клиент не будет спорить (они понятны и логичны), однако будет пытаться найти лазейку между принципами. Менеджер проекта, кстати, тоже.

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

Хочу ставить задачи через любой удобный канал (скайп, телефон, вотсап, смс-ку). В любое время дня и ночи

Да, но нет. Понятное желание, слепое потакание которому создаст кипиш, панику и неразбериху в студии и сделает любой проект технической поддержки убыточным. Чтобы такое обрабатывать, менеджеру проектов нужно ничего не делать, но всё время быть на стрёме. А это экономически нецелесообразно и морально тяжело. На все проекты по техподдержке мы заводим единую систему хранения задач клиента. Таскменеджер. Там же идет их уточнение, оценки и проставляются статусы. Что это будет технически за система — не так важно (оперативную работу можно организовать и в Google Docs и в портале Битрикса). Самое первое, что требуется для того, чтобы менеджер и клиент притерлись — это настойчиво но вежливо научить клиента писать и отвечать в таскменеджер. Понятно, что все равно в каких-то случаях клиент будет писать по Skype, звонить по телефону или писать 50 писем в течение часа в почту. Задача менеджера здесь: вежливо попросить поставить задачи в таскменеджер. Можно даже ссылаться на то, что в скайпе задача потеряется, пожалуйста, поставьте ее в таскменеджер. Поначалу это может раздражать клиента, однако со временем плюсы такого подхода станут понятны и ему.

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

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

Точных оценок

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

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

Замечу, что работа по time&material на практике для клиента быстрее и дешевле, однако возможна только если клиент доверяет и доволен. Нам это тоже выгодно, т.к. сокращает затраты на менеджмент и бюрократию (а менеджер, напомню, у нас бутылочное горлышко системы).

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

Если вас всерьез интересует вопрос точных оценок — в конце статьи я там насколько ссылок.

Ответственности за сделанное

По схеме работы по финализированным оценкам, все риски по кодированию лежат на нашей стороне. Замечу, что не любой проект мы готовы обслуживать по такой схеме.

При схеме time+material по сути все риски лежат на клиенте. Если ошибок много и их исправление выставляют клиенту — он будет недоволен и вам про это скажет. Как правило, экономически выгоднее не вступать в спор и поправить свои ошибки за свой счёт, не нагнетая обстановку, даже несмотря на то, что согласована схема работы по фактическим часам. Я придерживаюсь того, чтобы исправлять ошибки за наш счёт, если:

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

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

Если косяк откровенно наш — берем и исправляем, не компостируя мозги. Так в итоге дешевле.

Исключение: очень сложные системы с большим количеством зависимостей. Поменяешь запятую в карточке товара — сломается какой-нибудь хитрый импорт, который запускается раз в месяц. Здесь либо нужен code freeze + полный тест системы на каждое изменение (что очень дорого), либо полное покрытие кода тестами (что тоже очень-очень дорого), либо смирение, что такие ситуации возможны.

Замечу, что чтобы схема работала — нужно, чтобы спорные ситуации возникали как можно реже. Иначе клиент будет недоволен поддержкой или поддержка будет убыточной для студии.

Еще нюанс — мы не несем на себе ответственность за 3-х лиц (например, хостинг) или упущенную выгоду. Обычно это воспринимается адекватно.

Оперативности

В наших штатных договорах мы гарантируем время реакции 24 рабочих часа. В 97% случаев это годный вариант. Обращаю внимание, что речь идет именно о времени реакции, а не о времени готовности любой поставленной задачи. Это все на уровне здравого смысла, и нет особого резона требовать от нас с пеной у рта впихнуть в 24 часа невпихуемое.

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

0-8h на приемку и уточнение задачи. Менеджер получает уведомление о создании новой задачи. Банальный деловой этикет и принцип пустого ящика требует, чтобы в течении суток все такие обращения были обработаны. Далее, в зависимости от срочности — задача может быть либо отложена до формирования спринта, либо экстренно запущена в работу, либо запланирована в плане работы на программиста на следующий день. Либо, если формулировки неясны — начинаем работу над выяснением формулировок. Формально, здесь у менеджера есть лазейка включить дурочку и долго-долго чего-то не понимать и уточнять. Однако клиенты это чувствуют и становятся крайне недовольными в таких ситуациях и непременно скажут вам об этом. Останется только разобраться в причинах и применить управляющее воздействие.

8-16h обычно через сутки после того, как задача попала менеджеру проекта и все формулировки понятны, она попадает на разработку. Это связано с тем, что мы планируем, какими проектами будет заниматься каждый программист на утренних планерках (в 8:45) и затем уже стараемся не отклоняться от этого плана. Как правило, задача от клиента попадает в план на разработку на следующий день после постановки (но бывает, что и в тот же день).

16-24h в большинстве случаев мелкие задачи задачи выполняются и отгружаются клиенту за первые 8-16 часов. Еще 8 часов — резерв для выравнивания нашего потока работ или тестирования.

По большим и трудоемким задачам либо формируется спринт, либо — график выполнения, в зависимости от их срочности и приоритетов клиента. Абсолютно непродуктивно делать 30-40 часовые задачи урывками по 2 часа в день.

Понятно, что там, где форс-мажор, все сломалось и нужно все бросить и починить — бросаем и чиним. Если уровень форс-мажора выше 3-5% от всех задач — это повод искать огрехи в организации самого проекта или нашей над ним работы.

Ну и что бы не дорого

У нас две тарифные сетки:

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

Увеличение стоимости связано с тем, что мелкие и срочные задачи способны сломать нам весь конвейер и ставят под удар сроки по другим проектам. Мы стараемся свести срочные задачи к минимуму. Клиенты тоже не любят двойной тариф, но у них есть сознательный выбор. Задача менеджера проектов — предложить клиенту эту альтернативу.

Самое важное. Ретроспективы. Разбор полётов

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

Замечу, что в долгосрочной перспективе бухтение клиента практически неизбежно (ну или я не знаю случаев, когда клиент был бы целиком доволен 2-3 летним итогом поддержки, не имел каких-либо нареканий и время от времени не смотрел бы на сторону). Итак.

Довольно правильно делать с клиентом пересмотр сделанного за 2-3 месяца. Формально анализировать список задач и смотреть причины возникновения ошибок. Это могут быть формулировки, и в этом случае вы совместно должны решить, как вам улучшить постановку задач. Это могут быть слишком частые ошибки программирования, и тут нужно искать причины на своей стороне. Наконец, клиент может быть недоволен тем, что его не отговорили от каких-то его идей и это привело только к лишней трате денег.

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

Без этого в долгосрочной перспективе вас сольют.

Итого

Спрос на техническую поддержку сейчас значительно превышает предложение. Особенно в кризис многие будут стремиться «подлатать сайт», а не стартовать какие-то серьезные работы. Тем не менее, организовать работы грамотно, чётко и рентабельно здесь ОЧЕНЬ сложно. В первую очередь потому, что требуется высокие и разносторонние компетенции менеджеров и разработчиков. Оперативность, многозадачность и частые переключения. Много-много рутины. И это все на фоне высокой конфликтности атмосферы.

Нажмите на картинку для перехода к интерактивной карте

Текст пишу в реальном времени, т.е. за этим словом, я даже не знаю какое будет следующее. :)

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

С1.1. Проблематика и отклонения в типовых ситуациях

Нет понимания между службой ИТ и руководством организации. Что приводит к конфликтам, которые потом выражаются в виде анекдотов аля "я - дартаньян, а руководство - ...". Хотя в большинстве ситуаций реальность противоположна.
Пользователи в шоке
1. вынуждены тратить свое время на то, чтобы у них все работало
2. не редко получают хамство вместо помощи
3. доверие к службе ИТ отсутствует, т.к. одни и те же, элементарные вопросы нужно повторять, напоминать, т.к. они забываются или забиваются;
4. про пожелания к развитию можно вообще забыть... делается только то, что хочется специалистам по ИТ, а не то, что нужно пользователям или организации;
В службе бардак
1. Мало кто или практически никто из специалистов не понимает, что является результатом их труда;
2. Путается понятие ведущих специалистов и руководителей, точнее ведущих специалистов назначают руководителями
3. Загрузка специалистов под большим вопросом, а ее справедливость - тем более.
4. Энергия людей распыляется в разные стороны, в итоге усталость - есть, а заметных результатов - нет.
Высокие издержки организации
1. Одни и те же сбои в процессах повторяются многократно, но это мало кого волнует
2. Простои в процессах также имеют место быть, но это также быстро забывается и повторяется с завидной регулярностью.
Ну и последнее, но наиболее важное... без управления процессом специалисты думают, что ИТ как то завязаны на компьютеры, и вместо развития ИТ, занимаются компьютерной техникой.

С1.2. Желаемая ситуация

Клиент всегда прав. Организация, руководство организации и ее сотрудники являются клиентами службы ИТ.
1. Ключ к сердцу клиента - факты и цифры, показывающие динамики и позволяющие делать прогнозы, чтобы принимать решения.
2. Все люди, белые и черные, принимают решения одинаково (за исключением клинических отклонений в развитии разума и закрытие в дурдоме). Разность лишь в исходной информации. Умение подобрать нужную информацию - это основа успеха и понимания.
3. Сбор нужной информации это один из результатов правильной организации поддержки.
Нужно получить доверие пользователей
1. Они должны быть уверены в том, что сообщив один раз свою мысль, она будет записана, рассмотрена, будет ответ или решение. А не игнорирование или "а я забыл".
2. Первая фраза человека достигшего состояния Будды: я это ты. Если вы видите перед собой тупого человека... задумайтесь. Это не шутка.
3. Начинается все с записи обращений, но затем списки (базы данных, реестры, справочники) расширяются с развитие всей системы.
Порядок - дело тонкое
1. Результат службы ИТ это наличие нужной информации у сотрудников и отсутствие простоев в их деятельности. Но это лишь слова. Понять это сложно и понимание этого приходит лишь после некоторого времени использования системы управления ИТ.
2. Справедливость штука сложная. Для ее понимания есть отдельная статья и она
3. Кто у руля ИТ? Руководитель или специалист? Есть очень простой тест: ведется у вас регистрация обращений пользователей? Если - да, то у руля или руководитель или человек подающий надежды, если - нет, гнать нужно этого руководителя в шею, или понижать до специалиста, пусть даже ведущего.
4. У любого действия должен быть приоритет... и в первую очередь должны выполняться те действия, которые дают больший эффект с точки зрения целей организации. Добиться этого не просто, но реально.
Режем издержки
1. Простои минимизируем любой ценой, кровь из носу, т.к. любой простой это не просто "ща ща починим", это последствия, которые не всегда можно отследить, снижение репутации, потери клиентов и т.д.
2. Сбои нужно записывать, выслеживать причины, причины устранять - повторяющийся сбой это позор джунглям.
Ну а выполнив эти 4 пункта, приходит понимание, что ИТ - это ИТ, и им уже сотни тысяч лет... а комьютеры - это компьютеры им всего-то лет 50 и сейчас они используются чаще, чем стены пещер лишь потому, что чуть-чуть эффективней и не более того:)

С2. Особенности

Ключевой факто успеха это регистрации всех обращений пользователей. Ключевое слово в этом предложении: всех . Начнешь халтурить и пропускать обращения - пошел вон, ты не руководитель.
Когда добьешься регистрации всех обращений, то система начнет развиваться... сразу становятся заметны узкие места:
1. нет инструкций по процессам или инструкции кривые - много вопросов
2. нет обучения сотрудников - много вопросов
3. оборудование или программы слабо настроены или плохо подобраны - много сбоев
4. специалисты занимаются чем попало, но не тем, что нужно для организации, а значит и для руководства.
5. если проект какой-то плохо выполните, то динамика обращения подпрыгивает... надо проекты лучше планировать...
6. ну, в общем картинка становится ясная и в голове сразу появляется множество идей о том как улучшить ситуацию...
Очень важный элемент системы это CMDB или КБД - конфигурационная база данных или объекты услуг:
1. Здесь указываются все объекты, которые попадают под сферу влияния ИТ, для того, чтобы отслеживать те действия, которые над ними выполняются.
2. Частота сбоев по программам... что чаще вызывает сбои 1С БП 8 или 1С БП 7.7? Как следствие кто из них вызывает больше затрат?
3. Какие изменения и кто выполнял в программах? В каких? Пришло время перехода на новую версию? Какие изменения стоит повторить, а какие нет? Сколько это по финансам? Тут ответы находятся в лет.
4. Кто то пытается сюда же пихать мышки и сетевые карты... это личное дело каждого и каждый сходит с ума по своему... но мой опыт показывает, что такая детализация дает много затрат и мало толку и по сути это мартышкин труд.
5. В основном если вы отвечаете за ИТ, то достаточно вести учет в разрезе программ, баз данных, модулей системы, а компьютеры ваще можно записать как Компьютеры, даже без детализации по кабинетами, не говоря уже о детализации по комплектующим)
6. А если вы отвечаете еще и за качество (это уже ИСО 9000), то сюда же можно внести перечень всех инструкций и регламентов регулирующих и нормирующий порядок действий сотрудников. В этом случае руководство на вас уже молиться начнет, свечки в церквях ставить за ваше здоровье. Это не считая прочих бонусов и соц.пакетов))

С3. Варианты решений

Рассмотрим для начала характеристики обеспечивающие качество ИТ
1. Основные, обязательные, которые нужно выполнить в первую очередь
  1. Запись обращений, даты приема, даты завершения, еще можно результат фиксировать
  2. Регулярный (ежедневный, еженедельный, ежемесячный) мониторинг показателей, загрузки, результативности, динамики...
2. Дополнительные, удобные, улучшающие, можно выполнять во вторую очередь
  1. Запись изменений, проектов, объектов услуг для дополнительных разрезов анализа
  2. Ведение истории общения по обращениям, автоматические рассылки уведомлений на эл.почту обратившимся.
Инструменты
1. 1С ИТИЛИУМ
  1. Плюсы
    1. Основные требования тут выполнены
    2. Можно изменять ПО
    3. Можно найти пиратку
    4. Есть настройка автоматических уведомлений о создании
    5. Сильная отчетность
  2. Минусы
    1. Историю переписки вести тяжело, нет уведомлений о комментариях на эл.почту или возможности отвечать письмом
    2. Веб-морда тяжелая
  3. Рекомендации
    1. Для безденежных пиратов
    2. Тем, у кого политика привязана к 1С
    3. Тем, кто любит ковырять программы и любит 1С
  4. Цена что-то около 50 т.р. за ПО, услуги добавляются по вкусу.
  5. Заметки
    1. мне нравится т.к. это была моя первая система на которой построил управление ИТ
2. eStreamDesk - одно из наиболее эффективных решений
  1. Плюсы
    1. веб-ориентированная и модель SaS, т.е. доступ из любого места и не надо парить голову с правильной установкой и тех.поддержкой
    2. интегрирована с Google Apps
    3. есть русский язык
    4. есть конструктор автосообщений как при добавлении и закрытии обращений, так и о переписке по ходу решений;
    5. реально пользоваться даже бесплатным вариантом
  2. Минусы
    1. кривоватый код, глюки и плюшевой интерфейс
    2. отсутствует CMDB
    3. слабая отчетность
  3. Рекомендации
    1. для малых проектов, там где есть проблемы с финансами
    2. и если нет юридических отношений, т.к. у обращенцев нельзя указать организацию
  4. Цена от 0 до см. сайт. Услуги тут если и нужны то по минимуму т.к. функционал базовый.
  5. Заметки
    1. им бы код до ума довести, отчетность гибче и возможность ведения базы пользователей по организациям - было бы клево.
3. Mojo HD
  1. Плюсы
    1. те же, что и у п.2, но более приятный, отлаженный интерфейс и русификация чуть сложнее
    2. отчетность хорошая
    3. гибкий конструктор уведомлений о изменениях, комментариях...
    4. возможность отвечать на эл.почту
    5. ведение базы пользователей по организациям
  2. Минусы
    1. русского языка нет, но весь интерфейс можно переписать хоть на грубый мат
    2. цены относительно кусачие, бесплатным вариантом пользоваться не реально
  3. Рекомендации
    1. для устойчивых проектов, с наличием стабильных финансов
    2. тем, у кого нужно вести клиентуру по организациям
  4. Заметки
    1. цены чуть потише и можно считать идеальной системой для внутренних служб и проф.бизнесов
4. ДИРЕКТУМ
  1. Плюсы
    1. Есть выделенный модуль IT.Now но с заточкой под мышки. Нарушение принципа С1.1. п.5. Что-то типа 1С ИТИЛИУМ, но мене гибкий и похуже.
  2. Минусы
    1. Те же, что и у 1С ИТИЛИУМ
    2. Выделенного и продуманного модуля в части ИСО 20000 - нет. 1С ИТИЛИУМ перекрывает возможности в лет.
  3. Рекомендации
    1. Можно написать свой модуль... что оправдано в сложных ситуациях... например в гос.управлении и в гос.услугах, там где практика еще не наработана, но нужна интеграция с большим бумажным документооборотом.
  4. Заметки
    1. ДИРЕКТУМ хорошая система ЭДО, и построение ИТСМ на ее базе оправдано лишь в том случае если на этой системе строится все остальное. как уже было сказано например в гос.управлении.
5. 1С ITIL чего-то там от Рарус
  1. Плюсы
    1. это 1С
  2. Минусы
    1. сама программа написана теми, кто полностью подчинен стереотипу из С1.1. п.5. ориентирована на учет мышек и микросхем, вместо контроля характеристик по процессам.
  3. Рекомендации
    1. Для тех у кого нет сил сломать свои стереотипы и вместо ИТ хочется и дальше заниматься компьютерами да программами.
  4. Заметки
    1. Рарусу самим тех.поддержку нужно выправить. потом уже другим решения предлагать.
    2. субъективно меня чуть не стошнило при изучении этой программы.
6. HP, IBM и иже с ними
  1. большие и сложные, скорее всего ориентированы на большие объемы обращений.
  2. может быть интересны для таких монстров как Мегафон или Билайн, там где толпы пользователей.
  3. слышал, что Газпромовцы такие решения покупают. наверное там откаты вкусные.
7. Naumen ServiceDesk коробка
  1. не видел, но чую, что интересно.
8. Naumen ServiceDesk SaS
  1. Скоро обещают выпустить.
  2. Учитывая опыт Наумен решение должно получиться интересным.
  3. Если они выберут ценовую политику как у Мегаплана, то я их даже наверно постараюсь полюбить.
  4. Очень надеюсь, что тут получится аналог Можо ХД (п.3), но с ценовой политикой как у Мегаплана.

С4. Резюме

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

С5. Просьба

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

С6. Копирайты

Наши группы на Инфостарт (заброшены правда, т.к. от 1С сейчас слегка отошел, чуть другими проектами занимаюсь)
1. Инструкции и регламенты для 1С Предприятие
2. Технология внедрения 1С Предприятие
Обещанная ссылка на управление проектами

Видеопомощь

В этом видеоролике описана следующая информация:
— Общая информация о проекте;
— Процедура регистрации в сети православных сайтов Prihod.ru;
— Авторизация в сети православных сайтов Prihod.ru;
— Как создать свой первый сайт в сети;
— Заполнение формы регистрации сайта;
— Основная информация о шаблонах сайтов.

Если вы уже создали сайт, то наведите курсор на «Мои сайты» в левом нижнем углу и в выпадающем меню выберите пункт «Добавить сайт».

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

Вы сможете отредактировать введенные данные в консоли сайта в разделе «Регистрация».

Форма регистрации сайта

При заполнении полей слева в черном окошке появляется подсказка по заполнению этого поля. Если вы ввели ошибочные данные, об этом также выведется уведомление красным шрифтом.

Вкладка «Помощь». На вкладке «Помощь» вам предлагается ссылка на видеоролик, в котором рассказывается, как заполнять поля при регистрации. Если у вас нет возможности его просмотреть, вы можете использовать эту инструкцию.

Также на вкладке «Помощь» вам будет предложено выбрать основной язык сайта.

Чтобы перейти к регистрации, нажмите кнопку «Далее».

Первый шаг. На первом шаге регистрации нужно указать общую информацию о сайте.

Сначала выберите страну, от этого зависит на каком домене будет находиться Ваш сайт. Каждому сайту на Prihod.ru дается доменное имя третьего уровня. Для Украины это домен church.ua, для всех остальных стран — cerkov.ru или для православных организаций pravorg.ru. В дальнейшем вы сможете .

Обратите внимание, что на нашем проекте создаются только официальные сайты храмов, монастырей, благочиний, епархий и организаций при них. Сайты, создаваемые по самостоятельной инициативе пользователей без благословения настоятеля, не публикуются в сети православных сайтов Prihod.ru.

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

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

Обратите внимание! Сайты, относящиеся к Украинской Православной Церкви , в обязательном порядке должны иметь доменное имя на church.ua (например, vashHram.church.ua).

Итак, у вас получится доменное имя вида domain.cerkov.ru, domain.pravorg.ru или domain.church.ua.

Мы не рекомендуем указывать полное название храма (Местная Православная религиозная организация ‘Приход храма такого-то’), т.к. получается очень длинное название, это сбивает с толку непросвещенных мирян. Лучше указывать так: ‘Храм Живоначальной Троицы, поселок Доброе’.

Второй шаг . На втором шаге

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

Под каждым шаблоном приведено краткое описание его особенностей. По умолчанию устанавливается шаблон .

Сменить шаблон уже в процессе работы над сайтом нельзя , но вы можете просто удалить ненужные страницы, рубрики и записи или добавить новые. Самый кардинальный вариант — удалить полностью сайт и создать заново.

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

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

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

Организация служб технической поддержки – наш «конек», так как специалисты «Открытой Линии» имеют соответствующее профильное образование и большой опыт организации подобных служб.

Услуга представляет собой обслуживание поступающих от абонентов вызовов с вопросами технического характера.

На Ваш проект мы подберем операторов необходимой квалификации и с соответствующим образованием. Они будут приветствовать абонентов от лица Вашей компании и сделают все для решения возникшего вопроса.

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

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

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

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

Проанализировав Ваши бизнес-процессы, менеджер проекта предложит Вам оптимальную схему распределения вызовов. В некоторых случаях эффективно разделить вызовы на 2 типа: вопросы общего характера, которые будут отработаны более дешевыми специалистами (первая линия), и вопросы узкопрофильного технического характера, которые будут в компетенции инженеров Службы технической поддержки. Это ведет к оптимизации издержек на обработку вызовов абонентов и улучшает ситуацию с дозвоном, так как разгружает линию высококвалифицированных специалистов от звонков с простыми вопросами (напр., «где расположен Ваш офис», «часы его работы» и другое).

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

В периоды существенного повышения потока звонков мы готовы расширить число операторов на линии для повышения комфорта абонентов при дозвоне в компанию.

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

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

Преимущества использования наших ресурсов по сравнению с Вашими специалистами:

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