«Поддержка», как много в этом слове…

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

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

С чего все начинается

Итак, традиционно, начнем с основ. Попробуем ответить на вопрос:

что есть служба поддержки и для чего она нужна?

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

Допустим, у нас есть компания — производитель автобусов, в которой наличествуют отделы «разработки и производства» и отдел «технического обслуживания», который осуществляет гарантийное обслуживание проданных автобусов. Есть также вторая компания — потребитель, которая купила один из автобусов, чтобы возить своих сотрудников по некому маршруту внутри кампуса/офисного городка. Так вот, в данном конкретном примере мы получаем следующую картину:

Компания-потребитель имеет:

• пользователей – это пассажиры автобуса
• «службу поддержки» — это диспетчер, или справочная, и кондукторы в самом автобусе,

которые позволяют пассажирам решать возникающие сложности.

А в компании – производителе мы имеем:

• разработчиков – это отдел «разработки и производства»
• и тоже, «службу поддержки» – в данном случае, это уже отдел «технического обслуживания»

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

Но это хорошо видно на примере с автобусами, но, почему-то, совсем не очевидно в случае IT.
Давайте попробуем разобраться несколько подробнее.

Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает. Получается некий парадокс, вроде бы и там и тут – IT сфера, и там и тут вполне себе грамотные сотрудники и руководители, но в одном случае все в принципе работает вполне себе даже приемлемо, а в другом – как получится. В чем же разница? Почему мы можем обеспечить поддержку оборудования, ОС, вебсервисов, но при этом с поддержкой бизнес-платформ, таких как учетные системы, системы анализа данных, документооборота, управления ��изнес-процессов и прочих – зачастую возникают сложности? В чем может быть загвоздка?

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

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

И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:

— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?

С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.

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

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

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

Итак, на текущий момент мы, в общем, двигаемся в верном направлении. Примерно об этом нам говорят книжки из ITIL, множество прочитанных статей, да и логика тоже это подтверждает. И на самом деле, тут откровений нет. Но они будут дальше.

Итак, у нашего руководителя все получилось хорошо, все счастливы, и уже компания – производитель этой самой учетной системы, пригласила его/ее наладить их «службу поддержки». И вот тут начинаются чудеса. На новом месте он/она вновь задается теми же самыми вопросами, что и ранее:

— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?

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

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

Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.
Резюмируя, мы получаем следующую картину:

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

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

К чему обычно приходим

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

1. Использование чат-ботов. Последнее время эта тенденция набирает силу и многим кажется, что это отличный способ сэкономить на количестве сотрудников. При этом никто даже не задумывается о том, с какой целью люди обращаются в отдел поддержки и сопровождения. Так вот, чат-боты и прочие поисковые возможности строго необходимы, когда пользователь не может (при плохо структурированной или сложной и запутанной организации так называемой «базы знаний») или не хочет (в силу чрезмерной занятости или лени) искать информацию самостоятельно. Иными словами, только в случае, если пользователь не понимает или не может найти нужную информацию в онлайн-документации достаточно быстро, то ему в этом поможет расширенное средство поиска или чат-бот. Никаких нестандартных или технических проблем чат-бот касаться не должен. Этого, к сожалению, мало кто понимает. Конечно, есть огромное желание заставить пользователей, наконец, пользоваться документацией и статьями, размещенными на соответствующем портале, а не обращаться к сотрудникам отдела по уже расписанным и простым вопросам. Однако правильнее и проще это решается административными методами, а не попыткой все ухудшить. И второй момент, подключение службы поддержки на помощь «по каждому чиху» пользователям не самое коммерчески выгодное решение. С одной стороны, компания берет на себя ответственность за предоставляемые решения, а с другой – это ни как не компенсируется. Иными словами, такой подход отбирает хлеб у отделов внедрения/professional service.
   
   
2. Экономия на сотрудниках. Очень популярно разделение сотрудников по квалификациям на уровни поддержки, и набор «самых тупых» (то есть самых дешевых) на первые линии поддержки. Хотя изначально подразумевалось, что деление на уровни поддержки носит функциональный а не квалификационный характер. Получается как вариант предыдущего пункта с чат-ботами. Управляющий персонал просто не в состоянии правильно организовать взаимодействие сотрудников отдела с пользователями, и пытается решить проблемы в лоб – набором большего количество сотрудников за цену, которая имеется в распоряжении. В результате качество обслуживание просто падает, и, к полной неожиданности менеджеров, нагрузка на «квалифицированных» сотрудников только возрастает.
   Я уже молчу про специальное обучение сотрудников поддержки.
   
   
