Kreativität durch Umdenken

Kreativität durch Umdenken

Schlech­te Ideen und der Weg zum Erfolg

Von Sup­port über Prä­sen­ta­tio­nen, bis hin zur Teil­nah­me an Work­shops und der Mode­ra­ti­on von Mee­tings: unse­re Arbeit besteht zu erheb­li­chen Tei­len aus Kom­mu­ni­ka­ti­on. So ste­hen wir immer vor der Her­aus­for­de­rung, krea­ti­ve Gesprächs­si­tua­tio­nen zu schaf­fen. Auch in der inter­nen Kom­mu­ni­ka­ti­on ist es uner­läss­lich, klas­si­sche For­ma­te wie Dai­lys oder Retro­spek­ti­ven für die Teil­neh­mer inter­es­sant und anre­gend zu gestal­ten, um mög­lichst viel krea­ti­ves Poten­zi­al freizusetzen.

Klassische Gesprächstechniken

Ein All-Time-Clas­sic unter den Gesprächs­tech­ni­ken ist das Brain­stor­ming. Die Teil­neh­mer wer­den dazu ermun­tert, ihren Ideen frei­en Lauf zu las­sen. Es geht dabei im ers­ten Schritt nicht um die qua­li­ta­ti­ve Bewer­tung die­ser Ideen, denn es sol­len ja gera­de unkon­ven­tio­nel­le, ori­gi­nel­le Gedan­ken Gehör fin­den. Aller­dings ver­lässt sich der Ansatz prin­zi­pi­ell dar­auf, dass die Teil­neh­mer die­se ori­gi­nel­len Gedan­ken auch abru­fen und arti­ku­lie­ren kön­nen. Es gibt jedoch eini­ge Fak­to­ren, die dem im Weg ste­hen können.

Was ist zum Bei­spiel, wenn die Teil­neh­mer ihre bes­ten Ideen bereits zum Aus­druck gebracht haben? Wich­ti­ge The­men inner­halb eines Pro­jekts tre­ten nor­ma­ler­wei­se nicht von jetzt auf gleich auf, die meis­ten Betei­lig­ten haben ver­mut­lich schon viel­fach über das The­ma nach­ge­dacht und sich eine fes­te Mei­nung gebil­det. Haben sich grund­sätz­li­che Annah­men und Ver­fah­rens­wei­sen erst ein­mal fest­ge­setzt, fällt es häu­fig schwer, die eige­ne Krea­ti­vi­tät noch­mal „auf Anfang“ zu stel­len. Auch kann es vor­kom­men, dass sich zu einem The­ma bereits nega­ti­ve Emo­tio­nen gebil­det haben, die eine offe­ne und auf­ge­schlos­se­ne Aus­ein­an­der­set­zung behindern. 

Neue Blickwinkel

In sol­chen Fäl­len kann es hilf­reich sein, den Gesprächs­teil­neh­mern einen Per­spek­tiv­wech­sel anzu­bie­ten, ja viel­leicht sogar deren poten­zi­ell nega­ti­ve Gefüh­le anzu­zap­fen. Wenn bei­spiels­wei­se Pro­ble­me an einem Pro­dukt beho­ben wer­den sol­len, kann die Per­spek­ti­ve eines ver­är­ger­ten Kun­den inter­es­san­te neue Ein­bli­cke geben. Wir stel­len uns also die Fra­ge, wie das Pro­dukt beschaf­fen sein müss­te, damit der Kun­de frus­triert auf­schreit: „Hier funk­tio­niert ja gar nichts!“ 

Obwohl wir immer noch über das glei­che The­ma – und eigent­lich auch die glei­che Fra­ge­stel­lung – reden, ergibt sich eine kom­plett neue Sicht­wei­se, die den Teil­neh­mern einen fri­schen Zugang ermög­licht. Hier befin­den wir uns bereits mit­ten im Rever­se Brain­stor­ming. Auch die­se Metho­de stammt – wie ihr Gegen­part – aus dem „Design Thin­king“. Die­ser Ansatz geht davon aus, dass die Lösung eines kom­ple­xen Pro­blems am bes­ten durch die Inter­ak­ti­on zwi­schen krea­ti­ven Men­schen aus ver­schie­de­nen Dis­zi­pli­nen erreicht wer­den kann, die gemein­sam einen struk­tu­rier­ten Pro­zess der Ideen­fin­dung durch­wan­dern. Wir set­zen uns also eine Fra­ge­stel­lung für unser ima­gi­nä­res Mee­ting und ver­keh­ren die­se dann ins Gegenteil.

Wie soll­te ein krea­ti­ves Mee­ting aus­se­hen, bei dem ein mög­lichst schlech­tes Ergeb­nis herauskommt?“

Die Doku­men­ta­ti­on eines Brain­stor­mings zu die­ser Fra­ge könn­te wie folgt aussehen.

