Projektmanagement – Chris' IT Guide to The Galaxy

Podcast von Bernd Geropp über erfolgreiche Projektführung

CJeske — Thu, 07 Aug 2014 15:44:19 +0000

Bernd Geropp hat in seiner Podcastreihe „Führung auf den Punkt gebracht“ eine Folge zum Thema Projektmanagement veröffentlicht.

Als regelmäßiger Zuhörer seines Podcasts kann ich diesen nur empfehlen und diese Folge mit einem Interview mit Stefan Hagen ganz besonders.

FPG058 – Projekte erfolgreich managen und führen! Bei welchen Projekten sind agile Ansätze sinnvoll? Interview mit Stefan Hagen

Refactoring in der agilen Softwareentwicklung – Aufräumen muss sein!

CJeske — Wed, 15 Jan 2014 11:54:52 +0000

In der agilen Softwareentwicklung leiden viele Programme unter der Quick&Dirty Methode. Ein Stakeholder schreit und das gewünschte Programm oder Funktion muss schnellstmöglich umgesetzt werden. Oft bleiben diese Programme oder Funktionen länger im Einsatz als gedacht und eine spätere Pflege wird erschwert oder ist unmöglich. Zusätzlich leiden solche Programme unter verschiedensten Symptomen, wie Geschwindigkeitsprobleme oder unerklärliche Ergebnisse. Somit bleibt ein Refactoring, also eine Strukturverbesserung und eine klare Kommentierung des Programms oder Algorithmus, unter Beibehaltung der gewünschten Funktion, nicht aus, um ein zukunftssicheres Produkt zu erstellen.
Refactoring gibt es in zwei Varianten. Einmal kann man die grundlegende Architektur eines Programmes überdenken und zum anderen kann man den Quellcode optimieren.
Beim Architektur Refactoring stellt man sich grundlegend die Fragen, ob man die richtige Struktur für ein Programm oder Funktion gewählt hat, um die Anforderungen bestmöglich zu erfüllen. Hier sollten Dinge besprochen werden, wie Schnittstellenmöglichkeit, Technologie und Interoperabilität. Erstelle ich eine Anwendung als RichClient oder unter dem Paradigma von SOA. Je nach Bedarfsfall und Anwendung kann sich dies auch im Laufe der Zeit ändern. Somit ist für ein Programm mit längerem Lebenszyklus ein Architectur Refactoring zu empfehlen.
Das Code Refactoring sollte im agilen Prozess stetiger Begleiter sein, weswegen man auch meist von einem kontinuierlichen Refactoring spricht. Am Ende jedes Sprints steht ein potenziell auslieferbares Inkrement mit festgelegten Funktionen. Diese Funktionen müssen während des Sprints auch den Prozess des Code Refactoring durchlaufen. Dabei wird der Code auf Lesbarkeit, Übersichtlichkeit, Verständlichkeit, Erweiterbarkeit, Testbarkeit und Vermeidung von Redundanz geprüft.
Die Vorteile eines kontinuierlichen Refactorings spiegeln sich im Gesetzt der großen Zahlen wieder. In jedem Sprint ein wenig Zeit dafür zu verwenden ist wesentlich einfacher und zeitlich weniger aufwendig als im nach hinein tausende Codezeilen zu bearbeiten.
Refactoring ist somit ein wichtiger Bestandteil eines Entwicklungsprozesses, um ein zukunftsicheres und pflegbares Softwareprodukt herszustellen.

Weiterführende Links zum Thema:
Martin Fowler: Refactoring. Wie Sie das Design vorhandener Software verbessern. Addison-Wesley Verlag, ISBN 3-8273-1630-8
heise developer Podcast Architektur Refactoring http://www.heise.de/developer/artikel/Episode-8-Architektur-Refactoring-353295.html

Agiles Projektmanagement mit Erfolg einsetzen (02) – Kundenanforderungen

CJeske — Sat, 31 Aug 2013 09:49:13 +0000

Der Kunde weiß aus seiner Erfahrung, wie unwahrscheinlich es ist, dass das Team ein System liefert, das den Kundenwünschen entspricht. Das Team hat wiederum die Erfahrung gemacht, dass der Kunde nicht weiß, was er will, und in dem Moment, in dem das Team glaubt, die Kundenwünsche zu kennen, seine Meinung erneut ändert.[…]

– Ken Schwaber: Agiles Projektmanagement mit Scrum. Washington 2007, S. 56 –

