Research Cases
INSODEMA untersucht nicht nur Systeme anderer Organisationen. Das eigene Ökosystem ist selbst ein Forschungsumfeld. Hier wird sichtbar, welche Fähigkeiten wir bewusst selbst bauen, welche extern bleiben, welche integriert werden und an welchen Fragen wir noch arbeiten.
Diese Seite dokumentiert keine fertige Universalantwort. Sie zeigt ausgewählte Evidenz aus einem laufenden Forschungsprozess – mit unterschiedlichen Reifegraden und bewusst unterschiedlichen Abhängigkeitsentscheidungen.
Interner Research Case
Wie viel einer typischen betrieblichen SaaS-Landschaft braucht eine Organisation tatsächlich – und was passiert, wenn die benötigten Teile mehrerer Produkte in einer kontrollierten Eigenarchitektur zusammengeführt werden können?
DOS entstand nicht aus dem Ziel, „ein ERP“ oder „eine Plattform“ zu bauen. Es entstand aus wiederkehrenden operativen Bedürfnissen: Projekte steuern, Entscheidungen nachvollziehen, Freigaben kontrollieren, Kontakte und Organisationen konsistent verwalten, technische Systeme verbinden, kommerzielle Abläufe abbilden, Zugriffe steuern und Informationen über Produkte hinweg zusammenführen.
Viele dieser Fähigkeiten werden traditionell über getrennte SaaS-Produkte bezogen. DOS untersucht praktisch, welche Ausschnitte davon INSODEMA tatsächlich benötigt, welche gemeinsam in einer eigenen Architektur sinnvoller sind und welche spezialisierten externen Systeme bewusst erhalten bleiben sollten.
Das Ergebnis ist keine These, dass Eigenbau grundsätzlich besser ist. Die eigentliche Evidenz liegt in der Fähigkeit, Abhängigkeiten einzeln zu bewerten und unterschiedliche Entscheidungen zu treffen.
System Sovereignty ist nicht die Abwesenheit von Abhängigkeiten. Es ist die Fähigkeit, sie bewusst zu wählen.
Research in Practice
Nicht alles im INSODEMA-Ökosystem hat denselben Reifegrad. Einige Fähigkeiten sind bereits im Einsatz, andere befinden sich in aktiver Forschung oder Entwicklung. Diese Unterschiede bleiben sichtbar, statt sie durch eine einheitliche Produktdarstellung zu verdecken.
Operational und Active Research bezeichnen unterschiedliche Evidenz- und Reifestufen – nicht unterschiedliche Qualitätsansprüche.
Operational Evidence
Die folgenden Beispiele zeigen Fähigkeiten, die innerhalb des INSODEMA-Ökosystems bereits genutzt werden oder eine belastbare operative Foundation besitzen. Sie sind keine Aufforderung, dieselben Entscheidungen in jeder Organisation zu treffen.
DOS führt Organisationen, Personen, Kontakte und Kommunikationskontext in einer gemeinsamen Authority zusammen. Dazu gehören strukturierte öffentliche Kontaktanfragen und zentrale Kommunikationskontexte.
Statt mehrere isolierte Werkzeuge für Kontaktverwaltung, Formulare und Kommunikationskontext zu betreiben, untersucht DOS, welche tatsächlich benötigten Fähigkeiten in einem gemeinsamen kontrollierten Modell sinnvoller zusammengehören.
Decision: Build / Integrate
Projekte, Module, Releases, Entscheidungen, Tracker, Repositories und Product Handoffs werden in DOS in einem gemeinsamen Kontext gesteuert.
Der Forschungswert liegt nicht darin, jedes Projektmanagement- oder Issue-Tracking-Produkt vollständig nachzubauen. Entscheidend ist, welche Ausschnitte tatsächlich gebraucht werden und ob eine gemeinsame Authority mehr Wert schafft als isolierte Oberflächen.
Decision: Build
DOS verbindet operative Entscheidungen, Freigaben, Reviews und produktübergreifende Handoffs in einem gemeinsamen Steuerungskontext.
Diese Fähigkeiten überlappen mit klassischen Task-, Approval-, Portfolio- und Management-Werkzeugen, ohne eines davon vollständig kopieren zu wollen.
Decision: Build
Produktkatalog, Preise, Subscriptions, Rechnungslogik, Zahlungszuordnung und kommerzielle Stammdaten werden innerhalb von DOS kontrolliert. Die externe Buchhaltungswelt wird dagegen nicht pauschal ersetzt.
INSODEMA baut die Commercial-Fähigkeiten, die im eigenen operativen Kontext benötigt werden, und hält einen kontrollierten DATEV-orientierten Übergang in die externe Buchhaltung als Integrationspfad.
Decision: Build + Integrate
INSODEMA benötigte eine zentrale Analytics-Fähigkeit für Websites und öffentliche Web-Oberflächen. Der tatsächlich benötigte Umfang war enger als der Funktionsumfang großer externer Analytics-Plattformen und ließ sich innerhalb der eigenen Governance gezielter definieren.
Analytics zeigt, dass eine externe Plattform technisch verfügbar sein kann, ohne automatisch die sinnvollste Authority für die tatsächlich benötigten Daten und Regeln zu sein.
Decision: Build
OPS benötigt spezialisierte Orts-, Karten- und Routingfähigkeiten. Diese Abhängigkeit wird nicht allein deshalb ersetzt, weil INSODEMA andere Fähigkeiten selbst baut.
Wo externe Infrastruktur eine spezialisierte Fähigkeit zuverlässig liefert und der Integrationsnutzen höher ist als der Eigenbauwert, kann das bewusste Beibehalten der Abhängigkeit die souveränere Entscheidung sein.
Decision: Retain / Integrate
ATLAS schafft eine gemeinsame Geographie- und Adress-Authority für INSODEMA-Systeme. Länder-, Postleitzahl-, Orts- und Straßenkontext können dadurch konsistenter strukturiert und über Systemgrenzen hinweg wiederverwendet werden.
Adressidentität und räumlicher Kontext müssen dadurch nicht in jedem Produkt neu erfunden werden. Wiederverwendbare Einsatzgebiete und gemeinsame geografische Referenzen sind Teil dieser Richtung.
Decision: Build + Integrate / Reuse
Active Research
Einige der interessantesten INSODEMA-Fragen befinden sich bewusst noch in aktiver Entwicklung. Sie werden als Forschungsrichtungen gezeigt, nicht als fertige Universalantworten.
NEXUS ist die zentrale Wissens-, Kontext- und Verbindungsschicht des INSODEMA-Ökosystems. Es soll freigegebene Informationen in Beziehung setzen, Muster und Abweichungen erkennen, Hypothesen kennzeichnen, frühere Erkenntnisse erneut prüfen und Forschungswege innerhalb definierter Grenzen verfolgen.
Research focus: Im Mittelpunkt steht eine Forschungsarchitektur, in der AI erklären und unterstützen kann, ohne automatisch operative oder strategische Autorität zu übernehmen.
Decision: Build / provider-neutral / policy-controlled AI
Sentinel untersucht, welche grundlegenden Fähigkeiten für Infrastrukturbeobachtung, Betriebsereignisse und technische Evidenz unter direkter organisatorischer Kontrolle sinnvoll sind.
Research focus: Der Forschungswert liegt in der bewussten Trennung zwischen eigener Beobachtungsfähigkeit und spezialisierten externen Infrastruktur- oder Monitoring-Diensten.
Decision: Build + deliberate external infrastructure
ShopperMatch untersucht Aktivität, Erreichbarkeit, Qualifikation, regionale Verfügbarkeit und Freshness statt bloßer Registrierungszahlen. Der Forschungswert liegt in der Frage, wann ein Datensatz noch operative Realität ist – und wann nur noch historischer Bestand.
Research focus: Im Mittelpunkt steht ein Datenmodell, das aktuelle nutzbare Kapazität von rein historischem Bestand unterscheiden kann.
Decision: Build / continuously refreshed operational data model
Dependency Decisions
Die Beispiele oben führen nicht zu einer pauschalen „Build everything“-Strategie. INSODEMA bewertet Fähigkeiten einzeln. Manche werden selbst gebaut, manche integriert, manche bewusst beibehalten, manche ersetzt und manche so gestaltet, dass Anbieter oder Modelle austauschbar bleiben.
Deterministische Engine
Regeln, Zustände, Scoring, Berechtigungen, Workflows und Fachlogik können komplexe operative Intelligenz abbilden und dabei testbar, reproduzierbar und auditierbar bleiben.
KI kann eine Entscheidung erklären, ohne die Entscheidung zu besitzen.
Die DOS-Rechnungsfunktionen sind an den relevanten gesetzlichen Rechnungs- und Dokumentationsanforderungen ausgerichtet und auf anschließbare externe Buchhaltungs-/DATEV-Prozesse vorbereitet. Dies ist keine Zertifizierungs- oder Rechtsgarantie.
Research Partnerships
INSODEMA Research Cases beginnen deshalb nicht mit einer Produktentscheidung. Sie beginnen mit einem realen Problem, einer Abhängigkeit, einem Systembruch oder einer Frage, deren Antwort noch nicht feststeht.