Schlagwort: Anforderung

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. 

IAM – Fluch oder Segen

Umset­zung regu­la­to­risch erwei­ter­ter Anfor­de­run­gen im Eigen­in­ter­es­se der Banken

Ver­schär­fung der BAIT bei IAM zwingt zum Handeln

Am 16. August 2021 hat die BaFin die neue Fas­sung ihrer Bank­auf­sicht­li­chen Anfor­de­run­gen an die IT (BAIT) ver­öf­fent­licht, wel­che noch am sel­ben Tag in Kraft getre­ten sind.

Der Schwer­punkt der Neu­hei­ten liegt hier­bei nun­mehr weni­ger auf grund­le­gen­den Ände­run­gen als viel­mehr auf der Erwei­te­rung und Anpas­sung diver­ser Anfor­de­run­gen. Die­ses gilt auch für das zen­tra­le The­men­feld des Iden­ti­ty & Access Manage­ments (IAM).

Die BAIT beschreibt detail­lier­te Anfor­de­run­gen an IT-Berech­ti­gungs­kon­zep­te, Geneh­mi­gungs- und Kon­troll­pro­zes­se, Rezer­ti­fi­zie­rung der Berech­ti­gun­gen sowie Nach­voll­zieh­bar­keit und Doku­men­ta­ti­on sämt­li­cher Einrichtungs‑, Ände­rungs- und Deak­ti­vie­rungs­pro­zes­se. Unter IAM fal­len damit alle Funk­tio­nen und Arbeits­schrit­te im Zusam­men­hang mit der Admi­nis­tra­ti­on von Iden­ti­tä­ten und der Ver­wal­tung von Zugriffs­rech­ten sowie die damit ver­bun­de­ne Nachweisführung.

Von beson­de­rer Bedeu­tung ist die vor­ge­nom­me­ne Ergän­zung des Abschnitts 6.1. Mit ihm wur­de zusätz­lich in die BAIT auf­ge­nom­men, dass jeg­li­che Zugriffs‑, Zugangs- und Zutritts­rech­te auf Bestand­tei­le bzw. zu Bestand­tei­len des Infor­ma­ti­ons­ver­bun­des stan­dar­di­sier­ten Pro­zes­sen und Kon­trol­len unter­lie­gen sol­len, was kon­kret alle Berech­ti­gun­gen von Betriebs­sys­tem- über Daten­bank- bis Anwen­dungs­ebe­ne betrifft, und zwar auch für tech­ni­sche Zugän­ge bzw. Nutzer.

Aku­ter Hand­lungs­be­darf in der deut­schen Finanzszene

Für Deutsch­lands Ban­ken gilt mit Inkraft­set­zung der neu­en BAIT der Vor­satz „zeit­nah agie­ren und nicht erst, wenn die Auf­sicht an die Tür klopft“. Dies soll­te nicht im Lich­te eines Zug­zwangs gese­hen wer­den, son­dern im urei­ge­nen Inter­es­se der Insti­tu­te. Der Stand der tech­ni­schen Ent­wick­lung sowie der Digi­ta­li­sie­rung erhöht das Risi­ko betrü­ge­ri­scher Sys­tem­zu­grif­fe in erheb­li­chem Maße. In der Vor­beu­gung und Bekämp­fung betrü­ge­ri­scher Mög­lich­kei­ten sind koor­di­nie­ren­de Maß­nah­men erfor­der­lich, die man mit Bord­mit­teln und einer „dezen­tra­len teil­ma­nu­el­len Lösung“ von Zugriffs- und Berech­ti­gungs­kon­trol­len nicht mehr beherr­schen kann.

Der aus die­sen regu­la­to­ri­schen Anfor­de­run­gen resul­tie­ren­de Inves­ti­ti­ons­be­darf sowie die Bean­spru­chung unter­neh­mens­in­ter­ner Res­sour­cen gehen in vie­len Fäl­len über „das Mach­ba­re“ weit hin­aus. Auch vor dem Hin­ter­grund bereits erfolg­ter oder anste­hen­der Ver­la­ge­run­gen von Anwen­dun­gen in eine Cloud-Lösung gilt es, effi­zi­ent vor­zu­ge­hen und effek­ti­ve Ergeb­nis­se zu erzeugen.

