Unternehmen ist Code: Was Sie fehlen, ist nicht der Prozess, sondern eine versionierbare "Organisations-DSL"

Das Divine Translation Bureau ist ein Übersetzungsteam von 36Kr, das sich auf Technologie, Geschäft, Arbeitsplatz und Lebensbereiche konzentriert und vor allem neue Technologien, neue Ansichten und neue Trends aus dem Ausland vorstellt.

Herausgeberhinweis: Wenn Code die Welt verschlingt, warum bleibt das Unternehmen selbst noch in der "Papierzeit"? Die Programmierung der Organisationsstruktur könnte die ultimative Lösung sein, um interne Verwaltungsverschwendung zu beenden. Der Artikel stammt aus einer Übersetzung.

Letzte Woche, als ich mir gegenüber einem ISO 27001-Informationstechnik-Sicherheitsprüfer setzte und sah, wie sie sich bemühten, unsere Dokumente durchzusehen, kam mir plötzlich ein Gedanke:

Als Softwareunternehmen wird fast alles in vernetzten digitalen Systemen abgewickelt. Dennoch besteht das Kernstück unseres Geschäfts - die Richtlinien, Prozesse und die Organisationsstruktur - nur aus einer Sammlung von einfachen Dokumenten.

Das ist ziemlich ironisch. Wir nutzen fortschrittliche Tools, um die Einhaltungsprüfungen zu automatisieren, speichern unseren Code in Versionskontrollsystemen und verwalten unsere Infrastruktur "als Code". Dennoch setzen wir bei der Beschreibung und Verwaltung unseres Unternehmens auf "elektronisches Papier" zurück und verlassen uns auf verstreute Informationen, die in verschiedenen Teilen des Unternehmens mündlich weitergegeben werden.

Wenn ich über unsere täglichen Prozesse nachdenke, wird diese Diskrepanz noch deutlicher: 90 % unserer Produkte, Dokumente, Kommunikation und Entscheidungen existieren in digitalen Kanälen. Das sind alle Daten. Sie befinden sich in der Cloud und verteilen sich auf SaaS-Lösungen, die auf bestimmte Workflows spezialisiert sind - und alle diese Systeme verfügen über leistungsstarke APIs und programmgesteuerten Zugang.

Im Zentrum all dessen befindet sich jedoch eine Insel aus Dokumenten: darin stecken unsere Ambitionen, Ziele, Richtlinien und offizielle Struktur. Und das sind, wie ich finde, die wichtigsten Dinge.

Tatsächlich war unsere Sicherheitslage schon langsam gut, bevor wir an die ISO 27001 dachten, denn wir bemühten uns ständig, die Bedürfnisse unserer Kunden zu erfüllen. Aber beim Sammeln von Beweisen für die Kontrolle, beim Streiten und Aktualisieren der Formulierung der Richtlinien, beim Prüfen der Dokumente und bei der eigentlichen Prüfung haben wir hunderte von Arbeitsstunden vergeudet - Zeit, die wir besser dafür nutzen könnten, noch bessere Produkte für unsere Benutzer zu entwickeln.

Die fehlende Kette

Wenn wir so viel Betriebsdaten anstreben, warum tolerieren wir dann ein Mangel an Organisationsdaten? Wir haben die Infrastrukturverwaltung vollständig verändert durch "Infrastructure as Code" (IaC), die Bereitstellung über GitOps und die Sicherheit über "Policy as Code".

Wir haben die Vorteile davon gesehen.

Aber wenn es darum geht, unsere Organisation - also das Herzstück unseres Geschäfts - darzustellen, verwenden wir immer noch alte Methoden.

Stellen Sie sich vor, wir könnten die gesamte Organisationsstruktur programmgesteuert darstellen - nicht als statisches Bild, sondern als eine lebendige, atmende digitale Kopie des Unternehmens, die versioniert, abgefragt, getestet und automatisch validiert werden kann. In einem solchen System könnten Änderungen an Richtlinien wie Code-Commits verfolgt werden, die Einhaltung kontinuierlich überwacht werden und die Beziehungen zwischen Menschen, Prozessen und Technologien klar abgebildet und verstanden werden.

Ein größeres Vorhaben

Vorhandene Lösungen wie HRIS-Systeme verwalten zwar Mitarbeiterdaten, sind aber bei der Verwaltung von Richtlinienverknüpfungen nicht sonderlich effektiv. GRC-Tools verfolgen zwar die Einhaltung von Vorschriften, haben aber selten eine echte Verbindung zur Organisationsstruktur. Ich schlage vor, dass wir einen weiteren Schritt gehen. Wir sollten eine umfassende, programmgesteuerte Darstellung der gesamten Organisation erstellen: eine "Unternehmensliste", die als einzige Quelle für die Organisationsstruktur, die Richtlinien und den Betrieb dient.