Mit meinem ersten Beitrag zum agilen Projektmanagement bin ich mittendrin eingestiegen, ohne jedoch den ersten Schritt anzugeben: Aber am Anfang eines Projektes steht immer die Kundenanforderung. Das obere Zitat von Ken Schwaber, der mit Jeff Sutherland zusammen Scrum entwickelte, trifft oft die Problematik der Anfangssituation.

Aber wie kommt es dazu?

In den meisten Softwarefirmen wird das Wasserfall-Modell oder das V-Modell eingesetzt. Sie beschreiben einen Fluss von mehreren Punkten. Meistens Analyse- und Definition, Entwurf, Implementierung und Test. Nach jedem Punkt wird den Stakeholdern, also allen am Projekt Interessierten, die Ergebnisse präsentiert und überprüft, ob sich das Projekt in die richtige Richtung bewegt. Je tiefer im Projekt oder „Wasserfall“, desto schwerer oder kostenintensiver ist es, frühere unbeachtete Fehler zu korrigieren. Die Vorstellung, man fällt wirklich einen Wasserfall herunter zeigt deutlich: Es ist unmöglich wieder hoch zu schwimmen. Es sei denn, man bestelle einen Kran, der einen wieder hochzieht. Somit ist auch der Kunde daran interessiert, spät entdeckte Fehler oder Fehlinterpretationen zu ignorieren, damit seine Projektkosten nicht explodieren. Das Ergebnis ist ein Produkt, welches nur zum Teil oder im schlimmsten Fall gar nicht den Kundenanforderungen entspricht. Die Bezeichnung Wasserfall Modell passt somit wie die Faust aufs Auge. Viele Projekte ertrinken unterwegs.

Aber was macht Agiles Projektmanagement besser und wo liegen seine Vorteile? Es beruft sich auf kurze Iterationen und Inspektionszyklen. Am Anfang steht bei Scrum eine Kundenvision. Sie enthält den erwarteten ROI, die Releases und Meilensteine. Daraus entwickelt der Kunde zusammen mit dem Product Owner den sogenannten Product Backlog mit allen sich abzeichnenden Anforderungen. Das Team wählt nun aus diesem Product Backlog in dem sogenannten Sprint Planning Meeting Funktionen aus, welche sie innerhalb des nächsten Sprints (30 Tage) zu einem demonstrierbaren Prototyp entwickeln können. Mit diesem Sprint Backlog fängt das Team an zu entwickeln und überprüft alle 24 Stunden im Daily Scrum den Fortschritt. Am Ende jedes Sprints können der Product Owner und die Stakeholder das Projekt im Sprint Review Meeting anpassen.

Der Unterschied ist enorm. Dadurch, dass der Kunde alle 30 Tage Funktionen sieht, kann er Wünsche und Korrekturen kostengünstig äußern und umsetzten. Er sieht, was möglich ist und bekommt genau das, was er wünscht. Durch diese persönliche Einbindung des Kunden wird das Projekt qualitativ hochwertiger und der Softwareentwicklungsprozess schneller. Die Kundenvision, welche am Anfang stand, kann der Kunde durch Sehen des Machbaren immer neu ausrichten und diese folglich von Sprint zu Sprint immer realer erscheinen lassen.

Durch diese einfachen Methoden der kurzen Iteration kann man dem Fluch der Lasten- und Pflichtenhefte entkommen und den Kunden und das Entwicklungsteam wieder näher zusammenbringen.

Das Problempotenzial wird drastisch verringert und beide Seiten können Missverständnisse schneller korrigieren. Dadurch sind alle Beteiligten positiver gestimmt und bekommen ein zufriedenstellendes Ergebnis.

Gamification – Jeder spielt!

CJeske — Tue, 02 Jul 2013 07:28:10 +0000

Denn es um es endlich auf einmal herauszusagen, der Mensch spielt nur, wo er in voller Bedeutung des Wortes Mensch ist, und er ist nur da ganz Mensch, wo er spielt.

– Friedrich Schiller 15. Brief, Über die ästhetische Erziehung des Menschen 1795 –

