Miteinander statt Nebeneinander

Die Pro­zes­se und die Struk­tu­ren zur Wei­ter­ent­wick­lung der IT-Sys­tem­land­schaf­ten sind in vie­len gro­ßen Indus­trie­un­ter­neh­men qua­si der geron­ne­ne Was­ser­fall. Fach­be­rei­che for­mu­lie­ren ihre Anfor­de­run­gen an die IT, wo sie dann von der ers­ten Stel­le prio­ri­siert, von der nächs­ten spe­zi­fi­ziert, von einer wei­te­ren mit Hil­fe von Dienst­leis­tern in den Sys­te­men umge­setzt, getes­tet und schließ­lich an den Betrieb über­ge­ben wer­den. Zwi­schen die­sen Silos gibt es kla­re Ver­ein­ba­run­gen, wie Vor­leis­tun­gen und Ergeb­nis­se aus­zu­se­hen haben. Agi­li­tät ersetzt die­ses sequen­ti­el­le Nach­ein­an­der durch ein inter­dis­zi­pli­nä­res Mit­ein­an­der. Nun sol­len Men­schen ver­schie­de­ner, klar abge­grenz­ter Abtei­lun­gen per­ma­nent an einem gemein­sa­men Pro­dukt arbei­ten. Die­se gewohn­te Abgren­zung und Absi­che­rung auf­zu­ge­ben zuguns­ten einer kon­struk­ti­ven Zusam­men­ar­beit in gemein­sa­mer Ver­ant­wor­tung ist eine nicht zu unter­schät­zen­de Kulturveränderung.

Angst und Agi­li­tät ver­tra­gen sich nicht beson­ders gut. Wer Angst vor Feh­lern hat, sichert sich ab und wagt zu wenig. Wenn nun jeder nur für sei­nen Abschnitt des Was­ser­fall­pro­zes­ses Ver­ant­wor­tung über­nimmt, ent­ste­hen lieb­lo­se, kom­pli­zier­te und mit Funk­tio­nen über­frach­te­te und frus­trier­te Kun­den. Auf dem frei­en Markt hät­ten sol­che Pro­duk­te und ein der­ar­ti­ger Pro­dukt­ent­ste­hungs­pro­zess kei­ne Über­le­bens­chan­ce, intern gibt es aber kei­ne Konkurrenz.

You can’t just ask cus­to­mers what they want and then try to give that to them. By the time you get it built, they’ll want some­thing new.
Ste­ve Jobs

Es ver­wun­dert also wenig, dass Agi­li­tät in vie­len Unter­neh­men mitt­ler­wei­le ein gro­ßes The­ma ist. Zu schwer­fäl­lig ist das gewohn­te Was­ser­fall­vor­ge­hen und zu unbe­frie­di­gend die Pro­duk­te. Einer­seits. Kla­re Schnitt­stel­len und eng umris­se­ne Ver­ant­wor­tungs­gren­zen sind ande­rer­seits aber eine höchst beque­me Kom­fort­zo­ne. Schuld sind dann immer die ande­ren, deren Vor­leis­tung nicht pass­te oder deren Ergeb­nis­se völ­lig unzu­rei­chend sind. Wer Agi­li­tät for­dert, muss also not­wen­di­ger­wei­se auch Mau­ern ein­rei­ßen und inter­dis­zi­pli­nä­re Zusam­men­ar­beit för­dern, wo heu­te Abgren­zung herrscht.

Natür­lich arbei­ten im Rah­men von Pro­jek­ten immer schon Men­schen ver­schie­de­ner Abtei­lun­gen inter­dis­zi­pli­när zusam­men. Der ent­schei­den­de Unter­schied ist aber für was sich die­se Men­schen ver­ant­wort­lich füh­len. Dazu gibt es meis­tens kla­re Rol­len­be­schrei­bun­gen mit Auf­ga­ben, Kom­pe­ten­zen und Ver­ant­wor­tung. Mit die­sen Rol­len wird die Abgren­zung zwi­schen den Abtei­lun­gen im Gro­ßen in die Pro­jek­te im Klei­nen über­tra­gen. Wie­der ist jeder nur für sei­nen Abschnitt ver­ant­wort­lich und das Ergeb­nis ent­spre­chend wenig mutig und lieblos.

An orga­niza­ti­on’s abili­ty to learn, and trans­la­te that lear­ning into action rapidly, is the ulti­ma­te com­pe­ti­ti­ve advantage.
Jack Welch

Agi­li­tät erfor­dert ein inter­dis­zi­pli­nä­res Mit­ein­an­der statt einem klar abge­grenz­ten Neben­ein­an­der. Es geht um gemein­sa­me Ver­ant­wor­tung für das Pro­dukt. Die­ses Umden­ken von der gewohn­ten Ver­ant­wor­tung für sei­nen klei­nen Pro­zess­ab­schnitt hin zu einem Ein­brin­gen sei­ner jewei­li­gen Fähig­kei­ten für das gemein­sa­me Pro­dukt ist eine der größ­ten Her­aus­for­de­run­gen bei der Umset­zung von Agi­li­tät von klas­sisch-hier­ar­chi­schen, pro­zess­ge­trie­be­nen Industrieunternehmen.

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

2 Kommentare

Lie­ber Herr Raitner,

ich dan­ke Ihnen herz­lich für die­sen wun­der­ba­ren Arti­kel. Es ist sehr inter­es­sant zu sehen, wie die Anfor­de­run­gen an ein IT-Pro­jekt über­trag­bar sind auf die gene­rel­len Her­aus­for­de­run­gen, die das all­täg­li­che Mit­ein­an­der im Kol­le­gen­kreis so for­dert. Effi­zi­en­te Zusam­men­ar­beit ent­steht nur dann, wenn der Mensch mit sei­nen ein­ma­li­gen Stär­ken als Indi­vi­du­um wahr­ge­nom­men wird. Dann kann man kon­struk­tiv Dele­gie­ren, Kom­mu­ni­zie­ren und Moti­vie­ren. Jeder wird so ein­ge­setzt, wie es sei­ne per­sön­li­chen Talen­te for­dern. Ein Mit­ein­an­der macht erst außer­ge­wöhn­li­che Ergeb­nis­se mög­lich. Genau­so ist es beim abtei­lungs­über­grei­fen­den IT-Projekt.

Herz­li­che Grüße
Cars­ten Seiffert

Lie­ber Herr Sei­fert, vie­len Dank für Ihren Kom­men­tar. Sie haben voll­kom­men recht, dass Pro­jek­te ja nur eine Form der Zusam­men­ar­beit sind. Auf­grund von Matrix­or­ga­ni­sa­tio­nen erkennt man dort die­se Defi­zi­te viel­leicht eher, aber das Phä­no­men der Abgren­zung, des Gegen­ein­an­ders und im bes­ten Fall des Neben­ein­an­ders, das fin­det sich lei­der in den meis­ten tra­di­tio­nell-hier­ar­chi­schen Orga­ni­sa­tio­nen. Und ja, das ist nicht kon­struk­tiv, son­dern Verschwendung.

Schreibe einen Kommentar