Ich bin ja bekannt als Verfechter einer “Sourcecode auf jedem Kundensystem”-Politik, zu der ich Infor und Infors Kunden gerne bewegen würde.

Gegen den Strom

Infors Strategie ist leider im Moment sehr gegenteilig ausgerichtet, man versucht, Sourcecode-Agreements so wenig wie möglich zuzulassen. Über die Gründe, die hinter dieser Politik stehen, kann ich nur spekulieren. Da mag einmal die aus Baan-Zeiten übernommene Geheimniskrämerei sein (“das ist unser intellectual property, das geht keinen was an”). Zum anderen ist es vielleicht auch die Furcht davor, dass irgendwer (sprich: SAP) bei Baan-Ablöseprojekten verspricht, während der Ablösung die alte Baan-Software weiter zu warten. Das geht natürlich nur, wenn der Kunde Sourcen hat.

Beide Ängste sind meines Erachtens unbegründet. Denn es hilft niemandem, der ein ERP-System (nach)programmieren will, Baan-4GL-Sourcecode vor sich liegen zu haben – den kann man nur auf Baan Tools einsetzen, und auf denen hält Infor zu Recht lizenz- und source-technisch den Deckel drauf. Was vielleicht hülfe, sind Datenmodell und Grundlogiken. Um die abzukucken, brauchts aber keine Sourcen, sondern nur jemanden, der sich mit dem Programm auskennt. Der zweiten Furcht, die vor dem Ausnutzen vorhandenen Sourcecodes zum “Kundenklau”, lässt sich sicher durch vertragliche Regelungen begegnen, wenn man etwa Sourcecodeverfügung an das Bestehen eines Wartungsvertrages koppelt.

Vorgeschoben ist meines Erachtens die Begründung, dass man Anpassungen verhindern möchte, die das Upgraden erschweren. Ich weiß, dass das ein Problem ist, aber in der Regel liegt’s nicht an Anpassungen, wenn ein Releasewechsel schwierig ist, sondern an schlecht gemachten Anpassungen und an Report-Anpassungen, die man auch ganz ohne Sourcecode machen kann. Das muss man anders in den Griff kriegen, als gar keine Anpassungen zuzulassen.

Auch die Kunden scheinen sich bei Projektbeginn – gerade bei Neueinsteigern in die Software – keine Gedanken darüber zu machen, dass man Sourcecode bräuchte; entsprechend wird er häufig gar nicht verhandelt. Der Hauptgrund hier: Man hat ein Standardsystem gekauft, will das auch nicht anpassen. Wozu braucht man also Sourcecode?

Aber kein Unternehmen ist Standard

Lassen Sie sich gesagt sein: Erstens gibt es meines Wissens nicht ein einziges Baan-System, das im Standard läuft. Und das ist gut so: Kein Unternehmen ist Standard, sonst könnte es nicht am Markt existieren. Und daher geht der Gedanke, bei einer Firma, die etwa über ein fünfzig-Mitarbeiter-Unternehmen rausgeht, könne man nur unangepasste Standardsoftware einsetzen, an der Unternehmensrealität vorbei. Und zweitens, selbst wenn Sie nichts anpassen (was grade noch so geht), oder erweitern (was Sie nicht vermeiden werden wollen), selbst dann hilft Ihnen Sourcecode.

Also, warum Sourcecode? Ich sehe eine ganze Reihe von Bereichen, in denen ich als Berater beim Kunden, und die Kunden mit mir, wesentlich schneller in den Projekten vorankommen, wenn sie Sourcecode haben, als ohne:

1. Verständnis der Softwarelogik

Vielleicht lehne ich mich als Berater ja recht weit aus dem Fenster, wenn ich sage: Ich habe keine Ahnung, wie die Software genau funktioniert. Glauben Sie mir, anderen Beratern geht’s genauso, und die meisten geben es auch zu. Wir kennen natürlich die wesentlichen Prinzipien, und auch sehr sehr viele Details. Aber eben nicht jedes klitzekleine Fitzelchen Funktionalität.

Woran liegt das? Eine typische mittelgroße Baan-Source (etwa eine DLL) hat so um die 150 if-then-Anweisungen (ich hab das auf einem Kundensystem mal nachgezählt). Bei geschätzten 20000 Sourcen, macht das 3.000.000 Wenn-Danns. Drei Millionen Mal gibt es die Option, dass ERP-LN etwas mal so, oder eben so macht. Und das sind keine “wenn Betrag größer 100 €, dann Farbe rot”-Wenn-Danns. Das sind Geschäftslogiken-Wenn-Danns. Glauben Sie wirklich, als Berater hätte man die alle durchdrungen und im Kopf? Glauben Sie, sowas könne man so sauber dokumentieren (einschließlich Nachpflege der Dokumentation bei Bugfixes etc.), das man nur ins Handbuch kucken müsste?