Menschen verbringen in Spielen Höchstleistung. Ob es nun beim Fußball, Golf oder StarCraft 2 ist und das tun sie freiwillig und unentgeltlich. Spiele regen unsere Kreativität an, motivieren, geben uns Ausgleich und fördern Gesundheit, Intelligenz und soziale Kompetenz. Ich spiele gerne! Ich spiele gerne Gesellschaftsspiele, Golf oder mit meiner Tochter und als Mitglied der sogenannten Generation-Y bin ich mit Computerspielen groß geworden und spiele auch diese gerne. Ich bin dabei nicht alleine. Laut Studien spielen 65 % der deutschen Internetnutzer Computerspiele (Vgl. TNS / Gameindustry.com: 2009).

Aber was ist ein Spiel und warum verbringen Menschen so viel Zeit damit? Johan Huizinga hat 1956 ein Spiel so definiert: „Spiel ist eine freiwillige Handlung oder Beschäftigung, die innerhalb gewisser festgelegter Grenzen von Zeit und Raum nach freiwillig angenommenen, aber unbedingt bindenden Regeln verrichtet wird, ihr Ziel in sich selber hat und begleitet wird von einem Gefühl der Spannung und Freude und einem Bewußtsein des ‚Andersseins‘ als das ‚gewöhnliche Leben‘“. (Homo Ludens; Vom Ursprung der Kultur im Spiel; Reinbek 1956).

Menschen haben also bei Spielen eine sehr hohe Motivation, freiwillig einer zum Teil komplexen Beschäftigung nachzugehen, welche bestimmten Regeln folgt und diese zu lernen. Computer bieten heutzutage die Möglichkeit, sehr komplexe Spiele zu erstellen. Moderne Computerspiele fördern Kreativität, Intelligenz als auch soziale Kompetenzen, erweitern das Allgemeinwissen und das Alles mit Spaß. (Alles was ein Fernsehabend bei RTL nicht bieten kann und nein, „Wer wird Millionär?“ zählt nicht zum Bildungsfernsehen ;-P) Gamification versucht, diese positiven Eigenschaften zu nutzen und implementiert Spielprinzipien und Prozesse in die Arbeitswelt. Es versucht, eine dauerhafte Verhaltensänderung zu erzeugen, damit Menschen positiver und motivierter bestimmte Dinge erledigen.

Das Prinzip Gamification funktioniert. Große Firmen wie SUN oder Microsoft verwenden Gamification in den verschiedensten Bereichen mit Erfolg. SAP hat zum Beispiel sein SAP Community Network seit April dieses Jahres um Spielprinzipien erweitert. Seitdem werden Punkte, Ränge und Erfolge für bestimmte Aufgaben verteilt, die Benutzer in der Community erledigen. Dadurch wird die Qualität und Quantität der Beiträge gesteigert und somit eine komplexe Wissenbasis für SAP Produkte geschaffen.

Gamification bedient sich verschiedenster Bausteine moderner Computerspiele und hat sehr viele unterschiedliche Aspekte die berücksichtigt werden müssen.

In Spielen werden Gesamtaufgaben in kleine kurze Häppchen unterteilt. So genannte Questreihen. In World Of Warcraft zum Beispiel musste man am Anfang, um Zugang zu einem bestimmten Gegner zu bekommen (Onyxia) einen Schlüssel erspielen. Diese Questreihe schickte den Spieler in alle Teile dieser virtuellen Welt, um verschiedenste Aufgaben zu erledigen. Dabei mussten die Spieler sich zum Teil mit anderen Spielern zusammentun, um die Teilaufgaben zu erledigen und manchmal stupide Aufgaben alleine erledigen. Verwende ich jetzt andere Begriffe, ist dies nichts anderes als Arbeit in einem normalen Unternehmen. Trotzdem machten Millionen von Spielern aus aller Welt dies aus Eigenmotivation freiwillig.

Ich versuche mal, dieses Beispiel auf ein Unternehmen zu projizieren. Als Jahresziel nehmen wir zum Beispiel den Abbau von Lagerhütern in der Summe von 100.000 €. Diese „Questreihe“ wird jetzt in verschiedenste Teilaufgaben unterteilt, welche alle Mitarbeiter aus dem Bereich bekommen. Einige sind wiederholbar („Finde einen Lagerhüter“) einige einmalig („Verschrotte Artikel X“). Für das Erledigen der Teilaufgaben gibt es Punkte (z.B. pro Lagerhüter ein Punkt) und Erfolge (z.B. Trophäe „CSI Lager – Sie finden 5 Lagerhüter“). Diese Erfolge werden für jeden sichtbar gemacht und als Ziele gesetzt. Zudem werden die Erfolge und der Status jedes Mitarbeiters öffentlich ausgestellt (Level, gesammelte Erfolge.) Zudem werden Teams gebildet, die in einer Tabelle nach Punkten angezeigt werden. Punkte können dann am Ende zum Beispiel in zusätzliche Urlaubstage gewandelt werden. Mit diesem Anfang wird aus einer langzeitstrategischen, unternehmerischen Planung ein Spiel.

