Midrange (Quattro, AS400, System36) ablösen

Navision · Shopware · App

Print Friendly, PDF & Email

Voraussichtliche Lesedauer: 32 Minuten

Immer wieder liest man von gescheiterten Versuchen, ein über Jahrzehnte gewachsenes Großrechnersystem mit einer „kleinen“ Lösung wie Navision oder Business Central abzulösen. Gründe für das Scheitern gibt es viele. Und alle sind sie unnötig.

Warum? Navision / Business Central ist der „natürliche“ Nachfolger jeder SNI/Comet/AS400 Lösung.

–> Weil Navision und Business Central dem gleichen Prinzip der Datengetriebenheit folgen, welches neben der AS/400 mit ihrer DB1 auch schon Clipper & Dbase damals zum Erfolgsmodell machte.

Ach… übrigens: Auch Access ist so eine datengetriebene Anwendung. Auch für Access ist Navision bzw. neu Business Central eine natürliche Ablösung.

Ein einfacher Grund fürs Scheitern ist z.B. schlicht der Zeitdruck, geschuldet der Not. Zeitdruck entsteht, weil es z.B. keine Teile mehr für die AS400 gibt, niemand mehr weiß, „wo diese AS/400 eigentlich im Haus steht“ (Echt! Erlebt!), oder/und der bisherige hauseigene AS/400 oder Crossbasic/Netbasic (ehemals Business Basic) Spezialist endgültig in Rente geht. Oder, auch beliebt für Zeitdruck: Weil er schon in Rente gegangen ist. Bestenfalls. Schlechtestenfalls gestorben .

Dann wird es eng für eine Access oder Midrange-Ablösung. Man sucht auf die Schnelle einen Partner, der „Die Umstellung schnell, einfach und billig macht“. Und dann? Fällt einem das Ganze auf die Füße. Warum ist das so? Was machen die alten Midrange- und Großrechner einer Lidl oder einer Liqui-Molly , einem Haribo, einem Otto oder gar einer Deutschen Post denn so viel besser oder anders als eine moderne Warenwirtschaft wie Navision / Business Central auf mehr oder weniger standardisierter Hardware aus dem Baumarkt?

Spoileralarm: Es ist NICHT, wie eine AS400 grafische Elemente, Mails oder Webshops integriert. Diese Lösungen sind meist ohnehin sofort als „angeflanscht“ oder „übergestülpt“ oder „geht halt nicht anders“ zu erkennen (aber… Sie laufen!).

Dabei sollte eine Ablösung einer datengetriebenen Systemplattform durch eine neue, ebenfalls datengetriebene Lösung wie Navision (Business Central) doch eigentlich kinderleicht sein? Ich kann ja auch einen Mercedes-Transporter recht einfach durch einen Ford-Transporter ersetzen.

Wo liegen also die Stolpersteine, die solche AS400 oder Access Projekte scheitern lassen?

Frühe Verwandtschaft von AS400 & Navision Dynamics & Microsoft Business Central 365

In der heutigen Business Central Welt ist das sicherlich nicht mehr bekannt. Aber der Datenbankserver von Navision (damals noch Navision Dynamics) lief schon einmal nativ auf der AS/400!

Etwa in 2000 wurde eine AS/400 Version des nativen Datenbankservers angeboten. Diese Navisionversion war zu dieser Zeit eine Revolution, und zwar keine kleine! Während die damaligen 2.01er und 3.01er SQL-Gehversuche von Navision eher als kläglich zu bezeichnen waren („Folter“ war auch ein naheliegender Begriff), gab die AS/400 (AS400) dem nativen Datenbankserver von Navision (damals gab es noch kein Business Central) einen unglaublichen Leistungskick. Der native Datenbankserver war schon immer rattenschnell, und Microsoft musste sich ganz mächtig strecken, um das SIFT-Model (der technologische Kern der Flowfields) nach und nach im SQL-Server abbilden zu können.

Exkurs: Die optische Verwandschaft von Access und Navision ist sogar so groß, dass die ersten Designkurse für den damals brandneuen Reportgenerator von Navision unter… Access gemacht wurden 🙂 „Unter der Haube“ kann Access natürlich Navision und erst recht nicht Business Central das Wasser reichen.

Dabei war die native Datenbank von Navision (im Kern noch die Version von 1993!) sehr einfach aufgebaut. Ihr einziges Problem zu dieser Zeit: Sie konnte nur Table-locking. Und durch eine – Nun, nennen wir es einmal „etwas unorthodoxe“ – Sicherstellung der lückenlosen Buchführung startete jeder Buchungsprozess mit einem Tablelock auf die Artikelposten (Tabelle 32) bzw. Fibu Buchungspostentabelle (Tabelle 17).

In den Alltag übersetzt: Sobald irgendjemand im Haus ein Fibubuchungsblatt, ein Artikelbuchungsblatt, eine Einkaufsbestellung oder eine Verkaufsrechnung buchte, war jeder andere Buchungsvorgang dazu verdammt, auf das Ende(!) des vorherigen Buchungsvorganges zu warten. Und verbunden mit großen, kleinen und kleinsten Programmierer/Designfehlern merkte jeder im Verkauf, wenn die Fibu wieder Kontoauszüge verbuchte. Das musste nicht so sein, aber schon damals gab es schlechte Navisionprogrammierer. 🙂

Und dann kam die Version des nativen Navision Datenbankservers für AS400… was übrigens auch gar nicht schwer war. Einen Unix-Server gab es schon lange und so war der Schritt zur i5 oder AS400 nur sehr klein. Einer Ablösung stand damit nichts mehr im Wege.

