#106a – Fehler bei der ERP-Einführung: der digitale Status quo in der Industrie – ein Interview mit dem ehemaligen SAP-Berater und wissenschaftlichen Mitarbeiter Norman Pytel

Mit dem ehemaligen SAP-Berater Norman Pytel, der heute Mitarbeiter an meinem Lehrstuhl ist, unterhalte ich mich über Fehler bei der ERP-Einführung. Liebe ERP-Berater – hört genau zu. Liebe Anwendungsunternehmen: auch eure Fehler kommen zur Sprache und wir unterhalten uns über den digitalen Status Quo in der Industrie. Wie weit ist SAP S/4 und wo liegen die Herausforderungen?

Transcript:

ERP-Podcast Folge 106, erster Teil. Fehler bei der ERP-Einführung, der digitale Status quo in der Industrie. Ein Interview mit dem ehemaligen SAP-Berater und wissenschaftlichen Mitarbeiter Norman Pütell.

Mit dem ehemaligen SAP-Berater Norman Pütell, der heute Mitarbeiter an meinem Lehrstuhl ist, unterhalte ich mich über Fehler bei der ERP-Einführung. Liebe ERP-Berater, hört genau zu. Liebe Anwendungsunternehmen, auch eure Fehler kommen zur Sprache.

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, herzlich willkommen. Es ist wieder Mittwochmorgen. Wir wollen ein bisschen reden über die IT, über ERP, über das Unternehmensdatenfundament, wie ich auch gerne sage, und ich möchte heute mal reden über das Thema Fehler bei der ERP-Einführung.

Was ist eigentlich der digitale Status quo in der Industrie? Wie können wir weitermachen? Ich tue das nicht alleine. Ich habe mir wieder einen netten, sympathischen und vor allen Dingen versierten Gast eingeladen. Diesmal ist es ein Mitarbeiter von mir, Norman Pittel.

Er ist ehemaliger SAP-Berater und bereichert seit einiger Zeit bei mir das Team, was ja durchaus in der Breite sehr stark aufgestellt ist, von der Informatik, Mathematik bis hin in die Wirtschaftsinformatik und Betriebswirtschaftslehre. Und wer er ist und was er macht, das wird er uns gleich selber sagen und dann gehen wir in die Mediathrese. Herzlich willkommen, Norman Pittel, hier im ERP-Podcast.

Ja, schönen guten Morgen, Herr Prof. Winkelmann. Vielen Dank für die Einführung. Ja, zu meiner Person.

Wer ist eigentlich Norman Pittel? Also ich bin ehemaliger SAP-ERP-Berater aus dem Logistik- und Produktionsumfeld. Ja, die letzten drei Jahre war ich in der Zuliefererindustrie und vor allem im Automotive-Bereich unterwegs. Ja, und jetzt, sage ich mal, bin ich Mitarbeiter, wissenschaftlicher Mitarbeiter bei Ihnen am Lehrstuhl.

Ja, also das ist mal was, was für mich ganz besonders ist, dass jemand aus dem Studium, nach dem Masterstudium in die Industrie geht, Wissen reflektiert und dann auch letztendlich wieder zurück an die Alma Mater kommt, um das Ganze mit einer Promotion, mit einer Dissertation auch abzuschließen. Ich freue mich immer darauf. Das sind auch sehr spannende fachliche Diskussionen, die wir dann führen können.

Wir werden dann nachher auch noch mal darauf kommen, warum Sie diesen Schritt gewagt haben. Gehen wir ein bisschen auf Sie ein. Norman Pittel, ehemaliger SAP-Berater, Einführungsberater.

Welche fachlichen Schwerpunkte haben Sie dabei gehabt? Was macht man überhaupt als Berater in Ihrem Bereich? Also die ehemalige Berufsbezeichnung hieß bei mir eigentlich SCM-Berater. SCM ist in der SAP ja vor allem im Bereich APO eigentlich bekannt. Allerdings gibt es auch dort das SAP-EWM.

Das ist ein Warehouse-Management-System. Ich wollte gerade sagen, versuchen Sie bitte für die Zuhörer, die nicht ganz in der SAP-Welt sind, APO, Enterprise Warehouse Management und so weiter, dass wir so ein bisschen die Begriffe, die Abkürzungen auch verstehen. Genau, also APO ist eigentlich so die Antwort der SAP auf das Thema Feinplanung.

Also wenn Sie die Produktionslinie beispielsweise minuten- oder sekundengenau planen wollen. Und in dem Bereich gibt es allerdings auch Lösungen, die in der Lagerverwaltung zu finden sind, die ja etwas größer sind als, sage ich mal, das kleine Lager. Sondern da dreht es sich dann eher um Leger, die vollautomatisiert sind, wie zum Beispiel Leger von Unternehmen wie Amazon, die schon eine bestimmte Größe haben.

