Kaizen 2 go 095 : IT-Dokumentation - GeeMco : Götz Müller Consulting

Inhalt der Episode

Was ist ein CMDB-Evangelist? Was ist eine CMDB?
Welche Dokumentationsbedürfnisse hat die IT grundsätzlich?
Was soll damit erreicht werden?
Welchen Herausforderungen begegnet man dabei?
OBASHI in der praktischen (Dokumentations-)Anwendung für eine IT-Abteilung
Brauche ich als kleineres Unternehmen (50-100 MA) wirklich eine IT-Abteilung, um meine Geschäftsprozesse zu dokumentieren?
Wie gehe ich vor? OBASHI ist eine Methodik, was ist ein geeignetes Werkzeug dafür?

Notizen zur Episode

Mitmachen?

Wenn Sie selbst ein interessantes Thema für eine Episode im Umfeld von Geschäftsprozessen haben, können Sie mir das auf dieser Seite mit Vorbereitungsfragen vorschlagen.

Ich freue mich darauf!

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode bitte bei iTunes.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Episode 95 – IT-Dokumentation

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Heute habe ich Peter Resch-Edermayr bei mir im Podcastgespräch. Peter Resch-Edermayr nennt sich CMDB-Evangelist und das ist dann sicher auch ein guter Einstieg für die Zuhörer. Erstmal hallo, Herr Resch-Edermayr.

Peter Resch-Edermayr: Hallo Herr Müller, Grüß Gott.

Götz Müller: Und was ist denn ein CMDB-Evangelist?

PRE: Ja, klingt kompliziert. Das ist es gar nicht so. Ein Evangelist hat in erster Linie mal die Aufgabe aufzuklären. Die Kunden, aber auch uns selbst. Wir erarbeiten Grundlagen rund um das Thema Configuration Management und um das ganze Thema IT-Dokumentation. ich bin im Prinzip dran mit Kunden das Thema immer wieder neu zu analysieren und ja, diese Best Practices, wie man das so schön sagt, auch aufzubereiten und daraus Geschichten zu erzählen, quasi die Lagerfeuerromantik aufkommenzulassen.

Götz Müller: Gut, jetzt ist vielleicht nicht jeder von den Zuhörern so direkt drin in dem Thema IT und so weiter. Der ein oder andere wird sich vielleicht fragen: CMDB – Kann man das essen? Sagen Sie vielleicht auch da noch ein, zwei Sätze dazu.

Peter Resch-Edermayr: Ja, CMDB, das kommt aus der IT Infrastructure Library (ITIL). Das gibt es seit dreißig Jahren, kommt aus dem englischsprachigen Raum, ist im Prinzip eine Best Practice Sammlung, wie man IT-Management, IT-Service-Management, wie es so schön heißt, wie man das organisiert. Einer der Kernpunkte der ITL, also dieser Sammlung an Best Practices und Büchern, ist eben die Wortschöpfung CMDB Configuration Management Database. Die Idee dahinter ist die, dass alle Prozesse, die in der ITL laufen in irgendeiner Weise Daten benötigen oder Daten liefern und da gibt es dann in der Mitte eine Art Daten-Drehscheibe, natürlich sehr gerne in Datenbanken organisiert, die wurden eben mal Configuration Management Database genannt. Auch das unterliegt einer gewissen Mode, mittlerweile heißt es in der ITIL-V3 Configuration Management System. But however, gemeint ist eben diese Daten-Drehscheibe in der Mitte in der IT-Organisation und früher oder später kommt ja jede IT-Organisation darauf, dass man so etwas braucht und nicht einzelne Excel-Dateien, die verstreut herumliegen, sondern dass man hier eine gemeinsame Datenbank-Anwendung benötigt.

Götz Müller: Da kommen wir sicher noch mal drauf. Ich habe mir sagen lassen, sowas soll es trotzdem geben. Aber das wird sicher noch mal ein extra Thema. Jetzt haben wir ja ein bisschen so die Überschrift IT-Dokumentation und da zum Einstieg mal die Frage: Was sind denn die Dokumentationsbedürfnisse in der IT grundsätzlich?