Und dieser Server hatte es in sich. Galten vorher, also so etwa bis zum Jahr 2000, 80-120 User auf einer Navision-Datenbank für „gut machbar“ (eine Umschreibung für „gerade noch so“), so wurden mit der AS400 plötzlich im Monatsrhythmus 150, 200, 250, zuletzt 400 User von Navision freigegeben (Microsoft war bis dahin „nur“ strategischer Partner, noch kein Namensgeber). Ohne eine Änderung im Navision-Programmcode zeigte die AS400 der etablierten Serverhardware, wo der Barthel den Most holt.

Und der Microsoft SQL-Server konnte diesem nativen Datenbankserver weder auf Windows, Unix, OS/2 (Jupp, gab es auch!) das Wasser reichen, oder auch nur ansatzweise mit der AS/400 konkurrieren. Daher wurde dieser Zweig auch sofort eingestellt, als Microsoft in 2002 Navision kaufte. Und durch eine klare Fokussierung auf den MS-SQL Server abgelöst. Schade.

Damit kommen wir zu…

Die wichtigsten Punkte für den Erfolg der Altsysteme

Die alten Systeme waren weder besser noch magischer als die Techniken, die heute zur Verfügung stehen. Der wesentliche Vorteil war schon damals die tiefe Integration der Datenbank/Datenhaltung in die zur Programmierung zur Verfügung stehenden Sprachen wie Cobol und RPG unter der System36 bzw. AS400 (heute System i) auf der IBM Seite und in das Business Basic auf der Siemens Nixdorf Quattro Pro Seite (mit der Comet Warenwirtschaft & Finanzbuchhaltung). Etwas moderner betrifft das auch Access.

So brauchten sich die Entwickler auf diesen Systemen niemals ernsthaft um die Datenhaltung, Datenspeicherung, Datenabfrage kümmern: Die Daten wanderten einfach in den Datenspeicher (DB2 bei der AS400, Dateien auf der SNI Quattro Pro Seite). Und per Befehl tauchten diese auch einfach so wieder auf und das auch noch in einer vorhersehbaren & vorherbestimmbaren Reihenfolge. Bei den älteren Systemen von IBM und SNI mit heute sehr angestaubten Bildschirmmasken, aber schnell und zuverlässig.

AS/400 Bildschirmmasken: Nicht für jeden Lesbar, nicht für jeden bedienbar. Aber irre schnell und unkaputtbar. Ganz so wie die früheren Navision / Business Central Versionen :-)
AS/400 Masken brauchten typischerweise eine längere Einarbeitungszeit. Aber dann waren sie auch schnell zu bedienen, und das ganz ohne Maus und Schnickschnack.

Wenn Sie sich schon mit Navision bzw. Business Central beschäftigt haben, sollte Ihnen das sehr bekannt vorkommen: Gerade in der Blauen („Dos-Navision“) und den Legacy-Versionen von Navision bis zu Navision Dynamics 2009R2 besitzt Navision ganz genau die gleiche Magie… bzw. den gleichen Technologievorsprung, der die echten, für den Bediener sichtbaren Cobol & RPG-Programme der AS400 und der Business Basic der (überwiegenden) Comet Anwendungen so erfolgreich, zuverlässig und (für damalige Verhältnisse) unglaublich schnell gemacht hat.

Genau diese Verwandtschaft der datengetriebenen Programmierung macht das Ablösen, eine Migration von einer Comet oder einer AS400 so unerwartet einfach! Kennen Sie noch dBase und Clipper? Die gleiche Datengetriebenheit steuert auch eine AS400 und Navision / Business Central.

Von Informatikern erstellt

Diese Kerntechnik, diese Datenhaltung oder Datenbank (auf der Siemens Nixdorf Quattro über calls im Dateisystem abgebildet), wurde von Informatikvordenkern wie z.B. Edgar Codd entwickelt.

Da Rechenkapazität und vor allem Datenzugriffe auf Langzeitspeicher wie Festplatten damals nicht unbegrenzt zur Verfügung standen, wurden diese Datenbanksysteme auf die maximale Leistung der zugrunde liegenden, im Wesentlichen nicht modifizierbaren Hardware getrimmt. So wie heute noch Spiele von Spielekonsolen darauf ausgelegt werden, das Maximale aus der gegebenen Hardware auszureizen.

Business BASIC - Das professionelle BASIC für Großrechner von NixdorfSpotlight-Reporter
Egal ob nativ auf den SNI-8870 Terminals oder per Terminal unter Windows: So richtig „schön“ waren die Siemens Nixdorf Comet Masken nicht gerade. Aber eine CPU der 80386 Klassen reichte für locker 30 Mitarbeiter!


Hiermit haben die Systementwickler, also die Architekten der System36, später AS400 bzw. der SNI die Grundlagen, die Fundamente dafür gebaut, effiziente, datengetriebene Programme zu entwickeln. Jeder, der auf diesem Fundament aufbaute, konnte so von der hochkomplexen Vorarbeit der Systemarchitekten profitieren… wenn er denn die Begrenzungen der Systeme kannte und beachtete.

Von Fachleuten modifiziert

Die Warenwirtschaften, Finanzbuchhaltungen, Lohnsysteme, die später auf diesen Fundamenten aufbauten, wurden in aller Regel von Fachleuten der jeweiligen Aufgabengebiete zumindest betreut, wenn nicht sogar selbst programmiert.

