KPI качества поставки техники с инсталляцией: метрики и сбор

Что именно измеряем в проектах поставки и инсталляции

Поставка с инсталляцией - это не просто привезти технику. Обычно сюда входят доставка, распаковка и монтаж, подключение к сети и периферии, базовая настройка (учетки, домен, политики, драйверы), перенос нужных параметров, тесты, обучение на месте и ввод в эксплуатацию по акту.

Без KPI качество почти всегда становится предметом спора. Закупки смотрят на факт поставки и документы, ИТ - на работоспособность и соответствие ТЗ, пользователи - на то, что можно работать прямо сейчас. Одна и та же ситуация оценивается по-разному: для закупок все закрыто, а для ИТ это еще «не взлетело».

Метрики работают только тогда, когда они ловят типовые проблемы, которые чаще всего портят впечатление и бюджет:

• повторные выезды инженеров (и причины: не хватило данных, ошибка настройки, проблемы на площадке)
• доработки после сдачи (что пришлось переделать и почему это не сделали сразу)
• дефекты на приемке техники (упаковка, комплектация, внешний вид, базовые тесты)
• задержки и паузы (ожидание доступа, пропусков, готовности сети, решений со стороны заказчика)

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

Если вы внедряете технику в госсекторе, медицине или образовании, удобно фиксировать KPI одинаково для разных типов оборудования (ПК, моноблоки, серверы). Тогда сравнение по объектам становится честным и понятным.

Как выбрать единицы учета и не запутаться в цифрах

Чтобы KPI не превратились в спор «у кого цифры правильнее», сначала договоритесь, что именно вы считаете. Одна и та же проблема выглядит по-разному, если мерить по заявкам, по устройствам или по площадкам.

Выбирайте объект учета под смысл показателя. «Дефекты на приемке» логично считать на устройство (сколько единиц пришло с проблемой). «Повторные выезды» чаще понятнее на площадку или на заявку (сколько раз пришлось возвращаться в одну точку).

Объект учета: что подходит чаще всего

Обычно хватает 3-4 уровней:

• Заявка (тикет): удобно для сервиса и разбора причин повторных обращений.
• Устройство: подходит для дефектов, донастроек, замен и брака.
• Площадка (филиал, кабинет, серверная): показывает качество организации работ на месте.
• Проект: нужен для итоговой оценки и сравнения подрядчиков или команд.

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

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

И правило, на котором все держится: у каждого KPI должен быть один владелец и один источник данных. Например, «повторные выезды» фиксирует диспетчер в системе заявок, а «дефекты на приемке» подтверждает склад или комиссия приемки по чек-листу. Если источников два, цифры начнут расходиться уже на первой неделе.

Пример: при установке рабочих мест в госучреждении в одном городе дефекты считайте на устройство, а повторные выезды - на площадку. Так видно, где проблема в логистике, а где - в организации работ на месте.

KPI по повторным выездам: формулы и классификация причин

Повторный выезд - это визит инженера после закрытия работ по той же причине. Не путайте его с плановыми работами (например, расширение парка) и с новой проблемой, не связанной с исходной заявкой.

Чтобы не спорить о терминах, заранее зафиксируйте две вещи: что считается закрытием (акт, отметка в сервисной системе) и какой период вы считаете повтором (часто 7-30 дней).

Базовые метрики и формулы

Обычно хватает 2-3 показателей, которые легко сравнивать между объектами:

• Повторные выезды на 100 устройств = (кол-во повторных выездов за период / кол-во установленных устройств за период) x 100.
• Повторные выезды на 1 площадку = кол-во повторных выездов / кол-во площадок, где завершены работы.
• First Time Fix (FTF), % = (заявки, закрытые с первого визита / все заявки с выездом) x 100.

Пороговые значения зависят от типа техники и масштаба. При внедрении 200 рабочих мест на одной площадке даже 6 повторных выездов выглядят по-разному: это 3 выезда на 100 устройств, но 6 на одну площадку. Поэтому полезно вести оба среза.

Классификация причин: что считать и как не спорить