Peter Resch-Edermayr: Ja, da ist eine spezielle Sache, auch eine gute Frage, denn die IT per se dokumentiert natürlich nicht. Dokumentation ist so ungefähr das unangenehmste und langweiligste und man lernt das auch nicht, wenn man klassisch eine IT-Ausbildung bekommt. Allerdings kommt man dann sehr schnell darauf, dass man das auch benötigt. Man braucht ständig irgendwie eine Dokumentation, sei es um Fehler zu suchen, sei es um Dinge neu zu bestellen oder einem Anwender Unterstützung anzubieten und es gibt auch gesetzliche Vorgaben, die immer strenger werden. Branchenvorgaben oder jetzt neuerdings das Thema Datenschutz, das jetzt auf EU-weiter Ebene geregelt wird und Mitte Mai nächsten Jahres dann schlagartig aktiv wird. Das heißt plötzlich sind alle aufgefordert, zu dokumentieren und wir wissen aber nicht so recht, wie wir das tun sollen. Und da gibt es natürlich zuallererst mal im Prinzip die Idee das ganze mit einzelnen Dateien zu dokumentieren und dem besprochenen Excel, das sehr geduldig ist und nach und nach kommt man darauf, dass das Ganze ja miteinander zu tun hat und alles in Relation zueinander steht und da wird es dann spannend, weil diese Dokumentationsfälle dann weit über den eigentlichen Dokumentationszweck hinausgehen und hier eröffnen sich dann ganz neue Möglichkeiten, die ich aufgrund der Daten und Informationen in der Dokumentation drinhabe.

Götz Müller: Jetzt haben Sie es schon ein bisschen angedeutet, das werden wir vielleicht nachher noch vertiefen. Ich möchte jetzt noch auf einen Punkt noch ein bisschen zurückkommen zum Einstieg. Einmal: Dokumentation macht, glaube ich, nicht nur in der IT keiner gern. Das ist, glaube ich, ein grundsätzliches verbreitetes Phänomen. Deshalb aber die Frage hier: Was soll denn mit der Dokumentation eigentlich erreicht werden, weil ja in meinem persönlichen Weltbild ja Dokumentation an sich, für einen Kunden noch keine echte Wertschöpfung hat.

Peter Resch-Edermayr: Ja. Sollte man meinen. Jedoch ist es halt so innerhalb der IT, dass es in erster Linie einmal eine Prüfmöglichkeit geben muss, die IT sich sozusagen selbst überprüfen können soll. Dazu bräuchte ich beispielsweise eine Soll-Dokumentation, die ich mit einem Ist vergleichen kann. Das ist oft schon mal gar nicht der Fall, dass es etwas wie ein Soll dokumentiert ist, sondern wir gerne dazu übergehen einfach vom Ist, wie etwas ist, wie etwas läuft, wie etwas funktioniert, jetzt gerade, anzunehmen, dass das auch so sein soll. Mitnichten.

Dann gibt es natürlich das nächste: Um Steigerungs- und Optimierungspotential zu erkennen, brauche ich auch die Dokumentation, um mir mal einen Überblick zu verschaffen. Da brauche ich auch verdichtete Informationen. Thema Reporting oder andere Darstellungen oder das Extrapolieren von gewissen Zuständen, die ich identifiziert habe. Da geht es also schon um mehr Daten, die aufbereitet werden und verdichtet werden zu Informationen, die dann oft zu Entscheidungen führen. Beispielsweise, wenn wir an das Architekturmanagement denken, wenn wir die Möglichkeit haben wollen, die Anzahl der Anwendungen oder Betriebssysteme zu optimieren etc., bis hin zu Outsourcing-Szenarien – Was kann ich denn tatsächlich abgeben, in externe Betreuung übergeben? – Dazu brauche ich erst einmal eine fundierte Dokumentation der IT für sich selbst.

Und dann last not least, wir sprechen jetzt alle über Automatisierung und automatisieren kann man natürlich einen Standardprozess am besten und der Standardprozess bezieht sich natürlich auch auf Daten und Informationen, die stimmen, die korrekt sind und die ich dann als Input-Information benötige, um etwas weiter ausführen zu können. Auch hier tut sich die IT relativ leicht, da kann man schnell mal ein Skript erstellen, da kann man schnell mal den Rechenzentrumsbetrieb, nicht komplett automatisieren, aber mit kleinen, vielen einzelnen Automatisierungs-Tools ausstatten und dann schon ganz viel optimiert und eingespart. Also auch dafür wird IT-Dokumentation in dem Sinn benötigt.

