К статье
Практический материал

Автоматизация · 10 мин

1С ITIL: как работать с системой управления ИТ-процессами

Практическое руководство по работе с 1С:ITIL — регистрация обращений, управление инцидентами, база знаний, SLA и отчёты. Пошаговые инструкции для специалистов.

1С:ITIL (Управление информационными технологиями) — отраслевое решение на платформе 1С:Предприятие, которое автоматизирует процессы ITIL: работу с инцидентами, проблемами, изменениями, конфигурациями и уровнем услуг. Система построена на базе 1С:Документооборот и 1С:Управление нашей фирмой, поэтому интерфейс знаком большинству пользователей 1С, но логика работы отличается: здесь в центре внимания не проводки и документы, а жизненный цикл обращения.

Работа в системе начинается с понимания своей роли: пользователь услуги регистрирует обращения, специалист первой линии классифицирует и решает типовые вопросы, специалист второй линии разбирает сложные инциденты, а владелец процесса следит за SLA и качеством. Каждая роль видит свои разделы и кнопки, поэтому первый шаг при внедрении — правильно настроить права доступа и группы исполнителей.

Ниже разобраны основные рабочие сценарии: от регистрации обращения до контроля SLA и построения отчётности. Материал ориентирован на практическую работу в типовой конфигурации; названия конкретных пунктов меню могут отличаться в зависимости от версии и доработок вашего внедрения.

Роли и интерфейс: с чего начать работу

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

Начальная страница настраивается индивидуально: вынесите на неё списки «Мои обращения», «Обращения группы» и «Просроченные по SLA». Это три рабочих списка, которые специалист открывает чаще всего. Если в списке много записей, используйте отборы по статусу, приоритету и группе исполнителей — стандартный механизм настройки списков платформы здесь работает в полном объёме.

Регистрация и классификация обращений

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

Приоритет определяется матрицей «влияние + срочность»: массовый сбой критичной услуги получает высший приоритет, разовый вопрос по интерфейсу — низкий. Не завышайте приоритет «на всякий случай»: это ломает статистику SLA и мешает реагировать на действительно критичные инциденты.

После сохранения обращения система по настроенным правилам назначает группу исполнителей или конкретного специалиста. Если автоназначение не сработало, проверьте, заполнена ли услуга и настроены ли правила маршрутизации для неё — это самая частая причина «зависших» в общей очереди заявок.

Регистрация обращения за пять шагов
  1. 1
    Создайте обращение из раздела «Обращения» или примите из почты
  2. 2
    Укажите инициатора, услугу и тему, детально опишите ситуацию
  3. 3
    Выберите влияние и срочность — система рассчитает приоритет
  4. 4
    Привяжите конфигурационную единицу, если сбой связан с конкретным оборудованием или ПО
  5. 5
    Сохраните и проверьте, что назначена группа исполнителей и стартовал отсчёт SLA

Ведение обращения: статусы, решения, эскалация

Специалист берёт обращение в работу сменой статуса — это фиксирует время начала реакции для SLA. Все действия, переписка и промежуточные результаты заносятся в комментарии и историю обращения, а не ведутся в почте или мессенджерах: при передаче заявки коллеге вся история должна читаться из карточки.

Если для решения нужны действия пользователя или стороннего подрядчика, переведите обращение в статус ожидания — в типовой настройке таймер SLA при этом приостанавливается. Укажите в комментарии, чего именно вы ждёте и от кого, иначе заявка зависнет без движения.

При решении заполните поле решения содержательно: причина, выполненные действия, результат. Формулировки вида «исправлено» бесполезны для базы знаний и анализа повторяющихся инцидентов. После решения обращение возвращается инициатору на подтверждение или закрывается автоматически по таймауту — поведение задаётся настройками процесса.

База знаний и типовые решения

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

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

Самая частая причина неработающей базы знаний — статьи, написанные языком исполнителя, а не пользователя. Формулируйте заголовок так, как пользователь описывает проблему («не печатает принтер», «не открывается 1С»), а технические детали оставляйте в теле статьи.
ПЗ
Практическое замечание

Управление инцидентами, проблемами и изменениями

