Отдельная таблица оборудования отвечает на вопрос «что есть у компании». Service Desk отвечает на вопрос «с какой проблемой обратился сотрудник». Когда данные связаны, инженер может найти обращения по конкретному устройству, а руководитель — проверить историю его обслуживания.
Для этого недостаточно добавить название ноутбука в комментарий. Нужны устойчивый идентификатор актива, понятные отношения с сотрудниками и правила обновления. В SC Desk сценарий связи оборудования и обращений рассматривается в разделе IT-активы и CMDB. Ниже — схема подготовки данных; это учебная модель, а не описание фиксированного формата импорта продукта.
Определить задачу реестра
Если цель — знать, кому выдано устройство и какие неисправности с ним происходили, начните с небольшого набора полей. Не собирайте десятки атрибутов, которые никто не обновляет.
Учёт активов и CMDB решают пересекающиеся задачи. Реестр помогает учитывать оборудование, владельцев и жизненный цикл. CMDB дополнительно описывает связи конфигурационных единиц и сервисов. Полноту модели нужно выбирать по рабочим вопросам команды: например, какие сервисы затронет замена сетевого устройства.
Использовать идентификатор, который не меняется при передаче
Имя сотрудника, кабинет и отображаемое название оборудования не подходят как единственный ключ. Устройство могут передать другому человеку, переместить или переименовать.
Для миграции согласуйте внутренний ID актива и способ сопоставления с исходными данными. Серийный номер полезен для проверки, но его наличие и уникальность тоже нужно проверить: у виртуальных объектов или комплектующих правила могут отличаться.
| Поле учебной модели | Назначение | Проверка |
|---|---|---|
| ID актива | Связь с обращениями и исходным реестром | Не пустой, уникальный, сохраняется при обновлении |
| Тип | Ноутбук, монитор, сетевое устройство и другие группы | Значение из согласованного справочника |
| Серийный номер | Идентификация физического устройства | Дубли и отсутствующие значения разобраны |
| Статус | В эксплуатации, на складе, в ремонте, списан | Одно значение из утверждённого набора |
| Ответственный | Текущий пользователь или команда | Ссылка на существующего сотрудника или группу |
| Размещение | Площадка, подразделение, кабинет | Единый формат и известный владелец данных |
Разделить текущую выдачу и историю
Смена ответственного не должна стирать сведения о прошлых обращениях. В истории заявки полезно сохранить, к какому устройству относилась неисправность и кто обращался в момент регистрации.
Учебный пример: сотрудник сообщил о неисправности ноутбука A-104. После ремонта ноутбук передали другому сотруднику. У новой заявки должна быть актуальная связь с устройством, а старая переписка остаётся частью истории прежнего обращения. До внедрения проверьте, как выбранная система показывает текущую выдачу и прошлые события.
Не смешивайте оборудование и доступы. Заявка на выдачу прав может относиться к информационной системе и роли, а не к ноутбуку сотрудника. Модель связей должна соответствовать процессу.
Подготовить данные из Excel или старого Service Desk
Сначала соберите используемые реестры и назначьте владельца эталонного набора. Нормализуйте типы, статусы и размещения. Проверьте дубли серийных номеров и активы, у которых указаны уволенные сотрудники или неизвестные подразделения.
Затем согласуйте таблицу соответствия исходных и целевых идентификаторов. Это позволяет отдельно проверить перенос пользователей, активов и заявок, а после — восстановить отношения между ними. Не назначайте связи по совпадению отображаемых названий.
При переносе из GLPI составьте перечень сущностей, дополнительных полей и плагинов. Общая схема подготовки миграции описана в сравнении GLPI и SC Desk; конкретные форматы и перенос истории согласуются по конфигурации.
Проверить связь активов и обращений на пилоте
Возьмите небольшой набор реальных обезличенных данных. Подготовьте устройство с одним ответственным, общее оборудование отдела, актив без назначенного сотрудника и устройство, которое передавалось между подразделениями.
Пройдите проверки:
- Создайте обращение и выберите нужный актив.
- Проверьте, что инженер видит только разрешённые сведения.
- Найдите обращение из карточки актива или доступного в системе представления его истории.
- Измените ответственного и проверьте сохранность старой заявки.
- Повторите обновление исходных данных и убедитесь, что не появились дубли.
- Проверьте списанный актив: новые обращения и видимость должны соответствовать регламенту.
Если путь выполняется через разные экраны или требует доработки, включите это в состав внедрения. Результат пилота — подтверждённый рабочий сценарий, а не только список установленных модулей.
Назначить владельцев данных
Определите, кто создаёт новый актив, оформляет выдачу, меняет размещение и отмечает списание. Если источников несколько, согласуйте приоритеты: какие поля обновляет инвентаризация, какие ведёт администратор, какие поступают из каталога пользователей.
История изменений, доступ к персональным данным и регламент обновлений важнее объёма заполненной таблицы. Для решения о замене устройства полезно видеть подтверждённые обращения и расходы, а не выводить необходимость покупки из одного счётчика тикетов.
Для оценки сценария обсудите внедрение SC Desk. Укажите число активов, текущий источник учёта, нужные связи и систему заявок. Тарифы дают ориентир лицензии, а перенос данных и интеграции оцениваются отдельно.
Нужна система для IT-поддержки?
Посмотрите SC Desk: заявки, SLA, база знаний и IT-активы. Сравните возможности и обсудите внедрение.