Voraussichtliche Lesedauer: 36 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 viele sind richtig, alle sind unnötig.
Wenn Sie es eilig haben, gehen Sie bitte direkt zu Wie macht man es richtig
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 DB2 auch schon Clipper & Dbase sowie Access „damals“ zum Erfolgsmodell machten.
Ach… übrigens: Ja, auch Access ist so eine datengetriebene Anwendung. Auch für alte, gewachsene, inzwischen überforderte (weil viel zu langsame) Access- oder Filemaker Lösungen drängt sich Navision bzw. Business Central geradezu als natürliche Ablösung auf. Na ja, und bei Excel als „Betriebswirtschaftliche Universallösung.. Da sollte es eigentlich nur um „Ablösen & ersetzen, so schnell wie möglich, egal womit“ gehen.
Exkurs: Die optische Verwandtschaft 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 weder Navision noch Business Central das Wasser reichen. Damals nicht, und heute noch viel weniger. Es schadet aber nichts, diese frühen Verwandtschaften mal gehört zu haben.
Ein einfacher Grund für 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, Dbase, SNI Comet Ersetzungsprojekte 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 Navision 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.
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 für Navision gab es schon lange und so war der Schritt zur i5 oder AS400 nur sehr klein. Einer Ablösung bzw. Erweiterung 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 C/Side (CSide) 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 besonders dieser Zweig auf der AS400 sofort eingestellt, als Microsoft in 2002 Navision kaufte. Und nach und nach alle nativen Navision-Server durch eine klare Fokussierung auf den MS-SQL Server abgelöst. Schade.
Vertrautheitseffekte & Verlustaversionen
Wie oben beschrieben kann es einfach technisch oder organisatorisch notwendig sein, eine bestehende Warenwirtschaft (ganz egal, ob das eine AS400, Siemens Nixdorf, Quattro, Dbase, Oracle, Baan, Sage KHK, Lexware…) durch eine moderne ERP Lösung (Navision Financials Attain gibt es dann ja nicht mehr als option, daher hoffentlich Microsoft Business Central 365 🙂 ) abzulösen. Und: Vielleicht ist das auch vielen Mitarbeitern und erst recht der Geschäftsführung schon klar…
Aber: Sie und Ihre Mitarbeiter haben sich mit der derzeitigen Lösung arrangiert. Sie wissen, wie sie mit vorhandenen Fehlern umgehen können (oder müssen). Gerade die Geschäftsführung, aber auch die bereits seit langen im Unternehmen beschäftigten Mitarbeiter, scheuen dann oft schon rein innerlich das Umlernen. Dazu die ganzen Räubergeschichten, die Sie von anderen ERP Neueinführungen gehört haben. Vielleicht spielt auch noch die Erfahrung mit einer bereits begonnenen, dann jedoch gescheiterte Neueinführung einer neue Warenwirtschaft negativ mit in die Gefühle (Emotionen) eine Rolle.
Sie befürchten den Mehraufwand, die Änderung, ein erneutes Scheitern, Mehrausgaben, Überstunden… vielleicht sogar befürchten Sie die Erkenntnis, das Sie derzeit ein totes Pferd reiten, und das mit viel Aufwand.
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 dies auch Access, etwas historischer auch dBase, Filemaker & Clipper-Programme.
Egal ob modernere Warenwirtschaften (wie VLEX Plus) und teils Finanzbuchhaltungen auf der AS/400 (z.B. Manhattan Associates Warehouse Management solution for IBM i (WMi), die BP-Warenwirtschaft von Baierl und Partner, die ERP Software Frida von Command genauso wie Oxaion): Sie alle profitieren von der tiefen Verzahnung der DB2 oder DB/400 in die Gesamtlösung AS400 (bzw. moderner ISeries).
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.
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. Dabei ist bei Navision Financials Dynamics oder Microsoft Business Central BC365 auch noch das WMS (Wahrehouse Mangagement System) schon im ERP enthalten – es fehlt nur noch die vergleichsweise einfache Anbindung an eine Fördertechnik.
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.
 |
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.
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.
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.
Mit diesem Pfund 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 realistisch 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 jeder Wettbewerber 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 wir wirklich wieder alles so wie früher“? Es wird Sie viele Euros 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 oder 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 drum herum arrangiert. Dies führt Arbeitsweisen & Workarounds ein und verfestigt diese auf eine Art, die Navision / Business Central Entwicklern oft 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 hinzuweisen. Alles, was hier im Vorfeld versäumt wird, wird den Projektpartnern später tonnenschwer auf die Füße fallen.
Die CHANCE durch eine Umstellung, eine Neueinführung
Wenn Sie bis hierhin durchgehalten haben, dann haben Sie sich ohnehin schon Gedanken darüber gemacht. Ihre Kunden wollen PDF-Rechnungen oder gleich EDIfact Dateien. Ihr Webshop sieht aus wie selbstgestrickt… und ist das vielleicht auch. Neue Mitarbeiter brauchen ewig, bis sie sich unbrauchbare Nummernkombinationen, nicht intuitive Abkürzungen, kompliziertes Umgehen von bekannten Fehlern angelernt haben. Sie können vielleicht keine Datensicherung mehr durchführen, weil da ein ewiger Fehler in der Datenbank schlummert. Sie können aus technischen Gründen nicht auf PC Technik oder ein modernes Betriebssystem umstellen. Sie brauchen neue Schnittstellen zum Reporting, oder müssen verschiedene Workarounds & Auswertungen in Excel oder Word machen. Vielleicht haben Sie sogar einen Unternehmensberater im Haus, welcher viele der Engstellen ihrer jetzigen IT klar mit Worten beschrieben hat… Oder Sie selbst haben bei einem Perspektivenwechsel genau dies erkannt: Ihre EDV ist veraltet, Ihre Firma krankt daran, Ihr Wettbewerber rennt Ihnen davon, schnappt Ihnen Kunden durch besseren Service, bessere Dienstleistungen weg. Oder Ihre Mitarbeiter brauchen so viel Zeit, um mit Unzulänglichkeiten ihrer IT umzugehen, das Sie allein aus diesem Grund neue Mitarbeiter in der Verwaltung brauchen. Diese Analysen legen Ihnen nahe, eine Modernisierung ihrer IT Landschaft und Warenwirtschaft vorzunehmen.
Und so fragen wir uns…
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:
- 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)
Voraussichtliche Lesedauer: 36 Minuten
Deutsch 
English 
Español