Кейс: iTop для юрфирмы на 40 рабочих мест — SLA по договору, учёт «железа и бумаг» и мультиарендность для аутсорсера

До и после внедрения iTop в юрфирме: хаос телефонных заявок и стикеров против портала с очередью, SLA-таймерами и графом CMDB

Исходные данные и боль клиента

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

Итак, московская юридическая фирма: 40 рабочих мест, три сервера — контроллер домена, файловый сервер с системой кадрового ЭДО и терминальный сервер с 1С и СЭД. Своего ИТ-специалиста нет, вся инфраструктура на аутсорсинге у нас. Работали года полтора в режиме «позвонил — починили», и всех вроде устраивало, пока у фирмы не сменился управляющий партнёр. Новый руководитель пришёл с тремя претензиями, которые я записал почти дословно:

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

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

Почему iTop, а не GLPI, который мы тоже знаем и любим? Два аргумента. Первый — SLA: клиенту нужны были таймеры реакции и решения ровно по договорным цифрам, с календарём рабочего времени и отчётом по нарушениям, и в iTop это штатная механика, а не конструктор. Второй — связи «сервис — договор — подрядчик»: у фирмы СЭД и кадровый ЭДО находятся на поддержке у сторонних вендоров, и важно было видеть, по какому вопросу эскалировать нам, а по какому — открывать заявку вендору по его договору. Модель CMDB в iTop с классами договоров и контактов подрядчиков закрыла это из коробки. Подробно про архитектуру системы — в обзорной статье цикла.

Снятие требований: неделя до первой установки

Главная ошибка внедрений service desk — начинать с установки. Мы начинаем с опросника, и на юрфирме он занял неделю неспешных разговоров. Что выясняем:

  • Перечень сервисов глазами бизнеса. Не «терминальный сервер», а «работа с делами в СЭД», «1С для бухгалтерии», «печать и сканирование», «почта и календари». Юристу всё равно, какой сервер завис — он не может открыть дело клиента.
  • Каналы поступления заявок. Было: звонки инженеру, звонки мне, письма на общий ящик, сообщения в мессенджерах. Решили: портал и почта — официальные каналы, телефон остаётся для блокирующих ситуаций.
  • Матрица приоритетов. Тонкий момент: у юристов «горит судебное заседание, не печатается доверенность» — это блокирующий инцидент, даже если с точки зрения ИТ сломался всего лишь принтер. А «не работает мышка у стажёра» подождёт до завтра. Приоритет определяется влиянием на бизнес, и это надо проговорить и записать заранее, а не спорить в момент аварии.
  • SLA из договора. Выписали дословно цифры реакции и решения — о них ниже.

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

Проектируем CMDB под юрфирму

Классы конфигурационных единиц

Для фирмы на 40 рабочих мест не нужна вся мощь датамодели iTop — мы включили минимум: серверы и виртуальные машины, рабочие станции, МФУ и принтеры (юристы печатают тоннами, и печать — их вторая по частоте боль), сетевое оборудование, ПО и лицензии (КонсультантПлюс, СЭД, 1С, офисные пакеты), договоры с вендорами и контакты их поддержки.

Связи, ради которых всё затевалось

Ключевая цепочка выглядит так: сервис «Работа в СЭД» → терминальный сервер → гипервизор → договор поддержки вендора СЭД → контакт вендора с телефоном и почтой. Когда терминальник уходит в ребут, дежурный инженер видит в iTop, какие сервисы легли и кого предупреждать. Когда падает сама СЭД при живом сервере — видит номер договора и почту поддержки вендора. До внедрения эта информация жила в переписке двухлетней давности.

Граф CMDB юрфирмы: СЭД связана с терминальным сервером, гипервизором и договором вендора; подсвечен impact-анализ отказа

Конфиденциальность: что мы НЕ заносим в CMDB

Юрфирма — особый случай: адвокатская тайна не абстракция, а режим работы. Мы договорились на берегу: в CMDB не попадают названия дел и клиентов фирмы, содержимое документов и любые данные из СЭД. Учитываем железо, ПО, договоры на обслуживание и связи между ними — и только. В заявках юристов приучили писать «проблема с доступом к делу» без номера дела; если деталь нужна для диагностики, инженер уточняет её голосом, и в тикет она не попадает.

Итог наполнения: 310 конфигурационных единиц за два рабочих дня. Железо и ПО влетели через CSV-импорт из нашего PowerShell-инвентаря (скрипт обходит машины по WinRM и собирает модель, серийник, ОС, установленное ПО), договоры и контакты вендоров секретарь фирмы занесла руками за пару часов — их всего полтора десятка.

