Стоимость простоя рабочего места: расчет и модель на 1 лист

Что такое простой и зачем считать его стоимость

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

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

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

Чаще всего по итогам расчета решают:

• какой SLA по времени восстановления оправдан для разных подразделений;
• где важнее заменить технику, а где достаточно улучшить поддержку и процессы;
• какие рабочие места критичны (фронт-офис, регистратура, касса), а какие выдерживают более длинные простои;
• стоит ли вкладываться в резервные каналы, запасные ПК и стандартные образы.

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

Из чего складывается стоимость простоя

Стоимость простоя рабочего места почти никогда не равна только зарплате сотрудника за «пустое» время. Это удобная нижняя граница. В реальности простой тянет за собой потери в услугах, очереди и качестве.

1) Прямые потери: оплачиваемое время без результата

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

2) Потери услуги: недооказанные операции и «упущенная выручка»

Если сотрудник производит измеримый результат (приемы, сделки, заявки, операции в системе), простой превращается в недовыпуск. В госоргане это меньше обработанных обращений, в банке - меньше проведенных операций, в клинике - сорванные записи.

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

3) Очередь и задержки: эффект домино

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

4) Риски качества: ошибки и повторная работа

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

5) Косвенные эффекты: сроки, штрафы, репутация

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

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

Модель на 1 лист: какие строки и столбцы нужны

Одной страницы в Excel или Google Sheets достаточно, чтобы одинаково считать потери для разных подразделений. Лист должен быть понятен не только ИТ, но и руководителю: что произошло, сколько времени потеряли, сколько это стоило и почему.

Столбцы (что фиксировать по каждому инциденту)

Удобно вести учет построчно: одна строка = один инцидент (или один день простоя, если инцидент тянется).

• Дата (или период), подразделение, тип рабочего места (офис, касса/окно приема, инженерное, удаленное)
• Причина (ПК, сеть, учетная запись, ПО) и кто решал (ИТ, подрядчик, пользователь)
• Длительность инцидента (мин/час) и доля реально потерянного времени (0-100%)
• Стоимость часа сотрудника и коэффициент влияния на услугу/очередь
• Итоговые потери (авторасчет)

Как считать ключевые поля (простые правила)

Доля реально потерянного времени нужна, потому что не каждый инцидент равен полной остановке. Если сотрудник 30 минут ждал, но 20 минут отвечал на письма с телефона, то потери по времени будут 10/30 = 33%.

Стоимость часа берите по формуле: (оклад + обязательные начисления) / рабочие часы в месяц. Если не хотите спорить о точности, добавьте единый коэффициент накладных расходов (например, 1,2) и используйте его для всех.

Коэффициент влияния на услугу/очередь помогает быстро учесть «эффект домино», когда простой одного человека тормозит поток, повышает ожидание и создает повторные обращения. На старте достаточно 2-3 уровней, например: 1,0 для офисной роли без очереди, 1,3 для клиентского потока вне пика и 1,6-2,0 для пиковых часов.

Пошаговый расчет: от инцидента до суммы

Чтобы посчитать потери от простоя, не нужна сложная модель. Достаточно описывать каждый инцидент так, чтобы расчет легко повторялся для недели или месяца.

Пять шагов, которые можно сделать за 10 минут

1. Зафиксируйте длительность простоя и частоту. Берите время от момента, когда сотрудник реально не может выполнять основную работу, до восстановления. Если есть ожидание подтверждения или выдачи замены - это тоже простой.

2. Посчитайте стоимость часа сотрудника понятным способом. Самый простой вариант: (оклад + налоги/взносы + регулярные доплаты) / плановые рабочие часы в месяц. Если данных нет, используйте оклад/час как минимум и отдельно покажите «с полной нагрузкой».

3. Оцените долю потерянной выработки. Простой не всегда равен 100% потерь: иногда часть задач можно делать без системы. Возьмите коэффициент от 0 до 1 (например, 0,7, если 30% времени удается занять полезной работой).

4. Добавьте эффект на услугу или очередь. Это важнее зарплаты там, где есть клиентский поток или жесткие сроки: сколько заявок не обработали, сколько приемов сорвали, какая пеня или потеря выручки возможна.

5. Сведите в итог и сделайте 2-3 сценария. Базовая формула:

Время простоя x Стоимость часа x Доля потерь + Влияние на услугу.

Мини-пример

Оператор в сервисном окне простаивает 1,5 часа. Стоимость часа - 4 000 тг. Потери выработки - 0,8 (часть времени ушла на консультации без системы). База: 1,5 x 4 000 x 0,8 = 4 800 тг.

Дальше очередь: в среднем 6 клиентов в час, маржа - 700 тг за обращение. Потеря: 1,5 x 6 x 700 = 6 300 тг.