Götz Müller: Jetzt höre ich da so ein bisschen raus Automatisieren, das sind vermutlich dann wieder die Sachen die „Spaß machen“, weil man sich ja nicht darum kümmern muss. Ich könnte mir aber vorstellen, ich habe es zumindest rausgehört, so ganz trivial scheint es nicht zu sein. Deshalb ein bisschen die Frage danach: Was gibt es da jetzt für Herausforderungen?

Peter Resch-Edermayr: Die Standardfrage, die ich immer bekomme ist: Wie beginnen? Und da neigt man natürlich dazu: Hurra, ich habe ein Tool, das fülle ich mal an mit Daten. Alles, was ich bekommen kann, rein mal in das Tool und das ist jetzt wunderbar. Ich kann zeigen, was ich nicht alles Tolles zu leisten im Stande bin, was ich nicht verwalten kann. Dahinter steckt der Gedanke, alles zu dokumentieren und am besten jetzt und gleich. Das ist natürlich ein wenig zu hoch gegriffen und spätestens beim zweiten oder dritten Anlauf mit dieser Vorgehensweise kommt man darauf, dass das der falsche Weg ist. Und dann geht es in erster Linie mal darum, sich im Team zusammenzusetzen, das muss jetzt nicht nur die IT in sich sein, sondern oft auch mit anderen Fachbereichen etc., die eben gerade eine Anforderung am Tisch haben, die zu lösen ist, gemeinsam mit der IT. Und da beschäftigt man sich konkret mit einem Anwendungsfall, für den man eine gute Dokumentation braucht. Und den exerziert man dann am besten durch und die Herausforderung ist dann eben, dass die Pferde nicht zu schnell zu galoppieren beginnen, dass man sich also nach und nach an die nächsten Anwendungsfälle, die man erreichen kann, mit einer guten Dokumentation, die ich schon angeführt habe, dass man das quasi ein bisschen zügelt und hier versucht nach und nach diese Prozesse, die sich ja alle verändert haben in der IT-Organisation setzen zu lassen und das auch zu stabilisieren. Dann habe ich, wie ich gerne sage, eine akurate Dokumentation, also etwas das tatsächlich stimmt und genau dem entspricht, für das ich es mir gedacht habe.

Götz Müller: Jetzt bin ich ja auf Sie gestoßen über das Thema OBASHI, da hatte ich mit dem Robert Sieber vor einiger Zeit auch eine Episode, da haben wir das im Grunde nur zum Schluss angerissen, ich fand das aber, wo ich das bei Ihnen kennengelernt habe, sehr spannend, und bin ja dann. wie ich es schon gesagt habe, da auf Sie gestoßen. Und das würde ich gern noch ein bisschen vertiefen, auch unter dem Dokumentationsaspekt, weil es dann für mich selber wieder sehr wertvoll war, als ich das bei einem Kunden eingesetzt habe und dadurch für mich, und ich glaube auch anderen, eine, ich fand schon ziemlich erstaunliche, Klarheit entstanden ist.

Peter Resch-Edermayr: Also, OBASHI, ich war ja überrascht, dass es das überhaupt gibt. Da muss man dem Robert Sieber ein großes Danke sagen, dass er das in den deutschsprachigen Markt auch übersetzt hat und sich da wirklich darum kümmert, dass die Community immer größer wird und dass Wissen aufgebaut wird. Was hat mir an OBASHI, als ich das gefunden habe, so gefallen? Ich habe in früherer Zeit auch sehr viel in Outsourcing-Situationen gearbeitet und wir hatten die Aufgabe, beispielsweise, zweihundert Applikationen, die so laufen in einem Rechenzentrum zu dokumentieren, herauszufinden, wie hängt denn das alles zusammen. Dazu mussten wir quasi überhaupt erst einmal eine Methode schaffen und das hat natürlich ziemlich lange gedauert, bis diese Methode optimiert war, bis wir sie dann wirklich effektiv anwenden konnten. Da kannten wir OBASHI noch nicht. Und dann stieß ich eben auf OBASHI und kam darauf: Aha, da geht das ja vom Geschäftsprozess bis runter, wie der ITler so schön sagt, aufs Blech, wieder hoch übers Betriebssystem, in die Applikation bis in die Service-Ebene. Da gibt es ja was, eine Standard-Methode. Das hat mir sehr gut gefallen, auch dass es da die Möglichkeit gibt, das mit einem freien e-Mail-Kurs vom Robert Sieber zu belegen und sich diese Methode in relativ kurzer Zeit anzueignen und dass es dann mittlerweile eine Community gibt, die sich da intensiv mit auseinandersetzt. Das sind alles gute Vorbedingungen, damit das eben breitenwirksam angewendet werden kann. Ich will jetzt nicht sagen, ob es die beste Methode ist oder ob es da nicht noch andere gibt. Es gibt sie, sie ist verfügbar und man kann sie anwenden. Und mittlerweile, habe ich gehört, sollen es ja auch im universitären Sektor mehrere Projekte geben, die sich das quasi auf wissenschaftlicher Ebene ansehen und damit arbeiten, also ich glaube, das wird sich durchsetzen.

