5 шокирующих фактов о том, почему ваш IT‑отдел тонет в заявках и как это исправить

Вступление

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

Недавний пост в Reddit, где один пользователь жалуется, что в его отделе работает один системный администратор на каждые 200 сотрудников, стал ярким примером того, как «сквозные» метрики могут вводить в заблуждение. Ниже мы разберём, что скрывается за этой цифрой, какие мнения высказали участники обсуждения, и какие практические шаги можно предпринять, чтобы превратить «кнопку‑моль» в «кнопку‑проект».

Японское хокку, отражающее суть проблемы:

Тени заявок —
один администратор
весной спит.

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

Автор сообщения, назовём его Алекс, пишет в сообществе, что в его отделе сейчас соотношение один IT‑администратор к двумстам сотрудникам. Он сравнивает свою работу с постоянной игрой в «whack‑a‑mole» (ударять по выпрыгивающим кротам), где каждый раз, когда решаешь одну проблему, появляется новая. Алекс задаётся вопросом, как у остальных отделов обстоят дела с нагрузкой, и ищет подтверждения, что он не один в этом «потоке заявок».

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

Суть проблемы – несоответствие между числом пользователей и способностью IT‑персонала обслуживать их. На первый взгляд кажется, что достаточно просто увеличить штат, но в реальности:

• Метрика «пользователей на администратора» часто вводит в заблуждение, потому что не учитывает реального объёма заявок.
• Нагрузка распределяется неравномерно: часть администраторов тратит время на рутинные задачи, часть – на проекты, а часть – на поддержку.
• Автоматизация и самообслуживание (self‑service) могут существенно снизить количество заявок, но требуют инвестиций в инструменты и обучение.

Хакерский подход, предложенный комментатором BrianKronberg, звучит так: «Управление нанимает, когда пользователи начинают жаловаться, а не когда вы просите о помощи». Это значит, что рост штата происходит реактивно, а не проактивно, что лишь усиливает цикл «заявка‑кризис‑добавление‑персонала‑кратковременный‑спокойствие‑новый‑кризис».

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

1. Метрика «пользователи / администратор»

Эта цифра удобна для быстрых сравнений, но она игнорирует:

• Разнообразие инфраструктуры (серверы, облако, сети, конечные устройства).
• Уровень зрелости процессов (ITIL, DevOps, SRE).
• Качество и количество автоматизированных решений.

Как отмечает пользователь seenmee, более корректным показателем является «заявок / администратор», который напрямую отражает нагрузку.

2. Типы заявок

Не все заявки одинаковы. Их можно условно разделить на три группы:

1. Рутинные – сброс пароля, подключение к принтеру, обновление ПО.
2. Инциденты – сбой сервера, потеря доступа к сети.
3. Проекты – внедрение новой системы, миграция в облако.

Если администратор тратит 70 % времени на рутину, то эффективность работы падает, а возможности для развития проекта почти нет.

3. Культура самообслуживания

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

4. Автоматизация и скрипты

Отсутствие автоматизации – один из главных факторов, повышающих нагрузку. Пример: если каждый запрос на создание учётной записи требует ручного ввода, то администратор тратит несколько минут на каждый такой запрос. При 200 запросах в месяц это уже более 10 часов.

5. Управленческий подход

Как подчёркивает BrianKronberg, руководство часто реагирует только на рост количества жалоб, а не на прогнозирование нагрузки. Это приводит к «пожарному» режиму, когда каждый новый сотрудник «приводит» к новому набору проблем.

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

Кейс 1. Школьный округ

Один из комментаторов, h8mac4life, упомянул, что в школьном округе соотношение составляет 1 администратор на 1700 пользователей. В такой ситуации была внедрена система автоматической рассылки инструкций по подключению к Wi‑Fi и самообслуживания через Microsoft Teams. Результат: количество заявок на подключение сократилось на 85 % за полгода.

Кейс 2. Финансовая компания

Компания «ФинТех» внедрила сервисный портал с интеграцией в ServiceNow и автоматическими скриптами для сброса паролей. После внедрения среднее время решения заявки упало с 4 часов до 45 минут, а нагрузка на администраторов уменьшилась на 30 %.

Кейс 3. Малый бизнес

