Schlagwort: Methodik

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


Agilität-Regulatorik

„Agilität in Regulatorikprojekten – Widerspruch oder Chance?“

Anzahl und Kom­ple­xi­tät von Regu­la­to­rik­pro­jek­ten in Ban­ken stei­gen stän­dig. Immer mehr Res­sour­cen, per­so­nell und finan­zi­ell, wer­den mit der Sicher­stel­lung einer regu­la­to­rik­kon­for­men Gover­nan­ce gebun­den. Lei­der ist der Bei­trag zur unter­neh­me­ri­schen Wert­schöp­fung von Regu­la­to­rik­pro­jek­ten nahe­zu „Null“. Aus die­sem Grund kommt der effek­ti­ven Bear­bei­tung regu­la­to­ri­scher Anfor­de­run­gen sowie dem effi­zi­en­ten Manage­ment von Regu­la­to­rik­pro­jek­ten eine hohe Bedeu­tung zu. Kön­nen hier agi­le Metho­den oder gar Scrum helfen?

Zur Klä­rung einer Eig­nung von Scrum für die Durch­füh­rung regu­la­to­ri­scher Pro­jek­te in Ban­ken emp­fiehlt sich ein Blick auf die Cha­rak­te­ris­ti­ka von Pro­jek­ten, bei denen Scrum ide­al­ty­pisch ein­ge­setzt wird.

Kennzeichen von Projekten Scrum vs. Wasserfall

Auf­grund der gesetz­li­chen oder auf­sichts­recht­li­chen Vor­ga­ben, an denen Regu­la­to­rik­pro­jek­te aus­ge­rich­tet sind, wird auf den ers­ten Blick deut­lich, dass die­se Art von Pro­jek­ten nicht die Kenn­zei­chen auf­wei­sen, die ein Pro­jekt cha­rak­te­ri­sie­ren, das sich gut für die Anwen­dung von Scrum eig­net. Selbst­ver­ständ­lich lässt sich ein­wen­den, dass Metho­di­ken immer auch eine indi­vi­du­el­le Inter­pre­ta­ti­on oder Aus­prä­gung auf­wei­sen. Scrum lebt aber gera­de von der Ein­hal­tung des Metho­den­ka­nons, um sei­ne Wir­kung ent­fal­ten zu kön­nen. Metho­di­sche „Ein­grif­fe“ stel­len hier den Erfolg eines Scrum-Pro­jek­tes schnell in Fra­ge – die Anwen­dung von Scrum wird mit die­sen Ein­grif­fen abgebrochen.

Lösen wir uns vor die­sem Hin­ter­grund ein­mal von dem Begriff Scrum und rücken statt­des­sen Agi­li­tät in den Mit­tel­punkt der Betrach­tung. Unter der Fra­ge­stel­lung, ob und wenn ja wel­che agi­len Metho­den für Regu­la­to­rik­pro­jek­te geeig­net sind, ist eine Ent­kopp­lung von der Stren­ge der durch Scrum deter­mi­nier­ten Vor­ga­ben möglich.

Wel­che agi­len Metho­den gibt es, die in Scrum genutzt wer­den, und gibt es dar­über hin­aus geeig­ne­te Ergän­zun­gen die­ses agi­len Tool­sets – die­se Fra­ge soll im Fol­gen­den betrach­tet wer­den, um danach die Eig­nung für einen Ein­satz in Regu­la­to­rik­pro­jek­ten zu bewerten.

Die aus Scrum bekann­ten agi­len Metho­den las­sen sich aus mei­ner Erfah­rung grob in drei Schwer­punk­te auf­tei­len. Sie unter­stüt­zen eine inhalt­li­che Struk­tu­rie­rung, eine zeit­li­che Struk­tu­rie­rung oder stel­len die Inter­ak­ti­on der Betei­lig­ten in den Mit­tel­punkt. Nach­ste­hen­de Über­sicht ord­net die in Scrum genutz­ten Metho­den­bau­stei­ne die­sen drei Schwer­punk­ten zu.

Agile Methoden - Schwerpunkt Interaktion