Und ich sage mal, das war zwar die alte Berufsbezeichnung. Allerdings würde ich mich selber eher als Logistikberater bezeichnen. Vor allem, weil ich in den Modulen MM, PP und WM unterwegs war.

MM, dabei handelt es sich um Materialwirtschaft und Einkauf. PP, Produktionsplanung und Steuerung. Und das Thema WM geht eigentlich so ein bisschen einher.

Genauso wie dieses Warehouse-Management-EWM. Ist so die kleine Komponente der Lagerverwaltung der SAP. Also ein typischer SAP, ERP-Logistikberater.

Und die Fragestellungen oder die Themen, um die es sich dann meistens gedreht hat, wo ich unterwegs war, waren Fragestellungen rund um die Programmplanung. Beispielsweise alles, was Planprimärbedarfe oder Kundenbedarfe geht und dazugehörige Planungsstrategien. Beispielsweise wollen Sie, machen wir es mal an einem Beispiel fest, ein Fahrzeug auf Lager fertigen.

Der Golf ist ein ganz gutes Beispiel dafür. Oder haben Sie eigentlich den Fünfer-BMW oder die S-Klasse, wo Sie jetzt nicht die Massenfertigung haben, sondern wo Sie konkrete Kundenaufträge haben und nur für die Kunden die Fahrzeuge bauen. Also es sind so typische Fragestellungen, die darüber hinausgehen, wie plane ich denn eigentlich genau die Komponenten für diese Fahrzeuge? Also wann, wie und welchen Werken werden eigentlich diese Komponenten geplant? Und dann kommen wir schon langsam eigentlich in Richtung Disposition.

Wenn ich die Komponenten geplant habe, muss ich auch schauen, wie ich sie denn eigentlich beim Lieferanten beschaffe. Also wenn es um externe Beschaffung geht. Wenn wir allerdings schauen, wir fertigen ja nicht nur Komponenten oder lassen sie fertigen von Lieferanten, sondern wir fertigen sie auch selber, kommen wir genau in Fragestellungen rein, wie die Fertigung, dass wir schauen müssen, wie fertigen wir selber denn die Komponenten? Ja, vor allem bei den externen Komponenten geht es dann um Themen wie Fragestellungen oder oder informationstechnische Verbindungen in Richtung Lieferanten und Spediteure.

Also wie kann ich tracken, dass die Teile wirklich zum richtigen Zeitpunkt bei mir im Werk ankommen? Also wir haben da so Technologien wie Track and Trace beispielsweise. Ja und wenn das Material dann irgendwann mal bei uns im Werk angekommen ist, kommen wir dann in so Fragestellungen, wie muss ich es direkt an die Linie bringen oder bringe ich es zuerst ins Lager? Wie ist denn überhaupt die Materialbereitstellung an die Produktionslinie? Also ich meine, wir können es noch weiter treiben. Eigentlich handelt es sich darum, wie plane ich es und wie kommt das Material in den Wareneingang durch die Produktion und dann zum Warenausgang direkt zum Kunden? Also eigentlich schon eine sehr breite Thematik und sehr oder man muss sehr integrativ in diesen Themen unterwegs sein, um zu verstehen, wenn man eine Schraube dreht, was passiert denn eigentlich mit den ganzen anderen Schrauben? Das ist eigentlich mein Stichwort, was ich jetzt halt, also ich habe sehr sehr aufmerksam eben zugehört, weil ich das unglaublich spannend finde, was auch der Berufsalltag letztendlich des Beraters aus dem ERP-Umfeld macht und wie qualifiziert man dafür auch sein muss.

Was mir aber auffällt, ist das Thema Integration. Also das zusammenführende Element letzten Endes und zwar, wenn ich in das SAP-Umfeld reinschaue, dann habe ich da sehr häufig Berater, auch gerne jüngere Berater, die haben eine sehr sehr spezifische Berufsbezeichnung und das, was sie geschildert haben, war zwar auch hochgradig integrativ, aber es war sehr stark auf einzelne Produktionsausschnitte fokussiert. Während, wenn ich mir gerade auch bei den mittelständischen ERP-Systemen anschaue, die Berater, dann sind die eher Seniorer vielleicht auch in vielen mittelständischen Beratungen und vom Wissen her haben die einen breiteren, einen integrativeren Ansatz.