Причину повторного выезда фиксируйте в заявке обязательным полем (один выбор из справочника). Справочник должен быть коротким:

• Гарантийный дефект (подтвержденный отказ железа).
• Ошибка настройки/инсталляции (драйверы, домен, политики, ПО).
• Неготовность площадки (питание, сеть, доступ, пропуска).
• Изменение требований заказчика (попросили сделать иначе после закрытия).

Так вы отделяете качество работ от внешних задержек. В проектах интеграции (например, при поставке и установке ПК и серверов) это особенно важно: одна и та же цифра повторов может означать реальную проблему внедрения, а может - то, что на объекте не было сети.

Для сбора данных обычно достаточно дисциплины в одном месте. В каждой заявке должны быть: дата закрытия, признак повторного выезда (да/нет, со ссылкой на исходную заявку) и причина из справочника. Тогда KPI получается без ручных таблиц и бесконечных разборов.

Процент донастроек: как определить и измерять без споров

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

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

Как считать показатель

Самая понятная метрика:

Процент донастроек = (количество инсталлированных единиц, по которым была хотя бы 1 донастройка / общее количество инсталлированных единиц) x 100%.

Дополнительно полезны две «временные» метрики, чтобы видеть влияние на запуск:

• Среднее время донастройки (часы): сумма фактических трудозатрат по донастройкам / число донастроек.
• Задержка приемки из-за доработок (дни): дата плановой приемки минус дата фактической приемки, если причина отмечена как донастройка.

Единый словарь типов работ

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

Сбор данных делайте максимально простым: отдельный тип заявки в сервис-деске (например, «Донастройка после приемки») или отдельная строка в акте. Обязательные поля: серийный номер/инвентарный ID, объект, тип донастройки, причина (ошибка внедрения или изменение требований заказчика), время инженера, дата закрытия.

Пример: на объекте установили 40 рабочих станций. По 6 из них понадобилась донастройка доменных политик и ПО. Процент донастроек = 15%. Дальше уже видно, что проблема не в железе, а в согласовании политик безопасности до выезда.

Дефекты на приемке: что фиксировать и как считать показатель

Дефекты на приемке - это то, что вы видите и можете подтвердить сразу, до начала полноценной эксплуатации. Здесь важно договориться о терминах: дефект - это повреждение или неисправность изделия, а несоответствие ТЗ - ошибка в поставленной конфигурации или настройках (например, не тот объем RAM или неверный образ ОС).

В карточке приемки фиксируйте минимум: внешний вид, комплектацию, серийные номера и модели, базовые функциональные тесты и результат приемки (принято, принято с замечаниями, отказ в приемке).

Фотофиксация обязательна, иначе показатель превращается в мнение. К записи достаточно приложить 3-5 фото: общий вид, крупный план дефекта, стикер с серийным номером, упаковка (если есть следы удара) и экран с ошибкой (если проблема функциональная).

Считать удобно в двух разрезах:

• дефекты на 100 единиц = (кол-во дефектных единиц / кол-во принятых единиц) x 100
• доля отказа приемки = (кол-во единиц, по которым оформлен отказ / кол-во предъявленных к приемке) x 100%

Отдельно разделяйте транспортные повреждения и производственные дефекты. Первые обычно подтверждаются упаковкой и актом доставки, вторые - повторяемостью по партии и характером отказов. Если на объекте у части устройств не проходит тест питания, это похоже на дефект изделия. А если в спецификации стоит один SSD, а приехал другой - это несоответствие ТЗ и должно идти в отдельный показатель, не смешиваясь с браком.

Если вы работаете с отечественным производителем и интегратором вроде GSE.kz, раздельный учет помогает быстрее понять, где причина: логистика, сборка или комплектация проекта.

Сроки и паузы: KPI по времени без штрафов за чужие задержки

Сроки в проектах поставки и инсталляции часто «плывут» не из-за команды, а из-за доступа на площадку, готовности сети или электрики. Чтобы метрика была честной, измеряйте не только календарные дни, но и «чистое» рабочее время со стоп-часами.

Какие KPI по времени ставить

