Erfahren Sie im ersten Teil dieser Doppelfolge unter anderem,
- warum CIO der schönste und schrecklichste Beruf gleichzeitig ist,
- wie die moderne IT-Abteilung sich erfolgreich aufstellen kann und
- welche neuen Geschäftsmodelle für die IT sinnvoll sein können.
Viel Vergnügen!
Webempfehlung:
————————–
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:
Der ERP-Podcast weckt den Service wird ein Interview mit dem IT-Management und ITIL-Spezialisten Robert Sieber. Erfahren Sie im ersten Teil dieser Doppelfolge unter anderem, warum CIO der schönste und schrecklichste Beruf gleichzeitig ist, wie die moderne IT-Abteilung sich erfolgreich aufstellen kann und welche neuen Geschäftsmodelle für die IT sinnvoll sein können. 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. So herzlich willkommen zurück zum ERP-Podcast. Wieder eine neue Folge. Heute eine Folge mit einem interessanten Gast aus dem Bereich IT Service Management. Er bezeichnet sich selbst als Service Nerd. Er ist Inhaber einer Firma. Er ist leidenschaftlicher Podcaster. Auch und ich freue mich, dass er sich die Zeit genommen hat, hier im Podcast Rede und Antwort zu stellen. Ich begrüße ganz herzlich bei mir Robert Sieber. Herr Winkelmann. Wunderbar, Vielen Dank. Ich freue mich, hier zu sein. Und bei der Anmoderation kann ich ja eigentlich gar nicht mehr so viel erzählen. In der Regel steht bei mir unter Namen Berater, Podcaster, Service Nerd und das beschreibt es, glaube ich, relativ gut. Können Sie das ein bisschen ausführen? Was ist ein Service Nerd? Also was ein Podcaster ist, weiß jeder, der den Podcast hört. Also heute hier ist. Aber was ist ein Service? Nerd? Das ist ein. Das ist ein Begriff, über den streite ich auch immer wieder mit meiner Community, Weil Nerd ist ja bei uns im Sprachgebrauch eher so ein bisschen negativ belegt, dass der Nerd, der sitzt da in der Ecke und macht irgendetwas. Für mich ist ein Nerd jemand, der in etwas aufgeht, der für etwas brennt, begeistert ist. Und wenn ich das jetzt so ein bisschen mit IT, mit Service, mit Unternehmen zusammenbringe, dann habe ich irgendwann mal ein ja drei Sätze geprägt, die ich jetzt mal kurz vorlese, weil ich sie nie auswendig gelernt habe. Service Nerds stellen Menschen und Prozesse und die Geschäftsmodelle ihres Unternehmens in den Mittelpunkt des IT Service Management. Wir sehen IT nicht primär aus technischer Sicht, sondern als zweckmäßiges Mittel. Und für uns ist der Endkunde wichtig, das Produkt, die Dienstleistungserfahrung und letztlich Time to market. Das ist für mich ein Service Nerd, der kümmert sich ums Unternehmen. Also finde ich ganz toll, weil ich denke ähnlich ein Nerd, auch im positiven Sinne ist jemand, der für etwas brennt und die Betrachtung, wer das eigentlich ist, das hängt ja nur vom Betrachtungswinkel ab. Also nur zu sagen, die die IT-Leute, das sind eigentlich Nerds. Aus IT-Sicht sind andere Bereiche des öffentlichen Lebens da vielleicht noch viel schlimmer als wir in Bezug auf Brennen für eine bestimmte Sache. Sie brennen für das Thema IT Service Management. Sie haben eigenen Podcast. Wie heißt der? Was machen Sie da drin? Der Podcast heißt Och, das war es ganz am Anfang. IT Management Podcast zu finden auf www.different-thinking.de. Die URL ist definitiv Programm und im Podcast gibt es immer eine Mischung aus Beiträgen von mir, dass ich über Dinge spreche, die mich gerade bewegen, die mich in meiner früheren Rolle als CEO bewegt haben, die mich heute in der Beraterrolle bewegen. Was ich bei Kunden sehe und auf der anderen Seite immer wieder sehr interessante Interviewgäste zu Themen, die vielleicht nicht ganz was mit IT zu tun haben, wie Kommunikation, wie Vertrieb, Marketing oder das Gespräch, was wir aufgenommen haben über ERP-Systeme, was eher wieder in Richtung IT geht, so dass man bei mir durchaus so quasi Rundumschlag bekommt von dem, was ich denke, was man als Service tatsächlich wissen darf. Ich verfolge Ihren Podcast schon ein bisschen länger und Sie gehen ja letztendlich oder der Mensch Robert Sieber geht, ist ja gegangen von der Rolle eines Angestellten CEOs mit vielen Zwischenstationen, letztendlich zur Gründung eines eigenen Unternehmens. Was hat es damit auf sich? Was hat es damit auf sich? Wenn ich in meine Historie zurückschaue, dann habe ich irgendwie immer den Wechsel zwischen Anwendungsunternehmen und Dienstleister Berater. Angefangen habe ich als Administrator während meines Studiums, dann entwickelt hin zum Third Level Support bzw. zur Architektur von Infrastrukturen. Dann bin ich, wenn ich auf die Beratungsseite gewechselt habe, dort Technologiemanagement gemacht, habe dann irgendwann den Geschäftsbereich mit IT Service Management und IT Service Management Tools übernommen und dann war es mal wieder Zeit auf die Anwenderseite zu wechseln. Ich habe für ein Unternehmen mit 800 Mitarbeitern 20 Unternehmen in dem Konzern die IT geleitet. Und dann gab es irgendwie eine Gelegenheit, bei der ich gesagt habe Ja, jetzt machst du dich endlich selbstständig. Weil das ist was, was mich fürchterlich reizt, das wirklich zu machen, was mich bewegt, Menschen vorwärtszubringen und vor allem auch die Beratung, egal ob das jetzt digital stattfindet mit meinen Angeboten oder tatsächlich vom Kunden. Ich möchte, dass die Unternehmen weiterkommen, dass sie wirklich Servicemanagement machen. Und bei mir liegt beim Service Management die Betonung auf Service und nicht auf Management. Das klingt wirklich nach Nerd. Das klingt nach Leidenschaft an der Stelle. Sie haben so eine schöne Folge. Die haben Sie genannt. Warum der CIO der schlimmste und schönste Job gleichzeitig ist. Vielleicht können wir da mal einsteigen. So ein bisschen in das Inhaltliche. Als CIO, als IT-Leiter bin ich. Wenn ich das möchte, bin ich ganz vorn dabei. Ich habe das Wissen um Technologien. Ein CIO beobachtet den Markt. Blockchain, Big Data, künstliche Intelligenz, was auch immer. Das sind Dinge, die einen in der Regel an der Stelle interessieren. Wenn sich dann noch ein Interesse für Prozesse, für Geschäftsmodelle dazukommt, dann kann ich als interner Berater zu den Business Units gehen, zu den Fachbereichen gehen und mit denen ins Gespräch kommen und sagen Hey, hier gibt es wunderschöne neue Dinge. Lasst uns da mal drüber nachdenken, wie wir das für unser Geschäft nutzen können. Beispiel eines der Unternehmen in dem Konzern war ein Bildungsunternehmen, eine Privatuniversität. Ganz klassisch Präsenzformate. Gutes Geschäft, keine Frage. Und mit dem Wechsel des Geschäftsführers? Da kam ganz neuer Wind. Und in der ersten Woche haben wir zusammengesessen und darüber geredet, was heute alles technologisch gehen würde, wenn wir über Fernlehre nachdenken, wenn wir darüber nachdenken, dass diese Masterkurse nicht mehr zwangsweise in Präsenz stattfinden müssen oder wenn Menschen krank sind, wie sie das nachholen können. Konsequenz daraus war, dass wir entsprechende Räume, die gerade gebaut wurden, mit Technologie ausgestattet haben, damit wir das genau erledigen können. So, und dieses Treiben des Business. Jetzt habe ich es tatsächlich gesagt, dass das Treiben des Business zu informieren, was geht heute? Das ist die coole Seite an der Stelle, das ist das, was ich machen möchte als CEO. Was ich als CEO muss, ist natürlich das Ganze auch irgendwie zu betreiben. Und wir alle wissen Technik ist nicht zuverlässig. Da geht irgendwas unterwegs schief. Und ein Vertrauen, was man sich auf der anderen Seite aufgebaut hat, kann selbst durch kleine Dinge relativ schnell wieder ins Wanken geraten. Und es gibt vielleicht durchaus die eine oder andere unschöne Situation, in der man viel mehr wieder in den Betrieb rein muss und dafür sorgen muss, dass das eine oder andere wieder funktioniert. Und das sind dann so die Dinge. Ja, vielleicht ist Gott doch gar nicht so schlecht. So eine Verantwortung zu teilen, zu sagen, der eine macht die schönen Dinge, der anderen macht die weniger schönen Dinge. Also das ist auch das, was ich meinen Studierenden immer wieder in Veranstaltungen wie IT-Management oder ähnlich zu vermitteln versuche. Dass die IT-Organisation die IT-Abteilung eigentlich so zwiegespalten ist. Auf der einen Seite progressiv Potenziale erkennen, Technologie nicht um der Technologie willen, aber um Rationalisierung um Nutzen nach vorne zu bringen. Auf der anderen Seite ist man auch froh, oder Teile der IT-Abteilung sind auch froh, wenn die Festplatte einfach nur ruhig läuft. Übertrieben gesprochen macht es das nicht für den für den CIO. Dieser Spagat auch von den ganz unterschiedlichen Leuten, die ich dann dafür brauche, macht es das nicht fast unmöglich? Das ist eine Frage der Größe einer Organisation. Also wie stark kann ich meine Organisation strukturieren im Sinne von Die Wissenschaft behauptet Heute glaube ich, man kann sieben Direct Reports haben. Also wie kann ich das unterstrukturieren, um da nicht selbst wirklich diesen Spagat haben zu müssen? Meine Organisation war etwas klein und da ist dieser Spagat definitiv da. Das meine Antwort darauf ist immer Ich muss Generalist sein. Ich sage, ich darf aus jedem doofen Hund kennen, damit ich mich auf die einzelnen Personen auch einstellen kann, dass ich mit den einzelnen Personen auch tatsächlich auf der Beziehungsebene was, was herstellen kann, was aufbauen kann. Ich darf mein Gegenüber verstehen. Und das ist jetzt egal, ob in der IT oder ob das die Kollegen aus den Fachbereichen sind. Das kommt ja am anderen Ende immer noch dazu. Viele IT-Organisationen sind ja irgendwo historisch auch entstanden. Wenn ich mir das historisch angucke, wie sich IT entwickelt hat, dann war als die ersten IT-Abteilungen entstanden, vielleicht nur ein Mitarbeiter eingestellt wurde. Die Frage wo hängen wir den denn auf? Und damit war eigentlich die logische Konsequenz Wir packen den in den Verantwortungsbereich der Finanzabteilung, weil die haben eh die Budgets und der kostet ja nur was. Und damit war eigentlich die Natur der IT-Abteilung als Costcenter relativ offensichtlich manifestiert. Ist das heute noch so? Arbeiten die meisten IT-Abteilungen als Costcenter oder als Profitcenter? Oder was ist eigentlich ideal für eine Abteilung? Die Frage beantworte ich gleich. Ich möchte auf diesen Ursprung kurz eingehen. Gerne. Der Kardinalfehler ist nicht, die IT unter die Finanzen zu hängen. Das ist einfach eine organisatorische Aufhängung, die ist letztlich egal, wo es ist. Der Kardinalfehler, der meiner Meinung nach irgendwann, warum auch immer passiert ist, das war die Trennung von etwas, was ich gerne Betriebsorganisation nenne, also wo die Verantwortung für die Prozesse drin war, wo die Verantwortung für die Betriebsabläufe drin war hin zu einer eigenen IT-Abteilung. Weil die, die Erfahrung gerade aus dem Beratungsbereich zeigt, da wo diese Verantwortung für Prozesse, für Qualität, für IT, für Digitalisierung, für Risikomanagement in einer Hand liegt, da funktioniert IT wesentlich besser und wesentlich näher am Business, als dass es in anderen Unternehmen funktioniert. Ob die IT jetzt als Costcenter, Servicecenter, Profitcenter aufgestellt ist, ist erstmal an der Stelle auch irgendwie, ja, egal. Die Frage ist eher, wie gestalte ich als IT meine Kundenschnittstelle? Und für mich gibt es ein zentralen Punkt. Und dieser eine zentrale Punkt, das ist der Service an sich. Ein Service, meine momentane Lieblingsdefinition dafür ist die Erfüllung eines definierten Kundenwunsches bzw. Kundenbedürfnisses. Und wenn ich diese Services als IT-Abteilung anbiete, dann kann ich an so einen Service auch einen Preis ranschreiben. Ob ich diesen Service, äh, ob ich diesen Preis dann auch tatsächlich verrechne oder das nur für mich als internes Steuerkriterium ist, dass ich sehe, okay, der Service kostet mich… pro Nutzer drei Euro achtundfünfzig im Monat. Jetzt kann ich extern vergleichen, wo kriege ich ihn günstiger, wo kriege ich ihn besser und kann dann entsprechend informierte Sourcing-Entscheidungen treffen. Das ist, das an der Stelle erstmal auch wieder egal. Viel wichtiger ist, dass wir auch im innerbetrieblichen Verhältnis über diese Kosten, die entstehen, sprechen. Weil, was wir heute sehen, ist, dass viele Fachabteilungen nicht wirklich die Verantwortung für IT-Kosten übernehmen. Und in meiner Welt gibt es gar keine IT-Kosten, das sind alles Prozesskosten. Das heißt, wenn ich als IT sagen kann, das, was du dir hier gerade wünschst, das kostet diesen Betrag Geld. Ist es dir, ist dir dieses Geld für die Prozessunterstützung das wert? Und wenn die Frage mit ja beantwortet wird, ist alles gut. Wenn die Frage mit nein beantwortet wird, dann können wir dediziert darüber reden, was lassen wir weg? Werden’s vielleicht doch keine Platintürklinken, sondern eher silberne. Sieht ähnlich aus, kost‘ nicht, kost‘ wesentlich weniger. Sie haben gesagt, man setzt ein Preisschild an einzelne Angebote, die man als IT-Abteilung auch zur Verfügung stellt, Services, die man zur Verfügung stellt. Äh, ich glaube, den Begriff müssen wir gleich noch mal definieren. Aber ist dieses Preisschild, was ja wahrscheinlich auf Vollkostenbasis auch funktioniert, nicht sogar kontraproduktiv und treibt dann die Fachabteilungen in ihrer Einkaufs– in ihrer IT-Einkaufsentscheidung sogar in die Arme von externen Anbietern, die vielleicht nicht nur rein Vollkosten rechnen müssen? Das kommt jetzt ganz darauf an, was für Services ich anbiete. Wenn ich jetzt Services anbiete, die da lauten E-Mail oder virtuelle Maschine oder Internetzugang, was auch immer. Klar, das sind vergleichbare Produkte, das sind vergleichbare Services. Da darf ich als IT-Leiter selber gucken, wo ich die sinnvoll source. Hmm, den Vorteil, den wir als interne IT haben, das ist das Wissen um die Prozesse, das ist das Wissen um die Zusammenhänge. Und ein Service, nehmen wir mal, nehmen wir mal ERP. Ich würde wahrscheinlich nie einen Service anbieten, der einzig und allein irgendwie das ERP-System zur Verfügung stellt. Das wäre ähnlich, wie wenn Sie auf Lufthansa.com gehen und Ihnen wird dort die Nutzung eines Flugzeugs angeboten und alles andere, was da ringsherum ist, Sicherheitskontrolle, Gepäck, was auch immer, kümmern Sie sich selber. Ein ERP-System ist in der Landschaft des Unternehmens integriert. Es laufen Prozesse drin ab. Und nehmen wir beispielsweise mal so einen Bestellprozess. Bei so einem Bestellprozess gibt es ja unter Umständen eine Bonitätsprüfung, das heißt eine Schnittstelle zur Schufa, zu Bürgel oder zu wem auch immer. Das ist natürlich Teil des Service. Und dann heißt dieser Service vielleicht nicht mehr ERP-System, sondern dann heißt dieser Service vielleicht Angebotsmanagement und ist nur ein Teil des ERP-Systems, umfasst allerdings alles, was dazu gehört. Vielleicht dann auch einen externen Druckdienstleister, der die, der die Angebote rausschickt, wenn sie noch per Papier raus müssen. Er umfasst auch die Anbindung an das E-Mail für Angebote per E-Mail. Das heißt, die, den Mehrwert, den wir bieten können als interne IT, ist, den Bedarf der Geschäftsprozesse an IT-Unterstützung eins zu eins abzubilden. Und das schafft ein Externer nicht, weil der hat das Wissen nicht. Der kann wieder nur mit einem System um die Ecke kommen, was er zwar als Service verkauft. Der Service ist letztlich der Betrieb dahinter. Aber wenn ich mir jetzt einen Salesforce reinhole, muss ich das in meine Landschaft integrieren. Also biete ich doch lieber einen Service an, der die komplette Integration anbietet, ist nicht vergleichbar und stiftet tatsächlich Nutzen. ich glaube, das ist ganz wichtig zu verstehen. Service ist für Sie nicht alleine die Software, die angeboten wird, sondern die Leistungserbringung im Kontext des jeweiligen Prozesses. Definitiv. Jetzt haben Sie das Stichwort eigentlich selber gegeben, was ich mir hier auch aufgeschrieben habe. Das ist das Thema Schatten-IT. Also die Frage, wie hierarchisch ist das Unternehmen in Bezug auf seine IT-Leistungen, auf seine IT-Services eigentlich aufgestellt? dürfen die Fachabteilungen, die ja immer mosern, wir sind ja irgendwie als IT doch immer der Hygiene Faktor. Das heißt, wenn es sauber ist, meckert keiner lobt aber auch keiner. Nur, nur wenn irgendwas klemmt, dann muss man wieder mit dem Kettenhemd in die Kantine. Wie umgehe ich dieses Problem? Dass die Fachabteilungen sagen, das, was mir die IT anbietet, ist viel zu teuer. Ich kaufe jetzt ein Salesforce. Mhm. Hundertfach tausendfach passiert. Ich kaufe jetzt ein [unkenntlich]. Ich installiere mir ein paralleles E-Mail-System, weil das zentrale E-Mail-System ist einfach nicht geeignet. Und mit meinen fünf Mitarbeitern brauche ich mehr Flexibilität. Mhm. Die Frage, die, die sich dahinter verbirgt, könnte lauten: Warum wird dies getan? Was verspricht, und da sage ich jetzt bewusst, verspricht der Externe, was den Internen da so anfixt, dass er das Ganze kauft. Nehmen wir Salesforce. Wenn wir auf die Webseite von Salesforce schauen, dann spricht Salesforce immer noch relativ abstrakt, allerdings schon recht sinnvoll in der Sprache des Nutzers, also in der Sprache der Vertriebsabteilung, beispielsweise als CRM-System. Da werden Funktionen in entsprechende Prozessschritte verkleidet, da werden Funktionen in entsprechendes Sprech des Vertriebes, äh, verkleidet. Das heißt, dort fühlt sich der Mitarbeiter aus dem Vertrieb wesentlich besser aufgehoben als bei der IT, die halt sagt, woah, hier, wir haben da ein Microsoft CRM, damit kannste CRM machen. Das ist ein Punkt, der schief läuft. Der zweite Punkt, der ist auch historisch bedingt. Wir haben es erfolgreich geschafft, die Mitarbeiter im Unternehmen, die Kunden, die Nutzer darauf zu trainieren, mit uns in IT zu sprechen. So in der zweiten Woche in meinem Job als CIO kam der Leiter des Controllings um die Ecke und sagte, „Herr Sieber, Herr Sieber, wir brauchen eine neue Software fürs Controlling.“ Also das heißt, er hat mir schon gesagt, wie die Lösung für sein Problem ist. Mhm. Dabei haben wir noch gar nicht mal über sein Problem gesprochen. Hmm, der Vorteil, den ich immer habe, wenn ich neu bin, ich kann sagen, hmm, super, machen wir. Kein Problem. Ich würde gerne verstehen, wie Sie arbeiten. Hab mir dann zwei Leute und ihn aus dem Controlling genommen. Wir haben uns zwei Stunden hingesetzt. Ich habe mir die Prozesse erklären lassen. Wir haben sie ein bisschen am Flipchart dokumentiert. Wir haben drüber geredet, in welchen Systemen laufen die ab. Im Nachgang habe ich das Ganze dann in BPMN, im Tool dokumentiert. Und was kam raus? Wir hatten, glaube ich, so vier oder fünf Medienbrüche. Excel nach Navision, Navision nach Excel, Excel nach Navision. Haben wir gesagt, „Okay, wir können die Zahlen später schick machen. Jetzt müssen wir erst mal dafür sorgen, dass die Zahlen inhaltlich richtig sind. Wir beseitigen die Medienbrüche.“ Wir haben die Medienbrüche beseitigt. Allein das hat schon mal eine Einsparung von knapp sieben Mann Tagen im Controlling pro Monat gebracht. Danach haben wir mit einer BI Lösung die Zahlen schick gemacht, sodass sie entsprechend auch einfach analysiert und aufbereitet werden können. Hat noch mal zwei Manntage gespart. Und das war ein super Aufsatz im Unternehmen, weil die Leute haben begriffen, mit mir können sie in ihren Problemen reden und in ihren Anforderungen und müssen sich nicht schon eine Lösung raussuchen und der IT-Abteilung sagen, was da getan werden soll. Und das ist aus meiner Sicht der Schlüssel dazu, die Schatten-IT einzudämmen. Ganz werde ich sie nie beseitigen können und das ist auch nicht wirklich schlimm. Und ich m– darf mit den Menschen in ihrer Sprache, auf ihrer Ebene kommunizieren, weil dort finden ihre Probleme statt und nicht auf meiner Ebene. Mhm. Jetzt gibt es ja sicherlich auch zwei Arten, auf Services zu gucken. Das eine, das haben Sie jetzt mit dem Beispiel, glaube ich, sehr schön dargestellt, ist quasi das kreative Gestalten unter Berücksichtigung dessen, was die Fachabteilungen auch wollen. Aber es gibt natürlich auch die ganz normalen, äh, Serviceabläufe, Serviceerbringungen in der IT-Abteilung, wo natürlich auch immer wieder die Locke links oder die Locke rechts aus den Fachabteilungen gewünscht wird. Äh, inwieweit kann ich da auf die Wünsche der Fachabteilungen reagieren oder sollte ich Services nicht auch bis zu einem gewissen Grad standardisieren? Arbeit mit Services bedeutet Standardisierung. Mmm, meiner Meinung nach die Ursache dafür, dass es Locke links und Locke rechts gibt, ist, dass am Anfang nicht wirklich ein Anforderungsmanagement stattgefunden hat. Also das Gespräch mit den verschiedenen Kundengruppen im Unternehmen. Was braucht ihr wirklich? Dann fehlt in der Regel eine klare Beschreibung der Dienstleistung. Also ich sage dazu immer Servicebeschreibung und das ist ganz klar Erwartungshaltungs-Management. Also welche Erwartungshaltung lasse ich zu und was schließe ich tatsächlich komplett aus? Also auch eine negative Abgrenzung ist an der Stelle immer hilfreich. Denn das machen die externen Serviceanbieter auch nicht anders. Sie kriegen bei einer Microsoft keine Locke links bei E-Mail und sie kriegen bei Salesforce auch keine Locke rechts im CRM. Sie bekommen das, was beschrieben ist und damit sind die Menschen zufrieden, weil es entspricht dem, was– also das, was sie bekommen, entspricht dem, was ihnen versprochen wurde.Das heißt wir dürfen unsere Services egal auf welcher Ebene die stattfinden, dürfen wir in Kundensprache so beschreiben, dass der Gegenüber eine konkrete Vorstellung hat, was er damit machen kann und dann wird es locke links und locke rechts wesentlich weniger geben. Jetzt gibt es so Frameworks, ähm ich weiß, Sie sind da durchaus auch an der einen oder anderen Stelle kritisch. das was, wenn ich über Services rede, natürlich den IT-Abteilungen als erstes in den Sinn kommt ist ITIL, also ITIL. Vielleicht können wir da ein bisschen drüber sprechen, welche Chancen auch in solchen Frameworks, äh, bestehen, um eine vernünftige IT Service Leistung auch erbringen zu können. Über das, was wir jetzt gerade alles besprochen haben, das war so eine wundervolle Outside in Betrachtung. Das heißt, ich habe einen Blick von außen auf die IT. Das ist wichtig, dass dieser primär ist. Der Blick über Prozesse, Frameworks ist dann die Inside out Betrachtung und das ist der Teil Management im Wort Servicemanagement. Und der ist leider Gottes in den letzten vielen Jahren viel zu überbetont worden. Weil was ist ITIL? ITIL oder auch Fit SM egal, ist eine Sammlung von Ideen, worüber man nachdenken darf, wenn man IT-Services erbringt. Das ist nichts, was man dogmatisch irgendwie machen muss. Das heißt, dass das ITIL kennt, nageln Sie mich nicht fest. Ich glaube, es sind so dreiundzwanzig Prozesse mit jeder Menge Rollen. Und jetzt bin ich eine IT mit vielleicht zehn Leuten. Kann ich alles gar nicht abbilden, brauche ich alles gar nicht. Ich kann mir. Ich kann mir das Zeug anschauen und kann gucken, was davon ist für mich tatsächlich sinnvoll. Woah, ein Servicedesk? Sicher. Haken dran. Ein Incident Management? Also wie gehe ich im Fehlerfall mit den Anfragen um, wie komme ich wieder zum normalen Betriebszustand? Haken dran. Brauchen wir. Veränderungsmanagement, Changemanagement brauchen wir. Ah, dann gehen wir mal ein Stück weiter, gucken so, naja, Capacity Availability Management ist wichtig, brauchen wir aber wahrscheinlich nicht als einzelnen Prozess in so einer Organisation. Und so schaue ich mir die einzelnen Punkte an und überlege, wie kann ich diese Punkte in meiner konkreten Situation in meiner Organisation abbilden. Nehmen wir mal so ein ganz beliebtes Beispiel Ein Großteil der Unternehmen, die wir draußen haben, reden davon, dass sie von diesen dreiundzwanzig Prozessen Incident, Problem und Change umgesetzt haben. Incident glaube ich allen, Change glaube ich den meisten, Problem Management glaube ich den wenigsten, weil das ist eigentlich einer der wichtigsten Prozesse, also wirklich zu schauen, was ist die Ursache für eine gewisse Anzahl von Störungen, was ist die Ursache für einen großen Ausfall und dann nachhaltig dies zu beheben und das auch wirklich aktiv und proaktiv zu betreiben. Damit würden wir viele Störungen vermeiden. Öhm, das haben wir ganz, ganz wenig, obwohl das einer der wichtigsten Prozesse in diesem Umfeld eigentlich ist. Wenn wir vom reinen Betrieb kommen. Ich greife da nochmal ein. Also ich mache mal ein Beispiel. in meiner Fachabteilung tut der WLAN WLAN-Druckert mehr. Funktioniert einfach nicht. Jetzt rufe ich an in der IT-Abteilung. Sie haben eben gesagt, das ist eine IT-Abteilung mit zehn Mitarbeitern. Ich werde also durchgestellt zu dem Mitarbeiter, der für den Drucker zuständig ist. Also typische klassische IT-Abteilung. Da gibt es einen Experten für die Drucker und der schlurft dann nachmittags mal in mein Büro, schaut sich den Drucker an, sagt alles in Ordnung mit dem Drucker, Toner tut noch und, äh, alles andere ist auch in Ordnung. Ist nicht mein Problem. Punkt. So, der Fachmitarbeiter, also ich in dem Fall ist genauso schlau wie vorher, ruft also nochmal an und sagt Ich habe immer noch ein Problem mit meinem WLAN-Drucker. Ich kann nichts drucken. So, und dann landet das in der Abteilung für WLAN oder Flan oder was auch immer. Und auch die stellen keinen Fehler fest und sagen ist nicht mein Problem. Und dann landet das in der Abteilung für, äh, das Betriebssystem. Ist auch kein Problem. Und so weiter und so fort. Wie hilft mir jetzt das Nachdenken über IT Service Management eigentlich diese funktionale Aufteilung, ich glaube, das hat das Beispiel jetzt klar gemacht, (übersprechen 00:03:42) zu beheben und ein Verständnis auch in der IT-Abteilung zu etablieren, dass es eben nicht darum geht, meinen Bereich ganz besonders toll zu machen, also das WLAN bis zum letzten zu optimieren, sondern eigentlich das Gesamtproblem zu betrachten und eine integrierte, eine Gesamtlösung, äh, anzustreben. Jetzt gehen aus meiner Sicht in dem Beispiel zwei Dinge schief. Das Erste, was schief geht es gibt niemanden, der sich für Ihre Störung verantwortlich fühlt. Das ist so das sogenannte Hot Potato Routing. Irgendwo angerufen. Der nimmt das auf, kann jetzt ad hoc erstmal nicht helfen, was nicht schlimm ist, was völlig in Ordnung ist, und routet es dann an eine Bearbeitergruppe weiter, die aus seiner Sicht dafür am besten geeignet ist. Bis dahin soweit alles völlig in Ordnung. Hmm, was jetzt aber passiert ist in den meisten Organisationen. Jetzt gibt der Supporter, also der First Level, gibt die Verantwortung für diesen Vorgang, für diesen Incident ab. Da gibt es eine wunderbare Disziplin. Ich glaube, sie kommt aus der Notfallmedizin, nennt sich Case Management. Die kennen dort den Case Owner.Und genau so etwas würde ich in der IT etablieren, dass ich sage, es gibt für jeden Vorgang einen Case Owner und der sorgt, der hat dafür Sorge zu tragen, dass der Incident gelöst wird. Das heißt nicht, Sie rufen wieder beim Helpdesk an, dass es noch nicht ist, sondern der Kollege von Druckern meldet zurück, hm, ich konnte nichts finden, beziehungsweise leitet es vielleicht gleich selbst weiter, aber im schlimmsten Fall meldet er das zurück, sagt kann nichts finden und der Caseowner kümmert sich darum, dass es weitergeht. Das ist das eine, das andere, da kommt wieder der Service ins Spiel. Der Service ist als Ende-zu-Ende-Verantwortung zu verstehen. Also wenn ich jetzt diesen Service, mit dem ich mich jetzt gerade ein bisschen schwertue, (kichern) da er doch sehr Hardware lastig ist. Wenn ich jetzt so sage, ich habe einen Service drucken, dann gibt es jemanden, der sogenannte Serviceowner, der für diesen, äh, Service verantwortlich ist und das ist nicht zwangsweise der, der diesen Service auch betreibt, sondern es ist tatsächlich die Verantwortung für die SLA gerechte Lieferung dieses Service, für die Weiterentwicklung, für die Aktualisierung im Servicekatalog und alles, was damit zu tun hat. Und wenn ich jetzt als Serviceowner sehe, weil das gehört zu meinen Aufgaben, dass es da Incidents gibt oder einen Incident gibt, der da in der Organisation rumwabert, dann kümmere ich mich darum. Dann nehme ich meine Ende-zu-Ende-Verantwortung wahr und bilde jetzt vielleicht ein kleines Problem Management Team, wenn wir das so behandeln wollen. Oder ich sage einfach, ich nehme die Leute, die da ihre Beiträge zuliefern, nehme ich zusammen und wir gucken uns das Problem, die Störung genau gemeinsam an. Und lösen Sie hoffentlich. Ich nehme das Wort, äh, das Stichwort Ende zu Ende jetzt einfach mal als Stichwort mit Blick auf die Zeit und, äh, würde das Interview gerne an dieser Stelle für diese Woche beenden, weil ich meinen Zuhörern versprochen habe, immer so in der magischen dreißig-Minuten-Phase zu bleiben. Ich möchte Sie aber einladen, mit mir in der nächsten Woche über das Thema gerne weiterzusprechen. Ich glaube, äh, ITIL, ITIL, andere Formate oder sagen wir mal zumindest die Grundvoraussetzung dahinter sind wichtig zu verstehen, um eine moderne IT auch aufzusetzen. Und darüber sollten wir noch ein bisschen reden. Sehr gern. 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.