Siemens Nixdorf Quattro Pro Terminal 8850 8860 8870. Der Erfolg dieses Computers war untrennbar mit der (um Datenbankfunktionen erweiterten) Business Basic Sprache verbunden. Datenzentrierte Anwendungen waren damit kinderleicht erzeugbar. So wie unter PRG und Cobol auf der AS400, in der auch die hauseigene Datenbank DB2 ein integrierter (Erfolgs-)faktor war. Vorbild von Navision / Business Central.
Siemens Nixdorf Quattro Pro 8850 8860 8870 Terminal. Der Erfolg dieser Arbeitsmaschinen war untrennbar mit der um Datenbankfunktionen erweiterten Business Basic Sprache verbunden. Datengetriebene Anwendungen waren damit -sprichwörtlich- im Handumdrehen erzeugbar. So wie auf der AS400 unter PRG und Cobol, in denen auch die hauseigene Datenbank DB2 ein untrennbarer (Erfolgs-)faktor war. Es gab keine AS400, i5 oder System36 ohne die DB2. Ganz so wie später -und moderner- Navision Dynamics und dem Nachfolger Microsoft Business Central 365, welche ja auch ihre Datenbank als Kernmodul der agilen Entwicklung voraussetzen bzw. gleich mitbringen.

Hier hat sich nichts von meiner 90er Aussage geändert: Ich mache eher aus einem Buchhalter einen ausreichend guten Programmierer als aus einem Programmierer einen ausreichend guten Buchhalter. Das war auch damals so, dank der Vorarbeiten der Systementwickler.

Die Rahmenbedingungen, in denen sich die Programme damals bewegten, wurden bereits durch das Datenbankmodel der SNI Quattro oder AS400 vorgegeben. Eine Verletzung war in bestimmten Bereichen gar nicht möglich, z.B. eine Abfrage mit oder ohne Filterung ohne einen Index (eine Sortierungsvorgabe).

Natürlich konnte man dann immer noch einen falschen Filter, oder einen unpassenden Index (Sortiervorgabe) auswählen. Das wurde dann aber so radikal schnell von dem System mit exorbitanten Antwortzeiten bestraft, dass auch dem schlechtesten Programmierer schnell bewusst wurde, dass er oder sie Mist gebaut hatte.

Noch heute ist das für mich ein Grund, Entwicklungen hin und wieder auf Servern mit sehr wenigen Kernen und sehr wenig Arbeitsspeicher auszutesten. Wenn erst der Cache oder die Hardware retten muss, was der Programmierer / Entwickler vorher verbogen hat, ist das Kind bereits in den Brunnen gefallen. Wenn man das rechtzeitig bemerkt (Dazu muss man aber vorher schon ein paar Grundregeln in den Wind geschossen haben.), kann man das Kind wenigstens noch an den Beinen packen, bedeutet: Man kann oder sollte die Entwicklung noch einmal überdenken.

Auf Effizienz getrimmt

Die alten Systeme, wie eben eine IBM AS400, eine System36 oder gar eine SystemR, waren, genauso wie eine Siemens Nixdorf Quattro, 8860 oder 8870 mit der Warenwirtschaft Comet von Beginn an aufeinander abgestimmt. Entwickler kannten die Rahmenbedingungen, die Einschränkungen, aber natürlich auch die genialen Möglichkeiten der Systeme. Da diese sich auf engen Schienen bewegten, war die Einarbeitungszeit für Programmierer oft erstaunlich kurz und die Qualität der geschriebenen Anwendungen oft (natürlich auch nicht immer) auf sehr hohem Niveau.

Eine Siemens Nixdorf Quattro Pro 88xx (8850 oder 8860 oder 8870?), vergleichbar mit und Wettbewerb zu der AS400 von IBM.
Sexy waren sie nicht, die Midrange und Großrechner der 80er. Was war es dann, was sie so erfolgreich machte? Es war immer die integrierte Datenhaltung! Das um Datenbankelemente angereicherte BusinessBasic (heute CrossBasic oder NetBASIC) der SNI Quattro mit Comet, oder eben das eng mit der DB2 verzahnte Cobol & RPG der AS400. Genau der gleiche Erfolgsmotor wie die integrierte, datengetriebene Entwicklungsumgebung von Navision Dynamics, z.B. 2009R2, oder Microsoft Business Central 365. Schade, dass Microsoft selbst diese Kraft der datengetriebenen Entwicklung nicht verstanden hat. Übrigens genauso wie bei Access.

Durch die Vorgaben der Systeme gab es auch eine sehr konsistente Bedienerführung. Aus heutiger Sicht anachronistisch, geradezu eine Beleidigung für das Auge und den Mausklick gewöhnten Zeigefinger. Aber eben konsistent durch das ganze System hindurch wiedererkennbar. Im ganzen Comet galt: F3 legt einen neuen Datensatz (Auftrag, Kunde, Lieferbedingung) an, F4 löscht einen Datensatz. Egal, wo / in welchem Programm man sich gerade befand. Wem noch „DOS-Navision“ (die blaue Version) oder das „alte Navision“ (Windows-Navision von der Version 1.3, 20.1 bis zur Version 2009R2) geläufig ist, kommt das gewiss bekannt vor. 🙂

Sie finden noch mehr Informationen zu diesem spannenden Thema hier.

Die häufigsten Fehler der Neusysteme

Es gibt unglaublich viele Fehler, die man machen kann. Doch es kristallisieren sich gängige Muster der Todsünden beim Migrieren/Updaten aus einer alten, abzulösenden Warenwirtschaft heraus. Das betrifft hier nicht nur die gute alte AS400, System i oder andere Programme auf Cobol, RPG oder Business Basic Basis. Diese Todsünden betreffen so gut wie jede Migration von Software. Ich gehe hier aber aus naheliegenden Gründen jedoch direkt auf meine Erfahrung in Rettungseinsätzen von Migrationen auf Navision oder Business Central 365 ein.

