Integration führt zu Koexistenz

Wenn es viele Lösungsmöglichkeiten gibt, gilt es also zu erkennen, welche das sind und eine Entschei-dung für die eine oder die andere Lösung zu treffen. Auf technischer Seite z. B., ob eine neue Technologie einge-führt wird oder man die vorhandene nur soweit anpasst, dass es ausreichend ist. Kann man an dieser Stelle einige notwendige Kriterien benennen?

Krause: Ein Kriterium ist sicher die Anforderung an die Kompetenzen der beteiligten Perso-nen. Derjenige, der die IT-Lösung vorschlägt, muss selbstverständlich im IT-Bereich stark sein, aber er muss auch wissen, wie das Business funktioniert. Ein IT-Spezialist sollte nicht meinen, er könne eine Bankapplikation entwickeln, wenn er nicht weiß, wie eine Bank funktioniert. Da kann er ein noch so versierter Java-Crack sein, er wird trotzdem nichts Vernünftiges hinbekommen. Wir haben die Erfahrung gemacht, dass die besten Lösun-gen resultierten, wenn das Business sein Fachwissen einbrachte und die IT die Methodik. Das Business war dankbar für die Methodik und die IT für den fachlichen Input.

Wie lange braucht der Prozess, bis dieses Zusammenspiel von wechselseitigem Einbringen und Aufnehmen funktioniert?

Krause: Von Nanosekunden bis Jahre! Im Ernst, es ist ganz einfach abhängig von den invol-vierten Personen. Wenn Sie z. B. eine Börsenapplikation entwickeln wollen, ist nicht zwingend der erfolgreichs-te Händler der ideale Gesprächspartner für diese Fragen. Dieser weiß sehr oft nicht, warum er etwas macht und kann es auch nicht zum Ausdruck bringen. Es kann sein, dass einer, der nicht der Beste ist im effektiven Busi-ness, oft besser die wesentlichen Punkte herausarbeiten kann. Das Profil des idealen Businessvertreters ist hier schwierig zu formulieren.

Aber die Frage, wie lange es dauert, lässt sich aus der Erfahrung doch gut beantworten. Wenn es länger als einen halben Tag dauert, bis die Parteien sich gefunden haben, sind die falschen Leute zusammen. Das ist die einfache Konsequenz. Dann hat es auch keinen Sinn mehr, die Mitarbeiter in ein Teambildungsseminar zu schi-cken, mit River Rafting oder Modellierungsworkshops, denn diese Seminare können in diesem Fall auch nicht helfen. Entweder die Parteien finden sich in relativ kurzer Zeit oder es geht eben nicht. Das ist keine Aussage zur generellen Qualifikation des einen oder des andern Mitarbeiters. Wenn die persönliche Chemie der Beteilig-ten nicht stimmt, dann kommen sie als Team auf keinen grünen Zweig.

Wir haben jetzt das Feld grob abgesteckt, aber wenn nun ein Integrationsprojekt ins Laufen gekommen ist, welche der beiden Seiten muss mehr Geduld mitbringen und warum?

Krause: Ich nehme an, das Business. Das liegt am Verhältnis von Skizze zu schwerem Bauge-rät. Als Bauherr eines Gebäudes mache ich in zwei, drei Stunden eine Bleistiftskizze und habe dann schon mein Bauprojekt gezeichnet. Jetzt kommt die Arbeit der Baufachleute. Es müssen Pläne gezeichnet werden, Bewilli-gungen sind einzuholen, Berechnungen sind anzustellen und last but not least ist abzuklären, ob nicht doch noch etwas fehlt, und dann muss noch gebaut werden. So braucht auch die IT Zeit, um die Systeme zu planen und zu realisieren. Wenn ich in meinem Garten ein neues Blumenbeet anlegen will, dann nehme ich einen Spa-ten in die Hand, grabe um und in kurzer Zeit habe ich mein Blumenbeet. Wenn ich aber ein Biotop mit Teich anlegen will, kann das wirklich lange dauern, wahrscheinlich mehrere Tage, wenn ich selbst mit der Schaufel arbeite. Wenn aber schweres Gerät aufgefahren wird, geht es viel schneller, aber die Organisation und Bereit-stellung der Geräte dauert eine Weile.

Wenn ein Antikschreiner eine Rechnung für einen Schrank schreiben will, dann geht das per Hand am schnellsten. Wenn aber ein großes Möbelhaus tausende Tische, Schränke und Küchen fertigt und dafür Rech-nungen schreiben muss, dann lohnt sich sicher der IT-Einsatz. Das Erstellen der Rechnung ist in beiden Fällen prinzipiell das Gleiche. Und dennoch, bis die IT das umgesetzt hat und Rechnungen erstellt werden können, dauert es eine Weile. Für die Realisierung dieses Projekts braucht es mehr als nur Kugelschreiber und Papier. Darum braucht das Business sicher mehr Geduld.

Wenn es um Zeit geht, dann geht es auch um Geld. Die Frage ist immer, ob und wenn ja ab wann sich eine Integration lohnt. Kann oder muss man hier aus der Perspektive des Architekten manchmal auch sagen, dass eine Idee – so gut sie auch sein mag – sich auch aus Zeitgründen nicht lohnt?

Krause: Für jedes Projekt sollte vorgängig eine Zeit- und Kostenschätzung gemacht wer-den. Wir hatten beispielsweise einmal ein Projekt in einem Unternehmen der Investitionsgüterindustrie mit rund 600 Mitarbeitern und rund 30 Verkäufern. Der Unternehmer wollte eine IT-Applikation, um die Provi-sionen dieser Verkäufer zu berechnen. Das Ergebnis unserer Schätzung war, dass man für die Umsetzung rund zwei Jahre bräuchte und die Kosten sich auf vier Personenjahre belaufen würden. Weiter war bekannt, dass jedes Jahr die Basis der Provisionsberechnung umgestellt wurde. Das Projekt wäre also erst fertig ge-worden, nachdem die Anforderungen schon wieder geändert worden wären. Dann wurde der Aufwand von vier Personenjahren mit der Zeit und den Kosten gegengerechnet, die es braucht, die Provisionen manuell auszurechnen. Die Provisionsabrechnung manuell zu erstellen, dauert sicher länger, ist aber am Ende günsti-ger und den jeweils aktuellen Vorgaben entsprechend. Daraufhin hat man von der Einbindung der Provisi-onsberechnung in die IT Abstand genommen und es wurden nur die Ergänzungen gemacht, die nötig waren, um das Ergebnis der manuellen Berechnung in die Lohnabrechnung einzufügen.

Es gehört zur Rolle des Architekten, auch mal zu sagen, dass ein Projekt nicht sinnvoll ist. Im Bankenbe-reich hat man diesen Fall vor allem bei strukturierten Produkten, die schnell auf den Markt kommen müssen und die ebenso schnell wieder verschwinden. Da kann es sein, dass z. B. ein Derivat schon nach einem Viertel- oder halben Jahr nicht mehr gebraucht wird. Solche Anforderungen können dann zum Teil mit Excel oder Ac-cess realisiert werden und so die Lösung mit einer sicherlich mangelhaften Integration in das restliche Umfeld der Bank möglich machen. Natürlich sind bei solchen Lösungen Sicherheit und Skalierbarkeit ein großes Prob-lem. Die Schwierigkeit hier ist aber vor allem, dass ich diese kleinen Provisorien auch wieder aus dem System entfernen kann, sobald sie nicht mehr gebraucht werden. Trotzdem kann sich so eine Lösung unter Umständen rechnen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.