Schlagwort: Kernbanksystem

ITIL Zauberkessel

ITIL – Zaubermittel eines regulatorikkonformen Multiprovidermanagements?

Aus der Sicht des IT-Manage­ments bringt ITIL eine not­wen­di­ge Zutat mit, die für ein „Zau­ber­mit­tel“ uner­läss­lich ist – das not­wen­di­ge Alter mit einem ent­spre­chen­den Rei­fe­grad. Hier­bei darf jedoch nicht ver­kannt wer­den, dass ITIL von sei­nem Ursprung Ende der 80er Jah­re bis heu­te eine erheb­li­che Wei­ter­ent­wick­lung durch­lau­fen hat.

Ursprüng­lich bestand die Neu­ar­tig­keit von ITIL in der IT dar­in, auf die Erfor­der­nis­se der Kun­den aus­ge­rich­tet zu sein. Effek­ti­ve Pro­zes­se und klar zuge­ord­ne­te Ver­ant­wort­lich­kei­ten stan­den im Fokus. Ers­te Wei­ter­ent­wick­lun­gen ergänz­ten wei­te­re Pro­zes­se, bis in einer grund­le­gen­den Über­ar­bei­tung der Ser­vice Life­Cy­cle in den Mit­tel­punkt rück­te. Hier­bei wur­den wei­te­re Pro­zes­se ergänzt und die Ziel­set­zung von ITIL der­ge­stalt geschärft, dass eine mess­ba­re, posi­ti­ve Wert­schöp­fung für den Kun­den im Fokus steht und die­se einen rele­van­ten Mehr­wert für das Unter­neh­men schafft. Schwer­punk­te der wei­te­ren Ent­wick­lungs­schrit­te zur aktu­el­len Ver­si­on ITIL 4 waren neue Tech­no­lo­gien und das Ser­vice-Manage­ment, die ein­ge­bun­den wur­den in das ITIL Ser­vice Value Sys­tem (SVS).

Neben dem SVS erfolg­te im Kon­text des Ser­vice-Manage­ments die Über­füh­rung der bestehen­den 4 Ps von ITIL (Perso­nen, Produk­te, Part­ner und Prozes­se) in ein Modell mit vier Dimen­sio­nen, die über die ursprüng­li­chen 4 Ps hinausgehen:

  • Orga­ni­sa­tio­nen und Menschen
  • Infor­ma­tio­nen und Technologie
  • Part­ner und Lieferanten
  • Wert­strö­me und Prozesse

Auf die­se Wei­se hat ITIL in den ver­gan­ge­nen 35 Jah­ren sei­nen Best-Prac­ti­ce-Cha­rak­ter stets an den aktu­el­len Ver­än­de­run­gen und Gege­ben­hei­ten des IT-Manage­ments ausgerichtet.

Die Ver­än­de­rung der IT in Ban­ken und die Wei­ter­ent­wick­lung der Best Prac­ti­ces von ITIL ver­lie­fen zeit­lich und inhalt­lich viel­fach im Gleich­klang. Für die Ban­ken-IT war die­se gemein­sa­me Ent­wick­lung essen­zi­ell. Ver­ant­wort­lich dafür sind vor Allem vier Trends:

  • Ohne IT sind Bank­dienst­leis­tun­gen kaum noch zu erbringen
  • Die tech­ni­sche Kom­ple­xi­tät und Hete­ro­ge­ni­tät sind erheb­lich angewachsen
  • IT-Pro­zes­se sind durch ein unter­neh­mens­über­grei­fen­des Wert­schöp­fungs­netz­werk gekennzeichnet
  • Der Bedeu­tung ent­spre­chend sind die regu­la­to­ri­schen Anfor­de­run­gen an die Bank-IT erheb­lich gestiegen

Der ers­te Punkt ist ein­fach nach­zu­voll­zie­hen. Die wei­te­ren drei Punk­te sind stark mit­ein­an­der ver­zahnt. So führ­te die wach­sen­de Kom­ple­xi­tät und Hete­ro­ge­ni­tät der Bank-IT viel­fach dazu, dass wesent­li­che Tei­le an spe­zia­li­sier­te Dienst­leis­tungs­part­ner aus­ge­glie­dert wur­den. Bei­spiel­haft sei­en hier der Desk­top Ser­vice, der Betrieb von Kern­bank­sys­te­men, die Bereit­stel­lung von Cloud-Ser­vices sowie spe­zi­fi­sche IT-Secu­ri­ty-Leis­tun­gen genannt.

Die Steue­rung des sich dar­aus erge­ben­den Wert­schöp­fungs­netz­wer­kes aus inter­nen und extern erbrach­ten Leis­tun­gen und Pro­zess­an­tei­len ist aktu­ell domi­nie­ren­de Kern­auf­ga­be der IT Deut­scher Ban­ken. Auch den für Regu­la­to­rik von Ban­ken zustän­di­gen Instan­zen in Euro­pa und Deutsch­land (z. B. EBA, EZB, Bun­des­bank) ist die­ses bewusst. In der Kon­se­quenz wer­den die regu­la­to­ri­schen Anfor­de­run­gen an die IT in Ban­ken in immer kür­ze­ren Abstän­den in Brei­te und Tie­fe aus­ge­baut. Für die Aus­la­ge­rung von IT-Leis­tun­gen der Ban­ken an Dienst­leis­tungs­part­ner gel­ten gleich eine Viel­zahl, sich in Tei­len über­schnei­den­de, regu­la­to­ri­sche Anfor­de­run­gen. Nach­ste­hen­de Dar­stel­lung ver­deut­licht dieses:

© 2023 bankon

Die Her­aus­for­de­rung für die Bank-IT ist damit defi­niert. Das Wert­schöp­fungs­netz­werk der IT-Pro­zes­se ist effi­zi­ent und kon­form zu regu­la­to­ri­schen Anfor­de­run­gen zu gestal­ten und zu steu­ern. Eine aus­schließ­lich pro­vi­der­ori­en­tier­te Struk­tu­rie­rung ist hier­für nicht ziel­füh­rend. Zum einen ent­spricht die­se mehr­heit­lich nicht der aktu­el­len Situa­ti­on des Aus­la­ge­rungs­port­fo­li­os der Ban­ken, zum ande­ren gestat­tet sie nur wenig Fle­xi­bi­li­tät für eine pro­vi­der­un­ab­hän­gi­ge Erwei­te­rung des Serviceportfolios.