Denn dies ist ein Fakt: In meiner Zeit als Selbstständiger (Freelancer) Navision / Business Central Berater, Trainer, Programmierer, Gutachter wurde ich bis heute noch nie zu einer Navision / Business Central (BC) Migration „auf der grünen Wiese“ gerufen. Ich wurde immer nur gesucht und gefunden, wenn das Kind bereits so tief im Brunnen steckte, dass es mit dem Kopf im Wasser steckte, und die Füße für jeden Retter unerreichbar waren.

Erst dann, so meine Erfahrung, sind Entscheider bereit, sich meine Konzepte anzuhören. Oft war dann das Ergebnis ein kompletter Neuanfang.

Einsatz von „Branchenlösungen“

Die Todsünde schlecht hin. Wirklich. Seit ich Kontakt zu Navision habe, und das ist seit 1993 der Fall, habe ich nur Leid mit diesen sogenannten „Branchenlösungen“ erlebt. Darum schreibe ich diese Bezeichnung hier auch nur in Anführungsstriche.

Warum ich so wenig von diesen „Banchenlösungen“ halte? Dazu muss man Folgendes wissen:

Wie entstehen „Branchenlösungen“?

Navision / Business Central „out of the Box“ kann schon unglaublich viel: Auftragserfassung, Bestandsführung in beliebig vielen Lagern, unbegrenzte Lieferadressen, Umlagerungen auch über Hallengrenzen hinweg („Betriebstätten“), Kostenrechnung, Dimensionsbuchhaltung (Kostenstellen & Kostenträger? Das ist was für Anfänger wie Datev, Diamand, H&S… Navision / Business Central kann schon seit Jahrzehnten mit beliebig vielen Buchungsdimensionen umgehen! Nicht nur 2. Allein darüber könnte ich einen ganzen Tag referieren… Das ist konkurrenzlos in der Finanzbuchhaltungswelt!!), komplizierte Preisberechnungen (aber tatsächlich im Standard keine Aufschlagrechnung!), Vertreterabrechnungen, Auswertungen, ABC-Analysen (na ja… mit minimalen Anpassungen).

Navision / Business Central kann „out of the box“ Rechnungen drucken, Lieferscheine mailen, die neuen Versionen ab dem RTC können direkt PDFs und Mails aus der Applikation erstellen (die alten auch, mit etwas Nachhilfe…).

Die (aus meiner Sicht) beste, einfachste und leistungsfähigste Finanzbuchhaltung ist auch immer mit an Bord.

Rene Store  - - auch keine Branchenlösung
Rene Store… Man kann einfach Rene irgendwo dran schreiben. Aber dann ist da noch lange kein Rene (Thöne) drin. Mit den „Branchenlösungen“ ist es genauso.

Mit diesem Fund kann also jeder einzelne Navision-Verkäufer oder Business Central Berater oder auch jedes Systemhaus wuchern. Das ist eh immer da, und das funktioniert immer! Von Anbeginn. Einfach nur installieren, und Sie können -im Prinzip- erst einmal ein Unternehmen nach GOB steuern. Sogar die GdPDU Logik ist schon vorbereitet, UVA’s könnte das System. Ein bisschen einrichten, vielleicht einen richtigen SKR03 oder SKR04 rein, und fertig.

Und dann kommt (oder besser: kam) ein Holzhändler, ein KFZ Händler, ein Schlachter, ein Lebensmittelproduzent, ein Gebäudemanagement-Unternehmen zu irgend so einem Systemhaus und sagte: „Das ist ja schön und gut, aber wir brauchen noch folgende Funktion:“

Und das Systemhaus sagte: OK, gib uns Geld dafür, dann passen wir Dir Dein Navision Dynamics oder Microsoft Business Central genau auf diese Wünsche an, auf dass wir beide glücklich werden.

Und der Kunde gab Geld. Und das Systemhaus tat, wie ihm geheißen. Und beide lebten glücklich und zufrieden, bis…

…Ja. Hier fängt das Elend an. Das Systemhaus dachte sich: Ui, so haben wir überaus füllig Anpassungen der mächtigen Sorte. Vermögen wir es, diese erneut in güldene Taler zu verwandeln? Und das Systemhaus hänge sich eine Fahne vor den Wams und an das Büro: Wir haben eine „Branchenlösung“ für KFZ-Händler/Fleischerei/Holz/Immobilienhandel…

Doch in den meisten Fällen war es so, dass das Systemhaus keine grundlegenden Kenntnisse dieser Branche hatte. Woher auch? Sie haben ja nur in 2-20 Wochen die Anpassungen umgesetzt, die der Kunde mehr oder weniger qualifiziert gefordert hat. Und die dann das Systemhaus mehr oder weniger qualifiziert umgesetzt hat.

Und dann passierte das, was passieren muss: Der nächste Kunde kommt um die Ecke, liest das Schild „Branchenlösung“, und… kauft!

Der Kunde merkt dann aber schnell und schmerzhaft, dass die Geschäftsprozesse, die sein Vorgänger (Sie erinnern sich? Der erste Fach-Kunde von dem Systemhaus…) sich ausgedacht hat, bei ihm gar nicht passen. Das gibt Zoff und zusätzliche Anpassungen und damit zusätzliche Kosten. Irgendwann läuft das Ganze.

Nun hat das Systemhaus eine noch stärker verbogene „Branchenlösung“, die immer weniger mit dem eleganten (Echt!), schnellen (Echt!) und fehlerfreien (Echt!) Navision oder Business Central zu tun hat, welches Microsoft einmal auf die DVD gebrannt hat.

Das stört den BC-Händler aber nicht! Er hat Morgenluft gerochen, oder noch genauer: Geld. Und da sage noch einmal jemand: Geld stinkt nicht. Und so kommt ein weiterer Kunde, hinterlässt ein noch weiter verbogenes System für die nachfolgenden Kunden.

