Wie {yourcompany}os funktioniert: Prozessschicht, Implementierungsschicht, offenes Schema

Ein neues Projekt startet. Jemand tippt den Namen ins ERP. Jemand anderes legt den Ordner in SharePoint an. Eine dritte Person richtet das Postfach ein, und die Pläne landen im CDE. Fünf Systeme, jedes für sich einwandfrei, keines davon weiss, dass sie alle dasselbe Projekt beschreiben. Niemand hat das so gewählt. Es passiert, weil jedes Tool seine eigene Version der Wahrheit hält und Menschen die Integrationsschicht dazwischen sind.

{yourcompany}os ist die Schicht, die auf diesem Stack sitzt und ihn zusammenhält. Sie ersetzt nicht Ihr ERP, Ihre Ablage, Ihre E-Mail oder Ihre Spezialtools. Sie führt den Prozess über sie hinweg, sodass das Projekt einmal als Prozess existiert und jedes System erfährt, was es wissen muss.

Darunter ist diese Trennung Absicht: Der Prozess, die Systeme, mit denen er spricht, und das Datenmodell sind drei unabhängige Schichten statt eines Pakets. Dieser Artikel zeigt, was jede Schicht leistet, was sie Ihnen erspart und wie sich die drei verhalten, wenn sich ein Tool in Ihrem Stack ändert.

Was bleibt und was sich tatsächlich ändert

Bleibt genau so	Was sich ändert
Ihr ERP, CRM, Ihre Ablage, E-Mail und Ihr CDE	Ein Prozess spannt sich darüber, statt dass eine Person die Arbeit dazwischen trägt
Die Tools, die Ihre Leute schon kennen	Aufgaben erscheinen im bestehenden Postfach und Ablagesystem, nicht in einer weiteren Oberfläche
Wo Ihre Dateien liegen	Welche Version aktuell ist, beantwortet der Prozess, nicht eine Namenskonvention
IFC als Austauschformat	Darüber liegt ein Workflow-Schema, damit Anwendungen abfragen und prüfen können

Der praktische Gewinn davon, eine Schicht zu sein statt einer Plattform: Es gibt kein Migrationsprojekt. Nichts muss aus den Systemen herausgelöst werden, in denen es lebt, bevor der erste Prozess laufen kann. Deshalb geht ein erster Kernprozess in 1-2 Tagen live statt nach einem Rollout. Niemand muss auf eine neue Oberfläche umgeschult werden, weil Arbeit in die Tools geliefert wird, die Ihre Leute jeden Morgen ohnehin öffnen. Und wenn die eine Person, die alle Schritte kannte, in die Ferien geht oder kündigt, stecken die Schritte im Prozess statt in ihrem Kopf.

Die drei Schichten

Schicht	Was sie ist	Was sie Ihnen bringt
Prozess	BPMN-Definitionen, die Ihr Team schreibt und besitzt	Der Ablauf überlebt Toolwechsel und Personalwechsel und bleibt prüfbar
Implementierung	Eine Anbindung pro Capability-Gruppe (Ablage, ERP, E-Mail, KI, Checkout, ...)	Ein Anbieterwechsel ist eine Konfigurationsänderung, kein Umbauprojekt
Datenmodell	Das offene Schema, gegen das Entitäten und Prozesse lesen und schreiben	Sie können Ihre eigenen Daten einsehen und exportieren, ohne zu fragen

Die meisten Workflow-Tools werfen das in einen Topf: Der "Flow" ist die Integration ist die Datenstruktur, alles im selben No-Code-Canvas definiert und alles gemeinsam verloren, wenn Sie den Anbieter wechseln. {yourcompany}os hält die drei Teile unabhängig austauschbar. Genau das macht es unbedenklich, die Schicht auf einen Stack zu setzen, in den Sie schon investiert haben.

Schicht 1: Prozess - der Teil, der Ihre Tools überlebt