Es wird deut­lich, dass hier nur ein ganz­heit­li­cher Ansatz mit­tels mit End-to-End-Aus­rich­tung zur Lösung bei­tra­gen kann. Wel­che Rol­le kann ITIL hier­bei spie­len, und wel­che Lösun­gen kann ITIL anbieten?

Durch die sys­te­ma­ti­sche Wei­ter­ent­wick­lung unter­stützt ITIL spe­zi­fi­sche IT-Manage­ment-Pro­zes­se, bie­tet aber auch pro­zess- und ser­vice­über­grei­fen­de Steue­rungs­an­sät­ze über das gesam­te IT-Uni­ver­sum der Bank. Die­ses schließt auch Leis­tun­gen ein, die durch Drit­te erbracht werden.

Mit­tels ITIL kann die erfor­der­li­che Trans­pa­renz geschaf­fen wer­den, die der Bank eine regu­la­to­rik­kon­for­me und effi­zi­en­te Steue­rung der Gesamt-IT ermög­licht. Unter­stüt­zung bie­tet hier­bei die Manage­ment-Metho­dik des Ser­vice Inte­gra­ti­on and Manage­ment, kurz SIAM.

© 2023 bankon

SIAM ist nicht Inhalt von ITIL, son­dern ist aus­ge­legt auf die Steue­rung mul­ti­pler Pro­vi­der­struk­tu­ren, nutzt hier­zu aber die Kon­zep­te zum IT Ser­vice Manage­ment aus ITIL. Die Struk­tu­ren eines SIAM füh­ren in einem Mul­ti­pro­vi­der­ma­nage­ment die Geschäfts­pro­zes­se und die für ihre Leis­tungs­er­brin­gung erfor­der­li­chen IT-Ser­vices zusam­men. Sei­tens der IT bereit­ge­stell­te Ser­vices umfas­sen hier­bei pro­vi­der­über­grei­fend sowohl Infra­struk­tur­kom­po­nen­ten, Netz­werk­kom­mu­ni­ka­ti­on, Daten­hal­tung, IT-Anwen­dun­gen/Ap­pli­ka­tio­nen als auch deren Bereit­stel­lung am Arbeits­platz. Ent­stan­den ist SIAM im Jahr 2012 mit Erschei­nen des XGOV Stra­te­gic SIAM refe­rence set der bri­ti­schen Regie­rung und basiert auf einem Best Prac­ti­ce-ori­en­tier­ten Vorgehen.

Wel­che Gestal­tungs­fel­der für eine Ser­vice­inte­gra­ti­on und ein Ser­vice­ma­nage­ment erge­ben sich dar­aus für die Bank, die im Rah­men der Ein­füh­rung zu berück­sich­ti­gen sind? Die fol­gen­de Abbil­dung skiz­ziert die aus unse­rer Sicht rele­van­ten Felder:

© 2023 bankon

I. Strategie

Das pro­vi­der­über­grei­fen­de, inte­gra­ti­ve Manage­ment der IT-Ser­vices ist not­wen­di­ger­wei­se Bestand­teil der IT Stra­te­gie sowie der dar­un­ter­lie­gen­den Aus­prä­gun­gen z. B. einer Sourcing- oder Cloud Stra­te­gie. Die­ses ist auf­grund der Aus­rich­tung der IT-Ser­vices auf die Geschäfts­pro­zes­se erfor­der­lich, da die IT-Stra­te­gie die Ver­knüp­fung zur Geschäfts­stra­te­gie bildet.

II. Organisation

Wesent­li­cher Fokus ist hier das Sco­ping und damit die Iden­ti­fi­ka­ti­on der rele­van­ten IT-Ser­vices. Hier­bei sind Busi­ness- und Infra­struk­tur­per­spek­ti­ve mit­ein­an­der zu ver­bin­den. Die orga­ni­sa­to­ri­sche Ver­an­ke­rung des inte­grier­ten Mul­ti­pro­vi­der­ma­nage­ments geschieht über spe­zi­fi­sche Rol­len, die mit dem bestehen­den Rol­len­mo­dell zu ver­knüp­fen sind. Mit die­sen Rol­len ein­her­ge­hen­de Auf­ga­ben wer­den ver­ant­wort­li­chen Per­so­nen zuge­ord­net. Die­ses Vor­ge­hen ver­bin­det Rol­len, Ver­ant­wort­lich­kei­ten und Auf­ga­ben in einer Matrix, wel­che wesent­li­che Grund­la­ge für die quan­ti­ta­ti­ve Per­so­nal­pla­nung ist.

III. Prozesse

Wesent­li­ches Ele­ment ist die pro­vi­der­über­grei­fen­de Orches­trie­rung der IT-Ser­vice­pro­zes­se im Sin­ne eines End-to-End-Gedan­kens. Sie ist Vor­aus­set­zung einer Unter­stüt­zung die­ser Pro­zes­se mit­tels eta­blier­ter IT-Manage­ment­pro­zes­se wie Incident‑, Pro­blem- oder Chan­ge-Manage­ment. Ent­spre­chend der Kri­ti­k­ali­tät der Pro­zes­se sind Report­ing- und Kon­troll­ver­fah­ren zu eta­blie­ren, die durch geeig­ne­te KPIs unter­legt wer­den müssen.

IV. Tools