Götz Müller: Jetzt will ich das noch ein bisschen vertiefen. Ich meine, IT ist ja im Grunde eine Dienstleistung für das Unternehmen im Unternehmen. Da kommt dann schnell so ein Stichwort ins Spiel wie Service-Katalog und das vorhin schon genannte mit der CMDB. Wie sehen Sie die Zusammenhänge? OBASHI und die anderen zwei Themen?

Peter Resch-Edermayr: Natürlich kann ich auf dem Weg der Analyse, und ich werde nicht sofort mit dem Ziel, einen Service-Katalog aufzubauen, die Ziele sind zumeist herauszufinden, Spezialitäten oder Konfigurationen einer Applikation, die entweder besonders kritisch oder instabil ist oder outgesourct werden soll oder wie auch immer. Es wird sich etwas ändern und man muss herausfinden, wie es derzeit ist und wie mit dieser Applikation gearbeitet wird. Und dann kommt man eben schnell darauf, dass die Komplexität, die da schlummert, absolut undokumentiert ist und nicht mal in den Köpfen klar ist. ALs Nebeneffekt, wenn ich mich damit beschäftige, stolpere ich natürlich, wenn ich den Gedanken IT-Service-Management ernst nehme, über IT-Services, die dann plötzlich als Abfallprodukt, wenn man so sagen will, aufgezeichnet werden. Und man sollte nicht glauben, in einem Rechenzentrum gibt es nur so an die hundert Infrastruktur-Services, die quasi jede IT betreibt und an Applikationen laufen auch üblicherweise 100-200 in jedem Unternehmen. Also es gibt hier eine Menge an Services, die man zumindest mal notieren kann. Ob man sie dann einzeln vertieft und im Detail ausführt, ist dann die Frage, welche Analyse mein Vorhaben ergeben hat, in welche Richtung ich meine Dokumentation treiben will. Aber alleine die Tatsache, dass es diese alle IT-Services gibt und ich die mal auflisten kann, das ist schon mal der Beginn meines Service-Katalogs. Das ist ein wunderbarer Effekt, um demonstrativ darstellen zu können, was die IT überhaupt leistet.

Götz Müller: Jetzt könnte ich mir vorstellen, dass es vielleicht der ein oder andere Zuhörer, ich weiß es auch schlichtweg, in einem kleinen Unternehmen unterwegs ist. Klein an der Stelle einfach mal mit 50-100 Mitarbeitern, der sich jetzt fragt: Brauche ich eine IT-Abteilung, um meine Geschäftsprozesse zu dokumentieren? Brauche ich das, von dem ich da gerade was höre?

Peter Resch-Edermayr: Ich möchte die Frage gerne in zwei Teile zerlegen. Der erste Teil ist: Was wird dokumentiert? Und der zweite wäre dann: Wer dokumentiert?
Bei Was? ist die Frage: Muss ich meine Prozesse, im Sinne der Kerngeschäftsprozesse, muss ich die überhaupt dokumentieren? Das ist natürlich von Branche zu Branche, von Unternehmen zu Unternehmen, unterschiedlich. Viele wollen oder müssen. Automobilzulieferer, da wird die Kette Ende zu Ende mit Dokumentation geschlossen. Medizin, Healthcase ditto. Es gibt also viele Branchen, die Dokumentation vom Geschäftsprozess bis runter in die IT einfach erfordern.
Dann kommen so ISO 27000-, ISO 9001-Anforderungen, die allesamt mit einer guten Dokumentation der Geschäftsprozesse zu tun haben. Es ist ja nicht mehr so, vor dreißig Jahren, wie ich in der IT begonnen habe: Na gut, wenn es nicht funktioniert, gehen wir in den Keller und holen die Schreibmaschine hoch. So ist es ja heute nicht mehr. Es gibt ja keinen Geschäftsprozess mehr, der per se ohne IT funktionieren würde. Also müssen wir diese Kette von Geschäftsprozess bis runter IT-Prozess in irgendeiner Weise schließen und das bedeutet aber auch, gemeinsam zu dokumentieren.

