# Что меняется, когда команда растет с 20 до 200 сотрудников?

- Канонический адрес: https://qrgate.az/ru/blog/poseshchaemost-pri-roste-komandy
- Markdown: https://qrgate.az/ru/blog/poseshchaemost-pri-roste-komandy.md
- Язык: ru
- Дата: 2026-07-15

В команде из 20 человек учёту посещаемости обычно не нужна никакая система: все друг друга видят, отсутствие очевидно, а конец месяца закрывает одна таблица. При 200 сотрудниках тот же способ перестаёт работать - и это ничья не вина. **Посещаемость в растущей компании** усложняется не линейно: она меняется скачками в определённых точках. В этой статье показываем, где эти скачки. Цифры иллюстративны и не являются ограничением какого-либо продукта.

## Что работает на 20 сотрудниках

В маленькой команде процесс держится на трёх вещах: все друг друга видят, память и прямое общение.

Всё три дёшевы и быстры. Когда кого-то нет, знают все; отгул согласуется устно; в конце месяца один человек заполняет таблицу - и работа сделана.

Важно: этот способ не *плох*. В своём масштабе он оптимален. Проблемы начинаются, только когда масштаб меняется.

## Первый скачок: «видеть» перестаёт работать

Первая критическая точка наступает, когда команда перестаёт помещаться в одну комнату. Обычно это около 30–40 человек или появление второго отдела либо этажа.

С этого момента вопрос «кто на месте?» перестаёт отвечать на себя сам. Кто-то должен спросить, кто-то ответить - и это становится ежедневной работой.

Именно на этом этапе появляется первая таблица. Сама по себе она не проблема; проблема в том, кто её заполняет.

## Второй скачок: источников становится больше

Вторая точка связана не с числом людей, а со **структурой**: появляется вторая точка, вторая смена или полевая команда.

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

В конце месяца возникает новая задача - сведение. Она растёт пропорционально числу *источников*, а не числу людей.

## Третий скачок: графики становятся разными

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

С этого момента единая база измерения становится непригодной. Сменная команда, измеряемая по 09:00, ежедневно выглядит опоздавшей, и отчёт теряет доверие.

На практике этот скачок упускают чаще всего - ведь число сотрудников не растёт, растёт разнообразие.

## Четвёртый скачок: отчёт нужен другим

В маленькой компании данные нужны одному человеку. С ростом - трём-четырём ролям: руководителям подразделений, операционному руководству, финансам.

У каждой роли свой вопрос, и один отчёт не устраивает никого. HR начинает готовить одни и те же данные в разных форматах - а это может занимать несколько дней в месяц.

## Картина в цифрах

| Измерение | 20 человек | 60 человек | 200 человек |
| --- | --- | --- | --- |
| Источников данных | 1 | 2-3 | 5-8 |
| Типов графиков | 1 | 2 | 3-5 |
| Аудиторий отчёта | 1 | 2-3 | 4-6 |
| Правок в конце месяца | 0-1 | 3-6 | 10+ |
| Вопрос «кого нет?» | Очевидно | Спрашивают | Выясняют |

Цифры приблизительны и различаются от компании к компании. Но направление всегда одно: при росте численности втрое нагрузка процесса растёт больше чем втрое.

## Почему рост не линейный

Причина арифметическая. Нагрузка пропорциональна не числу людей, а **числу связей**.

Между двумя источниками одна сверка, между пятью - десять. Поэтому при удвоении числа точек работа по сведению растёт не вдвое, а примерно вчетверо.

Та же логика касается типов графиков: каждый новый тип влияет на все существующие отчёты.

## Признаки скачка

Вместо теоретических расчётов полезнее смотреть на практические сигналы:

1. Сведение в конце месяца занимает больше дня.
2. Вопрос «что в этой ячейке?» повторяется каждый месяц.
3. Правки после расчёта зарплаты стали нормой.
4. Одна команда полностью вне отчётности (поле, смены, неполный день).
5. Руководители подразделений каждое утро пишут в HR.

Три признака из пяти означают, что скачок уже произошёл - просто процесс ещё не изменился.

## Когда и что менять

Самая частая ошибка - менять слишком поздно. Вторая по частоте - слишком рано: строить сложную систему для команды из 15 человек.

Практический триггер - не численность, а *событие*: открытие второй точки, появление второй смены или формирование полевой команды.