Denken Sie an die Vorteile in folgenden Szenarien:

• Prüfungen auf Einhaltung: Prüfer müssen nicht mehr manuell aus verschiedenen Systemen Beweise zusammenstellen, sondern können direkt in der Unternehmensliste nachschlagen und eine klare Rückverfolgbarkeit zwischen Richtlinien und ihrer Umsetzung herstellen.

• Änderungen an Richtlinien: Aktualisierungen können versioniert werden, und eine automatisierte Auswirkungsanalyse kann zeigen, welche Teams und Prozesse betroffen sein werden.

• Organisationsdesign: Die Führungsebene kann vor der Umsetzung von Strukturänderungen in einer "Staging-Umgebung" simulieren, um besser zu verstehen, wie diese Veränderungen im gesamten Unternehmen zu einem Kettenreaktion führen werden.

Warum ist dies noch nicht Realität?

Je mehr ich über diese Idee nachdenke, desto mehr Fragen stellen sich mir, als ich Antworten finde.

Hat jemand das schon versucht? Wenn nicht, warum?

Ist es, weil Organisationen von Natur aus zu komplex und zu dynamisch sind, um sie als Code darzustellen? Wenn ja, scheint das im Widerspruch zu Regulierungen und Standards zu stehen - denn wir erwarten, dass Unternehmensaktivitäten so einheitlich und programmierbar sind, dass wir sie zuverlässig als einhaltungskonform, nicht konform, legal oder illegal einstufen können.

Ist es, dass wir noch nicht die richtige Abstraktionsebene gefunden haben - wie "Infrastructure as Code" es für die Systemverwaltung getan hat?

Die Tools und Konzepte sind eigentlich vorhanden: Graphdatenbanken zur Darstellung von Organisationsbeziehungen, domänenspezifische Sprachen zur Beschreibung von Geschäftsregeln und API-first-Architekturen zur Integration.

Vielleicht fehlt einfach ein Rahmenwerk, das all diese Ideen zusammenführt und es sowohl leistungsstark und praktisch als auch einfach zu bedienen macht.

Umsetzung in die Praxis

Denken wir darüber nach, wie das funktionieren könnte.

In diesem Abschnitt stelle ich meine Erwartungen an "Unternehmen als Code" vor. Dann ordne ich sie auf einige Systemkomponenten ab, die diese Anforderungen erfüllen können.

Als Ingenieur und Geschäftsinteressent möchte ich, dass das Unternehmensmodell folgende Eigenschaften hat:

Abfragbarkeit

Das System muss in der Lage sein, die Beziehungen zwischen Menschen, Richtlinien und Systemen zu verfolgen - ähnlich wie die Verfolgung von Codeabhängigkeiten. Benutzer sollten in der Lage sein, die Organisation aus verschiedenen Perspektiven zu betrachten, z. B. welche Personen von einer bestimmten Richtlinie betroffen sind und wer für diese Richtlinie verantwortlich ist.

Versionierbarkeit

Klare Verfolgung von Organisationsänderungen, einschließlich des Ausführers, der Änderung und des Grundes. Dies ist für Prüfungen und das Verständnis der Entwicklung der Organisation von entscheidender Bedeutung.

Integration

Nahtlose Datenaustausch mit bestehenden Tools wie Azure, Slack usw., um ein aktuelles Bild der Organisation zu erhalten und die Toolkonfiguration gemäß den Richtlinien durchzusetzen.

Testbarkeit

Bereitstellung einer "Staging-Umgebung", um Organisationsänderungen vor der eigentlichen Umsetzung zu modellieren und die Automatisierungstests für einzelne Regeln und Steuerungen zu unterstützen.

Benutzerfreundlichkeit

Obwohl es von Code angetrieben wird, sollte die Benutzeroberfläche intuitiv genug sein, damit auch Führungskräfte ohne technischen Hintergrund es effektiv nutzen können.

Um diese Vision zu verwirklichen, benötigen wir einige Bausteine. Jede Komponente muss bestimmte Anforderungen erfüllen, um ein leistungsstarkes und dennoch relativ einfaches System zu erstellen.

Eine deklarative Sprache für Organisationen

In Anlehnung an "Infrastructure as Code"-Tools wie Terraform stellen wir uns eine deklarative, domänenspezifische Sprache (DSL) vor, die natürlich zu lesen ist und gleichzeitig formelle Strukturen ausdrücken kann.