Widerspricht sich das? Haben sie das auch so wahrgenommen? Wie kann ich auch als sehr spezifischer Fachberater hier vielleicht gegenüber Leuten, die sehr integrativ unterwegs sind, bestehen und auch entgegen reagieren? Also mein Eindruck aus der SAP-Welt war, die SAP-Berater, die ich kennengelernt hatte, waren vor allem, sage ich mal, in großen Beratungshäusern zu finden und die Berater waren teils weniger integrativ unterwegs und mehr in ihrem einzelnen Modul. Also man hat bei den Beratern problematisch festgestelltes Silo-Denken, was man eigentlich auch in der großen Industrie findet. Wenn ich beispielsweise Mitarbeiter im Einkauf bin, dann kenne ich mich nur mit Einkaufsthemen.

Wenn ich Mitarbeiter in der Fertigungsplanung oder in der Produktionsplanung bin, dann ist das eigentlich nur irgendwo mein Radius, wie weit ich denken kann. Und eigentlich ergeben sich viele Probleme eben durch Integration oder durch integrative neue Technologien, die wir gerade auch in Industrie 4.0 finden, zu sagen, ich muss eigentlich das Datenfundament in vielen Bereichen kennen, um nicht einen, sage ich mal, digitalen oder automatisierten Prozess in nur einem Bereich irgendwo umsetzen zu können, sondern eigentlich müsste die Denke unternehmensübergreifend oder auch abteilungsübergreifend sein, sage ich mal, smarte Prozesse irgendwo umzusetzen. Es ist schön, wie wir uns die Bälle zuschmeißen.

Wir haben das nicht verabredet. Im Prinzip ist es doch ein Plädoyer, Wirtschaftsinformatik zu studieren, oder? Also die Wirtschaftsinformatik ist vor allem ein Gebiet, wo man sagt, man bewegt sich genau zwischen diesen beiden Welten, Fachbereich oder BWL und der IT, zum einen den betriebswirtschaftlichen Prozess zu verstehen, allerdings auch zu verstehen, welche Daten ich dafür benutzen kann oder, ich sage mal, in der heutigen Zeit, welche Algorithmen kann ich denn eigentlich benutzen, um genau diese Prozesse zu optimieren, zu automatisieren und vielleicht auch genau diese wiederkehrenden Tätigkeiten im Unternehmen zu eliminieren, weil, wenn wir ehrlich sind, ist das eigentlich heute nicht mehr state of the art, wie man eigentlich arbeiten sollte, sondern spätestens wenn mir auffällt, dass der Fachbereich immer wieder dieselben Tätigkeiten macht, ist das eigentlich das erste Indiz, zu sagen, okay, wir gucken uns mit der IT eigentlich mal an, wie wir den Fachbereich da unterstützen können, weil der Fachbereich, so meiner Meinung nach, heute gar nicht verstehen kann, was wir aus der IT für ihn liefern können. So, jetzt verändern sich die Unternehmen, es verändern sich die Geschäftsmodelle.

Die Unternehmen müssen an einem Datenfundament arbeiten, sprich ERP einführen, darüber hinausgehen. Wer meine Folgen so ein bisschen verfolgt, wird das Stichwort, die Reduzierung von virtuellen Puffern hin zur kompletten Automatisierung der BWL sicherlich schon mal gehört haben. Ansonsten, ich verlinke es auch gerne nochmal in den Shownotes von dieser Folge.

Sie kommen jetzt als Berater rein in dieses Unternehmen. Entweder das Unternehmen weiß schon ein bisschen was oder vielleicht auch noch gar nicht. Was haben Sie so als Berater, wenn Sie in solche Unternehmen reingehen, festgestellt, wenn die ein ERP einführen wollen? Also, ich glaube, wenn sich ein Unternehmen für ein bestimmtes ERP entschieden hat und wenn wir dann in Größenordnung sind wie Oracle, Microsoft oder SAP, dann ist, glaube ich, viel schon in dem Bereich gelaufen, dass viel Marketing abgespult wurde, viele politische Diskussionen geführt wurden.

Und als Berater kommt man dann eigentlich nur noch in die Möglichkeit zu sagen, okay, das Unternehmen hat sich entschieden, das Projekt wurde aufgesetzt, hier sind wir jetzt und jetzt legen wir los. Das ist genau so das Arbeitsgebiet, wo ich dann eigentlich eingesetzt wurde. Und oftmals hat man dann Problemstellungen oder Themen festgestellt, die wiederkehrend zu finden sind in jedem Projekt.

