10 шокирующих фактов о том, почему ServiceNow раздражает пользователей — и как их решить

Вступление

Платформа ServiceNow уже несколько лет считается «золотым стандартом» для управления ИТ‑услугами. На первый взгляд она обещает автоматизацию, прозрачность процессов и удобный веб‑интерфейс. На практике же многие специалисты сталкиваются с тем, что система превращает простую задачу в целый квест, отнимает время и силы, а иногда даже заставляет задуматься, зачем она нужна.

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

И в завершение вступления – небольшое японское хокку, которое, как ни странно, отлично описывает ощущение бесконечного кликанья в ServiceNow:

静かな雨
空っぽの画面に
クリック無限

Перевод: «Тихий дождь падает, пустой экран, кликов бесконечность».

Пересказ Reddit‑поста своими словами

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

• После внесения правки в инцидент и нажатия «Сохранить» система автоматически переключает пользователя на другой, случайный инцидент, будто работа завершена.
• Для одной заявки приходится получать три разных номера: REQ, RITM и SCTASK. То есть один запрос превращается в тройную бумажную работу.
• Добавление нескольких конфигурационных элементов разных категорий к одному тикету требует множества кликов и «потёртых» действий.
• Поиск по строке работает, но результаты отображаются так, что их почти невозможно найти.
• Запрос на изменение (CHG), имеющий дочерние задачи (SCTASK), не наследует от него конфигурационные элементы – их нужно вводить вручную.
• Отсутствует массовое назначение тикетов на конкретного сотрудника или команду, а также массовое изменение статуса. При попытке «прокликать» 30 тикетов по отдельности пользователь теряет терпение.
• Система работает медленно, сама обновляется без команды пользователя, что только усиливает раздражение.

Автор также отмечает, что сотрудники вынуждены пользоваться этой «запертой» системой, хотя в клиентском продукте такой интерфейс был бы неприемлем. У него нет прав администратора, доступа к API и возможности использовать скрипты, поэтому он почти безоружен в борьбе с неудобствами.

Суть проблемы, хакерский подход и основные тенденции

Суть проблемы сводится к трём фундаментальным аспектам:

1. Избыточность и запутанность интерфейса. Пользователь вынужден выполнять множество однообразных действий, которые могли бы быть автоматизированы.
2. Недостаток гибкой настройки. По умолчанию система не учитывает специфики бизнес‑процессов, а кастомизация часто слишком дорогая и сложная.
3. Отсутствие пользовательского опыта (UX). Разработчики интерфейса, как правило, не являются специалистами по удобству использования, поэтому привычные паттерны «пользователь‑центричный дизайн» игнорируются.

Хакерский подход, который уже упоминали пользователи, состоит в поиске «скрытых» функций (правый клик по серой полосе, использование фильтров вместо поисковой строки) и в написании небольших скриптов, которые автоматизируют рутинные операции.

Детальный разбор проблемы с разных сторон

Техническая сторона

ServiceNow построена на платформе, где почти всё – от форм до бизнес‑правил – реализуется через скрипты JavaScript и конфигурационные таблицы. Это даёт огромную гибкость, но одновременно создаёт барьер входа: без доступа к администрированию невозможно изменить поведение базовых элементов, таких как автоматический переход после сохранения.

Кроме того, система использует модель «запрос‑за‑запросом», где каждый тип записи (REQ, RITM, SCTASK) имеет собственный жизненный цикл. Это удобно для крупных организаций, где каждый запрос действительно проходит несколько стадий, но в небольших командах выглядит как избыточность.

Организационная сторона

Во многих компаниях внедрение ServiceNow происходит без привлечения специалистов по процессам и пользовательскому опыту. Как отмечает один из комментаторов, «большинство внедрений делается группой ИТ‑специалистов, а не людьми, которые понимают, как люди работают». В результате получаются «тяжёлые» решения, которые требуют постоянного вмешательства администраторов.

Психологическая сторона

Когда сотрудник вынужден тратить время на «клик‑марафон», его мотивация падает, а уровень стресса растёт. Это приводит к тому, что пользователи ищут обходные пути, используют сторонние инструменты (если позволяют политики) или вовсе игнорируют систему, что вредит целостности данных.

Практические примеры и кейсы

Рассмотрим два типичных сценария, которые часто встречаются в реальной работе.

Сценарий 1. Массовое назначение тикетов

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

Сценарий 2. Дублирование номеров заявок

Клиент просит установить новое программное обеспечение. Сотрудник создаёт REQ, затем получает RITM и SCTASK. При этом в системе уже существует открытый инцидент, связанный с тем же клиентом, но без ссылки на новые номера. В итоге в базе появляется три разных записи, которые трудно сопоставить.

Экспертные мнения из комментариев

Service Now похож на Sales Force – работает «из коробки», но без глубокой кастомизации почти бесполезен, а кастомизация стоит дорого и может привести к ошибкам.

Эта мысль подчёркивает, что базовый набор функций слишком ограничен, а доработки требуют значительных инвестиций.

Простота лучше – поэтому я перешёл на Zendesk. Да, там нет некоторых функций, но в конце концов всё сводится к открытию тикета, работе над ним, отправке писем клиенту и закрытию.