Gegenteiltag im Meetingraum

  1. Legen Sie kei­ne Zie­le und Erwar­tun­gen für das Mee­ting fest. Um einen Miss­erfolg zu garan­tie­ren, soll­ten die Teil­neh­mer mög­lichst unstruk­tu­riert an das The­ma her­an­ge­hen, damit sich kei­ne gemein­sa­me Visi­on ent­wi­ckeln kann. Bit­ten sie die Teil­neh­mer dar­über hin­aus, sich nicht auf das The­ma vor­zu­be­rei­ten und stel­len Sie ihnen im Vor­feld kei­ne Mate­ria­li­en zur Ver­fü­gung. Eine knap­pe Anset­zung („in einer Stun­de im Mee­ting­raum!“) kann die­se Effek­te ver­stär­ken und men­ta­le sowie inhalt­li­che Vor­be­rei­tung erfolg­reich unterbinden.
  1. Auch die unsorg­fäl­ti­ge Aus­wahl der Teil­neh­mer ist ele­men­tar für ein Schei­tern. Die­se soll­ten alle aus dem­sel­ben Fach­be­reich stam­men und eine mög­lichst schma­le Band­brei­te an Per­spek­ti­ven in den Krea­tiv­pro­zess ein­brin­gen. Idea­ler­wei­se gibt der ers­te Teil­neh­mer ein State­ment ab und alle ande­ren schlie­ßen sich ihm kom­men­tar­los an. Ein sol­cher Krea­tiv­pro­zess kann schon inner­halb weni­ger Minu­ten zum Erlie­gen kommen.
  1. Mit einer unge­eig­ne­ten Mode­ra­ti­on kann die­ser Effekt noch ver­stärkt wer­den. Stil­le, intro­ver­tier­te Teil­neh­mer ver­su­chen häu­fig nicht aktiv, sich ins Gespräch ein­zu­brin­gen, gut so! Hier soll­te von­sei­ten der Gesprächs­füh­rung nicht inter­ve­niert wer­den, denn je weni­ger Teil­neh­mer sich äußern, des­to weni­ger krea­ti­ve Syn­er­gien kön­nen ent­ste­hen. Gera­de mei­nungs­star­ke Teil­neh­mer, die sich ger­ne selbst reden hören, soll­ten ermun­tert wer­den, das Mee­ting in eine One-Man-Show zu verwandeln.
  1. Schlech­tes Zeit­ma­nage­ment und nicht vor­han­de­ne Doku­men­ta­ti­on run­den jedes erfolg­lo­se Krea­tiv­mee­ting ab. Je län­ger sich mit den immer glei­chen Punk­ten beschäf­tigt wird, des­to unwahr­schein­li­cher wird ein krea­ti­ver Durch­bruch. Soll­te doch fünf Minu­ten vor dem Anschluss­ter­min jemand einen Geis­tes­blitz haben, kann die­ser lei­der nicht mehr aus­führ­lich bespro­chen wer­den. Da sowie­so kein kla­res Ziel for­mu­liert wur­de, ist das aber auch gar nicht schlimm. Wenn das Mee­ting dar­über hin­aus nicht schrift­lich fest­ge­hal­ten wird, ist sicher­ge­stellt, dass das Team beim nächs­ten mal wie­der exakt bei null anfängt.

Der diebische Spaß am Destruktiven

Das soll erst­mal rei­chen, obwohl noch eini­ge Punk­te hät­ten fol­gen kön­nen. Denn dem Leser mag auf­ge­fal­len sein, wie viel Spaß der Autor beim Schrei­ben die­ses Abschnitts hat­te. Tat­säch­lich lie­ßen sich die Absät­ze ein­fach so run­ter­schrei­ben und er muss­te sich kaum am Rie­men rei­ßen, um nicht gedank­lich abzu­schwei­fen. Dar­in wird die Kraft des Rever­se Brain­stor­mings deut­lich. Das Anzap­fen nega­ti­ver Gefüh­le wird – aus nach­voll­zieh­ba­ren Grün­den – eher sel­ten im Krea­tiv­pro­zess genutzt. Umso erfri­schen­der ist es, wenn man in der Phan­ta­sie mal so rich­tig die Welt bren­nen las­sen kann.

Nach­dem zu Beginn ein Pro­blem defi­niert wur­de, kön­nen wir final die erziel­ten Ergeb­nis­se ins Gegen­teil umkeh­ren, um Lösungs­vor­schlä­ge zu for­mu­lie­ren. Das soll­te nun kaum noch Schwie­rig­kei­ten berei­ten, da die Krea­tiv­ar­beit – ohne dass es sich wirk­lich so ange­fühlt hat – schon erle­digt ist.

Confluence und Jira in gewachsenen Kundenprojekten

Confluence und Jira in gewachsenen Kundenprojekten

SYST­HE­MIS at Work

Wir arbei­ten seit Lan­gem mit Con­fluence und Jira und haben uns über die Jah­re eine Exper­ti­se in der Ein­füh­rung und Betreu­ung der Tools in Kun­den­pro­jek­ten erar­bei­tet. Heu­te wol­len wir einen Ein­blick in unse­re Arbeit geben und auf häu­fi­ge Feh­ler und Miss­ver­ständ­nis­se hin­wei­sen, die bei der Ein­füh­rung zu beach­ten sind.

Warum Atlassian?

