Wie man IT-Projekte zum Erfolg bringt: Kleine Ideen ganz groß

»Geil!«

Das Wort »connected« stand rechts oben auf der Webseite. Es sah alles andere als spektakulär aus, aber diese Kleinigkeit, die fast schon banal wirkte, kämpfte sich durch diverse Schichten des SAP CRM 7 bis an die Oberfläche hindurch, um dort weitere Ebenen und Systeme zu durchqueren, bis es endlich dort oben auf dem Bildschirm angekommen in grüner Schrift aufzuleuchten begann.

Wer SAP kennt, der weiß, dass nichts daran so einfach ist, vor allem nicht, wenn man in dessen Oberfläche (UI) für die Contact Center Lösung (Interaction Center WebClient genannt) etwas umsetzt, was von der Software so nicht vorgesehen wurde.

Aber das war es nicht, was den Mitarbeiter meines Kunden (ein anderer als dieser) zu seinem begeisterten Aufruf verleitete, sondern die Idee, genau diese Information überhaupt und dort zu platzieren. Der Mitarbeiter erkannte sofort, die weitreichende Bedeutung meiner Umsetzung.

Zeit für Ideen

Die Idee zu dieser Lösung kam mir am Vorabend, weil mich ein Problem bei dieser Umsetzung noch nach der Arbeit umtrieb. Eigentlich will ich mich nach Feierabend nicht mehr mit der Arbeit beschäftigen, doch das passiert mir, wenn mich ein Thema wirklich interessiert und nicht mehr loslässt. Schlimmer wird es bei mir, wenn mir dann wirklich etwas einfällt, was mir selbst gefällt.

Als mir die Idee kam, lief ich sofort zu meinem Notebook, so cool fand ich sie (daher fand ich das »Geil!« meines Kunden schon treffend)  und schickte mir eine Erinnerungsmail für den nächsten Morgen, sonst hätte ich noch im Bett begeistert darüber nachgedacht – und wer will das schon, vor allem, wenn man sich selbst auferlegt, nach der Arbeit nicht mehr sich mit der Arbeit zu beschäftigen (ich bin schon so schlecht im Bett).

Besonderer Kunde mit echtem Qualitätsanspruch

Aber bei diesem Kunden machte ich gerne eine Ausnahme, oder auch zwei, oder drei… (bitte bis zu deiner Lieblingszahl hochzählen) Dieser Kunde gehörte zu den Kunden, die mir vertrauten und Freiheiten ließen und bereit waren, dafür auch mehr zu bezahlen – das Letztere ist sonst immer das Problem (eigentlich wurde die Arbeit dadurch nicht teurer, eher im Gegenteil, aber dazu später).

Doch dieser Kunde ist ein Familienunternehmen über mehrere Generationen hinweg, das sehr viel Wert auf Qualität legt. Um Missverständnisse zu vermeiden, ich liefere immer qualitativ hochwertige Lösungen ab, und meine Lösung bei diesem Kunden hätte auch ohne diese Kleinigkeit allen Anforderungen voll genügt.

Manchmal kommt es genau auf dieses Detail an.

Etwas Fahrbares mit vier Rädern

Meistens arbeitet man in Projekten unter Budget- und Zeitdruck. Lösungen sind abgeschlossen, wenn sie der funktional definierten Anforderung genügen. Und genau hier liegt eine riesige Bandbreite voller Möglichkeiten, als würde jemand sagen, ich brauche etwas mit vier Rädern, das fährt. Der Kunde erwartet <hier die Marke eines Luxusfahrzeugs einfügen> und bekommt in seinen Augen jedoch einen Trabbi. Bezahlen wollte der Kunde nur für ein Fahrrad.

Natürlich übertreibe ich, aber nur ganz wenig. Es gab sogar Kunden, die forderten, dass das Auto losfährt, obwohl es direkt vor der Wand stand. Das war den Mitarbeiter des Unternehmens egal, denn ihre Vorgabe war es, dass das Fahrzeug fahren muss. Wenn es danach direkt gegen die Wand donnerte, dann war es nicht ihre Schuld, sondern die des Dienstleisters. Der durfte das Wrack dann reparieren.

Das bevorstehenden Probleme, und damit auch die (Folge-)Kosten, wurden also in die Zukunft oder/und auf andere verlagert. Meistens arbeitet man arbeitsteilig und ein anderer Mitarbeiter des Kunden muss sich mit den Folgeproblemen herumschlagen (was auch ein Grundproblem ist, denn einer nimmt das Produkt ab, aber ein anderer muss damit arbeiten, ob er will oder nicht).

Das Absurde und die Folgekosten

Jetzt kommt allerdings das Absurde. Das Fahrzeug wurde vom Kunden genauso spezifiziert, budgetiert und das Datum der Umsetzung festgelegt. Nachdem das Fahrzeug fristgerecht fertig gestellt wurde, erfolgen in der Regel Tests und eine Abnahme.

