Das ist eine Folge für alle, die mehr über die Entwicklungsgeschichte von ERP wissen oder einfach nur verstehen wollen, warum ihr ERP-System optisch modern wirkt, aber sich in der Entwicklung kaum noch „vom Fleck“ bewegt.
In der heutigen Folge spreche ich über die historische Entwicklung von ERP-Architekturen von der monolithischen Mainframewelt bis hin zu modernen Web Scale SOA und Microservices von „heute“ und „morgen“.
Viel Vergnügen!
————————–
Wenn Ihnen unsere Folgen gefallen, dann freuen wir uns über eine 5-Sterne-Bewertung auf Ihrer Wunschplattform, damit auch andere auf diesen Podcast aufmerksam werden und wir das Angebot weiter verbessern können. Zeitaufwand: 1-2 Minuten.
In diesem Sinne: keep connected.
Herzlichst
Ihr
Axel Winkelmann
Transcript:
ERP-Podcast, Folge 127 – Technische Einblicke in die ERP-Architekturen Das ist eine Folge für alle, die mehr über die Entwicklungsgeschichte von ERP wissen oder einfach auch nur verstehen wollen, warum ihr ERP-System modern wirkt, aber sich leider in der Entwicklung kaum noch vom Fleck bewegt. In der heutigen Folge spreche ich über die historische Entwicklung von ERP-Architekturen, der monolithischen Mainframe-Welt bis hin zu modernen Web-Scale SOA und Microservices von heute und morgen. Viel Vergnügen! Herzlich Willkommen zum ERP-Podcast.
Dem Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen auseinandersetzen wollen. Mit diesem Podcast möchte ich Sie mit eigenen Gedanken und Interviews bei der Gestaltung moderner IT-Konzepte nebenbei, also zum Beispiel beim Spazierengehen oder Autofahren, begleiten. Damit möchte ich Ihnen in dieser von technologischen Veränderungen geprägten Zeit Informationen anbieten, die sich in Zeitschriften, Fachbüchern und wissenschaftlichen Artikeln in dieser Form nicht darlegen lassen und für die sich im hektischen Alltag ohnehin nicht die Zeit findet.
Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg. Ich darf Sie ganz herzlich wieder begrüßen hier im ERP-Podcast.
Ich bin immer noch ein bisschen landunter, insofern dürfen Sie heute wieder mit mir vorlieb nehmen, denn ich möchte meine Folge jeden Mittwoch eine neue Episode zu bringen, natürlich auch heute nicht brechen. Dann habe ich mir überlegt, über was kann ich reden, was vielleicht auch für Sie im ERP-Markt von großem Interesse ist. Es gibt ein Thema aus Hörerkreisen vorgeschlagen.
Es gibt ja die wunderbare Möglichkeit, auf iTunes auch Bewertungen oder Rezensionen darzulassen. Für alle, die das gemacht haben, einen ganz herzlichen Dank. Für die, die es nicht gemacht haben, insbesondere die, denen es besonders gefällt, ich würde mich sehr freuen, wenn Sie dort auch eine Fünf-Sterne-Bewertung hinterlassen, damit es der Algorithmus wieder für andere, die dieses Format interessant finden könnten, dann entsprechend auch findet.
So, Ende letzten Jahres hat mir jemand geschrieben über iTunes, hat gesagt, vielen Dank für die Mühe. Das war KingMO90. Er würde sich gerne mehr Technik-Themen wünschen.
Nun ist es so, dass ich Technik sicherlich sehr, sehr schwer vermitteln kann, ist auch nicht mein Kern und wird dann sicherlich auch für viele an einigen Stellen schnell ermüdend. Ich möchte heute aber mal ein Technik-Thema rausgreifen, weil ich immer wieder in Auswahlprojekten, immer wieder in Gesprächen auch mit Unternehmen das Gefühl habe, dass das Thema technische Architekturen, also wie sind die Systeme eigentlich aufgebaut oder warum sind sie so aufgebaut, wie sie aufgebaut sind, gar nicht so richtig beleuchtet wird. Es ist so, dass wir einige sehr, sehr, sehr moderne Systeme haben oder zumindest moderne Systeme.
Man braucht ja durchaus einige Jahre, um ein neues ERP-System zu entwickeln. Das heißt, die Technologie ist immer etwas schneller als die Unternehmenssoftware per se. Aber es gibt eben auch Systeme, die sehen von der Oberfläche wahnsinnig modern aus.
Ja, und dann wundert sich das Anwendungsunternehmen irgendwann, dass es gar nicht so einfach ist, ein neues Feld zu erstellen auf der Oberfläche, dass es verdammt schwierig ist, eine moderne Maschinenanlage an das ERP-System anzubinden, dass es fast unmöglich ist, andere Software-Systeme anzubinden, eine individuelle Entwicklung dranzusetzen etc. pp. Also viele, viele Dinge, die da zusammenkommen, obwohl das System eigentlich von der GUI, von der grafischen Oberfläche, GUI, Graphical User Interface, also dem, was man eigentlich bedient, auch schick und modern aussieht und natürlich die Betriebswirtschaftslehre in Form der vielen Funktionen und der Prozessabläufe im System absolut rund zu sein scheint.
Und das ist natürlich ein Problem, mit dem ich immer wieder zu kämpfen habe. Einerseits Systeme langjährig geheift, sage ich jetzt mal, mit toller Funktionalität und andererseits modernere Systeme in Bezug auf die Technik, die vielleicht in der Funktionalität noch das eine oder andere vermissen lassen, die aber von der Möglichkeit, das System schnell weiterzuentwickeln und das System an verschiedene Anwendungszwecke, z.B. Maschinenpark etc. anzubinden, ganz anders aufgestellt sind, und zwar im Sinne der Effizienz.
Und dann habe ich mir überlegt, weil das Thema eben immer wieder aufpoppt, darüber sollten wir mal sprechen. Und ich bin hingegangen und habe so ein bisschen rausgesucht, wie sich eigentlich die Architekturen von ERP unterscheiden. Ich werde im Laufe der Folge eine Reihe von Querverweisen auf andere Folgen machen.
Sie wissen, ich sehe den ERP-Podcast gar nicht so sehr als, man muss die neueste Folge hören, sondern es ist für mich mehr eine Wissensdatenbank, eine Wissensbasis, in der ich natürlich auch selber Gedanken äußere, aber vor allen Dingen ganz viele Leute aus Anwendungsunternehmen, ganz viele historische, aber auch aktuelle Persönlichkeiten aus dem ERP-Umfeld, aus dem Unternehmensdatenfundament-Umfeld, zu Wort kommen lasse, damit Sie, liebe Hörer, die Möglichkeit haben, ganz viel aus diesem Thema zu ziehen, sei es, weil Sie selber bei ERP-Unternehmen angestellt sind oder selber ein ERP-Unternehmen betreiben. Auch da erreichen mich durchaus einige Zuschriften. Oder weil Sie eben gerade selber bei der Auswahl eines ERP-Systems von entsprechender Unternehmenssoftware dabei sind.
Oder aber einfach mehr über Ihre IT-Strategie, über die Möglichkeiten der Geschäftsmodellgestaltung, der Prozessgestaltung mit dem Unternehmensdatenfundament erfahren wollen. So, jetzt hole ich ein bisschen aus, denn ich habe ja gesagt, ich möchte eigentlich so ein bisschen die ganze Geschichte von Unternehmenssoftware, von ERP beleuchten. Ich werde nicht überall ganz tief ins Detail gehen, aber so, dass es hoffentlich auch unterhaltsam ist.
Ich habe in den ersten zwei Folgen des Podcasts sehr viel erzählt, wie sich so die Computertechnologie entwickelt hat, und zwar weit vor den 1940ern. Also wer die Anfänge der mechanischen Computertechnologie erfahren will, wird dort sicherlich fündig werden. Für uns interessant ist sicherlich die Zeit ab der ersten integrierten Schaltkreise 50er, 60er Jahre, wo die ersten Computersysteme dann auch in den Großunternehmen eingebracht wurden.
Das war natürlich vor allen Dingen die Firma IBM, die sich den Namen gemacht hat als großer Computerhersteller. Vielleicht zu nennen hier auch von führender europäischer Seite der deutsche Heinz Nixdorf, der 1968 in Paderborn die Firma Nixdorf gegründet hatte. Also das waren so die gängigen Systeme, es gab viele an der Stelle.
Am Anfang war natürlich der Computerchip, der Rechenpower, das limitierende Merkmal für alle Funktionalität in Form von Software. Das heißt, gerade in den 50ern, vor allen Dingen 60er Jahren, waren die Computerprogramme, die auf dieser Hardware liefen, sehr, sehr begrenzt. Also wir reden eigentlich noch nicht in dem Sinne von integrierter Unternehmenssoftware, wie wir es heute tun, sondern wir reden eigentlich über kleine Funktionen, um zum Beispiel die Lohnbuchhaltung zu unterstützen oder entsprechend Stücklistenauflösungen im Produktionsumfeld, im Lagerumfeld durchführen zu können.
Zu der Zeit war es eigentlich so, dass die Software gar nicht so bedeutsam war, sondern die Hardware entscheidend war. Es waren alte Mainframe-Systeme, IBM-Mainframe-Systeme, die entstanden und auf denen die Software als Dreingabe letztendlich lief. Also das Ganze war extrem stark miteinander verbunden.
Und das Ganze wurde erst im Laufe der Zeit aufgelöst, weil es dann auch Kartellklagen gab über die Verbindung von Hardware und Software. Und natürlich standen einzelne Software-Pioniere in den Startlöchern, um selber zu entwickeln. Wer so ein bisschen was über die Zeit wissen möchte, dem empfehle ich mal die Folge 8, die ERP-Historie, die ich so ein bisschen aus dem Hellbohm-Gümbel herausgekitzelt habe als ehemaliger Gartner-Stratege, Gartner-Berater hier in Europa, der diese Zeit sehr, sehr stark mitgekriegt hat und zwar noch lange bevor der Terminus Technicus ERP eigentlich aus Gartnermund das erste Mal das Licht der Welt erblickte.
Also Hardware und Software wurden getrennt und das war natürlich der Startschuss dann auch für viele Software-Unternehmen. Wir hatten parallel in der Wissenschaft die BWL-Generation nach dem Krieg, allen voran sicherlich mein wissenschaftlicher Ururgroßvater Gutenberg, der drei große Bände zur BWL, zu Funktionen in der BWL geschrieben hatte. Also die BWL war sehr stark treibend in der funktionalen Betrachtung und es lag irgendwo nahe, dass die Software, die jetzt rein funktional einzelne Bereiche aufgriff, umsetzte in Code, in Assembler, in Lochkarten-Code, dass die immer größer wird und dass das immer mehr dazu führt, dass die Daten integriert für verschiedene Anwendungszwecke zur Verfügung standen.
So einen Namen, vielleicht mal Herrn Meier genannt, ADV Orga aus Wilhelmshaven. Ich hatte versucht, ihn auch nochmal in den Podcast zu holen, aber er hatte mit dem Thema ERP auch entsprechend abgeschlossen. Sicherlich einer der ersten Software-Entwickler, die sehr erfolgreich damals entsprechend Unternehmenssoftware entwickelt haben.
Parallel zu nennen immer noch extrem erfolgreich die SAP 1972 gegründet mit dem Ziel, aus der IBM kommt die Gründer damals, mit dem Ziel, eine Software eben auch zu schaffen, die wirklich verschiedenste Funktionalität auf den gleichen Daten hat. R1 war die rudimentäre erste Version, wie gesagt auch in Assembler geschrieben für IBM Mainframes mit entsprechender Lochkarten-Technologie an der Stelle. Wen das ganze Thema SAP, Entwicklung der SAP interessiert, auch den verweise ich gerne auf eine Folge, nämlich die Folgen 25 und 26, wo ich mich mit dem langjährigen Entwicklungsvorstand Peter Zenke sehr sehr intensiv und sehr lange und sehr nett darüber unterhalte, wie eigentlich die SAP entstanden ist und wie die Produkte immer weiter sich entwickelt haben.
Also am Anfang, da war die Technologie noch nicht sonderlich weit, man hatte große zentrale Rechner, namentlich vor allen Dingen von der Firma IBM Mainframe Produkte. Das heißt, der gesamte Code, der hier entwickelt wurde, insbesondere in den 70er Jahren, der musste noch nicht auf Skalierung, auf verschiedene Rechnersysteme oder ähnliches Rücksicht nehmen, sondern das war ein sogenannter monolithischer Code, monolithische Architekturen, die entstanden. Zentrale Systeme, bei denen man die Datenhaltung, die eigentliche Funktionalität und die Benutzerschnittstelle nicht voneinander getrennt hat, sondern die waren in einem System eigentlich untrennbar miteinander verbunden und die waren entsprechend zentral auf dem Mainframe Rechner installiert.
So, das hat zunächst mal einen Vorteil, weil ich das Zielsystem natürlich par excellence kenne. Das hat sicherlich auch einen Vorteil, weil ich nicht in der Entwicklung auf besondere Restriktionen, auf besondere Codevorgaben in der Form achten muss. Ich finde es sowieso bemerkenswert, wenn Entwickler große Systeme in Assembler entwickeln.
Ja, aber der Nachteil dieser Untrennbarkeit zwischen Datenhaltung, Funktionalität und Benutzerschnittstelle war natürlich das Ersetzen, das Updaten, die Wartung, das Hinzufügen von Programmteilen. All das machte es wahnsinnig schwierig und ja, wenn man den Code einmal geschrieben hat, dann hat man ihn so spaghettiartig ineinander geflochten und den dann nochmal wiederzuverwenden für andere Softwaresysteme oder ähnliches, das war natürlich wahnsinnig schwierig. Und jetzt sprechen wir auch noch über einen Markt, wo man eigentlich nicht so wirklich gut Individualentwicklung machen kann, sondern wo man eigentlich besser Standardsysteme entwickelt, die man dann in verschiedenen Anwendungsunternehmen parallel nutzen kann, adaptieren kann.
All das ist dann natürlich mit solchen monolithischen Architekturen, mit der Verschmelzung der verschiedenen Programmteile ineinander wahnsinnig schwierig. Entsprechend war der Aufwand natürlich immens groß, um mit dieser Technologie Plattform überhaupt entwickeln zu können. Ja, also die Performance war sicherlich super, weil man genau auf das Zielsystem hin entwickelte, aber die Weiterentwicklungsfähigkeit, die Flexibilität für Veränderungen, der Wechsel auf eine andere Plattform, das war natürlich alles wahnsinnig schwierig.
Gleichzeitig machte das Entwickeln in Assembler auch nicht wirklich viel Freude. Gerade für große Unternehmenssysteme war das sicherlich in der Form nicht so geeignet. Peter Zenke hat es in seiner Postkart-Folge nochmal 2526 sehr schön gesagt.
Dann hat auch die SAP, wie viele andere Häuser aus der Zeit, angefangen, ein neues System zu entwickeln, nämlich als die Mainframe-Systeme entsprechend kleiner und leistungsfähiger wurden als 400-Systeme. Und SAP hat mit dem R3-System um 1985 versucht, von den Großrechnersystemen für die Großindustrie runterzukommen in den AS400-Bereich für mittelgroße Firmen. Aus dem Versuch ist letztendlich das bis heute immer noch gültige R3-System geworden, was dann aber nicht, wie ursprünglich angedacht, auf der AS400 lief, sondern bereits für Client-Server-Systeme ausgerollt wurde.
Und das ist genau der nächste architektonische Entwicklungsschritt, den wir bei der ganzen technischen Entwicklung von ERP-Architekturen eigentlich haben. Wie gesagt, 70er-Jahre sehr, sehr stark Mainframe. Das war das Einzige, was es dann auch gab.
Und Mitte der 80er-Jahre etwa immer leistungsfähiger werdende dezentrale Computersysteme, die genutzt werden konnten, um den Mitarbeitern direkt am Arbeitsplatz einen eigenen Rechner zur Verfügung zu stellen. Und damit kam dann entsprechend auch die Vernetzung auf und man konnte eben sogenannte Client-Server-Systeme entwickeln oder Multi-Tier-Architekturen, wenn wir es amerikanisch betrachten wollen. Die Idee dahinter ist es, nicht nur die komplette Unternehmenssoftware auf einem zentralen Rechnersystem laufen zu haben, sondern die Software in mehrere Schichten aufzuteilen.
In zwei Schichten aus Datenhaltung sowie Funktionalität und Benutzerschnittstelle auf der anderen Seite, beziehungsweise teilweise sogar heute noch gebräuchlich in drei Schichten, die sich unterscheiden in die Datenhaltungsschicht, in die Datenbankschicht, in die Funktionsschicht, die sogenannte Applikationsschicht und die entsprechende Benutzerschnittstelle. Also das, womit wir letztendlich heute jedes Programm bedienen. Aber ganz am Anfang stand zunächst mal eine vernünftige Datenbank.
Die relationale Datenbanktechnik erhielt gerade in den 80er Jahren massiven Zulauf, massive Weiterentwicklung. Wer auch das Thema Datenbanken ein bisschen vertiefen möchte, der sei verwiesen auf die Folge Nummer 98 mit Gottfried Vossen. Gottfried Vossen ist ein Professor der Informatik, der sich sehr stark mit Datenbanken auseinandergesetzt hat über viele Jahrzehnte.
Und der mir netterweise in der Folge Rede und Antwort zur Entwicklung von Datenbanken, von flachen, von hierarchischen relationalen Datenbanken bis heutigen modernen Datenbanksystemen, nur SQL-Datenbanksystemen und ähnlichen, Rede und Antwort gestanden hat. Also sicherlich auch sehr, sehr spannend. Wir hatten eine Datenhaltungsschicht, weil die Software-Systeme natürlich immer größer wurden.
Und je mehr ich die Daten zu unterschiedlichen Zwecken nutzen wollte, desto wichtiger wurde eben die Datenhaltung, das Zugriffsmanagement. Wer darf auf welche Daten zugreifen? Und damit entstand letztendlich aus dem Spaghetti-Code eine geordnete Programmierung. Ich hatte eine Programmierung für die Datenhaltungsschicht.
Bei der Two-Tier, bei der Zwei-Schichten-Architektur gab es dann, wie gesagt, nur eine zweite Schicht. Bei der Multi-Tier oder Drei-Schichten- und Mehr-Schichten-Architektur gab es dann drei und mehr Schichten. Die Idee dahinter eben, ich lasse die Datenstruktur zentral, also die Datenbank, die Datenhaltung zentral gespeichert auf einem Server.
Und die reine Funktionalität in Form der Benutzerschnittstelle, die ist dann entsprechend auf den Arbeitsplatzrechnern der Anwender zu finden. Und auf diese Art und Weise, man muss sich vorstellen, in den 80er, frühen 90er Jahren, da waren natürlich die Bandbreiten auch nicht wirklich groß der Leitungen, die durch die Unternehmen gelegt wurden. Und entsprechend hatte man natürlich hohe Latenzen.
Das heißt, es war gut, Funktionalität auf den Endgeräten zu haben, um entsprechend flüssig mit so einem System arbeiten zu können. Und gleichzeitig mit der zentralen Datenhaltung natürlich sicherzustellen, dass in Echtzeit die Anwender auf aktuellen Daten arbeiten. Was in den 80er Jahren noch typischerweise so eine Zweischichtenarchitektur aus zentraler Datenhaltung und dezentraler Abarbeitung war, das wurde dann in den 90er Jahren immer mehr zur Dreischichtenarchitektur.
Vielleicht auch nochmal ein Hinweis auf eine Folge, die ich mit dem Padasoft-Gründer Arnold Kattele-Böhm gemacht habe, zum Thema Technologiemigration. Also wie schwierig das auch dann war, letztendlich Software, die schon im Mainframe-Bereich entwickelt wurde, auch in das neuere Zeitalter zu holen. Was für Ansätze man dort gefahren hat und sicherlich auch immer noch fährt.
Ich denke, auch das ist durchaus sehr, sehr spannend, wenn man sich so ein bisschen mit Architekturen und den Veränderungen der Architekturwelt auseinandersetzen will. Wie gesagt, Folge 58, 59, wie alles. Ich verlinke das in den Shownotes.
Wer noch ein bisschen mehr über die Herausforderung von Neuentwicklungen dann auch wissen möchte, der sei verwiesen auf die Folge 20, wo ich mit dem Prokuristen der Firma SAD über eine Neuentwicklung gesprochen habe, die sich, bis sie dann erfolgreich am Markt platziert war, durchaus über fast anderthalb Jahrzehnte hingezogen hat. Also auch das gibt es. Wer von den Anwendungsunternehmen heute über hohe Kosten für die ERP-Software stöhnt, sollte sich durchaus auch einmal derartige Folgen anhören, um zu verstehen, dass Software zwar von soft, von weich kommt, im Gegensatz zu Hardware, die man anfassen kann, die fest ist, die offensichtlich teuer sein muss.
Aber Software ist heute natürlich als Unternehmenssoftware etwas Hochkomplexes, an dem viele, viele Mannjahre in die 100 Jahre Entwicklungsarbeit hineingeflossen sind. Und das macht natürlich auch entsprechend den Preis von so etwas aus. Wer Interesse hat, Folge 20 des ERP-Podcasts.
Also 80er-Jahre, die Kleins kamen auf. 90er-Jahre, das wurde natürlich immer leistungsstärker. Gleichzeitig wurden die Programmiersprachen immer leistungsfähiger.
Am Anfang Maschinencode-nahe Assembler, dann immer mehr Richtung dritte Generation, vierte Generation von Sprachen. Bei der SAP beispielsweise ABAP, neuere Sprachansätze, die dann eigentlich auch als Standardsoftware-Sprachen aufkamen. Und damit konnte ich natürlich immer mehr in dieses Drei-Schichten- oder Mehrschichten-Paradigma eintauchen.
Weil jetzt natürlich neben dem Endgerät, was der Anwender auf dem Schreibtisch hatte, oder unter dem Schreibtisch vielmehr, neue Geräte dazukamen, mobile Geräte so langsam dazukamen. Und jetzt wurde es immer offensichtlicher, dass man eigentlich zwischen der zentralen Datenhaltung, der funktionalen Schicht und der Benutzerschnittstelle trennen wollte. Und da gibt es jetzt mehrere Konzepte, die dort entsprechend auftauchen.
Was wir bereits aus den 80er-Jahren kennen, ist das Thema FATclient. Also eine Software, die sehr intensiv, sehr aufwendig installiert wird auf jedem einzelnen Anwendungsrechner. Und diese Software hat natürlich die Benutzerschnittstellen-Logik, aber eben auch große Teile der betriebswirtschaftlichen Funktionalität in ihrem Software-Code drin.
Der Riesenvorteil an der Stelle, ich brauche eigentlich nur Daten über das Netzwerk zu ziehen. Alle Repräsentations-Funktionalität, alle Benutzerschnittstellen-Funktionalität, die ist natürlich entsprechend installiert auf dem Endgerät. Also das war der Riesenvorteil.
Der Riesennachteil an der Stelle ist natürlich, dass wir entsprechend darüber nachdenken müssen, wie man, wenn man zum Beispiel ein Unternehmen mit 5000 Endanwendern hat, auf jedem einzelnen Endanwender-Arbeitsplatz die Software aktualisiert, alle halbe Jahre. Noch schlimmer wird das, wenn die nicht alle in einer Firma sind, sondern dezentral in Filialen, zum Beispiel im Einzelhandel, verteilt sind über ganz Deutschland. Und wenn nicht alle halbe Jahr oder Jahr ein Update erfolgt, sondern vielleicht jeden Monat.
Oder so etwas schiefgelaufen ist beim Update und entsprechend nochmal nachgearbeitet werden muss. Also das sind alles die Herausforderungen, die wir in der entsprechenden FATclient-Welt 90er Jahre vor allen Dingen hatten. Es gibt auch noch Software-Systeme, die in dieser Welt verankert sind.
Aber es gibt heute natürlich andere Wege, damit umzugehen. Und mit diesen anderen Wegen damit umzugehen, damit entlasse ich Sie für diese Woche und werde auf diese Wege in der zweiten Episoden-Hälfte zu sprechen kommen. Wie immer gilt, keep connected.
Herzlichst, Ihr Axel Winkelmann. Ihnen hat der ERP-Podcast gefallen und Sie konnten wertvolle Erkenntnisse gewinnen? Dann würde ich mich über eine Bewertung auf iTunes freuen, damit auch andere von diesem Podcast erfahren können. Eine Anleitung für die Bewertung finden Sie auf www.erp-podcast.de. Dort finden Sie auch weitere Hinweise, Links und Aktualisierungen zu dieser Folge.
Das war der ERP-Podcast für alle, die sich aktiv mit dem Einsatz und der Gestaltung von Unternehmenssoftware und den daraus entstehenden Veränderungen und Potenzialen in Unternehmen losgelöst von Fachzeitschriften, Büchern und wissenschaftlichen Veröffentlichungen zum Beispiel beim Spazierengehen oder Autofahren auseinandersetzen wollen. Mein Name ist Axel Winkelmann. Ich bin Professor für Betriebswirtschaftslehre und Wirtschaftsinformatik an der Universität Würzburg.