In der Werbung hört man immer wieder den Slogan „Geiz ist geil“, das mag in manchen Fällen stimmen, aber meistens bezahlt man irgendwann für seinen Geiz – das ist zumindest meine Erfahrung. Das gilt sowohl im Alltagsleben, als auch im beruflichen Leben, insbesondere bei IT Projekten.
Ich habe in letzter Zeit immer wieder die Erfahrung gemacht, dass bei IT-Projekten überall gespart wird. Sei es im Projekt-Management, bei den Skills der Mitarbeiter etc. Um zu verdeutlichen, was ich meine, will ich ein paar Fallbeispiele angeben.
Fallbeispiel 1: Fehlende Dokumentation
Ich hatte ein Projekt, bei dem mir gesagt wurde, ich solle nichts dokumentieren, nur realisieren. Es ging dabei um eine relativ komplexe Middleware-Infrastruktur. Ich habe die Anforderungen erfolgreich umgesetzt. Irgendwann, vor dem GoLive, konnte noch etwas Budget freigeschaufelt werden und plötzlich sollte ich doch (nach 6 Monaten) meine Arbeit dokumentieren.
Ganz ehrlich, ohne eine Dokumentation, möchte ich nicht derjenige sein, der das System betreuen muss. Die Middleware bestand aus ABAP-Proxies, SAP PI, SOAP Adapter, SOAP-Web-Services, REST-Web-Services, LDAP etc. Eine Menge Fehlerquellen also, die nicht einheitlich gemonitored werden können. Zudem gab es keine Anforderungen bzgl. Logging/Tracing – es ging einfach darum, dass die Chose möglichst kostengünstig läuft. Ach ja, und das waren nur die rein technischen „Bedenken“, die mir bei diesem Auftrag im Kopf herumspukten – für den späteren Betrieb war auch die Kenntnis, was den da übertragen wurde wichtig!
Da es, wie gesagt, komplexe Anforderungen gab, konnte man nicht von einem „geraden“ Realisierungsweg ausgehen. Es wurde dies und jenes probiert, man hatte eine geniale Idee, etc. Natürlich merkt man sich nicht alles und nach 6 Monaten geht das eine oder andere verloren.
Fallbeispiel 2: Fehlendes Projektmanagement
Ich gebe zu, dass ich früher Projektmanagement für nicht unwichtig, aber auch nicht übermässig wichtig hielt – schließlich wird da nichts wirklich realisiert und oft haben die sog. Projektmanager von der eigentlichen Materie nicht viel Ahnung. Diese Meinung habe ich gründlich revidiert, nachdem ich mehrere Projekte ohne Projektmangement „durchlitten“ habe. Mittlerweile bin ich der Meinung, dass Projektmanagement absolut wichtig ist. Es ist aber auch wichtig, dass der Projektmanager, oder zumindest einer seine „Untergebenen“ technische Kenntnisse besitzen. Es ist zudem wichtig einen Projektplan zu haben und Meilensteine benennen zu könenn. Es ist auch wichtig Arbeitspakete zu schnüren und deren termingerechte Fertigstellung zu überwachen. Je nach Größe des Projektes muss das der Projektmanager oder seine Teamleiter als eine der wichtigsten Aufgaben realisieren.
Fallbeispiel 3: Mangelnde Skills der eigenen Mitarbeiter
Man spart wo man kann, das ist auch gut so, sofern es nicht der eigentlichen Zielsetzung und Unternehmensstrategie widerspricht. Man kann nicht ein Produkt als strategisch wichtig positionieren und von seinen Mitarbeiten verlangen, dass sie die notwendigen Skills von sich aus autodidaktisch erlernen. Das ist „Russisch Roulette“. Man kann natürlich damit Glück haben, aber für eine strategische Planung ist das ziemlich riskant. Die Ausbildung der Mitarbeiter sollte, falls noch nicht vorhanden, auf jeden Fall in das Budget mit eingeplant werden.
Man kann sich die beste (und meist auch teuerste) Software kaufen und customizen, wenn sie aber keiner warten und bedienen kann, bringt das nichts. Die Wartung muss von den eigenen Mitarbeitern sichergestellt oder zumindest koordiniert werden, sonst wird die Software auf Dauer unbezahlbar. Das heisst aber auch, dass die entsprechenden Skills im eigenen Unternehmen vorhanden sind.
Fallbeispiel 4: Überforderung der eingesetzen Software
Ich finde es immer wieder erstaunlich, was manche Kunden in die Middleware „packen“ wollen. Aus meiner fast 20 jährigen Erfahrung im Bereich Middleware kann ich nur sagen, lasst die Middleware mappen und routen, aber packt keine Applikationslogik hinein. Im Bereich SAP PI gibt es dafür die sog. BPE (Business Process Engine). Meine Erfahrung damit ist: langsam, kompliziert und nur schwer wartbar.
Wenn man die BPE gut kennt, kann man damit technisch viele tolle Sachen machen. Viel Spass beim nächsten Update der Software oder bei Änderungen im Prozess. Man braucht dann Jemanden der sich im Sender, im PI und im Empfänger auskennt. Das kostet, insbesondere dann, wenn man für einen oder mehrere Bereiche externe Firmen einsetzt. Da hatte jemand von Firma A eine geniale Idee, beim Update wird Firma B eingesetzt. Der Berater von Firma B braucht x Tage um zu verstehen, was sich der Berater von Firma A damals überlegt hat…
Man sollte die eingesetzte Software nicht „überfordern“, auch wenn die Hersteller von irgendwelchen übertriebenen Fähigkeiten schwärmen. Jede Software sollte das tun, wofür sie gedacht ist und nicht mehr! Auch, wenn sie das theoretisch könnte! Insbesondere im Bereich Middleware sollte die Software zur Übertragung, Anpassung (Mapping) und Weiterleitung(Routing) eingesetzt werden. Fachliche Feinheiten sollte man der Sender- bzw. Empfängerlogik überlassen. Dafür ist Middleware nicht wirklich vorgesehen.
Für die eingesetzte Software muss es auf Kundenseite, Experten geben, die die betrieblichen Eigenschaften der eingesetzten Software beherrschen. Schließlich will der Kunde die Software einsetzen und verspricht sich einen geschäftlichen Vorteil davon. Zudem geht es dabei meist um eine langanhaltende Betriebsdauer.
Fazit:
Geiz ist Scheiss !!!
RedEyeWatching 