Und dann reden wir eigentlich noch gar nicht über das ERP-System als Software, dass es die Prozesse irgendwo verbessern kann, sondern wir reden über Themen wie Projektorganisation oder ganz klassisch Change Management. Also, inwiefern habe ich denn überhaupt die Mitarbeiter vorbereitet? Ja, in Themen wie, wir werden anders morgen arbeiten, da wo ihr heute nicht bucht, müsst ihr zukünftig buchen oder wir führen andere IT-Lösungen ein, wo ich aus eigener Erfahrung sagen kann, die IT-Lösung hat dann zwar funktioniert, aber die Buchungsqualität war einfach so schlecht, dass wir ERP-Systeme oder Lösungen im Produktionsumfeld eingeführt haben, die mangelt Change Management. Also im Sinne von, ich habe das Unternehmen oder die Mitarbeiter mitgenommen, diese IT-Lösung zum Erfolg zu bringen.

Und wenn wir von Projektorganisation und dem Change Management mal weiterschauen, also klassisch die technischen Fragen, die dahinter stecken, dann sind es vor allem fehlerhafte oder fehlende Stammdaten. Wenn man sagt, man kommt aus einem Altsystem, wo nicht die Datengrundlage da war, um gut zu planen, dann müssen beispielsweise viele Stammdaten nachgezogen werden oder es gibt Migrationsprobleme, weil man unterschiedliche Systemfunktionen hat. Ich glaube aber auch, dass das Thema, wenn man als Unternehmen sich entscheidet, ein neues ERP-System einzuführen, war auch ein beliebter Fehler, diese Frustration zu merken, die vor allem die ältere Belegschaft mitgebracht hatte aus vergangenen IT-Projekten, dass diese eigentlich die Kernkompetenz haben und für die ERP-Einführung, ich nenne es mal, die B-Mannschaft geschickt haben.

Aber das Problem bei dieser B-Mannschaft ist, dass die genau die Unternehmensprozesse nicht so kennt wie die A-Mannschaft. Und als Berater hat man natürlich dann das Problem, wie soll man bestimmte Anforderungen umsetzen oder es fällt halt im Nachhinein auf, gewisse Anforderungen sind überhaupt nicht genannt worden, wo man dann als Berater dastehend eigentlich nicht mehr viel machen kann im Sinne von, wir sind jetzt zwar live, aber wir müssen halt die ganzen Anforderungen nachziehen. Ich grätsche da mal rein, weil das sind jetzt alles ja schon organisatorische Dinge, in die wir einsteigen.

Ich würde da auch gerne jetzt noch mal einsteigen. Sie kommen als Berater rein in das Unternehmen. Sie sind Teil eines Teams.

Da sind viele Entscheidungen, wenn Sie kommen, wahrscheinlich ja schon gefallen. Und die Frage, die sich mir stellt einfach, was finden Sie organisatorisch vor? In welchen Projektformen? Gibt es überhaupt schon ein Projektteam? Sie haben gerade gesprochen, meistens sind es dann irgendwelche B-Teams aus den Fachabteilungen, die in dem Projekt mitarbeiten. Ich habe gestern ein Gespräch geführt mit jemandem, der sagte, na ja, ich habe gar keinen so in der IT, also ein kleineres Unternehmen, das ist wahrscheinlich nicht Ihr Problem, wenn Sie SAP einführen.

Da haben Sie dann schon Fachteams. Aber wie sieht so eine Projekt-Organisationsstruktur aus, die Sie vorfinden? Wo Sie vielleicht auch sagen, ist gut oder eben B-Team? Also ich glaube, man kann ab einem bestimmten Unternehmensgründe Ich würde sagen, eine gute Projektorganisation wäre, dass man, wenn man mehrere Werke hat, mehr oder weniger ein zentrales Team hat, was in der IT sitzt und lokale Teams vor Ort, die die Anforderungen der Werke vor Ort umsetzen. Allerdings das zentrale Team dabei auch so eine Art, nennen wir es mal, Wissensdatenbank übernimmt, weil dieses zentrale Team wird vor allem dafür sorgen, dass das gesamte Unternehmen letzten Endes immer mehr diese SAP-Lösung umsetzen wird oder einsetzen wird. Und die lokalen Teams sorgen eigentlich dafür, dass genau die Anforderungen, global getriebene Anforderungen oder auch das Wissen, was global gesammelt wurde, in den einzelnen Werken vor Ort zum Einsatz kommt.

Also explizit geht es dann darum, dass man sagt, man baut sich eigentlich ein Template, ein sogenanntes IT-Template, in dem die IT die individuelle Lösung oder eher die Standardprozesse abbilden kann. Und man rollt dieses Template dann auf die Werke aus, fängt beispielsweise mit einem kleinen an, dass es nicht komplex ist oder zu komplex wird am Anfang und geht dann sukzessive durch die Unternehmen durch, um dieses Template immer weiter auszubauen. Das Schwierige an der ganzen Geschichte ist, glaube ich, allerdings zu sagen, dass man vorher die Werke mindestens einmal abgeklopft haben sollte, was Anforderungen angeht.