Im Kon­text der welt­weit zu begrü­ßen­den posi­ti­ven, aber auch bedroh­lich nega­ti­ven Effek­te der fort­schrei­ten­den Digi­ta­li­sie­rung, han­delt es sich hier um eine not­wen­di­ge, gera­de aber auch für die mit hoch­sen­si­blen Daten ope­rie­ren­de Finanz­dienst­leis­tungs­bran­che maxi­mal sinn­haf­te Inves­ti­ti­on in die Zukunft.

Die sich in Sum­me erge­ben­den Vor­tei­le über­wie­gen den ver­meint­li­chen Auf­wand und brin­gen sogar ins­ge­samt mit­tel­fris­tig Kos­ten­vor­tei­le, da wesent­li­che Pro­zes­se auto­ma­ti­siert wie­der­ver­wend­bar sind und die manu­el­le Admi­nis­tra­ti­on in den Hin­ter­grund rückt.

Was ist zu tun

Gemäß öffent­lich zugäng­li­chem Zah­len­ma­te­ri­al waren bis Ende 2020 etwa 60 % der Finanz­in­sti­tu­te inten­si­ver mit dem The­ma befasst, davon ver­füg­te die Hälf­te der Insti­tu­te bereits über ein­ge­führ­te IAM-Sys­te­me. Hier ist, bezo­gen auf die gesam­te Com­mu­ni­ty, also noch ein deut­li­cher Weg zu beschreiten.

Wie­der ein­mal han­delt es sich um ein The­ma an der Schnitt­stel­le zwi­schen Fach­lich­keit und IT, wobei IAM-Pro­jek­te kei­ne pri­mä­ren IT-Vor­ha­ben sind, son­dern die Fach­lich­keit mit kla­ren Vor­ga­ben für User-Pro­fi­le und Rol­len­be­schrei­bun­gen vorlegt.

Par­al­lel dazu erfolgt der Abschluss der Sys­tem­aus­wahl. Eine Viel­zahl der Anbie­ter von IAM-Sys­te­men waren in der Ver­gan­gen­heit US-ame­ri­ka­nisch geprägt. Inzwi­schen haben sich aber in den letz­ten fünf bis zehn Jah­ren im deutsch­spra­chi­gen Raum eine Rei­he von Lösungs­an­bie­tern etabliert.

Ins­ge­samt bie­tet sich die Chan­ce zum „Auf­räu­men“ durch Löschung von über­hol­ten Zugän­gen (Mit­ar­bei­ter sind gar nicht mehr im Haus oder haben die Posi­tio­nen und damit Auf­ga­ben­zu­stän­dig­kei­ten gewech­selt) und Schaf­fung einer kla­ren und siche­ren Struk­tur mit sich selbst steu­ern­den Mechanismen.

Vor­ge­hens­mo­dell

Von Vor­teil ist die Ein­schal­tung einer erfah­re­nen und unab­hän­gi­gen Instanz in die Aus­wahl­pro­zes­se und vor­be­rei­ten­den Akti­vi­tä­ten, um die Umset­zungs­pha­se eines IAM-Pro­jekts mög­lichst kom­pakt zu gestal­ten. Immer wie­der hat sich gezeigt, dass die Kom­ple­xi­tät eines sol­chen Vor­ha­bens deut­lich unter­schätzt wird. Sowohl den gesetz­li­chen als auch den eige­nen Anfor­de­run­gen des Hau­ses ist in aus­rei­chen­dem Maße Rech­nung zu tra­gen. Ins­ge­samt geht es dar­um, inno­va­tiv in die Zukunft zu inves­tie­ren (Sta­te of the Art), aber gleich­zei­tig den Bogen nicht zu über­span­nen und mit Blick auf Cost-Value-Fak­to­ren eine ange­mes­se­ne Lösung mit ver­träg­li­cher Pro­jekt­lauf­zeit zu imple­men­tie­ren, wel­che auch für klei­ne­re und mit­tel­gro­ße Häu­ser geeig­net ist (maxi­ma­le Nut­zung vor­han­de­ner, aber vor allem erfor­der­li­cher Funktionalitäten).

Das fol­gen­de Schau­bild illus­triert die wesent­li­chen Eck­pfei­ler eines voll inte­grier­ten IAM-Lösungsansatzes:

IAM - Schaubild Artikel MJH