Für Gamification gibt es keine Patentlösung. Für die jeweiligen Aufgaben und Mitarbeiter muss das Spiel neu erfunden werden. Wichtig ist, dass das Spiel langzeitmotiviert und direktes Feedback gibt, was wohl die wichtigsten Aspekte einer guten Spielifizierung ausmachen.

Gamification ist nicht einfach. Langeweile und Piontification (nur das Verteilen von Punkten) können es unterwandern und nur einen sehr kurzen Motivationsschub bewirken. Eine dauerhafte Verhaltensänderung ist damit nicht gegeben und anfängliche Erfolge können nicht wiederholt werden. Gamification ist ein zu aktualisierender Prozess. Die Herausforderung muss sich stets wandeln und dem „Spieler“ Abwechslung und mehr als nur Punkte bieten.

Gamification steckt noch in den Kinderschuhen und ob es ein Trend ist, der wieder abflaut oder sich fest in die Managementmethodik integriert, bleibt noch abzusehen. Jedoch ist das Potenzial vorhanden. Es bietet ein hohes Maß an Motivation und richtig eingesetzt kann man dauerhaft Menschen dazu bewegen, in langweiligen Aufgaben ein Spiel zu sehen, welches sie gerne spielen.

Agiles Projektmanagement mit Erfolg einsetzten (01) – Meetings

CJeske — Mon, 17 Jun 2013 09:01:16 +0000

Seit je her bin ich im Projektgeschäft tätig. Schon in meiner Ausbildung habe ich individuelle Lösungen für Kunden programmiert, wobei Kundenorientierung immer im Vordergrund stand. Frühzeitig habe ich erkannt, dass Pflichten- oder Lastenhefte Vor- und Nachteile haben. Wenn ich zurückblicke sind die besseren Projekte durch klar definierte Ziele aus Anwendersicht geprägt worden und kamen ohne solche Anforderungslisten aus. Mit diesem ersten Beitrag möchte ich eine Serie starten, mit der ich meine Erfahrungen mit agiler Softwareentwicklung und agilem Projektmanagement berichte.

Mit agilem Projektmanagement können Projekte rapide und effizient zum Erfolg geführt werden. Schnelles Feedback und kurze Entwicklungszyklen fördern deutlich die Qualität und bewahren vor Fehlentwicklung. Leider gibt es auch viele Stolpersteine, wodurch die anfänglichen Ziele weit verfehlt werden können.

Ein großes Problem in der Softwareentwicklung ist das „Vorbeiprogrammieren am Kunden“. Ziele müssen klar aus Anwendungssicht formuliert sein. Ist das endgültige Produkt falsch beschrieben, können nachträgliche Änderungen ziemlich teuer werden.

Richtig eingesetzt kann agiles Projektmanagement verhindern, dass ein Produkt entwickelt wird, welches den Anforderungen der Benutzer nur zum Teil oder gar nicht entspricht. Eine essentielle Voraussetzung besteht in der stetigen Kommunikation zwischen allen Projektbetroffenen. Durch wöchentliche Meetings mit den Stakeholdern (Interessenten) und täglichen Meetings des Projektteams kann ein effizientes Exceptionmanagement (Abweichungsmanagement) aufgebaut werden. In der Praxis können so schwammig definierte Projektpunkte konkretisiert und schnell korrigiert werden, falls die Entwicklung sich in die falsche Richtung bewegt.

Allerdings stellen genau diese Meetings gleichzeitig die ersten Stolpersteine dar und dies in mehreren Aspekten.

Aspekt 1: Die Meetings müssen zeitlich begrenzt sein. Sie dürfen nicht zu lange dauern. Die täglichen Meetings sollten sich an einem Zeitfenster zwischen fünf und zehn Minuten halten und die wöchentlichen Meeting nicht über eine Stunde hinausgehen. Zu schnell wird sonst dazu geneigt, Themen zu zerreden und das Projekt unnötig in die Länge zu ziehen. Natürlich sollten bestimmte Problemstellungen zwischen den Verantwortlichen länger besprochen werden. Es ist stets bei den Meetings zu beachten, das es um das weitere Vorgehen im Projekt als Ganzes geht und Teilaufgaben nur als „in Arbeit“, „nicht gestartet“ oder „fertig gestellt“ besprochen werden mit der Angabe, wann noch offene Punkte abgearbeitet sein sollen. Dadurch haben alle Teammitglieder eine Übersicht über den Projektfortschritt.