Die SYST­HE­MIS setzt aus guten Grün­den auf Atlas­si­an-Pro­duk­te, da sie sowohl was den Umfang, die Inter­kon­nek­ti­vi­tät sowie die Ska­lier­bar­keit betrifft, für jede Art von Pro­jekt – nicht nur in der Soft­ware­ent­wick­lung – eine umfas­sen­de Basis für gelun­ge­nes Pro­jekt­ma­nage­ment bie­ten. Eine gro­ße Stär­ke von Atlas­si­an-Tools ist ihre Fähig­keit, orga­nisch mit einem Kun­den­pro­jekt zu wach­sen. Das gilt sowohl für die indi­vi­du­el­le Kon­fi­gu­ra­ti­on der Werk­zeu­ge selbst, als auch für ihre Inter­kon­nek­ti­vi­tät. Jira kann bei­spiels­wei­se pro­blem­los in eine bestehen­de Con­fluence-Infra­struk­tur inte­griert wer­den, wenn zu einem spä­te­ren Zeit­punkt im Pro­jekt ein Bedarf ent­steht. Zudem ste­hen zahl­rei­che Erwei­te­run­gen zur Ver­fü­gung und auch eine Ver­bin­dung mit ande­ren Sys­te­men ist möglich.

All die­se Vor­tei­le und Mög­lich­kei­ten dür­fen jedoch nicht den Ein­druck erwe­cken, dass die Ein­füh­rung sowie ein grund­sätz­li­ches Ver­ständ­nis der Anwen­dun­gen allein schon eine Struk­tur in Unter­neh­mens­pro­zes­se brin­gen. Atlas­si­an Tools sind kei­ne Black­bo­xes, die man mit rele­van­ten Infor­ma­tio­nen füt­tert und die einem dann eine Road­map aus­spu­cken: es sind im bes­ten Sin­ne Werk­zeu­ge, die von Men­schen kom­pe­tent bedient wer­den müs­sen, um ihre vol­le Wir­kung zu entfalten.

Fallstricke bei der Implementierung

Die Ein­füh­rung von Con­fluence und/oder Jira läuft unse­rer Erfah­rung nach häu­fig so ab: eine oder meh­re­re Per­so­nen wer­den mit der Auf­ga­be betraut und befas­sen sich mit dem The­ma. Die Tools wer­den als ein Auf­ga­ben­be­reich ver­stan­den, der mög­lichst von einem klei­nen Team abge­deckt wer­den soll. Dabei haben die betrof­fe­nen Per­so­nen oft noch ande­re rele­van­te Funk­tio­nen im Unter­neh­men und sol­len die Betreu­ung der Platt­form zusätz­lich erle­di­gen. Schon bald nach der Ein­füh­rung beginnt die Platt­form zu wach­sen, neue Auf­ga­ben kom­men hin­zu, das „Unkraut“ sprießt. Der eigent­li­che Effekt, den man sich von einem Kol­la­bo­ra­ti­ons-Tool erhofft hat, näm­lich ein Mehr an Struk­tur, ein Mehr an Über­sicht­lich­keit, droht, sich ins Gegen­teil zu ver­keh­ren: anstatt dem Team Arbeit abzu­neh­men, ent­steht zusätz­li­che Arbeit.

Organisatorische Rahmenbedingungen

Um die­ses Pro­blem zu ver­mei­den, soll­te die Ein­füh­rung eines Kol­la­bo­ra­ti­ons-Tools von Beginn an auf meh­re­re orga­ni­sa­to­ri­sche Säu­len ver­teilt wer­den. Es ist uner­läss­lich, sich bereits zu Beginn die Fra­ge zu stel­len, wel­che Anfor­de­run­gen man an das Tool hat und wel­che The­men im spä­te­ren Ver­lauf noch hin­zu­kom­men könn­ten. Denn jedes The­ma bringt auch wei­te­re Auf­ga­ben mit sich und benö­tigt zusätz­li­che Res­sour­cen. Ist der Über­blick in einem gewach­se­nen Kun­den­pro­jekt erst ein­mal ver­lo­ren gegan­gen, führt oft kein Weg an einer grund­sätz­li­chen Neu­struk­tu­rie­rung vor­bei. Als Ori­en­tie­rung dient uns hier das ITIL v4 Framework.

Bereiche und Funktionen

Grund­sätz­lich lässt sich eine Unter­schei­dung zwi­schen tech­ni­schen und fach­li­chen The­men tref­fen. Auf der tech­ni­schen Sei­te ste­hen der Betrieb der Pro­duk­te sowie die tech­ni­sche Admi­nis­tra­ti­on. Im Betrieb geht es um The­men wie das Moni­to­ring auf Sys­tem­ebe­ne, Lizenz­be­schaf­fung, das Patch- und Update­ma­nage­ment, CR-Manage­ment und Ver­trags­con­trol­ling. Die Admi­nis­tra­ti­on dage­gen trägt die Gesamt­ver­ant­wor­tung für das Sys­tem. Von tech­ni­scher Bera­tung über War­tungs­auf­ga­ben bis hin zu Feh­ler- und Plug­in­ma­nage­ment lau­fen hier alle Fäden zusammen.

Der First und Second Level-Sup­port ist der zen­tra­le Ansprech­part­ner, an den die Nut­zer des Sys­tems sich wen­den kön­nen, um Tickets für alle mög­li­chen Anlie­gen auf­zu­ma­chen; wenn bei­spiels­wei­se neue Nut­zer oder Rech­te gebraucht wer­den, aber auch für neue Fea­tures und grund­sätz­li­che Fragen.

Fach­ad­mi­nis­tra­ti­on und Con­tent-Pfle­ge sind stets eng gekop­pelt mit der tech­ni­schen Admi­nis­tra­ti­on, da jede Neue­rung im Sys­tem indi­vi­du­ell kon­fi­gu­riert wer­den muss. Sie ist unter­stüt­zend tätig für neue Anfor­de­run­gen, die nicht auf dem First und Second Level lie­gen. Dabei kann es um die Struk­tu­rie­rung und Gestal­tung von Berei­chen in den Anwen­dun­gen gehen, oder auch um den Umgang mit Plug­ins und Makros.

