Lancelot ITSM Service Desk: Служба Поддержки управление обращениями и операционная надёжность
Запросить демонстрациюДемонстрация
Lancelot ITSM Service Desk: Служба Поддержки — управление обращениями и операционная надёжность

Проведите каждое обращение по регламенту до закрытия — и соберите из тех же инцидентов квартальную форму 0409072

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

Запросить демонстрацию

Показываем на своём стенде маршрут обращения от приёма до закрытия, счётчик срока на карточке, права на переход статуса и сборку формы 0409072 — около 40 минут по видеосвязи. Если сначала нужны подробности — форма 0409072, права и аудит, требования к развёртыванию. ITSM — управление ИТ-услугами, ЗНО — запрос на обслуживание, КЕ — конфигурационная единица, SLA — соглашение об уровне обслуживания, НФО — некредитная финансовая организация.

  • Квартальная форма 0409072 собирается из тех же инцидентов, что ведёт служба поддержки: двенадцать разделов включаются независимо друг от друга.
  • Реквизиты кредитной организации — переменные шаблона: код по ОКАТО, код по ОКПО, регистрационный номер, полное фирменное наименование, адрес.
  • Разделы 11 и 12 закрывают диапазоны номеров платёжных карт по эмиссии и банковские идентификационные номера по эквайрингу.

Продукт в цифрах

Ниже — то, что заложено в статусные модели, модель прав и отчётные формы продукта.

19 статусов в жизненном цикле инцидента — от регистрации до закрытия, включая передачу подрядчику Статусная модель инцидента
25 переходов между статусами инцидента: маршрут описан явно, шаг мимо модели невозможен Статусная модель инцидента
6 статусных моделей зарегистрированы как охраняемые типы с действиями просмотр, изменение и выполнение действия / смена статуса Модель прав, реестр охраняемых типов
5 разделов карточки, на каждый из которых право выдаётся отдельно: проблема, процесс, событие, ЗНО, поставщик Модель прав, реестр охраняемых типов
12 разделов квартальной формы 0409072, каждый включается в выгрузку независимо Выгрузка формы 0409072
0,15 / 0,30 / 0,50 доли нормативного срока, отведённые первой, второй и третьей линиям поддержки Расчёт нормативного срока по обращению
4 режима входа переключаются одним свойством: файл, база, OAuth2 / OIDC, каталог учётных записей по LDAP Конфигурация аутентификации
1 мин период опроса почтового ящика: каждое непрочитанное письмо становится обращением Фоновое задание приёма почты

Один экран вместо десятка таблиц

Слева — как учёт обращений выглядит, пока живёт в файлах. Справа — как та же работа выглядит в реестре продукта.

Пока учёт живёт в таблицах

  • Инциденты_2026Q1_v3_итог_финал_2_правки.xlsx Просроченные строки закрашены руками. Версия — в имени файла.
  • Согласования_процессов_свод.xlsx Кто согласовал и когда вернул — на отдельной вкладке.
  • 0409072_сборка_из_трёх_файлов.docx Разделы формы сводятся вручную к каждому кварталу.
  • Поставщики_контакты_актуальное.xlsx Договорные сроки — в четвёртом столбце, если его не сдвинули.

Нарушение срока обнаруживается на сверке. Автора перевода статуса восстанавливают по переписке.

Один реестр в продукте

Инцидент · Передан подрядчику остаток нормативного срока 00:42:10

Инцидент · Принят в работу 3 линией поддержки −00:12:04

Обращение · Первичная обработка 1 линия

Процесс · Передано на согласование КПО возврат с комментарием

Статус, срок и исполнитель — в одной строке.

Переход статуса доступен только субъекту с правом выполнения действия или смены статуса на этой статусной модели и попадает в журнал переходов.

Кому адресован продукт

Руководителю службы поддержки

Обращение уходит на вторую линию, и дальше его судьба держится на памяти исполнителя: кто принял, когда вернул, сколько осталось до срока.

В продукте маршрут задан статусной моделью: девятнадцать статусов инцидента, двадцать пять переходов, отдельные статусы приёма, отклонения и решения для второй и третьей линии. Остаток срока стоит на карточке и краснеет сам.

ИТ-директору и архитектору

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

Вход переключается одним свойством на файл, базу, OAuth2 / OIDC или каталог учётных записей по LDAP. Конфигурационные единицы, процессы и поставщики ведутся здесь же, обращения отдаются наружу запросом к API, а массовые данные заводятся импортом Excel через промежуточные таблицы.

