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