So, und die zweite Frage, also irgendwann ist es so weit und ich muss entweder zum Erreichen eines Zertifikates oder aus anderen Anforderungen meine Geschäftsprozesse dokumentieren und sei es nur, um sie zu optimieren und dann ist die Frage, wer dokumentiert sie? Und Sie haben mich gefragt: Brauche ich eine IT-Abteilung, um meine Geschäftsprozesse zu dokumentieren? Das kann die IT-Abteilung oftmals gar nicht leisten. Sie hat nämlich viele Informationen über die Geschäftsprozesse gar nicht vorliegen. Sie ist eigentlich nur die technische Ausprägung. Es muss also eine Zusammenarbeit zwischen den Fachbereichen und den IT-Erbringern geben. Und da passieren dann, während dieser (üblicherweise) Workshops, die man hier gemeinsam macht, große Aha-Effekte und auch kleine Sensationen und bereits während des Dokumentierens, Analysierens stellt man ja fest: Ui, das könnten wir besser machen. Oder Ui, da haben wir eigentliche in Risiko drin. Und da passieren nebenbei so listenweise Optimierungsmöglichkeiten, alleine dadurch, dass man sich mal zusammengesetzt und darüber geredet hat, wie der Prozess läuft und welche IT darunter ist. Dann kommt last, not least noch so Themen dazu, dass es halt Schatten-IT etc. oder Web-Services oder Cloud-Services gibt, die halt so schnell mal dazwischen reingefügt wurden und schon allein aus Datenschutzgründen unerwünscht sind und das muss man dann auch schnell a) dokumentieren und b) Abhilfe schaffen und in einen sicheren Hafen bringen.

Götz Müller: Ja, da erlebe ich auch immer wieder bei Kunden spannende Themen, gerade auch so dieser Aspekt Schatten-IT, Schatten-Prozesse, die beliebten Excel-Sheets. Da auch wieder, wie Sie es gesagt haben, man sitzt am Tisch und der eine erzählt plötzlich: Ja, da haben wir halt so ein Excel-Sheet und durchaus passiert es, dass die IT da ganz aus allen Wolken fällt.

Peter Resch-Edermayr: Damit wir im Home-Office auch gut arbeiten können mit dem CRM, exportieren wir sie ins Excel und legen die gesamten Kundendaten auf Dropbox ab und dann, ja genau.

Götz Müller: Das ist schon sehr spannend. Aber vielleicht an der Stelle noch so ein paar Aspekte, einen haben Sie genannt, Datenschutz und Datenschutzgrundverordnung. Wenn wir jetzt mal so das Thema Steuer auf der anderen Seite. Dieses Schlagwort GoBD. Was im Grunde ja auch einen hohen Dokumentationsanteil, ich will jetzt nicht sagen Aufwand, aber einen Anteil, wo ich dem Finanzamt gegenüber sagen muss: Hey, was passiert mit den Rechnungen, die einerseits Papier, andererseits elektronisch und dann ist es noch in einer e-Mail und wird nur runtergeladen. Ich glaube, auch das sind ja Dinge, die ich da miterfasse, oder?

Peter Resch-Edermayr: Also Rechnungen per se stehen jetzt nicht in der CMDB. Wenn aus der IT etwas verrechnet wird …

Götz Müller: Aber der Umgang damit, oder?