Das wöchentliche Meeting hat zum Ziel den Stakeholdern eine Übersicht über die schon fertig gestellten Projektschritte zu geben und wie man im geplanten Zeitrahmen steht. Fragen, die beantwortet werden sollten, sind zum Beispiel: „Bewegt sich das Projekt in die richtige Richtung?“, „Werden in den schon fertig gestellten Teilaufgaben alle definierten Punkte richtig umgesetzt?“ oder „Befindet sich das Projekt im vereinbarten Zeit- und Kostenrahmen?“. Bei Meilensteinen sollte das Produkt auch immer zumindest als Prototyp mit den definierten Punkten präsentiert werden. Dadurch haben die Stakeholder auch konkrete Berührungspunkte zum Projekt und Missverständnisse können schneller erkannt und geklärt werden. Hier sollten auch Änderungen von Projektpunkten besprochen werden.

Die Umsetzung dieses Konzeptes mit Beachtung seiner einzelnen Aspekte erfordert ein hohes Maß an Disziplin. Helfen können genaue Rollenverteilungen. Beim Einsatz des Scrum-Vorgehensmodells für agiles Projektmanagement von Jeff Sutherland und Ken Schwaber werden zum Beispiel sechs verschiedene Rollen verteilt. Dabei ist der Scrum-Master für die korrekte Einhaltung der Prozesse zuständig. (Die anderen Rollen: Entwicklungsteam, Product Owner Management, Customer und User werde ich in weiteren Einträgen dieser Serie genauer erklären)

Durch ein erfolgreiches agiles Projektmanagement kann ein Produkt schnell, kostengünstig und qualitativ hochwertig fertig gestellt werden. Jedoch erfordert dies die Disziplin aller Beteiligten und das Umdenken weg vom klassischen Pflicht- und Lastenheft, hin zu einer klar aus Anwendungssicht formulierten Zielsetzung.

Das Babelfisch-Problem

CJeske — Sat, 18 May 2013 18:21:06 +0000

„Der Babelfisch […] ist klein, gelb und blutegelartig und wahrscheinlich das Eigentümlichste, was es im ganzen Universum gibt. Er lebt von Gehirnströmen, die er nicht seinem jeweiligen Wirt, sondern seiner Umgebung entzieht. Er nimmt alle unbewußten Denkfrequenzen dieser Gehirnströme auf und ernährt sich von ihnen. Dann scheidet er ins Gehirn seines Wirtes eine telepathische Matrix aus, die sich aus bewußten Denkfrequenzen und Nervensignalen der Sprachzentren des Gehirns zusammensetzt. Der praktische Nutzeffekt der Sache ist, daß man mit einem Babelfisch im Ohr augenblicklich alles versteht, was einem in irgendeiner Sprache gesagt wird. Die Sprachmuster, die man hört, werden durch die Gehirnstrommatrix entschlüsselt, die einem der Babelfisch ins Gehirn eingegeben hat. […]“

Douglas Adams: „Per Anhalter durch die Galaxis“, S. 54.

Ich wünschte, solch einen Babelfisch würde es geben! – Ich find‘ die Idee klasse! Er würde Projekte und vor allem Projektdefinitionen wesentlich vereinfachen. Das Besondere an einem Babelfisch ist, dass er nicht einfach das Gesprochene übersetzt, sondern das Gemeinte übermittelt. Einige externe Dienstleister würden in vielen Projekten nur die Hälfte an Stunden berechnen können. Somit wäre der Babelfisch auch ein wahres Geheimrezept, um Kosten einzusparen.

In der Kommunikationstheorie gibt es verschiedene Modelle, die Kommunikation zwischen zwei oder mehr Teilnehmern beschreiben. Als Grundvoraussetzung für eine fehlerfreie Kommunikation in diesen Modellen wird jedoch ein gemeinsamer „Zeichensatz“ benötigt. Sprich: Alle verstehen unter einem bestimmten Wort das Gleiche und alle haben den gleichen Wortschatz. Ich denke, bei Wikipedia kann man dies als Beispiel eines perfekten Paradoxons aufnehmen. Klar ist ein Stuhl ein Stuhl. Aber bei Projekten geht es meistens nicht um Büromöbel, auch wenn sie noch so ergonomisch geformt sind, sondern um komplexe Aufgaben und Abläufe.