Wie ver­hin­dert man nun aber das oben beschrie­be­ne Sprie­ßen von „Unkraut“? Anstatt die Nut­zer selbst wild drauf los arbei­ten zu las­sen, wer­den im Bereich Vor­la­gen und Plug­ins Stan­dards ange­legt: Bereichs- und Sei­ten­vor­la­gen wie bei­spiels­wei­se Pro­to­kol­le, Über­sichts­sei­ten, sowie vor­ausge­wähl­te Plug­ins. Die­ser Pro­zess soll­te in eine Art Vor­la­gen­ma­nage­ment mün­den, in die sinn­vol­le Ver­wal­tung und Wei­ter­ent­wick­lung sol­cher Vor­la­gen. Auch das The­ma Wor­ding spielt hier eine Rol­le: wie benen­ne ich mei­ne Sei­ten oder wie erzie­le ich ein­heit­li­che Sei­ten­struk­tu­ren, damit sich jeder über­all zurechtfindet?

Es emp­fiehlt sich auch, ein eige­nes Test­sys­tem ein­zu­füh­ren, um Plug­ins aus­pro­bie­ren zu kön­nen. Bei Tests im Pro­duk­tiv­sys­tem geht viel zu schnell der Über­blick ver­lo­ren und es ver­ur­sacht extra Arbeit im Nach­gang, wenn Plug­ins wie­der zurück­ge­baut wer­den müssen.

An die­ser Stel­le schlägt sich eine Brü­cke zum The­ma Pro­zes­se und Stan­dards, also zur Fra­ge: Wie arbei­te ich mit den Werk­zeu­gen? Wird bei­spiels­wei­se ein neu­es Jira-Pro­jekt benö­tigt, emp­fiehlt es sich, das in Con­fluence fest­zu­hal­ten, um den Vor­gang für die Nut­zer nach­voll­zieh­bar zu machen. Alle Wege füh­ren in Rich­tung Standardisierung.

Der Qua­li­täts­ma­na­ger ist der Gärt­ner in unse­rem Sys­tem. Er über­wacht und prüft, ob Pro­zes­se und Stan­dards gelebt, sowie Vor­la­gen gemäß den Vor­ga­ben ver­wen­det wer­den. Er hat das gro­ße Bild, das gan­ze Sys­tem im Blick. Gera­de in Jira besteht immer die Gefahr einer „Über­mül­lung“. Daher ist es wich­tig, eine neu­tra­le Stel­le zu instal­lie­ren, die prüft, ob Tickets oder Tei­le von Pro­jek­ten unbe­ar­bei­tet im Sys­tem lie­gen und gege­be­nen­falls ent­fernt wer­den können.

Rollen

Wie nun die beschrie­be­nen Berei­che auf kon­kre­te Rol­len ver­teilt wer­den, hängt von den indi­vi­du­el­len Vor­aus­set­zun­gen und Bedürf­nis­sen des jewei­li­gen Unter­neh­mens ab. In einem klas­si­schen Kick-Off wür­de der Bera­ter der SYST­HE­MIS mit dem Kun­den gemein­sam ein Kon­zept erar­bei­ten, wie die rich­ti­gen Exper­ten am bes­ten ein­zu­set­zen sind, um die Berei­che opti­mal abzu­de­cken. Unse­re Erfah­rung zeigt: ein geschul­ter Blick von außen ist häu­fig Gold wert, um Poten­zia­le zu erken­nen und opti­mal zu nutzen.

Das Kapazitäten UI

Das Kapazitäten UI

Tool zur Kapazitätenplanung

Die SYST­HE­MIS AG hat über vie­le Jah­re Erfah­run­gen in der Pla­nung von IT-Pro­jek­ten gesam­melt. Auf­bau­end auf die­ser Exper­ti­se haben wir ein eige­nes Tool zur Kapa­zi­tä­ten­pla­nung ent­wi­ckelt, das sowohl intern als auch in Kun­den­pro­jek­ten wert­vol­le Diens­te leis­tet: Das Kapa­zi­tä­ten UI (KAPA­ZUI).

Was ist KAPAZUI?

KAPA­ZUI ist ein Tool zur selbst­ge­steu­er­ten Kapa­zi­täts­ver­wal­tung. Es ermög­licht Mit­ar­bei­tern und Teams, schnel­len Über­blick über ihre Aus­las­tung und Kapa­zi­tä­ten zu bekom­men. Jeder Mit­ar­bei­ter ver­wal­tet sei­ne Kapa­zi­tä­ten selbst. Pro­jekt­lei­ter und Füh­rungs­kräf­te kön­nen auf einen Blick sehen, wie die Aus­las­tun­gen ihrer Mit­ar­bei­ter sind. Dabei legt Kapa­zui sehr viel Wert auf ein­fa­che, intui­ti­ve Bedie­nung und schnel­le Erken­nung von Aus­las­tun­gen über Farbcodierung.

Was macht KAPAZUI anders als andere Werkzeuge?