Weil das Schlimmste, glaube ich, was passieren kann, ist, wenn man genau dieses Template gebaut hat, um am Ende dann festzustellen, dass die Anforderungen in anderen Werken so unterschiedlich sind, dass man diese Arbeit oder diesen Aufbau des Templates eigentlich umsonst gemacht hat. Kann man den Unternehmen Tipps geben, wie man das Unternehmen erstmal vorbereitet auf so ein Projekt? Also ich denke, es ist zum einen die Projektorganisation, die ich gerade angesprochen habe, aber zum anderen auch das Change-Management, dass man Mitarbeiter mitnimmt, Schulungen im Anfang dann anbietet, vor allem auch den Engpass, also die internen Kapazitäten bereitstellt oder zumindest die Vorbereitung dafür trifft, dass genau diese A-Mannschaft eigentlich auflaufen kann, um die Herausforderungen, die wir jetzt im Bereich einer ERP-Einführung haben, meistern zu können. Und ich glaube, einer der wichtigsten Punkte ist, dass genau diese A-Mannschaft dann dafür sorgt, dass die Prozesse, die in so einem IT-Template drin sind, auch getestet werden.

Also eins war auch festzustellen, dass genau nach diesen Go-Lives, also in dem Sinne, wo wir die Lösung dann scharf geschaltet haben, aufgefallen ist, dass beispielsweise zu wenig getestet wurde oder auch mal gar nicht getestet wurde oder die Prozesse nicht End-to-End getestet wurden. Also beispielsweise mit einem Material genau diese integrativen Prozesse einmal durchzubuchen, um festzustellen, ob der Material- und Informationsfluss vom Eingang des ERPs bis zum Ausgang des ERPs komplett funktioniert. Okay, also Qualitätsmanagement ganz wesentlich als Erfolgsmoment.

Also alle Folgen zu Projekt, Orga und Auswahl, die wir hier im ERP-Podcast gemacht haben, auch die, liebe Zuhörer, packen wir Ihnen natürlich in die Shownotes. Sie können also nachschlagen, andere Folgen hören, aber es ist ja auch immer wieder schön, aus anderen Blickwinkeln darüber zu sprechen. IT, die mit reingeholt werden muss, Mitarbeiter aus den Fachabteilungen.

Was können Sie jetzt Unternehmen raten, die im Auswahlprozess nicht nur der eigenen Mitarbeiter stecken, sondern die vor allen Dingen dann auch im Auswahlprozess eines Beratungshauses stecken? Das ist eine gute Frage. Ich glaube, dass die Unternehmen, die sich schon entschieden haben für SAP und jetzt gerade dabei sind, zu sagen, welches SAP-Beratungshaus kann dann genau dieses Projekt stemmen, wäre es, glaube ich, ratsam, genau diese A-Mannschaft mal auflaufen zu lassen und fachliche Fragen den Beratern zu stellen. Denn was ich in meiner Karriere festgestellt habe, ist, dass sich teilweise SAP-Berater Seniors nennen und allerdings den Kenntnisstand eines Juniors haben in einigen Bereichen.

Womit man dann eigentlich sehen kann oder herausfinden kann, mit ganz einfachen fachlichen Fragen der A-Elite, die im eigenen Unternehmen eigentlich da ist, was weiß denn der Berater eigentlich. Und im Vorhinein, bevor man diese Fragen irgendwo dem Berater stellt, kann man die Unternehmen auch schon fragen, ob sie nicht das eine oder andere Projekt, was der Berater schon mal umgesetzt hat oder was die Mannschaft, die dort auflaufen soll, was die für Projekte umgesetzt haben, um für sich selber einen ersten Eindruck davon zu bekommen, was denn die Mannschaft da überhaupt des Beratungshauses imstande ist zu leisten. Aus dem einfachen Grund sollte man das machen.

Ja, wer kauft schon die Katze im Sack? Also, ich nenne es mal so. Ich glaube, das wird einfach ein Problem werden, wenn man Berater sich reinholt, wo man nicht zumindest mal ein Mindestmaß an Qualitätssicherung betrieben hat. Jetzt ist das typische Problem, was der Mittelstand gerade auch immer wieder feststellt, man hat da eine Mannschaft von Beratern vor sich sitzen, das System gefällt, die Mannschaft ist kompetent, man hat gemeinsam einen Kriterienkatalog erarbeitet, der Vertrag wird abgeschlossen, die Verhandlungen sind abgeschlossen, das Projekt beginnt und der Herr Meier als erfahrener Berater taucht gar nicht mehr auf, sondern es taucht irgendein Newbie, irgendein Rookie mit Hochschulabschluss auf, der eigentlich noch gar nicht weiß, wie das System funktioniert.

