Schlagwort: Management

Skills MHL

Mitarbeiterqualifikation in Banken – Was fordert die Zukunft?

Am 2. Sep­tem­ber las ich einen inter­es­san­ten Arti­kel zum The­ma „IT-Skills im Ban­king”. Der ein­gän­gi­ge Titel lautet:

„If you want a ban­king job now, you need to code in Python”

Mia Hol­mes, https://​www​.efi​nan​cial​ca​re​ers​.com/​n​e​w​s​/​2​0​2​1​/​0​8​/​p​y​t​h​o​n​-​f​o​r​-​b​a​n​k​i​n​g​-​j​obs, 1. August 2021

Die Autorin schrieb dar­in über den Wan­del der Anfor­de­run­gen an Mit­ar­bei­ter in Ban­ken: „Weg von Excel – hin zu Python”. Gut: ob nun Python das künf­ti­ge Ana­ly­se­tool ist oder nicht sei dahin­ge­stellt. Die Bot­schaft hal­te ich jedoch für valide.

Die Anfor­de­run­gen an die Mit­ar­bei­ter im Finanz­dienst­leis­tungs­sek­tor in Bezug auf IT-Kennt­nis­se wer­den und müs­sen steigen!

Der Arti­kel brach­te mich dazu, über das The­ma wei­ter nach­zu­den­ken, weil es mich bereits seit län­ge­rem beweg­te. Eini­ge Lese­rin­nen und Leser aus dem Kreis mei­ner Kun­den wis­sen das, da wir bereits gemein­sam dar­über philosophierten 😉

Ein klei­ner Rück­blick sei gestat­tet: Als ich im Sep­tem­ber 1994 mei­ne Bank­leh­re begann, war die Welt noch „in Ordnung”:

  • Papier soweit das Auge reichte
  • Ter­mi­nals zur Online-Abfra­ge von Kon­ten und Kunden
  • Eine Erfas­sungs­mög­lich­keit für Kon­ten, usw.
  • Das zen­tra­le Instru­ment „Schreib­ma­schi­ne”

Am Ende mei­ner Aus­bil­dung stieg ich in die neu gegrün­de­te Abtei­lung „Elec­tro­nic Ban­king” ein: Wir waren ein Team von anfangs zwei Leu­ten. Mein Chef (22 Jah­re) und ich (21). Außer eini­gen Mit­ar­bei­tern in der Abtei­lung Orga­ni­sa­ti­on wuss­te so gut wie nie­mand, was wir da trie­ben. Und wir hat­ten bereits E‑Mail und Internet! 🙂

Nun – die Zei­ten haben sich gewan­delt. Inzwi­schen ist so ziem­lich jedem klar, dass die IT neben der Res­sour­ce „Mensch” der wich­tigs­te Pro­duk­ti­ons­fak­tor der Bank ist. Ja – ich gehe so weit zu behaup­ten: Ban­ken sind fak­tisch IT-Unter­neh­men! Folg­lich liegt es doch nahe, dass viel­leicht abge­se­hen vom direk­ten Kun­den­ver­trieb in nahe­zu allen Tätig­keits­be­rei­chen der Bank Mit­ar­bei­ter mit IT-Kennt­nis­sen benö­tigt wer­den. Und damit mei­ne ich nicht, Excel benut­zen zu kön­nen, auch wenn es hier noch gro­ßen Nach­hol­be­darf gäbe (nicht nur bei Ban­ken und Spar­kas­sen). Wenn wir über Zukunfts­the­men – nein – aktu­el­le The­men wie „Machi­ne Lear­ning” und „Data-Sci­ence” reden, soll­ten wir uns ehr­lich fra­gen: Wer in den Ban­ken und Spar­kas­sen kennt sich denn heu­te wirk­lich mit die­sen The­men aus, kann sie auch anwen­den, geschwei­ge denn beherrschen?

  • Akqui­si­ti­on: Die klas­si­sche Ziel­grup­pen­se­lek­ti­on hat aus­ge­dient. Gute Pro­dukt­emp­feh­lun­gen erfor­dern Data-Sci­ence-basier­te Ansät­ze und den Ein­satz von KI
  • Kre­dit­ent­schei­dun­gen: KI’s wer­den künf­tig ein­fach bes­ser sein als jeder Mensch, wenn es um Bilanz­ana­ly­sen geht
  • Kon­troll­hand­lun­gen im Back­of­fice: Las­sen sich kos­ten­güns­ti­ger und in bes­se­rer Qua­li­tät maschi­nell abwickeln
  • Fraud Detec­tion: Daten­sät­ze fern­ab vor­ab fest­ge­leg­ter Mus­ter klas­si­fi­zie­ren und so Risi­ken schnel­ler erkennen