Директору по операционным рискам

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

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

Как проходит обращение

Рабочий экран службы: реестр, статусы из статусных моделей продукта и остаток срока в той же строке.

Реестры службы поддержки Пример заполнения

Таблица прокручивается вбок — колонок больше, чем помещается.

НомерТема обращенияСтатусГруппа исполнителяИсполнительОстаток нормативного срока
INC-10412Недоступен модуль печати платёжных документовПередан подрядчику3 линия поддержкиСмирнов А. В.−00:12:04
INC-10407Ошибка выгрузки в смежную системуПринят в работу 3 линией поддержки3 линия поддержкиКрылов И. С.00:42:10
INC-10399Замедление отклика при закрытии дняПринят в работу 2 линией поддержкиГруппа сопровожденияТарасова Е. Н.03:15:48
INC-10388Не приходят уведомления по согласованиямОжидает ответаГруппа сопровождения—приостановлен
INC-10375Сбой резервного канала связи в филиалеРешен 3 линией поддержки3 линия поддержкиКрылов И. С.01:04:22
INC-10361Повторный отказ терминала самообслуживанияЗакрыт1 линия поддержкиГришина О. П.закрыт

Статусы «Передан подрядчику», «Принят в работу 3 линией поддержки» и «Решен 3 линией поддержки» — из статусной модели инцидента, вместе с переходами между ними.

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

Полный маршрут обращения

Сроки, которые видно на карточке

Нормативный срок делится между тремя линиями поддержки, хранится в секундах и отсчитывается на открытой карточке раз в секунду.

Сколько времени бюджета достаётся линии

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

— часа бюджета на выбранную линию

  • 1 линия — доля 0,15 бюджета
  • 2 линия — доля 0,30 бюджета
  • 3 линия — доля 0,50 бюджета

Первая линия работает внутри своей доли бюджета. Когда она переводит обращение дальше, отсчёт продолжается по бюджету принявшей линии.

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

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

Доли трёх линий заданы в продукте как 0,15, 0,30 и 0,50 бюджета времени. Они применяются, пока для обращения не рассчитан индивидуальный нормативный срок обработки.

Просрочка видна на карточке, а не на сверке

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

Если нормативный срок по фактическим данным не рассчитан в течение 15 секунд после остановки таймера обработки, система определяет его по бизнес-функции и приоритету обращения. Карточка не остаётся без срока.

Срок не приходится спрашивать

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

Кому уйдёт сообщение, определяет карточка: у обращения, у инцидента и у прочих объектов — свои правила подбора адресатов.

Подробнее о сроках, счётчике и порогах напоминаний

Права доступа и разделение полномочий

Право выдаётся не только на объект, но на раздел карточки и на конкретный переход статуса. Один человек не заводит нарушение, согласовывает его и закрывает.

Что нужно, чтобы перевести инцидент в статус «Передан подрядчику»

Отметьте выданные права — кнопка перехода в карточке ведёт себя так же.

Ещё не выдано прав: 0 из 0. Пока не хватает хотя бы одного, перехода в карточке нет.

Все 0 права выданы — переход доступен субъекту с этой ролью.

Переход выполнен. Он записан в журнал переходов, и журнал открывается прямо на карточке: видно, кто перевёл, когда и из какого статуса.

Право на переход — отдельный охраняемый объект

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

Согласование расписано по ролям

Согласование процесса идёт тремя ступенями подряд: Владелец данных, затем сотрудник КПО, затем менеджер по ОРМ. У каждой ступени есть ветка возврата на доработку, и возврат требует комментария.

Конфигурация напоминаний по срокам согласования описывает 16 пар «роль → статус» для шести ролей: Владелец данных, Владелец процесса уровня 3, Менеджер по качеству данных, Менеджер процесса, сотрудник КПО, сотрудник ОРМ. Пороги одинаковы для всех пар: первое напоминание, «красный» порог 1440 минут и «мёртвый» 2880 минут.

Подробнее о ролях, охраняемых объектах и журналах

Отчётность: надзорная и операционная

Квартальная форма 0409072 собирается в документ Word из двенадцати разделов. Каждый раздел включается в выгрузку отдельным признаком, реквизиты организации — переменные шаблона, а не зашитый текст.

Состав выгрузки формы 0409072

Снимите отметку с раздела — он не попадёт в документ.