Im Pro­jekt­ab­lauf geht es u. a. um das Auf­set­zen einer IAM-Stra­te­gie, die Durch­füh­rung von Vor­ar­bei­ten wie Bestands­ana­ly­se, Bestands­be­rei­ni­gung sowie die Kon­zep­ti­on und Über­ar­bei­tung des Rol­len­mo­dells (IT vs. Busi­ness) unter Beach­tung gefor­der­ter Funk­ti­ons­tren­nun­gen. Wei­te­re Hand­lungs­fel­der betref­fen die tech­ni­sche Anfor­de­rungs­auf­nah­me (z. B. Inte­gri­tät in die Umsys­te­me, User Expe­ri­ence, Work­flows), die Pro­zess­ge­stal­tung, die Erstel­lung und Aus­wer­tung von RFI/RFP, die Sys­tem­ent­schei­dung sowie die Kon­zep­ti­on der Sys­tem­an­bin­dun­gen (z. B. HR). Nach Instal­la­ti­on und Umset­zung der tech­ni­schen Kon­zep­te in der Ent­wick­lungs­um­ge­bung, einer aus­rei­chen­den technisch/fachlichen Test- und Abnah­me­pha­se (Nut­zung agi­ler Pro­jekt­me­tho­dik) sowie der zeit­ge­rech­ten Durch­füh­rung von Anwen­der­schu­lun­gen kann „die neue IAM-Welt“ in Pro­duk­ti­on an den Start gehen.

Je nach geleis­te­ter Vor­ar­beit und Kom­ple­xi­tät der Unter­neh­mens- und Anwen­dungs­struk­tur kann das Pro­jekt­vor­ha­ben einen Zeit­raum von sechs bis 18 Mona­ten in Anspruch neh­men. ban­kon beglei­tet Sie als neu­tra­ler Part­ner bei der Sys­tem­aus­wahl, Vor­be­rei­tung und Umset­zung Ihres IAM-Projekts.

Geld

ZAIT – Regulatorik für Zahlungsinstitute und E‑Geld-Institute

„Frü­her oder spä­ter krie­gen wir Euch alle“ mag die Finanz­auf­sicht (flap­sig for­mu­liert) gedacht haben, als sie mit den Zah­lungs­dienst­auf­sicht­li­chen Anfor­de­run­gen an die IT (ZAIT) ihre auf­sichts­recht­li­chen Vor­ga­ben auch auf Zah­lungs­in­sti­tu­te und E‑Geld-Insti­tu­te aus­ge­dehnt hat.

Der­zeit befin­den sich die ZAIT in der Kon­sul­ta­ti­on – jedoch ist nach Abschluss die­ser unmit­tel­bar mit einer Gül­tig­keit der ZAIT zu rechnen.

Unter­stützt wird die­se Annah­me durch die Tat­sa­che, dass die ZAIT das Kapi­tel „Kun­den­be­zie­hun­gen mit Zah­lungs­dienst­nut­zern“ for­mu­liert, das nach der Kon­sul­ta­ti­on auch Bestand­teil der Ban­ken­auf­sicht­li­chen Anfor­de­run­gen an die IT (BAIT) wird.

Die Begrün­dung für die pla­ka­ti­ve Ein­lei­tung die­ses Arti­kels gibt die Über­sicht der auf­sichts­recht­li­chen Anfor­de­run­gen, die sei­tens der Finanz­auf­sicht bis­her vor­ge­ge­ben wurden.

ZAIT 1 RJO

Wur­den zu Beginn Ban­ken und Ver­si­che­run­gen in den Mit­tel­punkt gerückt und ent­spre­chen­de auf­sichts­recht­li­che Anfor­de­run­gen für die siche­re Aus­ge­stal­tung der IT-Sys­te­me sowie der zuge­hö­ri­gen Pro­zes­se und die Umset­zung der IT-Gover­nan­ce ein­ge­führt, folg­ten bereits 2019 spe­zi­fi­sche Anfor­de­run­gen für Kapi­tal­ver­wal­tungs­ge­sell­schaf­ten. Dazwi­schen wur­de für beson­ders kri­ti­sche IT-Sys­te­me das KRI­TIS-Modul ein­ge­führt. Im Jahr 2020 erfuh­ren die BAIT eine deut­li­che Erwei­te­rung, die vor allem den Infor­ma­ti­ons­ver­bund in den Mit­tel­punkt rück­te und sei­ne Defi­ni­ti­on gegen­über den bis­her gül­ti­gen BAIT deut­lich ausbaute.

Im Jahr 2021 befin­den sich nun die ZAIT in der Kon­sul­ta­ti­ons­pha­se. Zunächst behan­deln wir in die­sem Arti­kel zwei Fragen:

  • Wen betref­fen die ZAIT?
  • Wie unter­schei­den sich die ZAIT von den ande­ren auf­sichts­recht­li­chen Anfor­de­run­gen an die IT?