Обычно хватает трех показателей, которые легко объяснить и проверить:

• Соблюдение срока поставки, %: доля поставок, прибывших не позже плановой даты.
• Соблюдение срока завершения инсталляции, %: доля объектов, где «готовность к приемке» наступила не позже плановой даты.
• Lead time на площадке, часы или дни: от «прибытия на объект» до «готовности к приемке».

Lead time лучше считать в двух вариантах: календарный и «активное время работ» (без подтвержденных пауз).

Как учитывать паузы и убрать манипуляции

Пауза учитывается только с причиной и подтверждением. Например, инженер зафиксировал «ожидание доступа в серверную», а заказчик в тот же день подтвердил это в заявке или акте.

Типовые причины пауз: нет доступа, нет электропитания, не готова сеть, нет учетных записей, ожидание ответственного со стороны заказчика, ожидание разрешения на работы.

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

• дата заказа и плановая дата поставки
• дата отгрузки и прибытия на объект
• старт работ и готовность к приемке
• дата приемки
• интервалы пауз: начало, конец, причина, подтверждение

Пример: оборудование доставили в понедельник, работы начали во вторник, но 6 часов ушло на ожидание доступа и еще 4 часа - на выдачу учетной записи. Календарно срок выглядит «долгим», но активное время работ покажет реальную скорость команды и точку роста в подготовке площадки.

Стабилизация после внедрения: метрики первых 30 дней

После сдачи проекта главная проверка качества - как техника ведет себя в реальной работе. Полезно выделить период стабилизации: первые 7 дней (быстрые проблемы) и первые 30 дней (накопительный эффект).

Какие KPI считать в первые 7 и 30 дней

Эти показатели легко сравнивать между объектами и партиями, если заранее зафиксировать дату ввода в эксплуатацию:

• Доля закрытий без инцидента: % устройств, по которым не было обращений в первые 7 дней и отдельно в первые 30 дней. Формула: (устройства без инцидентов / всего устройств) x 100%.
• Обращения пользователей на 100 устройств: (кол-во обращений за период / кол-во устройств) x 100.
• Доля обращений из-за настройки, а не эксплуатации: % обращений, где причина - образ ОС, драйверы, политики, права, подключение к домену, сетевые профили, печать, корпоративные приложения.

Как собирать данные без споров

Ключевой принцип: каждое обращение должно однозначно связываться с конкретной поставкой.

Для этого в сервис-деске и в акте сдачи заведите обязательные поля: серийный номер, модель, площадка (адрес/код), дата ввода, ID заявки на установку, версия образа ОС, ответственный инженер.

Пример: на площадке установили 120 моноблоков. За 30 дней пришло 18 обращений, из них 11 - из-за настройки печати и прав в приложении. Это 15 обращений на 100 устройств, а доля обращений по настройке - 61%. Дальше шаги понятны: обновить типовой образ, дописать короткую инструкцию для пользователей и уточнить чек-лист приемки (например, проверка печати и входа в нужные системы до сдачи).

Организация работ и коммуникации: простые KPI без лишней отчетности

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

Минимальный набор KPI по коммуникации

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

Второй - время реакции на запрос заказчика в проекте (например, «нужен список портов», «подтвердите дату пусконаладки»). Заранее зафиксируйте правило: реакция - это первое осмысленное сообщение с планом действий, а не «приняли в работу».

Третий - доля работ, где окно согласовано вовремя (например, не позднее чем за 2 рабочих дня до выезда) и назначены контактные лица с обеих сторон.

Чтобы метрики собирались сами, заведите «журнал согласований» в той же системе, где живут задачи. Достаточно нескольких обязательных полей: объект, дата и окно работ, причина переноса (заказчик или подрядчик), время первого ответа, ответственные.

Как не превратить это в бюрократию

Оставьте 3-4 обязательных статуса по каждой заявке, чтобы всем было видно, где работа застряла:

• Запланировано (окно подтверждено)
• В работе (инженер на объекте)
• Завершено (акт или результат принят)
• На паузе (ждем заказчика, указана причина)