Wenn nach der erfolgreichen Abnahme ein Fehlerfall eintritt, schaut man sich an, ob es sich um einen echten Fehler handelt oder eine fehlende Anforderung (auch Gap genannt). In diesem Beispiel würde der Kunde sich beschweren, dass das Auto kaputt gegangen ist. Darauf würde der Dienstleister den Fehlerfall untersuchen und folgerichtig erwidern, dass man einen Wagen nicht gegen die Wand fahren darf, denn dafür wurde es nicht gebaut. Somit handelt es sich nicht um einen kostenlosen Garantiefall, und für die Reparatur muss und wird der Kunde bezahlen.

Und jetzt die Binsenweisheit, weil sie jeder Projektteilnehmer auf allen Seiten kennt: Wer am Anfang spart, der verliert am Ende viel mehr Geld. Zeit. Nerven.

Der Fehlerfall mit Pointe

Genau das wusste der Mitarbeiter, dem ich die Kleinigkeit vorführte, denn er gehörte nicht nur zu den Anforderern der Funktionalität, sondern musste im Fehlerfall selbst aktiv werden (müsste er es nicht, würde er trotzdem an diese Menschen denken, die sich mit dem Problem herumschlagen müssten, und entsprechend handeln).

In dem Moment, wo wir mit dieser Lösung live gehen würden, d.h. wir führen diese Lösung in diversen Ländern des Kunden ein, hätten wir im Fehlerfall ein nicht unerhebliches Problem. Um genauer zu sein, wir wüssten zunächst nicht, ob wir ein Problem hätten, denn die Oberfläche für das Contact Center verbannt sich über einen anderen Server mit einer anderen Applikation.

Es gab als drei Fehlerquellen und alle drei könnten für sich keinen Fehler haben, aber im Zusammenspiel trotzdem nicht funktionieren. Diese winzige Meldung oben rechts gab also Auskunft über den Zustand des Systems und im Fehlerfall Auskunft über das System, das ein Problem verursacht bzw. hat.

(Fehlerbehandlung, Logging oder Protokollierung werden gerne vernachlässigt, vergessen oder unzureichend umgesetzt, denn – du weißt schon – Zeit, Geld, Kapazitäten etc. Ein Problem ist halt nur ein Problem, erst wenn es auftritt. Und dann ist es auch nur ein Problem der anderen.)

Jetzt kommt der nächste Gag.

Im Fehlerfall würde ich von meinem Kunden zur Analyse und Lösung dieses Problems mitbeauftragt werden, da der Mitarbeiter meine Unterstützung benötigen würde. Meistens sind Analysen und Anpassungen an der Lösung im Nachhinein sehr viel aufwendiger als die Umsetzung einer besseren Lösung direkt zu Beginn.

Erschwerend käme in diesem Fall hinzu, dass die externen Dienstleister der anderen beiden Systeme hinzugezogen werden müssten. Damit würde der/die Dienstleister in den meisten(?) Fällen also mehr Umsatz mit der Problemlösung machen als mit einer optimaleren bzw. besseren Lösung.

Bei diesem Kunden wäre ich somit der 3rt Level Support. Davor käme der 2nd Level Support zum Einsatz, den meine Kollegen machen. Also würde meine Firma auch dort Umsatz generieren.

Zuletzt käme noch hinzu, dass die Mitarbeiter meines Kunden mit dieser Lösung arbeiten würden. In diesem Fall wären die Agenten im Kontakt-Center betroffen, die sich über den Fehler ärgern würden, vielleicht wäre der Kunde am Telefon auch davon betroffen. Am Ende würde es dem Ansehen der Software und den daran mitwirkenden Mitarbeitern schaden. Was wiederum die Berater in den Fokus rücken würde. So zieht eine nicht umgesetzte Kleinigkeit immens große Kreise nach sich.

Die Mücke und der Elefant

So ist das halt mit Kleinigkeiten. Schätz man sie, können sie Großes bewirken.

Eines dieser Kleinigkeiten ist der Berater deines Vertrauens, also ich;-)

Im Ernst: Ich stelle mir vor, wie jemand acht Stunden jeden Tag über Jahre mit der Software arbeitet, für die ich Lösungen erstelle. Dann werden schnell mal aus Kleinigkeiten große Hindernisse, alleine schon, weil sie zu nerven beginnen.

Die richtigen Kleinigkeiten hingegen helfen dem Mitarbeiter, vor allem wenn es sich um Fehler handelt, die nicht ersichtlich sind. Und genau die Suche nach diesen Kleinigkeiten treibt mich an (und natürlich die Schönheit der Lösung).

Ich bin intrinsisch motiviert, d.h. ich motiviere mich selbst. Das ist Lohn genug (wenn das mein Arbeitgeber liest: Gehalt ist immer zu niedrig), und wenn mein Kunde das zu schätzen weiß, dann versuche ich die beste Lösung zu finden. Also eine Win-Win-Win Situation, denn, dass Unternehmen, dessen Angestellter ich bin, profitiert davon auch.

Der Kunde sollte nicht gegen den Dienstleister arbeiten, ihm/ihr gewisse Freiräume einräumen und sich als Team begreift, das im selben Boot sitzt. Dann steckt die Begeisterung gegenseitig an. Am Ende kommt meistens mehr heraus, als das, was beauftragt und bezahlt und auch vorstellbar wäre.

Übrigens gehört Wertschätzung ebenso dazu.