Erfolgs­kri­tisch ist in ers­ter Linie die Ver­füg­bar­keit der für die IT-Ser­vice­pro­zes­se End-to-End erfor­der­li­chen Infor­ma­tio­nen. Die­se müs­sen an einer zen­tra­len Stel­le gebün­delt sein, an die jeder Pro­vi­der sei­ne Daten zulie­fert und aktu­ell hält. Die­ser Daten­pool wird im Rah­men der IT-Manage­ment­pro­zes­se genutzt und ist Basis für eine work­flow­or­i­en­tier­te Pro­zess­be­ar­bei­tung unter Ein­bin­dung der Pro­vi­der. Hier­für bie­tet es sich an, eine markt­gän­gi­ge Platt­form zu ver­wen­den, die sowohl die Daten­hal­tung als auch die pro­zes­sua­len Work­flows unter­stützt. Offe­ne Stan­dard­schnitt­stel­len ermög­li­chen die fle­xi­ble Ein­bin­dung wei­te­rer Pro­vi­der und Assets. 

V. Verträge

Idea­ler­wei­se sind die Ver­trags­in­for­ma­tio­nen in der obi­gen Platt­form hin­ter­legt und ste­hen als Infor­ma­ti­on zur Ver­fü­gung. Neben dem Infor­ma­ti­ons­cha­rak­ter ist jedoch vor allem sicher­zu­stel­len, dass die für ein Mul­ti­pro­vi­der­ma­nage­ment erfor­der­li­chen tech­ni­schen, pro­zes­sua­len und regu­la­to­ri­schen Sach­ver­hal­te Inhalt der Ver­trags­wer­ke von Bank und Pro­vi­der sind. Beson­ders sei an die­ser Stel­le dar­auf hin­ge­wie­sen, dass ein fle­xi­bles Mul­ti­pro­vi­der­ma­nage­ment nicht nur ein Onboar­ding von Leis­tun­gen des Pro­vi­ders erfor­dert, son­dern auch die Häu­fig­keit eines Off­boar­ding erhöht ist. Dafür erfor­der­li­che Exit-Ver­ein­ba­run­gen sind aus die­sem Grund eine Kom­po­nen­te, die ver­trag­lich gere­gelt sein muss.

Bie­tet ITIL nun das Wun­der­mit­tel für ein regu­la­to­rik­kon­for­mes Pro­vi­der­ma­nage­ment, gege­be­nen­falls unter Hin­zu­fü­gen einer „Pri­se“ SIAM?

Obi­ge Aus­füh­run­gen machen deut­lich: Der Zau­ber­trank für ein regu­la­to­rik­kon­for­mes Mul­ti­pro­vi­der­ma­nage­ment ist ITIL nicht. Aber ITIL ent­hält die dafür erfor­der­li­chen Zuta­ten. Die­se sind in der IT der Bank unter Zusam­men­wir­ken mit wei­te­ren rele­van­ten Stake­hol­dern wie z. B. Ein­kauf oder Com­pli­ance zusam­men­zu­stel­len und mit erfor­der­li­chen Tools zu eta­blie­ren. ITIL bil­det eine Art Rezept­buch und wird damit sei­nem Best-Prac­ti­ce-Ansatz gerecht. Die Bank hat aber ent­spre­chend der indi­vi­du­el­len Aus­gangs­si­tua­ti­on aus IT-Kom­ple­xi­tät, End-to-End-Rei­fe­grad der IT-Pro­zes­se, Aus­ge­stal­tung des IT-Aus­la­ge­rungs­port­fo­li­os sowie regu­la­to­ri­schem Sta­tus quo das Mul­ti­pro­vi­der­ma­nage­ment aus­zu­ge­stal­ten. Hier unter­stützt der Manage­ment­an­satz SIAM und bie­tet Hil­fe­stel­lung in der bedarfs­ge­rech­ten Kon­zep­ti­on und Etablierung.

Exper­ti­se ban­kon Manage­ment Consulting

Die Exper­ti­se der ban­kon-Bera­ter aus mehr als fünf­zehn Jah­ren Erfah­rung mit Pro­jek­ten im Kon­text IT-Manage­ment (ITIL), Pro­vi­der­ma­nage­ment, IT-Ser­vices sichert pra­xis­er­prob­tes Wis­sen. Umfang­rei­che Kennt­nis von Orga­ni­sa­ti­ons- und Pro­vi­der­struk­tu­ren, Pro­zes­sen und IT-Sys­te­men deut­scher Ban­ken und Spar­kas­sen gewähr­leis­ten den erfor­der­li­chen fach­li­chen und tech­ni­schen Hintergrund.

Erfah­run­gen aus der Vor­be­rei­tung, Beglei­tung und Nach­be­rei­tung von Prü­fun­gen der Ban­ken­auf­sicht ergän­zen die­se Pra­xis­er­fah­rung um regu­la­to­ri­sche Kompetenz.

Nut­zen Sie unse­re umfang­rei­chen Erfah­run­gen und spre­chen Sie mit uns:

ban­kon Manage­ment Con­sul­ting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://​www​.ban​kon​.de
E‑Mail: research@bankon.de


Transformationsprojekte in Banken – agil gedacht, hybrid gemacht

Die von innen und außen gestell­ten Anfor­de­run­gen an Pro­jek­te in Ban­ken ken­nen eigent­lich nur eine Rich­tung – „von allem mehr“:

  • Mehr Kom­ple­xi­tät
  • Mehr Zeit­druck
  • Mehr Kos­ten und auch Zwang zu mehr Kosteneinsparung
  • Mehr regu­la­to­ri­sche Rahmenbedingungen
  • Mehr Vola­ti­li­tät des Anforderungsportfolios

Eine Hand­ha­bung die­ser Anfor­de­run­gen mit den bewähr­ten, „tra­di­tio­nel­len“ Pro­jekt­ma­nage­ment­me­tho­den ist kei­ne Opti­on, da die­se hier an ihre Gren­zen sto­ßen und in Tei­len dar­über hinausgehen.

Ziel­set­zun­gen

Gera­de bei Trans­for­ma­ti­ons­pro­jek­ten (z. B. Ein­füh­rung Kern­bank­sys­te­me, Neu­struk­tu­rie­rung Geschäfts­fel­der, Umset­zung regu­la­to­ri­scher Anfor­de­run­gen), die durch lan­ge Pro­jekt­zeit­räu­me gekenn­zeich­net sind, steht die Welt nicht still, son­dern das Anfor­de­rungs­port­fo­lio ist im Zeit­ab­lauf regel­mä­ßig intern oder extern indu­zier­ten Anpas­sun­gen unter­wor­fen. Vor die­sem Hin­ter­grund sind das Anfor­de­rungs­ma­nage­ment sowie die Pro­jekt­steue­rung die wich­tigs­ten inhalt­li­chen und metho­di­schen Gestal­tungs­fel­der zur Sicher­stel­lung des Projekterfolgs.

