Кейс: service desk на GLPI для бухгалтерской фирмы на 30 человек — от заявок в WhatsApp к порталу с SLA

Переход бухгалтерской фирмы от хаоса заявок в WhatsApp к порядку в портале GLPI: слева заваленный сообщениями админ, справа аккуратная очередь заявок со статусами

Исходная точка: WhatsApp-хаос

Дисклеймер. Это собирательный кейс. Он основан на нескольких похожих внедрениях ITfresh для бухгалтерских компаний, но конкретные цифры, имена, сроки сертификатов и детали инфраструктуры изменены и обобщены, чтобы не раскрывать данные заказчиков. Технические решения и подход — настоящие, ими мы пользуемся в работе.

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы держим свои серверы в дата-центре МТС и уже больше пятнадцати лет обслуживаем малый бизнес в Москве — компании до пятидесяти рабочих мест. За это время через нас прошли десятки бухгалтерских фирм, и почти все они приходили с одной и той же болезнью. Расскажу, как мы её лечим, на примере типичной конторы.

Итак, бухгалтерская фирма на аутсорсе, тридцать рабочих мест. Ведут около двух сотен клиентов — от ИП на упрощёнке до средних ООО с НДС. Стек стандартный для отрасли: в нескольких базах, СБИС для сдачи отчётности, три разных банк-клиента под разные банки клиентов, КриптоПро CSP и ворох токенов с электронными подписями. У каждого бухгалтера на столе один-два Рутокена, а у ведущих специалистов — целая связка на кольце, потому что подпись директора клиента, подпись главбуха клиента и подпись самой фирмы физически лежат на разных носителях.

Айтишника в штате нет. Есть приходящий админ — то мы, то до нас кто-то ещё. И заявки этому админу прилетали единственным способом: в личный WhatsApp. «Женя, у Марины не открывается база», «принтер на третьем не печатает», «слетела подпись, завтра сдавать НДС, помогите». Всё вперемешку с рабочими чатами, семейными фотографиями и рассылками из родительского комитета.

Пока заявок пять в день — это работает. Терпимо. Но у бухгалтерии есть сезон. В марте-апреле, когда идёт годовая отчётность и НДС за первый квартал, поток вырастает втрое, все на нервах, и примерно половина сообщений просто тонет. Человек написал в 22:40, админ прочитал утром, к обеду забыл, а бухгалтер уверен, что заявку приняли. Классика: «я же ещё на той неделе писала».

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

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

Почему GLPI, а не платный helpdesk

Первый вопрос, который задаёт собственник: «А почему не купить готовый облачный хелпдеск, там же всё из коробки?» Вопрос честный, и мы всегда проговариваем критерии выбора вслух, а не навязываем своё решение. Для этой фирмы критериев было четыре, и все они одинаково важны.

  • Свой сервер. Бухгалтерская фирма работает с персональными данными сотрудников своих клиентов — по сути, с данными половины города. Отдавать в чужое облако даже метаданные заявок (кто, когда, по какому клиенту обращался) собственник не захотел, и правильно сделал. Своя инсталляция на своём VPS — это контроль над тем, где физически лежат данные.
  • Русский интерфейс для бухгалтеров 45+. Средний возраст пользователей — сильно за сорок. Половина из них искренне боится компьютера за пределами 1С и Excel. Любой англоязычный или перегруженный интерфейс убьёт затею на старте: люди просто вернутся в WhatsApp. Нужен полностью русский, спокойный, предсказуемый портал.
  • Ноль лицензионных платежей. Тридцать пользователей в облачном хелпдеске по подписке за каждого агента и каждого запросившего — это ощутимая ежемесячная статья расхода, растущая вместе с фирмой.
  • Учёт токенов и лицензий в той же системе. Это оказалось решающим. Нам был нужен не просто трекер заявок, а система, которая одновременно ведёт инвентарь: где какой токен, чей сертификат, когда истекает, какая лицензия 1С к какому месту привязана. Заводить для этого отдельный продукт — плодить зоопарк.

GLPI закрывает все четыре пункта разом. Это open source, ставится на свой сервер, полностью русифицирован в ядре, не берёт денег за пользователей и из коробки умеет и заявки, и инвентаризацию, и учёт произвольных активов. Одиннадцатая версия дополнительно втянула в ядро конструктор форм (бывший плагин Formcreator), нативную двухфакторную аутентификацию по TOTP, вебхуки и встроенного агента инвентаризации — то есть ровно то, что раньше приходилось собирать из плагинов.

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

ВариантРазовые затратыЕжемесячноИтого за 3 года
Облачный helpdesk A (за агента)Настройка ≈ 30 000 ₽≈ 24 000 ₽≈ 894 000 ₽
Облачный helpdesk B (за пользователя)Настройка ≈ 20 000 ₽≈ 18 000 ₽≈ 668 000 ₽
GLPI на своём VPSВнедрение ≈ 90 000 ₽VPS ≈ 1 500 ₽≈ 144 000 ₽