Inzwischen wechseln die Entwickler im Systemhaus, unerfahrene Programmierer machen noch mehr kaputt, usw. usw.

Genau so entstehen „Branchenlösungen“!

Was ist das Problem von „Branchenlösungen“?

Sie geben vor, die Probleme einer ganzen Branche in einem einzigen Paket abbilden zu können. Diese Pakete haben sich jedoch viel zu weit von dem ursprünglichen Navision / Business Central entfernt, und enthalten unter der Oberfläche (teils aber auch direkt sichtbar) schlimme Programmfehler, die in immer mehr Kundeninstallationen verbreitet werden.

Außerdem tendiert der Markt, der Kunde und das Systemhaus dazu, Kunden zu überfrachten. Vielleicht braucht der 20. Autohändler für genau seine Abläufe (Prozesse) nur eine winzige Anpassung am Standard. Aber er bekommt ein verbogenes, fehlerträchtiges und fehlerstrotzendes Navision oder Business Central 365 serviert, und soll sich nun damit anfreunden.

So viel, so kurz: Das wird nix!

Dies ist übrigens eine Spezialität des Navision / Business Central Marktes! Früher entstanden Branchenlösungen, indem sich qualifizierte Entwickler mit qualifizierten Beratern und ausgesuchten Kunden zusammensetzten, branchenspezifische Details abklopften und diese dann ganz gezielt umsetzten.

Ein Softwarehaus hat meistens nur ausreichende Kapazität, um eine einzige Branche, z.B. Frisöre, KFZ-Werkstätten, Handwerker oder Banken abzubilden und zu betreuen. So baute sich auf der Software-Anbieterseite ein enormes Fachwissen der jeweiligen Branche auf.

Oft arbeiten bzw. arbeiteten auch Fachleute der jeweiligen Branche direkt im Softwarehaus, um zwischen Kunden und Entwicklern zu vermitteln, bzw. um zu übersetzen. Früher war nicht alles besser, um Gottes Willen. Eigentlich war nur -wenn wir ehrlich sind- sehr wenig besser. Außer vielleicht Sonntag. Früher war Sonntag, heute ist Montag. Aber dieser Fakt, dass die Branchenpakete, die man ohne “ schreiben darf, wirklich zu der jeweiligen Branche passten: DAS war wirklich besser.

Heute -und speziell im Navision / Business Central Umfeld- wurde daraus im Wesentlichen: „Wir haben schon einmal einen Kunden oder zwei aus dieser Branche bedient“. Auch wenn schon keiner der damaligen Mitarbeiter mehr im Systemhaus angestellt ist. Und sich das „branchenspezifische Fachwissen“ auf „Da lässt sich viel Geld verdienen“ reduziert hat.

Einsatz von Programmierern statt Informatikern