Если случилось одно из трёх, процесс нужно менять - даже если численность осталась прежней. Общая картина автоматизации - на странице [автоматизация учёта посещаемости](https://qrgate.az/ru/avtomatizaciya-ucheta-poseshchaemosti).

## Подготовиться до роста

Самый лёгкий переход - тот, который сделан *до* роста. Причина проста: при открытии новой точки внимание команды и так распылено.

Достаточно заранее записать три вещи: список типов графиков, порядок оформления отгула и то, кто какой отчёт и в каком формате получает.

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

## Что менять не нужно

При росте возникает желание поменять всё сразу. На практике это даёт обратный эффект.

От Excel отказываться не нужно - он остаётся форматом выгрузки. Существующее оборудование тоже не обязательно менять немедленно: гибридная модель нормальна, если источники сводятся в один отчёт.

По-настоящему менять нужно только одно: **где хранится основной массив данных**.

## Практический пример

Торговая компания на 28 человек вела посещаемость в одной таблице, и проблем не было. За год открылись две новые точки, численность выросла до 74.

Численность выросла примерно втрое, а работа конца месяца - примерно вшестеро: три файла, два разных графика, четыре разных требования к отчётности.

Переход компания сделала после открытия третьей точки. Их собственная оценка постфактум показательна: сделай они это при открытии второй, сэкономили бы около двух месяцев ручной работы. Критерии выбора собраны на странице [выбор программы учёта посещаемости](https://qrgate.az/ru/vybor-programmy-ucheta-poseshchaemosti).

## Критерий решения

Ситуацию описывают три вопроса: из скольких источников приходят данные; сколько типов графиков; сколько часов ручной работы занимает конец месяца?

Если первая цифра больше трёх, ваш процесс ограничен уже не численностью, а структурой. Пользу системы мы описали на странице [польза программы учёта посещаемости](https://qrgate.az/ru/polza-programmy-ucheta-poseshchaemosti).

## Работа с командой при переходе

На этапе роста изменение процесса требует не столько техники, сколько объяснений: команда привыкла к старому способу.

Обычно достаточно трёх пунктов: почему меняем, что понадобится от каждого и чем это отличается от прежнего порядка.

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

Вторая важная деталь - не ставить изменение на ту же неделю, что и открытие новой точки.

## Следующий шаг

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

QRGate ведёт посещаемость в контексте филиала, графика и роли, а новая точка не порождает отдельный файл. [Посмотреть возможности QRGate](https://qrgate.az/ru/preimushestva) или [рассчитать стоимость](https://qrgate.az/ru).

## Часто задаваемые вопросы

### Триггер - это численность?

Нет, это событие: открытие второй точки, появление второй смены или формирование полевой команды. Процесс меняется даже при прежней численности.

### Почему рост нагрузки не линейный?

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

### Нужна ли система команде из 20 человек?

Обычно нет, и это стоит сказать прямо. В маленькой команде видеть друг друга, память и прямое общение оптимальны в своём масштабе.

### Какое решение дешевле принять до роста, а не после?

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

## Связанные страницы

- Выбор программы учёта - [Markdown](https://qrgate.az/ru/vybor-programmy-ucheta-poseshchaemosti.md) | [HTML](https://qrgate.az/ru/vybor-programmy-ucheta-poseshchaemosti)
- Автоматизация посещаемости - [Markdown](https://qrgate.az/ru/avtomatizaciya-ucheta-poseshchaemosti.md) | [HTML](https://qrgate.az/ru/avtomatizaciya-ucheta-poseshchaemosti)
- Безопасность QR-системы - [Markdown](https://qrgate.az/ru/bezopasna-li-sistema-vhoda-po-qr-kodu.md) | [HTML](https://qrgate.az/ru/bezopasna-li-sistema-vhoda-po-qr-kodu)
- Разные рабочие часы - [Markdown](https://qrgate.az/ru/poseshchaemost-pri-raznyh-rabochih-chasah.md) | [HTML](https://qrgate.az/ru/poseshchaemost-pri-raznyh-rabochih-chasah)
- Польза программы учёта - [Markdown](https://qrgate.az/ru/polza-programmy-ucheta-poseshchaemosti.md) | [HTML](https://qrgate.az/ru/polza-programmy-ucheta-poseshchaemosti)
- Отслеживание рабочих часов - [Markdown](https://qrgate.az/ru/otslezhivanie-vremeni-prihoda-i-uhoda.md) | [HTML](https://qrgate.az/ru/otslezhivanie-vremeni-prihoda-i-uhoda)