Peter Resch-Edermayr: Der Umgang, ja. Also wie eine Rechnung entsteht. Also der Prozess des Erstellens einer Rechnung, das ist sehr wohl ein Prozess, der natürlich auf IT fußt. Und darüber müssen wir uns klar sein: Wenn die Rechnungen nicht rausgehen, wird auch kein Geld überwiesen. Das ist also durchaus ein Kernprozess vieler Unternehmen und da ist natürlich auch schnell mal die rote Linie um diesen Prozess herum gezogen. Also hoher Augenmerk darauf, dass diese Prozesse in hoher Verfügbarkeit und Sicherheit funktionieren. Und da dürfen auch keine Daten in irgendeiner Weise verfälscht werden. Also hier habe ich hohe Aufmerksamkeit, auch von der Geschäftsführung, Buchhaltung etc. der Fachbereiche. Und dort wird auch gerne begonnen bei solchen Prozessen, ja mit dieser OBASHI-Methode, um herauszufinden, wo denn hier jetzt die Risiken drinliegen oder wo wir uns noch besser absichern können. Also da gibt es ja auch, wie beginnt man oder wie kommt es dazu, dass man dokumentiert. Da gibt es ja auch zwei Ansätze. Der eine Ansatz ist eben, dort zu beginnen, wo es wirklich teuer wird. Wenn beispielsweise ein Ausfall passiert oder wenn Daten wegkommen oder verändert werden, also wo das größte Risiko ist. Und andere Ansätze gibt es eben, diese ganze Masse mit der die IT-Abteilung zu tun hat, einmal zu erschlagen und sich diese Daten anzusehen und hier eine gemeinsame Basis zu haben, um die Breite sozusagen, Client-Management sage ich nur, irgendwo dokumentiert zu haben.

Götz Müller: Jetzt möchte ich den Punkt noch ein bisschen vertiefen, im Sinne auch: Wie gehe ich vor? Für mich ist OBASHI jetzt auch eine Methode und parallel dazu oder sehr eng verknüpft ist ja der Begriff Werkzeug. Was ist da so die Vorgehensweise, die zum Teil auch, so ein kleiner Werbeblock an der Stelle ist völlig in Ordnung, die Sie da auch anbieten.

Peter Resch-Edermayr: Also die OBASHI-Methode selbst, die Analyse der Geschäftsprozesse und Dokumentation passiert und das empfehlen wir auch weiterhin, erst einmal auf einer Art Papier, das kann auch digitales Papier sein. Das muss jetzt nicht handschriftlich auf Papier stattfinden. Aber hier geht es darum, auch die gesamten Informationen, die während eines Workshops, während gemeinsamer Gespräche, mal diese ganzen Informationen zu sammeln und hier mal in ein gemeinsames Bild zu bringen. Das strukturiere ich dann mit der OBASHI-Methode im Aufbau und das ist ja dann etwas, das soll weiterleben und das muss auch in ein Werkzeug hinein. Und wir die Firma synetics sind eben auch ein Werkzeughersteller. Unsere Software heißt i-doit, das kommt von „I document IT“ und i-doit ist eine Dokumentationssoftware, die sich nach und nach im Sinne von ITIL zu einer CMDB entwickelt hat. Wir können also auch diese Relationen der einzelnen gefundenen Objekte in der Konfiguration und der Relation zueinander darstellen und in Beziehung bringen und natürlich kann man darin in der Software, die ist beliebig erweiterbar und das ganze zu sehr geringen Kosten, kann man eben auch Prozesse mit hineinnehmen oder das ganze Thema DSGVO, die Notwendigkeit hier zu dokumentieren, das machen bereits viele Kunden. Es gibt viele Partner, die sich auf das Thema spezialisiert haben, auch eine Dienstleistung, um hier die Kunden zu unterstützen, die jetzt ein wenig in Zeitnot geraten sind. Das heißt, hier gibt es die Möglichkeit, das, was wir ausliefern noch zu erweitern und im Prinzip zu dokumentieren, vom Stuhl und Tisch bis zum Geschäftsprozess. Wir kommen aus der IT, liefern da schon nahezu hundert Objekttypen, wie wir das nennen, mit und die Kunden finden dann immer noch den hundertersten Anwendungsfall, den sie da selbst hineintun.

Götz Müller: Jetzt zum Abschluss möchte ich noch mal ein Stichwort aufgreifen, dass Sie schon ein-zweimal genannt haben. Zum Schluss eben der Aspekt Prozesse und das ist dann immer das, wo ich sehr aufmerksam werde. Wenn es eben auch um die Verbesserung geht. Wie können dann da Methoden und Werkzeuge ihrer Ansicht nach helfen? Ich komme wieder ein bisschen auf meine Eingangs- sagen wir mal Anmerkung, zurück, dass so eine Dokumentation an sich ja noch keinen Wert schöpft. Aber dadurch, dass ich verbessere, kann ich eventuell oder mit ziemlicher Sicherheit, dann auch meine Wertschöpfung verbessern.

