Облачно, возможны осадки в виде заявлений

Меня зовут Роман Ишмухаметов. Я возглавляю команду сопровождения 1С:ERP на 5000 пользователей. Мы обслуживаем предприятие, состоящее из 9 заводов машиностроения с общей численностью сотрудников 18 000 человек. Заводы территориально расположены по всей России – от Уссурийска до Ростова-на-Дону.
 

Представьте себе картину: ночь, тишина, вы спокойно спите, видите хороший добрый сон, и тут звонок: «У нас документ не проводится! Пишет, что не хватает остатков!»

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

Жизненный цикл проекта

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

Согласно методике «1С:Технология быстрого результата», сопровождение продукта начинается сразу же после внедрения первого функционального блока. Как только пользователь получает возможность вносить какие-либо данные, понадобится кто-то, кто возьмет на себя задачи техподдержки.

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

Варианты организации техподдержки

Организовать сопровождение можно различными способами. Рассмотрим три базовых.

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

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

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

Ключевые задачи сопровождения

Какой бы вариант сопровождения вы не выбрали, задачи техподдержки предопределены:

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

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

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

И все это – ежедневные задачи техподдержки.

Трудности работы специалиста техподдержки и функциональное разделение

Если переложить 8-часовой рабочий день специалиста техподдержки на схему, получится замкнутый цикл, который можно охарактеризовать выражением «как белка в колесе».

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

• Бешеный поток входящих неформализованных тикетов.

• Отсутствие удобной базы знаний.

• Капризный пользователь с плохим настроением.

Все это делает рабочий день специалиста невыносимым. В любой момент сотрудник может вспыхнуть и сказать: «Все, хватит! Надоело!».

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

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

Мы выделяем первую, вторую и третью линию:

• Специалисты первой линии сопровождают один или два функциональных блока в рамках существующих инструкций.

• Специалисты второй линии уже работают по вопросам, где нет инструкций, либо на стыке блоков.

• А на третьей линией специалисты занимаются развитием системы – у них свой порядок работы.

Психотипы сотрудников

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

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

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

• «Мыслитель» прекрасно справится с объемными и непростыми задачами. К примеру, с ошибками при закрытии месяца.

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

• «Теоретик» будет чувствовать себя как рыба в воде на задачах по улучшению системы.

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

Как разнообразить серые будни техподдержки

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

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

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

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

Во-первых, мы добавили сотрудникам ответственности – включили их в процесс управления нетиповыми задачами.

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

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

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

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

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

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

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

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

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

Чем понятнее функциональное деление в вашем отделе, тем проще вам будет переключать внимание сотрудников.

Но в подобных ротациях всегда надо учитывать риск того, что будет некая просадка на время адаптации.

Польза недостижимых высот

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

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

К этому проекту мы не могли подступиться долго – он пугал своими масштабами.

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

Мы расписали всю последовательность действий, определили конкретные шаги и получили эффективный результат.

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

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

Речь – универсальный инструмент отношений. 5 принципов построения диалога

Я считаю, что залог нашего успеха состоял в том, что постоянно были в диалоге. Речь – это универсальное средство взаимодействия.

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

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

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

Во-первых, следует определить цель разговора.

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

• А могут быть связаны с самим специалистом: узнать его ожидания, амбиции, понимать причины тех или иных простоев.

• Также целью разговора может выступать весь отдел – скажем, обсудить вектор развития направления или скорректировать какие-то организационные вопросы.

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

• Чаще всего это текущие задачи или обсуждение инструментов service desk.

• Реже – что-то отвлеченное от работы.

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

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

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

Приведу один из часто встречающихся сценариев беседы в нашем отделе.

• Допустим, наша цель – определить ответственного за новое направление «Подготовка пользовательской документации». Специалист должен определить правила ведения данного раздела. Определив кандидата, мы приступаем к диалогу.

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

  • Во-первых, я всегда понимаю текущую ситуацию и вовремя ловлю отклонение service desk от реальности.

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

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

• Количество инструкций, скорость поиска ответа, усвояемость материала – все это количественно измеряется, и в нашем разговоре появляются конкретные метрики.

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

• Оценить результат будет несложно – через установленный срок вы должны увидеть единообразие в пользовательской документации.

Досуг команды, как альтернатива диалогу

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

Рекомендую в качестве альтернативы диалогу использовать досуг команды. Понятно, что в условиях офиса общие занятия найти проще. А для удаленных команд мы составили список, который представлен на слайде.

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

При возможности организуйте очные встречи. Никакая видеоконференция не заменит магии живого общения.

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

Тут главное – не допустить соревнования ради соревнования. Конкуренция должна быть здоровой. А вы, как руководитель, можете создать все условия для развития специалистов вашего отдела.

Хорошим поводом для неформального собрания коллектива является конференция Инфостарта.

Сопровождение – самое сложное

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

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

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

• Простая беседа «ни о чем» может скрасить будни специалиста и подсветить вам его настроение.

• Лучше действовать, чем не проявлять активность.

• Разговор и действие являются неотъемлемой частью развития сотрудников и отдела.

Вопросы и ответы

Вы сказали, что у вас численность предприятия – 18 тысяч сотрудников на 9 филиалов. Какой Service Desk вы используете на такое количество сотрудников?

18 тысяч – это общая численность сотрудников на заводах машиностроения. А активных пользователей у нас 5000.

В качестве Service desk мы используем 1С:ITIL – недавно перешли с Итилиума на 1С:ITIL. И он вполне эффективно справляется с нагрузкой.

Какие меры вы предпримете, если у вас в отделе возникнет конфликт с сотрудником, и он после этого не захочет с вами коммуницировать?

Мы понимаем, что команда – это сложная структура. И если какой-то элемент этой структуры никак не хочет укладываться, необходимо либо вывести его за контур сопровождения – дать ему какое-то индивидуальное направление развития, либо нам не по пути с таким сотрудником.

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

У нас есть набор базовых инструкций.

• Есть инструкции пользователя, чтобы новый специалист мог ознакомиться с работой системы со стороны пользователя.

• Есть инструкции консультанта.

• Плюс есть такой элемент как наставничество.

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

Пробовали ли вы для введения сотрудников в должность игровые варианты?

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.