Alle Werk­zeu­ge, die wir bis dato ein­ge­setzt oder am Markt gefun­den hat­ten, haben nicht das gebo­ten, was wir als ganz wich­tig emp­fun­den haben: dass unse­re Mit­ar­bei­te­rin­nen und Mit­ar­bei­ter eigen­stän­dig in der Lage sind, ihre Kapa­zi­täts­pla­nung auf die Pro­jek­te im Detail vor­zu­neh­men. Das Pro­blem ist häu­fig, dass die Pla­nung zwar gemacht wird, aber dann irgend­wo ver­staubt. Daher haben wir bei KAPA­ZUI einen Fokus dar­auf gelegt, dass die Betrof­fe­nen selbst ein­grei­fen und reagie­ren kön­nen, wenn es im Pro­jekt Ver­schie­bun­gen gibt und umge­plant wer­den muss.

Wie ist der aktuelle Stand von KAPAZUI?

In den letz­ten Jah­ren ist viel pas­siert, vor allem was die Ober­flä­che angeht. Wir haben dar­an gear­bei­tet, das Frame­work neu anzu­pas­sen und die User Expe­ri­ence zu erhö­hen. Dafür wur­de ein moder­nes Gra­phi­cal User Inter­face auf­ge­baut, das intui­tiv in der Bedie­nung ist. Das ist ele­men­tar, weil das bes­te Werk­zeug nur so gut ist, wie die Infor­ma­tio­nen, die dar­in ste­cken. Wenn Mit­ar­bei­ter ger­ne mit einem Werk­zeug arbei­ten, dann wer­den die Infor­ma­tio­nen dar­in auch ger­ne aktua­li­siert. So ent­steht Mehrwert.

Außer­dem haben wir die Kon­nek­ti­vi­tät mit ande­ren Sys­te­men ver­bes­sert. Wir haben einen Excel-Import ein­ge­baut, weil in vie­len Berei­chen Excel immer noch füh­rend ist, sowie einen Import aus SAP byDe­sign, mit dem die meis­ten Mit­ar­bei­ter ihre Abwe­sen­hei­ten pfle­gen. Damit kön­nen immer mehr Infor­ma­tio­nen teil­au­to­ma­ti­siert oder voll­au­to­ma­ti­siert aus ande­ren Sys­te­men abge­ru­fen und in KAPA­ZUI zusam­men­ge­führt werden.

Für wen ist KAPAZUI als Werkzeug interessant?

KAPA­ZUI ist inter­es­sant für alle Unter­neh­men und Pro­jek­te – unab­hän­gig von der Bran­che – für jeden Ein­satz­zweck, wo sich fol­gen­de Fra­gen stel­len: wie vie­le Mit­ar­bei­ter arbei­ten an einem Pro­jekt, wann sind die­se Mit­ar­bei­ter gege­be­nen­falls nicht ver­füg­bar, wie vie­le Kapa­zi­tä­ten haben sie für Pro­jek­te im Grund­satz, die ein­ge­plant wer­den kön­nen und wie sieht ein soli­des Pro­jekt­ge­schäft in einem Unter­neh­men aus? je unüber­sicht­li­cher es wird, des­to bes­ser ist KAPA­ZUI ein­setz­bar. Es ist das idea­le Werk­zeug, um alle rele­van­ten Infor­ma­tio­nen zusam­men­zu­brin­gen und eine ver­läss­li­che Aus­sa­ge dar­über tref­fen zu kön­nen, wie vie­le Kapa­zi­tä­ten ein­zel­ne Per­so­nen heu­te und per­spek­ti­visch auf den Betrach­tungs­zeit­raum zur Ver­fü­gung haben.

Struktur von Beginn an

Struktur von Beginn an

Fort­bil­dun­gen in der SYSTHEMIS

SYST­HE­MIS-Exper­ten arbei­ten in ver­ant­wor­tungs­vol­len Posi­tio­nen in ver­schie­dens­ten Pro­jek­ten. Um den Ansprü­chen unse­rer Kun­den gerecht zu wer­den, ist ste­ti­ge Wei­ter­bil­dung und die Opti­mie­rung unse­rer Abläu­fe uner­läss­lich. In einer zwei­tä­gi­gen Schu­lung mit der Exper­tin Sabi­ne Zehn­der-Samu­els haben wir unse­re Kennt­nis­se in die­sem Bereich auf den neu­es­ten Stand gebracht und auch unse­re bewähr­ten Pro­zes­se auf den Prüf­stand gestellt.

Was ist Requirements-Engineering?

Der Grund­stein für den Erfolg jedes ambi­tio­nier­ten Pro­jekts wird bereits ganz zu Beginn mit dem Erar­bei­ten der rich­ti­gen Anfor­de­run­gen gelegt. Was will der Kun­de? Weiß er über­haupt genau, was er will? Und spre­chen alle Stake­hol­der die­sel­be Spra­che, wenn es um die For­mu­lie­rung der gemein­sa­men Zie­le geht? Der Schlüs­sel zu all die­sen Fra­gen ist das Requi­re­ments-Engi­nee­ring.  Zur grund­le­gen­den Begriffs­klä­rung wer­fen wir einen Blick in die Defi­ni­ti­on des Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board (IREB):

