Das ist der zweite Teil einer Folge – die ein bisschen tiefer gehend ist – die sich vielleicht richtet an Leute, die sich sehr sehr viel Gedanken rund um ihr Unternehmenssoftwaresystem/ ihr ERP-System machen. Es richtet sich an alle Entwickler/ an alle IT-Architekten, die sich nicht nur fragen, wie eine ERP- oder Unternehmenssoftware-Architektur technisch gestaltet sein muss sondern die sich auch fragen, welche betriebswirtschaftlichen Erfordernisse an ein zukünftige ERP-Architektur gestellt werden müsste.
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 128, zweiter Teil. Betriebswirtschaftliche Erfordernisse an ERP-Architekturen. Das ist der zweite Teil einer Folge, die ein bisschen tiefergehend ist, die sich vielleicht richtet an Leute, die sich sehr, sehr viel Gedanken rund um ihr Unternehmenssoftware-System, ihr ERP-System machen.
Es richtet sich an alle Entwickler, an alle IT-Architekten, die sich nicht nur fragen, wie eine ERP- oder Unternehmenssoftware-Architektur technisch gestaltet sein muss, sondern die sich auch fragen, welche betriebswirtschaftlichen Erfordernisse an eine zukünftige ERP-Architektur gestellt werden müsste. 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. Herzlich willkommen zurück zum ERP-Podcast. Wir sind mittendrin in der Episode 128 Betriebswirtschaftliche Erfordernisse an ERP-Architekturen.
Ausgangspunkt für die Folge war die Folge 127. Da hatte ich mich ein bisschen ausgelassen über die Entwicklung von ERP- oder Unternehmenssoftware-Architekturen, angefangen von den 60er, 70er Jahren bis eigentlich zu ganz, ganz modernen Architekturen. Wir sind immer noch recht oberflächlich geblieben.
Ich glaube, wenn man die ERP-Hersteller, die ganz modernen, en detail fragt, dann werden die natürlich noch viel, viel tiefer gehen können. Aber das war ein bisschen reichen, um einfach einen Einblick zu kriegen in die Entwicklung und auch vielleicht eine Einschätzung zu ermöglichen, was das eigene ERP-System kann, beziehungsweise das, was ich auswählen will, entsprechen kann. So, dann hatte ich in der letzten Woche gesagt, okay, jetzt ist es so, dass wir natürlich nicht nur technische Erfordernisse haben, die sich einfach aus der Hardwareanforderung, aus den Infrastrukturmöglichkeiten zunehmend ergeben, sondern wir haben eigentlich auch ganz viele betriebswirtschaftliche Anforderungen.
Klar, natürlich insbesondere funktionale Anforderungen, aber das soll an der Stelle gar nicht das Thema sein, die funktionale Anforderung. Ich möchte auf etwas ganz anderes hinaus. Das habe ich letzte Woche so ein bisschen begonnen.
Das möchte ich heute natürlich gern auflösen und zu Ende bringen. In der vergangenen, im ersten Teil, letzte Woche, bin ich zunächst darauf eingegangen, dass wir für eigentlich jedes physische Objekt oder auch Subjekt für jede Transaktion letztendlich ganz, ganz viele virtuelle Daten haben. Ich hatte das Beispiel Apfel genannt.
Also klar, die Anzahl an Äpfeln, die wir haben, die Farbe relativ offensichtlich, Mindesthaltbarkeitsdatum, da wird es dann schon nicht mehr so ganz offensichtlich, wenn wir dann noch wissen wollen, mit welchen Stoffen der Apfel beim Bauern gespritzt worden ist. Dann haben wir schnell Daten, die eigentlich eine ganze Kette von Wertschöpfungspartnern durchlaufen. Und dann sind wir bei dem Thema, was ich letztes Mal auch kurz angesprochen hatte, die Entwicklung von Unternehmen und sozusagen die Abgrenzung von eigentlich natürlicherweise zusammengehörenden Daten, Datenstrukturen.
Und das kann man natürlich einerseits sehr positiv nutzen, beispielsweise Intercompany-Geschäft, auch natürlich im steuerlichen, indem man physische Dinge virtuell sozusagen über die entsprechenden z.B. GmbHs oder Unternehmen abgrenzt. Das hat natürlich aber auch negative Seiten. Und das ist genau der Punkt, wo ich sage, für genau diese Erfordernisse brauchen wir eigentlich auch in der Betriebswirtschaftslehre neue Architekturstrukturen im IAP.
Wir haben nämlich, wenn wir uns das Thema Datenaustausch anschauen, das läuft so alles unter der Überschrift I-Standards, elektronische Datenaustausch-Standards, EDI, Edifact, XML-Formate, Zugpferd, etc. PP, all das sind Ansätze, um eben Daten zwischen z.B. unterschiedlichen Organisationen, unterschiedlichen Unternehmen hin- und herzuschieben. Das Problem dabei ist nur, dass jeder einzelne dieser Unternehmen sich unserer Untersuchung nach, dazu werden wir auch noch eine Folge machen, dazu haben wir auch schon ganz am Anfang Folgen gemacht, ich verlinke die, ich habe die jetzt gerade nicht im Kopf, dass jeder einzelne Unternehmensbeteiligte eigentlich seine eigenen Datenformate haben.
Und selbst wenn die sich dann auf einen Datenaustausch-Standard geeinigt haben, dann hat doch irgendjemand irgendeine Vorstellung, welche Extradaten er noch gerne übermittelt haben möchte und welches standardisierte Datenfeld aus dem Datenaustausch-Standard doch noch missbraucht werden kann. Dann wird aus dem Geburtsdatum plötzlich ein Haltbarkeitsdatum oder ähnliche Spielchen, also wer mit den Leuten aus den EDI-Abteilungen der großen Handelsunternehmen spricht, der erfährt da Sachen, die sind also unglaublich teilweise und die sind mit Sicherheit nicht sehr zielführend. Das mag noch gehen, wenn ich, jetzt nenne ich mal keine Namen, aber wenn ich ein ganz großes Handelsunternehmen bin oder meinetwegen ein Automobilhersteller, dann kann ich letztendlich meinen Lieferanten und vielleicht auch den Kunden nicht nur den Standard diktieren, sondern meine Dialekte, meine Abweichungen vom Standard, die diktiere ich halt den anderen Partnern auch direkt mit, damit wir Rechnungsdaten austauschen können, damit wir Produktartikeldaten austauschen können, damit wir Liefererwiesen austauschen können und so weiter und so fort.
So, das mag funktionieren, wenn ich der Stärkste in der Kette bin. Wenn ich jetzt aber so einer bin, der irgendwo dazwischenhängt, starke Kunden, starke Zulieferer, also ich bin zum Beispiel Logistiker, dann habe ich an der Stelle ein Riesenproblem, denn ich habe zum Beispiel 4000 Kunden und 4000 Lieferanten, die ich alle mit logistischen Leistungen versorgen muss und jeder sagt mir, du musst zwar den gleichen Standard nutzen, aber wenn du mit mir Daten austauscht, dann bitte mit der und der Dialektabweichung und wenn du mit jemand anders die Daten austauscht, dann vielleicht mit einem ganz anderen Standard und einer anderen Dialektabweichung. Also das sind die Probleme, die wir in der Realität haben.
Die Forschung ist da gar nicht so drauf eingegangen. Das war vor allen Dingen vor knapp 20 Jahren großes Forschungsgebiet, diese elektronischen Standards und da hat man eben festgestellt, man braucht diese Standards, logisch, wenn jeder eins zu eins irgendwas austauscht. Dann habe ich halt 17.000 verschiedene Standards und wenn ich mich auf einen Standard einige, Entschuldigung, dann habe ich nicht 17.000 Standards, sondern dann habe ich 17.000 verschiedene Varianten, wie ich Daten austausche, also muss ich mich auf einen Standard einigen, idealerweise noch eine Datenaustauschplattform dazwischen haben und dann, so sagt die damalige Theorie, dann kann ich natürlich auf einer Eins-zu-Eins-Basis die Daten austauschen.
Die Praxis sieht da natürlich ein bisschen anders aus. Also wir haben diese riesen Datenaustauschprobleme. Ja, und wenn ich das jetzt weiterdenke, dann muss ich irgendwo sagen, woran liegt denn das, dass das Einzelne oder Nebenzweite sagt, super, da ist ein Standard zum Austausch von Artikeldaten, zum Austausch von Rechnungsdaten, zum Austausch von Angebotsdaten etc.
pp. Und dann geht das Unternehmen trotzdem hin und weicht von diesem Standard ab. Da gibt es natürlich viele verschiedene Erklärungsansätze.
Auch aus dem Verhaltensbereich würde ich gar nicht darauf eingehen. Aber einen Punkt, den möchte ich herausgreifen und das ist das Thema, wie bilden wir eigentlich Semantik, also Inhalte, innerhalb des ERP-Systems ab. Sie werden mir wahrscheinlich recht geben.
Jedes ERP-System verarbeitet die betriebswirtschaftlichen, die transaktionalen Daten des Unternehmens und seiner Wertschöpfungspartner mit dem relativ gleichen Ergebnis. Das Ergebnis ist sicherlich relativ normiert. Nur der Weg, wie es das macht, technisch, der ist sicherlich ganz unterschiedlich.
Also wenn ein ERP-System Ware aus dem Lager entnimmt, dann ist die Art und Weise, wie diese Daten hin- und hergeschoben werden, letztendlich ganz, ganz unterschiedlich. Und das zieht sich so durch das komplette System durch. Ein Teil findet sich in der Datenbank wieder, betriebswirtschaftliche Logik.
Ein Teil findet sich irgendwo im Programmcode wieder, in SQL-Abfragen, irgendwo. Und das ist eigentlich ein Punkt, den haben wir so akzeptiert. Der hat sich einfach historisch ergeben.
Die Standardsoftware, die Standardunternehmenssoftware, die ist ja eigentlich dadurch entstanden, dass wir irgendwann mal gesagt haben, als die Computer leistungsfähiger wurden, wir brauchen Standardsoftware, wiederverwendbare Software für Unternehmenszwecke. Zunächst mal ganz kleine Lösungen, dann immer holistischer, immer größer werdende Lösungen für das gesamte Unternehmen. ADV Orga, 1972 die SAP, um mal zwei Unternehmen zu nennen, die sich sehr früh hervorgetan haben in dem Bereich.
Und man hat sich einfach angeschaut, was machen die Unternehmen eigentlich? Wie funktioniert BWL in den Unternehmen? Gerade zu SAP-Zeiten habe ich mir sagen lassen, wurde dann auch viel mit den betriebswirtschaftlichen Professoren zusammen diskutiert, wie bestimmte betriebswirtschaftliche Funktionen algorithmisch, also in Software abzubilden sind. So, und dann hat man gemacht, Version 1.0, Version 2.0, Version 3.0, irgendwie jeder IAP, jeder Unternehmenssoftwarehersteller auf eine etwas andere Art und Weise. Ja, und im Ergebnis haben wir heute unglaublich viele Benutzerschnittstellen innerhalb des Systems, Datenschnittstellen innerhalb des Systems.
Teilweise ist es sehr, sehr aufwendig, irgendwelche Daten aus dem System rauszukriegen, sie inhaltlich zu verarbeiten. Wir haben eine eigene Kostenrechnung drum herum gebaut. Wir haben eigenes Controlling um die Systeme herum gebaut und haben uns sozusagen, ohne das zu merken, eingeschossen auf die Logik, die der Unternehmenssoftware, der IAP-Hersteller über die Jahre in seinem System, irgendwo im Code, irgendwo in der Datenbank so verankert hat.
Und das nutzen wir halt irgendwie zum Mapping, wenn wir den Daten austauschen wollen mit anderen Unternehmen und dann sind dazwischen eben die vermeintlich standardisierten I-Standards. So, das ist der Status quo. Jetzt gucken wir ein bisschen zurück in der Geschichte.
Ich hatte letztes Mal gesagt, so mit die ersten Daten, die wir eigentlich digitalisiert haben, wenn man das so nennen will. Sie wissen, ich verstehe Digitalisierung manchmal eher im weiteren Sinne. Das hat mit 1 und 0 dann herzlich wenig zu tun.
Also die ersten Daten, die uns als Menschen von Anfang an eigentlich interessiert haben, war der Wert von Ware. Ganz am Anfang haben wir Hühner gegen Ziegen getauscht. Dann haben wir angefangen zu abstrahieren mit irgendwelchen Währungen, Muscheln beispielsweise.
Ja, und daraus ist irgendwie das Geldsystem geworden. Und das Geldsystem ist, ich hoffe, die Volkswirtschaft schlägt mich jetzt nicht, eine normierte Werteangabe auf eigentlich beliebige realwirtschaftliche Begebenheiten und Objekte. Manchmal auch Subjekte.
Ja, also diese normierte Dimension, die haben wir eigentlich über Jahrhunderte, über Jahrtausende mit uns rumgeschleppt. Und die Menschheit hat sich relativ bald überlegt, wie man denn sinnvollerweise, wenn man solche Transaktionen macht, vielleicht auch losgelöst von dem physischen Besitzübergang, das Ganze aufschreiben kann. Und dieses Aufschreiben, das nennen wir heute die doppelte Buchführung, die Doppik.
Ja, das gibt in der Historie verschiedene Daten, über die das belegt ist. Wahrscheinlich am belegtesten ist die Herkunft aus dem Mittelalter. Eine lückenlose doppelte Buchführung kann für das Jahr 1340 nachgewiesen werden.
Genua, Italien, viel Handel, der über Europa stattfand. Und man musste natürlich immer aufschreiben, wer welche Ware, wer welche Werte zur Verfügung hatte. Also dem einen wegnehmen und dem anderen geben.
Einnahmen, Ausgaben, Dokumentation. Die Hanse vielleicht auch zu nennen, auch in 1340 in Lübeck. Der doppelte Buchungssatz mit bilanzähnlichen Übersichten.
Also für die Finanzströme verbunden ansatzweise mit Warenströmen hatte man sehr sehr schnell ein System in der Historie gefunden, mit dem man relativ gut sagen kann, ich habe T-Konten und ich nehme von dem einen Konto etwas weg und gebe es auf das andere Konto, um entsprechend Warenbewegungen darzustellen. Und das Ganze mache ich als doppelte Buchführung. Das heißt, ich buche zum Beispiel Forderungen aus, um Wertgegenstände oder Werte auf den entsprechenden Konten zu verbuchen.
Jetzt haben wir diese Konten und wenn wir uns das System heute anschauen, dann haben wir den Mechanismus des Verbuchens der doppelten Buchhaltung, die Topic und wir haben die entsprechenden Kontenrahmen SK03, SK04 usw. mit denen Transaktionen in Bezug auf den Wert verbucht werden. Das ist heute Stand der Dinge.
Das haben wir natürlich auch in jedem FIBU-System so implementiert. Also auch da können wir die Kontenrahmen auswählen, wenn wir ein Buchhaltungssystem haben. Und dann können wir munter drauf losbuchen und diese Schicht des Buchungsrahmens und die Methodik, wie wir buchen, die ist völlig losgelöst von der Art und Weise, wie dann technisch die Daten geschrieben werden.
Aber jeder, der jetzt diese Daten ausliest, sei es z.B. der Betriebsprüfer, also ein Mensch oder auch ein Prüfungssoftware-System geht jetzt nicht hin per SQL und versucht aus irgendwelchen Daten Banktabellen irgendwie die Daten herauszubekommen, sondern es geht immer über die Logik des Kontenrahmens. Sie merken schon, worauf es hinausläuft. Wir hätten vermutlich zukünftig auch die Chance, diese Doppik in der physischen Welt oder in der virtuellen Welt der physischen Bestände von ERP-Systemen viel, viel besser zu nutzen.
Wenn wir z.B. sagen würden, wir produzieren ein Produkt und für dieses Produkt brauchen wir bestimmte Rohstoffe. Das können wir heute schon mit der Doppik buchen. Aber wir brauchen z.B. auch 20 Minuten Personalzeit des Menschen an der Maschine.
Wir brauchen 2 Kilowattstunden Strom. Wir brauchen für 5 Minuten den Gabelstapler für den einzelnen Job und so weiter und so fort. Wenn wir das auf den einzelnen Konten verbuchen, dann haben wir auch gar keine Probleme mehr in der Analytik der BWL, weil wir über die Konten sehr viel detailliertere Kontenrahmen als ein SK03, SK04 die Dinge betriebswirtschaftlich, semantisch, inhaltlich verbuchen und sie dann technisch im System je nach System ganz, ganz unterschiedlich in die Datenbanken wegschreiben.
Aber wenn wir dann darauf zugreifen, dann können wir das immer wieder über die Logik der Doppik und die Logik des einzelnen Kontenrahmens machen. Dieser Kontenrahmen ist natürlich viel, viel, viel, viel größer als die Kontenrahmen, die wir rein aus der Finanzwelt kennen. Und diese Kontenrahmen sind sicherlich auch nur begrenzt standardisierbar, aber sie sind zumindest begrenzt standardisierbar.
Das heißt, wir könnten jetzt hingehen und könnten ganz tiefe, also ganz detaillierte Kontenrahmen für die unterschiedlichsten Branchen erstellen. Ich hätte wahrscheinlich ziemlich viel mehr Tabellen als der Finanzkontenrahmen. Und wenn wir das aber erstellt haben, dann kann man sogar noch Tabellen Konten dazufügen.
Wie gesagt, wie das dann technisch im System gelöst wird, interessiert uns gar nicht. Und jetzt kommt eben der Clou und deswegen wäre das wahrscheinlich auch ein guter Lösungsansatz für den Datenaustausch. Wenn ich jetzt weiß, wie der Kontenrahmen meines Gegenübers, des anderen Unternehmens, mit dem ich Daten austauschen will, aussieht, dann kann ich eben rein auf dieser betriebswirtschaftlichen Ebene die Daten über den Ausweis des Kontenrahmens austauschen und die darunterliegende technische Schicht, die Datenbasis, die Datenbank, die Datentabellen, die interessieren mich, wie gesagt, an der Stelle dann überhaupt nicht mehr.
Ja, und ich glaube, das ist ein Ansatz, den es sich in der Entwicklung, in der Weiterentwicklung von Unternehmenssoftware definitiv lohnt, weiter zu denken und weiter zu entwickeln. Heute einfach ein bisschen nur für die Synapsen. Ich glaube das auch deswegen, weil wir immer mehr dazu hingehen müssen, ein Datenfundament zu bilden, den Abbau der virtuellen Puffer, also möglichst wenig Reibungsverlust, wenn wir anfangen, die betriebswirtschaftlichen Prozesse zu automatisieren und damit die Daten in Echtzeit größtmöglich in den Prozessen zur Verfügung stehen müssen und wir uns wegbrechende Standards, Datenaustausche Richtung Maschine, Richtung Produktionsplanungsprozess etc.
einfach nicht leisten können. Ja, und gleichzeitig haben wir natürlich den Bereich MES, die Einbindung von intelligenten Maschinen, die gesteuert werden wollen, mithilfe der betriebswirtschaftlichen, mithilfe der transaktionalen Daten und andersherum die Maschinendaten, die natürlich eingehen müssen in die betriebswirtschaftliche Kalkulation, in die betriebswirtschaftliche Welt. Ja, und diese Datenmengen, die zukünftig im Unternehmen anfallen werden, die sind a. längst nicht so schön gekapselt, wie wir das heute in den betriebswirtschaftlichen Transaktionen haben und b. ist die Datenmenge, die dann plötzlich anfällt natürlich um ein Vielfaches größer als die Datenmenge, die wir heute noch in den ERP-Systemen haben.
Also das ist, glaube ich, eine der großen betriebswirtschaftlichen Herausforderungen des nächsten Jahrzehnts, nochmal, parallel zu den technischen Architekturen, in denen ich in Folge 127 gesprochen habe. Eine weitere sehr stark betriebswirtschaftliche Herausforderung sind sicherlich auch Schichten betriebswirtschaftlicher Art, mit denen ich auch inhaltliche Datenanalyse machen kann, los angefangen von Fehlern in bestimmten Daten, in bestimmten Transaktionsdaten bis hin zur Entscheidungsunterstützung in den operativen Abläufen innerhalb des Systems, also wie unterstütze ich die Sachbearbeiter dabei, die richtigen Hypothesen für ihre Entscheidungen zu bilden, also beispielsweise, wie viel Ware vom Produkt 4711 nachzubestellen ist. Das werden sehr, sehr spannende Fragestellungen im nächsten Jahrzehnt werden.
Der letzte Punkt, auf den ich eingehe, ist, dass wir uns natürlich auch noch viel, viel mehr Gedanken machen müssen, wie wir Daten über die Prozessabläufe, also über die Dinge, die innerhalb des Systems von Seiten der Sachbearbeiter oder Mitarbeiter durchgeführt werden, wegschreiben können, um sie entsprechend mit betriebswirtschaftlichen Hypothesen zu analysieren. Eine Analysefrage könnte zum Beispiel sein, liebes System, sag mir doch mal für den normalen Bürobedarfsbestellprozess, wie das typische Vorgehen ist und ob wir bei bestimmten Lieferanten vielleicht von diesem Vorgehen abweichen und ob diese Abweichung, die wir da machen, vielleicht sogar kostentechnisch für uns kontraproduktiv ist oder wir damit den Pfad des Standardbestellens verlassen. So, können wir heute nicht beantworten, müssen wir uns neben die Mitarbeiterstellen beobachten.
Es gibt seit einigen Jahren erste Ansätze, um entsprechend Prozessanalyse in den System zu machen. Ich habe relativ viele Systeme bei uns im ERP-Labor. Wir arbeiten mit relativ vielen ERP-Herstellern, mit Unternehmenssoftwareherstellern zusammen und ich kann sagen, viele Softwarehersteller haben dieses Wegschreiben von Prozessdaten, um sie später mit geeigneter Software analysieren zu können, überhaupt noch nicht in ihren Systemen großartig drin.
Man kann natürlich einiges locken, protokollieren, um es dann versuchen, irgendwo in den Prozesspfad zu bringen und zu analysieren. Das machen wir auch. Wir haben selber eigene Tools für das Process Mining geschrieben.
Wir arbeiten selber sehr eng an diesen Themenstellungen mit ERP-Systemen, mit Herstellern und wollen natürlich auch diesen Themenbereich entsprechend weiterbringen, also Task Mining, Process Mining. Wir sind da relativ gut aufgestellt. Ich glaube, auch das ist eine betriebswirtschaftliche Erfordernis, die wir zukünftig einfach an Unternehmenssoftware, an ERP-Architekturen stellen müssen.
Ich sehe das Thema ERP, auch wenn es ein Terminus technicus ist, der schon bestimmt 30 Jahre auf dem Buckel hat, noch lange nicht am Ende, mag es zukünftig Plattform heißen, wie im Microsoft-Umfeld oder wie bei mir Unternehmensdatenfundament. Wichtig ist einerseits, dass wir die technischen Architekturen weiterentwickeln, entsprechend der Infrastrukturanforderungen weiterentwickeln und dass wir uns vielleicht ein bisschen mehr als in der Vergangenheit auch über die betriebswirtschaftlichen Erfordernisse sehr viel Gedanken machen und ich hoffe, ich konnte mit diesem zweiten Teil der Episode so ein paar Gedankenspitzen ein bisschen was für die Synapsen mitgeben in dieser Woche. Ich danke Ihnen ganz, ganz herzlich fürs Zuhören.
Wie immer 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 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.