Когда на площадке 50 асиков, всё держится на двух людях и одном рабочем чате. Кто что привёз, где что стоит, кому сколько насчитали — всё в головах и в переписке. И это работает. До тех пор, пока устройств не становится 300.
На 300 асиках те же два человека и тот же чат, но они уже не вывозят. Задачи забываются, серийники путаются, клиенты ждут ответа по два дня, отчёты собираются неделю. Ломается не оборудование. Ломается всё, что вокруг него.
Дальше — про то, что именно перестаёт работать при росте хостинга и как мы у себя на площадке через это прошли.
Что нормально работает на маленьком объёме
На 50–100 устройствах хостинг можно вести почти вручную. Приёмка через сообщения — все помнят, кто что привёз. Биллинг в таблице — клиентов десять, пересчитать за час. Передача смены устно — в смене два человека, они и так в курсе. Отчёт для клиента — «напиши, если будут вопросы».
На этом этапе никто не думает о системе, потому что и так справляются. Проблема в другом: люди привыкают к этому режиму. И когда объём вырастает в три-пять раз, они пытаются работать так же. Только теперь это перестаёт работать.
Пять точек, которые ломаются первыми
Приёмка и склад. На 50 асиках ты помнишь каждое устройство. На 300 — уже нет. Клиент привёз партию, серийники записали в чат, потом чат уехал. Через месяц вопрос «где мой аппарат» — и никто не может быстро ответить. Если приёмка идёт через сообщения, оборудование начинает теряться. Не физически, а в учёте — что хуже, потому что спор с клиентом уже не разрешить.
Биллинг. Десять клиентов в таблице — терпимо. Пятьдесят, с разными тарифами, с индивидуальными условиями на электричество, с разным количеством устройств — это уже два дня работы каждый месяц. Плюс ошибки: перепутал клиента, подставил не тот объём потребления, сбился период. Каждая ошибка — спор. С ростом количества клиентов такие споры становятся регулярными.
Задачи. «Почисти партию в дальнем контейнере» — сказали устно. Кто взял? Сделал? Когда? На 50 устройствах это одна задача в день. На 300 — пять-семь задач на смену: чистки, перезагрузки, замены, клиентские запросы, плановые работы. Без записи в системе часть задач просто исчезает. Не потому что люди плохие, а потому что голова не резиновая.
Передача смен. Ночная смена увидела проблему, перезагрузила асик, написала в чат. Утренняя смена открыла чат — там 40 сообщений, половина не по делу. Информация потерялась на стыке. Чем больше площадка, тем чаще это происходит.
Отчётность. Когда потребление считается в одном месте, клиентская база живёт в другом, а список устройств — в третьем, сборка любого отчёта превращается в проект. Отчёт для клиента, отчёт для собственника, отчёт в ФНС — каждый требует ручной работы. Команда, которая должна заниматься площадкой, вместо этого сидит в таблицах.
Как мы закрыли это у себя через ROC
Мы столкнулись со всем этим, когда выросли с сотни устройств до нескольких сотен. Чаты и таблицы, на которых всё держалось, начали трещать. Перешли на ROC — вот что получилось по каждой из пяти точек.
Склад и приёмка. Приёмка и выдача оформляются документами в системе. Каждое устройство привязано к документу, видна история движения: когда приняли, куда поставили, когда выдали. Вопрос «где мой асик» закрывается за минуту — открыл карточку, показал клиенту.
Биллинг. Начисления формируются в системе — с учётом индивидуальных тарифов на электроэнергию для каждого клиента. У клиента есть личный кабинет, где видны выставленные суммы за период, потреблённая электроэнергия и история платежей. Клиент видит, за что платит. Споров стало заметно меньше.
Задачи. Задача фиксируется в системе с конкретным исполнителем, сроком и статусом. Видно, кто взял, кто просрочил, что в работе. Руководителю не нужно обзванивать смену, чтобы понять, что сделано, а что нет.
Передача смен. Инциденты и задачи живут в системе, а чат остаётся чатом. Утренняя смена открывает ROC и видит, что произошло за ночь: устройства, которые уходили в офлайн, открытые инциденты, задачи в работе. Ничего не теряется на стыке.
Отчётность. Отчёты формируются из тех данных, которые уже есть внутри: мониторинг, биллинг, потребление, инциденты. Общая сводка по хостингу, отдельный отчёт по каждому клиенту с фильтрацией по датам, выгрузка в ФНС в формате XML для оператора. Клиент-майнер может сам сформировать отчёт в реестр через личный кабинет. Команда перестала тратить дни на ручную сборку.
Когда пора внедрять систему
По нашему опыту — не тогда, когда уже горит. А когда появляются первые признаки.
Задачи начинают теряться. Клиенты спрашивают одно и то же, потому что им не отвечают вовремя. Отчёт собирается дольше, чем раньше. Споры по биллингу случаются чаще. Новый сотрудник не может войти в курс дела, потому что все процессы в голове у старого.
Если вы узнали хотя бы два-три пункта — скорее всего, площадка уже переросла ручной режим. И дальше будет только хуже, потому что объём растёт, а процессы остаются прежними.
Вывод
Рост — это хорошо. Больше устройств, больше выручка. Но без нормальных процессов рост превращается в хаос с бо́льшим количеством устройств. Оборудование масштабируется легко — поставил, подключил, запустил. Процессы вокруг него — нет. Их нужно выстраивать отдельно.
Через это прошли на своей площадке — операционку перевели в ROC. Площадка растёт, а команда не тонет.
Пользуемся этой системой уже давно. Если хотите посмотреть, как она работает — у них можно запросить демо или попробовать бесплатный пробный период 30 дней: https://t.me/platform_roc
Материал основан на опыте нашего объекта. У каждого хостинга своя специфика — процессы, масштаб, команда. Описанные решения могут работать по-разному в зависимости от условий.