Wenn Spezialisten aus verschieden Bereichen aufeinander treffen, gibt es häufig bestimmte Begriffe, bei denen die Bedeutung für den Einen selbstverständlich sind und die wiederum bei Anderen ein spontanes „HÄH??“ verursacht. Zudem gibt es unternehmensspezifische Ausdrücke (die berühmt berüchtigten Insider), welche externe Mitarbeiter auch abteilungsfremde Mitarbeiter nicht verstehen. Bei Projektmeetings sollte man also stets darauf bedacht sein, eine verständliche „Sprache“ zu sprechen. Man sollte versuchen, sich in seinen Gegenüber kurz hinein zu versetzten. Vor allem aber sollte man eines tun: Wenn man etwas nicht verstanden hat, nachfragen! Nachzufragen ist für viele eine Hürde. Aber man kann nicht alles wissen. Vor allem bei fachfremden Ausdrücken. Einfach Kopfnicken und dann später (so nach zwei bis drei Wochen im Projekt) zuzugeben, dass man doch nichts richtig verstanden hat, untergräbt die meist hart erarbeitete Glaubwürdigkeit komplett. Also lieber zugeben, dass man etwas nicht weiß. Aber das ist nur ein Teil des Problems, welches sich durch den Babelfisch in Luft auflösen würde.

Ein größeres Problem ist, wenn in einem Projekt falsch formulierte Vorgaben gemacht werden oder gar nicht mit den Betroffenen geredet wird. Somit wird am Kunden vorbei entwickelt und mit dem Ergebnis kann keiner etwas anfangen. Zumal die Nachbearbeitung sehr kostspielig ist – und dadurch nie stattfindet. In der Informatik geht es darum, komplexe Aufgaben und Abläufe mit Computern und Programmen zu unterstützen. Dies setzt eine genaue Kenntnis der zu unterstützenden Bereiche voraus. Informatiker lernen jedoch meist nur die Informatikseite in ihrer Ausbildung. Logischerweise müssen somit besonders Anfänger im IT Bereich aufpassen und auch nachfragen, falls etwas nicht verstanden wurde. Jedoch sind gerade die Jungen ITler gehemmt und glauben, sie müssten alles wissen, denn ansonsten würden sie nicht ernst genommen. Doch wie Paul Watzlawick, einer der größten Sprachwissenschaftler des 20. Jahrhunderts, schon feststellte: Man kann nicht nicht kommunizieren. Die Konsequenz dieser wesentlichen und doch einfachen Erkenntnis besteht darin, dass allein die Körpersprache einen verrät, wenn man bei etwas unsicher ist.

Werfen wir also einen Blick auf die Konsequenz des Ganzen: Viele IT Projekte holen nicht das Optimum an Verbesserung heraus oder scheitern gar durch mangelnde Kommunikation oder Verständnis der eigentlichen Abläufe. Gerade im Mittelstand gibt es komplexe Workflows, die meistens nicht dokumentiert sind und nur in den Köpfen der Sachbearbeiter geordnet werden.

Leider gibt es keinen Babelfisch. Wir können somit den Gegenüber oft nicht sofort verstehen. Die Kommunikation ist gestört und muss erst einmal wieder berichtigt werden; wichtige Zeit geht verloren. Aus diesem Grund ist eine gute Kommunikation im Projektmanagement unverzichtbar. Man kann viele Stress vermeiden, wenn zur richtigen Zeit die richtigen Fragen gestellt werden.

Excel „Ob Gift oder Medizin – die Dosis macht‘s“

CJeske — Tue, 07 May 2013 11:56:46 +0000

