ИТ-сервис глазами пользователя
У ИТ есть удобный способ доказать, что все работает — это показать цифры. Из них следует, что серверы доступны, SLA выполнен, а заявки закрыты в срок. Только сотрудники почему-то все равно ждут, переносят данные руками, заводят свои таблицы, ругают систему и в итоге звонят в поддержку.
Причина может оказаться где угодно, например, в KPI, которые научились выполнять слишком буквально, в конфликтующих требованиях разных подразделений, в потерях на стыке систем или в том, что никто не проверяет сервис глазами пользователя.
эксперта
Практики разбирают реальные ситуации, делятся опытом и решениями.
Взгляд 01. Сценарий. Когда мониторинг говорит, что все работает
Бывают проекты, в которых корпоративная система формально доступна, но пользователи жалуются на медленную или нестабильную работу. Как обнаружить причину и какие изменения в инфраструктуре помогут улучшить сервис?
«У одного нашего заказчика — в крупной энергосетевой компании — дежурные смены следят за событиями на подстанциях и в кабельной сети через отдельную технологическую систему. Инфраструктурный мониторинг показывал, что система работает штатно: серверы доступны, критической нагрузки нет. Но сотрудники регулярно сталкивались с другой картиной — интерфейс загружался несколько минут, а иногда не открывался вовсе. На уровне контроля инфраструктуры эпизоды не оставляли следа.
Причина в том, что инфраструктурный мониторинг видит только состояние технических компонентов: доступность серверов, загрузку процессора и памяти, работу сети. На вопрос, может ли сотрудник в данный момент выполнить конкретную операцию в системе, эти показатели не отвечают. ИТ-служба узнавала о сбое чаще всего только от самих сотрудников: смена замечала проблему и сообщала о ней. Пока жалобы не было, проблема считалась несуществующей. Задачу осложняло то, что система оказалась закрытой: получать данные через API, логи или напрямую из базы было нельзя, единственный доступный способ — графический интерфейс.
Решить проблему помог синтетический мониторинг: программные роботы проверяют систему с точки зрения пользователя — регулярно по расписанию заходят в систему так же, как обычный оператор, проходят сценарий и выгружают отчет о результате и времени выполнения.
Теперь ИТ-служба видит не только состояние инфраструктуры, но и доступность ключевого пользовательского сценария. Программные роботы сообщают о сбое сразу, как только сценарий перестает выполняться, не дожидаясь, пока это заметит и сообщит человек. Они фиксируют любой эпизод в момент возникновения: когда он начался, сколько продолжался и на каком шаге сценарий остановился. За этим стоит ощутимый для бизнеса эффект: дежурная смена получает доступ к оперативной картине по подстанциям и кабельной сети сразу, а не спустя часы разбирательств с ИТ-службой. Чем меньше времени смена работает вслепую, тем быстрее в сети замечают и локализуют технологические события, а для энергосетевой компании это напрямую про надежность электроснабжения.
Изменилась и сама диагностика. Вместо жалобы «система не работала» у специалистов появляется подробная информация: в такое-то время не открылся нужный экран или операция заняла заметно больше обычного. Раньше поиск причины занимал несколько часов: сотрудники должны были заметить сбой и сообщить о нем, а ИТ-специалисты — разобраться, что произошло. Теперь понять, из-за чего возникли жалобы, можно за несколько минут.
Наша практика показывает: если система формально доступна, а пользователи недовольны, дело часто не в серверах, а в том, что никто не проверяет сервис глазами сотрудника. Стандартный инфраструктурный мониторинг отвечает на вопрос «работает ли сервер?», но не на вопрос «может ли человек сделать свою работу?». Для критичных сценариев вторая проверка не менее важна, чем первая. Особенно там, где сбой на несколько минут стоит компании дорого».
Взгляд 02. Пользователи. Удобства для всех не существует
Что делать ИТ-директору, если одной группе пользователей система удобна, а другой мешает работать? Чьи требования должны определять развитие корпоративного решения?
«Коби Брайант говорил: «Я понял, что ключ к тому, чтобы помочь игрокам расти — адаптировать подход к каждому из них, понимая их истории и цели». Это именно то, с чем сталкивается любой ИТ-директор, когда слышит на разборе проекта: «система работает, а люди недовольны».
У меня был показательный случай с миграцией на 1С: ERP, когда на каждом этапе проекта система отрабатывала исправно, данные вводились и считались корректно, но при этом некоторые отделы откровенно бунтовали, а кто-то просто молча работал дальше. Дело было не в ошибках или проблемах системы, а в том, что людям пришлось перестраивать привычные процессы, а привычка сопротивляется упрямее любой формы в интерфейсе.
С тех пор исхожу из того, что «среднего пользователя» не существует: у них, как и у игроков, разные истории. В крупной компании всегда присутствует набор конфликтующих интересов: финансам нужна точность и полная прослеживаемость операций, производству минимум полей, а руководству сводка без деталей. Удобство вообще не равно эффективности и система, в которой легко работать, часто теряет управляемость, а обязательные поля, которые всех раздражают, на деле держат качество данных.
А вот кто определяет, чьи требования весомее, это вопрос не к ИТ, а к бизнесу: чья скорость или чья точность сейчас критичнее для результата. Моя роль заключается в том, чтобы честно показать цену каждого варианта, а не тихо решать за всех и уж тем более не плодить систему под каждую жалобу: так ландшафт превращается в лабиринт, который через пару лет не объяснит никто, включая тех, кто его строил.
Фил Джексон приводил к чемпионству и «Буллз» с Джорданом, и «Лейкерс» с Брайантом, двух игроков с разными стилями и требованиями к игре, и говорил: «Сила команды в каждом отдельном участнике. Сила каждого участника в команде». Система работает не тогда, когда всем одинаково удобно, а когда конфликт интересов разрешен осознанно, а не молчанием или в пользу того, кто громче жалуется».
Взгляд 03. Показатели. Зеленые KPI не означают хороший сервис
Что делать ИТ-директору, если по отчетам все показатели в норме, подрядчики выполняют SLA, а бизнес продолжает жаловаться на качество ИТ? Кому верить и что в такой ситуации менять?
«Возможно, KPI поддержки устарел. Сотрудники нашли способы, как подстроиться под высокий KPI с наименьшими усилиями. В моей практике была ситуация, когда инженеры ради красивой статистики и личных высоких показателей стабильно закрывали заявки невыполненными. Чтобы решить эту проблему, мы добавили в KPI метрику решения с первого раза (FCR: first contact resolution) и увеличили вес оценки от самого пользователя.
Несколько сложнее, но важнее поменять SLA на XLA (Experience Level Agreement), переходить от технических метрик к оценке клиентского опыта. Измерять интересующие бизнес-показатели: время оформления заказа, время проведения платежа. Бизнесу не слишком интересен «аптайм сервера» или «среднее время восстановления», которые по умолчанию должны быть на высоком уровне.
Однако, на мой взгляд, самое важное для ИТ-лидера — быть ближе к бизнесу, к процессам. Обязательно нужно постоянно бывать «в полях». Необходимо видеть, как пользователи работают с софтом, что им мешает, какой информации в каких моментах не хватает. Чаще всего сотрудники даже не знают, какая информация есть в системе. Получив когда-то отказ от ИТ или постеснявшись спросить, боятся задать вопрос. В этом случае пользователи начинают изобретать обходные пути и приспосабливать программу под несвойственные ей задачи, хранить устаревающую информацию в Excel вместо того, чтобы получить или ввести ее быстро в нужном интерфейсе системы онлайн. Необходимо не только знать, как теоретически работает внедренная информационная система, но и какие боли остались и какие новые появляются у сотрудников, работающих в ней.
Но «негативный фон» по отношению к ИТ может возникать в компании и в том случае, если в самом ИТ-коллективе что-то не в порядке. Особенно это касается техподдержки, то есть тех, кто постоянно контактирует с сотрудниками других подразделений. В моей практике был случай, когда все отчеты и графики техподдержки светились зеленым, инциденты закрывались в срок, показатели SLA всегда выполнены, но при этом недовольство ИТ в компании было очень сильным, причем на всех уровнях, от руководителей до рядовых сотрудников. Оказалось, что внутри службы поддержки нездоровая атмосфера. В результате неграмотного руководства атмосфера в коллективе была очень напряженной, что сказывалось на отношении к работе, а главное на взаимодействии с клиентами техподдержки — всеми сотрудниками компании. Ситуация разрешилась сменой 80% сервис-деска, включая руководителя. Были очень сложные первые пара месяцев, но потом ИТ стали одной из самых востребованных и уважаемых служб компании».
Взгляд 04. Стыки. Система быстрая, процесс медленный
Как понять, что пользователи недовольны не самой ИТ-системой, а тем, как устроен сквозной бизнес-процесс, и где именно искать потери на стыках между системами и подразделениями?
«Самая частая жалоба, «ИТ опять тормозит», почти никогда не про ИТ. Серверы исправны, SLA выполнен, каждая система по отдельности отвечает быстро. А сотрудник все равно ждет, переспрашивает и злится. Так происходит, когда измеряли системы, но никто не измерял путь между ними.
ERP работает, CRM работает, документооборот работает. Но заявка живет не внутри одной системы, а идет через все три и через несколько отделов. На каждом переходе человек переносит данные руками, ждет согласования, уточняет что-то в мессенджере. Здесь и копятся часы, которых не видит ни один SLA: он меряет отклик системы, а не время на стыке между системами.
Отличить медленное ПО от медленного стыка я советую так. Возьмите одну жалобу и пройдите один реальный случай с секундомером, от задачи сотрудника до результата. Засеките отдельно время работы внутри систем и время ожидания между ними. Почти всегда внутри уходят минуты, между ними часы и дни. Это и есть ответ.
Дальше ищите приметы стыка, а не тормозящей системы. Одни и те же данные вводят дважды. Работа стоит в ожидании человека, а не сервера. Процесс склеивают мессенджером и таблицами в обход систем. Жалобы липнут к переходам: «не могу передать в…», «жду выгрузку из…». А теневые таблицы и чаты складываются в готовую карту ваших стыков.
Тип стыка подсказывает и лечение. Нет нужной цифры на месте решения, дайте видимость данных. Формат перебивают руками, нужна интеграция или единый формат. Передача идет без срока, задайте норматив и приоритет. За результат на стыке не отвечает никто, назначьте хозяина перехода.
Проверить легко. Ускорьте сервер, обновите интерфейс. Если «ИТ тормозит» осталось, дело было не в ИТ. Система быстрая, медленный стык. Стыки дороже систем, и недовольство пользователей чаще всего живет именно там».
Что проверить, если все работает
У недовольства пользователей слишком много возможных причин, чтобы искать одну универсальную. Но из ответов экспертов складывается вполне практичный порядок действий. Прежде чем заказывать очередную доработку или искать виноватого, стоит проверить несколько вещей.
- Посмотреть, как люди работают на самом деле — где ждут, что переносят вручную, какие Excel, чаты и обходные пути используют.
- Взять одну типичную жалобу и пройти весь путь от задачи до результата. Отдельно посмотреть, сколько времени уходит внутри систем и сколько — на переходах между ними, где данные вводятся повторно, ждут согласования или вообще нет ответственного.
- Если отчеты зеленые, а бизнес жалуется, проверить, что именно измеряют KPI. Возможно, они показывают скорость закрытия заявки или доступность сервера, но ничего не говорят о том, решил ли пользователь свою задачу.
- Не считать всех пользователей одинаковыми. Требования финансов, производства и руководства могут противоречить друг другу, и выбирать между ними должен бизнес, понимая цену каждого варианта.
- Не превращать каждую жалобу в доработку. Иногда причина в процессе, недостатке информации или в том, что сотрудники просто не знают возможностей уже существующей системы.
- Проверить работу самой поддержки. Красивые показатели мало значат, если заявки закрываются формально, а общение сервис-деска с пользователями только усиливает раздражение.
- Для критичных операций контролировать не только инфраструктуру, но и сам пользовательский сценарий — действительно ли человек может войти в систему и выполнить нужное действие.
Опубликовано 28.08.2026