Итого: 11 100 тг за один случай. Для отчета удобно показать три варианта: оптимистичный (меньше потерь), базовый и пессимистичный (больше очередь, выше коэффициент потерь). Так проще обосновать требования к SLA, выбор уровня поддержки (например, 24/7) и необходимость запасных рабочих мест.

Как оценить влияние на услуги и очередь

Важно видеть не только зарплатные потери, но и то, что именно перестало происходить: приемы, звонки, оформление заявок, выдача документов. Это особенно заметно там, где работа идет потоком.

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

Небольшой набор формул, который обычно хватает держать под рукой:

• Неоказанные услуги = (средняя скорость, услуг/час) x (простой, часов)
• Потеря выручки или ценности = неоказанные услуги x ценность одной услуги (или штраф/риски)
• Рост очереди = неоказанные услуги за простой (они «переезжают» на позже)
• Дополнительное ожидание = рост очереди / фактическая скорость после восстановления
• Поправка на пик = простой в пике x коэффициент 1,3-2,0 (по загрузке)

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

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

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

Пример: в сервисном окне обычно обслуживают 6 клиентов в час. Если одно место не работало 40 минут в пиковое время, это около 4 клиентов, которые перейдут в очередь. Дальше вы уже считаете, сколько времени потребуется, чтобы их «догнать», и что это сделало с ожиданием и качеством сервиса.

Где взять данные без сложной аналитики

Чтобы оценить потери, не нужно строить большой BI-отчет. Достаточно нескольких простых цифр из источников, которые уже есть почти в любой компании.

Источники данных, которые обычно уже под рукой

Начните с Service Desk или хотя бы журнала заявок (почта, чат, Excel). Там обычно есть дата и время обращения, тип проблемы и комментарий о результате. Если есть мониторинг (доступность сети или серверов), он помогает подтвердить массовые простои и увидеть, когда «упало» и когда «поднялось». Полезен и короткий разговор с руководителем подразделения: он быстро отделит инциденты, которые реально останавливали работу, от тех, что были просто «неудобством».

Если нужно зафиксировать данные быстро, соберите минимальный набор за 2 недели:

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

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

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

Не обсуждайте конкретные оклады. Возьмите среднюю стоимость часа по роли или подразделению (ФОТ + налоги, деленное на рабочие часы). Для базовой модели обычно достаточно 3-5 ролей. Это снижает споры и ускоряет согласование.

Причины простоя лучше группировать крупно, чтобы потом видеть, где основные потери: ПК (железо), ОС и обновления, сеть и Wi‑Fi, учетные записи и доступы, периферия (принтер, сканер, касса). Например, в сервисном окне поликлиники один «падающий» сканер может давать меньше минут простоя, но больше жалоб из-за очереди. Поэтому категорию полезно фиксировать отдельно.

Сценарии: как показать эффект от улучшений

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

3 варианта, которые легко сравнить

Сведите их в одну таблицу:

Эффект от сокращения MTTR считайте прямо: если среднее восстановление было 90 минут, стало 45, то потери на один инцидент уменьшаются в 2 раза. Дальше умножьте на число инцидентов в месяц.

Эффект от снижения частоты инцидентов еще нагляднее: если было 4 инцидента в месяц, стало 2, то потери по этой причине падают на 50% даже без изменений MTTR.

Как показать окупаемость без «магии»

Сведите результат в «экономия в месяц» против «стоимость меры» и покажите срок окупаемости. Например: ускорение поддержки (доп. смена, запасные рабочие места, 24/7 для критичных точек) дает экономию 1,2-1,8 млн тг/мес при затратах 0,9 млн тг/мес. Обновление ПК снижает инциденты и дает 0,8-1,4 млн тг/мес экономии при разовой закупке.

Чтобы не обещать невозможное, используйте диапазоны:

• MTTR: «от 60 до 40 минут», а не «будет 37 минут»
• Частота: «минус 20-40%», а не «инцидентов не будет»
• Потери: «минимум, базовый, максимум»
• Отдельно отмечайте, что в пиковые часы влияние на очередь выше

Пример: простой рабочего места в сервисном окне

Контекст: сервисное окно в госоргане или банке. Оператор работает с 09:00 до 18:00, пик по очереди - с 10:00 до 12:00 и с 15:00 до 17:00. В пиковые часы любой сбой сразу отражается на ожидании клиентов и количестве жалоб.

Возьмем модель на 1 лист и подставим простые числа:

• Стоимость часа сотрудника (зарплата с начислениями) - 3 500 KZT/час
• Производительность - 6 клиентов в час
• Коэффициент влияния на услуги (очередь, жалобы, срыв сроков) - 1,6 в пик и 1,3 вне пика
• Повторяемость за месяц - по факту обращений в поддержку

Инцидент 1: «не загружается ПК» (пик). Диагностика и замена занимают 45 минут (0,75 часа). Прямая потеря по времени: 0,75 x 3 500 = 2 625 KZT. С учетом влияния на услуги: 2 625 x 1,6 = 4 200 KZT.