Das Requi­re­ments-Engi­nee­ring ist ein sys­te­ma­ti­scher und dis­zi­pli­nier­ter Ansatz zur Spe­zi­fi­ka­ti­on und zum Manage­ment von Anfor­de­run­gen mit den fol­gen­den Zie­len: die Wün­sche und Bedürf­nis­se der Stake­hol­der zu ver­ste­hen und das Risi­ko zu mini­mie­ren, ein Pro­dukt, das nicht die­se Wün­sche und Bedürf­nis­se erfüllt, auszuliefern.“ *

Zu Beginn der Schu­lung gab ein dif­fe­ren­zier­ter Blick auf die Dimen­sio­nen des Requi­re­ments Engi­nee­ring als Dis­zi­plin bereits wich­ti­ge Erkennt­nis­se. Denn es ist dabei lan­ge nicht getan mit rei­nem Anfor­de­rungs­ma­nage­ment. Requi­re­ments-Engi­nee­ring ist die Sum­me aus ver­schie­de­nen Teil­dis­zi­pli­nen: wie erhe­be ich Anfor­de­run­gen, wie doku­men­tie­re ich sie, wie mana­ge ich sie und wie siche­re ich Qua­li­tät? Dabei wird bereits in den ers­ten Schrit­ten, der Erhe­bung und Doku­men­ta­ti­on von Anfor­de­run­gen, der Grund­stein für ein gelun­ge­nes Pro­jekt gelegt. Wenn in IT-Pro­jek­ten Bud­gets oder Dead­lines über­schrit­ten wer­den, liegt dies häu­fig dar­an, dass im Lau­fe des Ent­wick­lungs­pro­zes­ses noch Anfor­de­run­gen über­ar­bei­tet wer­den müs­sen, weil sich her­aus­stellt, dass bereits bei deren Erhe­bung und Doku­men­ta­ti­on Miss­ver­ständ­nis­se ent­stan­den sind, die dann durch die fol­gen­den Pro­jekt­pha­sen mit­ge­schleppt wurden.

Die Rolle des Requirements-Engineers

Das Ent­ste­hen sol­cher Miss­ver­ständ­nis­se im gesam­ten Pro­jekt zu ver­hin­dern, ist Auf­ga­be des Requi­re­ments-Engi­neers. Des­sen Rol­le ist am ehes­ten als die eines Ver­mitt­lers zu sehen, der die Inter­es­sen und Wün­sche aller Stake­hol­der jeder­zeit im Blick hat und der idea­ler­wei­se die Spra­che aller Betei­lig­ter glei­cher­ma­ßen zu spre­chen ver­mag. Im inners­ten Kreis des Pro­jek­tes arbei­tet er mit abso­lu­ten Fach­ex­per­ten zusam­men, wei­ter außen sitzt die Pro­jekt­lei­tung, dann fol­gen die Abtei­lungs­lei­tung und letzt­lich ganz außen die Ent­schei­der. Der Requi­re­ments-Engi­neer ist damit gewis­ser­ma­ßen die kom­mu­ni­ka­ti­ve Schalt­zen­tra­le des gesam­ten Pro­jekts, wo alle Fäden zusam­men­lau­fen. Er ist dafür ver­ant­wort­lich, dass auch der Geschäfts­füh­rer ver­steht, wovon der inners­te Kreis der Ent­wick­ler spricht. Die­se Rol­le lässt sich nicht her­un­ter­bre­chen auf das blo­ße Abschrei­ben von Anfor­de­run­gen: es geht um einen erheb­li­chen Mehr­auf­wand, der sich letzt­lich jedoch lohnt.

Des­halb ist größ­te Skep­sis ange­bracht, wenn es von Kun­den­sei­te heißt: „Das macht der Pro­jekt­lei­ter oder Pro­dukt­ma­na­ger mit.“ Genau die­se Her­an­ge­hens­wei­se führt näm­lich häu­fig dazu, dass die Rol­le stief­müt­ter­lich behan­delt wird. Es ist wich­tig, sich bewusst zu machen, dass ein Pro­jekt nicht mit dem Kick­off-Work­shop beginnt. Die wich­tigs­te Arbeit des Requi­re­ments-Engi­neers fin­det weit vor­her statt.

Methoden

Um den Stake­hol­dern die für ihn rele­van­ten Infor­ma­tio­nen zu ent­lo­cken, bedient sich der Requi­re­ments-Engi­neer ver­schie­dens­ter Metho­den, vor allem aus dem Bereich der Psy­cho­lo­gie. Ob Fra­ge­bö­gen – wie bei­spiels­wei­se die Del­phi-Metho­de – Inter­views oder Beob­ach­tungs­tech­ni­ken: rich­tig ange­wen­det lie­fern sie ihm ziel­ge­nau das gesuch­te Wis­sen und hel­fen ihm, den Stake­hol­der, des­sen Wis­sens­stand und des­sen Wün­sche bes­ser zu verstehen.

Das kann von Pro­jekt zu Pro­jekt kom­plett unter­schied­lich aus­se­hen. Mög­li­cher­wei­se bekom­men wir bereits einen Use Case, den es zu erfül­len gilt, oder es besteht bereits ein Stan­dard­pro­dukt, auf dem wir auf­bau­en sol­len. Es gibt aber auch Pro­jek­te, in denen die Stake­hol­der zu Beginn noch kei­ne kon­kre­te Vor­stel­lung vom gewünsch­ten End­pro­dukt haben. Bei einem sol­chen Start auf der grü­nen Wie­se bie­ten sich Krea­tiv­tech­ni­ken wie Brain­stor­ming oder Mind-Map­ping an, um gemein­sam eine Visi­on zu ent­wi­ckeln. Akku­ra­te und ziel­ge­rich­te­te Kom­mu­ni­ka­ti­on, kom­bi­niert mit der Aus­wahl der rich­ti­gen kom­mu­ni­ka­ti­ven Werk­zeu­ge, sind das A und O des Requirements-Engineers.