Also, ich denke, die Mischung aus jung und alt wäre eigentlich der richtige Weg. Nur jung oder nur alt. Ja, also, sie haben es gerade bei dem Rookie genannt.

Bei dem Rookie habe ich das Problem, dass er vielleicht gar nicht das System in der Tiefe kennt, wie man es eigentlich kennen müsste. Das kann der alte Berater machen. Der alte Berater, ich sage mal, wenn wir eigentlich Prozesse von morgen bauen oder IT-Prozesse, dann habe ich das Problem, dass diese alte Berater ja Wissen von vor 40 Jahren oder anders formuliert, wir bauen Prozesse von morgen mit Leuten, die mehr als 20 Jahre unterwegs sind und Wissen von vor 40 Jahren haben.

Für mich ist die Mischung aus jung und alt eigentlich der richtige Weg, wie man die Fragestellungen oder die Herausforderungen von heute meistert, weil wir zum einen die fachliche Tiefe des alten Beraters haben, aber auch die Kreativität und auch das neue Wissen der Universität beim jungen Berater vorfinden. Also, ich erinnere mich gerade dran in der ERP-Podcast-Folge mit Ulf Erben, internationale SAP-Retail-Projekte, sagte er eben auch, das gibt verschiedene Wege, um zur Lösung zu kommen. Also, es geht jetzt nicht um betriebswirtschaftliche Wege, sondern auch technische Wege.

Und wenn ich halt eingefahren bin in meinen technischen Lösungsweg, da mache ich das halt immer so. Und das könnte tatsächlich auch ein Problem von Senioren-Beratern sein, dass die irgendeinen Weg wählen, der früher vielleicht mal sehr gut war, technischer Art, aber der heute eher eine antiquite technische Lösung darstellt, oder? Also, ich denke, in guten Beratungshäusern wird man vor allem eine Mentalität finden, die heißt 100 Prozent Motivation, aber 80 Prozent Übereinstimmlichkeit. Also im Sinne von, wir wissen einen groben Korridor, in den wir eigentlich rein wollen, aber durch Diskussionen kommen wir eigentlich genau zum Ziel, um das umzusetzen, was der Kunde eigentlich morgen will.

Das ist so meine Meinung zu dem Thema. Okay. Jetzt sind Sie nicht mehr Berater, also Sie können vielleicht ein bisschen offener über die Branche sprechen.

Ich möchte jetzt auch die Branche nicht irgendwie in Verruf bringen oder so, weil wir haben ja wirklich extrem richtig, richtig gute Leute auch in dieser Branche. Ich ziehe meinen Hut auch vor allen, die sowohl dieses technologische Wissen als auch das betriebswirtschaftliche Wissen an der Stelle haben. Und ich sorge mit meinen Mitarbeitern letztendlich ja auch dafür, dass es immer wieder neue Unternehmensberater, ERP-Berater ausgebildet werden.

Aber wenn wir mal auf die Berater schauen, was sind so typische Fehler, die Berater bei der ERP-Einführung machen? Das ist eine gute Frage. Ich würde mich da gar nicht selber ausschließen wollen, weil ich habe auch selbst genug Fehler gemacht, aber genau durch diese Fehler lernen wir eigentlich. Und auch bei dem einen oder anderen Kunden, wo ich dann hingekommen bin und ans ERP-System gesetzt wurde, hat man auch so Fehler, immer wieder im Kern gesehen, die Berater eigentlich machen, wenn sie ja mit ERP-System zu tun haben.

Ich glaube, eins der größten Probleme ist, aber das liegt dann vielleicht auch in unserem Schulsystem, ist das Problem, dass wenn sie denken, ich stelle ihnen eine Frage und diese Frage beinhaltet ein Problem, dass sie sofort die Lösung wissen. Das ist das, was wir eigentlich in der Grundschule beigebracht bekommen. Eins plus eins ist zwei.

So trivial ist eben die Welt daraus nicht. Und deswegen ist einer der beliebtesten Fehler, glaube ich, von Beratern, dass sie dem Kunden zwar zuhören, meinen das Problem verstanden zu haben, aber das Problem nicht zu Ende analysiert haben und eigentlich schon die Lösung im Kopf wissen, wie gesagt, obwohl sie das Problem nicht 100 Prozent durchleuchtet haben. Und am Ende eine IT-Lösung umsetzen, die leicht am Problem vorbeigegangen ist oder es vielleicht nicht vollkommen umsetzen konnte.