Wen betref­fen die ZAIT?

Betrof­fen von den ZAIT sind Zah­lungs­in­sti­tu­te und E‑Geld-Insti­tu­te:

  • Zah­lungs­in­sti­tu­te:
    • Der­zeit sind etwa 70 Zah­lungs­in­sti­tu­te bei der Finanz­auf­sicht registriert
    • Zah­lungs­in­sti­tu­te betrei­ben gewerbs­mä­ßig Zah­lungs­diens­te wie z. B. Ein­zah­lungs- oder Aus­zah­lungs­ge­schäft, Lastschrift‑, Über­wei­sungs- oder Zah­lungs­kar­ten­ge­schäft ohne Kre­dit­ge­wäh­rung oder Zah­lungs­ge­schäft mit Kreditgewährung
    • Auch Anbie­ter von Zah­lungs­aus­lö­se­diens­ten oder Kon­to­in­for­ma­ti­ons­diens­ten zäh­len zu den Zahlungsinstituten
  • E‑Geld-Insti­tu­te:
    • Der­zeit sind neun E‑Geld-Insti­tu­te bei der Finanz­auf­sicht registriert
    • E‑Geld-Insti­tu­te bege­ben E‑Geld
    • E‑Geld ist der elek­tro­nisch, dar­un­ter auch magne­tisch, gespei­cher­te mone­tä­re Wert in Form einer For­de­rung an den Emit­ten­ten, der gegen Zah­lung eines Geld­be­trags aus­ge­stellt wird, um damit Zah­lungs­vor­gän­ge im Sin­ne des BGB durchzuführen

Somit han­delt es sich quan­ti­ta­tiv um eine eher klei­ne Zahl betrof­fe­ner Insti­tu­te, für die­se erfah­ren die vor­ge­ge­be­nen Anfor­de­run­gen aber eine deut­li­che Anspruchssteigerung.

Was sind die Gemein­sam­kei­ten und Unter­schie­de der ZAIT zu ande­ren auf­sichts­recht­li­chen Anforderungen?

Auch der grund­sätz­li­che Auf­bau bei­der Doku­men­te ist in sei­ner Struk­tur nahe­zu iden­tisch. Eben­so steht der Infor­ma­ti­ons­ver­bund bei den ZAIT im Mit­tel­punkt der Betrach­tun­gen. Aus bei­den Anfor­de­rungs­do­ku­men­ten her­aus gilt für die Insti­tu­te das Pro­por­tio­na­li­täts­prin­zip in der Umset­zung der gefor­der­ten Maßnahmen.

Was unter­schei­det die ZAIT von ande­ren regu­la­to­ri­schen Vor­ga­ben wie z. B. den BAIT? Fünf Punk­te fal­len hier auf und sol­len kurz betrach­tet wer­den. Sie betref­fen fol­gen­de Kapitel:

  • IT-Gover­nan­ce
  • Infor­ma­ti­ons­si­cher­heits­ma­nage­ment
  • IT-Pro­jek­te und Anwendungsentwicklung
  • Aus­la­ge­rung und sons­ti­ger Fremdbezug
  • Not­fall­ma­nage­ment

Im Zusam­men­hang mit der IT-Gover­nan­ce liegt die wesent­li­che Unter­schei­dung dar­in, dass eine Aus­rich­tung der IT an eta­blier­ten Stan­dards zu erfol­gen hat. Hier wer­den drei Stan­dards expli­zit genannt (IT-Grund­schutz des Bun­des­amts für Sicher­heit in der Infor­ma­ti­ons­tech­nik (BSI), die inter­na­tio­na­len Sicher­heits­stan­dards ISO/IEC 270XX der Inter­na­tio­nal Orga­niza­ti­on for Stan­dar­diza­ti­on und der Pay­ment Card Indus­try Data Secu­ri­ty Stan­dard (PCIDSS)).

Im Infor­ma­ti­ons­si­cher­heits­ma­nage­ment besteht die Mög­lich­keit, die Funk­ti­on des Infor­ma­ti­ons­si­cher­heits­be­auf­trag­ten mit ande­ren Funk­tio­nen im Unter­neh­men zu kom­bi­nie­ren oder, in beson­de­ren Fäl­len, auch außer­halb des Unter­neh­mens anzusiedeln.

