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

В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки 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. Автобусный сервис отсюда