3. Использование телефона как основного способа обращения за поддержкой. Вообще, довольно странно видеть, что зачастую при организации отделов поддержки/сопровождения отдается предпочтение созданию call-центров. Если мы говорим про поддержку IT систем, то один телефонный звонок требует примерно столько же ресурсов, сколько обработка 2-3 инцидентов, поданных через портал, форум или email. Звонки иногда нужны и важны, но далеко не всегда такой дорогой (для отдела) вид коммуникации рационален и удобен именно с точки зрения организации поддержки пользователей и/или заказчиков. Даже если не вдаваться в подробности мониторинга качества продукта и/или услуг, организации комфортной коммуникации с пользователями/заказчиком, то даже вопросы доступности и распространения опыта и знаний внутри коллектива, при телефонных коммуникациях, требуют дополнительных усилий и затрат.
   
   
4. Использование службы поддержки в роли секретариата. Иными словами, когда первая линия поддержки играет роль своего рода отдела диспетчеризации и направляет пользователей к нужным сотрудникам, в зависимости от имеющихся вопросов и возникших проблем. На самом деле это тревожный «звоночек», что в компании «что-то пошло не так». Служба поддержки хоть и является составной частью CRM (Customer Relationship Management) — системы управления взаимоотношениями с заказчиком, но является именно ее частью, а не ее подменой. Поэтому, когда заказчик обращается в службу поддержки с проблемой, что у него закончился период действия лицензии на продукт, то это значит что аббревиатура CRM в компании для галочки, а профильные отделы (в данном случае, отдел продаж) занимаются чем угодно, кроме своей прямой работы. И поэтому сотрудники поддержки/сопровождения будут работать «передастами» между заказчиком с одной стороны и коммерческим отделом, отделом лицензирования, fulfillment департаментом – с другой.
   
   
5. Имитация «персонального» сопровождения, когда сотрудники отделов поддержки подписываются только именем, например «Мария», «Иван» и т.д. Я, конечно, понимаю, что за рубежом это рядовое явления и, с одной стороны, намекает на «теплые дружеские отношения», а с другой — несколько тешит самолюбие западных пользователей (слуги не имели фамилий), но даже там это имеет смысл только в очень редких случаях. В практике IT поддержки это создает только трудности. Простейшая ситуация: в отделе четыре человека носят имя «Алексей» (реальный случай), при этом в силу обстоятельств в офисе присутствует только один из них (второй — в отпуске, третий — заболел, четвертый — в командировке) и возникает проблема по одному из инцидентов, который обслуживался неким «Алексеем». Как положено, тот, кто в офисе, понятия не имеет о чем идет речь. Что делать супервайзеру/лидеру или начальнику отдела, если заказчик ссылается на некие устные рекомендации, полученные от «Алексея»?
   
   С другой же стороны, когда к Вам обращается некий «Федор», это далеко не всегда комфортно, поскольку Вы не знаете этого человека, его никто не представлял, чтобы разводить «панибратство» и вообще, как Вы можете быть уверены, что «Федор» это его реальное имя?
   Поэтому всегда, при любом ответе компании в подписи должны быть, как минимум, фамилия и имя человека, отправившего сообщение. Даже если данное письмо/сообщение идет от коллектива в целом. Кроме того, если обращение начал обрабатывать один сотрудник, то он и ведет работу по данному конкрет��ому инциденту до конца, без постоянного переключения участников со стороны компании. Смена допускается лишь при необходимости (например, заболел, или перегружен более важными запросами, или же работу «подхватили» сотрудники «технической поддержки») и новый ответственный сотрудник всегда должен представиться и указать будет ли он до конца работать по заявке, или же только временно ее обрабатывает. Вообще, все это очень странно и создается впечатление, что основами административной работы многие менеджеры просто не владеют.
   
   
6. Создание отделов «Customer Success», «Technical Enablement» и прочих «Fulfillment». Опять же, это мода последнего времени, в основном связанная с восторгом от «Agile» методов ведения разработки и является попыткой наладить обратную связь, что называется, «в лоб». К сожалению, в реальности это обычно является показателем того, что потерпев неудачу в организации нормальной работы как отделов внедрения, обучения, сопровождения/поддержки пользователей в частности, так и во внедрении CRM методов – вообще, люди начали лепить рядом с кое-как уже работающими отделами, новую дублирующую службу. Увы, довольно часто с тем же успехом.
   
   
7. «Карго-культ» ITIL/ITSM. По факту — это самая большая проблема организации работы служб поддержки. Артефакты фреймворка требуют достаточно глубокого анализа перед их внедрением и четкого понимания, что мы делаем, ради чего, как и почему именно так. Для примера, возьмем CMDB – базу данных конфигурации/настроек и истории их изменений. Рассмотрим простой вопрос: какую информацию/атрибуты и их изменения нам нужны в случае, если мы осуществляем поддержку некой бизнес-платформы (допустим, учетной системы)? Есть соблазн туда добавить все, что только можно, но для компаний уровня «1С», с десятками тысяч заказчиков – это превратит систему в могильник никому ненужных деталей.
   
   Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.
   
   Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.
   
   
8. «Кривые» KPI. Этот пункт идет «вне конкурса», как и все метрики эффективности вообще. То, что они нужны – теперь уже понимают все. Но вот вопросы: «для чего?» и «какие именно?» – являются уже «вопросами на засыпку» для подавляющего числа управленцев. Так же обстоит дело и в случае оценки эффективности работы отделов поддержки/сопровождения. Простейший пример: как оценить полезность отдельно взятого сотрудника отдела? Количеством обработанных инцидентов? Если да, то значит ли это, что 100 решенных проблем за неделю лучше, чем 10? В реальной жизни – далеко не значит. Эти 10 инцидентов могут быть настолько сложными и важными, а та сотня – просто самыми легкими, что сравнивать в лоб количества – просто бессмысленно. К огорчению, мало кто вспоминает, что сутью KPI является численная характеристика для рутинных, повторяющихся и однотипных работ/процессов. Поэтому в числах отобразить вклад сотрудников поддержки не так уж и легко, как кажется на первый взгляд и он будет выражаться некой интегральной метрикой.
   
   Кроме этого, анализ работы служб поддержки позволяют оценить и качество работ внешних поставщиков услуг и/или отдела разработки. Эту часть анализа деятельности зачастую вообще игнорируют.
   

На этом у меня все. Ваши комментарии и аргументированные замечания – всячески приветствуются.

Всем удачи и успехов.

Источники изображений:

1. «Мерзлый» песик — отсюда
2. «Суровый» пес отсюда
3. Call-центр: отсюда
4. Автобусный сервис отсюда