Die Lis­te lie­ße sich noch eine Wei­le fort­set­zen, das haben jedoch schon Ande­re getan. Sei­en wir ehr­lich: Da ist die Luft sehr dünn. Im Bereich der Geld­au­to­ma­ten­über­wa­chung und Fraud Detec­tion ent­wi­ckeln Spe­zia­lis­ten schon ent­spre­chen­de Lösun­gen. Jedoch ste­cken vie­le Pro­jek­te der­zeit noch in den Kin­der­schu­hen und erst recht bei wirk­lich span­nen­den The­men wie der Fra­ge, wie Kun­den­be­dürf­nis­se und damit Ver­kaufs­chan­cen wirk­lich bes­ser erkannt wer­den kön­nen, wird die Luft wirk­lich dünn.

Es genügt also nicht, sich als Bank bzw. Spar­kas­se dar­auf zu ver­las­sen, dass der Markt schon „irgend­wann” ent­spre­chen­de Lösun­gen anbie­tet, die dann „schlüs­sel­fer­tig” ein­ge­baut bzw. genutzt wer­den kön­nen. Denn spä­tes­tens zu die­sem Zeit­punkt ste­hen die­se Lösun­gen dann auch dem Wett­be­werb zur Verfügung!

Nein, die Lösung muss lau­ten: Jetzt selbst aktiv werden!

  • Eine eige­ne Mann­schaft auf­bau­en und „fri­sche Köp­fe” her­ein holen
  • Dem Team ent­spre­chen­de Tools und Platt­for­men im eige­nen Haus zur Ver­fü­gung stellen
  • Test­be­stän­de auf Basis der vor­han­de­nen Daten auf­bau­en und absichern
  • Aus Schlag­wor­ten end­lich kon­kre­te Ideen ent­wi­ckeln und zügig verproben
  • Kon­se­quen­te Inte­gra­ti­on der Lösun­gen in die vor­han­de­ne Systemlandschaft

Aufbau einer eigenen Mannschaft

Aus­ge­hend von mei­ner Ein­lei­tung müs­sen Kre­dit­in­sti­tu­te also end­lich begin­nen, sich als IT-Unter­neh­men zu betrach­ten. Dazu gehört neben der Fort­bil­dung der vor­han­de­nen Mit­ar­bei­ter vor allem, IT-Exper­ten ein­zu­stel­len und zu inte­grie­ren. Und natür­lich bedeu­tet das auch, die­sen Men­schen ent­spre­chen­de Arbeits­be­din­gun­gen zu bieten.

Tipp: jun­ge Men­schen las­sen sich mit Pro­zes­sen, Arbeits­an­wei­sun­gen und Vor­schrif­ten wie „Rei­se­kos­ten­ab­rech­nung mit drei­fa­cher Unter­schrift der Vor­ge­setz­ten, des Paps­tes und der eige­nen Mut­ter” rich­tig toll motivieren 😉

Tools und Entwicklungplattformen

Vor allem Spar­kas­sen und Volks­ban­ken sind hier an einem Punkt, der erheb­li­ches Know-how und Durch­set­zungs­ver­mö­gen der Betei­lig­ten erfor­dert. Sind über­haupt adäqua­te Test­um­ge­bun­gen vor­han­den? Wer betreibt die­se? Wie sind sie abge­si­chert und wie schnell kön­nen sie an neue Anfor­de­run­gen ange­passt wer­den? Hier ist das Manage­ment gefragt, die Teams bei der Beschaf­fung der Res­sour­cen zu unter­stüt­zen und ent­spre­chen­de Anfor­de­run­gen auch bei den IT-Dienst­leis­tern zu vertreten.

Wei­ter­hin müs­sen Big-Data-taug­li­che Daten­bank­sys­te­me beschafft und Ent­wick­lungs­tools bereit­ge­stellt wer­den. Die Ent­wick­ler benö­ti­gen aus­rei­chend Frei­raum, um Biblio­the­ken selbst­stän­dig nach­zu­in­stal­lie­ren. Das Insti­tut muss dabei selbst­ver­ständ­lich in der Lage sein, die dar­aus ent­ste­hen­den Risi­ken zu mana­gen. Auch hier ist es erfor­der­lich, ent­spre­chen­de Exper­ti­se im Haus zu haben:

  • Fach­leu­te für Systemsicherheit
  • Data-Sci­en­tists
  • Daten­bank­ex­per­ten
  • Fach­leu­te für Systemintegration

Testbestände aufbauen

Was ist das wich­tigs­te Asset der Ban­ken und Spar­kas­sen? Das Ver­trau­en der Kunden!

