Кейс: учёт оборудования в клинике на Snipe-IT

Исходная точка: как выглядел учёт до нас

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы занимаемся IT-аутсорсингом компаний до 50 рабочих мест в Москве, и Snipe-IT — бесплатную систему учёта активов — разворачиваем у клиентов регулярно. В прошлых статьях серии я разбирал, что это за система, как поставить её в Docker за день и как потом сопровождать. Эта статья — живой кейс. Детали я изменил и обобщил, чтобы не выдавать клиента, но суть, цифры и грабли — из реального проекта. Объект — частная многопрофильная клиника на 45 сотрудников с тремя точками приёма.

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

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

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

Особенности клиники как объекта учёта

Прежде чем что-то настраивать, я всегда разбираюсь, чем объект отличается от «офиса с ноутбуками». У клиники набор отличий, который делает её почти идеальным кандидатом на строгий реестр активов.

Дорогое и подвижное оборудование

В офисе актив стоит на столе и живёт там годами. В клинике половина ценного оборудования подвижна: портативные УЗИ-аппараты катают между кабинетами, датчики к ним снимают и переставляют, часть техники ездит на выездные приёмы. Один такой датчик стоит как несколько ноутбуков, а физически это маленькая коробка, которую легко унести, перепутать или сломать. Учитывать надо не только «аппарат №5», но и конкретный датчик с конкретным серийником, потому что именно на него оформляется гарантия.

Разъездные врачи с ноутбуками

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

Материальная ответственность персонала

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

Поверки и ТО с жёсткими сроками

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

Сложите всё вместе — и получится профиль, под который система учёта активов создана почти буквально: много ценных единиц с серийниками, постоянные перемещения, персональная ответственность и календарь обслуживания. Snipe-IT закрывает ровно это. Оговорюсь честно, чтобы не вводить в заблуждение: Snipe-IT — это реестр активов, а не медицинская информационная система. Он не хранит данные пациентов, не имеет медицинских сертификаций и не заменяет МИС. Он отвечает на вопросы «что, где, чьё, в каком состоянии и когда обслуживать» — и делает это бесплатно, без лимита на число активов и пользователей, потому что распространяется как open source.

Проектируем структуру под клинику

Ошибка номер один при внедрении любой системы учёта — начать заводить активы до того, как продуман каркас справочников. Потом всё придётся переделывать с уже забитыми данными. Поэтому первый рабочий день проекта — это не импорт, а проектирование структуры. Разберу по элементам Snipe-IT.

Locations — филиалы → этажи → кабинеты

Локации в Snipe-IT можно вкладывать друг в друга, и мы использовали это на всю глубину: клиника → филиал → этаж → кабинет. Возникает резонный вопрос: зачем такая детализация, не проще ли «Филиал на Ленина»? Ответ дала первая же инвентаризация. Когда актив привязан к «Кабинет 12, 2 этаж», человек со смартфоном обходит клинику по маршруту и физически видит, что должно стоять именно в этой комнате. Когда привязка на уровне филиала — вы знаете, что аппарат «где-то в здании», и ищете его по всем трём этажам. Глубокая структура превращает годовую инвентаризацию из квеста в спокойный обход по списку.

Categories — категории с ответственными

Категории мы завели по типам активов, и у каждой своя логика обслуживания и свой ответственный. Базовый набор для клиники:

Категория в Snipe-IT задаёт поведение: например, для какой категории при выдаче требовать подтверждение приёмки (EULA/Acceptance), а для какой нет. Мебель никто не подписывает, а ноутбук врача — обязательно.

Custom Fields — поля под специфику

Штатных полей актива не хватает, поэтому мы собрали набор пользовательских полей (Custom Fields) и объединили их в наборы (Fieldsets), привязанные к категориям. Ключевые поля:

• Серийный номер датчика — отдельно от серийника самого аппарата, потому что датчик меняется и обслуживается сам по себе.
• Дата следующего ТО / поверки — то самое поле, на котором держится весь календарь обслуживания.
• Инвентарный номер бухгалтерии — чтобы наконец связать реестр ИТ с балансовым учётом и закрыть вечное расхождение «у вас свои номера, у нас свои».
• Ответственное подразделение — для отчётов по материальной ответственности.

Status Labels — жизненный цикл

Метки статусов (Status Labels) описывают, в каком состоянии актив прямо сейчас. Мы завели их под реальный жизненный цикл клиники: в работе, на ТО (приборы уехали к сервисному инженеру), на выезде (техника на выездном приёме), в резерве и списано. Snipe-IT различает «развёрнутые» и «доступные» статусы, и это удобно: отчёт сразу показывает, сколько единиц реально работает, а сколько простаивает на обслуживании или в резерве.

Материальная ответственность через checkout и подпись акта

Это раздел, ради которого клиника, по сути, и затевала проект. Бумажный учёт не давал главного — доказуемого факта передачи. Snipe-IT решает это механизмом выдачи (checkout) с электронным подтверждением приёмки.

Выдача с подписью акта

Когда врачу выдают ноутбук, мы не просто меняем статус в базе. Актив оформляется на сотрудника через checkout, а Snipe-IT формирует запрос на подтверждение приёмки: сотрудник получает акт с текстом соглашения (EULA) и подтверждает получение с фиксацией даты. Так возникает то, чего не было в тетрадке, — юридически осмысленная запись «такой-то принял такой-то ноутбук такого-то числа и согласился с условиями». Врач в халате ставит подпись прямо на планшете администратора, акт сохраняется в системе. При споре это уже документ, а не воспоминание.

На человека или на кабинет: когда что

Snipe-IT умеет выдавать актив на пользователя, на локацию или на другой актив — и это принципиально для клиники. Мы применяем простое правило:

• Checkout на человека — для всего персонального и подвижного: ноутбук врача, портативный УЗИ-аппарат за конкретным специалистом, дорогой датчик. Здесь важна именно личная ответственность.
• Checkout на локацию (кабинет) — для оборудования, закреплённого за помещением, а не за человеком: стационарный прибор в процедурном кабинете, который используют посменно разные сотрудники. Отвечает за него кабинет и его заведующий, а не тот, кто последним включил.

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

Контроль ТО и гарантий

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

Дата следующего ТО и еженедельный отчёт

У каждого обслуживаемого актива заполнено пользовательское поле «дата следующего ТО / поверки». Само по себе поле — это просто дата, оно ничего не напоминает. Поэтому мы подключили к базе Snipe-IT её REST API и написали небольшой скрипт, который раз в неделю запрашивает активы с приближающимся сроком и присылает ответственному сводку: что и когда пора обслуживать. Ответственный получает не «календарь, в который надо заглядывать», а готовое письмо со списком на ближайшие недели.

Запрос к API выглядит примерно так — токен доступа создаётся в личном профиле пользователя:

curl -s -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  "https://assets.klinika.local/api/v1/hardware?limit=500&sort=created_at" \
  | jq '.rows[] | select(.warranty_expires != null)
        | {name, asset_tag, warranty_expires}'

По этому же принципу собирается и отчёт о гарантиях. В Snipe-IT у актива есть штатное поле срока гарантии (warranty_months), от которого система считает дату её окончания. Скрипт выбирает всё, у чего гарантия истекает в ближайшие 60 дней, и шлёт алерт — чтобы успеть либо обратиться в сервис по гарантийному случаю, либо осознанно спланировать платный ремонт, а не узнать об окончании гарантии постфактум.

Экономический эффект одного случая

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

Инвентаризация с QR за один вечер

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

Наклейки и обход по кабинетам