Пример: при установке рабочих станций в учебном корпусе перенос случился из-за отсутствия доступа в аудитории. Событие отмечают как «перенос по причине заказчика», и в следующем цикле заранее просят письменное подтверждение доступа. Метрика не наказывает, а убирает повторяющиеся сбои.

Как собирать данные: источники, обязательные поля и правила

Чтобы KPI не превращались в споры, договоритесь о простом принципе: один факт - одна запись в системе, и у записи есть минимальный набор обязательных полей. Тогда повторные выезды, донастройки и дефекты на приемке считаются одинаково на всех объектах.

Источники данных обычно уже есть. Заявки и выезды фиксируйте в сервис-деске. Движение техники и серийные номера - в ERP и складской системе. Контакты и согласования - в CRM. План и статусы работ - в проектных задачах. Критично не тащить все в одну ручную таблицу, а определить, где «истина» для каждого показателя.

Минимальные обязательные поля для любой заявки/акта/задачи:

• серийный номер (или список серийников) и модель
• площадка (адрес, корпус/этаж/кабинет) и заказчик/подразделение
• тип работ (инсталляция, диагностика, замена, донастройка)
• причина выезда (из единого справочника)
• результат (сдано, частично, перенесено) и дата/время

Самое важное - единый справочник причин. В нем должны быть отдельные коды для «повторный выезд», «донастройка», «дефект», «неготовность площадки» (например, нет электропитания, нет сети, нет доступа, не готово помещение). Тогда вы не штрафуете команду за чужие задержки, а видите реальную картину.

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

Фотографии, акты и чек-листы дают доказательность. Храните минимум: фото серийника и установки, подписанный акт/чек-лист приемки. Помогает понятное имя файла: дата, площадка, серийник, тип документа (например, 2026-01-31_Алматы_Площадка-03_SN12345_Акт).

Быстрый чек-лист KPI: 10 минут, чтобы понять, все ли под контролем

Если нет времени разбирать отчеты, раз в неделю сделайте короткую проверку по последним закрытым работам (например, за 7 дней). Она показывает, держатся ли метрики в норме или проблемы уже копятся.

Проверка за 10 минут

Отметьте пять вещей:

• Приемка оборудования: комплектация совпадает, серийные номера внесены, пройдены базовые проверки и это отражено в акте.
• Готовность площадки: есть электрика и сеть, доступ подтвержден, учетные записи и права выданы до выезда.
• Повторные выезды: доля выездов по одной и той же установке не выше 3% в неделю.
• Донастройки: работы после сдачи (права, политики, драйверы, сетевые параметры) не выше 7% установок.
• Дефекты на приемке: выявленные на месте проблемы (не стартует, повреждения, некомплект) не выше 1% единиц.

Чтобы цифрам можно было доверять, раз в месяц делайте аудит выборкой 5-10% установок: сверяйте акт, чек-лист, фото маркировки/серийника и факт работы (включение, сеть, базовая нагрузка).

Если пороги превышены

Запускайте корректирующие действия на 2 недели и смотрите динамику, а не «разбирайте виноватых»:

• разложите причины по категориям: площадка, логистика, образ/ПО, человеческий фактор, заводской брак
• уберите топ-2 причины: обновите чек-листы и обязательные поля (например, «учетка готова» до выезда)
• введите стоп-правило: без подтверждения готовности площадки выезд не планируется
• проведите короткое обучение по типовым ошибкам и закрепите ответственных
• через 14 дней пересчитайте те же 3 KPI и сравните результат

Пример из практики: как KPI работают на реальном объекте

Школа получает партию техники для нескольких кабинетов: 28 настольных ПК и 6 сенсорных моноблоков, плюс настройка сети, учетных записей и печати. Поставка и инсталляция идут в один день, но часть работ зависит от местного администратора и доступов.

Чтобы потом не спорить, учет ведут не только по «объекту», а по кабинетам. У каждого кабинета есть карточка работ: перечень оборудования, серийные номера, ответственный, время начала и завершения, статус (доставлено, установлено, настроено, принято). Серийники снимаются при распаковке и сразу попадают в акт и в реестр, а фото шильдика и рабочего стола с именем ПК прикладываются как подтверждение.