Von regu­la­to­ri­schen Anfor­de­run­gen ein­mal abge­se­hen soll­te es selbst­ver­ständ­lich sein, dass der Schutz der Daten­be­stän­de des Insti­tuts obers­te Prio­ri­tät hat und dem­entspre­chend erfor­dert der Auf­bau brauch­ba­rer anony­mi­sier­ter Test­be­stän­de Exper­ten­wis­sen und kann nicht „neben­bei” gesche­hen. Not­wen­dig sind hier Fach­leu­te im Bereich: 

  • Test­ma­nage­ment und 
  • Sys­tem­si­cher­heit

Entwicklung konkreter Ideen

Um sinn­vol­le Lösun­gen zu fin­den müs­sen Pro­dukt­ent­wick­ler der Bank und IT-Fach­leu­te zusam­men­ar­bei­ten. Und natür­lich auch den End­kun­den ein­be­zie­hen. Zum The­ma „Kun­den­ori­en­tie­rung” und „Design Thin­king” wur­de wahr­haf­tig schon viel publi­ziert und sin­niert. Ich ver­mei­de jetzt ein­fach mal bewusst, irgend­ein Zitat von Ste­ve Jobs ein­zu­bau­en 😉 . Unbe­strit­ten ist, dass agi­le Ent­wick­lungs­pro­zes­se hier hel­fen und zwin­gend ein­zu­set­zen sind, um nicht „am Kun­den vor­bei” zu laborieren.

  • Exper­ten für Produktinnovation
  • Bank­fach­li­che Wissensträger
  • Mit­ar­bei­ter mit ent­spre­chen­den Skills in agi­len Metho­den und „Soft Skills” zur Steue­rung die­ser hete­ro­ge­nen Teams

Konsequente Integration der Lösungen

Zu guter Letzt muss auch geplant sein, wie eine fer­ti­ge Lösung in die haus­ei­ge­nen Pro­zes­se und Sys­tem­land­schaft inte­griert wer­den kann.

Nach aus­gie­bi­gen Tests, einer IT-Sicher­heits­prü­fung, Prü­fun­gen von Daten­schutz­be­lan­gen usw. müs­sen Pro­duk­ti­ons­sys­te­me auf­ge­baut und betrie­ben wer­den. Auch hier kann die Kom­ple­xi­tät sehr unter­schied­lich sein: Im ein­fachs­ten Fall wer­den Daten manu­ell zum Bei­spiel für Kam­pa­gnen in sepa­ra­te Tools über­führt, aus­ge­wer­tet und das Ergeb­nis in die vor­han­de­nen Kam­pa­gnen­werk­zeu­ge der Bank impor­tiert. Bei Anwen­dungs­sze­na­ri­en, die regel­mä­ßi­ge auto­ma­ti­sche Ver­ar­bei­tun­gen von Pro­duk­ti­ons­da­ten vor­se­hen, sind Ver­ar­bei­tungs­pipe­lines zu imple­men­tie­ren und zu betreu­en. Auch hier sind Fach­leu­te mit IT-Kennt­nis­sen und Kennt­nis­sen in der Regu­la­to­rik notwendig:

  • Fach­kräf­te in den Bereichen
  • IT-Sicher­heit und Datenschutz
  • Sys­tem­in­te­gra­ti­on
  • Anwendungsbetrieb/Application Manage­ment und/oder Providersteuerung

Fazit

Will sich eine Bank oder Spar­kas­se ernst­haft der Zukunft stel­len und neue, inno­va­ti­ve Ansät­ze ent­wi­ckeln, muss dem Manage­ment klar sein, dass ein völ­lig neu­er Typus von Mit­ar­bei­tern erfor­der­lich ist.

  • Die Rekru­tie­rung von Mit­ar­bei­tern erfor­dert auch Erfah­rung, erwei­ter­te Exper­ti­se im Personalwesen 
  • Es reicht nicht, allein auf die eige­nen bewähr­ten IT-Dienst­leis­ter zu warten 
  • Klei­ne­re Insti­tu­te soll­ten Koope­ra­tio­nen inner­halb der eige­nen Insti­tuts­grup­pe eingehen/aufbauen wenn klar ist, dass sie selbst nicht die aus­rei­chen­de Grö­ße besit­zen, um die­se Her­aus­for­de­run­gen allein zu meistern

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
http://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­coin 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­li­nes 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­tr­ums­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 Enab­ler, 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 Fin­Techs 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 Sourcingstra­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
http://www.ban​kon​.de
E‑Mail: research@bankon.de


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­niz­a­ti­on for Stan­dar­di­z­a­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­rik­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­ex­per­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.

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
http://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
http://www.ban​kon​.de
E‑Mail: research@bankon.de