Für IT-Pro­jek­te und Anwen­dungs­ent­wick­lung gibt es expli­zi­te Anfor­de­run­gen an die durch­zu­füh­ren­de Aus­wir­kungs­ana­ly­se und die Nut­zung des Begriffs „wesent­li­che Ver­än­de­rung“ im Zusam­men­hang mit Vor­ga­ben für die Testdurchführung.

Das Kapi­tel Aus­la­ge­rung und sons­ti­ger Fremd­be­zug ent­hält deut­lich umfang­rei­che­re Anfor­de­run­gen in den ZAIT als in den BAIT, die es zu berück­sich­ti­gen gilt.

Im Not­fall­ma­nage­ment wird die Not­wen­dig­keit zur Durch­füh­rung von Aus­wir­kungs­ana­ly­sen und Risi­ko­ana­ly­sen gefordert. 

Ers­te Schrit­te für Zah­lungs­in­sti­tu­te mit den ZAIT:

In einem ers­ten Schritt gilt es für die Zah­lungs­in­sti­tu­te und die E‑Geld-Insti­tu­te, ihre indi­vi­du­el­le Aus­gangs­si­tua­ti­on vor dem Hin­ter­grund der ZAIT zu ken­nen. Nur dann lässt sich der erfor­der­li­che Hand­lungs­be­darf identifizieren.

Vor­ran­gig gilt es, einen Über­blick über das eige­ne Insti­tut, die genutz­ten Aus­la­ge­run­gen sowie die Zah­lungs­dienst­nut­zer zu erhal­ten. Die­ses schließt auch den Infor­ma­ti­ons­ver­bund ein, der ein Nukle­us der ZAIT ist.

Inhalt­lich ste­hen fünf Hand­lungs­fel­der im Mit­tel­punkt der Erhebung.

ZAIT 2 RJO
  1. In wel­chem Umfang sind bereits Vor­be­fas­sun­gen zu Regu­la­to­ri­k­an­for­de­run­gen im Insti­tut erfolgt, z. B. durch eine inter­ne Erst­ana­ly­se oder die Jah­res­ab­schluss­prü­fung des Wirtschaftsprüfers?
  2. Wie steht es um die Gover­nan­ce des Insti­tuts, z. B. in Bezug auf eine durch­gän­gi­ge und doku­men­tier­te stra­te­gi­sche Aus­rich­tung oder ein eta­blier­tes inter­nes Kon­troll- und Prüfungswesen?
  3. Wird heu­te bereits auf eta­blier­te Stan­dards zurück­ge­grif­fen, auch über die in der ZAIT genann­ten hin­aus, z. B. ITIL oder Cobit?
  4. Wie trans­pa­rent sind die bestehen­den Aus­la­ge­run­gen tech­nisch und orga­ni­sa­to­risch und in wel­cher Form sind die­se in Kon­troll­pro­zes­se eingebunden?
  5. Wel­chen Stand hat die per­so­nel­le und tech­ni­sche Aus­stat­tung des Insti­tuts quan­ti­ta­tiv und qualitativ?

Die Ermitt­lung der Aus­gangs­si­tua­ti­on kann mit­tels eines Quick-Checks erfol­gen, um auf Grund­la­ge die­ser Infor­ma­tio­nen einen Über­blick über den erfor­der­li­chen Hand­lungs­be­darf zu erhal­ten und eine Indi­ka­ti­on für die Aus­ge­stal­tung des Pro­por­tio­na­li­täts­prin­zips zu gewinnen.

In einer Aus­bau­stu­fe kann sich eine Rei­fe­grad­ana­ly­se anschlie­ßen, für die es sich emp­fiehlt, die­se bereits an einen eta­blier­ten Stan­dard aus­zu­rich­ten, z. B. der ISO 27000-Reihe.

Neben der inhalt­li­chen Ana­ly­se zu den Kri­te­ri­en des Stan­dards ermög­licht ein sol­ches Vor­ge­hen auch eine Visua­li­sie­rung für das Management.

ZAIT 5 RJO

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 einer Viel­zahl von Regu­la­to­rik­pro­jek­ten bei Finanz­dienst­leis­tern gewähr­leis­ten die Sicher­stel­lung von Gover­nan­ce- und Regu­la­to­rik-Anfor­de­run­gen. Lang­jäh­ri­ge Pra­xis­exper­ti­se aus Pro­jekt- und Lini­en­tä­tig­keit bei Zah­lungs­in­sti­tu­ten schaf­fen den erfor­der­li­chen fach­li­chen, pro­zes­sua­len und tech­ni­schen Hintergrund.

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.