Ein Prozess in {yourcompany}os ist eine BPMN-Definition, kein Flow-Durchlauf. Dieser Unterschied klingt akademisch, bis sich ein Tool ändert. Ein "Flow-Durchlauf" (Power Automate, Zapier, die meisten iPaaS-Tools) ist eine einzelne Ausführung, die startet, ihre Sache macht und endet. Sie hat keine Erinnerung an sich selbst als Entität. Sobald ein Projekt über Wochen und mehrere Übergaben läuft, gibt es also nichts Dauerhaftes, auf das man zeigen könnte. Eine BPMN-Prozessdefinition ist ein Artefakt: Sie hat Phasen, Subprozesse, Gateways und einen Lebenszyklus, der jede einzelne Ausführung überdauert.

Was das im Alltag bedeutet:

• Eine Projektidentität statt fünf. Benennung, ERP-Erfassung (etwa in SAP oder bexio), Setup, Ausführung und Abschluss sind Phasen eines Prozesses. Jede berührt andere Systeme, alle zeigen auf dasselbe Projekt. Damit ist das Copy-Paste-Problem aus dem Einstieg strukturell gelöst. Die ganze Aufschlüsselung steht in Projekt erstellen: ein stabiler Anker über Ihre Tools.
• Lange Arbeit zerfällt nicht an den Übergaben. Setup und Abwicklung laufen als eigene Subprozesse über die Tools, bleiben aber Phasen des übergeordneten Prozesses und nicht eigenständige Skripte, die enden und vergessen.
• KI hilft, ohne die Führung zu haben. Ein Agent kann in einem Schritt recherchieren, klassifizieren oder Text entwerfen; Gateways und Menschen entscheiden, was als Nächstes passiert, und jeder Schritt wird protokolliert. Nützlich, wenn Sie einer Kundin oder einer Revision erklären müssen, warum etwas genehmigt wurde. Mehr dazu in Agentische KI im Unternehmenskontext betreiben.
• Sie können Ihren eigenen Prozess lesen. Weil es BPMN ist und nicht proprietäres Flow-JSON in einem SaaS-Canvas, ist die Definition lesbar und portabel. Eine neue Mitarbeiterin schaut auf das Diagramm, statt herumzufragen.

Tauschen Sie ein ERP, eine Ablage oder einen Viewer, ändert sich die Prozessdefinition nicht. Nur die Implementierung darunter wird anders aufgelöst - und das ist die nächste Schicht.

Schicht 2: Implementierungen - wo das Zusammenhalten tatsächlich passiert

Ein Prozessschritt nennt nie einen Anbieter. Er nennt eine Capability-Gruppe, und genau eine Implementierung ist konfiguriert, um diese Gruppe zu bedienen. Capability-Gruppen sind Dinge wie Ablage, E-Mail, ERP und Buchhaltung, CDE, Plananzeige, BIM, KI oder Checkout. Im Onboarding richten Sie jede benötigte Gruppe auf das, was Sie ohnehin betreiben, und die Prozesslogik bleibt identisch, unabhängig von Ihrer Wahl.

Heute verfügbare Implementierungen nach Gruppe:

• Ablage: Nextcloud, Google Drive, Microsoft 365 (SharePoint oder OneDrive über Microsoft Graph)
• E-Mail: Outlook / Microsoft 365, Gmail, Nuntly (für Projekt-Eingangspostfächer und Systemversand)
• ERP / Buchhaltung: bexio (Adressen, ERP, Buchhaltung)
• CDE: Trimble Connect
• Plananzeige / BIM: interne Engine oder iolabs (Plan-Viewer), abstractBIM (BIM und IFC)
• KI: Infomaniak AI (Schweizer Hosting, Standard), OpenAI, Anthropic, Google Gemini oder Ihr eigenes Modell als BYO LLM
• Checkout / Zahlungen: Stripe

Die vollständige Mechanik steht in Implementierungen: Kundensysteme konkret anbinden.

Daraus folgen zwei Dinge, die man erst nach zwei Jahren richtig schätzt:

1. Ein Systemwechsel ist eine Konfigurationsänderung, kein Umbauprojekt. Ihre Firma wechselt von Nextcloud zu SharePoint oder wegen einer Preisänderung den KI-Anbieter. Der Prozess, der "Ablage" oder "KI" als Capability nutzt, läuft unverändert weiter. Vergleichen Sie das mit einem No-Code-Flow, in dem der Anbieter in jedem Knoten verdrahtet ist.
2. Ein fehlendes System ergänzt, es blockiert nicht. Hat etwas in Ihrem Stack noch keine Implementierung, wird eine für diese Capability-Gruppe ergänzt, ohne den Prozess neu zu entwerfen, der sie nutzen wird. In der Praxis wird das über einen Discovery Sprint (ab CHF 6'000) abgegrenzt: Die neue Implementierung wird gebaut und in 1-2 Tagen an den betreffenden Prozess angebunden, nicht als separates Integrationsprojekt mit eigener Budgetrunde.

Damit ist die Frage beantwortet, die jede technische Prüfung in den ersten zehn Minuten stellt - also sagen wir es direkt:

Ersetzt {yourcompany}os mein ERP? Nein. Ihr ERP, CRM, Ihre E-Mail und Ihre Spezialtools bleiben, wo sie sind, und die Menschen, die damit arbeiten, arbeiten weiter damit. {yourcompany}os bindet sie als Implementierungen an und orchestriert die Schritte dazwischen. Es ist eine Orchestrierungsschicht neben Ihrem ERP, kein Konkurrent dazu.

Schicht 3: Datenmodell - offenes Schema, kein Login

Das Schema hinter {yourcompany}os ist als Pragmatic Data Contract publiziert und ohne Konto einsehbar auf schema.pragmaticbim.ch. Sie können Klassen, Relationen und versionierte Releases prüfen, bevor Sie integrieren oder sich zu irgendetwas verpflichten. Das Gegenteil eines Datenmodells, das Sie erst nach dem Verkaufsgespräch sehen.

Warum das Ihnen nützt und nicht uns:

• Bedeutung trägt über Tools hinweg. Entitäten wie Projekte, Räume, Anforderungen, Änderungen und Prozessobjekte teilen eine stabile öffentliche Schema-URI und Graph-Relationen. Dasselbe Projekt bedeutet dasselbe in {yourcompany}os, in iterthink und in allem anderen, das auf dem Contract aufbaut, statt in jedem System als proprietäre Spalten neu codiert zu werden.
• Sie können es verbessern. Das Schema liegt auf GitHub als Pragmatic BIM Data Contract. Issues eröffnen, Entitäten vorschlagen, Pull Requests stellen. Wenn Ihrer Branche ein Konzept fehlt, warten Sie nicht auf die private Roadmap eines Anbieters.
• Der Ausstieg ist prüfbar, nicht theoretisch. Weil das Schema öffentlich und versioniert ist, können Sie es vor der Bindung auditieren, einen Migrationspfad planen und gegen eine Version exportieren, die Sie pinnen. Sie wissen vorab, was "Ihre Daten" strukturell sind, statt es im Streitfall herauszufinden.

Alle Details in Offenes Schema statt Blackbox-Datenbank. Eine Klarstellung ist wichtig: Das ist kein IFC-Ersatz. IFC bleibt das Austauschformat, und das Schema ist ein workfloworientierter Contract darüber, damit Anwendungen abfragen, prüfen und automatisieren können, ohne jedes Mal die IFC-Logik neu herzuleiten.

Wie die drei Schichten zusammenspielen: ein durchgespieltes Beispiel

Nehmen wir das Ereignis aus dem Einstieg, "ein neues Projekt wird erstellt", und verfolgen es durch alle drei Schichten.

1. Der Prozess startet. Die Definition "Projekt erstellen" beginnt und vergibt Projektname und Identität. Einmal in BPMN definiert und unverändert, egal welche Tools dahinter stehen.
2. Er erreicht den Schritt der ERP-Erfassung. Dieser Schritt deklariert eine Abhängigkeit auf die Capability-Gruppe "ERP / Buchhaltung", nicht auf einen bestimmten Anbieter.
3. Die konfigurierte Implementierung löst ihn auf. Ist Ihre Implementierung für diese Gruppe bexio, läuft der Schritt gegen die bexio-API. Richten Sie die Gruppe anders aus, löst derselbe Schritt anders auf, während die Prozessdefinition unberührt bleibt.
4. Das Ergebnis wird gegen das offene Schema geschrieben. Projektentität, Identität und Relationen werden als publizierte Contract-Klassen persistiert und nicht als undurchsichtige Zeile in einer Anbietertabelle. Jedes andere Produkt und jede Integration auf diesem Schema kann dasselbe Projekt gleich adressieren.
5. Setup und Abschluss laufen auf derselben Spine weiter. Jeder Subprozess löst die Capability-Gruppen auf, die er braucht (Ablage für Dokumente, E-Mail für Benachrichtigungen), und bezieht sich weiter auf die eine Projektidentität aus Schritt 1.

Vergleichen Sie das mit der Version, die Sie heute wahrscheinlich fahren: Schritt 1 ist eine Person, die einen Namen an fünf Stellen tippt, und Schritte 2 bis 5 sind ein Chat-Verlauf. Nichts in diesem Ablauf koppelt den Prozess an einen Anbieter, und nichts versteckt die entstandenen Daten hinter einem Login. Jede Schicht kann sich ändern, ohne die anderen mitzuziehen.

Warum die Schichten so getrennt sind

Der Aufbau ist bewusst das Gegenteil einer Plattform mit geschlossener Ontologie. Ein System wie Palantir Foundry hält seine Ontologie proprietär, weil die Ontologie der Lock-in ist. {yourcompany}os publiziert das Schema offen und behandelt Ihre Prozessdefinitionen, nicht das Schema, als das, was Ihnen gehört und was Sie verfeinern. Ihr Wettbewerbsvorteil war nie das Datenmodell; er ist, wie Ihre Firma tatsächlich arbeitet. Der ganze Vergleich, inklusive Preis- und Liefermodell-Unterschiede, steht in Wie {yourcompany}os das Palantir-Modell zu KMU bringt.

FAQ

Ersetzt {yourcompany}os mein ERP?
Nein. Ihr ERP (etwa SAP oder bexio) bleibt als eine Implementierung hinter der Capability-Gruppe "ERP". {yourcompany}os orchestriert die Schritte darum herum und übernimmt keine ERP-Funktionen.

Müssen wir vorher Daten migrieren oder Leute umschulen?
Nein. Genau darum geht es bei einer Schicht statt einer Plattform. Daten bleiben in den Systemen, denen sie gehören, und Aufgaben werden in das Postfach und Ablagesystem geliefert, das Ihre Leute schon nutzen. Deshalb kann ein erster Prozess in 1-2 Tagen live gehen.

Kann ich selbst hosten oder auf eigener Infrastruktur betreiben?
Schweizer Hosting ist der Standardbetrieb. Weil das Schema öffentlich und versioniert ist, können Sie Datenportabilität unabhängig vom Hosting-Ort prüfen und planen.

Was passiert mit unseren Daten, wenn wir gehen?
Weil das Datenmodell publiziert und versioniert ist statt proprietär, exportieren Sie gegen ein Schema, das Sie bereits verstehen und auditiert haben, statt danach ein Exportformat zu verhandeln.

Wie unterscheidet sich das von einem iPaaS wie n8n oder Zapier?
iPaaS-Tools sind stark bei kurzlebigen Verbindungen zwischen Apps, werden aber schwach, sobald ein Prozess Phasen, Subprozesse und Governance bekommt, weil "Workflow" und "Prozess" dasselbe wegwerfbare Objekt sind. {yourcompany}os hält den Prozess als dauerhafte, versionierte Definition und die Integrationen als separat austauschbare Implementierungen darunter.

Wo ist die Quelle der Wahrheit für das Schema?
schema.pragmaticbim.ch für die aktuelle Referenz und versionierte Snapshots, mit dem zugrundeliegenden Contract offen auf GitHub als Pragmatic BIM Data Contract.

Was, wenn ein System bei uns noch keine Implementierung hat?
Eine neue Implementierung kann für diese Capability-Gruppe ergänzt werden, ohne den davon abhängigen Prozess neu zu entwerfen - inklusive Anbindung Ihres eigenen LLM als BYO-Implementierung für die KI-Gruppe. Abgegrenzt wird das über einen Discovery Sprint (ab CHF 6'000, 1-2 Tage), denselben Mechanismus, mit dem auch ein erster Prozess live geht.