Transformationsprojekte in Banken

Die­se bei­den Gestal­tungs­fel­der sind an den spe­zi­fi­schen Rah­men­be­din­gun­gen aus­zu­rich­ten. Ein „One fits all“ kann es nicht geben. Fol­gen­de vier Hand­lungs­fel­der sind zu berücksichtigen:

  • Varia­bi­li­tät des Pro­jekt­um­fangs (wie klar und fest­ge­fügt ist zu Beginn des Pro­jek­tes Umfang und Aus­prä­gung des ange­streb­ten Zielportfolios?)
  • Unter­neh­mens­kul­tur (wie hier­ar­chisch oder dyna­misch ist die Bank unab­hän­gig von Pro­jek­ten in ihrem Auf­bau und ihren Abläufen?)
  • Pro­jekt­kul­tur (wel­che Bedeu­tung haben Pro­jekt­struk­tu­ren in der Leis­tungs­er­brin­gung und wie stark wer­den Ver­än­de­run­gen aus Pro­jek­ten her­aus initiiert?)
  • Inter­ne Res­sour­cen und Skills (wie ist die Situa­ti­on hin­sicht­lich Quan­ti­tät und Qua­li­tät inter­ner Spe­zia­lis­tin­nen und Spe­zia­lis­ten auch im Ver­hält­nis zu exter­nen Dienstleistern?)

Im Kon­text die­ser Hand­lungs­fel­der sowie der spe­zi­fi­schen Pro­jekt­ziel­set­zung das geeig­nets­te Pro­jekt­vor­ge­hen zu wäh­len, ist von essen­zi­el­ler Bedeu­tung für den Projekterfolg.

Vor­ge­hens­op­tio­nen

In Trans­for­ma­ti­ons­pro­jek­ten von Ban­ken ist auf­grund ihrer Zeit­dau­er das „tra­di­tio­nel­le“ Pro­jekt­ma­nage­ment im Was­ser­fall in der Bewäl­ti­gung der Pro­jekt­an­for­de­run­gen nicht emp­feh­lens­wert. Eine rein agi­le Vor­ge­hens­wei­se mit­tels Scrum ist für Trans­for­ma­ti­ons­pro­jek­te auf­grund ihrer Grö­ße und Kom­ple­xi­tät eben­falls kei­ne Opti­on. Die Aus­rich­tung an agi­len Ver­fah­ren für das Manage­ment gro­ßer Pro­jek­te, z. B. mit­tels SAFe ist gera­de in den hier betrach­te­ten Pro­jek­ten ein denk­ba­rer Ansatz. Die metho­di­sche Kom­ple­xi­tät der­ar­ti­ger Ansät­ze darf hier­bei jedoch nicht außer Acht gelas­sen werden. 

Transformationsprojekte in Banken

Sinn­voll ist es vor die­sem Hin­ter­grund, Pro­jekt­kon­text und unter­neh­mens­in­di­vi­du­el­le Situa­ti­on für die Wahl des Vor­ge­hens her­an­zu­zie­hen. Im Ergeb­nis erge­ben sich dar­aus hybri­de Vor­ge­hens­op­tio­nen, die ähn­lich eines Metho­den­bau­kas­ten für die kon­kre­te Situa­ti­on aus­ge­wählt wer­den können.

Hand­lungs­emp­feh­lun­gen aus der Praxis

In den von ban­kon ver­ant­wor­te­ten Trans­for­ma­ti­ons­pro­jek­ten hat es sich bewährt, genau die­se situa­ti­ons­in­di­vi­du­el­len Aspek­te für die Aus­ge­stal­tung des Pro­jekt­vor­ge­hens zu berück­sich­ti­gen. Hier­aus ent­steht eine spe­zi­fi­sche Indi­vi­dua­li­sie­rung des Vor­ge­hens unter Nut­zung von Metho­den­bau­stei­nen. Fol­gen­de Dar­stel­lung illus­triert den „Ein­stieg“ in das hier­für von ban­kon ent­wi­ckel­te Ana­ly­se­werk­zeug mit der Ermitt­lung des unter­neh­mens­in­di­vi­du­el­len Agi­li­täts­scores. Spe­zi­fi­sche Pro­jekt­in­hal­te kön­nen durch eine ergän­zen­de Gewich­tung der Hand­lungs­fel­der Berück­sich­ti­gung erfahren. 

Transformationsprojekte in Banken

Eine „metho­den­rei­ne“ Vor­ge­hens­wei­se ist in Trans­for­ma­ti­ons­pro­jek­ten schon auf­grund der Kom­ple­xi­tät von Anfor­de­run­gen und Struk­tur in der Regel kun­den­sei­tig nicht anzu­tref­fen und zur Ziel­er­rei­chung auch nicht zu empfehlen.

Viel­mehr ist es sinn­voll, Pro­jekt­in­di­vi­du­ell und abhän­gig vom ermit­tel­ten Agi­li­täts­score metho­di­sche Bau­stei­ne ein­zu­fü­gen, mit denen der pro­jekt­spe­zi­fi­sche Hybridan­satz aus­ge­stal­tet wird.

  • Klas­si­sches Pro­jekt­um­feld mit nied­ri­gem Agilitätsscore:

In Unter­neh­men mit einem nied­ri­gen Agi­li­täts­score und einem klas­si­schen Pro­jekt­um­feld ist es emp­feh­lens­wert, agi­le Ele­men­te berei­chernd neben die klas­si­schen Struk­tu­ren zu stel­len. Es kann sich sogar anbie­ten, bei­de Struk­tu­ren an Punk­ten wie einem gemein­sa­men Back­log zusam­men­zu­füh­ren. Sinn­voll ist eine Auf­split­tung in Kom­po­nen­ten, die auf­grund ihrer inhalt­li­chen Deter­mi­niert­heit eher fixen Cha­rak­ter haben und wei­ter­hin klas­sisch bear­bei­tet wer­den und sol­che, die auf­grund Unsi­cher­hei­ten zum ange­streb­ten Ziel sinn­vol­ler­wei­se agil bear­bei­tet wer­den kön­nen. Fol­gen­de agi­le Metho­den bie­ten sich für eine Nut­zung in die­sem Pro­jekt­um­feld an:

  • Pro­jekt­wei­ter Back­log mit der Mög­lich­keit, Sprint­back­logs für agi­le Pro­jekt­ele­men­te zu extra­hie­ren und zu bearbeiten
  • Eta­blie­rung von Dai­ly-Scrums zur För­de­rung der Ver­net­zung zwi­schen den Pro­jekt­teilen und dem Manage­ment von Abhängigkeiten
  • Der Ein­satz von Kan­ban-Boards zur Unter­stüt­zung der Kommunikation
  • Ein­füh­rung von Ver­fah­ren des Reviews und der Retro­spek­ti­ve, um die Orches­trie­rung und Ziel­fo­kus­sie­rung der ein­zel­nen Pro­jekt­strän­ge zu fördern
  • Rol­le eines Pro­duct Owners als fachlich/technologische Evi­denz- und Kon­sis­tenz­stel­le etablieren

Die oben genann­ten agi­len Ele­men­te schaf­fen eine Klam­mer­funk­ti­on zwi­schen den in agi­ler und klas­si­scher Form auf­ge­setz­ten Pro­jekt­be­stand­tei­len. Sie eta­blie­ren ein gemein­sa­mes Ver­ständ­nis und zah­len in eine Ver­bes­se­rung des Agi­li­täts­scores ein. Dadurch wer­den die zukünf­ti­gen Mög­lich­kei­ten zum Ein­satz agi­ler Metho­di­ken im Pro­jekt deut­lich verbessert.

  • Agi­les Pro­jekt­um­feld mit hohem Agilitätsscore:

In Unter­neh­men mit einem hohen Agi­li­täts­score und einem agi­len Pro­jekt­um­feld ist das Zusam­men­wir­ken der ein­zel­nen agi­len Pro­jek­te im Hin­blick auf Zie­le oder die Nut­zung per­so­nel­ler und tech­ni­scher Res­sour­cen sicher­zu­stel­len. Dar­über hin­aus sind lang­fris­ti­ge Aus­rich­tun­gen und das Errei­chen stra­te­gi­scher Zie­le zu gewähr­leis­ten, was in der agi­len, sprint­ori­en­tier­ten Vor­ge­hens­wei­se durch die kur­ze Zeit­dau­er von Sprints und der häu­fig vor­herr­schen­den zeit­li­chen Limi­tie­rung des Pla­nungs­ho­ri­zonts auf Halb­jah­re oder Quar­ta­le nicht immer gege­ben ist. Metho­disch wer­den die­se Aspek­te in der Regel in ska­lier­ten agi­len Vor­ge­hens­for­men, z. B. SAFe berück­sich­tigt, in der Pra­xis aber nicht immer gelebt. Erfah­run­gen von ban­kon zeig­ten, dass durch die Ein­bin­dung aus­ge­wähl­ter klas­si­scher Pro­jekt­ma­nage­ment­bau­stei­ne in das agi­le Vor­ge­hen die­se Schwä­chen kom­pen­siert wer­den kön­nen, ohne den agi­len Cha­rak­ter zu beein­träch­ti­gen. Aus der Pra­xis­er­fah­rung von ban­kon bie­ten sich für eine Nut­zung in die­sem Pro­jekt­um­feld an:

  • Ver­knüp­fung the­men­spe­zi­fi­scher Back­logs mit einem über­grei­fen­den Anfor­de­rungs­ma­nage­ment, das eine Prio­ri­sie­rung und Aus­stat­tung der Pro­jek­te mit per­so­nel­len und tech­ni­schen Res­sour­cen über einen Zeit­raum von mehr als drei Mona­ten ermöglicht
  • Eta­blie­rung eines sys­te­ma­ti­schen, gesteu­er­ten, und zen­tra­len inhalt­li­chen Abhän­gig­keits­ma­nage­ments im Pro­jekt und in the­ma­ti­schen Projektbündeln
  • Ergän­zung um eine pro­jekt­über­grei­fen­de Res­sour­cen­steue­rung im Hin­blick auf per­so­nel­le Exper­ti­se (in Abstim­mung mit den Lini­en­ein­hei­ten) und tech­ni­sche Erfor­der­nis­se (z. B. in Form eines Test- und Releasemanagements)
  • Aus­bau der dezen­tra­len Risi­koer­fas­sung, z. B. in Jira zu einem ganz­heit­li­chen Risi­ko- und Issue Manage­ment, das eine Bewer­tung von Risi­ken und Issues ent­hält und ein sys­te­ma­ti­sches Con­trol­ling der hin­ter­leg­ten Maß­nah­men sicherstellt
  • Ver­län­ge­rung der Pla­nungs­ho­ri­zon­te durch Aus­deh­nung der Pla­nung auf mit­tel- und lang­fris­ti­ge Zeit­ach­sen. Vom Ziel des Trans­for­ma­ti­ons­pro­jek­tes aus­ge­hend wer­den die zur Errei­chung des Ziels erfor­der­li­chen Leis­tungs­bau­stei­ne iden­ti­fi­ziert und beplant. Hier­bei kann es sehr wohl zu unter­schied­li­chen Detail­lie­rungs­stän­den und Unsi­cher­hei­ten in der Pla­nung kommen
  • Ein­füh­rung zen­tra­ler Qua­li­täts­si­che­rungs­maß­nah­men über die in Jira und Con­fluence hin­ter­leg­ten Pro­jekt­do­ku­men­ta­tio­nen. Hier­durch wird ein gemein­sa­mer Qua­li­täts­stan­dard pro­jekt­in­tern und pro­jekt­über­grei­fend sicher­ge­stellt, der auch durch regu­la­to­ri­sche Anfor­de­run­gen vor­ge­ge­ben ist
  • Unter­stüt­zung der Qua­li­täts­si­che­rung durch den Ein­satz eines inhalt­li­chen PMO, wel­ches sich expli­zit um die­se ver­bin­den­den Metho­den küm­mert und eine Ent­las­tung der ope­ra­ti­ven Pro­jekt­teams sicherstellt