In dieser Größenordnung geht das einfach nicht mehr. Dazu kommt, dass Infor täglich um die zwanzig Solutions ausliefert, dass sich also jeden Tag in einem ganzen Haufen Skripten ein ganzer Haufen Wenn-Danns ändert, und dass es also vom exakten Solutionstand auf dem Kundensystem abhängt, wie sich das System konkret in den letzten Details verhält.

Da hilft nur eins: Nachlesen. Und zwar in der aktuellsten, genauesten und klarsten Softwaredokumentation, die es gibt: Dem Sourcecode. Der zudem die erfreuliche Eigenschaft hat, mittels eines Debuggers analysiert werden zu können. Warum springt diese blöde Multi-Bshell-Funktion der Herstellkostenberechnung nicht an? Trace auf die enstprechende Variable, aha, weil das nur im Bottom-Up-Modus funktioniert. Von der Art, wie der Muti-Bshell-Lösung in dem Programm konkret implementiert ist, kann das auch nur so sein, das steht nur weder in Hilfe, noch im Handbuch.

Mit Source: zwei Minuten. Ohne: Entweder man hat Glück, und ein Beraterkollege hat das gleiche Problem schonmal gehabt. Mit Abtelefonieren der Kollegen eine Stunde, bis ein halber Tag (man kriegt die ja nicht gleich). Ohne den Kollegen und ohne Source: Locker ein Tag, vielleicht sogar ein Support-Incident, bis der Groschen fällt.

Die Frage, ob ein Softwareverhalten, das uns nicht passt, ein Bug ist, oder an unseren Einstellungen liegt, oder zum Beispiel daran, dass im Table-Sharing etwas falsch aufgesetzt ist, ist mit Sourcen in der Regel deutlich einfacher zu beantworten als ohne.

Es geht nicht darum, ob Infor verpflichtet ist, sowas zu dokumentieren. Es geht nicht darum, ob wir Berater diese 300.000 Regeln eigentlich wissen müssten. Für das viele Geld, das wir kriegen. Es geht darum, ob man pünktlich live gehen kann, weil die Berater produktiver sein können.

2. Bugfixing

Bug gefunden

Software hat Fehler. So isses nunmal, leben wir damit. Infor hat glücklicherweise ein funktionierendes System, mit dem Bugs gemeldet und Bugfixes kontrolliert eingespielt werden können.

Nur: Das System ist in manchen Situationen zu träge, und zwar so träge, dass es Projektarbeit einfach ausbremst. Auch das ist normal, da kann man Infor eigentlich keinen Vorwurf machen: Manche Probleme stellen Sich aus Sicht eines Standard(!)-Softwareherstellers viel komplexer dar, als für das einzelne Anwenderunternehmen.

Konkretes Beispiel gefällig? Im ERP-LN-Service ist es derzeit nicht möglich, das Steuerland einer Ist-Bearbeitungskostenposition zu ändern. Der Kunde, bei dem mir das aufgefallen ist, hat glücklicherweise Sourcecode, so dass ich weiß, dass es sich um einen Bug handelt, der durch eine schnell ausgelieferte Solution in die Welt gesetzt wurde. Das ganze ist reproduzierbar, und an Infor gemeldet.

Dort geht jetzt der Tanz los: Wenn wir die Änderung des Landes zulassen, was passiert dann im Normalfall? Nix. Aber was passiert im Sonderfall? Was, wenn die ausführende Abteilung und die am Auftrag hängende Abteilung unterschiedlichen Fibu-Firmen angehören? Was in diesem Sonderfall, was in jenem?

Das zu klären, und sauber zu reparieren, so dass es bei allen Kunden funktioniert, dauert.

Und in der Zwischenzeit tickt in meinem Projekt die Uhr, wir wollen mit Service endlich live gehen und dieser Bug ist das einzige, was uns an der Projektabschlussparty hindert. Wir haben nicht die Situation, dass mehrere Firmen beteiligt sein können. Wir haben auch keinen anderen der vielen denkbaren Sonderfälle. Wir haben einfach nur einen Fiskalvertreter in England, so dass wir gezwungen sind, bei Aufträgen in England englische Steuerregelung zu beachten – und das macht diesen Bug zum Showstopper für ein ganzes Paket. Glücklicherweise gibt’s ein Sourceodeagreement: Die Skripte hochziehen und das Problem so zu bereinigen, dass es für das konkrete Anwenderunternehmen keines mehr ist, ist eine Sache von 15 Minuten. Party kann stattfinden.

Es geht nicht darum, ob Infor verpflichtet ist, solche Fehler zu lösen. Es geht darum, ob man pünktlich live gehen kann.

3. Software-Erweiterungen