Okay, also Sie sagen, der typische Fehler ist eigentlich, vor der Konzeption die fixe Lösung zu haben, die dann implementiert wird und die Konzeption eigentlich viel zu kurz kommt. Ich glaube, dass die Konzeption nicht zu kurz kommt. Ich glaube eher, dass es ein Teil der Empathie ist, den Anwender oder den User oder den Kunden, wie noch immer, zu verstehen, was eigentlich das richtige Problem ist.

Und dieses Zuhören-Problem oder dieses zu Ende Zuhören-Problem, das ist eigentlich der Grund, warum man dann vielleicht ein falsches Konzept aufbaut und dazu neigt, und das ist auch einer der beliebten Themen, dass man Dinge eigentlich programmiert, die man vielleicht auch im ERP-Standard hätte lösen können. Okay, schließt sich eine zweite Frage eigentlich an. Was Anwendungsunternehmen dem Berater immer vorwerfen, ist das Gefühl, der Berater würde eigentlich für zusätzliche Manntage sorgen, also sprich, Lösungen verkaufen, die zusätzlichen Aufwand bieten.

Können Sie das bestätigen oder würden Sie eher sagen, das ist eigentlich eher ein Mythos? Jein. Also ich würde sagen, das ist genau das Thema Berater-Ehre. Sind Sie ein Berater oder sind Sie ein verkaufender Berater? Um aus eigener Erfahrung zu sprechen, eines der ersten Projekte, wo ich eingesetzt wurde, war, dass ich dem Kunden direkt aufzeigen konnte, dass wenn er, wir haben uns ja vorhin über das IT-Template unterhalten, wenn er genau dieses IT-Template bei sich implementieren oder betreiben wird, dass er, ja und das war jetzt eher so ein Bauchgefühl, aber zumindestens konnte ich systematisch aufzeigen, dass wenn er dieses IT-Template jetzt einführt, nach zwei Wochen eigentlich die erste volle Inventur wieder machen kann, weil das Template nicht das hergibt, was es eigentlich verspricht oder was das zentrale Team versprochen hat und zum anderen, weil, ja und hier sprechen wir wieder vom Change-Management, weil die Disziplin vor Ort eigentlich gar nicht vor Ort war, aber das, was man wirklich beobachten kann, ist und da muss man an die Berater-Ehre appellieren, zu sagen, kann ich das im Standard lösen, kostengünstig oder habe ich genau einen Berater vor mir, der, ja einfach verkaufen will und das ist super schwer rauszufinden und ich glaube, wenn man ein Beratungsunternehmen gefunden hat, was da gute Arbeit liefert oder auch aufzeigen konnte, was in der Vergangenheit vielleicht nicht optimal im System gelaufen ist, dann hat man da schon einen Felsen im Stein in der Beratung.

Also wir sprechen jetzt über sehr, sehr große ERP-Applikationen, das heißt viele Möglichkeiten zu parametrisieren, viele Möglichkeiten zu customisen, viele Möglichkeiten, Sachen im Standard zu machen, aber vielleicht auch als Individuallösung zu entwickeln. Für den Fachanwender, der das System noch nicht so gut kennt, ist das natürlich schwierig, die Gestaltung des ERP-Beraters sozusagen zu durchschauen. Aus meiner Sicht vielleicht sinnvoll, jemanden reinzuholen, der fachlich neutral sozusagen das gesamte SAP-System übersieht, der aber nicht in diesem Funnel von ich muss mehr Manntage verkaufen drin hängt, sondern neutral das Unternehmen als Oberaufseher beraten kann.

Halten Sie das für sinnvoll? Ich glaube, der Punkt kann sinnvoll sein, wenn man ab einem gewissen Punkt im Projekt sich genau diese Fragen stellt, dass man ein Konzept hat und in wie weit ist denn dieses Konzept valide, dass man erfahrene Berater oder unabhängige Berater, meist auch Selbstständige, sich genau dieses Projekt mal mit rein holt und über dieses Konzept mal rüber gucken lässt. Das sind dann wahrscheinlich mal nochmal zehn oder zwanzig Manntage, die man damit verpulvert. Allerdings, vielleicht könnten es auch genau 100 oder 200 Manntage sein, die man dadurch spart.

