IT sollte kein Selbstzweck und auch keine isolierte Insel im Unternehmen sein. Ihre Aufgabe ist es, mit möglichst kurzen Reaktionszeiten informationstechnische Strukturen aufzubauen und anzupassen, um alle zentralen Aspekte professioneller Betriebswirtschaft wie Performance-Management, Risikomanagement und Compliance-Anforderungen bestmöglich abzubilden und zu unterstützen. Wenn aber speziell das Zusammenspiel von betriebswirtschaftlichem Management und Unternehmens-IT zum dominanten Faktor für langfristigen Geschäftserfolg wird, stehen wir vor einigen entscheidenden Fragen:
• Wie lösen wir das Dilemma, dass Betriebswirtschaft und IT sich in weiten Teilen unversöhnlich wie 0 und 1 gegenüberstehen – in der Substanz ohne gemeinsame Sprache und mit unzureichenden Methoden, dafür belastet von Vorurteilen und Misstrauen?
• Wie schließen wir den „Results-Gap“ – jene Kluft zwischen der erhofften Effizienz und Produktivität von Geschäftsanwendungen und dem tatsächlichen Nutzen für die Anwender im Unternehmen.
• Wie schließen wir den IT-Gap? jene Lücke, die aus der langsamen Reaktionszeit der IT auf betriebswirtschaftliche Anforderungen entsteht: Bis zum Lieferzeitpunkt haben sich die Anforderungen an IT-Services und Applikationen schon substanziell weiterentwickelt. Was eine Lösung sein sollte, ist schon bei der Implementierung unzureichend, zum Teil veraltet, wirft neue Probleme auf und provoziert im Endeffekt Unzufriedenheit, mangelndes Vertrauen in die Leistungsfähigkeit der IT-Abteilung und langfristig auch hohe Kosten. Analysten wie Gartner schätzen, dass Unternehmen aktuell rund zwei Drittel der IT-Kosten in Maintenance statt in Neuinvestitionen und Zukunftssicherung investieren.
• Wie gelingt der Quantensprung der IT: Interoperabilität innerhalb der digitalen Welt und kurze Reaktionszeiten auf externe Einflüsse und Anforderungen? Dies betrifft insbesondere das betriebswirtschaftliche Management, die Berücksichtigung neuer gesetzgeberischer Herausforderungen wie Basel II oder Sarbanes Oxley und andere wesentliche Bestimmungsfaktoren sich rasant entwickelnder Märkte.
Stehen diese Fragen im Zusammenhang mit SOA? Ansichtssache, aber eine zukunftsweisende Geschäftsarchitektur muss sich diesen Fragen stellen und auch überzeugende Antworten geben!
Die IT dient den Geschäftsprozessen und soll diese in vollem Umfang unterstützen. Es muss eine Transparenz zwischen der IT und den Geschäftsprozessen geschaffen werden. Des weiteren muss die IT visualisiert dargestellt werden, um die richtigen Entscheidungen treffen zu können. KPIs, Balance Scorecard, SOA sind nur einige Bausteine die dazu verhelfen. SOA hilft die IT in Module zu packen, eine gewisse Kostentransparenz zu schaffen. SOA ist sicher keine direkt Antwort auf Basel II oder SOX, aber um dies abzubilden kann SOA unterstützen.
Sehr geehrte Frau Sondermann,
mit großem Interesse habe ich Ihren Beitrag – SOA, Sein oder Nichtsein – gelesen. Als selbstständiger Berater im Mainframe-Umfeld möchte ich mich gerne dazu äußern; ich denke, dass ich hier auch die Meinung vieler meiner Branchen-Kollegen vertrete. Sie fragen nach Antworten, bitte lassen Sie mich einige Antworten aus meiner Sicht dazu geben.
Ich möchte zunächst einmal Folgendes vorausschicken: ich bin zwar ein Mainframer aus Überzeugung, aber meiner Meinung nach ist die 3270 Klötzchen-Grafik absolut out! Ebenso das Look & Feel dieser veralteten Technologie. Hier hat IBM definitiv die Entwicklung verschlafen. Die Security und Verlässlichkeit (auf neudeutsch: reliability) eines Mainframe ist da schon was Anderes… die hätten andere Plattformen auch gerne.
Im Übrigen habe ich auch Java und WMQ und SOA gelernt, und jedes Jahr investiere ich mindestens drei Wochen in Fortbildung – not bad for a mainframer.
Ich bin SOA Mensch aus Überzeugung, weil ich meine, dass dies ein gangbarer Weg zu vernünftiger Wiederverwendbarkeit ist – aber bitte plattformübergreifend.
Zu den Punkten, die Sie in Ihrem Beitrag anführen.
„Wie lösen wir das Dilemma, dass sich Betriebswirtschaft und IT in weiten Teilen unversöhnlich gegenüber stehen“.
Es kann natürlich sein, dass ich eine branchenunübliche Sicht der Dinge habe. Aber meiner Meinung nach ist das einzig wichtige Kriterium der Benutzer, bzw. die Prozesse, die er ausführt. Danach muss sich die IT richten. Ich habe als IT’ler niemals der Betriebswirtschaft unversöhnlich gegenüber gestanden. Was Sie hier behaupten, ist – tut mir leid, es so hart sagen zu müssen – einfach eine infame Lüge, nichts weiter.
ICH möchte dem Benutzer auf dem Schoß sitzen, seinen Puls fühlen und herausfinden, wie er seine Arbeit – und die Prozesse – möglichst effizient ausführen kann. Das habe ich schon seit 1983, dem Jahr als ich in der IT tätig wurde, so gehalten. Dies hat sich seitdem nicht geändert. Auch hier spreche ich für viele meiner Kollegen. Das ist absolut nicht Neues.
Und nun raten Sie einmal, wohin uns das dabei moderne IT-Management führt. Wir dürfen mit dem Endkunden (Benutzer) nicht einmal mehr reden, Angebote werden nur vom so genannten Vertrieb an den Kunden gegeben, und der Endpreis macht NUR das acht bis zehnfache unserer Schätzung aus (JA, ich weiß natürlich auch, dass Gemeinkosten berechnet werden müssen…). Dass uns der Endkunde (manchmal sogar ziemlich direkt) fragt, ob wir wahnsinnig ob des geforderten Preises seien, dürfen/können wir auch nicht direkt beantworten… Mit dem weiteren kleinen Problem, dass der Kunde in einzelnen Fällen selbst nach sechs Wochen noch kein ordentliches Angebot auf dem Tisch hat… leider hat der Vertrieb nicht genug Kapazitäten…
Ist das noch IT-Business? Macht so modernes IT-Management Sinn? NEIN!
Bekommt man auf diese Weise Aufträge? Ebenfalls NEIN!
Nun die Frage nach „Results-Gap, IT-Gap“. Da darf ich wirklich nur müde lächeln. Es werden NEUE Systeme als die Allheilbringer verkauft, die alle Probleme lösen. Nach der ersten oder zweiten Terminverschiebung werden dann die Altsysteme gefragt, ob sie nicht dieses oder jenes Problem lösen könnten, weil die neuen Systeme das nicht können!!! Weil sie leider nicht wissen, wovon sie reden.
Natürlich können wir in die Bresche springen! Weil wir unser Geschäft beherrschen und wir wissen, wovon wir reden! Aber wenn wir den Endbenutzer oder Prozessdesigner nicht direkt fragen dürfen, können wir auch nie endgültig anforderungskonform sein!!!
Wieso haben sich zwischen Bestell- und Lieferzeitpunkt die Anforderungen weiterentwickelt? Das darf doch gerade wegen des iterativen Zyklus Spezifikation – Design – Entwicklung gar nicht mehr sein. Habe ich da etwa was falsch verstanden?
Könnte es etwa sein, dass die Betriebswirtschaft seine Anforderungen nicht zukunftsorientiert durchdacht hat? Kann es sein, dass man das auch nicht rechtzeitig zugegeben hat?
Hätte es sein können, dass man die Implementierung noch rechtzeitig hätte ändern können (hätte man nicht diese bescheuerten Vertragsgrundlagen gehabt, grummel)?
Aber was soll es: nur die ungenügende Organisation zwischen einzelnen Gesellschaften zwingt uns, einmal spezifizierte Lösungen als nicht veränderliche Vertragsgrundlage zu betrachten…
Darf ich Ihnen bezüglich Ihrer Fragen eine weitere (zugegeben subjektive) Antwort geben?
Vertrauen Sie den Menschen, die seit Dekaden Geschäftsprozesse in Anwendungen abgebildet haben! Mischen Sie diese mit Menschen, die neue Technologien beherrschen! Bringen Sie dann das Beste beider Welten zusammen! Sie werden sehen, die Jungen lernen von den Alten, und die Alten lernen von den Jungen! Gemeinsam werden sie eine Architektur beherrschen und realisieren, die einen wirklichen Fortschritt in der IT realisiert. Und meiner Meinung nach kann diese Architektur durchaus auch SOA heißen.
„Quantensprung der IT“???
Lassen Sie bitte die Beteiligten einmal als solche Menschen miteinander reden, die sie sind. In meinem betrachteten Fall Mainframe-Entwickler, die wirklich jede Menge Erfahrung mitbringen, und neue Entwickler, die die neuen Technologien mitbringen, aber nicht über die Prozess- und Projekterfahrung verfügen. Warum künstlich eine Konkurrenz schaffen, wenn eine Kooperation wesentlich mehr Erfolg im Sinne der Unternehmen hätte?
Wie heißt der alte Spruch: nur sprechenden Menschen kann geholfen werden! Warum sprechen Alt und Neu nicht miteinander??? Warum nur??? Ich verstehe es nicht!!!
Glauben Sie mir bitte Eines:
es gibt wesentlich mehr Menschen aus dem Bereich der Mainframes, die Objektorientierung verstanden haben, als umgekehrt (es wird nämlich kaum mehr unterrichtet…ätsch, wir haben da die Gnade der frühen Geburt)
Dementsprechend als Generalantwort auf all Ihre Fragen:
Reden wir darüber, und finden wir eine gemeinsame Lösung! Wir sind alle Menschen und durchaus konsensfähig. Ist das so schwer zu praktizieren?
Ich freue mich auf jede Menge zustimmende und nicht-zustimmende Kommentare und die anschließende Diskussion!
Mit freundlichem Gruß
Herbert Thümer, ht systemberatung GmbH
Übrigens:
wir haben in unserer Mainframe Anwendung seit vielen Jahren sogenannte Services implementiert , die Mainframe-Programme kapseln und der Umwelt zugänglich machen – lange bevor SOA der neue Hype war… Raten Sie doch einmal, wie groß der Aufwand wäre, unsere Anwendung in eine richtige SOA-Architektur zu überführen… Aber es macht niemand, da Alt-Systeme eben alt sind, und systema non grata…
Herr Thümer,lassen Sie sich gesagt sein,dass es Menschen gibt,die sehr ähnlich denken wie Sie.Allerdings sehe ich die Art Unversöhnlichkeit von IT oder Technik allgemein und BWL schon noch.Meines Erachtens ist das historisch begründet.Die Herleitung wäre allerdings ein bißchen lang hier.Aufgrund meiner Erfahrung ist ein guter ITler,der auf dem Stand der Technik ist (aber eben kein Fachidiot,sorry) schneller in der Lage die Welt eines BWLers zu durchdringen als umgekehrt.Frau Sondermann gibt sich die Antworten im Grunde selbst: Denn was eine IT-Abteilung tut,darüber entscheidet meist das betriebswirtschafliche Management oder das Management überhaupt.Wenn Gelder also überwiegend in Erhaltung/Wartung fließen,so kann sich das Management über seine eigenen Entscheidungen beschweren,aber nicht über die eigene nicht zukunftsfähige IT,die können meist besser,wenn man sie lassen würde.Also da sollte man die Kirche im Dorf lassen.