SLA как в договоре, а не «как получится»

Берём договор и переносим цифры в SLT-объекты iTop один в один:

Тип обращенияРеакцияРешение
Инцидент «блокирующий» (не работает сервис целиком или у ключевого сотрудника)30 минут4 часа
Инцидент «стандартный»2 часа8 рабочих часов
Запрос на обслуживание (новый сотрудник, доступ, установка ПО)4 часа3 рабочих дня

Обязательная деталь — рабочий календарь: у фирмы это будни с 9:00 до 19:00. iTop считает таймеры с учётом календаря, поэтому заявка, поданная в пятницу в 18:50, не «горит» всю субботу: таймер замирает в 19:00 и продолжает тикать в понедельник с 9:00. Без настроенного календаря SLA-отчёт превращается в генератор ложных нарушений — это, кстати, частая ошибка самостоятельных внедрений.

И момент честности, который я считаю самым важным в этом разделе. Первые два месяца отчёт показывал нарушения SLA — 8% в первый месяц, 5% во второй. Мы не стали подкручивать цифры и показали клиенту как есть, с разбором каждого случая. Реакция управляющего партнёра меня приятно удивила: «Отлично, значит, система не рисует». Система впервые показала реальность — а реальность до формализации была, очевидно, хуже, просто её никто не измерял. К четвёртому месяцу вышли на стабильные 96–98% соблюдения.

Портал и приживаемость: как заставить юристов писать заявки

Технически портал заработал в первый день. Организационно — «мне проще позвонить» держалось месяцами. Сопротивление сломали три вещи:

  1. Заявка с портала получает приоритет в очереди. Мы прямо объявили: письменные обращения инженер берёт первыми, телефонные без регистрации — по остаточному принципу (кроме блокирующих). Пара недель — и самые громкие «телефонные» пользователи распробовали, что через портал быстрее.
  2. Формы-шаблоны под типовые запросы. В портале собрали заготовки: «новый сотрудник» (ФИО, дата выхода, нужные доступы — галочками), «доступ к делу», «проблема с печатью» (какой принтер, какой документ). Пользователь не сочиняет текст, а заполняет три поля. Это снизило и порог входа, и количество уточняющих вопросов от инженера.
  3. Еженедельный дайджест партнёру. Короткое письмо: сколько заявок, сколько закрыто в срок, что в работе. Руководитель видит движение — и сам транслирует вниз «пишите на портал, я по нему смотрю, кто чем занят».

Метрика приживаемости: к концу третьего месяца 87% обращений приходили через портал и почту. Оставшиеся 13% — телефонные, из них большая часть честно блокирующие, которые инженер сам регистрирует задним числом. Это здоровая пропорция, лучше на малом офисе не бывает.

Мультиарендность: один iTop — много клиентов аутсорсера

Бонусный раздел для коллег по цеху. Юрфирма из кейса живёт не в отдельной инсталляции: это одна из организаций в нашем общем iTop. Вести отдельную систему под каждого клиента до 50 РМ экономически бессмысленно — сопровождение (бэкапы, обновления, мониторинг, см. статью об эксплуатации) умножается на число инсталляций.

Механика Organizations

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

Профили и allowed organizations для инженеров

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

Схема мультиарендности iTop: одна инсталляция в центре, шесть изолированных секторов-организаций, инженеры аутсорсера с доступом ко всем

Каталоги услуг per-организация

У каждого клиента свой тариф и свой набор услуг, поэтому каталог услуг в iTop тоже привязан к организации: юрфирма видит свои девять услуг со своими SLA, торговая компания — свои двенадцать с другими таймерами. Один движок — разные договорные обвязки.

Когда мультиарендность не подходит

Честные ограничения подхода. Отдельную инсталляцию мы поднимаем, когда у клиента жёсткие требования ИБ (данные не могут находиться в общей базе с кем-либо — у юристов и медиков такое случается), когда нужна кастомная датамодель, ломающая общую (свои классы CI и поля затрагивают всех арендаторов), и когда клиент дорос до собственной ИТ-службы и хочет систему себе. Для остальных шести наших организаций-клиентов общая инсталляция — экономия на сопровождении буквально в разы: один сервер, один бэкап, одно окно обновлений.

Отчётность для директора: «за что я плачу»

