Woran ein gemeinschaftlicher „Merkmalserver“ (derzeit) scheitert

Erst vor Kurzem wurde wieder verlautbart, dass ein neuer Merkmalserver (BIM properties, Merkmalservice – bei jedem Anlauf heißt es ein wenig anders) in Angriff genommen wird. Das Ziel: endlich eine einheitliche Benennung von Bauteileigenschaften, mit eindeutiger ID, um den Datenaustausch endgültig zu ermöglichen. Das Konzept dieser Initiative sieht vor, dass zahlungskräftige Mitglieder Vorschläge machen dürfen, und diese werden dann (nach Einigung zwischen den Mitgliedern) vom Normungsinstitut als Standard übernommen. Natürlich ist das Ganze „generisch, neutral und für alle in der Branche kostenlos“. Allein, mir fehlt der Glaube, wie es so schön heißt.

Konzeptioneller Irrtum

Der typische Weg, der bei der Konsensfindung in Österreich gegangen wird, zeigt sich auch in den meisten der oben genannten Initiativen. Einige Unternehmen entscheiden sich für ein gemeinsames Vorgehen (grundsätzlich positiv!), treffen sich regelmäßig, einigen sich auf einen Kompromiss und lassen diesen als „Norm“ absegnen. Zumeist wird rasch ein gefördertes Forschungsprojekt daraus, immerhin hat ja die Gemeinschaft etwas davon. Und dann dauert es ein paar Jahre, bis ein Ergebnis vorliegt.

Warum ist eine solche Kompromisslösung in diesem Fall nicht zielführend? Es liegt in der Natur der Sache, dass es sich hier immer um eine Minimallösung handelt. Nehmen wir an, zwei Unternehmen haben bereits für sich eine bestimmte Anzahl an solchen Bauteileigenschaften definiert. Diese werden sich in manchen Bereichen überschneiden, in anderen jedoch nicht. Ist es nun im Interesse der beiden, nur den Überschneidungsbereich in einem solchen System zu verwalten? Und wenn es in den anderen Bereichen gleiche Konzepte gibt, aber im Detail unterschiedliche Bezeichnungen – wer von den beiden passt sich an?

Sollten nicht grundsätzlich alle Eigenschaftsdefinitionen in einem solchen System enthalten sein? Somit würde mit jedem Teilnehmer der Erfahrungsschatz wachsen.

Mit jedem Unternehmen, das sich einer solchen Plattform anschließt, schränkt sich in der derzeitigen Vorgangsweise der Überschneidungsbereich weiter ein, wohingehend der Diskussionsbedarf (und somit der Aufwand) weiter steigt.

Immerhin will jeder Teilnehmer seine Variante durchsetzen; andernfalls müssen interne Prozesse umgeschrieben werden. Häufig werden ja genau diese Eigenschaften bereits im Unternehmen wiederverwendet. Soll man diese internen, funktionierenden Systeme adaptieren, nur um möglicherweise externe, noch nicht etablierte Systeme zu fördern? Hier könnten bereits Zweifel aufkommen.

Besprechungskultur

Ein weiterer Faktor, der den Erfolg einer solchen „traditionellen“ Herangehensweise unrealistisch erscheinen lässt, liegt im Naturell von solchen Arbeitsgruppen. Die Besprechungsintervalle sind zu lang, es sitzen oft die „falschen“ Leute – oder immer die gleichen – in diesen Gremien; Praktiker vs. Theoretiker, Bautechniker vs. Informatiker. Zeit für Vorbereitung ist gering, Entwicklungsstände werden abgesegnet, um den Eindruck von Fortschritt zu erzeugen (sehr pessimistisch, aber leider oftmals der Fall).

Für eine 20%-Lösung wird es kaum ein volles Comittment der Branchenteilnehmer geben. Es muss von Anfang an eine 100%-ige Abdeckung für jeden Beteiligten einer solchen Bestrebung geben. Daran führt kein Weg vorbei. Andernfalls verläuft auch der nächste Anlauf wieder im Sand.

Evidenzbasierte Entscheidungen

Es handelt sich bei der Auflistung von Bauteileigenschaften um ein datentechnisches Problem. Dementsprechend muss es auch mit den Mitteln der IT gelöst werden. Die Meinung von Experten in solchen Gremien ist weniger relevant als die tatsächliche Verwendung in den Projekten. Eine Normierung sollte einer Standardisierung (bzw. einer De-Facto-Standardisierung) nachgereiht sein, nicht am Beginn einer solchen stehen. Wenn sich die Verwendung von Merkmalen statistisch messen lässt, dann kann auch die Relevanz besser eingeschätzt werden.

Automatismus

Wenn ein Unternehmensstandard in einen solchen System verwaltet wird, sich also etablierte unternehmensinterne Prozesse darauf beziehen, dann kann eine Konsolidierung auch automatisiert angegangen werden. Dabei besteht nicht mehr die Gefahr, interne Abläufe zu korrumpieren. Bei Einigung auf eine neue (mit der eigenen kompatible!) Definition können die unternehmensinternen (hoffentlich revisionssicher) „überschrieben“ werden. Schrittweise kommt es dadurch zu einer Annäherung der Standards; eine völlige Deckungsgleichheit wird jedoch niemals erreicht werden, auch unter Unternehmen der gleichen Branche (Planer, Baufirmen, Hersteller etc.) nicht.

Conclusio

Es wird schon zu lange über dieses Thema nur geredet. Gehen wir doch einmal einen anderen Weg: zuerst nutzen (machen ja schon einige seit Jahren), beobachten, messen, analysieren, und ganz am Schluss (unterstützt durch Automatisierung) konsolidieren. Wir müssen Diskrepanzen und Toleranzen zulassen – nicht in der Normierung, aber am Weg zur Standardisierung. Wir müssen aus den Erfahrungen von allen anderen lernen, und das möglichst ungefiltert (und natürlich anonymisiert). Kaum jemand wird in einer Abstimmungsbesprechung zugegeben, dass die eigenen Definitionen nicht praktikabel sind. Niemand kann derzeit nachweisen, ob und wie diese im Unternehmen verwendet werden. Erst durch einen solchen branchenweiten Nachweis kann Vertrauen in einen funktionierenden Datenaustausch entstehen und somit eine tatsächliche Produktivitätssteigerung erreicht werden.