Какие софт скиллы нужны консультанту поддержки

Больше семи лет Анастасия Чехонина, старший консультант департамента EPM КОРУСа, работает на проектах поддержки систем бюджетирования. Опираясь на свой опыт, Настя расскажет, в чем заключается работа консультанта поддержки и кому она может подойти.

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

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

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

Есть в нашей работе и что-то медитативное. Например, настройки цепочек регламента. Мой любимый заказчик перед началом каждой бюджетной кампании присылает для настройки цепочки согласования примерно по ста бюджетам. Суть настройки состоит в проставлении порядка согласования (цифры от 1 до 7) для пользовательских ролей на верхних уровнях МВЗ (место возникновения затрат) и проектов. Затем для каждой цепочки нужно выполнить запуск расчета для детализации цепочки до нижнего уровня справочников. Такой работой приходится заниматься на протяжении двух недель. Одна из коллег сказала, что для нее такая работа похожа на медитацию. Я, в принципе, с ней в этом согласна.

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

• Спокойствие и стрессоустойчивость. Консультанты поддержки много взаимодействуют с пользователями и обрабатывают большое количество срочных запросов. Важно уметь не паниковать, а последовательно выполнять задачи. У меня бывали случаи, когда спешка приводила к серьезным ошибкам, в результате чего сначала приходили письма от заказчиков, а затем приходилось восстанавливать данные из бэкапа и довносить через Smart View данные из аудита, введенные пользователями за последнее время.
• Умение находить общий язык с разными людьми. У всех пользователей разный стиль общения и к каждому нужно найти подход.
• Умение просить помощи у более опытных коллег. У каждого заказчика есть свои особенности в модели, и в определенных случаях нужно поступать только так, а не иначе. Если вы только начинаете работать над проектом, лучше уточнить у опытных коллег о нюансах и особенностях процессов. 
  Например, работая с проектами на Oracle, мы часто сталкивались с историей, когда заказчик просит листовой элемент справочника сделать узловым и добавить под него потомков. Если поступить подобным образом в Oracle Hyperion, то данные на элементе затрутся после запуска агрегации, если оставить элемент хранимым, или сразу, если сделать его «динамиком». Но я не раз встречалась с ситуацией, когда молодые сотрудники совершали подобную ошибку, аргументируя это тем, что «клиент же попросил». Нужно понимать, что клиент транслирует конечный результат и может не знать деталей, как правильно реализовать задачу. В моей практике, в этом случае обычно создается новый узловой элемент с аналогичным названием, а старый листовой элемент вместе с новыми потомками помещается под него. Можно, конечно, и листовой элемент сделать узловым, но тогда с него предварительно нужно скопировать данные на один из его будущих потомков. В результате таких ошибок мы восстанавливали данные из бэкапа. Хотя, этого можно было легко избежать, если бы сотрудник уточнил этот момент у коллег перед реализацией.
• Ответственность. Пользователям системы важно соблюдать сроки бюджетного регламента, поэтому им необходимо, чтобы их запросы обрабатывались максимально быстро и точно, чтобы не пришлось тратить лишнее время на несколько итераций по уточнению требований, тестированию и проверке устранения ошибок.
• Любопытство. При решении запроса мне всегда очень любопытно, в чем причина ошибки и как сделать, чтобы все работало. Это сравнимо с разгадыванием загадок или прохождением квеста, и в конце всегда радостно, когда ответ находится.

1. Молодым специалистам. Разнообразие задач по сравнению с работой на проектах внедрения меньше, но количество однотипных задач и их объем может быть таким же. Благодаря этому вы сможете изучить систему и наработать опыт за счет повторения однотипных действий. Также на поддержке обычно не приходится реализовывать расчеты «с нуля» — обычно требуется лишь внести небольшие изменения или создать расчеты по аналогии с существующими, что повышает скорость решения задачи и снижает риск ошибок.

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

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

• Документация по Oracle Enterprise Performance Management System
• Руководство администратора Optimacros
• Руководство администратора Tурбо Бюджетирование
• Библиотека ITIL
• ITSM подход

Полезные материалы для развития софт скиллов из нашего телеграм канала Tech it Easy

• ТОП-5 книг для развития софт скиллов
• Как давать обратную связь
• Прокачиваем переговорные навыки
• Вебинары для прокачки навыков коммуникации
• Как общаться с коллегами, чтобы вас понимали