Возвращаюсь к главной претензии управляющего партнёра. Ежемесячный отчёт, который он теперь получает, собирается из iTop за полчаса и состоит из четырёх блоков:

  • Заявки по категориям и сервисам — сколько было, сколько закрыто, среднее время решения. Видно, что «болит»: три месяца подряд лидирует печать — значит, пора менять парк МФУ, и это уже аргументированный разговор о бюджете.
  • Выполнение SLA — процент в срок, список нарушений с причинами. Та самая прозрачность, ради которой всё затевалось.
  • Топ проблемных рабочих станций — машины с наибольшим числом инцидентов. Кандидаты на замену определяются не ощущениями инженера, а статистикой: у станции восемь тикетов за квартал — вот она, строчка в бюджет следующего года.
  • Реестр техники и лицензий — тот самый, который для аудитора собирали неделю. Теперь это экспорт из CMDB за пять минут: инвентарные номера, серийники, версии ПО, сроки лицензий и договоров.

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

Цифры внедрения: сроки, деньги, эффект

ПоказательЗначение
Трудозатраты на внедрение (требования, настройка, наполнение CMDB, портал, обучение)12 дней инженера
ИнфраструктураОдна виртуальная машина (4 vCPU / 8 ГБ), лицензии — 0 ₽
Сопровождение системы~4 часа в месяц
Конфигурационных единиц в CMDB310
Потерянных заявок за полгода0
Среднее время решения−38% к «дожурнальной» эпохе (по первым замерам против четвёртого месяца)
Реестр техники к аудиту5 минут вместо недели

Про деньги — считаю окупаемость против облачного helpdesk-SaaS. Типовые коммерческие сервисы такого класса стоят от 1000–1500 ₽ за агента в месяц, плюс учёт активов часто отдельным модулем. Но главная разница даже не в подписке: на 40 портальных пользователей многие SaaS начинают тарифицировать и их. Наш вариант: ВМ на собственном гипервизоре — условно 3–4 тысячи ₽ в месяц инфраструктурных затрат плюс 4 часа сопровождения. За три года разница набегает в несколько сотен тысяч рублей — при том, что данные лежат на нашей площадке в дата-центре МТС, а не у третьей стороны, что для юрфирмы был отдельный аргумент.

Что бы я сделал иначе + применимость к другим сегментам

Честные ошибки кейса. Первая: мы сразу включили модуль управления изменениями (Change Management) — по учебнику ITIL же положено. Через месяц выключили: на 40 РМ согласование изменений через отдельный процесс — чистый оверхед, все изменения и так проходят через одного нашего инженера и одно контактное лицо клиента. Вернёмся к нему, когда фирма дорастёт до сотни рабочих мест. Вторая ошибка: недооценили обучение секретарей — а именно они оказались главными «диспетчерами» заявок от партнёров старой школы, которые сами на портал не пойдут никогда. Два дополнительных часа обучения секретарей дали больше эффекта, чем вся рассылка инструкций юристам.

Насколько кейс переносится на другие сегменты малого бизнеса — из нашей практики:

  • Медицинская клиника. Плюс: учёт медицинской техники с договорами поверки и обслуживания ложится в CMDB идеально — классы договоров и дат следующего ТО закрывают то, что клиники ведут в Excel. Минус: требования к персональным данным жёстче адвокатской тайны — правило «в тикетах никаких данных пациентов» приходится закреплять организационно и проверять.
  • Бухгалтерская фирма. Специфика — сезонность: в отчётные кампании (март, апрель, июль, октябрь) нагрузка на ИТ взлетает, и «стандартный» инцидент у главбуха 28 марта — это на самом деле блокирующий. Решается сезонной матрицей приоритетов: на период кампаний SLA по бухгалтерским сервисам ужесточаются, и это прописано в договоре.

Общий вывод цикла простой. iTop — редкий случай, когда бесплатный инструмент закрывает договорную, юридически значимую часть отношений аутсорсера и клиента: SLA, учёт, отчётность. Внедрение — 12 дней, сопровождение — 4 часа в месяц, а взамен — отношения с клиентом, в которых вопрос «за что я плачу» больше не звучит.

Хотите такой же порядок в ИТ?

Внедрим iTop под ваш договор: каталог услуг, SLA, учёт техники и понятный отчёт раз в месяц. Работаем с юрфирмами, клиниками и бухгалтериями до 50 рабочих мест — 15+ лет практики IT-аутсорсинга.

✈️ Telegram @ITfresh_Boss 📞 +7 903 729-62-41
#iTop #кейс #SLA #CMDB #аутсорсинг #service desk
Комментарии 0

Оставить комментарий

загрузка...

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

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

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.