Peter Resch-Edermayr: Also die Optimierung stelle ich fest aus den vielen Projekten, die ich begleitet habe, die Optimierung passiert über große und weite Strecken schon während des Analysierens. Da passiert in den Köpfen schon dieser Klick, wo man sagt: Hey, das machen wir eigentlich die ganze Zeit, das ist ja viel zu kompliziert. Das können wir bereits verbessern. Und dann ist die nächste Frage: Mache ich den Aufwand der Dokumentation eines Geschäftsprozesses, wir sind jetzt kein Geschäftsprozessdokumentationswerkzeug, aber wir können im Prinzip den Prozess per se abbilden und dort alle Anhänge dran, die man üblicherweise als Dokumentation so vorhält. Und wie viel Aufwand stecke ich in die Dokumentation für etwas, das noch nicht richtig gut läuft. Und dabei kommt man schnell darauf, dass man lieber den Soll-Zustand des Prozesses, wie er in naher Zukunft passiert, dokumentiert. Gilt auch für die Infrastruktur darunter. Plötzlich habe ich einen Soll-Zustand dokumentiert, den ich nach und nach mit Projekten oder einzelnen, kleinen Vorhaben meistens in der IT, quasi unterstütze. Das heißt, meine Erfahrung ist die, dass ich beim Dokumentieren oder beim Analysieren des Prozesses, an und für sich und noch vor der Dokumentation, das hier schon eine Optimierung stattfindet und dann gibt es natürlich die größeren Vorhaben. Beispielsweise wenn es darum geht komplette Plattformen zu ändern, Applikationen auszutauschen oder zu konsolidieren. Das bedarf dann natürlich eines größeren Umbaus in jeder Organisation und das kommt dann natürlich in die Projektliste hinein. Auch hier wieder ab dem Zeitpunkt des gemeinsamen Analysierens, wo IT-Wissende und Wissende aus dem Fachbereich zusammensitzen, ab dem Zeitpunkt hat man da ja ein kleines Team gebildet und man kann dann plötzlich über diese Themen dann am Gang oder schnell mal reden und sich sehr schnell austauschen. Also es gibt hier auch eine Art Teambuilding-Prozess und es ist normal, über Prozesse und IT zu reden ab dem Zeitpunkt, wo man das mal getan hat.

Götz Müller: Ja, genau. Und das fand ich jetzt auch, ja, ein stückweit ein gutes Schlusswort. Dieses Miteinanderreden, glaube ich, da schadet es dann gar nicht, wenn man ein „profanes Werkzeug“ oder ein „profanen Zwang“ hat, zu dokumentieren, wenn da durch die Hintertür praktisch dieses Miteinanderreden auftritt, weil das ist auch die Erfahrung, die ich immer wieder mache, in dem Augenblick, Sie haben es mehrfach angedeutet, da beginnen wirklich die Hirnwindungen sich gegenseitig zu verkoppeln und da entsteht dann auch die echte Verbesserung, auf die es mir persönlich immer ankommt.

Herr Resch-Edermayr, ich danke Ihnen für Ihre Zeit. Ich fand es ein klasse Gespräch, bin im Grunde noch aus keinem rausgegangen, ohne etwas Neues gelernt zu haben.

Peter Resch-Edermayr: Ja, danke Herr Müller auch für die Einladung, es ist auch für mich eine schöne Gelegenheit ein bisschen aus der Schule zu plaudern und es würde mich freuen, wenn wir ein bisschen einen Beitrag geleistet haben, dass man in Europa für ein bisschen sichere und optimierte IT gesorgt haben, nicht nur IT, sondern letztlich auch Geschäftsprozesse. Vielen Dank.

Götz Müller: Ich danke Ihnen.

Das war die heutige Episode im Gespräch mit Peter Resch-Edermayr zum Thema IT-Dokumentation. Notizen und Links zur Episode finden Sie auf meiner Website unter dem Stichwort 095.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei iTunes.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder zu lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.