Ich kam einmal auf einer Party mit einem sehr erfolgreichen Unternehmensberater ins Gespräch. Es ist immer schwer zu erklären, was mein Beruf ist. Bei Fachfremden sage ich meistens „Ich bin Informatiker“. Damit können die meisten etwas anfangen und ich werde dann oft gefragt, ob ich nicht ihren Router oder ihr WLAN einrichten könne. Dieses Mal jedoch wollte ich etwas konkreter werden. Als ich ihm erzählte, dass ich Spezialist für Predictiv Analytics sei, glühte seine Stirn nur so vor Fragezeichen. Nach fünf Minuten „Informatik für Fachfremde“ kam ein Satz von meinem Gegenüber, den ich schon oft gehört und jedes Mal gehasst habe. „Geht das nicht auch mit Excel?“ Ich dachte mir, eine längere Erklärung oder gar ein Disput über den Sinn oder Unsinn, was man mit Excel machen kann, geht auf einer Geburtstagsparty über den normalen Smalltalk hinaus ; und des Frieden Willens antwortete ich mit „Ja.“

Diese Anekdote ist leider wahr. Im Nachhinein plagt mich mein Gewissen! Ich hätte die Diskussion führen sollen! Es ist halt nicht möglich komplexe Prognosen aus umfangreichen Daten in Excel abzubilden. Nicht, dass ich diesem äußerst erfolgreichen Unternehmensberater seine Kompetenz absprechen will. Ganz im Gegenteil, ich halte ihn für sehr fähig. Doch auch die Kompetentesten sind nicht vor Fehlern gefeit und so nimmt der Missbrauch von Excel als Datenbank oder Universaltool seinen Lauf. Die ursprüngliche Funktion der reinen Tabellenkalkulation gerät dabei in Vergessenheit.

Die Beste und gleich schlechteste Eigenschaft von Excel ist, dass jeder damit besser oder schlechter umgehen kann. Somit ist es in vielen Fällen „DAS WUNDERMITTEL“; aber obwohl Excel eine sehr mächtige Tabellenkalkulation ist, bleibt Excel nur eine Tabellenkalkulation.

In meiner Zeit als ITler, habe ich schon viel Schreckliches gesehen, was mit Excel angestellt wurde. Eine Firma ist sogar durch Excelmissbrauch in die Insolvenz getrieben worden. Keine kleine Firma, sondern ein gehobener Mittelständer, der sich einen Fehler in seinem „Kalkulationssheet“ erlaubte und somit Teile seiner Waren unter dem Einkaufspreis verkaufte. Ich könnte Seitenweise mit derartigen Excelmissgeschicken fortfahren aber das soll hier nicht das Ziel sein.

Excel sollte meiner Meinung nach nicht für unternehmenskritische Kennzahlengewinnung oder Kennzahlenhaltung verwendet werden. Dafür ist es einfach zu fehleranfällig. Man verrutscht in einer Zeile und schon ist das Malheur geschehen. Für höhere mathematische Berechnungen sollte man es ebenso wenig missbrauchen und zur Datenhaltung taugt es nicht besser als ein Post-It.

Als Konsequenz den Gebrauch eines so allgegenwärtigen Tools zu unterbinden, stellt allerdings keine adäquate Lösung dar. Sprichworte wie „Excel is SAPs best friend!“ heben gerade hervor, dass es ohne Excel teilweise nicht gehen kann, weil die Individualität in manchen Warenwirtschafts- oder ERP-Systemen fehlen. Zudem würden die IT-Abteilungen gar nicht mehr zur Ruhe kommen, sollten sie jeden Excelgedanken in einem Datawarehouse implementieren (Willkommen im BI-Grab). Es gibt jedoch gewisse Alternativen.

Ad-Hoc Reporting bietet heutzutage schon eine Menge Features, mit denen sich die meisten Excelsheets ablösen lassen. Dadurch ist die gleiche Datenbasis garantiert. (Somit haben alle Auswertungen zumindest die gleichen Fehler).

Auswertungen mit kleinen Datenmengen ohne Wiederholungspotenzial können ohne Probleme in Excel umgesetzt werden. Für alle anderen Auswertungen gibt es am Markt unterschiedliche Anbieter von Bussiness Intelligence Tools wie SAP Business Objects oder kostenlose Varianten wie Pentaho, die sich bestens für Unternehmensauswertung und Kennzahlengewinnung eignen.

Mit Excel lassen sich zwar recht einfach Ad-Hoc Reporte erstellen und auch ansprechend gestalten, jedoch sollte man genauestens hinsehen wofür man diese Auswertung braucht und ob ein reiner „Schnappschuss“ der Daten reicht. Man sollte mit Excel stets mit Bedacht umgehen und vor allem seine Versionierung im Griff haben, denn wie Paracelsus schon sagte: Allein die Dosis macht das Gift.