Когда Google Sheets ещё нормальная система, а когда уже операционный риск

Коротко

• Таблицы — не зло: часто это лучший первый контур для управленческого учёта, если есть структура и владелец.
• Риск начинается не с размера файла, а с цены ошибки: платежи, маржа, остатки, закрытие месяца и решения собственника.
• Выходить нужно без революции: сначала слои, справочники, проверки и регламент, потом API, DWH, ERP или BI там, где это действительно нужно.

1. Таблицы — не зло, если они честно выполняют свою роль

Google Sheets хорош как быстрый слой проектирования управленческого учёта: можно увидеть реальные поля, договориться о справочниках, проверить формулы и быстро показать собственнику первую картину. Проблема появляется, когда черновик незаметно становится критичной системой без прав, журнала, проверки источников и регламента закрытия.

• таблица нормальна как прототип модели
• таблица нормальна как controlled ledger для малого контура
• таблица опасна, если по ней платят деньги, но её никто не принимает как систему

2. Уровень 1: ручная таблица как черновик учёта

На первом уровне таблица нужна, чтобы зафиксировать, какие данные вообще существуют: банк, продажи, склад, себестоимость, маркетплейсы, ДЗ/КЗ, авансы и ручные корректировки. Главный результат — не красивый отчёт, а список источников, обязательных полей и расхождений.

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

3. Уровень 2: таблица как управленческая система

Таблица становится системой, когда в ней есть слои: input, references, ledger, calculation, report, archive и audit log. Ввод отделен от расчёта, справочники защищены, отчёт не редактируется руками, а закрытие месяца идёт по checklist, а не по памяти одного человека.

• единый ledger операций
• защищённые справочники
• контроль обязательных полей
• архив периода после закрытия

4. Уровень 3: таблица + Apps Script + API + проверки

Если ручной ввод начинает ломать сроки и качество, таблицу можно усилить без полной миграции: загрузка банковских выписок, API кабинетов, scheduled refresh, дедупликация, validation rules, журнал ошибок и статус готовности отчёта. Apps Script здесь нужен не ради автоматизации ради автоматизации, а как слой контроля качества.

• source id и дедупликация
• проверка сумм и обязательных полей
• refresh status и журнал ошибок
• блокировка публикации при критичной ошибке

5. Уровень 4: когда надо уходить в DWH/ERP/BI

Переход нужен, когда таблица уже не держит объём, права, историю, SLA обновления или сложность связей. Если источников много, корректировки влияют на баланс, закрытие зависит от нескольких ролей, а отчёт должен регулярно обновляться без ручного копирования, пора проектировать DWH, ERP-логику или BI-витрину.

• нужна история изменений и роли
• источники обновляются по расписанию
• появляются регистры, партии, Дт/Кт, остатки и intercompany
• требуется регулярная витрина для команды

6. 12 признаков, что таблица стала риском

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

• непонятно, какая версия файла последняя
• формулы редактируют в отчётных листах
• нет владельцев справочников
• выписки и выгрузки копируются руками
• дубли ищутся глазами
• нет source id у операций
• закрытие месяца зависит от одного человека
• остатки, ДЗ/КЗ и авансы не связаны с P&L и ДДС
• ошибки исправляются молча
• нет журнала изменений
• права доступа шире, чем нужно
• отчёт публикуется без checklist приёмки

7. Как выходить без революции

Правильный путь — не сразу менять инструмент, а сначала описать правила. Сначала фиксируем источники, справочники, ledger, проверки, владельцев и критерии закрытия. Потом переносим только те части, где таблица уже объективно не справляется: загрузку, хранение истории, расчёт, BI-витрину или ERP-регистр.

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

Чек-лист

• таблица влияет на платежи
• таблица влияет на P&L или ДДС
• есть несколько источников
• нет source id
• нет журнала изменений
• нет владельцев справочников
• есть ручные копии
• закрытие зависит от одного человека
• формулы спорят
• нет checklist приёмки
• остатки не связаны с балансом
• ошибки исправляются без статуса

Дальше

По теме

• Что ломается в Google Sheets-управленке
• Почему баланс не сходится
• Согласованный P&L, ДДС и баланс
• История продаж, которую можно анализировать