Nach­ste­hen­des Prin­zip­bild stellt Tei­le des ver­füg­ba­ren ban­kon Metho­den­port­fo­li­os dar, mit dem Trans­for­ma­ti­ons­pro­jek­te situa­ti­ons­ge­recht zum Erfolg geführt wer­den und Maß­nah­men zur Stei­ge­rung des Agi­li­täts­scores im Unter­neh­men umge­setzt werden.

Transformationsprojekte in Banken

Exper­ti­se ban­kon Manage­ment Consulting

Die Exper­ti­se der ban­kon-Bera­ter aus mehr als fünf­zehn Jah­ren Erfah­rung in Trans­for­ma­ti­ons-Groß­pro­jek­ten sichert pra­xis­er­prob­tes Wis­sen. Die Erfah­rung in der Durch­füh­rung die­ser Art von kom­ple­xen Pro­jek­ten hat gezeigt, dass ein allei­ni­ges agi­les oder klas­si­sches Vor­ge­hen den Anfor­de­run­gen des Pro­jek­tes nicht opti­mal Rech­nung trägt. Viel­mehr ist ein geeig­ne­ter Mix aus Metho­den und Tool­bau­stei­nen erfor­der­lich, um den Pro­jekt­er­folg best­mög­lich zu unter­stüt­zen. In Form eines Best Prac­ti­ce-Ansat­zes hat ban­kon einen Metho­den­bau­kas­ten erar­bei­tet, der eine bedarfs­ge­rech­te Aus­wahl zur Ver­fü­gung stellt. Die ver­füg­ba­ren Metho­den und Tools sind ver­knüpft mit einem Agi­li­täts­score, der zu dem pro­jekt- und unter­neh­mens­in­di­vi­du­el­len Score gemappt wird, der für das Trans­for­ma­ti­ons­vor­ha­ben der Bank ermit­telt wird.

Dar­über hin­aus wird durch die­ses Vor­ge­hen eine Wei­ter­ent­wick­lung der Agi­li­tät in Pro­jek­ten, aber auch in Ver­än­de­rungs­pro­zes­sen der Bank gene­rell gefördert.

Pro­fi­tie­ren Sie von der lang­jäh­ri­gen Erfah­rung der ban­kon-Bera­ter in agi­len und klas­si­schen Trans­for­ma­ti­ons­pro­jek­ten auf Ihrem Weg zur agi­len Bank und zur erfolg­rei­chen Durch­füh­rung von Transformationsprojekten. 

Nut­zen Sie unse­re umfang­rei­chen Erfah­run­gen und spre­chen Sie mit uns:

ban­kon Manage­ment Con­sul­ting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://​www​.ban​kon​.de
E‑Mail: research@bankon.de


stürmische Wetterlage

CoOpetition 2.0 – Banken müssen Ihre IT-Wertschöpfungsketten neu denken

Ban­ken sehen sich nicht erst durch die Coro­na-Pan­de­mie einer „stür­mi­schen Wet­ter­la­ge“ gegen­über. Bereits vor dem Virus stan­den Geschäfts­mo­del­le und ihre Ver­än­de­rung in Pro­zes­sen und Tech­nik im Fokus der Akti­vi­tä­ten in den Instituten.

Bli­cken wir vor die­sem Hin­ter­grund auf die Infor­ma­ti­ons­tech­nik der Ban­ken, dann wird fol­gen­des deutlich:

  • Die tech­ni­schen Bedro­hungs­si­tua­tio­nen von außer­halb, aber auch von inner­halb der Bank, wer­den quan­ti­ta­tiv und qua­li­ta­tiv spürbarer
  • Hier­bei kann die Bedro­hungs­si­tua­ti­on sowohl mit­tels kri­mi­nel­ler Ener­gie her­ge­stellt wor­den sein als auch durch Unacht­sam­keit beför­dert werden
  • Die Tech­no­lo­gi­sie­rung der betrof­fe­nen Pro­zes­se nimmt hier­bei stän­dig zu – bei­spiel­haft sei­en hier Block­chain oder Bit­co­in genannt
  • Staat und Ban­ken­auf­sicht grei­fen mit­tels Vor­ga­ben zur Ein­däm­mung der Risi­ken regu­la­to­risch ein

Zusam­men­ge­fasst ergibt sich für die IT in Ban­ken fol­gen­des Bild:

Zwei poten­zi­el­le Miss­ver­ständ­nis­se gilt es hier­bei von vor­ne­her­ein zu vermeiden:

  • Unter Inno­va­ti­ons­kraft ist hier nicht zu ver­ste­hen, dass neben den Run-Akti­vi­tä­ten noch ein Rest­an­teil von Kapa­zi­tät und Bud­get für Chan­ge-Akti­vi­tä­ten verbleibt
  • Unter Manage­ment von Wert­schöp­fungs­ket­ten ist nicht die Erfül­lung der Anfor­de­run­gen aus den EBA-Gui­de­lines zum Sourcing gemeint

Viel­mehr ist es für die IT in Ban­ken von essen­zi­el­ler Bedeu­tung, neben der Gestal­tung des Span­nungs­fel­des regu­la­to­ri­scher Anfor­de­run­gen und der Abwehr tech­ni­scher Angrif­fe von innen und außen par­al­lel die Inno­va­ti­ons­kraft von Pro­zes­sen und Tech­nik in der IT erheb­lich zu stär­ken. Hier­zu ist es erfor­der­lich, die bestehen­den Wert­schöp­fungs­ket­ten grund­le­gend zu über­den­ken – Stich­wort CoO­pe­ti­ti­on 2.0. Die­ses kann kei­nes­falls unab­hän­gig von­ein­an­der gesche­hen, da in der Neu­ge­stal­tung der Make-or-Buy-Struk­tur für die Ban­ken-IT der größ­te Hebel liegt, Inno­va­ti­ons­frei­räu­me zu generieren. 