Инцидент — это обращение о нарушении работы услуги. Если одна и та же причина порождает несколько инцидентов, их связывают и регистрируют проблему — задачу на поиск и устранение первопричины. Связывание выполняется из карточки обращения через механизм связанных объектов.

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

Маршрут решения

Как выбрать процесс

Единичный сбой у одного пользователяВедите как обычное обращение-инцидент, решайте в рамках своей компетенции
Массовый сбой или повторяющиеся однотипные инцидентыСвяжите инциденты и зарегистрируйте проблему для поиска первопричины
Решение требует изменения конфигурации, обновления ПО или работ на инфраструктуреСоздайте запрос на изменение и дождитесь согласования
Пользователь просит стандартную услугу (доступ, установку ПО)Оформляйте как запрос на обслуживание по каталогу услуг, а не как инцидент

Контроль SLA и отчётность

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

Для анализа работы службы используйте типовые отчёты: по количеству и динамике обращений, соблюдению SLA, нагрузке на исполнителей, повторяющимся инцидентам. Руководителю службы достаточно еженедельного просмотра трёх показателей: доля нарушений SLA, среднее время решения и число переоткрытых обращений — именно они показывают качество процесса.

Контрольные точки

Как проверить, что процесс работает

Назначение исполнителей
Норма

Обращение получает группу или специалиста автоматически в течение минут

Тревожный признак

Заявки висят в общей очереди без назначения — проверьте правила маршрутизации

Качество решений
Норма

В решении указаны причина, действия и результат

Тревожный признак

Формальные ответы «исправлено», растёт число переоткрытий

Соблюдение SLA
Норма

Нарушения единичны и разбираются

Тревожный признак

Систематические просрочки по одним услугам или группам — требуется пересмотр нормативов или штата

Частые ошибки и ограничения самостоятельной настройки

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

Границы безопасной самостоятельной работы: пользовательские настройки списков, отборов, шаблонов ответов и личных оповещений можно менять свободно. Изменение правил маршрутизации, матрицы приоритетов, параметров SLA и статусной модели — только через администратора системы, поскольку ошибка затронет всех пользователей и может исказить действующие соглашения с заказчиками услуг.

Типичные ошибки при работе в 1С:ITIL
01
Завышение приоритета всех заявок — теряется смысл матрицы и статистика SLA
02
Ведение переписки в почте вне карточки — при передаче заявки история теряется
03
Закрытие без содержательного решения — база знаний не пополняется, повторные обращения решаются с нуля
04
Игнорирование статуса ожидания — таймер SLA идёт, хотя шар на стороне пользователя
05
Изменение продуктивной среды по инциденту без запроса на изменение — риск сбоев и потери данных
Итог

Что важно запомнить

Ядро работы в 1С:ITIL — дисциплинированное ведение обращения: точная классификация на входе, все действия в карточке, содержательное решение на выходе. SLA, база знаний и отчёты работают только на качественных данных. Изменения в продуктивной среде — только через согласованный запрос на изменение.

Частые вопросы

Чем обращение отличается от инцидента в 1С:ITIL?

Обращение — общий объект для любого запроса пользователя: вопроса, запроса на услугу или сообщения о сбое. Инцидент — частный случай обращения, связанный с нарушением или деградацией качества услуги. Тип определяется при классификации и влияет на маршрутизацию и применяемый процесс.

Почему обращение не назначается исполнителю автоматически?

Чаще всего не заполнена услуга в обращении или для неё не настроено правило маршрутизации. Проверьте также, что группа исполнителей активна и в ней есть специалисты. Настройку правил выполняет администратор системы.

Как приостановить отсчёт SLA, если жду ответа пользователя?

Переведите обращение в статус ожидания с комментарием, чего именно вы ждёте. В типовой настройке таймер SLA в этом статусе приостанавливается. Если остановка не происходит, уточните у администратора параметры статусной модели — поведение таймера настраивается.

Что делать, если пользователь не подтверждает закрытие заявки?

В типовых настройках обращение закрывается автоматически по истечении заданного срока ожидания подтверждения. До этого пользователю можно отправить напоминание из карточки обращения. Срок автозакрытия задаётся в настройках процесса.

Можно ли подключить приём заявок из почты и Telegram?

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

Какие отчёты смотреть руководителю службы поддержки?

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