В документ войдёт разделов: 0 из 0

    Ни один раздел не отмечен — документ соберётся из одного титульного листа с реквизитами организации.

    Шапку формы заполняют переменные шаблона: код территории по ОКАТО, код организации по ОКПО, регистрационный номер, полное фирменное наименование, адрес и дата «по состоянию на».

    Отчёты службы поддержки

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

    Сверх готовых форм работает конструктор отчётов: модель привязывается к объекту и набору представлений, шаблон Excel загружает пользователь, а сама модель проходит согласование между двумя состояниями — «Редактируется» и «Готов», причём в обе стороны требуется комментарий.

    Форма 0409072 по разделам · Отчёты и конструктор

    Что именно держит регламент

    Не общие слова о процессном подходе, а механизмы, которые не дают обойти маршрут.

    Семь жизненных циклов вместо одного поля «статус»

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

    Возврат от подрядчика заложен в маршрут

    Инцидент принимается на второй линии или сразу на третьей; вторая линия отклоняет, решает или передаёт на третью; третья отклоняет, решает или передаёт подрядчику. Путь от подрядчика ведёт обратно на приём, отклонение или решение третьей линии.

    Переход, который не пройти молча

    Часть переходов объявлена вместе с диалогом комментария: без заполненного комментария переход не выполняется. Так устроены возвраты на доработку в согласовании процесса и в запросе на обслуживание.

    Журнал переходов на карточке

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

    Почта становится обращением

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

    Массовые данные заводятся импортом

    Excel загружается в промежуточные таблицы, а оттуда переносится процедурой слияния. У каждого прогона есть состояние — загрузка, обработка, завершено, ошибка, отменено — и журнал импорта; колонки привязаны к полям буквой столбца, ограничения типизированы.

    Вход переключается свойством

    Четыре режима аутентификации выбираются одним свойством конфигурации: пользователи из файла, учётные записи в базе, OAuth2 / OIDC и каталог учётных записей по LDAP. Отдельная цепочка обслуживает административный вход.

    Навигатор собирается по правам

    Дерево разделов строится в коде, а затем фильтруется правами: остаются только ветки, которые субъект вправе читать. Недоступный раздел не показывается заблокированным — его просто нет в меню.

    Представления пяти категорий

    Любой реестр открывается через именованные представления: системные, базовые, пользовательские, для дашборда и для отчёта. Ветки «Мои представления» в навигаторе — это персональные сохранённые виды.

    Из чего состоит система

    Крупные блоки продукта — те, что покупатель узнает в своей работе.

    Развёртывание в контуре заказчика

    Система ставится в инфраструктуре организации: наружу она обращается только туда, куда ей разрешено конфигурацией.

    Что разворачивается

    Веб-приложение на Java и Spring Boot, собранное в WAR. Хранилище — PostgreSQL; схема ведётся миграциями Liquibase с собственными таблицами журнала изменений. Часть запросов написана вручную и живёт в отдельных описаниях, а не в генераторе.

    Что подключается по месту

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

    Как заводятся пользователи

    Одно свойство конфигурации выбирает режим входа: пользователи из файла, учётные записи в базе, OAuth2 / OIDC или каталог учётных записей по LDAP. Для последнего задаются домен, сервер, база и фильтр поиска. Роли и права редактируются в самой системе.

    Что настраивается под вашу организацию. Состав ролей и матрица прав по модулям, доли нормативного срока и пороги напоминаний, расписание фоновых заданий по четырём готовым режимам — «Никогда», «Ежедневно», «Раз в неделю», «Раз в месяц», — состав разделов формы 0409072, справочники, представления реестров и собственные модели отчётов.

    Кому подходит

    Подходит

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

    Область поставки

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

    Опыт внедрений

    Платформа внедрена в банках и профессиональных участниках рынка под надзором Банка России

    • Ситибанк
    • Банк Русский Стандарт
    • ОТП Банк
    • Тойота Банк
    • Industrial and Commercial Bank of China
    • SBI Bank
    • Mizuho Bank
    • Кредит Европа Банк
    • Международный Банк Азербайджана
    • Нокс Банк
    • Банк РостФинанс
    • Славянбанк
    • БелгородСоцБанк
    • Банк Долинск
    • Петербургский социальный коммерческий банк
    • БрокерКредитСервис Банк
    • Юг-Инвестбанк
    • Синко-Банк

    Перечень относится к платформе в целом; состав внедрённых продуктов у каждой организации свой.

    Посмотреть, как это работает на ваших регламентах

    Показываем маршрут обращения от приёма до закрытия, срок на карточке, права на переход статуса и выгрузку отчёта. Состав показа согласуем заранее.

    Запросить демонстрацию Требования к развёртыванию