Requirements-Engineering in unserem Arbeitsalltag

Wir haben fest­ge­stellt, auch durch die Erkennt­nis­se der Schu­lung, dass wir als Pro­duct-Owner, Pro­jekt­lei­ter oder Orga­ni­sa­ti­ons­be­ra­ter in der Ver­gan­gen­heit häu­fig Auf­ga­ben eines Requi­re­ments-Engi­neers mit­über­nom­men haben, obwohl die Rol­le im Pro­jekt so nur teil­wei­se oder gar nicht vor­ge­se­hen war. Das zeigt, wie die Rele­vanz und Trag­wei­te die­ser Funk­ti­on immer noch mas­siv unter­schätzt wer­den. Das umfas­sen­de Manage­ment von Anfor­de­run­gen ist nichts, was man neben­bei machen kann. Eine kla­re Abgren­zung ist hier wich­tig, schon allein auf­grund des gro­ßen Auf­wands, den die­se Rol­le mit sich bringt. Es ist unrea­lis­tisch, zu erwar­ten, dass mit einem Work­shop beim Kun­den mal neben­bei Anfor­de­run­gen erho­ben wer­den kön­nen, die dann auch noch ein­deu­tig sind und als Basis für das gan­ze Pro­jekt ausreichen.

Des­halb haben wir beschlos­sen, die­se Erkennt­nis­se in unse­re lau­fen­den und zukünf­ti­gen Pro­jek­te zu tra­gen und einen dem­entspre­chen­den Werk­zeug­kas­ten in der SYST­HE­MIS ein­zu­füh­ren, aus dem wir uns alle bedie­nen kön­nen. Wir haben bereits Tem­pla­tes erar­bei­tet, die jetzt stan­dar­di­siert wer­den. Das soll zu einem Best Prac­ti­ce füh­ren, zu einem all­ge­mei­nen Leit­fa­den auf Basis eines Tool­sets wie Con­fluence und Jira. Im Ergeb­nis wird es ein ein­heit­li­ches und abge­stimm­tes Vor­ge­hen geben, wie wir in bestehen­den Pro­jek­ten dahin­ge­hend nach­steu­ern kön­nen und wie wir neue Pro­jek­te aufsetzen.

* Rupp, Chris und die SOPHIS­Ten: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Das Hand­buch für Anfor­de­run­gen in jeder Situa­ti­on, 7. Auf­la­ge, Nürn­berg, Deutsch­land, Han­ser, 2020, S.18.

Entwicklungshilfe in der SYSTHEMIS

Entwicklungshilfe in der SYSTHEMIS

Der Mikro­kre­di­te-Cir­cle

Seit 2019 bie­tet die SYST­HE­MIS AG ihren Mit­ar­bei­te­rin­nen und Mit­ar­bei­tern die Mög­lich­keit, orga­ni­siert in klei­nen Arbeits­grup­pen selbst Ver­ant­wor­tung für ein gemein­sa­mes The­ma zu über­neh­men und so das Betä­ti­gungs­feld und das Pro­fil des gesam­ten Unter­neh­mens mit­zu­prä­gen. Heu­te wol­len wir den Mikro­kre­di­te-Cir­cle vor­stel­len, der sich der Ent­wick­lungs­hil­fe in bedürf­ti­gen Regio­nen widmet.

Eine Idee verändert die Welt

Es kann kei­nen ech­ten Frie­den geben, wenn gro­ße Tei­le der Bevöl­ke­rung kei­nen Weg aus der Armut fin­den.“ Mit die­sen Wor­ten begrün­de­te das Oslo­er Nobel­ko­mi­tee 2006 sei­ne Ent­schei­dung, den Frie­dens­no­bel­preis über­ra­schend an einen Öko­no­men aus Ban­gla­desch zu ver­ge­ben, und führ­te wei­ter aus: „Eine posi­ti­ve öko­no­mi­sche Ent­wick­lung ist der Garant für Men­schen­rech­te. Auch kann man kein voll­wer­ti­ges Wachs­tum und Demo­kra­tie errei­chen, wenn die Hälf­te der Men­schen, die Frau­en, nicht gleich­be­rech­tigt ist.“

Der Name des Preis­trä­gers war Muham­mad Yunus und sei­ne Idee so sim­pel wie bahn­bre­chend: schon mit gerin­gen Beträ­gen kann ein mit­tel­lo­ser Mensch in einer armen Regi­on der Welt, der eine Geschäfts­idee hat, die ers­ten gro­ßen Schrit­te aus sei­ner unver­schul­de­ten Abhän­gig­keit gehen. Nur ver­ge­ben gewöhn­li­che Ban­ken kei­ne Kre­di­te an Mit­tel­lo­se, schon gar nicht ohne Sicher­hei­ten. Und so lieh Yunus den Men­schen in sei­ner Nach­bar­schaft zunächst sein eige­nes Geld. Nach den ers­ten Erfol­gen schaff­te es der jun­ge Öko­no­mie­pro­fes­sor 1976, sei­ne Uni­ver­si­tät in Chit­ta­gong davon zu über­zeu­gen, die Kre­dit­ver­ga­be als Ent­wick­lungs­pro­jekt wei­ter­zu­füh­ren, was 1983 gar in der Grün­dung der Gra­meen Bank mün­de­te, eines Kre­dit­in­sti­tuts, das sich allein der Ver­ga­be von Mikro­kre­di­ten ver­schrieb und des­sen ers­ter Mana­ging Direc­tor Muham­mad Yunus wurde.