Das ist in der Tat keine Wortklauberei, das ist ein Riesenunterschied. Die früheren Basissysteme (Also z.B. Navision / Business Central „out of the box“, Trampolin, aswaw400 (as/waw 400), Oxaion, Portolan, Perform, LFS400, Charisma, Assistent… auf der AS400, Comet (gab es da überhaupt eine Alternative?) auf der Siemens Nixdorf Quattro Pro 8870, 8860 mit Business Basic (bzw. den Derivaten Cross Basic, Surfbasic und NetBasic) oder ganz andere Systeme wie Steeb, wurden und werden als Grundversion in enger Zusammenarbeit zwischen Anwendungsfachleuten und Informatikern entwickelt.

OK, Bei Microsoft ist das eingerissen, das merkt man an der Qualität und dem (Un-)Sinn neuer Funktionen.

Somit waren (und, eigentlich, auch sind) die Grundversionen der jeweiligen Warenwirtschaften erfahrungsgemäß sehr flink und stabil.

Erst durch die Modifikation von Programmierern, die viele Grundlagen der IT gar nicht mehr beherrschen, werden diese Systeme langsamer und Fehlerträchtiger.

Das war und ist in einzelnen Unternehmen auch kein großes Problem!

Wenn der „weißhaarige Computergott“ mit dem Schraubenzieher einen Kratzer in „seine“ Warenwirtschaft oder Finanzbuchhaltung (ERP) macht, dann kann er (meistens) noch sehr gut nachvollziehen, wodurch dies verursacht wurde und seine Änderung sofort zurücknehmen oder korrigieren.

Wenn aber ein Programmierer, der den Hintergrund einer Änderung gar nicht kennt und welcher die Basisapplikation, z.B. Navision oder Business Central, noch gar nicht durchdrungen hat, so eine Änderung macht… Oh je!…

Und wenn dann diese Änderung versteckte Fehler hat und diese an viele Kunden ausgeliefert werden…. Oh je!…

Und wenn dann dieser Programmierer das Systemhaus verlässt, und ein noch weniger erfahrener Nachfolger an diesen schon kaputten Programmen weiter herumbastelt… Oh je! Oh je! Oh je!…

Einsatz von Verkäufern statt Beratern

Früher wurden solche Systeme sehr oft nicht von klassischen „Eisschrank-am-Nordpol-Verkäufern“ verkauft. Stattdessen bat ein Kunde um einen Vorführtermin und die ersten Gespräche dazu wurden bereits mit Fachleuten, Fachberatern geführt, welche ihr Produkt gut bis sehr gut kannten. So wurde auf der Kundenseite sofort die Erwartungshaltung auf das Machbare korrigiert und die (Änderungs-)Anforderungen wurden ebenfalls auf das Sinnvolle, Bezahlbare und Machbare korrigiert. So konnte bereits der Vertragsabschluss für beide Seiten klarstellen, was geliefert wird. Und eben auch: Was nicht.

Die in den 90ern üblichen hohen Deckungsbeiträge bei Softwareverkauf hat aber leider auch Verkäufer angelockt, die von dem eigentlichen Produkt nichts verstanden, die auch den Kunden nicht verstanden und auch nicht zwischen Kunde und Entwickler vermitteln konnten. Dem Kunden wurde (und wird) das Blaue vom Himmel versprochen… und dem Entwickler wird gesagt: Du machst das schon. Das muss verbrannte Erde hinterlassen… und genau das tut es auch oft.

Nicht selten suchen dann die Kunden ihr Heil darin, den hoffnungslos überforderten Programmierer selbst anzustellen, um zu retten, was noch zu retten ist. Und im Systemhaus wird wieder ein neuer, unerfahrener, vielleicht noch ein paar Euro billigerer Programmierer eingestellt, welcher von Navision / Business Central (noch) keinen blassen Schimmer hat… und von der „Branchenlösung“ auch nicht. Bingo!

Das muss wieder so werden wie früher

Die Sturheit (es gibt hier kaum höfliche Umschreibung, manchmal muss man sogar auf „Borniertheit“ zurückgreifen) der bisherigen Grossrechneranwender, ganz egal ob AS400 oder Comet oder Quattro Pro, ist in solchen Projekten auch legendär.

„Ja klar möchten wir alles ganz modern und so richtig schön machen. Beraten Sie uns bitte. Am Ende muss es aber alles wie früher machen, sonst können wir nicht arbeiten.“ Sie merken schon: Ich nutze lieber offene Worte, statt um den heißen Brei herum zu reden.

Mein eigenes einschneidendes Erlebnis dazu war eine Bastelpapierfabrik im Raum Kassel. Nachdem die Rechnungsformulare in Navision eingerichtet waren, wurden ein paar Testrechnungen geschrieben. Fast alle mit einem oder wenigen Cent Abweichung. Das wurde ein langer Abend…

Nach mehreren Stunden hatte ich den Fehler endlich gefunden: Die Siemens Nixdorf Quattro Pro, natürlich mit Comet, rechnete falsch! Sie hatte einen bisher nicht entdeckten Rundungsfehler mit Gruppenrabatten. Ich konnte dies mit Taschenrechner und Kugelschreiber auf den Originalrechnungen vorrechnen!

Der Kommentar des Geschäftsführers: Das haben wir schon immer so gemacht, dass muss auch weiter so gerechnet werden. Ich habe den Kugelschreiber & die Ausdrucke in die Ecke geworfen und ab diesem Zeitpunkt jeden Sch… umgesetzt, den der Geschäftsführer „so wie früher“ haben wollte. Und keinerlei Verbesserungsvorschläge mehr gemacht.

Mit und für solche beratungsresistenten Menschen sollte man keine unnötige Zeit verschwenden. Es wird sowieso nicht gedankt und ändern kann man in solchen Firmen sowieso nichts. Diese Denkweise geht immer quer durch das ganze Unternehmen, so meine Beobachtung.

Natürlich kann man auch in solchen Firmen erfolgreich Navision / Business Central einführen. Gerade die Werkzeuge bis zur BC 14 machen diese Produkte geeigneter als jeden Wettbewerb am Markt. Auch das eben beschriebene Projekt wurde umgesetzt und der beschriebene Fehler ist auch in 2022 noch in der inzwischen 2013er Navision Version noch eingebaut. Diese „Das haben wir schon immer so gemacht“ habe ich nirgendwo in einer dermaßen unflexiblen Betonkopfdenke erlebt wie unter den Anwendern der Grossrechnersysteme.

Hier müssen Sie sich als Auftraggeber sehr sehr kräftig an die eigene Nase fassen und sich für sich selbst die Frage stellen: Wollen Sie wieder alles so wie früher? Es wird Sie an Euro zusätzlich kosten, die Umstellung wesentlich verlängern, und Ihr System wird – genau wie früher, genau wie „Das war ja schon immer so“ – praktisch nicht updatebar werden. Egal, was Ihnen vorher versprochen oder zugesagt wurde.

Seit Business Central 15 werden einige der liebgewordenen Dinge Ihrer alten AS400/Siemens Nixdorf Quattro Pro Comet schlicht nicht mehr innerhalb der Basisapplikation umsetzbar sein. Hier können selbst kleine „Das muss wieder so wie früher“ unglaublichen Entwickleraufwand nach sich ziehen. Für Geld kann man viel bekommen…

Immerhin muss ich als Berater auch so fair sein und das Ganze zusätzlich aus Sicht der bisherigen Großrechneranwender sehen: Die Boliden im Keller arbeiten mit minimalen Veränderungen oft seit Jahrzehnten „auf genau diese haben wir schon immer so gemacht“ Weise und das ganze Unternehmen hat sich darum herum arrangiert. Dies führt Arbeitsweisen & Workarounds ein und verfestigt diese auf eine Art, die Navision / Business Central Entwicklern schlicht fremd ist.

In „unserer“ Welt leben wir von Dynamik und Veränderung, nicht von „Haben wir schon immer so gemacht“. Bei einer Großrechnerablösung treffen also regelrechte Paradigmenwelten aufeinander. Hier ist es umso wichtiger, bereits im Vorfeld auf Stärken und Schwächen einzugehen und auch auf Unmöglichkeiten hinzuweißen. Alles, was hier im Vorfeld versäumt wird, wird den Projektpartnern später tonnenschwer auf die Füße fallen.

Wie macht man es richtig?

Eigentlich ist die Zusammenfassung simpel: Etwas Demut. Etwas Demut vor dem gewachsenen, abzulösenden System. Aber auch vor dem neuen, ablösenden (einzusetzenden) System, z.B. (Aber nicht nur) Navision bzw. Microsoft Business Central 365. Daraus ergibt sich der ganze Rest schon fast wie von allein. So z.B.:

Respekt vor der IT

Retten Sie sich unbedingt die Unterstützung Ihres bisherigen EDV-Betreuers. Vorsicht! Das muss nicht unbedingt der EDV-Leiter sein. Bekommen Sie heraus, wer wirklich hilft und helfen kann, wenn sich ein Auftrag nicht verbuchen lässt. Ihre Mitarbeiter wissen das in der Regel. Die Betonung liegt auf Mitarbeiter. Abteilungsleiter haben oft schon nicht mehr genug Bezug zur Arbeit. Deshalb heißen sie auch Leiter, und nicht Arbeiter. Auch hier bestätigt die Ausnahme die Regel.

Wenn der IT-Verantwortliche echt Bock auf die neue Warenwirtschaft hat

Sie Glückspilz!

Das ist (siehe nächster Punkt) nämlich überaus selten der Fall. Halten Sie ihn bei der Stange! Geben Sie ihm Projektverantwortlichkeit. Geben Sie ihm Verantwortung. Integrieren Sie ihn in jede Besprechung. Schicken Sie ihn auf Schulungen. Versuchen Sie auf keinen Fall, ihn durch die neue Warenwirtschaft „abzuschießen“, nur weil Ihr Verkäufer (siehe weiter oben) gesagt hat, dass „Sie zukünftig keine IT mehr brauchen, das geht jetzt alles viel billiger in der Cloud.“

Dieses Versprechen wird nie gehalten. Nie.

Wenn der IT-Verantwortliche gar keinen Bock auf das neue ERP hat

Das ist oft die Ausgangssituation. Möglicherweise auch schon durch das Alter Ihres IT-Verantwortlichen geprägt. Oft werden solche Ablösungen von Altlösungen erst durch das drohende Ausscheiden des bisherigen IT-Leiters angestoßen. Manchmal auch danach.

Jahrzehntelang wurden die Pflege und Modernisierung der IT auf die lange Bank geschoben, auf die leichte Schulter genommen. Und dann die Nachricht: „Ey Cheffe, bin ich zur nächsten Weihnachtsfeier noch eingeladen?“

„Wieso?“

„Weil ich da doch schon in Rente bin. Übrigens… wer soll denn jetzt mein Nachfolger werden?“.

Und schon brennt die Hütte. Und jetzt, ganz schnell, mit aller Kraft, ein Nachfolgesystem installieren… Aber mit langsamem Anlauf. Bis alles viel zu spät ist. Und dann aber richtig. Sie kennen das…

Und dieser Mitarbeiter sagt dann: „Och, ich bin zu alt für diesen Scheiß.“ Oder „Ich brauch das nicht mehr, nächstes Jahr bin ich weg.“ Oder etwas ähnliches.

Und Sie stehen da, und sind auf das -oft nicht wirklich vorhandene- Know How Ihres neuen „Branchenlösungsexperten“ angewiesen. Oh je, oh je!…

Retten Sie sich den Goodwill Ihres bisherigen EDV-Betreuers! Bieten Sie ihm einen Beratervertrag an. Eine 3-Monatsreise auf die Malediven, wenn das neue System läuft. Einen Firmenwagen für die ersten 2 Rentenjahre. Egal was: Halten Sie ihn bei der Stange, nutzen Sie seine Erfahrung für Ihr Projekt. Lassen Sie die Neulinge, die Ihnen in wenigen Wochen ein über Jahrzehnte gewachsenes ERP ablösen sollen, von ihm lernen.

Jeden Cent, den Sie an dieser Stelle sparen wollen, werden Sie im Laufe des Projektes zehnfach an Ihr Systemhaus bezahlen.

Wobei es auch die Situation gibt (schon erlebt), dass eine Firma genau diese Gelegenheit nutzen will, um sich aus der Macht des bisherigen IT-Verantwortlichen zu befreien. Auch das geht. Dann muss man halt genug Energie in die Suche der guten Sachbearbeiter im Haus stecken.

Respekt vor den Mitarbeitern

Ihre Mitarbeiter, besonders die, die wirklich arbeiten, haben über die Jahre viel Fachwissen über Ihre Prozesse angehäuft. Oft haben sie Workarounds gefunden, die nicht mal Ihr IT-Leiter kennt. Vielleicht haben sie Prozesse in Exceltabellen ausgelagert („Schatten-IT“), die nun dringend in die neue Warenwirtschaft aufgenommen werden müssen. Integrieren Sie Ihre Leistungsträger (die müssen Sie erst einmal identifizieren…) in den Projektablauf.

Respekt vor den Arbeitsabläufen

Programmierer verstehen in der Regel nichts von Ihren Abläufen / Prozessen. Die lesen nur die Arbeitsbeschreibung von den Verkäufern (siehe dazu weiter oben) und programmieren dann das, was sie daraus verstanden haben.

Haben Sie als Kind gerne „Stille Post“ gespielt und sich dann am Ende über das Ergebnis totgelacht?

Ein Abteilungsleiter, der die Prozesse nicht lebt, erklärt einem Verkäufer, der das Unternehmen nicht kennt, wie eine Aufgabe abzulaufen hat. Der Verkäufer, der weder Ihr Unternehmen noch Navision / Business Central kennt, erklärt einem Programmierer, welcher beides kaum kennt, was dieser zu tun hat. Und dieser arme Programmierer ist am Ende immer der Schuldige, wenn das Ergebnis nicht so viel mit der Realität zu tun hat.

Stille Post für Erwachsene und mit Geldeinsatz….

Respekt vor der eigenen Applikation

Gerade als „junger Hüpfer“ juckt es einem gehörig in den Fingern, dem Kunden zu zeigen, wie toll doch Navision Dynamics und Business Central gegenüber den ollen Comet und AS400 Anwendungen ist.

„Klar machen wir das, geht ganz schnell.“

Sehr schnell verrennt man sich damit!

Praktisch jeder Navisionentwickler, der für mehr als 2 Firmen gearbeitet hat, hat schon einmal das Artikel-Beschreibungsfeld verlängert. Und Wochen, Monate oder gar Jahre sind ihm dann irgendwelche Buchungsblätter vor die Füße gefallen, die damit ein Problem hatten.

Auch das recht einfache Abschalten von „Data per Company“, z.B. für die Debitorentabelle 18 oder die Sachkontentabelle 15 oder, ganz beliebt, die Artikeltabelle 27. Und erst im Laufe des Projektes wurde auch dem begeistertsten Entwickler klar, was er (oder sie) da eigentlich für einen Riesen-Bockmist angezettelt hat.

Glücklicherweise hat Microsoft diesem Umtreiben nun einen dicken Riegel vorgeschoben. Leider mit massivem Kollateralschaden, sodass nun das (fast immer notwendige) Anzeigen von Name 2 & Beschreibung 2 in dutzenden von Pages eine Tagesarbeit ist…und eine gute Fingerübung für die ersten Extension-Schritte.

Respekt vor dem Datenbankserver

Ich bin mal mutig: 90% aller Menschen, die in Navision oder Business Central Anpassungen vornehmen, haben keine Ahnung davon, wie der Datenbankserver die nötigen Daten zusammenträgt. Mutig, weil ich denke, das 90% noch zu gering angesetzt ist.

„Transaktionen“: Wer dieses Wort nicht kennt, darf sich nicht wundern, wenn selbst vermeintlich kleine Änderungen an einem Flowfield, einer Page, einen Key danach das ganze ERP ausbremsen. Und wer hier meint, „Transaktion“ ist eine gebunde Datenmanipulation, die nur vollständig oder gar nicht durchgeführt werden darf, verwechselt hier den Unterschied zwischen Datenbank/Festplatten/Buchungstransaktionen.

Respekt vor der goldenen Regel

Sie können -ganz generell, nicht nur bei AS/400 (as400), RPG, Cobol, Navision, Comet- im Prinzip 3 Arten von Servicequalität auf dem Markt bekommen:

  • Gut
  • Billig
  • Schnell

Sie können sich -in gewissen Grenzen- auf dem Markt diese Kombinationen kaufen:

Merkzettel: Gut, Schnell und billig ist zusammen nicht möglich. Schon bei Comet nicht, auch nicht bei Navision, und auch nicht bei der AS400.
Merkzettel: Gut, schnell und billig ist zusammen nicht möglich.

  • Gut & Billig. Das ist nicht SCHNELL.
  • Gut & Schnell. Das ist nicht BILLIG.
  • Schnell & Billig. Das ist nicht GUT.
  • Gut, Schnell & Billig. Das ist NICHT MÖGLICH.

Kritisches Hinterfragen der eigenen Applikation & der bisherigen Abläufe

Das ist kein Zufall und keine Willkür, dass dieser Punkt als letzter aufgeführt wurde.

Auch die Qualität von Navision / Business Central wird, 100% Microsoft konform, immer schlechter.

Flowfields in Listen, beliebige Sortierungen in beliebigen Tabellen, Emulieren von Keys ohne Rückmeldung an den Entwickler: Ja, technisch ist das großartig, dass das geht. Aber in einem echten Unternehmen geht das eben nicht.

„Die Hardware ist zu schwach“ heißt es dann oft.

Nein, ist sie nicht. Die Anforderungen sind einfach unrealistisch.

Reservierung? Was für ein Molloch! Wie konnte es nur dazu kommen, ein schlechtes System so derart tief in das System einzugraben?

Lagerregulierung? Seit 20 Jahren eine Baustelle. Siehe auch gleitender-einstandspreis-in-navision-business-central

Vorauskasse Rechnung? Komplizierter geht es immer, muss sich da einer gedacht haben… und es dann auch noch komplizierter gemacht haben. Dabei ist da noch nicht einmal die Mindest-IST Versteuerung mit drin! Dabei reicht bei 98% der Kunden eine Auftragsbestätigung, auf der man per Wunsch das Wort „Auftragsbestätigung“ gegen die Worte „Pro-Forma Rechnung“ austauschen kann. Sogar für Auslandslieferungen.

Lohn… Eine ewige Baustelle. Ein sehr sehr ernst gemeinter Hinweis: Machen Sie keinen Lohn in Navision. Nein. Nicht. Nie!

OCI & EDIfact? Kennt eigentlich noch jemand den BizzTalk Server von Microsoft? Gibt es den eigentlich noch? Alles Müll. Microsoft hat nie eine vernünftige EDIfact Lösung gehabt. Das können andere besser.

Man muss sich bei aller Begeisterung für Navision Dynamics oder Business Central einfach darüber im Klaren sein, dass auch dieses großartige System seine Grenzen hat. Und am besten kennt man diese Grenzen auch noch.

Was aber wiederum fantastisch ist: Für die Migration von AS/400 (as400) oder Cometprogrammen, egal ob aus RPG, Cobol oder BusinessBasic (NETbasic, CrossBasic) gilt das nicht! Selbst uralte dBase und Clipperprogramme! Was diese Altsysteme konnten, das kann Navision und Business Central schon lange!

Und wenn nicht: Dynamics & Business Central wurden dazu gemacht, die „fehlenden Goldkanten“ eben ganz schnell und effektiv an die super Warenwirtschaft und schöne Finanzbuchhaltung einfach anzunähen.

Glauben Sie mir.

(Beitragsbild von MHMcCabe)