Даже с учётом того, что внедрение GLPI на старте дороже (за него платят один раз живому инженеру, а не подписке), на горизонте трёх лет своя инсталляция выигрывает в пять-семь раз. А главное — по функциям для этого масштаба она не уступает: те же формы, SLA, уведомления, плюс инвентарь, которого в базовых тарифах облаков обычно и нет.

Честная оговорка. GLPI не бесплатен в смысле «поставил и забыл». Кто-то должен его обновлять раз в один-два месяца, следить за бэкапами и безопасностью. Если у фирмы нет своего админа — этот кусок берёт на себя аутсорсер, и его стоит закладывать в расчёт. У нас он входит в абонентское обслуживание, поэтому в таблице отдельной строкой не выделен.

Проектирование под пользователя, который боится компьютера

Главная ошибка при внедрении хелпдеска в бухгалтерии — спроектировать его так, как удобно инженеру. Инженеру удобно поле «Опишите проблему» и десяток технических категорий. Бухгалтеру это поле — стена. Он не знает, что писать, боится ошибиться и уходит обратно в мессенджер. Поэтому мы проектировали портал от обратного: от самого нетехнического пользователя.

Конструктор форм: пять сценариев вместо пустого поля

В GLPI 11 конструктор форм встроен в ядро. Мы не стали давать людям абстрактную «новую заявку», а собрали пять конкретных форм под реальные сценарии, которые за годы наблюдений покрывают процентов девяносто обращений:

  • «Не работает 1С» — выпадающий список: какая база (клиент выбирается из справочника), что именно (не запускается / вылетает / тормозит / ошибка на экране), рабочее место. Ни одного поля со свободным вводом, кроме необязательного «добавить детали».
  • «Нужен доступ к базе клиента» — выбор клиента, тип доступа, кто согласовал. Заявка сразу уходит на согласование к главбуху.
  • «Проблема с ЭП или токеном» — выбор токена из списка активов, тип проблемы (не видит носитель / истёк сертификат / забыл ПИН / нужен перевыпуск). Форма сразу подтягивает срок действия сертификата из карточки актива.
  • «Принтер или сканер» — выбор устройства, симптом. Самая частая и самая простая форма.
  • «Новый сотрудник» — заводится не бухгалтером, а офис-менеджером: ФИО, отдел, какие базы и доступы нужны, к какой дате. Это готовый чек-лист онбординга для нас.

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

Портал самообслуживания: убрать всё лишнее

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

Вход доменной учёткой: ноль новых паролей

Отдельный логин и пароль к порталу — это ещё один барьер и ещё одна причина не пользоваться системой. GLPI умеет авторизацию через LDAP/Active Directory из коробки, поэтому мы подключили портал к доменным учёткам. Сотрудник открывает страницу и заходит тем же логином, что и в Windows — новых паролей запоминать не надо. Заодно это решает вопрос увольнений: отключили учётку в AD — человек автоматически потерял доступ к порталу.

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

SLA с поправкой на отчётность

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

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

СитуацияПриоритетРеакцияРешение
Встала 1С у расчётчика в период отчётностиКритический30 минут2 часа
Не видит токен ЭП, сегодня сдачаКритический30 минут2 часа
Тормозит база вне сезонаВысокий1 часрабочий день
Не печатает принтерСредний2 часарабочий день
Новый сотрудник к датеСредний4 часак указанной дате
«Поменять обои на рабочем столе»Низкий1 день3 дня

Каждый уровень считается по календарю рабочего времени: с 9 до 18 в будни, выходные и праздники не тикают. Если заявка пришла в 17:55, а на реакцию час — таймер продолжится с утра следующего дня, а не «сгорит» ночью. Это честно и по отношению к инженеру, и по отношению к клиенту.

При просрочке GLPI сам поднимает эскалацию на старшего инженера ITfresh: если заявка приоритета «критический» висит без реакции дольше нормы, уведомление уходит не только исполнителю, но и руководителю группы. В сезон это спасает: одну заявку из десятков реально проглядеть, но система не даст ей уйти в тишину.

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

Матрица приоритетов SLA: сетка важность на срочность, выделена критическая ячейка «1С в отчётность — реакция 30 минут»

Учёт специфичных активов бухфирмы

Вот здесь GLPI обыгрывает любой чистый хелпдеск. В бухгалтерской фирме самые ценные и самые проблемные активы — не компьютеры, а токены с электронными подписями и лицензии 1С. Их надо учитывать так же строго, как основные средства, и именно на них раньше не смотрел никто. GLPI 11 позволяет заводить кастомные типы активов с произвольными полями, и мы описали три таких типа.

Токены электронной подписи

Каждый носитель (Рутокен, eToken, JaCarta) стал карточкой актива с полями: владелец подписи (директор клиента, главбух клиента, сама фирма), удостоверяющий центр, выдавший сертификат, срок действия сертификата, физическое местоположение (сейф, у кого на руках, номер ячейки). Теперь на вопрос «а где подпись Ивановой и когда она протухает» ответ — три секунды в системе, а не обзвон коллег.

Лицензии 1С

