Проблема: техника живёт в головах
Типичная ситуация в сервисной компании: какой кондиционер стоит у клиента на третьем этаже, знает Сергей. Когда его меняли — знает Сергей. Гарантия ещё действует? Тоже Сергей. Сергей в отпуске.
Пока объектов десяток, это терпимо. Дальше начинается: выезд на объект без нужной запчасти, потому что не знали модель. Спор с клиентом о том, ремонтировали этот узел или нет. Плановое обслуживание, про которое все забыли, — и авария, которой не должно было быть.
Всё это — симптомы одного: у вас нет учёта того, что вы обслуживаете.
Что такое CMDB простыми словами
CMDB (Configuration Management Database) — это база того, что вы обслуживаете, и связей между этими объектами. В ITIL термин звучит грозно, но по сути это ответ на вопрос «что у клиента стоит, где именно и как оно связано с остальным».
Ключевое слово — связи. Список серийников в Excel это ещё не CMDB. CMDB начинается там, где видно: этот сервер стоит в этой стойке, на нём крутится вот эта услуга, и если он ляжет — встанут вот эти клиенты.
Для большинства сервисных компаний полноценная CMDB по ITIL избыточна. Нужен её практический минимум: карточка объекта обслуживания, привязанная к клиенту, договору и истории работ.
Что заносить в учёт
Минимально полезная карточка единицы оборудования:
- что это — тип, модель, серийный номер;
- чьё и где — клиент, адрес, конкретное место на объекте;
- по какому договору обслуживается и с каким SLA;
- даты — установка, окончание гарантии, последнее и следующее ТО;
- история работ — все заявки по этой единице.
Что НЕ надо тащить на старте: сотню полей «на всякий случай». Карточка, которую лень заполнять, не заполняется — и учёт умирает через месяц. Начните с пяти полей, добавляйте новые, только когда конкретно упрётесь.
Главное — связать оборудование с заявками
Отдельный реестр техники бесполезен. Ценность появляется, когда заявка заводится не «на клиента», а на конкретную единицу оборудования. Тогда сразу становится видно:
- вся история по этому агрегату — что уже чинили и чем закончилось;
- какая техника ломается чаще остальных (кандидат на замену, а не на бесконечный ремонт);
- какой клиент съедает больше всего выездов и почему;
- что на гарантии, а что вы чините за свой счёт по недосмотру.
В Tikkee объекты обслуживания живут в карточке клиента вместе с договорами, а заявки привязываются к конкретной единице — история собирается сама, без отдельной таблицы.
Как начать без больших вложений
Не пытайтесь описать весь парк за один заход — этот проект гарантированно умрёт на второй неделе. Работает инкрементальный подход:
- Заведите карточки только на технику ключевых клиентов — тех, где больше всего заявок;
- Дальше заносите единицу в момент первого выезда на неё: инженер и так на объекте, добавить карточку — минута;
- Через квартал у вас описано то, что реально обслуживается, а не мёртвый архив;
- Плановое ТО подключайте, когда карточки уже есть — иначе планировать нечего.
Принцип тот же, что с базой знаний: наполняется по ходу работы, а не отдельным героическим проектом.
Что это даёт в деньгах
Учёт оборудования — не бюрократия ради галочки, он окупается конкретными вещами:
- меньше повторных выездов — инженер едет, зная модель и историю, и берёт нужную запчасть сразу;
- плановое ТО вместо аварийных работ — дешевле для вас и спокойнее для клиента;
- аргументы в спорах: видно, что и когда делали;
- основание поднять цену — вы показываете клиенту, сколько реально стоит его парк в обслуживании;
- гарантийные случаи не оплачиваются из вашего кармана по забывчивости.