На объекте чаще всего всплывают три проблемы: нет доступа в сеть (или «порт не поднят»), не готовы учетные записи и права (домен, почта, доступ к системам), переносы по времени (кабинет занят, уроки, прием).

Метрики помогают отделить качество работ от внешних задержек. По итогам месяца картина может выглядеть так:

• First Time Fix: 90% кабинетов закрыты без повторного выезда
• Процент донастроек: 18% рабочих мест потребовали дополнительной настройки (драйвер принтера, прокси, доменная политика)
• Дефекты на приемке: 2% единиц с замечаниями (битый пиксель, повреждение упаковки, некомплект)

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

После первого месяца команда обновляет чек-лист приемки по кабинетам, дополняет типовую сборку (например, заранее включить нужные политики и драйверы) и проводит короткое обучение инженеров по частым кейсам. В проектах производителя и интегратора вроде GSE.kz это обычно снижает долю донастроек и повышает First Time Fix на следующей поставке.

Частые ошибки при внедрении KPI и как их избежать

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

Вторая ошибка - считать только проценты и забывать про объем. 10% повторных выездов при 10 заявках и 10% при 1 000 заявках - это разные истории. Всегда фиксируйте и долю, и абсолют: сколько выездов, сколько устройств, сколько объектов, за какой период.

Третья ошибка - нет единого словаря. Один инженер считает донастройкой установку драйвера, другой - только изменения в BIOS, а третий - любую просьбу пользователя после сдачи работ. То же с повторным выездом: он может быть гарантийным, из-за изменения требований, из-за брака или из-за отсутствия исходных данных.

Четвертая ошибка - нет связи между устройством и заявкой. Если в актах и тикетах не указан серийный номер, потом сложно доказать, что именно с этим ПК, сервером или моноблоком был инцидент и почему он возник.

Рабочий способ поправить ситуацию за 1-2 недели:

• разделите метрики на проектные (поставка, монтаж, сдача) и сервисные (инциденты после сдачи) и не склеивайте их в один показатель
• введите четкие определения: что такое повторный выезд, донастройка, дефект на приемке, какие причины допустимы
• обновите шаблоны актов и чек-листов: обязательны серийник, ID заявки, причина, кто инициировал, дата и результат
• настройте простой контроль качества заполнения: 10-минутная проверка выборки раз в неделю
• согласуйте знаменатели: процент донастроек от чего считаем (устройств, визитов, объектов) и закрепите это в регламенте

Следующие шаги: как запустить KPI за месяц и закрепить процесс

Начните с простого: договоритесь о терминах. Одна страница с 6-8 показателями, формулами и правилами учета обычно полезнее любой «красивой панели».

Дальше - план на 4 недели: сначала собрать данные, потом проверить, что их можно сравнивать, и только после этого делать выводы.

План на месяц

• Неделя 1: утвердите список KPI и определения. Например, что считается повторным выездом (любой визит после закрытия заявки или только по вине исполнителя), что такое «донастройка», когда фиксируется дефект на приемке.
• Неделя 2: добавьте обязательные поля в сервис-деск и шаблоны актов. Минимум: площадка, серийный номер, дата, причина работ, кто инициировал, результат, фото/примечание при дефектах.
• Неделя 3: запустите пилот на 1-2 площадках. Проверьте качество данных: нет ли «прочих причин», пустых полей, разных названий одной и той же проблемы.
• Неделя 4: проведите первый разбор причин и назначьте корректирующие действия. Фиксируйте не только цифру, но и решение: обновить чек-лист, изменить упаковку, добавить шаг проверки, дообучить инженеров.

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

Закрепить процесс помогает один владелец метрик и регулярный 30-минутный ежемесячный разбор. Если исполнитель ведет полный цикл (поставка, инсталляция, поддержка), как это делает GSE.kz - производитель и системный интегратор в Казахстане - проще связывать дефекты на приемке, повторные выезды и реальные причины в одну цепочку, а не спорить о том, «чья вина».