Glauben Sie mir: Der Standard reicht nie. Selbst wenn Sie das Kernverhalten der Software nicht ändern wollen, werden Sie früher oder später feststellen, dass es Zeitersparnis im betrieblichen Alltag bringt, wenn bestimme Geschäftsfunktionen ins ERP-System integriert werden, die im Standard nicht vorhanden sind. Oder dass es sinnvoll ist, die Flexibilität des Standards einzuschränken, weil die Anwender sonst zu viel Mist bauen. Oder dass sie Einzelschritte, die der Standard sie abzuarbeiten zwingt, automatisieren wollen.

Nun, mit der 4GL-Entwicklungsumgebung von Infor steht eines der besten Systeme für geschäftskritische Transaktionssysteme zur Verfügung, die ich kenne. Also kann ich nur empfehlen, die zu nutzen – eine Entwicklungslizenz kostet nun wirklich nicht die Welt, und der Gewinn, den ein Unternehmen davon hat, wenn man Addon-Entwicklung für das ERP-System betreibt, ist schon nicht zu unterschätzen.

Diese Addons müssen aber irgendwie mit dem Standard interagieren. Dazu muss man Funktionen der Standardsoftware entweder ansprechen und/oder sich in enstprechende Funktionen einklinken (was, dank “User-Exits”, heute in bestimmten Bereichen schon sehr gut geht).

Und da entsteht das erste Problem: Man muss wissen, welche Funktion man nutzen kann. Diese Funktionen sind aber nur an einer Stelle sichtbar: Im Quellcode. Es gibt – und es ist auch nicht realistisch, so etwas zu erwarten – keine Dokumentation. Man kann sich zwar eine DLL-Dokumenation generieren lassen, für die praktische Arbeit reicht diese aber einfach nicht aus.

Das zweite, gravierendere Problem ist jedoch, dass diese Funktionen nicht stabil sind – Infor hat keine sogenannten “stabilen APIs”, man muss damit rechnen, dass sich die Signatur einer Funktion (welche Parameter muss man übergeben) nach dem Einspielen einer Solution auf einmal geändert hat. Selbst wenn ein Addon also lange funktioniert hat, kann es nun auf einmal einen Programmabbruch verursachen. Die einzige Chance, das Addon wieder lauffähig zu machen, besteht darin, es auf die neue Signatur der genutzten Standardmethoden umzuschreiben. Und diese Signatur sehen (und verstehen) Sie nur – im Sourcecode, der mit der Solution ausgeliefert wurde, wenn Sie denn ein Sourcecodeagreement haben.

Mit anderen Worten: Alle Anpassungen und Erweiterungen müssen auf den konkreten Solutionstand abgestimmt sein, der am Kundensystem installiert ist. Wenn Sie Anpassungen/Erweiterungen extern (etwa bei Infor oder einem Systemhaus) beauftragen, extern programmieren und dann bei Ihnen einspielen lassen, muss auf dem externen Entwicklungssystem immer der selbe Solutionstand vorhanden sein wie auf Ihrem. Das ist nur mit hohem Aufwand machbar (den Sie als Kunde natürlich bezahlen). Einfacher und billiger ist es, auf Ihrem eigenen System zu entwickeln oder eben entwickeln zu lassen. Und dazu brauchen Sie Sourcecode.

Es geht nicht darum, keine Softwareerweiterungen zu schreiben und auf Produktivitätsvorteile zu verzichten. Es geht darum, diese Addons mit geringem Aufwand auch Warten zu können.

4. Programmieren lernen

ERP LN verfügt über eine eigene Programmiersprache. Die muss man sich erstmal erarbeiten. “Schulen und dann kann der programmieren” funktioniert leider nicht: Jeder, der regelmäßig Software entwickelt weiß, dass man das “Coden” in einer Programmiersprache nur dadurch lernt, dass man den Quellcode Anderer lesen und sich daran orientieren kann. Die größte und so ziemlich einzige (brauchbare) Codebasis, die für die Baan-4GL-Programmiersprache vorhanden ist, ist nun aber der Sourcecode der Baan-Anwendung. Wenn dieser nicht verfügbar ist, wenn Sie (oder Ihre Leute) aber für die Anwendung bspw. Add-Ons programmieren sollen, kann ich Ihnen garantieren, dass der entsprechende Code grottenschlecht sein wird. Anpassungscode auf Kundensystemen ist in viel zu vielen Fällen ziemlich gruselig programmiert. Da, wo Sourcecode vorhanden ist, ist die Qualität in der Regel immerhin deutlich besser (meiner Meinung nach immer noch zu schlecht, aber besser). Besserer Anpassungcode heißt bessere Wartbarkeit, und weniger Münzen, die man bei Releasewechseln einwerfen muss.