Нечеткое техническое задание, передача системы на поддержку в сжатые сроки, выбор не самых эффективных каналов коммуникации — это лишь часть факторов, которые могут негативно влиять на сопровождение ИТ-систем. Рассмотрим, почему возникают сложности и как их избежать.
Выбор подхода
Любая компания заинтересована в том, чтобы критичные для бизнеса ИТ-системы работали стабильно, инциденты устранялись в соответствии с SLA, а пользователи оперативно получали ответы техподдержки. Однако обеспечить качественный сервис непросто. Часто условия соглашения формулируются без учета реальной инфраструктуры. Например, требуется реакция в течение 15 минут, при этом доступ к тестовому контуру выдается только после многоэтапных согласований.
Службу поддержки можно сравнить с небольшим бизнесом внутри компании, который требует затрат, но сам не зарабатывает, поэтому поддержку корпоративных систем обычно поручают внешнему ИТ-партнеру.
Несмотря на общие цели, может оказаться, что стороны видят процесс сопровождения по-разному. Не редкость ситуация, когда заявляется один подход, а при выборе поставщика применяются совсем другие критерии. Например, у компании есть запрос на сервис SLA, но в реальности она хочет, чтобы за сопровождение системы отвечал один постоянный сотрудник. Хотя в таких условиях обеспечить ожидаемый уровень техподдержки невозможно.
Иногда подобные стремления связаны с ограниченным бюджетом на ИТ. У корпоративной ИТ-службы могут быть опасения, что привлечение для сопровождения системы большего числа специалистов не позволит уложиться в лимиты.
Еще одно объяснение — влияние предыдущего опыта по организации поддержки. Допустим, раньше в компании за нее отвечал один штатный специалист, потом с ним работали как с внешним сотрудником, поэтому предполагают, что сервис может быть организован только так, а не иначе.
Кроме того, такой подход могут выбирать компании, которые сталкивались с частой сменой исполнителей. Например, при работе с франчайзи, когда специалисты поддержки не резервируются и могут привлекаться на проекты внедрения, где нужна стабильная команда. Новым сотрудникам приходится каждый раз тратить время, чтобы разобраться в системе, а ИТ-команда заказчика становится посредником между меняющимися специалистами поддержки и бизнес-пользователями.
В результате под влиянием негативного опыта в прошлом компания в следующий раз может выбрать не самый эффективный подход к организации сопровождения.
Подготовка технического задания
Бизнес не должен досконально вникать во все технические нюансы, но, чтобы сориентировать ИТ-партнера, важно обозначить в ТЗ свое видение процесса сопровождения и ключевые параметры сервиса.
Оптимальный вариант — когда в документе прописаны четкие критерии, по которым будут сравниваться предложения. Например, в виде таблицы, где каждый подрядчик отмечает, полностью ли он соответствует этому пункту, частично или не соответствуют. В этом случае не придется тратить время на уточнение деталей и приведение сведений к единому виду, как при подаче информации «в свободной форме». Процесс выбора становится быстрее и прозрачнее, основывается на конкретных данных.
Подготовить хорошее ТЗ — почти искусство. Далеко не все ИТ-специалисты разбираются в особенностях конкурсных процедур, а сотрудники, которые проводят тендеры, — в ИТ.
Например, у компании, которая раньше использовала зарубежную систему, может не быть компетенций по похожей российской. С переходом на новую платформу ей сложно оценить, какой объем поддержки потребуется, поэтому приходится обращаться за помощью в составлении ТЗ к подрядчику, который внедрял отечественную систему, либо собирать доступные предложения с рынка и выбирать из них. В результате бизнес подстраивается под других, а не формирует ТЗ на основе своих потребностей.
С нехваткой релевантного опыта связана еще одна причина появления некачественного ТЗ — подготовка документа на основе регламента работы предыдущего подрядчика. Возможно, на практике этот документ никогда не соблюдался, но он становится требованием, по которому нужно организовывать сервис.
Отсутствие системного подхода к управлению ИТ-услугами тоже сказывается на качестве ТЗ. Обычно внедряются только базовые процессы. Например, управление инцидентами без управления изменениями, хотя это разные процессы с разными маршрутами, участниками и жизненным циклом. Несмотря на то, что на рынке есть разработанные ITSM-стандарты, эти моменты редко отражаются в ТЗ, поэтому подрядчики вынуждены перестраиваться и работать по упрощенной схеме. На мой взгляд, самое качественное ТЗ с точки зрения организации сервиса появляется, когда в его подготовке участвуют ITSM-менеджеры, менеджеры по качеству или методологи.
Нечеткое ТЗ мешает ИТ-партнеру оценить объем услуг, спланировать работу и в дальнейшем может негативно сказаться на качестве сервиса, но крупные подрядчики, которые ориентируются на продолжительное сотрудничество, стараются брать такие риски на себя.
Передача решения на поддержку
Передача знаний от команды внедрения к команде поддержки — один из самых уязвимых этапов. Часто этот процесс происходит в последние дни перед запуском системы. Из-за сжатых сроков проектная документация, как правило, оказывается неактуальна, база знаний не заполнена, а изменения последних недель не описаны.
Без четкого процесса приемки-передачи (handover checklist) команда поддержки по сути получает «черный ящик». В первые недели после запуска это может обернуться каскадом инцидентов и перерасходом часов на диагностику ошибок, которые ранее уже устранялись.
Чтобы организовать качественную поддержку и соблюсти SLA, требуется усиление команды и привлечение высококвалифицированных специалистов, которые параллельно изучают систему и тут же оказывают помощь пользователям в решении их бизнес-задач. Иногда приходится подключать разработчиков, чтобы проанализировать алгоритмы и на уровне кода разобрать недокументированные возможности системы. Через несколько месяцев количество сотрудников, необходимое для ежедневной поддержки системы, станет меньше. Они будут хорошо знакомы с системой и смогут консультировать более оперативно.
Чтобы передача знаний проходила более спокойно, специалистов поддержки лучше всего подключать к проекту на этапе опытной эксплуатации. В это время у пользователей возникает наибольшее количество вопросов, а команде внедрения не хватает ресурсов, чтобы отвечать на обращения и устранять выявленные недочеты. Специалисты поддержки, с одной стороны, помогут разгрузить внедренцев, с другой — приобретут опыт работы с системой, на простых вопросах разберутся в ее функциональности, устранят неточности в документации и выстроят процессы. Хотя такой вариант финансово затратен для бизнеса, т. к. приходится одновременно оплачивать работу двух команд, он позволяет плавно перейти между этапами.
Поддержка систем с долгой историей
Чем дольше существует система, тем больше в ней кастомизаций и изменений, внесенных в архитектуру. Если в компании нет выстроенных процессов управления изменениями и релизами, эти доработки носят ситуационный характер: возникла проблема, нашли быстрое решение, реализовали, причем без тестирования его влияния на систему в целом.
При частой смене подрядчиков изменения вносятся разными сотрудниками, которые поверхностно знакомы с системой и не несут ответственности за ее работоспособность в долгосрочной перспективе. Они могут выбрать простой, а не оптимальный вариант решения, например, создать «костыль» вместо устранения причины проблемы.
Со временем разобраться в системе становится все труднее. Она продолжает работать, но, скорее всего, медленно и не совсем корректно, а новому подрядчику уже сложно внести качественные изменения.
Еще одна непростая ситуация — сопровождение системы, которая давно не обновлялась. Компания может откладывать обновления по разным причинам. В числе основных — финансовый вопрос и сложности с подбором технологических окон. Если бизнес непрерывный, такие окна очень небольшие и согласовываются с трудом. Спустя время можно оказаться в ситуации, когда вместо дообновления потребуется перевнедрение, а это совсем другие сроки и бюджеты.
Устаревшая система — это риски для бизнеса. Без своевременных обновлений возникают сложности с исполнением требований законодательства, особенно в области бухучета и кадрового делопроизводства, где изменения происходят наиболее часто. С технической стороны система тоже становится более уязвимой.
С надежным подрядчиком такой ситуации не возникнет. Он отвечает, в том числе финансово, за стабильную работу системы, поэтому заинтересован в поддержании ее в актуальном состоянии.
Коммуникация между пользователями и технической командой
Привычный вариант взаимодействия с техподдержкой не всегда оптимальный. Например, общение по телефону. Пользователи звонят в любое время, остаются на связи с консультантом, пока проблема не будет полностью решена, и обращаются даже по тем вопросам, с которыми могли бы разобраться самостоятельно. Главный минус такой ситуации — увеличение стоимости поддержки.
При внедрении системы часто создаются различные чаты для связи между проектной командой и сотрудниками компании. Привыкнув к ним, пользователи хотят общаться с техподдержкой в этих же каналах. Как показывает практика, это один из самых неэффективных способов коммуникации: обилие сообщений отвлекает участников чата, вопросы теряются и остаются без ответов, одни и те ситуации обсуждаются повторно.
Наилучший вариант — если у сотрудника есть возможность подать заявку в техподдержку непосредственно из системы, в которой он работает. В этом случае специалисты сразу получают максимум информации о пользователе и его проблеме и могут оперативно и качественно помочь ему, не тратя время на выяснение деталей.
Второй эффективный способ обращения — корпоративный портал или портал самообслуживания, где пользователь может оставить заявку: выбрать услугу, указать важность вопроса, обозначить сроки и ожидаемые решения. В результате заявка будет маршрутизирована наиболее точно.
Третий вариант — почта. Система Service Desk настраивается таким образом, что все поступающие обращения автоматически регистрируются, получают номера, а пользователю уходит оповещение, что его заявка принята в работу, с указанием планового срока исполнения.
Во всех трех случаях информация в рамках задачи сохраняется. Даже если консультант поменяется, пользователю не придется заново объяснять свою проблему. При этом загрузка и сроки выполнения заявки регулируются на стороне исполнителя в отличие от коммуникации по телефону, поэтому для организации сервиса потребуется меньше специалистов, а его стоимость будет ниже.
Для уточнения информации или моделирования ситуации, с которой столкнулся пользователь, у специалистов техподдержки должна быть возможность связаться с ним. В зависимости от корпоративных стандартов это может быть переписка в почте или видеоконференция с доступом к рабочему столу сотрудника. Во втором случае специалист может увидеть проблему «глазами пользователя», под его учетной записью и с его правами доступа, что позволяет сразу понять суть вопроса и исключить лишние трудозатраты.
Как улучшить взаимодействие с техподдержкой
- Обучение. Когда новые сотрудники начинают работу в системе без предварительного ознакомления с ней, велика вероятность, что все возникающие вопросы они будут адресовать техподдержке, а ее специалисты будут тратить дорогостоящее время на то, чтобы помочь пользователям разобраться в базовых функциях вместо решения сложных задач. Гораздо эффективнее, если сотрудник при приеме на работу или переводе на новую должность сначала проходит обучение и лишь после этого получает доступ к системе.
- База знаний. С ее помощью пользователи могут самостоятельно, без обращения в техподдержку находить ответы на типовые вопросы. Внедрение машинного обучения позволит еще больше упростить поиск нужной информации: система будет сама предлагать ответы на наиболее частые вопросы и подбирать инструкцию из базы знаний.
- Минимизация участия. Чем точнее поставлена задача, тем быстрее техподдержка даст на нее ответ, но не все пользователи умеют формализовать обращения, поэтому лучше максимально автоматизировать этот процесс. Например, за счет возможности отправлять заявку прямо из интерфейса системы, чтобы весь контекст по обращению автоматически собирался и направлялся в техподдержку.
- Проактивный подход. Важно заранее информировать пользователей о планируемых изменениях и выпуске релизов. Описание их сути и последствий, а также готовые инструкции помогут избежать ситуаций, когда сотрудник сталкивается с неожиданностями и вынужден обращаться к специалистам.
Кроме того, необходимо проанализировать категории обращений, среднее время диагностики, количество повторных заявок и распределение по ролям пользователей, чтобы перейти от реакции на инциденты к проактивному управлению и сократить нагрузку на поддержку.