Здесь подчёркнута идея «минимального жизнеспособного продукта»: иногда лучше иметь простую, надёжную систему, чем сложную, но неудобную.

Правый клик по серой полосе вверху тикета сохраняет изменения без перехода к предыдущему тикету.

Это практический совет, который спасает от автоматического переключения, описанного в оригинальном посте.

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

Фильтры позволяют сузить результаты и находить нужные записи быстрее.

Большинство внедрений делаются ИТ‑специалистами, а не людьми, которые понимают процессы, UX или полные возможности системы. Такие проекты часто «умирают», оставляя кучу нерешённой работы.

Эта критика указывает на необходимость междисциплинарных команд при внедрении.

Возможные решения и рекомендации

1. Оптимизировать конфигурацию интерфейса. Отключить автоматический переход после сохранения, добавить кнопку «Сохранить и остаться». Это обычно делается через настройку бизнес‑правил (Business Rules) и клиентских скриптов.
2. Сократить количество типов записей. При возможности объединить REQ, RITM и SCTASK в один тип заявки, используя «запрос‑по‑шаблону», что уменьшит количество номеров и упростит отслеживание.
3. Внедрить массовые операции. Создать пользовательскую кнопку «Назначить всем», которая через API обновит поле «Ответственный» у выбранных записей.
4. Улучшить поиск. Настроить глобальные фильтры и сохранить их как «избранные», а также обучить пользователей работе с ними.
5. Автоматизировать наследование конфигурационных элементов. Добавить скрипт, который при создании дочерних задач копирует CI из родительского CHG.
6. Обучить персонал. Провести воркшопы по эффективному использованию ServiceNow, показать «хакерские» приёмы (правый клик, фильтры).
7. Регулярно проводить аудит UX. Приглашать специалистов по пользовательскому опыту для оценки интерфейса и предложения улучшений.

Заключение с прогнозом развития

ServiceNow остаётся лидером рынка благодаря своей масштабируемости и богатому набору функций. Однако без правильной кастомизации и внимания к пользовательскому опыту система будет продолжать вызывать раздражение у большинства сотрудников. В ближайшие годы мы можем ожидать два направления развития:

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

Если компании инвестируют в правильную настройку, обучение и UX‑аудит, они смогут превратить ServiceNow из «тормоза» в настоящий центр эффективности.

Практический пример на Python

Ниже представлен скрипт, который демонстрирует, как с помощью API ServiceNow можно получить список открытых инцидентов и массово переназначить их на выбранного специалиста. Скрипт написан без использования сторонних библиотек, кроме requests, и полностью комментирован.

# -*- coding: utf-8 -*-
"""
Скрипт для массового переназначения открытых инцидентов в ServiceNow.
Требуется:
    - URL экземпляра ServiceNow (например, https://myinstance.service-now.com)
    - Учётные данные пользователя с правами чтения/записи
    - Имя нового ответственного (sys_id)
"""

import requests
import json

# --------------------------- Конфигурация ---------------------------
INSTANCE_URL = "https://myinstance.service-now.com"
USERNAME = "user@example.com"
PASSWORD = "secure_password"
NEW_ASSIGNEE_SYS_ID = "1234567890abcdef1234567890abcdef"  # sys_id нового ответственного

# --------------------------- Функции ---------------------------
def get_open_incidents():
    """
    Получает список всех открытых инцидентов (state = 1 – Новый, 2 – В работе).
    Возвращает список словарей с полями sys_id и number.
    """
    endpoint = f"{INSTANCE_URL}/api/now/table/incident"
    # Параметры запроса: только нужные поля, статус открытых, ограничение 200 записей
    params = {
        "sysparm_fields": "sys_id,number",
        "sysparm_query": "stateIN1,2",   # 1 – Новый, 2 – В работе
        "sysparm_limit": "200"
    }
    response = requests.get(
        endpoint,
        auth=(USERNAME, PASSWORD),
        params=params,
        headers={"Accept": "application/json"}
    )
    response.raise_for_status()
    data = response.json()
    return data.get("result", [])

def assign_incident(incident_sys_id):
    """
    Обновляет поле assigned_to у конкретного инцидента.
    """
    endpoint = f"{INSTANCE_URL}/api/now/table/incident/{incident_sys_id}"
    payload = {
        "assigned_to": NEW_ASSIGNEE_SYS_ID
    }
    response = requests.patch(
        endpoint,
        auth=(USERNAME, PASSWORD),
        headers={"Content-Type": "application/json"},
        data=json.dumps(payload)
    )
    response.raise_for_status()
    return response.json()

def batch_assign():
    """
    Основная логика: получаем открытые инциденты и последовательно
    переназначаем их. Выводим прогресс в консоль.
    """
    incidents = get_open_incidents()
    total = len(incidents)
    print(f"Найдено открытых инцидентов: {total}")

    for idx, inc in enumerate(incidents, start=1):
        try:
            assign_incident(inc["sys_id"])
            print(f"[{idx}/{total}] Инцидент {inc['number']} переназначен.")
        except Exception as e:
            print(f"[{idx}/{total}] Ошибка при переназначении {inc['number']}: {e}")

# --------------------------- Запуск ---------------------------
if __name__ == "__main__":
    batch_assign()

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