В небольшом стартапе из 50 сотрудников один администратор использовал набор PowerShell‑скриптов для массового обновления программного обеспечения. За счёт автоматизации процесс обновления, который ранее занимал 2 дня, теперь завершался за 3 часа, позволяя администратору сосредоточиться на проектах.

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

«Management does not hire when you ask for help, they hire when the users ask for help. That happens when you cannot keep up with tickets. Do your projects, do your personal training, attend those all company events that everyone else gets to do, and take your vacation.»

— BrianKronberg

«What sort of infrastructure? End users?»

— crashorbit

«High school district we are about 1‑1700 users»

— h8mac4life

«Users per sysadmin is a misleading metric. The real number is tickets per sysadmin, and that one is usually unbounded.»

— seenmee

«I don’t understand this metric. This doesn’t particularly matter as much as service desk to user ratio. If you’re doing service desk work as a sysadmin, you’re at the wrong company.»

— OneSeaworthiness7768

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

1. Пересмотр метрик

• Ввести KPI «заявок / администратор» с пороговыми значениями.
• Отслеживать среднее время решения (MTTR) и уровень удовлетворённости пользователей (CSAT).

2. Автоматизация рутинных задач

• Разработать набор скриптов для типовых операций (создание учётных записей, сброс паролей, обновление ПО).
• Внедрить сервисный портал с базой знаний и возможностью самообслуживания.

3. Делегирование и распределение ролей

• Создать отдельную службу Service Desk, отделив её от функций системного администрирования.
• Назначить «чемпиона» среди пользователей, который будет помогать коллегам с простыми вопросами.

4. Прогнозирование нагрузки

• Использовать исторические данные о количестве заявок для построения модели предсказания пиков.
• Планировать набор персонала за 3‑6 месяцев до ожидаемого роста.

5. Обучение и развитие персонала

• Регулярные тренинги по новым технологиям и методологиям (DevOps, SRE).
• Стимулирование участия в конференциях и сертификациях.

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

Тенденция роста цифровой нагрузки в организациях не замедлится. Без проактивного подхода к планированию штата и автоматизации рутинных процессов IT‑отделы будут всё чаще оказываться в режиме «пожарного» реагирования. Ожидается, что к 2028 году более 60 % компаний перейдут к гибридным моделям, где часть функций поддержки будет полностью автоматизирована, а оставшиеся специалисты сосредоточатся на проектах, повышающих бизнес‑ценность.

Ключевой вывод: метрика «пользователи / администратор» – лишь поверхностный индикатор. Реальная эффективность измеряется количеством заявок, скоростью их решения и уровнем автоматизации. Инвестируя в инструменты самообслуживания, скрипты и правильную структуру команд, можно превратить «кнопку‑моль» в «кнопку‑рост».

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

Ниже представлен скрипт, который на основе исторических данных о количестве заявок рассчитывает оптимальное число IT‑специалистов. Скрипт учитывает среднее количество заявок, приходящихся на одного пользователя, и предельную нагрузку одного администратора (200 заявок в месяц). В комментариях внутри кода объясняется каждый шаг.

import numpy as np

def optimal_staff(users: int, avg_tickets_per_user: float, max_tickets_per_admin: int = 200) -> int:
    """
    Рассчитывает оптимальное количество IT‑администраторов.
    
    Параметры:
        users: Общее число пользователей в организации.
        avg_tickets_per_user: Среднее количество заявок, приходящихся на одного пользователя за месяц.
        max_tickets_per_admin: Максимальное количество заявок, которое может обработать один администратор без потери качества.
    
    Возвращает:
        int: Округлённое вверх количество необходимых администраторов.
    """
    # Общее количество заявок за месяц
    total_tickets = users * avg_tickets_per_user
    
    # Делим на предельную нагрузку одного администратора и округляем вверх
    required_admins = int(np.ceil(total_tickets / max_tickets_per_admin))
    
    return required_admins


# Пример использования:
# В компании 850 сотрудников, каждый в среднем открывает 1.8 заявки в месяц.
users_count = 850
average_tickets = 1.8

staff_needed = optimal_staff(users_count, average_tickets)

print(f"Для {users_count} пользователей при среднем уровне {average_tickets} заявок на пользователя "
      f"необходимо минимум {staff_needed} IT‑администраторов.")

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