Operative und finanzielle Daten bilden die belastbare Ausgangsbasis.
← Project Lab
01 · OPEN CPM · ENGINEERING DEEP DIVE
EPIP
Enterprise Planning & Integration Platform
Unternehmensplanung und Datenintegration.
Offen, modular und für KMU beherrschbar.
SYSTEM IDEA
EPIP verbindet die Idee eines offenen CPM-Systems mit einer PostgreSQL-basierten Daten- und Integrationsplattform. Planung, fachliches Modell und Workflows sollen konfigurierbar bleiben; Frontends werden kundenabhängig angebunden.
01DATASources · Actuals
→02INTEGRATEStage · Transform
→03MODELDimensions · Rules
→04PLANBudget · Forecast
→05ANALYZEKPI · Semantic
→06DECIDEReview · Action
01 · Vision
CPM-Fähigkeiten ohne starre Suite.
EPIP ist als offene Plattform für kleine und mittlere Unternehmen gedacht, die Planung, Reporting und Datenintegration strukturiert verbinden wollen, ohne das fachliche Modell oder die Oberfläche an einen einzelnen Hersteller zu binden.
Der Ansatz trennt bewusst fachliche Steuerung, Datenplattform und Präsentation. Dadurch kann dieselbe Plattform unterschiedliche Organisationen, Planungsmodelle und Frontends unterstützen.
02 · Open CPM
Actual. Budget. Forecast. Scenario.
Planwerte werden entlang der fachlichen Dimensionen erfasst und versioniert.
Rollierende oder periodische Erwartungen ergänzen die Jahresplanung.
Alternative Annahmen und Versionen bleiben getrennt vergleichbar.
ZIELARCHITEKTURDer CPM-Layer ist die fachliche Weiterentwicklung des bereits aufgebauten technischen EPIP-Fundaments.
03 · Open Business Model
Ein Meta-Modell statt eines starren Kontenplans.
EPIP soll die technische Struktur stabil halten, während das fachliche Modell je Unternehmen konfiguriert wird. Damit kann dieselbe Plattform Finance-, Sales-, Projekt- oder operative Modelle tragen.
↓
Planung und Ist-Vergleich entlang der Finanzstruktur.
Absatz, Umsatz und kommerzielle Szenarien.
Projekt-, Kapazitäts- oder Leistungsplanung.
Designprinzip: offen heißt konfigurierbar – nicht schemafrei. Definitionen, Datentypen, Beziehungen, Gültigkeiten und Regeln benötigen einen kontrollierten Meta-Layer.
04 · Planning Model
Ist-Daten werden zum Ausgangspunkt für Versionen und Szenarien.
ACTUALIstobserved business data
↓BASELINEPlanungsbasisreference / assumptions
↙↘
BUDGETBudgetapproved planning version
FORECASTForecastrolling expectation
↘ ↙
SCENARIOBase · Best · Worst · Customalternative assumptions remain comparable
↓VARIANCE / MANAGEMENT VIEWCompare · Explain · Decide
PLANNING CONTEXT
Jeder Planwert braucht Koordinaten.
PERIODMonat · Quartal · Jahr
VERSIONWorking · Submitted · Approved
SCENARIOBase · Best · Worst · Custom
ORGANISATIONCompany · Unit · Cost Center
CURRENCYLocal · Group · Reporting
MEASUREAmount · Quantity · KPI
Diese Achsen sind ein konzeptionelles Zielbild für die CPM-Erweiterung und noch kein festgeschriebenes Produktmodell.
05 · Configurable Workflow Engine
Nicht der Prozess ist fest – seine Bausteine sind definiert.
01OPEN / INPUTEdit · Save
↓02SUBMITTEDValidate · Route
↓03REVIEWApprove · Return
RETURNED↺ Revision
↓04APPROVEDConfirm · Publish
↓05LOCKEDFinal · Audit
WORKFLOW DEFINITIONSTATESOpen · Review · Approved … TRANSITIONSSubmit · Return · Approve … ROLESPlanner · Controller · Management ACTIONSEdit · Validate · Lock · Comment RULESConditions · Four-eyes · Thresholds EVENTSNotifications · Deadlines · Escalation
Konfigurierbare Prozess-DNA
EXAMPLE
State + Role + Action + Rule → TransitionZIELARCHITEKTURDer Workflow-Layer soll Planungsprozesse konfigurierbar machen. Die Darstellung beschreibt die geplante Systemlogik – nicht einen bereits vollständig implementierten Workflow Designer.
06 · Integration
Das technische Fundament ist bereits modular gedacht.
SOURCEERP · CRM · Files · API
→STAGINGInbound / Raw
→TRANSFORMETL · Rules
→COREBusiness Data
→SERVICEAPI · Reporting · Semantic
Die bestehende Architektur trennt Staging, Kerndaten, Referenzdaten, Transaktionen, API, Reporting, Audit, Semantic und QA in eigene Verantwortungsbereiche.
07 · PostgreSQL Core
Vier Templates. Klare Datenrollen.
SCD2-fähig · Business Keys · Gültigkeit · Hash / Audit
Codes · Lookups · Kategorien · kontrollierte Wertebereiche
Konfiguration · Batch-Status · Prozesssteuerung · Audit
Append-only · Datum · Menge / Betrag · nachvollziehbare Herkunft
TECHNICAL FOUNDATIONPostgreSQL · pgvector · SCD2 · API · QA · Audit · Containerized Operations
08 · Semantic CPM
Von der Abweichung zum vergleichbaren Geschäftskontext.
Klassische CPM-Logik zeigt, was sich verändert hat. Der geplante Semantic-CPM-Layer soll zusätzlich helfen, ähnliche historische Situationen, relevante Geschäftsentitäten und Kontext im vorhandenen Datenbestand zu finden – ohne das relationale Modell zu ersetzen.
CLASSIC CPMActual · Budget · ForecastVersion · Scenario · Period · Organisation
↓VARIANCEWas hat sich verändert?SQL · KPI · dimensional comparison
↓EXPLANATION CONTEXTVergleichen · Einordnen · Weiter analysierenanalytical support – not automated business truth
SEMANTIC CPM QUESTION
„Welche früheren Situationen ähneln dieser aktuellen Planabweichung – und welche Geschäftskontexte waren damals relevant?“
ZIELARCHITEKTUR / RESEARCHSemantic CPM beschreibt eine geplante analytische Erweiterung. Ähnlichkeit liefert Vergleichskandidaten und Kontext – keine automatische Kausalität oder Entscheidung.
09 · Semantic Architecture
Drei analytische Ebenen. Eine gemeinsame Datenbasis.
Facts, Dimensions, Historisierung, Regeln, Actuals, Budget und Forecast bleiben die präzise fachliche Grundlage.
Vektorrepräsentationen ergänzen relationale Daten um Similarity Search und semantische Beziehungen. Die EPIP-Architektur sieht dafür einen eigenen semantic.*-Bereich vor.
Hyperdimensional Computing wird als Forschungsrichtung für hochdimensionale Repräsentationen, schnelles Matching und assoziative analytische Modelle untersucht.
BUSINESS OBJECTPlanabweichung / Geschäftssituation
→STRUCTURED VIEWSQL · Dimensions · Measures
+SEMANTIC VIEWVector / Hypervector Representation
→ANALYSISSimilarity · Ranking · Context
Prinzip: Semantic und HDC sind zusätzliche analytische Projektionen. Sie ersetzen weder SQL, SCD2 noch die fachlich definierten CPM-Strukturen.
10 · Quality & Governance
Planung braucht Vertrauen in Daten und Prozess.
Datenqualitätsregeln und Findings werden als eigener Systembereich behandelt.
Fachliche Regeln sollen nachvollziehbar und getrennt von Präsentation bleiben.
Ladevorgänge, Änderungen und Prozesszustände werden nachvollziehbar geführt.
Zugriffe erfolgen über definierte Rollen und Schnittstellen statt unkontrolliert auf Kerndaten.
11 · Open Interfaces
EPIP ist nicht das Frontend.
EPIP COREPlanning · Model · Workflow · DataAPI / defined interfaces
→Frontend-agnostisch by design: Metabase kann eine bevorzugte Open-Source-BI-Erweiterung sein, gehört aber nicht zum EPIP-Kern. Die Oberfläche richtet sich nach dem Kundenkontext.
12 · Deployment
Vom kleinen Setup zur betriebenen Plattform.
Entwicklung, Demonstration und kleine Installationen.
Gemeinsame Nutzung, APIs, Jobs und zentrale Datenhaltung.
Monitoring, Backup, Rollen, mehrere Fachbereiche und definierter Betrieb.
DESIGN PRINCIPLEEnterprise Planning & Integration – modular genug für KMU, offen genug für unterschiedliche fachliche Modelle.
Engineering Status
Fundament und Zielbild bewusst getrennt.
Bestehendes Fundament: PostgreSQL/pgvector, normierte Daten-Templates, SCD2, getrennte Schemas, API-/Integrationsansatz, QA/Audit sowie containerisierter Betrieb.
Zielarchitektur: offenes CPM-Modell, konfigurierbare Planning-Strukturen und Workflows sowie kundenabhängige Frontends. Research-/Ausbauebene: Semantic CPM verbindet klassische Abweichungsanalyse mit Similarity und historischem Kontext; HDC bleibt ausdrücklich Forschungsrichtung. Diese Funktionen werden als Entwicklungsrichtung dargestellt, nicht als bereits vollständig implementiertes Produkt.