CoO­pe­ti­ti­on 1.0

Der Begriff CoO­pe­ti­ti­on beschreibt die Dua­li­tät von Kon­kur­renz und Koope­ra­ti­on. Wesent­li­cher Inhalt von CoO­pe­ti­ti­on 1.0 war die Posi­tio­nie­rung der Bank im Markt und in ihrer Funk­ti­on. In den Insti­tuts­grup­pen der Genos­sen­schaf­ten und der Spar­kas­sen lässt sich die Umset­zung gut identifizieren.

Bei­de Insti­tuts­grup­pen haben vie­le Tätig­kei­ten für die Pri­mär­in­sti­tu­te zen­tra­li­siert und auf einen oder weni­ge Anbie­ter ver­dich­tet. So gibt es in bei­den Grup­pen jeweils nur noch einen Rechen­zen­trums­an­bie­ter mit einem Kern­bank­sys­tem. Die Genos­sen haben nur noch ein Spit­zen­in­sti­tut. Die Spar­kas­sen haben nur noch zwei bedeu­ten­de Back­of­fice-Anbie­ter. Leis­tungs­an­ge­bo­te, wie z. B. das Kon­su­men­ten­kre­dit­ge­schäft, wer­den insti­tuts­über­grei­fend bereit­ge­stellt – sie­he S‑Kreditpartner GmbH.

Im Ergeb­nis fokus­sie­ren sich die Insti­tu­te deut­lich stär­ker auf Ihre Kern­kom­pe­tenz und zwar den Ver­kauf von Bank­pro­duk­ten ein­her­ge­hend mit erfor­der­li­chen Beratungsleistungen.

CoO­pe­ti­ti­on 2.0

In der Wei­ter­ent­wick­lung zur CoO­pe­ti­ti­on 2.0 liegt der Schwer­punkt auf der IT. Sie ist der Enabler, um Verkaufs‑, Beratungs‑, Abwick­lungs- und Steue­rungs­pro­zes­se effi­zi­ent zu gestalten.

Da es nicht die Kern­kom­pe­tenz einer Bank ist, ein Rechen­zen­trum zu betrei­ben oder Soft­ware zu ent­wi­ckeln, wer­den wesent­li­che IT-Leis­tun­gen von Dritt­an­bie­tern bezo­gen. Stra­te­gi­sche Part­ner­schaft ver­sus Best-of-Breed ist hier­bei die domi­nie­ren­de Fra­ge. Die zen­tra­len IT-Dienst­leis­ter der bei­den gro­ßen Ban­ken­grup­pen Deutsch­lands haben um den Betrieb des Kern­bank­sys­tems in ihren Rechen­zen­tren hin­aus ein umfang­rei­ches Soft­ware- und Dienst­leis­tungs­an­ge­bot geschaf­fen, das sie obli­ga­to­risch zu stra­te­gi­schen Part­nern der Insti­tu­te macht.

Drei Hand­lungs­op­tio­nen haben sich in der Pra­xis als ziel­füh­rend herausgestellt:

CoOpetition 2 RJO

Opti­on 1 (Stan­dard):

Die Nut­zung der Leis­tungs­an­ge­bo­te des Rechen­zen­trums im Stan­dard mini­miert sowohl die Steue­rungs­auf­wän­de als auch die Run-Kos­ten. Freie Kapa­zi­tä­ten und Bud­gets für tech­ni­sche und pro­zes­sua­le Inno­va­tio­nen sind das Resul­tat. Eine Nut­zung hier­für stün­de aber im Wider­spruch zu dem auf Stan­dard gesetz­ten Fokus.

Ande­rer­seits kann der Schwer­punkt so ver­stärkt auf die Berei­che der Bank gelegt wer­den, in denen das Insti­tut die Kern­kom­pe­tenz besitzt – Bera­tung und Verkauf.

Dar­über hin­aus kann aus dem reich­hal­ti­gen Ange­bot von Stan­dard­leis­tun­gen und Tools das für das Insti­tut best­mög­li­che Port­fo­lio aus­ge­wählt wer­den. Die­ses kann auf­grund der stan­dar­di­sier­ten Nut­zung umfang­rei­cher ausfallen.

Bei einer Ent­schei­dung für die­se Opti­on sind die IT-Pro­zes­se inklu­si­ve des Anfor­de­rungs­ma­nage­ments sowie die über­ge­ord­ne­te IT-Stra­te­gie ent­spre­chend auszurichten.

Opti­on 2 (Indi­vi­dua­li­tät im Standard):

Mit der Ergän­zung des Stan­dards um durch das Rechen­zen­trum ange­bo­te­ne Indi­vi­du­al­leis­tun­gen las­sen sich pro­zes­sua­le und tech­ni­sche Inno­va­tio­nen stär­ker umset­zen als in einer aus­schließ­li­chen Aus­rich­tung am Stan­dard. Bei­spiel­haft für Indi­vi­dua­li­tät kann der Ein­satz leis­tungs­stär­ke­rer Ana­ly­se­tools für Daten­aus­wer­tun­gen sein oder Soft­ware, wel­che die Abbil­dung kom­ple­xe­rer Pro­duk­te und Dienst­leis­tun­gen ermöglicht.

Die zusätz­li­chen, indi­vi­du­el­len Leis­tun­gen erlau­ben eine Unter­schei­dung vom Leis­tungs­an­ge­bot des Wett­be­werbs. Frei­heits­gra­de wie die Ein­bin­dung von Part­ner­pro­duk­ten außer­halb der Insti­tuts­grup­pe oder das Ange­bot insti­tuts­in­di­vi­du­el­ler, digi­ta­ler Leis­tun­gen sind hier aber nur ein­ge­schränkt möglich.

