Wenn dem IT-Chef der Kragen platzt

"Sie müssen sich an unsere Richtlinien halten"

26.05.2013 von Sabine Niodusch
In der fiktiven H.UMOR AG knirscht es in der Zusammenarbeit zwischen IT und Fachabteilungen. Projektleiterin und Autorin Sabine Niodusch hat einen typischen Dialog für COMPUTERWOCHE-Leser nachgezeichnet.
Sabine Niodusch ist freiberufliche Beraterin und Trainerin in IT-Projekten sowie als Autorin tätig.
Foto: Niodusch Consulting

Tim Lenze, CIO der H.UMOR AG, schnaubt: "Wenn Sie ein Projekt umsetzen wollen, halten Sie sich besser an die Regeln." "Und die wären?", fragt Sven Wintermann, neuer Leiter Innendienst, leicht ironisch. Lenze schüttelt den Kopf: "Offensichtlich hat Ihnen noch niemand unsere Spielregeln erklärt. Für jedes Projekt gilt:

Sven Wintermann, neuer Leiter Innendienst: "Warum braucht die IT so lang, um eine App zu entwickeln?" - IT-Chef Lenze antwortet: "Ihre Anwendung muss sich mit der ganzen IT vertragen."
Foto: Michael Kowalski - shutterstock.com

Wintermann unterbricht ihn: "Dann können wir das Projekt vergessen, da tragen mir die ITler tausende Bedenken vor, warum was nicht geht und weshalb das Projekt plötzlich Millionen kosten würde. Ihre Richtlinien sind unrealistisch."

"Das ist Ihre Sicht der Dinge", kontert Lenze. "Da Sie selten ein Vorhaben auf der grünen Wiese starten, müssen Sie sich an unsere Richtlinien halten."

"Hier ist ein iPhone", nestelt Wintermann seines aus der Tasche. "Damit kann ich mir in 30 Sekunden eine kostenlose App herunterladen - und fertig ist die Anwendung. Und mit Ihnen soll ich mich jetzt über Regeln unterhalten."

"Wenn Sie länger im Unternehmen bleiben wollen, empfehle ich Ihnen das dringend", knurrt Lenze. Wintermann murmelt etwas, das "wie uncool" klingt. "Herr Lenze, Sie sind doch ein kluger Mann", schmeichelt Wintermann plötzlich. "Es gibt in der IT doch immer eine Abkürzung." "Stimmt", sagt Lenze schmunzelnd, "aber die wollen auch die Leute vom Marketing und aus der Personalabteilung haben. "

"Was muss ich tun, damit ich bevorzugt behandelt werde?", lässt Wintermann nicht locker. "Wenn Sie mir erstens versichern, dass Ihr Projekt zu einem festen, am besten vom Gesetzgeber vorgegebenen Endtermin live gehen muss." "Und zweitens?", ist Wintermann neugierig. "Sie sollten wasserdicht begründen können, dass es für Sie keinen anderen Ausweg gibt, als die Lösung sofort von der IT zu bekommen. Um die Schritte eins bis drei und den schriftlichen Projektantrag kommen Sie nicht herum. Je nach Projektbudget unterhalten Sie sich nicht nur mit mir, sondern mit unserem CEO, Dr. Simon Profitlich." Lenze lässt eine Pause entstehen. "Ich weiß nicht, wie gut Sie Profitlich kennen, doch der fühlt Ihnen auf den Zahn und holt zudem meinen Rat ein." Wintermann zieht die Stirn in Falten. "Ganz schön langatmig. Mit dem iPhone ging das schneller."

Worauf Projektleiter achten sollten
Worauf Projektleiter achten sollten
Grundsätzlich sind wie für jedes andere technische Projekt folgende Fragen zu beantworten:
Was wird bezweckt, ...
... wer soll davon einen Nutzen haben, was müssen entsprechende technische Ziele sein, wie lässt sich das Ganze finanzieren, technisch umsetzen, in die bestehende IT-Umgebung (auch administrativ) integrieren?
Der vorgesehene Grad der Offenheit ...
... muss definiert sein und bestimmt die Ansprüche schon an die Metadaten. An den Schnittstellen nach außen dürfen keine herstellereigenen, lizenz- oder kostenpflichtigen Formate Voraussetzung sein.
Fair, Reasonable And Non-Discriminatory (FRAND) ...
... ist nicht zukunftssicher. Proprietäre Technologien haben einen herstellerbestimmten Life Cycle.
Ein Open-Projekt darf niemals ...
... in eine neue Herstellerabhängigkeit führen. Alles muss ersetzbar sein.
Die verwendeten Software-Tools ...
... sollten ausschließlich auf offene Schnittstellen und international akzeptierte Standards ausgelegt sowie bestens dokumentiert sein. Daher liegt die Nutzung von Open-Source-Software nahe, ist aber nicht zwingend.
Wer sich selbst öffnen muss, ...
... darf das auch von Auftragnehmern verlangen. Falls für die Entwicklung eines Open-Source-Projekts Dienstleister benötigt werden, sollten es mehrere sein. Die notwenige kooperative Software-Entwicklung macht einen offenen Umgang mit geistigem Eigentum notwendig. „Not invented here“ ist fehl am Platze.
Release often, release early
In Open-Projekten kommt es zur Akzeptanz auf schnell vorzeigbare Erfolge und laufenden Ausbau an. Öffnung ist immer ein Prozess.

"Im Gegensatz zu Ihrem Spielzeug da", und Lenze lässt es abschätzig klingen, "sind Sie mit Ihren Anwendungen nicht allein auf der Welt. Sie müssen in die gesamte IT eingebunden werden und sich mit ihr vertragen."

"Ist ja schon gut", gibt Wintermann nach. "Wäre doch cool, wenn Ihre Anwendungen so schnell installiert wären wie diese Apps." "Kennen Sie eine IT, die dazu imstande wäre?", fragt Lenze provozierend. "Naja, bei meiner letzten Firma durften wir alles auf das iPhone laden", erzählt Wintermann. "Und?" wird Lenze neugierig. "Irgendwann hat die Staatsanwaltschaft wegen Veruntreuung von Betriebsgeheimnissen ermittelt", muss Wintermann zugeben. "Und so gut geht es denen im Moment nicht. Deswegen bin ich ja jetzt hier." IT-Chef Lenze triumphiert: "Um zu lernen, wie man richtig mit der IT umgeht und dass iPhones zwar nette Spielzeuge sind, man sie aber im betrieblichen Kontext nur so nutzen darf, wie die IT es vorgibt!"(hk)

* Sabine Niodusch ist freiberufliche Beraterin und Trainerin in IT-Projekten sowie als Autorin tätig.