На этапе внедрения каждый актив получил наклейку с QR-кодом — Snipe-IT генерирует их пачкой прямо из системы. Дальше инвентаризация — это обход по дереву локаций: открываешь на смартфоне список «Кабинет 12», сканируешь камерой QR каждого прибора в комнате, система сразу подтверждает, что этот актив числится именно здесь. Сканирование по камере открывает карточку актива мгновенно — не надо ничего искать и вводить руками. Два человека расходятся по этажам и за пару часов закрывают всю клинику.

Сверка отчётом и что делать с ненайденным

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

• Актив числится в кабинете, но не найден — сначала ищем в соседних локациях (возможно, переставили и не отметили), проверяем, не на выезде ли он и не на ТО. Если не нашли нигде — переводим в статус «розыск» и разбираемся адресно, а не списываем скопом.
• Актив найден, но числится в другом месте — переносим в системе на фактическую локацию прямо со смартфона. Это самое частое расхождение, и оно закрывается в одно действие.
• Найден актив без наклейки — заводим в систему на месте, клеим QR. Обычно это то, что купили в течение года мимо учёта.

Через год после запуска расхождение учёта с фактом составило менее 2% против стартовых 30%. И это не разовый героизм комиссии, а естественный результат того, что перемещения фиксируются в системе в момент, когда они происходят, а не раз в год авралом.

Цифры проекта

Люблю кейсы с конкретными числами — они честнее рассуждений. Сведу проект в таблицу, чтобы было видно масштаб и экономику. Напомню: детали обобщены, но порядок величин реальный.

Разложу три дня внедрения, потому что «3 дня» звучит подозрительно быстро, а на деле это реальный срок для объекта такого размера, если не изобретать велосипед:

• День 1 — проектирование и разворачивание. Согласование дерева локаций, категорий и полей со старшей медсестрой и бухгалтером; установка Snipe-IT на наш VPS в дата-центре; настройка справочников, статусов и наборов полей.
• День 2 — миграция и наклейки. Перенос данных из Excel и тетрадки в единый реестр со сверкой на месте; генерация и наклейка QR-меток на активы; заполнение серийников и дат обслуживания.
• День 3 — выдачи и обучение. Оформление текущей материальной ответственности через checkout с подписью актов; подключение API-отчётов по ТО и гарантиям; короткое обучение администраторов и старшей медсестры работе со смартфоном.

Важная деталь про стоимость: лицензий действительно 0 ₽, но «бесплатно» относится только к лицензии. VPS в надёжном дата-центре, установка, миграция, наклейки и ежемесячное сопровождение — это труд, и он стоит денег. Честная экономика self-hosted в том, что этого труда мало: два часа в месяц против абонентки за облачную систему учёта, которая на 180 активов и 45 человек вылилась бы в заметную сумму ежемесячно и навсегда. Здесь же основные расходы разовые, а дальше — только поддержка.

Матрица адаптации кейса под другие сегменты

Самое ценное в этом кейсе — не то, что он про клинику, а то, что каркас переносится почти без изменений. Меняется наполнение справочников, а логика (локации, категории, поля, статусы, checkout с подписью, контроль сроков, QR-инвентаризация) остаётся той же. Ниже — как я адаптирую тот же проект под три других типичных для нас сегмента.

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

Здесь ценность актива не в цене железа, а в том, что на нём лежит. Ноутбуки с конфиденциальными материалами дел — главный объект учёта. Локации проще (обычно один-два офиса), зато критична привязка «кто персонально отвечает за это устройство» и история выдач. Часто добавляется интеграция с корпоративным входом (SSO), чтобы список сотрудников и доступы жили в одном месте. Custom Fields смещаются в сторону «уровень конфиденциальности», «зашифрован ли диск».

Розница

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

Сервисная и монтажная компания

Здесь всё крутится вокруг инструмента, который постоянно в разъездах. Главный механизм — checkout на день: утром бригада получает инструмент под подпись, вечером сдаёт. История выдач показывает, у кого что на руках прямо сейчас. Локации превращаются в «склад / автомобиль / объект», а статусы — в «на складе / в работе / в ремонте».

Сведу это в матрицу — что именно меняется при переносе кейса:

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