Zum Inhalt springen
Keine Parallelwelt.
Ein kontrollierter Übersetzungs- und Integrationslayer zwischen Ihren Systemen.
Zehn Kapitel – von den Menschen und ihrem Ansatz bis zum gemeinsamen nächsten Schritt.
01 Über uns
Operative Immobilienpraxis trifft Finanz-, Transformations- und Skalierungserfahrung. So verbindet CREMconnect Fachlogik, Technologie und wirtschaftliche Umsetzbarkeit.
Gründer · Geschäftsführung
Geschäftsführender Gesellschafter und Gründer. Immobilien- und Transformationsexperte mit über 20 Jahren Erfahrung – vom Handwerk und operativen Gebäudebetrieb bis zur strategischen Unternehmensführung. Als Handwerksmeister und Betriebswirt verbindet er technische Praxis, kaufmännische Perspektive und die Entwicklung von Methoden, Datenmodellen und digitalen Lösungen.
Immobilienbetrieb · Datenmodelle · Transformation
Mitgründer · Finanzen
Mitgründer und Gesellschafter. Finanz- und Transformationsexperte mit über 20 Jahren Erfahrung in Wirtschaftsprüfung, Corporate Finance und Unternehmensführung – von Big Four über börsennotierten Maschinenbau bis zu PE-finanzierten Technologieunternehmen. Er steht bei CREMconnect für wirtschaftliche Tragfähigkeit, Skalierung und die unternehmerische Perspektive hinter Technologie und Produkt.
Corporate Finance · Skalierung · Unternehmensführung
02 Unser Ansatz
Prozesse vor Werkzeugen.
Wir beginnen mit einem geschäftlich relevanten Problem und einem messbaren Ziel. Dann verbinden wir Rollen, Arbeitsschritte, Daten und Systeme zu einer durchgängigen Operations-Logik – anschlussfähig an Ihre bestehende Systemwelt.
Geschäftliches Ziel und messbaren Nutzen festlegen.
Ist-Prozess, Ausnahmen und Nebenwege aufnehmen.
Rollen, Datenobjekte, Übergaben und Systemgrenzen verbinden.
Priorisierten Prototyp früh in der Praxis prüfen.
Einführung, Datenübernahme und Verbesserung steuern.
03 Funktionsprinzip
ERP, CAFM, Tabellen, Dokumente und Fachanwendungen sprechen unterschiedliche Sprachen. CREMconnect legt fünf Ebenen übereinander: unten Ihr Bestand, in der Mitte ein gemeinsamer Kern und eine kontrollierende API, oben die Anwendungen und Menschen, die damit arbeiten. Jeder Zugang – auch KI – nutzt denselben Weg.
Grafik horizontal erkunden
Kontrollierter Rückkanal: Ergebnisse, Aufgaben und Analysen werden mit dem Bezug ausgegeben, den das führende Kundensystem erwartet. Ihre Begriffe bleiben, die Semantik dahinter wird gemeinsam.
Von oben nach unten gelesen. Ebene öffnen für Aufgabe, Beispiel und Stand.
Hier wird entschieden und gearbeitet. Menschen sehen Daten in ihrer gewohnten Sprache und geben frei, was ausgeführt werden soll.
Beispiel: Die Objektleitung bestätigt eine vorbereitete Prüfaufgabe.
Oberflächen und Prozesse – auch die Assistenzanwendung – sind gleichrangige Zugänge. Keine von ihnen besitzt eigene Daten oder eigene Regeln.
Beispiel: Dashboard, Fristenportal, BPMN-Prozess oder KI-Assistent zeigen dieselbe Zahl.
Der einzige Weg zu Daten und Fachfunktionen. Hier werden Identität, Mandant und Rolle geprüft, Fachregeln angewendet, Freigaben eingeholt und jede Aktion protokolliert.
Beispiel: „Verbrauch vergleichen“ ist eine Fachfunktion der API – das Portal und die MCP-Anbindung rufen exakt dieselbe auf.
MCP setzt hier an: Die MCP-Anbindung übersetzt Anfragen einer Assistenzanwendung in API-Aufrufe – mit denselben Rechten, ohne Nebenweg zur Datenbank. Möglichkeiten ansehen ↓
Das gemeinsame Kernmodell aus Ort, Technik und Organisation auf PostgreSQL. Mandantengrenzen und Berechtigungen reichen bis in die Datenbank; Versionen machen Änderungen nachvollziehbar.
Beispiel: Ein Aufzug hat eine stabile interne ID, auch wenn sich Kunden-ID oder AKS ändern.
Ihre Quellsysteme bleiben führend. Original, Herkunft und Quellschlüssel werden unverändert übernommen und auf den Kern gemappt.
Beispiel: Die Raumliste aus dem CAFM und die Vertragsdaten aus dem ERP landen am selben Gebäude.
Das Architekturprinzip
Sie ist der kontrollierte Weg zu Daten und Fachfunktionen. Menschen, Prozesse, Integrationen und KI nutzen denselben Regelraum.
04 MCP & Assistenz Zielbild / optional
Das Model Context Protocol (MCP) ist ein offener Standard, über den Assistenzanwendungen mit bereitgestellten Daten und Fachfunktionen sprechen. CREMconnect stellt dafür einen MCP-Server bereit, der als dünner Adapter auf der API sitzt. Was die Assistenz darf, entscheidet nicht MCP – sondern die Kontrollschicht.
05 Vom Bestand zur Wirkung
Kundendaten werden nicht in eine fremde Logik gezwungen. Herkunft, Schlüssel und Bedeutungen bleiben erhalten; das Mapping auf den gemeinsamen Kern wird nachvollziehbar geführt.
Originalbestand, Herkunft und Quellschlüssel unverändert aufnehmen.
Kundenschlüssel mit Ort, Technik und Klassifikation verbinden – mit fachlicher Freigabe.
Beziehungen prüfen, Versionen führen und fachliche Regeln anwenden.
Funktionen ausführen, Berechtigungen prüfen und Freigaben berücksichtigen.
Ergebnisse für Portale, Exporte und führende Systeme kundengerecht ausgeben.
Keine Einbahnstraße: Original, Herkunft, Mapping und Rückbezug bleiben nachvollziehbar. KI kann Zuordnungen vorschlagen; die fachliche Freigabe bleibt beim Menschen. Änderungen an führenden Systemen erfolgen nur über definierte Schnittstellen.
06 Datenmodell
Drei autoritative Strukturen werden getrennt geführt und über typisierte, zeitbezogene Beziehungen verbunden. Genau diese Trennung verhindert, dass Kundenpfade, Kataloge oder Prozesse später zur technischen Sackgasse werden.
Autoritative Struktur
Autoritative Struktur
Autoritative Struktur
Die interne ID eines Objekts ist unveränderlich. Kunden-IDs, AKS und externe Klassifikationen werden versioniert zugeordnet.
Ort, Technik und Organisation werden verbunden, aber nicht zu einem künstlichen Navigationsbaum vermischt.
Kataloge, Regeln und Zuordnungen tragen ihren Ausgabestand. Bewertungen lassen sich dadurch später neu einordnen.
07 FAC.ID & Pflichtenlogik (ähnlich der bekannten REG-IS-Logik)
Ein Aufzug braucht eine stabile interne Identität, ein sprechendes Kennzeichen und eine fachliche Klasse. Erst die saubere Trennung macht Pflichten, Fristen und Nachweise über Systemgrenzen hinweg belastbar.
Technischer Anker für Historie, Beziehungen und Ereignisse.
Lesbar für die Organisation und rückführbar in das Quellsystem.
Beschreibt die Anlagenart – nicht das konkrete Objekt.
Kundenobjekt
„Aufzug Haus B“ Kunden-ID · AKS · OrtFacility-Achse
FAC.ID Was ist es?Service-Achse
Serv-ID Was ist zu tun?Anwendbarkeit
Gebäudeart & Rechtsraum Welche Regeln gelten?Externe Regelwerkslogik
Pflicht · Tätigkeit · Frist Qualifikation · Regelwerk · RisikoFachliche Verlängerung
Eine lizenzierte, laufend gepflegte Wissensquelle kann nach einer Logik angebunden werden, die der bekannten REG-IS-Logik ähnelt. FAC.ID bleibt dabei eine externe, versionierte Klassifikation. Pflichten und Tätigkeiten werden auf konkrete Anlageninstanzen aufgelöst, ohne den externen Code zur internen Identität zu machen.
08 Standards & Kontrolle
Die Innovation liegt nicht in einem neuen Datensilo. Sie entsteht, weil vorhandene Daten, Regeln und Funktionen über offene Beschreibungen kontrolliert nutzbar werden – für Menschen, Systeme und neue Assistenzanwendungen.
Etablierter Datenbankkern mit relationalen Constraints, Transaktionen und portabler Datenbasis.
Maschinenlesbare Beschreibung von Daten, Relationen und Fachfunktionen statt proprietärer Punktkopplung.
Identität, Rollen und Mandantengrenzen werden bis in die Datenbank gedacht. Der konkrete Benutzerkontext ist Teil der Integration.
Regelstände, Zuordnungen und Nachweise bleiben historisch einordenbar; sensible Kernobjekte werden nicht unbemerkt überschrieben.
Fachprozesse lassen sich als BPMN beschreiben und über die API mit Aufgaben, Rollen und Freigaben verbinden.
Assistenzanwendungen nutzen bereitgestellte Fachfunktionen über denselben API- und Berechtigungsraum – ohne Nebenweg zur Datenbank.
Kontrolle bleibt im System
Ein neuer Zugang erhält keine neuen Befugnisse. Ob Portal, Prozess, Integration oder Assistenz: Jede Aktion folgt derselben Fachlogik und kann vor der Ausführung geprüft und protokolliert werden.
09 Fragen der IT
Architekturvertrauen entsteht nicht durch Schlagworte. Deshalb trennt CREMconnect technische Grundlage, laufende Integration und Zielbild – und konkretisiert Betriebs- sowie Schutzkonzepte je Einsatz.
Architekturgespräch vereinbarenQuell-IDs, Herkunft und Mappings werden mitgeführt. CREMconnect stellt einen gemeinsamen fachlichen Kern bereit, ersetzt aber nicht automatisch ERP, CAFM oder DMS. Welche Daten zurückgeschrieben werden, wird je Schnittstelle und Freigabe vereinbart.
Der Kern setzt auf PostgreSQL und maschinenlesbare API-Beschreibungen. Klassifikationen sind austauschbare Mappings statt fest eingebauter Identitäten. Export-, Übergabe- und Betriebsrechte werden dennoch konkret im Vertrag festgelegt – nicht als pauschales Versprechen.
Der vorgesehene Zugriff führt über dieselbe API wie bei anderen Anwendungen. Rollen, Mandantengrenzen, Prüfungen und Freigaben gelten weiterhin. Anbieter, Modellbetrieb und freigegebene Datenräume werden projektspezifisch festgelegt.
Die Zielarchitektur trennt PostgreSQL-Datenbank und Objektspeicher und kann in einer deutschen beziehungsweise europäischen Betriebsumgebung umgesetzt werden. Der verbindliche Standort, Sicherung und Wiederanlauf gehören in das konkrete Betriebskonzept.
Versionen, Gültigkeitszeiträume, Herkunft und Audit-Ereignisse sind Teil des Datenmodells. Für Nachweisketten werden fachliche Beendigungen statt unbemerkter Überschreibungen vorgesehen. Lösch- und Anonymisierungsregeln für Personendaten sind im jeweiligen Datenschutzkonzept zu konkretisieren.
PostgreSQL-Kern, Datenmodell und API-Prinzip bilden die technische Grundlage. Benutzerkontext, Betriebsumgebung und einzelne Prozess- oder Assistenzbausteine werden im Projekt integriert. Die Statuskennzeichnung dieser Seite macht diese Ebenen bewusst sichtbar.
10 Nächster Schritt
Für Technische Leitung, IT und Datenverantwortliche.