Executive summary
- Таблицы - не зло: часто это лучший первый контур для управленческого учета, если есть структура и владелец.
- Риск начинается не с размера файла, а с цены ошибки: платежи, маржа, остатки, закрытие месяца и решения собственника.
- Выходить нужно без революции: сначала слои, справочники, проверки и регламент, потом API, DWH, ERP или BI там, где это действительно нужно.
Короткий digest для копирования
Когда Google Sheets еще нормальная система, а когда уже операционный риск Таблицы - не зло: часто это лучший первый контур для управленческого учета, если есть структура и владелец. Риск начинается не с размера файла, а с цены ошибки: платежи, маржа, остатки, закрытие месяца и решения собственника. Выходить нужно без революции: сначала слои, справочники, проверки и регламент, потом API, DWH, ERP или BI там, где это действительно нужно. Что проверить: таблица влияет на платежи; таблица влияет на P&L или ДДС; есть несколько источников; нет source id.
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-регистр.
- стабилизировать текущий файл
- выделить критичные правила учета
- перенести загрузку и проверки
- оставить таблицу как интерфейс там, где это дешевле и понятнее