Mehr als eine Spende

Mitt­ler­wei­le gibt es zahl­rei­che Orga­ni­sa­tio­nen und Insti­tu­te, die das Kon­zept über­nom­men haben und welt­weit Mikro­kre­di­te ver­ge­ben. Im digi­ta­len Zeit­al­ter kön­nen Kre­dit­ge­ber per Online­platt­form gezielt aus tau­sen­den Klein­un­ter­neh­mern und Pri­vat­pe­rao­nen in den ver­schie­dens­ten Regio­nen der Welt die­je­ni­gen aus­su­chen, deren Geschäfts­mo­dell sie unter­stüt­zen wol­len. Doch wie kam die SYST­HE­MIS dazu, einen Cir­cle für Mikro­kre­di­te zu grün­den? Dar­über haben wir mit Grün­dungs­mit­glied Micha­el Amt­hor gesprochen:

Ich habe den Vor­schlag damals für unse­re jähr­li­che Weih­nachts­spen­de ein­ge­bracht. Er kam gut an, aber da wir in dem Rah­men vor allem regio­na­le Orga­ni­sa­tio­nen und Pro­jek­te unter­stüt­zen, pass­te es nicht rich­tig rein. Des­halb haben wir als SYST­HE­MIS beschlos­sen, uns dop­pelt zu enga­gie­ren und zusätz­lich zur Weih­nachts­spen­de den Cir­cle Mikro­kre­di­te gegrün­det. Ich fand die Idee geni­al. Viel nach­hal­ti­ger geht es nicht, denn man kann das­sel­be Geld ja immer wie­der ver­lei­hen, sobald es zurück­ge­zahlt wur­de. Man kann ja dau­er­haft Gutes tun mit den immer sel­ben 1000 Dollar.“

Schlagzeuge und Waschmaschinen

Und mit genau die­sem Start­ka­pi­tal begann es. Die SYST­HE­MIS betei­lig­te sich mit jeweils 25 oder 50 Dol­lar pro Mikro­kre­dit, viel Aus­wahl also für die Mit­glie­der des Cir­cles, die immer dann zusam­men­kom­men, wenn ein gro­ßer Teil des Gel­des zurück­ge­zahlt wur­de, um sorg­sam neue Pro­jek­te aus­zu­wäh­len. Micha­el Amt­hor gewährt einen Ein­blick in die­sen Prozess:

Für gewöhn­lich set­zen wir uns zusam­men und jeder bringt Vor­schlä­ge ein, die er unter­stüt­zens­wert fin­det. Das kann aus allen mög­li­chen Sek­to­ren sein: Bil­dung, Kunst, täg­li­cher Bedarf. Wir legen Wert dar­auf, Leu­te zu unter­stüt­zen, die mit dem Kre­dit etwas auf die Bei­ne stel­len wol­len, ger­ne auch nach­hal­tig. Wenn jemand sei­nen Fami­li­en­be­trieb aus­bau­en will, Saat­gut oder Dün­ger für sei­ne Farm benö­tigt, in die Bil­dung sei­ner Kin­der inves­tie­ren will, ein Lap­top für sein Stu­di­um benö­tigt, dann haben wir ein gutes Gefühl bei der Sache.

Was die Län­der betrifft, ver­lei­hen wir haupt­säch­lich in arme Regio­nen der Welt, wo wir das Gefühl haben, dass wir mit unse­ren gerin­gen Sum­men wirk­lich etwas bewe­gen kön­nen: das kann ein Musi­ker aus dem Koso­vo sein, der mit einem neu­en Schlag­zeug auf Dorf­fes­ten den Men­schen eine Freu­de berei­tet und dabei noch sei­nen Lebens­un­ter­halt bestrei­tet. Das kann eine Frau aus Peru sein, die mit dem Kauf einer Wasch­ma­schi­ne einen eige­nen Wasch­sa­lon eröff­net und damit ihre gan­ze Fami­lie ernährt.“

Ein Circle für die Zukunft

Drei Jah­re und über 70 Mikro­kre­di­te spä­ter ist die Arbeits­grup­pe ein vol­ler Erfolg. Knapp vier­mal wur­de das Start­ka­pi­tal inzwi­schen neu ver­lie­hen, nur 41 Dol­lar Ver­lust ste­hen in der Bilanz. Die­se sind aller­dings zurück­zu­füh­ren auf schwan­ken­de Umtausch­ra­ten, denn zurück­ge­zahlt wur­den die Kre­di­te alle­samt. Damit bestä­tigt sich, was Muham­mad Yunus schon vor fast einem hal­ben Jahr­hun­dert wuss­te: Wer Armut bekämp­fen will, der muss in Men­schen inves­tie­ren: in ihre Talen­te, in ihre Träu­me und in den unbän­di­gen Wil­len, das Leben jeden Tag ein Stück bes­ser zu machen.