Инцидент 2: «нет доступа к системе» (вне пика). Сброс пароля, проверка прав и вход занимают 25 минут (0,42 часа). Прямая потеря: 0,42 x 3 500 = 1 470 KZT. С учетом влияния: 1 470 x 1,3 = 1 910 KZT.

Итого за день, если оба случая произошли один раз: 4 200 + 1 910 = 6 110 KZT. Если за месяц «не загружается ПК» случается 3 раза, а «нет доступа» - 8 раз, то стоимость составит: 3 x 4 200 + 8 x 1 910 = 27 880 KZT.

Дальше вывод лучше формулировать как требование к качеству, а не как пожелание:

• Для «не загружается ПК»: нужен быстрый обмен на резервное рабочее место и стандартный образ для восстановления (цель - до 15-20 минут в пик).
• Для «нет доступа»: нужна понятная процедура и время реакции поддержки, плюс контроль типовых причин (цель - до 10-15 минут).

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

Как использовать расчет для SLA и требований к сервису

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

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

Обычно хватает трех метрик, которые можно измерять без сложных систем:

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

Дальше переводите метрики в деньги. Если час простоя стоит 12 000 тенге, разница между восстановлением за 2 часа и за 6 часов - это 48 000 тенге на один случай. Такие числа удобно прикладывать к заявке на бюджет или к изменениям в договоре поддержки.

Как выбирать приоритеты и формулировать требования

Не пытайтесь «улучшить все». Возьмите статистику за 1-3 месяца и посчитайте потери по причинам. Обычно топ-3 причины дают большую часть суммы (например, сбой ОС, отказ диска, проблемы с учеткой). На них и ставьте самые жесткие цели.

Минимальный набор формулировок в требованиях:

• Для критичных ролей: реакция до N минут, восстановление до M часов.
• Для некритичных: реакция до N часов, восстановление до M дней.
• Эскалация: если не восстановили за M часов, подключается следующий уровень.
• Отчетность: ежемесячно число инцидентов, среднее время восстановления, сумма потерь по модели.

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

Типичные ошибки и как их избежать

Расчет чаще всего «не работает» в переговорах по простой причине: цифры выглядят правдоподобно, но не отвечают на вопрос, что именно бизнес потерял.

Ошибки, которые дают неверную сумму

• Путать «время инцидента» и реально потерянное время. Инцидент мог длиться 2 часа, но сотрудник 40 минут работал офлайн. В модели фиксируйте потерянные минуты по процессу, а не время жизни тикета.
• Считать только зарплату и забывать про влияние на услугу. Если из-за одного рабочего места выросла очередь, потери идут не только от этого сотрудника, но и от задержек, срывов сроков и повторных обращений.
• Ставить коэффициенты «на глаз». Коэффициенты типа «потеря эффективности 0,7» должны пройти короткую проверку. Пяти минут разговора с руководителем подразделения часто достаточно.
• Смешивать разные роли в одну среднюю цифру. У оператора колл-центра и у бухгалтера разная стоимость часа и разная цена ошибки. Разбейте хотя бы на 2-3 группы ролей.
• Не учитывать пиковые часы и критические процессы. 30 минут простоя в 10:00 и в 16:50 могут стоить по-разному, особенно если есть закрытие смены, платежные окна, прием граждан.

Как быстро «приземлить» расчет

Проверьте модель на одном реальном случае. Например: из-за сбоя ПК сотрудник не мог работать 45 минут, но 15 минут принимал заявки вручную. Сравните «45 минут по тикету» и «30 минут чистой потери плюс клиенты, которые не успели попасть в окно и пришли повторно». Такой пример делает сумму понятной и защищаемой.

Чеклист и следующие шаги

Для первой оценки не нужен идеальный учет. Достаточно честной, понятной модели, которую потом можно уточнять и сравнивать по месяцам.

Чеклист на 10 минут

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

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

Минимальный пилот и регулярное обновление

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

Раз в месяц обновляйте модель одним и тем же способом:

• собрать 5-10 самых частых инцидентов и их длительность;
• обновить стоимость часа (если менялись ставки или графики);
• зафиксировать последствия для услуг (задержки, переносы, рост очереди);
• отметить, что изменилось в ИТ (обновления, замена ПК, новые правила поддержки);
• сравнить итог с прошлым месяцем и кратко записать причину изменений.

Следующий шаг для разговора с ИТ и руководством - обсуждать меры, которые прямо снижают простой: стандартные конфигурации ПК или моноблоков, запасной фонд, регламент замены, понятная поддержка 24/7. Если вы подбираете железо и поддержку под такие требования, полезно сверяться с тем, как это делают системные интеграторы и производители на месте. Например, GSE.kz (gse.kz) работает с инфраструктурой и рабочими местами для организаций в Казахстане, и ваша модель простоя помогает заранее сформулировать, где нужна максимальная надежность, а где достаточно базового уровня сервиса.