![\"WarumSourceCode\"](\"http:\/\/all-in-for-erp.com\/de\/wp-content\/uploads\/sites\/2\/2016\/05\/WarumSourceCode-300x188.jpg\")
Ich bin ja bekannt als Verfechter einer “Sourcecode auf jedem Kundensystem”-Politik, zu der ich Infor und Infors Kunden gerne bewegen w\u00fcrde.<\/p>\nIch bin ja bekannt als Verfechter einer “Sourcecode auf jedem Kundensystem”-Politik, zu der ich Infor und Infors Kunden gerne bewegen w\u00fcrde.<\/p>\n
Infors Strategie ist leider im Moment sehr gegenteilig ausgerichtet, man versucht, Sourcecode-Agreements so wenig wie m\u00f6glich zuzulassen. \u00dcber die Gr\u00fcnde, die hinter dieser Politik stehen, kann ich nur spekulieren. Da mag einmal die aus Baan-Zeiten \u00fcbernommene Geheimniskr\u00e4merei 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\u00f6seprojekten verspricht, w\u00e4hrend der Abl\u00f6sung die alte Baan-Software weiter zu warten. Das geht nat\u00fcrlich nur, wenn der Kunde Sourcen hat.<\/p>\n
Beide \u00c4ngste sind meines Erachtens unbegr\u00fcndet. 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\u00e4lt Infor zu Recht lizenz- und source-technisch den Deckel drauf. Was vielleicht h\u00fclfe, 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\u00e4sst sich sicher durch vertragliche Regelungen begegnen, wenn man etwa Sourcecodeverf\u00fcgung an das Bestehen eines Wartungsvertrages koppelt.<\/p>\n
Vorgeschoben ist meines Erachtens die Begr\u00fcndung, dass man Anpassungen verhindern m\u00f6chte, die das Upgraden erschweren. Ich wei\u00df, dass das ein Problem ist, aber in der Regel liegt’s nicht an Anpassungen, wenn ein Releasewechsel schwierig ist, sondern an schlecht gemachten<\/em> 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.<\/p>\n Auch die Kunden scheinen sich bei Projektbeginn – gerade bei Neueinsteigern in die Software – keine Gedanken dar\u00fcber zu machen, dass man Sourcecode br\u00e4uchte; entsprechend wird er h\u00e4ufig gar nicht verhandelt. Der Hauptgrund hier: Man hat ein Standardsystem gekauft, will das auch nicht anpassen. Wozu braucht man also Sourcecode?<\/p>\n Lassen Sie sich gesagt sein: Erstens gibt es meines Wissens nicht ein einziges Baan-System, das im Standard l\u00e4uft. Und das ist gut so: Kein Unternehmen ist Standard, sonst k\u00f6nnte es nicht am Markt existieren. Und daher geht der Gedanke, bei einer Firma, die etwa \u00fcber ein f\u00fcnfzig-Mitarbeiter-Unternehmen rausgeht, k\u00f6nne man nur unangepasste Standardsoftware einsetzen, an der Unternehmensrealit\u00e4t 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.<\/p>\n 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:<\/p>\n Woran liegt das? Eine typische mittelgro\u00dfe Baan-Source (etwa eine DLL) hat so um die 150 if-then-Anweisungen (ich hab das auf einem Kundensystem mal nachgez\u00e4hlt). Bei gesch\u00e4tzten 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\u00f6\u00dfer 100 \u20ac, dann Farbe rot”-Wenn-Danns. Das sind Gesch\u00e4ftslogiken-Wenn-Danns. Glauben Sie wirklich, als Berater h\u00e4tte man die alle durchdrungen und im Kopf? Glauben Sie, sowas k\u00f6nne man so sauber dokumentieren (einschlie\u00dflich Nachpflege der Dokumentation bei Bugfixes etc.), das man nur ins Handbuch kucken m\u00fcsste?<\/p>\n In dieser Gr\u00f6\u00dfenordnung geht das einfach nicht mehr. Dazu kommt, dass Infor t\u00e4glich um die zwanzig Solutions ausliefert, dass sich also jeden Tag in einem ganzen Haufen Skripten ein ganzer Haufen Wenn-Danns \u00e4ndert, und dass es also vom exakten Solutionstand auf dem Kundensystem abh\u00e4ngt, wie sich das System konkret in den letzten Details verh\u00e4lt.<\/p>\n 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\u00f6nnen. Warum springt diese bl\u00f6de 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\u00f6sung in dem Programm konkret implementiert ist, kann das auch nur so sein, das steht nur weder in Hilfe, noch im Handbuch.<\/p>\n Mit Source: zwei Minuten. Ohne: Entweder man hat Gl\u00fcck, 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\u00e4llt.<\/p>\n 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.<\/p>\n 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\u00fcssten. F\u00fcr das viele Geld, das wir kriegen. Es geht darum, ob man p\u00fcnktlich live gehen kann, weil die Berater produktiver sein k\u00f6nnen.<\/p>\n Bug gefunden<\/p><\/div>\n Software hat Fehler. So isses nunmal, leben wir damit. Infor hat gl\u00fccklicherweise ein funktionierendes System, mit dem Bugs gemeldet und Bugfixes kontrolliert eingespielt werden k\u00f6nnen.<\/p>\n Nur: Das System ist in manchen Situationen zu tr\u00e4ge, und zwar so tr\u00e4ge, 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\u00fcr das einzelne Anwenderunternehmen.<\/p>\n Konkretes Beispiel gef\u00e4llig? Im ERP-LN-Service ist es derzeit nicht m\u00f6glich, das Steuerland einer Ist-Bearbeitungskostenposition zu \u00e4ndern. Der Kunde, bei dem mir das aufgefallen ist, hat gl\u00fccklicherweise Sourcecode, so dass ich wei\u00df<\/i>, 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.<\/p>\n Dort geht jetzt der Tanz los: Wenn wir die \u00c4nderung des Landes zulassen, was passiert dann im Normalfall? Nix. Aber was passiert im Sonderfall? Was, wenn die ausf\u00fchrende Abteilung und die am Auftrag h\u00e4ngende Abteilung unterschiedlichen Fibu-Firmen angeh\u00f6ren? Was in diesem Sonderfall, was in jenem?<\/p>\n Das zu kl\u00e4ren, und sauber zu reparieren, so dass es bei allen<\/i> Kunden funktioniert, dauert.<\/p>\n 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\u00f6nnen. Wir haben auch keinen anderen der vielen denkbaren Sonderf\u00e4lle. Wir haben einfach nur einen Fiskalvertreter in England, so dass wir gezwungen sind, bei Auftr\u00e4gen in England englische Steuerregelung zu beachten – und das macht diesen Bug zum Showstopper f\u00fcr ein ganzes Paket. Gl\u00fccklicherweise gibt’s ein Sourceodeagreement: Die Skripte hochziehen und das Problem so zu bereinigen, dass es f\u00fcr das konkrete Anwenderunternehmen<\/i> keines mehr ist, ist eine Sache von 15 Minuten. Party kann stattfinden.<\/p>\n Es geht nicht darum, ob Infor verpflichtet ist, solche Fehler zu l\u00f6sen. Es geht darum, ob man p\u00fcnktlich live gehen kann.<\/p>\n Nun, mit der 4GL-Entwicklungsumgebung von Infor steht eines der besten Systeme f\u00fcr gesch\u00e4ftskritische Transaktionssysteme zur Verf\u00fcgung, 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\u00fcr das ERP-System betreibt, ist schon nicht zu untersch\u00e4tzen.<\/p>\n Diese Addons m\u00fcssen 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).<\/p>\n 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\u00fcr die praktische Arbeit reicht diese aber einfach nicht aus.<\/p>\n 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 \u00fcbergeben) nach dem Einspielen einer Solution auf einmal ge\u00e4ndert hat. Selbst wenn ein Addon also lange funktioniert hat, kann es nun auf einmal einen Programmabbruch verursachen. Die einzige Chance, das Addon wieder lauff\u00e4hig 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.<\/p>\n Mit anderen Worten: Alle Anpassungen und Erweiterungen m\u00fcssen 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\u00fcrlich bezahlen). Einfacher und billiger ist es, auf Ihrem eigenen System zu entwickeln oder eben entwickeln zu lassen. Und dazu brauchen Sie Sourcecode.<\/p>\n Es geht nicht darum, keine Softwareerweiterungen zu schreiben und auf Produktivit\u00e4tsvorteile zu verzichten. Es geht darum, diese Addons mit geringem Aufwand auch Warten zu k\u00f6nnen.<\/p>\n Ich bin ja bekannt als Verfechter einer “Sourcecode auf jedem Kundensystem”-Politik, zu der ich Infor und Infors Kunden gerne bewegen w\u00fcrde. Gegen den Strom Infors Strategie ist leider im Moment sehr gegenteilig ausgerichtet, man...<\/p>\n","protected":false},"author":1,"featured_media":386,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/posts\/350"}],"collection":[{"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/comments?post=350"}],"version-history":[{"count":4,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/posts\/350\/revisions"}],"predecessor-version":[{"id":409,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/posts\/350\/revisions\/409"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/media\/386"}],"wp:attachment":[{"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/media?parent=350"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/categories?post=350"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/all-in-for-erp.com\/de\/wp-json\/wp\/v2\/tags?post=350"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Aber kein Unternehmen ist Standard<\/h1>\n
1. Verst\u00e4ndnis der Softwarelogik<\/b><\/h1>\n
![\"man-211505_1280\"](\"http:\/\/all-in-for-erp.com\/de\/wp-content\/uploads\/sites\/2\/2016\/05\/man-211505_1280-300x169.jpg\")
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\u00fcrlich die wesentlichen Prinzipien, und auch sehr sehr viele Details. Aber eben nicht jedes klitzekleine Fitzelchen Funktionalit\u00e4t.<\/p>\n2. Bugfixing<\/b><\/h1>\n
![\"Bugfixing\"](\"http:\/\/all-in-for-erp.com\/de\/wp-content\/uploads\/sites\/2\/2016\/05\/chrobak-813479_640-300x200.jpg\")
3. Software-Erweiterungen<\/b><\/h1>\n
![\"puzzle-693870_1280\"](\"http:\/\/all-in-for-erp.com\/de\/wp-content\/uploads\/sites\/2\/2016\/01\/puzzle-693870_1280-150x150.jpg\")
Glauben Sie mir: Der Standard reicht nie. Selbst wenn Sie das Kernverhalten der Software nicht \u00e4ndern wollen, werden Sie fr\u00fcher oder sp\u00e4ter feststellen, dass es Zeitersparnis im betrieblichen Alltag bringt, wenn bestimme Gesch\u00e4ftsfunktionen ins ERP-System integriert werden, die im Standard nicht vorhanden sind. Oder dass es sinnvoll ist, die Flexibilit\u00e4t des Standards einzuschr\u00e4nken, weil die Anwender sonst zu viel Mist bauen. Oder dass sie Einzelschritte, die der Standard sie abzuarbeiten zwingt, automatisieren wollen.<\/p>\n4. Programmieren lernen<\/b><\/h1>\n
![\"Lernen\"](\"http:\/\/all-in-for-erp.com\/de\/wp-content\/uploads\/sites\/2\/2016\/05\/laptop-1071781_1280-300x177.jpg\")
ERP LN verf\u00fcgt \u00fcber eine eigene Programmiersprache. Die muss man sich erstmal erarbeiten. “Schulen und dann kann der programmieren” funktioniert leider nicht: Jeder, der regelm\u00e4\u00dfig Software entwickelt wei\u00df, dass man das “Coden” in einer Programmiersprache nur dadurch lernt, dass man den Quellcode Anderer lesen und sich daran orientieren kann. Die gr\u00f6\u00dfte und so ziemlich einzige (brauchbare) Codebasis, die f\u00fcr die Baan-4GL-Programmiersprache vorhanden ist, ist nun aber der Sourcecode der Baan-Anwendung. Wenn dieser nicht verf\u00fcgbar ist, wenn Sie (oder Ihre Leute) aber f\u00fcr 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\u00e4llen ziemlich gruselig programmiert. Da, wo Sourcecode vorhanden ist, ist die Qualit\u00e4t in der Regel immerhin deutlich besser (meiner Meinung nach immer noch zu schlecht, aber besser). Besserer Anpassungcode hei\u00dft bessere Wartbarkeit, und weniger M\u00fcnzen, die man bei Releasewechseln einwerfen muss.<\/p>\n","protected":false},"excerpt":{"rendered":"