Skip to content

Needs analysis — ERP backbone

Guide

Needs analysis — ERP backbone

GR-4: analyze the need before building. Owner: Operations (with Finance, when stood up). Precedes docs/erp-plan.md. Lean / plan-phase.

  • Need: one integrated view over the company’s resources — Finance & AI-usage, HR/workforce, Records/archive, Operations — without replacing the sources of truth (they stay in the repo + Notion). The ERP indexes and integrates.
  • Stakeholders: the Principal (oversight), Operations (run), Finance (ledgers), HR (roster), The Archives (records), and every unit (consumers).
  • Requirements:
    • R1 — Integrate, don’t replace; the repo/archive remain the system of record.
    • R2 — Stable entity IDs (agent, unit, venture, document, transaction, event) so things cross-reference (extends the CONTRIBUTING.md ID scheme).
    • R3 — Read-mostly surfacing first (the intranet already does this slice).
    • R4 — Finance + AI-usage ledgers with a cross-rate (docs/financial-system.md).
    • R5 — Low toil — automate upkeep (cf. scripts/archive-manifest.sh).
    • R6 — Least privilege & no secrets in repo (hr/policies/security.md).
    • R7 — Lean — earn each module with demonstrated need (360 review).
  • Constraints: plan-phase (build deferred); solo Principal; local-first; output-over-scaffolding.
  • Options: (a) keep the static intranet + grow surfaces on demand (recommended now); (b) add Supabase for dynamic data when chatter/ledgers need persistence; © full ERP app (deferred until demand is real).
  • Recommendation: continue the lean, repo-first path; add a real datastore only when a surface needs persistence (chatter, ledgers). Feeds docs/erp-plan.md.
  • Success criteria: the team uses the intranet daily; the record stays 0-drift; adding a surface doesn’t add manual toil.