Die Grundsyntax folgt einem klaren Muster:

EntityType "Identifier" {

    References = AnotherEntity.Identifier

    Attribute = Value

    ListAttribute = [

        "Item One",

        "Item Two"

    ]

}

Jede Entität wird durch einen Typ, einen eindeutigen Bezeichner und eine Reihe von Attributen definiert. Entitäten können sich über die Punktnotation aufeinander beziehen, um ein Netzwerk von Beziehungen zu schaffen, das das Organisationsdiagramm bildet.

Definition einer Organisation

Schauen wir uns an, wie wir mit dieser Sprache ein kleines Ingenieurteam definieren können:

1. Definition der Rollen in der Organisation:

Role "SoftwareEngineer" {

    Responsibilities = [

        "Schreiben Sie sauberen, wartbaren Code",

        "Nehmen Sie an Code-Reviews teil",

        "Dokumentieren Sie technische Entscheidungen"

    ]

}

Role "EngineeringManager" {

    Responsibilities = [

        "Bieten Sie technische Führung",

        "Führen Sie Leistungsbewertungen durch",

        "Verwalten Sie die Ressourcen des Teams"

    ]

}

2. Erstellung einer Organisationseinheit für unser Team:

OrganisationalUnit "EngineeringTeam" {

    Department = "Engineering"

    CostCenter = "ENG - 001"

}

3. Mit diesen Strukturen können wir nun konkrete Personen und ihre Beziehungen definieren:

Person "AliceSmith" {

    FullName = "Alice Smith"

    Role = Role.EngineeringManager

    Unit = OrganisationalUnit.EngineeringTeam

    Email = "alice.smith@company.com"

}

Person "BobJohnson" {

    FullName = "Bob Johnson"

    Role = Role.SoftwareEngineer

    Unit = OrganisationalUnit.EngineeringTeam

    Manager = Person.AliceSmith

    Email = "bob.johnson@company.com"

}

4. Die Definition von Richtlinien bildet den Rahmen für die Einhaltung von Vorschriften:

PolicyGroup "SecurityPolicies" {

    Owner = Person.AliceSmith

}

PolicyRule "MFARequired" {

    Group = PolicyGroup.SecurityPolicies

    Enforcement = "Mandatory"

    ComplianceLevel = "Critical"

}

5. Wir können diese Richtlinien auf externe Anforderungen abbilden:

ExternalRequirement "ISO27001_A9_4_1" {

    Standard = "ISO 27001:2013"

    Control = "A.9.4.1"

    ComplianceLevel = "Mandatory"

}

ComplianceMapping "MFACompliance" {

    Requirement = ExternalRequirement.ISO27001_A9_4_1

    ImplementingPolicies = [PolicyRule.MFARequired]

}

Von der hohen Architektur bis hin zu den konkreten Einzelrichtlinien und ihren regulatorischen Auswirkungen erlaubt diese deklarative Methode, ein vollständiges Bild der Organisation zu erstellen. Jede Definition ist klar und selbsterklärend, und die Referenzen zwischen den Entitäten bilden ein Netzwerk von Beziehungen, das zur Analyse, Validierung und Automatisierung von Organisationsprozessen verwendet werden kann.

Die in der DSL deklarierten Entitäten bilden ein Diagramm.

Durch diese Darstellung können wir davon profitieren, die Organisation in logische Dateien und Verzeichnisse zu strukturieren und Organisationsänderungen wie Codeänderungen zu behandeln: versionieren, prüfen und validieren, bevor sie angewendet werden.

Dies ermöglicht Praktiken wie die Prüfung von Änderungen über Pull Requests, das Testen von Richtlinienänderungen vor der Veröffentlichung, die automatische Generierung von Einhaltungsdokumenten und die Verfolgung der Entwicklung der Organisationsstruktur im Laufe der Zeit.

Modellierung

Während "Infrastructure as Code"-Tools wie Terraform "gerichtete azyklische Graphen" (DAGs) verwenden, um die Bereitstellungsreihenfolge zu bestimmen, ist die Struktur einer Organisation von Natur aus stärker vernetzt. Menschen verwalten andere Menschen, Richtlinien beziehen sich auf Aktivitäten, und Aktivitäten wiederum verweisen auf Richtlinien. Es gibt komplexe Abhängigkeiten zwischen Teams. Dies erfordert ein "undirektiertes, zyklisches Graphmodell", um diese vielfältigen Beziehungen darzustellen.

public record Node(

    string Id,           // z. B. "Person.AliceSmith"

    string Type,         // z. B. "Person", "PolicyRule"

    List<Edge>