Zu 1 – Inhalt­li­che Strukturierung

  • Mit­tels eines Back­logs kön­nen Anfor­de­run­gen in unter­schied­li­cher Aus­prä­gung und Doku­men­ta­ti­ons­form ver­wal­tet werden
  • Neben der Beschrei­bung erfolgt für die Inhal­te eines Back­logs eine Dar­stel­lung von Auf­wand und Nut­zen sowie eine Priorisierung
  • Ent­spre­chend der Prio­ri­sie­rung wird die Beschrei­bung detail­lier­ter spezifiziert
  • Das Kan­ban-Board visua­li­siert Arbeitsfortschritte
  • Auf­ga­ben durch­lau­fen nach Arbeits­fort­schritt geglie­der­te Rubri­ken, die je nach Ein­satz­zweck unter­schied­lich geglie­dert wer­den, z. B.:
    • Zu tun | In Arbeit | Erledigt
    • Back­log | Kon­zep­ti­on | Umset­zung | Test | Frei­ga­be | Erledigt

Eig­nung für Regulatorikprojekte:

Eine struk­tu­rier­te Samm­lung von Anfor­de­run­gen ist Inhalt jedes Pro­jek­tes und damit auch für Regu­la­to­rik­pro­jek­te essen­zi­ell. User Sto­ries wer­den sicher­lich nicht die domi­nie­ren­de Bedeu­tung in der Zusam­men­set­zung des Back­logs haben. Eben­so wenig wird die Sum­me der Anfor­de­run­gen mit­tels eines Fach­kon­zepts und eines DV-Kon­zepts beschrie­ben, um dann mit dem Label Back­log ver­se­hen zu werden.

Unter Berück­sich­ti­gung eines modu­la­ren Auf­baus der Grund­ge­samt­heit von Anfor­de­run­gen in Regu­la­to­rik­pro­jek­ten ist ein Back­log gut geeig­net, um die­se als Sum­me zu ver­wal­ten. Aus ihm las­sen sich dann zusam­men­hän­gen­de Ein­zel­an­for­de­run­gen her­aus­zie­hen und in einen Sprint-Back­log zusam­men­fas­sen. Denk­bar sind hier bei­spiels­wei­se Use-Cases zur Anbin­dung von Anwen­dungs­sys­te­men oder Infra­struk­tur­kom­po­nen­ten an ein SIEM (Secu­ri­ty Inci­dent and Event Management).

Zu 2 – Zeit­li­che Strukturierung

Sich für einen kur­zen Arbeits­zeit­raum defi­nier­te Arbeits­in­hal­te vor­zu­neh­men, die aus der Grund­ge­samt­heit aller Anfor­de­run­gen aus­ge­wählt wer­den, ist unab­hän­gig von Scrum ein sinn­vol­les Vor­ge­hen zur Hand­ha­bung eines kom­ple­xen Anfor­de­rungs­uni­ver­sums. Vor­aus­set­zung ist jedoch, dass die Inhal­te eines Sprints kei­ne zu fes­te Kopp­lung zu ande­ren Anfor­de­run­gen außer­halb des Sprits auf­wei­sen und damit eine unab­hän­gi­ge Bear­bei­tung ermöglichen.

Eig­nung für Regulatorikprojekte:

Fol­gen­de Bei­spie­le aus Regu­la­to­rik­pro­jek­ten sei­en zur Ver­deut­li­chung genannt:

  • Anbin­dung von Anwen­dun­gen an ein PAM-Tool (pri­vi­le­ged access manage­ment) zum Hand­ling pri­vi­le­gier­ter Berechtigungen
  • Durch­füh­rung einer Busi­ness-Impact-Ana­ly­se für einen Kernprozess
  • Umset­zung gemein­sa­mer Schwach­stel­len­scans mit einem IT-Provider

Gemein­sa­mes Cha­rak­te­ris­ti­kum obi­ger Tätig­kei­ten ist, dass sie nicht durch eine Per­son allein durch­ge­führt wer­den, son­dern nur personen‑, abteilungs‑, bereichs- oder fir­men­über­grei­fend bewäl­tigt wer­den kön­nen. Mit ihrer losen Kopp­lung zu ande­ren The­men sind sie jedoch gut für eine Bear­bei­tung in Form eines Sprints geeignet.

Deut­lich wird anhand die­ser Auf­ga­ben jedoch die Not­wen­dig­keit zur Inter­ak­ti­on in der Bear­bei­tung. Und genau hier liegt der drit­te Schwer­punkt agi­ler Methodiken.

Zu 3 – Interaktion

