Wie oft haben Sie bei einer Werkzeugeinführung diesen Satz gehört: „Das konfigurieren wir Ihnen."
Er klingt nach unternehmerischer Freiheit. Für die tatsächliche Logik eines Werkzeugs ist er ein Warnzeichen.
Werte und Logik sind zwei Dinge#
Nehmen Sie Ihre Buchhaltung. Kontenrahmen, Steuerschlüssel und Kostenstellen legen Sie fest. Das ist Konfiguration, und sie ist richtig.
Was Sie nicht festlegen: dass jede Buchung zwei Seiten hat. Soll gleich Haben ist keine Einstellung. Darüber diskutiert niemand.
Oder ein Fahrzeug. Es hat Räder. Das Auto hat vier, das Motorrad zwei. Die Zahl ist ein Wert. Das Rad ist Struktur. Wer für das Motorrad ein neues Datenmodell braucht, hat das Fahrzeug nicht verstanden.
Bei Werkzeugen für Anforderungen und Produktdaten heißt „konfigurierbar" meist etwas anderes. Konfiguriert werden Artefakttypen, Verknüpfungsarten, Statusmodelle und Freigabeabläufe. Das sind keine Werte. Das ist die Logik selbst.
Daraus folgt der Kern dieses Textes:
Werte einzustellen ist normal. Wer die Logik einstellen muss, dem fehlt die Regel.
Normen unterscheiden sich in Werten, nicht in Strukturen#
Der häufigste Einwand lautet: „Wir sind da anders, Luftfahrt ist anders als Automobil. Medizin ist anders als Bahn."
Die Normen selbst sagen etwas anderes. Die IEC 61508 ist als Grundnorm der funktionalen Sicherheit angelegt. Branchennormen leiten sich von ihr ab: ISO 26262 für Fahrzeuge, IEC 61511 für die Prozessindustrie, IEC 62061 für Maschinen, die EN-50126-Reihe für die Bahn. Sie übersetzen dieselbe Grundlage in die Branche.
Auch wo keine direkte Ableitung besteht, wiederholt sich das Muster. Jede Branche kennt eine Stufe: SIL, ASIL, DAL, Sicherheitsklasse. Je höher die Stufe, desto strenger die Nachweise. Die Namen unterscheiden sich. Die Struktur nicht.
Der härteste Gegenfall, den ich kenne: Die ASIL-Einstufung bezieht zusätzlich ein, ob der Fahrer die Lage beherrschen kann. SIL und ASIL lassen sich deshalb nicht eins zu eins umrechnen. Das ist eine weitere Eingangsgröße in derselben Einstufung. Eine neue Struktur ist es nicht.
Diese Aussage lässt sich widerlegen. Ein einziges Gegenbeispiel genügt: eine Normanforderung, die sich nicht als Wert auf einer gemeinsamen Struktur darstellen lässt. Kennen Sie eines, schicken Sie es mir.
Warum Werkzeuge trotzdem die Logik freigeben#
Es gibt mehr als eine Ursache.
- Die Regel wurde nicht gefunden. Dann bleibt nur, dem Anwender alles zu erlauben.
- Einführung ist ein Geschäft. Jede Konfiguration bringt Beratertage.
- Haftung wandert. Wer konfiguriert hat, verantwortet das Ergebnis.
- Sie wünschen es. Viele Firmen wollen ihren gewachsenen Prozess im Werkzeug wiederfinden.
Zum vierten Punkt: Ein Werkzeug mit fester Logik bildet Ihren Prozess nicht ab. Es zeigt, wo er von der Regel abweicht. Ob Sie den Prozess ändern oder bei Ihrem bleiben, entscheiden Sie. Aber Sie entscheiden es dann einmal, sehenden Auges und an einer Stelle. Nicht in jedem Projekt neu.
Und - nachdem ich Jahrelang für verschiedene Hersteller ALM und PLM Systeme ausgerollt habe weiß ich: Viele Prozesse sind nur auf dem Papier oder diese sind entstanden “Auf mehrfachen Wunsch einer einsamen Person”
Für Sie zählt am Ende nicht das Motiv. Es zählt die Wirkung, und die ist bei allen vier Ursachen dieselbe: Die Regelfindung wandert zu Ihnen. Sie bezahlen sie bei jeder Einführung, jedem Upgrade, jedem neuen Projekt. Und Sie tragen das Risiko, wenn die Regel falsch ist.
SAP empfiehlt seinen Kunden unter den Begriffen „Clean Core" und „Fit-to-Standard", das System nah am Standard zu halten und eigene Anpassungen zu vermeiden, die spätere Upgrades erschweren. Als Ziel nennt SAP auch geringere Betriebskosten durch weniger Customizing. Das ist eine Herstelleraussage mit eigenem Interesse: SAP will seine Kunden in die Cloud bringen. Das macht die Aussage nicht falsch, aber auch nicht zum Beweis.
Bemerkenswert ist eine Unterscheidung aus der SAP-Welt selbst. „Customizing" meint dort das Einstellen vorhandener Funktionen. Davon getrennt ist der Eingriff in die Funktion selbst. Das ist genau die Grenze zwischen Wert und Logik.
Was angepasst werden darf#
Feste Logik heißt nicht, dass nichts anpassbar ist. Die Grenze ist klar:
| Frei anpassbar | Fest |
|---|---|
| Namen und Fachbegriffe | Arten der Bausteine |
| Kataloge: Merkmale, Größen, Bauteile | Arten der Verbindungen |
| Gliederungsvorlage Ihrer Firma | Prüfregeln |
| Sichten und Berichte |
Die Prüffrage für jede Anpassung lautet: Ändert sie, was das System prüft? Dann ist es Logik.
Prüfen Sie es in Ihrem Haus#
Diese Prüfung richtet sich an die Leitung der Entwicklung und an den Verantwortlichen für das Werkzeug. Sie dauert einen Vormittag.
Selbsttest. Nehmen Sie zwei Projekte, die derselben Norm unterliegen. Zählen Sie je Projekt die Artefakttypen, die Verknüpfungsarten und die Statusmodelle. Unterscheiden sich die Zahlen, haben Sie keine Regel. Sie haben zwei.
Maßnahme. Frieren Sie die Logik ein. Neue Typen, Verknüpfungen und Abläufe gibt es nur noch an einer Stelle, mit Begründung, für alle Projekte. Bestehende Abweichungen führen Sie zurück, beginnend mit dem nächsten neuen Projekt.
Messung. Erheben Sie vorher den heutigen Stand. Danach dieselben Größen:
- Anzahl Artefakttypen, Verknüpfungsarten und Statusmodelle je Projekt
- Beratertage für Konfiguration pro Jahr
- Tage, bis ein neues Projekt im Werkzeug arbeitsfähig ist
- Abweichungen zur Rückverfolgbarkeit im Audit
Frist. Zwölf Monate oder das nächste Audit.
Erwartung. Stimmt die These, sinken Beratertage und Anlaufzeit. Die Abweichungen zur Rückverfolgbarkeit sinken oder bleiben gleich. Steigen sie, oder ändert sich nichts, lag Ihr Problem nicht in der Konfiguration. Auch das ist ein Ergebnis. Dann suchen Sie die Ursache woanders.
Der Preis. Der Rückbau kostet Migrationsaufwand. Arbeitet Ihr Werkzeug ohne die Konfiguration gar nicht, bleiben zwei Wege. Sie wechseln. Oder Sie nehmen es bewusst hin und wissen dann, was Sie jedes Jahr bezahlen.
Der Preis des Nichthandelns ist leiser. Sie bezahlen die Regelfindung weiter, in jedem Projekt neu. Und jedes Projekt findet eine etwas andere.
Anbieterhinweis. Ich entwickle mit OTSM selbst ein Enterprise Werkzeug. Was in diesem Kasten steht, ist meine Aussage als Anbieter.
OTSM arbeitet mit fünf festen Bausteinarten: Zweck, Funktion, Lösung, Merkmal, Kontext. Dazu kommen feste Verbindungsarten. Die Methode dahinter beschreibe ich unter Lebensfähigkeit. Normkapitel, Kundenanforderungen und User Stories sind Anforderungen. Sie werden an die Elemente geheftet, für die sie gelten. Eigene Typen je Norm gibt es nicht. Die Logik konfigurieren Sie nicht. Kataloge und Vorlagen ergänzen Sie.
Ein Werkzeug ist übrigens nie „compliant". “Eine nach ISO xxx zertifizierte Software, welche Sie einsetzen, macht ihnen kein zertifiziertes Produkt.” Konformität prüft man Ihr Produkt und Ihre Organisation. Das Werkzeug liefert die Nachweise. Die Qualifizierung des Werkzeugs für Ihren Einsatz liegt bei Ihnen.
Prüfweg: Lassen Sie sich das an Ihrem eigenen Beispiel zeigen. Oder schicken Sie mir die Normanforderung, die nicht passt.
Quellen
- IEC 61508 als Grundnorm (Basic Safety Standard): VDE Verlag, Leseprobe Kapitel 20 IEC/EN 61508
- Branchennormen und SIL/ASIL nicht eins zu eins umrechenbar: itemis, Glossar IEC 61508 (Anbieter von Engineering-Werkzeugen)
- Clean Core und Fit-to-Standard: SAP Learning, Geschäftsprozesse Clean-Core-konform machen (Herstelleraussage)
- Customizing als Einstellen vorhandener Funktionen: SAP Community Blog, „Keep the core clean" statement considered harmful