Лицензии описали отдельным типом: вид (базовая или ПРОФ), привязка к рабочему месту, номер комплекта. Когда у бухгалтера падает 1С с ошибкой лицензирования, инженер сразу видит в карточке, какая именно лицензия должна стоять на этом месте, и не гадает.

Доступы к СБИС и банк-клиентам

Отдельно — реестр учётных записей в СБИС и банк-клиентах по клиентам фирмы: где какой логин, кто отвечает, какие полномочия. Это не пароли (пароли живут в защищённом менеджере), а карта того, кто и куда имеет доступ, — чтобы при уходе сотрудника было понятно, что перевыпускать.

Напоминания, которые закрывают исходную боль

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

Инвентарь остальной техники — тридцать рабочих станций — собрал GLPI Agent, встроенный в одиннадцатую версию. Мы раскатали агента через групповую политику домена, и за один вечер в системе появились все машины: модель, процессор, память, диски, установленное ПО, серийники. Руками не вбивали ничего.

Внедрение за две недели: план по дням

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

  1. Дни 1–2. Сервер и домен. Разворачиваем GLPI 11 на VPS (docroot в public/, PHP 8.2, MariaDB), настраиваем HTTPS, подключаем авторизацию к Active Directory, заводим профили прав. К концу второго дня есть пустая, но живая и защищённая инсталляция, в которую сотрудники уже могут зайти доменной учёткой.
  2. Дни 3–5. Формы и категории — с главбухом. Ключевой момент: категории заявок и формулировки форм мы проектируем не с директором, а с главным бухгалтером. Директор — заказчик, но реальный владелец процесса и человек, который знает, как на самом деле формулируют проблемы сотрудники, — это главбух. Три дня сидим с ней и превращаем реальные обращения из старого WhatsApp в структуру форм и справочников.
  3. Дни 6–7. Агенты и инвентарь. Раскатываем GLPI Agent через GPO, собираем парк машин, заводим кастомные активы — токены и лицензии. К концу первой недели система знает про всё железо и все подписи.
  4. Неделя 2. Пилот на пяти пользователях. Не запускаем сразу на всех. Берём пять человек разного уровня уверенности — от продвинутого до самого «боящегося компьютера» — и неделю гоняем на них реальные заявки. Смотрим, где люди спотыкаются, и доводим формулировки. Именно на пилоте мы переписали тексты трёх форм.
  5. Запуск и памятка. В конце второй недели включаем портал для всех и раздаём одностраничную памятку: две кнопки, три картинки, куда нажимать. Не инструкцию на двадцать страниц, которую никто не прочтёт, а один лист.
Про обучение. Мы сознательно уложили обучение пользователей в двадцать минут, а не в два часа. Если систему нужно объяснять два часа — она спроектирована неправильно. Двадцать минут — это «вот кнопка подать заявку, вот выбор из списка, вот ваши заявки». Всё остальное человек понимает сам, потому что форма не даёт ошибиться.

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

Цифры через три месяца

Через квартал после запуска мы сели и посмотрели на цифры. Не на ощущения «вроде стало лучше», а на то, что показывает система, — в этом и была вся идея.

ПоказательБыло (WhatsApp)Стало (GLPI)
Заявок в месяцнеизвестно≈ 120
Медиана времени решенияне измерялась4 часа
Потерянных заявок≈ половина в сезон0
Предотвращённых истечений сертификатов02
Споров «мы просили месяц назад»регулярнонет

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

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

Что не взлетело — честно

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

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

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

Итоги внедрения GLPI за три месяца: 120 заявок в месяц, медиана решения 4 часа, 0 потерянных заявок, 2 спасённых сертификата

Как перенести этот шаблон на юрфирму или клинику

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

Юридическая фирма

У юристов вместо токенов и лицензий 1С в центре внимания — доступы к правовым системам: справочно-правовым базам и системам работы с судебными делами. Их учитываем теми же кастомными активами: у кого какой доступ, до какой даты оплачен, кто ответственный. Формы переписываем под их сценарии: «не открывается правовая база», «нужен доступ к делу», «проблема с электронной подачей в суд».

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

Клиника

В клинике добавляется учёт медицинской техники как кастомных активов — с привязкой к кабинетам, датами поверки и обслуживания, гарантией. А заявки массово идут от регистратуры: «не печатает талон», «завис компьютер на приёме», «не работает касса». Это ровно тот же профиль пользователя, что бухгалтер 45+, — нетехнический человек под нагрузкой, которому нужны простые формы с выбором из списка, а не пустое поле.

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

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

Наведём порядок в заявках за две недели

ITfresh — IT-аутсорсинг для компаний до 50 рабочих мест в Москве. Внедрим GLPI под ключ с типовыми формами в комплекте, настроим SLA, инвентаризацию и учёт токенов ЭП. Собственные серверы в дата-центре МТС, 15+ лет опыта. Telegram: @ITfresh_Boss, телефон: +7 903 729-62-41

📞 Связаться с нами
#GLPI #service desk #бухгалтерия #helpdesk #ITSM #внедрение #электронная подпись #ИТ-аутсорсинг
Комментарии 0

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

загрузка...

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

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

Реквизиты оператора персональных данных

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