Diese Ansicht kann man glaube ich schwer rechnen, aber ich bin ein Freund davon, genau diesen fachlichen Austausch unter den Beratern umzusetzen oder zu empfehlen. So, jetzt möchte ich natürlich den Beratern nicht das Gefühl geben, wir schlagen hier auf die Berater ein, im Gegenteil, es gibt wirklich Top-Berater draußen auf dem Markt, extrem gut, die sich auch ein Bein ausreißen für die Kunden, also nicht alles, was der Kunde wahrnimmt, ist dann auch tatsächlich Fehler des Kunden. Wir haben schon ein bisschen darüber gesprochen, auch die Anwendungsunternehmen, die Projektteams machen ganz viele Fehler.

Vielleicht nochmal so ganz kurz aufgelistet, was sind so die Top-Fehler, die sie immer wieder wahrnehmen in solchen Projekten? Also ich denke, die Top-Fehler in solchen Projekten sind, dass die Anwendungsunternehmen zu wenig Kapazitäten für Projekte bereitstellen. Also man kann natürlich als Berater nur damit arbeiten, was einem an Zeit geboten wird oder geliefert wird. Man steht natürlich auf verlorenen Posten, wenn man keinen internen Ansprechpartner hat, der einem gar nicht zuarbeiten kann oder die Anforderungen richtig stellen kann und ich glaube, Top 2 ist diese Probleme oder Anforderungen klar formulieren zu können.

Also vor allem Mitarbeiter aus dem Fachbereich, jetzt nehme ich mal BWL und IT zusammen, tun sich super schwer, die Anforderungen, die sie eigentlich haben, konkret und richtig formulieren und ausführlich formulieren zu können. Ich glaube, eins meiner Highlights war in einem agilen Softwareprojekt, wo jemand eine Anforderung stellte, das System soll betriebswirtschaftlich sinnvoll planen, wo ich mir denke, super. Also mit so einer Anforderung kann natürlich ein Entwickler definitiv nichts anfangen.

Das ist, glaube ich, so einer der Punkte, wo die Unternehmen Schwierigkeiten haben, eigentlich aufzuzeigen, was das Problem ist. Ja, ich glaube, das sind so meine Top 2. Okay, also jetzt haben wir gesprochen, was ist das Problem mit Beratern vielleicht auch an der Stelle, wobei die Auftragslage bei Beratern momentan so groß ist, dass man gar keine Angst haben muss, dass die Berater zu lange in einem Projekt bleiben wollen wahrscheinlich. Gleichzeitig die typischen Fehler, die auch von den Anwendungsunternehmen, von den Projektteams gemacht werden.

Jetzt reden wir doch nochmal als drittes über Fehler, die sie vielleicht auch typischerweise beim ERP-System oder bei ERP-System gefunden haben. Also ich denke, eins der größten Fehler im ERP-System oder wenn man als Berater in ein Unternehmen kommt, wo viel im ERP-System schon gelaufen ist an Einstellungen, war, dass wenig dokumentiert ist über beispielsweise Zusatzprogramme. Also man sitzt als Berater vor einem Spaghetti-Code, der gefühlte 20.000 Zeilen hat und die Anforderung der IT ist, lieber Berater, finden Sie doch jetzt mal den Fehler.

Das ist natürlich schlecht, wenn vorher niemand intern mal drüber geguckt hat, wie denn eigentlich im ERP-System gekodet wurde. Also mehr oder weniger nimmt es mal so wie so eine Abnahmeprüfung für den Code oder Themen, die eigentlich im Standard hätten umgesetzt werden können, wurden durch Programmierung umgesetzt oder das ERP-System war eigentlich die Bank, um schlechte betriebswirtschaftliche Prozesse hochzuhalten. Also man hat eigentlich eine IT-Lösung auf einen schlechten Prozess gebaut, wo eigentlich der Prozess hätte umgestellt werden müssen.

Das sind glaube ich so die Top 3, die man da finden kann. Okay. Ich könnte jetzt noch ganz tief reingehen.

Ich gucke so ein bisschen auf die Uhr. Wir sind wieder etwas über unsere magische Schwelle von einer halben Stunde drüber. Ich würde gerne den hier einfach zubinden, würde den aber nächste Woche gerne nochmal wieder aufmachen und zwar würde ich gerne auch von Ihnen erfahren, was es da Neues gibt in der SV-Welt, also in der Veränderung, die die SAP jetzt auch im großen ERP-System vornimmt und vielleicht auch, dass wir ein bisschen über den digitalen Status in der Industrie hier auch zu sprechen kommen.

Wenn das für Sie okay ist, würde ich Sie gerne nächste Woche nochmal einladen, genau an der Stelle mit mir weiterzumachen. Ich bedanke mich ganz ganz herzlich bei Norman Petel für diese erste Runde und wir sehen uns und hören uns nächste Woche wieder. Vielen Dank.

Vielen Dank, Herr Prof. 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.