„Mit­ein­an­der reden“ hie­ßen nicht nur die vier Stan­dard­wer­ke von Frie­de­mann Schulz von Thun zur Kom­mu­ni­ka­ti­ons­psy­cho­lo­gie, son­dern auch in Pro­jek­ten gilt die­ser Leit­satz. Aus die­sem Grund wur­den in der Scrum-Metho­dik Vor­ga­ben zum struk­tu­rier­ten Aus­tausch umge­setzt, sei es der täg­li­che Stan­dup oder Sprint-Review und Sprint-Retro­spek­ti­ve. Struk­tu­rel­le und zeit­li­che Vor­ga­ben stel­len die Effi­zi­enz und Effek­ti­vi­tät die­ser Ter­mi­ne sicher.

Eig­nung für Regulatorikprojekte:

Die Eig­nung eines täg­li­chen Stan­dup für Regu­la­to­rik­pro­jek­te steht außer Zwei­fel, hat sich doch die­ses kur­ze Mee­ting inzwi­schen weit über Scrum hin­aus in den beruf­li­chen All­tag aus­ge­brei­tet. Wich­tig im Kon­text von Regu­la­to­rik­pro­jek­ten ist hier jedoch die Ein­hal­tung der struk­tu­rel­len und zeit­li­chen Vor­ga­ben aus Scrum, um einen dif­fu­sen Infor­ma­ti­ons­aus­tausch zu ver­mei­den. Das Ergeb­nis eines Sprints im Review zu betrach­ten und Ver­bes­se­run­gen dar­aus abzu­lei­ten (Retro­spek­ti­ve), ist grund­sätz­lich auch außer­halb von Scrum wich­tig. Die eng gefass­ten metho­di­schen Vor­ga­ben ver­lie­ren jedoch ein Stück weit an Bedeu­tung, wenn in Regu­la­to­rik­pro­jek­ten nicht wie bei Scrum das Ergeb­nis eines Sprints pro­duk­tiv gesetzt wird.

Zusam­men­fas­sung:

Zusam­men­fas­send lässt sich sagen, dass Scrum als geschlos­se­ne Metho­dik sicher­lich nicht geeig­net ist für die Durch­füh­rung von Regu­la­to­rik­pro­jek­ten. Aber eine Viel­zahl von Ele­men­ten aus dem agi­len Metho­den­bau­kas­ten, den Scrum nutzt, las­sen sich über­tra­gen. Sie zah­len ein auf die schnel­le Erzeu­gung ver­wert­ba­rer Ergeb­nis­se im Pro­jekt, die Sicher­stel­lung der Kom­mu­ni­ka­ti­on sowie die Umset­zung der ganz­heit­li­chen Ziel­set­zung des Projektes.

Hier haben Erfah­run­gen gezeigt, dass sich ein­zel­ne Ele­men­te auch sehr gut mit­ein­an­der kom­bi­nie­ren las­sen. Expli­zit sei hier auf die Metho­dik des Scrum­ban hin­ge­wie­sen, in der die Visua­li­sie­rung mit­tels Kan­ban-Board um pro­zes­sua­le Ele­men­te erwei­tert wird. So infor­miert es über die Anzahl der Objek­te, an denen das Team gera­de arbei­tet, sowie die Anzahl an Auf­ga­ben, wel­che schon abge­schos­sen sind. Ziel ist hier die Stär­kung von Ver­ant­wor­tungs­be­wusst­sein und Kom­mu­ni­ka­ti­on sowie die Visua­li­sie­rung der bereits erziel­ten Leistungsergebnisse.

In einer fort­ge­schrit­te­nen Aus­bau­stu­fe kann ein sol­ches Scrum­ban-Board durch die inkre­men­tel­le Arbeits­pla­nung Sprints obso­let machen. Jedoch hat sich im prak­ti­schen Ein­satz die Kom­bi­na­ti­on von Sprints und Scrum­ban-Boards bewährt. Das Prin­zip­bild eines Scrum­ban-Boards zeigt nach­ste­hen­de Abbildung.

Backlog

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-Regu­la­to­rik sichert pra­xis­er­prob­tes Wis­sen. Umfang­rei­che Kennt­nis von Orga­ni­sa­ti­ons­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.

Auf die­ser Grund­la­ge sowie mit­tels unse­res lang­jäh­ri­gen Erfah­rungs­schat­zes in der erfolg­rei­chen Anwen­dung tra­di­tio­nel­ler und agi­ler Metho­den im Pro­jekt wäh­len wir gemein­sam mit Ihnen den für Ihr Insti­tut geeig­ne­ten Metho­den­mix aus.

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