Es bleibt der Fokus auf die Kern­kom­pe­ten­zen Bera­tung und Ver­kauf. Da die Indi­vi­du­al­leis­tun­gen sepa­rat bepreist wer­den, ist die Nut­zung die­ser Mög­lich­kei­ten Bestand­teil einer insti­tuts­spe­zi­fi­schen Kal­ku­la­ti­on. In die­se flie­ßen neben den höhe­ren Run-Kos­ten gegen­über der Opti­on 1 auch erhöh­te Auf­wän­de für die Admi­nis­tra­ti­on, Steue­rung und Kon­trol­le der Indi­vi­du­al­leis­tun­gen ein.

Die Indi­vi­dua­li­tät im Stan­dard muss somit einen mess­ba­ren öko­no­mi­schen Vor­teil gegen­über dem rei­nen Stan­dard auf­wei­sen, um für die Bank sinn­voll zu sein.

Ent­spre­chend ist auch bei einer Ent­schei­dung für die­se Opti­on die IT-Stra­te­gie ent­spre­chend zu for­mu­lie­ren und die IT-Pro­zes­se stra­te­gie­kon­form auszurichten.

Opti­on 3 (Indi­vi­dua­li­tät zusätz­lich zum Standard):

Für Insti­tu­te, die Ihr Pro­dukt- und Dienst­leis­tungs­an­ge­bot um Leis­tun­gen von Dritt­part­nern oder FinTechs ergän­zen wol­len, ist die Erwei­te­rung des Stan­dards um indi­vi­du­el­le Leis­tun­gen, die nicht durch das Rechen­zen­trum ange­bo­ten wer­den, eine Option.

Bei­spiel­haft für eine sol­che Erwei­te­rung sei hier die Ein­füh­rung leis­tungs­be­zo­ge­ner Pro­dukt­öko­sys­te­me genannt. Die­se kön­nen unter ande­rem im Kon­text Bau (z. B. Ange­bo­te von Hand­wer­kern, Archi­tek­ten oder Behör­den) oder Senio­ren (z. B. Ange­bo­te zu Pfle­ge­diens­ten, zur Frei­zeit­ge­stal­tung sowie Ein­kaufs­ser­vices) kon­zi­piert werden.

Glei­ches gilt aber z. B. auch im Kon­text des Wert­pa­pier­ge­schäf­tes. Schritt­wei­se ein­ge­führ­te insti­tuts­grup­pen­spe­zi­fi­sche Ange­bo­te wie z. B. der Beves­tor der Deka­Bank ste­hen hier neben Eigen­ent­wick­lun­gen von Insti­tu­ten wie Sma­ves­to der Spar­kas­se Bre­men und Ange­bo­ten außer­halb der Institutsgruppe.

Für alle gemein­sam gilt jedoch, dass die Indi­vi­dua­li­tät die­ser Ange­bo­te erheb­lich in die Gestal­tung tech­ni­scher und orga­ni­sa­to­ri­scher Pro­zes­se in der IT ausstrahlt.

Insti­tu­te, die sol­che Leis­tun­gen nut­zen, benö­ti­gen per­so­nel­le und tech­ni­sche Kapa­zi­tä­ten, um die­se Ange­bo­te abbil­den zu kön­nen. Steue­rungs- und Betriebs­pro­zes­se sind inhalt­lich und regu­la­to­risch ent­spre­chend aus­zu­ge­stal­ten. Sie sind in einer IT-Stra­te­gie zusam­men­zu­füh­ren sowie durch Vor­ga­ben der IT-Archi­tek­tur und ein Tar­get Ope­ra­ting Model zu operationalisieren.

Eine Ent­schei­dung für die­sen Weg erfor­dert dar­über hin­aus, dass dadurch ein nach­hal­tig mess­ba­rer öko­no­mi­scher Mehr­wert gene­riert wer­den kann.

Zusam­men­fas­sung:

Es gibt kei­ne rich­ti­ge oder fal­sche Ent­schei­dung. Aus­schlag­ge­bend sind vor allem nach­ste­hen­de fünf Handlungsfelder:

  • Die Geschäfts­stra­te­gie der Bank (wie posi­tio­nie­re ich mich gegen­über mei­nen Wettbewerbern)
  • Die Sourcing­stra­te­gie der Bank (wie affin bin ich für eine Aus­la­ge­rung von Leis­tun­gen an Drit­te und wie eta­bliert sind mei­ne Pro­zes­se für eine regu­la­to­rik­kon­for­me Steuerung)
  • Grö­ße und Wett­be­werbs­in­ten­si­tät des Instituts
  • Per­so­nel­le Aus­stat­tung (quan­ti­ta­tiv und skillspezifisch)
  • Insti­tuts­in­di­vi­du­el­le Governance

Aus die­sen Hand­lungs­fel­dern ist die für das Insti­tut opti­ma­le Opti­on zur Gestal­tung der       CoO­pe­ti­ti­on 2.0 aus­zu­wäh­len und auszugestalten.

Exper­ti­se ban­kon Manage­ment Consulting

Die Exper­ti­se der ban­kon-Bera­ter aus mehr als fünf­zehn Jah­ren Erfah­rung aus Pro­jek­ten im Kon­text der Ban­ken-IT sichert pra­xis­er­prob­tes Wis­sen. Erfah­run­gen aus Stra­te­gie- und Trans­for­ma­ti­ons­pro­jek­ten, der Ein­füh­rung neu­er Geschäfts­fel­der und Pro­duk­te sowie der Sicher­stel­lung von Gover­nan­ce- und Regu­la­to­rik-Anfor­de­run­gen gewähr­leis­ten den erfor­der­li­chen fach­li­chen, pro­zes­sua­len und tech­ni­schen Hintergrund.

Nut­zen Sie unse­re umfang­rei­chen Erfah­run­gen und spre­chen Sie mit uns:

ban­kon Manage­ment Con­sul­ting GmbH & Co. KG
Max-Planck-Str. 8
85609 Aschheim/München
Tel.: (089) 99 90 97 90
Fax: (089) 99 90 97 99
Web: https://​www​.ban​kon​.de
E‑Mail: research@bankon.de