Einführung des Organisations-Architekten als Initiator und Realisierer der Geschäftsprozessoptimierung und seine Rolle in IT-Projekten

Kurze Kommunikationswege sind in unserer Informationsgesellschaft 'trendy' und werden allgemein als ein 'must have' angesehen. Tatsächlich verbessern schnelle und direkte Informationsflüsse unter Umgehung etablierter Hierarchien und Befehlsketten das Betriebsergebnis in vielen Fällen. Ein cc:Boss eMail reicht bei Alltagsentscheidungen meist aus, und spart dem Management überdies viel Zeit.

Warum trifft das nicht auf die Kommunikation zwischen operativen Einheiten und (internem wie externem) IT-Personal zu?

Wenn der Einkäufer mit dem Logistiker oder der Vertriebsassistent mit dem Produktmanager spricht, wissen beide Seiten wovon und worüber sie reden. Kontext, Geschäftsprozesse und -Objekte sind beiden gleichermaßen vertraut, trotz der Spezialisierung auf das eigene Fach- bzw. Verantwortungsgebiet. Beide kennen ihre Grenzen und werden im Zweifelsfalle einen Manager mit abteilungsübergreifender Entscheidungsbefugnis hinzuziehen. Gegenseitiges Verständnis ist gegeben, weil Sender und Empfänger auf gleicher Wellenlänge arbeiten. Das Kommunikationsprotokoll, definiert durch Mentalität, kaufmännische Ausbildung und beruflichen Werdegang, Vokabular und Sprachgebrauch, ist bei allen Beteiligten nahezu identisch. Gesendete Nachrichten kommen vollständig an und werden ohne Verlust verstanden und verarbeitet.

Wenn jedoch der Einkäufer mit dem Programmierer oder der Produktmanager mit dem Webmaster spricht, prallen Galaxien aufeinander. Sie verwenden dem Gegenüber unverständliche Syntax und Semantik. Schnittmengenvokabular mit auf beiden Seiten unterschiedlichem Begriffsverständnis erzeugt Einigkeit, wo keine ist. Weil sie durch ihre Berufserfahrung beide ein, oft nur vermeintliches, aber jedenfalls gefährliches Teil- oder Halbwissen aus dem Arbeitsgebiet des Gesprächspartners erworben haben, entstehen viele Missverständnisse und Informationsversäumnisse durch Ignoranz, Schüchternheit und Angst vor Imageverlust sowie Höflichkeit. Ein gemeinsames Kommunikationsprotokoll ist weder vereinbart noch implementierbar. Mentalität, kaufmännische vs. technische Ausbildung und die entsprechende Berufserfahrung, die Sicht auf und das Verständnis von Geschäftsprozessen und -Objekten, selbst Vokabular und Sprachgebrauch sind nicht kompatibel. Sender und Empfänger modulieren zwar auf unterschiedlichen und sich nur teilweise überlappenden Wellenlängen, beide Seiten erhalten somit nur einen Bruchteil der übermittelten Information, aber sie arbeiten munter damit weiter. Die Ergebnisse können sich sehen lassen, und zwar als vermeidbare Kosten bzw. entgangener Gewinn in der GuV, sowie als eskalierende (innerbetriebliche) Animositäten.

Betrachten wir ein Alltagsobjekt wie 'Kunde' aus der Sicht eines Vertriebsmitarbeiters und eines Softwareentwicklers, so stellen wir fest, dass das geistige Abbild dieses Geschäftsobjektes und seiner Verknüpfungen in beiden Köpfen extrem voneinander abweicht.

Dem Vertriebsmitarbeiter kommen primär Personen in den Sinn, Gesichter, Namen, Eigenschaften usw. von Mitarbeitern verschiedener Kunden, die er z.B. auf Messen kennen gelernt hat. Selbst ein Telefonverkäufer stellt sich seine Gesprächspartner (unbewusst) bildlich vor. Als nächstes liefert das Gedächnis Gespräche an, und weil das meist Verkaufsgespräche sind, werden im Folgenden Produkte mit den Kunden assoziiert. Auch von den Produkten und deren Eigenschaften hat der Verkäufer primär bildliche Vorstellungen. Über die abgenommenen oder auch nur angefragten und angebotenen Produkte wird Wissen über die Bedürfnisse der Kunden abgerufen, hier kommen spätestens auch Erinnerungen an Lokalitäten aus Kundenbesuchen sowie eher statistische Informationen über Kunden ins Spiel. Auch Erfolgserlebnisse gefolgt von missratenen Aktivitäten werden i.d.R. erst jetzt erinnert. In der Fülle all dieser Informationen kommen Details wie z.B. Liefervereinbarungen, Zahlungskonditionen, logistische Abläufe u.s.w. meist nicht oder nur am Rande vor. Unabhängig von der tatsächlichen 'Reihenfolge' bei der Anlieferung dieser Informationen, erzeugt der Begriff 'Kunde' beim Vertriebsmitarbeiter das Abbild eines eher unstrukturierten Konglomerats aus primär visuellen Daten, wobei Eigenschaften und Verhalten verschiedener Kunden zwar (partiell vermengt) vorhanden, jedoch diese Informationen weder auf die Gesamtmenge der Kunden bezogen vollständig, noch nach Eigenschaften und Verhalten geordnet sind. Alle als wichtig klassifizierten und somit besonders gut erinnerten Daten lassen sich quasi 'anfassen', sie stammen aus dem richtigen Leben und sind nach persönlichen und damit subjektiven Kriterien priorisiert.

Der Programmierer (bzw. Modellierer), selbst einer mit Linienerfahrung, denkt anders, sieht anders, und stellt anders dar. Seine Sicht auf das Geschäftsobjekt 'Kunde' basiert auf einem abstrakten hierarchischen Modell, in dem Bedeutung, Eigenschaften und Verhalten aller Kunden in Entitäten, Attributen, Methoden und Relationen 'breitgeklopft' wurden, damit das Modell auf jede Instanz bzw. Permutation von 'Kunde' anwendbar ist. 'Kunde' bezeichnet in seiner Welt ein Objektnetz, dessen Persistenz aus Tupeln in Datenbanktabellen besteht und dessen Verhalten in Methoden, sprich Programmen, manifestiert ist. Sofern sein Bild von 'Kunde' ad hoc überhaupt visuell angeliefert wird, handelt es sich primär um Objektmodell- bzw. ERM-Grafiken (ERM = Entity Relationship Model), Programmablaufpläne etc., und sekundär um Ein-Ausgabe-Visualisierungen wie Bildschirmmasken und Druckausgaben. Viel eher sieht er aber besonders gelungene code snippets und elegante Softwarearchitekturen zeilenweise als source code. Da Programmierer auch rudimentäre Funktionstests durchführen, sind ihm sogar einige Kundennamen bekannt, genauer kennt er aber nur die Daten seiner bevorzugten Testfälle (die erste Kundennummer sowie eine Handvoll Großkunden mit speziellen Softwareanforderungen).

Zusammengefasst ist 'Kunde' für den Vertriebsmitarbeiter ein lebendes Geschäftsobjekt, für den IT-Mitarbeiter jedoch nur ein abstraktes Datenobjekt. Sowenig wie der jüngste Azubi nach seinem ersten Arbeitstag im Vertrieb zum Top-Verkäufer mutiert, wird der IT-Mitarbeiter seinem toten Datenobjekt soviel praxisnahes Leben einhauchen können, dass er in der Lage ist, den unstrukturierten Gedankenfluss des Vertriebskollegen in brauchbare und nützliche Software zu verwandeln.

Wenn Mitarbeiter aus operativen Bereichen versuchen, den Softwareentwicklern neue oder veränderte Geschäftsabläufe als Anforderungen zu übermitteln, führt das zu suboptimalen Arbeitsergebnissen.

Der operative Mitarbeiter ist auf seinen unmittelbaren Arbeitsbereich und sein aktuelles Problem fixiert. Er verfügt weder über den globalen Kontext noch Verständnis 'fremder' Geschäftsprozesse, die durch seine Anforderung betroffen sein können. Das Gesamtbild des Softwareentwicklers ist ebenfalls unvollständig, und außerdem noch durch seine technische Sicht eingeschränkt.

Selbst die Betriebsblindheit der Beteiligten ist inkompatibel. Operativen Mitarbeitern fehlt es an Abstraktionsvermögen, analytischen Fähigkeiten und betriebsfremder Erfahrung, um die als notwendig erachtete Veränderung der Arbeitsorganisation zu hinterfragen und ggf. optimiert in die Geschäftsprozesse zu implementieren.

Laienhaftes Technikverständnis operativer Mitarbeiter und deren Improvisationstalent, im Sinne von Abwandlung vorhandener Softwarefunktionalität für andere Abläufe, führen zu Vorgaben, ohne die der Softwareentwickler ein besseres Programm abliefern könnte. Dieser hat mangels Praxisbezug und operativer Erfahrung keine tatsächliche Möglichkeit die Vorgaben zu validieren, und damit keine Chance, seine analytischen Fähigkeiten zur Entwicklung eines schlanken und optimierten Lösungsweges einzusetzen.

Naturgemäß versucht der Softwareentwickler schon im Gespräch mit dem operativen Mitarbeiter, technische Lösungsansätze zu finden. Diese Ablenkung führt nicht nur dazu, dass er wesentliche Informationsbrocken und Zusammenhänge nicht oder nur teilweise aufnimmt. Tatsächlich versucht er unbewusst sogar, alle folgenden Informationen in seinen ersten Lösungsansatz einzubauen, bzw. diesen zu erweitern. Das Ergebnis ist ein verzerrtes, technisiertes und unvollkommenes Problemverständnis.

Aus der Sicht der Beteiligten findet ein sehr konstruktives Gespräch statt. Munter werden Bildschirmmasken entworfen, Ausgabeformate und andere Details diskutiert, und vermutlich wird der Entwickler am Ende sogar mit einer Aufwandsschätzung aufwarten. Was hier so professionell wirkt, ist angewandter Dilettantismus in seiner kontraproduktivsten Form. Während ein gemeinsames und gleichlautendes Verständnis der kaufmännischen bzw. organisatorischen Anforderung in der Realität zwar nicht zu erreichen ist, von beiden Seiten jedoch angenommen wird, verständigen sich die Beteiligten auf einem niederen technischen wie auch fachlichem Niveau über Details, ohne zu bemerken, dass sie wie Installateure in einem Gebäude ohne Bauplan, Fundament und umbauten Raum arbeiten.

Die Folge sind Aus- und Unterlassungen. Auf der Anwendungsseite entstehen ungeprüfte Beeinflussung vor- und nachgelagerter interner und externer Geschäftsprozesse, und die Kernanforderung selbst wird nicht optimal umgesetzt. Auf der Applikationsseite entstehen Inkonsistenzen im ursprünglich fachlich und technisch sauberen Modell und seiner Implementierung. Deren Spätfolgen werden zum Implementierungszeitpunkt nicht erkannt, resultieren aber unweigerlich in kostspieligen Problemen, wenn irgendwann die Anpassung von Kernfunktionalität der Software an die Anforderungen zukünftig veränderter Märkte auf Bastellösungen aufgesetzt werden muss.

Falls die fachliche Koordinierung der Organisations- und Softwareentwicklung operativen oder entwickelnden Mitarbeitern obliegt, leidet die Qualität der Ergebnisse noch zusätzlich, weil die Bandbreite an Verständnis sowie die Richtigkeit und Vollständigkeit der übermittelten Information durch die Einschaltung eines nicht vollkompetenten Dritten weiter reduziert wird, selbst wenn die koordinierenden Mitarbeiter über ein umfassenderes Verständnis der Geschäftsprozesse verfügen.

Der spezialisierte Mensch ist das Problem in der Interaktion zwischen Fachabteilung und IT. Das Kommunikationsproblem zwischen Menschen mit unterschiedlichem Wissenshorizonten eskaliert im Verhältnis zur Dauer des spezialisierten Einsatzes bis hin zur Unerträglichkeit in interdisziplinären Projekten. Im Tagesgeschäft hervorragend beurteilte operative Mitarbeiter können IT-Projekte -schuldlos!- genauso wirksam zum Scheitern verurteilen, wie geniale Programmierer, Modellierer und Softwaredesigner.

Fazit: Die etablierten Verfahren und Kommunikationsstrukturen in der Softwareentwicklung konterkarieren die Projektziele. Projektziele, Erwartungshaltung und tatsächliche Erfordernisse klaffen weit auseinander.

Das Kardinalproblem der meisten IT Projekte besteht darin, dass die Beteiligten nicht wahrhaben wollen, dass Softwareentwicklung primär ein Teilaspekt der Arbeits- und Organisationsgestaltung ist. (Kommerzielle) Software hat keinen Selbstzweck, sie ist Werkzeug und/oder Produktionsmaschine im Geschäftsprozess. Auch der einzelne Geschäftsprozess verfügt über keine wirkliche Eigenständigkeit, denn er ist eingebunden in und abhängig von anderen Geschäftsprozessen. Modifikationen der Organisation dürfen weder einseitig von Bereichsanwendern oder Entwicklern gesteuert werden, noch von einem de facto für diese Aufgabe unqualifiziertem 'Kollektiv', selbst wenn dieses de jure in der richtigen Hierarchieebene angesiedelt ist.

Ein Unternehmen gleicht einer komplexen, modularen Produktionsmaschine. Das Funktionieren der Maschine als Ganzes ist abhängig vom Funktionieren jedes Moduls im reibungslosen Zusammenspiel untereinander. Beschließt ein einzelnes Modul, sein Verhalten oder seine Komponenten und Beschaffenheit zu modifizieren, erzeugt das Störungen in anderen Modulen, und die Funktionalität der Maschine wird beeinträchtigt.

Bevor in einer Fabrik ein Modul einer Produktionsmaschine modifiziert wird, werden mögliche Auswirkungen (auf andere Module und deren Änderungsbedarf) analysiert, ggf. das Funktionieren des Gesamtwerkes und evtl. Auswirkungen auf die Umgebung simuliert, Investitionsbedarf und veränderte Betriebskosten gegen den Nutzen gerechnet, der Bauplan verändert usw., bevor an der ersten Schraube gedreht wird. So wie Kaufleute und Ingenieure mit Produktionsanlagen umgehen, sollten auch Geschäftsprozesse und deren Hilfsobjekte wie u.a. Software gehandhabt werden.

In der Kommunikation zwischen IT und Fachabteilungen wird inzwischen auf Koordinatoren gesetzt, die in IT-Projekten als Mittler, Moderator und Übersetzer der Projektleitung beigestellt werden. Dieser Ansatz ist jedoch eher eine halbherzige Verschlimmbesserung. Koordinatoren können zwar helfen, Verständigungsprobleme zu reduzieren, es fehlt ihnen jedoch an Kompetenz bezogen die ganzheitliche Sicht auf das Unternehmen, bestehend aus strategischen und taktischen Unternehmenszielen, sowie allen in- und extern wirkenden organisatorischen, technischen als auch betriebswirtschaftlichen Komponenten. Der feste Glaube an die Wirksamkeit des Konzeptes 'Koordinator' ohne weitere Veränderungen althergebrachter Projektstrukturen lässt nicht weniger IT-Projekte scheitern, aber er wiegt die Verantwortlichen in Sicherheit, zumindest bis zum bitteren Erwachen.

Die Rolle 'Koordinator' in Teams ist wichtig und sinnvoll, aber ein Projektleiter, der ihre Dienste in Anspruch nehmen muss, ist eine Fehlbesetzung. Organisationsändernde Projekte sollten fachlich und technisch von Organisations-Architekten initiiert und geleitet werden. Der Organisations-Architekt handelt unbeeinflusst von Bereichsprioritäten im globalen Kontext (Unternehmensziele, -Organisation, -Ressourcen, -Umfeld). Er berät Geschäftsleitung, Produktentwicklung und Vertrieb und steuert produzierende/operative Prozesse und interne Dienstleistungen.

Die Anforderungen an den Organisations-Architekten als übergeordnete, weisungs- und entscheidungsbefugte Instanz für alle (nicht nur die IT-lastigen) Organisationsprojekte sind fachlich und menschlich sehr hoch. Er ist ein vorsichtiger aber vertriebsorientierter Kaufmann, ein breitbandiger Informatiker, schnell lernender Analytiker mit extrem ausgeprägtem Abstraktions- und Simulationsvermögen sowie gutem Gedächnis, ein natürliches Organisationstalent, ein Visionär und Realist mit interdisziplinärer Linienerfahrung. Er ist ein Generalist, der die Fachgebiete der beteiligten Spezialisten ausreichend kennt, Details versteht aber sie nicht zwingend auch beherrscht, und vorzugsweise ein Genie, dem die Geschäftsleitung (auch bei nur partiellem Verständnis seines Vorgehens im Einzelfall) 'blind' vertraut.

All diese Eigenschaften treten in einer Person vereint selten auf, und sie haben in ihrer Entwicklung meist Nebenwirkungen auf die Persönlichkeit hinterlassen. So sind diese Menschen außerhalb ihrer beruflichen Rolle oft Einzelgänger, weil sie ihre intellektuelle Meßlatte im Privatleben zu hoch aufhängen. Auch mit einer oder mehreren (oftmals vorzeitig beendeten) Ausbildungen sind sie i.d.R. wissensdurstige Autodidakten, die mit Engstirnigkeit, Ignoranz und vermeintlicher Dummheit nicht oder nur schlecht umgehen können. Wenn sie sich langweilen, wechseln sie unhaltbar in ein anderes Tätigkeitsfeld. Wenn sie schlecht in die Unternehmenshierarchie eingegliedert (z.B. ihren Vorgesetzten intellektuell überlegen) sind, ziehen sie schnell weiter. Wohlstand reizt sie weniger als eine interessante Aufgabe, vorzugsweise verbunden mit der Möglichkeit, ungehindert zu lernen und zu forschen, und neu erworbenes Wissen sofort in der Praxis anzuwenden. Routine langweilt sie, deshalb benötigen Sie einen Stab.

Bei Beratern und in einigen IT-Abteilungen, die sich frühzeitig vom Rechnungswesen emanzipiert und Organisationskompetenz entwickelt haben, hat sich der Software-Architekt etabliert, dessen Rolle (bezogen auf einzelne Projekte) der des Organisations-Architekten (bezogen auf das Unternehmen als Ganzes) ähnelt. Der Stab des Organisationsarchitekten besteht im Optimalfall aus den Softwarearchitekten aller Projekte.

Organisations-Architekten sind nicht leicht zu finden und nicht leicht zu halten. Kleinere Unternehmen können gut mit externen Organisations-Architekten arbeiten, sie werden nur selten so innovativ sein, dass diese Rolle langfristig eine Vollbeschäftigung darstellt.

Mittlere und große Unternehmen werden selten Organisations-Architekten in den eigenen Reihen finden oder ausbilden können, weil sie zu schwerfällig sind, um diesen (schnell als Querulant einsortierten) Typ Mensch über längere Zeit hin zu halten, falls sie sein Potential im Tagesgeschäft überhaupt erkennen würden. Sie versuchen, diesen Nachteil über die eingesetzten Ressourcen zu kompensieren, aber viele Projekte sind ohne Organisationsarchitekt(en) auch mit gigantischen Budgets nicht zu realisieren, bzw. bleiben im Ergebnis weit hinter den Vorgaben und vor allem den Erwartungen zurück.

Interessanterweise taucht bisher der Begriff 'Organisationsarchitekt' bzw. ein Synonym im entsprechenden Kontext in online Stellenanzeigen fast nur bei Beratern und IT-Dienstleistern auf. Diese Unternehmen sind nicht nur dazu in der Lage, Menschen mit besonderen Gaben (unter Umgehung standarisierter Verfahren und auch ohne die üblichen Anforderungen an Bewerbungsunterlagen zu stellen) zu rekrutieren, sie können ihnen auch die gewünschte und notwendige berufliche Abwechslung garantieren.

Selbst in der Zeit immer kleinerer Budgets auch in Grossunternehmen ist fraglich, ob sich hier irgendwann die Erkenntnis durchsetzt, dass die Rolle 'Organisationsarchitekt' mehr bedeutet als die Fähigkeit eines Projektleiters, projektgetriebene Organisationsänderungen zu implementieren. Nach Kenntnis des Autors ist der Organisationsarchitekt in Großunternehmen bislang nicht präsent, hier wird nach wie vor versucht, Organisations- und Ressourcenmängel erfolglos mit Geld auszugleichen.

Die hier skizzierten Kommunikationsprobleme zwischen Fachabteilungen/Anwendern und Entwicklern/IT-Personal per se und deren Folgen (wie suboptimal organisierte und mangelhaft DV-gestützte Geschäftsprozesse, Bürokratieaufbau, Kostenfallen und nicht bezifferbarer entgangener Gewinn, die Metamorphose optimierter ERP-Systeme zu Investitionsruinen durch Implementierungs-, Wartungs- und Erweiterungsfehler, die Entwicklung persönlicher Animositäten bis hin zu Mobbing und kalten Kriegen zwischen Servicestellen und operativen Bereichen), als auch oft erhebliche Störungen der Betriebsabläufe durch IT-Projekte (durch das nicht ganzheitlich organisatorisch orientierte Herangehen an erkannte Optimierungserfordernisse) sind keine auf kleine und mittlere Unternehmensgrößen beschränkten Phänomene.

Die bisherigen Ausführungen scheinen nicht zwingend auch auf Großanwender zuzutreffen, die viel Geld in Organisationsabteilungen und die Ausbildung deren Mitarbeiter gesteckt haben. Können deren Projektleiter, Analytiker und Modellierer in einen Topf mit dem oben erwähnten Softwareentwickler gesteckt werden? Sie verfügen immerhin über Prozess- und technisches Wissen sowie i.d.R. die modernsten Methoden und Werkzeuge, um der Vorgabe wirksam als Schnittstelle und Kontrollinstanz zwischen Fachabteilung und Softwareentwicklung fungieren zu können zu entsprechen.

Sorry, das ist Wunschdenken. Selbst die partielle Delegation von Personal aus den Fachabteilungen in die Projekt-Teams wird das systemimmanente Kommunikationsproblem nicht beheben, auch wenn es sicherlich anfangs etwas hilft. CaseTools etc. in der Hand durch betriebliche Umstände faktisch nicht vollkompetent gehaltener Mitarbeiter mit erzwungenem Tunnelblick ersetzen nicht das ganzheitlich ausgerichtete Vorgehen und das herausragende Abstraktionsvermögen des erfahrenen und sowie kaufmännisch als auch technisch versierten objektiven Analytikers bzw. Organisations- oder Softwarearchitekten. (Insbesondere interne und damit mehr oder weniger betriebsblinde) Analytiker und Modellierer sollten diesen nur zuarbeiten.

Das Problem ist auch hier das Wesen Mensch. Der Mensch ist Opportunist und Herdentier. In Teams und Abteilungen entsteht Corpsgeist, und dieser wird massiv (unbewusst sowie gezielt durch die leitenden Mitarbeiter) gefördert. Corpsgeist bedeutet, dass das untergeordnete Individuum seine Fahne nach dem durch die Häuptlinge erzeugten Wind ausrichtet. Es bedeutet auch, dass die Häuptlinge sich zusammenschließen, und im Eigeninteresse (zur Wahrung ihrer persönlichen Besitzstände) ihren Wind in eine dem Häuptlingsgemeinwohl gefällige Richtung lenken. Die Richtung dieses Windes bestimmt sich aus der fachlichen Ausrichtung der Herde.

In einer Organisationsabteilung, die sich naturgemäß primär mit Technik, und sekundär mit der Unterstützung operativer Einheiten mittels der eingesetzten Technik beschäftigt, bestimmt sich der Vorbildstatus eines leitenden Mitarbeiters im Wesentlichen aus seiner ((im Innenverhältnis) glaubhaft dargestellten) technischen Kompetenz und seiner (für alle offensichtlichen, weil gezielt herausgestellten) Anerkennung in operativen Unternehmenseinheiten. Wer kann es da dem nach Anerkennung strebenden Mitarbeiter ankreiden, dass er blitzartig nach Eintritt in die Organisationsabteilung seine Sicht der Realität von (in Fachabteilungen erlerntem) prozess- und kundenorientiertem Verständnis in abstraktes und technisch geprägtes Denken umstellt? Wie kann man weiterhin erwarten, dass technisch ausgebildete Mitarbeiter in diesem Umfeld anfangen, prozess- und kundenorientiert zu denken? Schließlich ist erstens der tatsächliche Kunde der IT- oder Organisationsabteilung die Fachabteilung, und deren präsente Mitarbeiter lassen sich doch sooooo leicht assimilieren. Zweitens haben die technisch ausgebildeten Mitarbeiter keine wirkliche Chance, die Realität der relevanten Geschäftsprozesse aus eigener Anschauung zu erleben. Es hilft sicherlich auch nicht sehr viel weiter, dass nach weitläufiger Praxis unbequeme oder schlichtweg unbrauchbare Mitarbeiter von den Fachabteilungen in die Organisationsabteilungen abgeschoben werden, damit sie im Außenverhältnis keinen Schaden (mehr) anrichten können.

Im Extremfall arbeitet also der tatsächlich ausführende (in Grossunternehmen i.d.R. externe) Softwareentwickler nach schierem und verzerrtem Hörensagen, weil die ihm vorgelagerten Filter zur Realität so wirksam sind, dass seine Informationsbasis und sein Anforderungskatalog zu halbverdautem und entstellendem Wunschdenken, sehr weit weg vom richtigen Leben, reduziert wurden. Seine Arbeitsergebnisse werden (von den Mitarbeitern der Fachabteilung und aus Opportunitätserwägungen heraus natürlich auch der IT/Orga) kollektiv verworfen, ohne dass tatsächlich Prototyping vereinbart wurde.

Das macht er eine Weile lang mit, bis er wegen anhaltender Frustration das Team verlässt. In Projektteams der Grossunternehmen können nach einiger Zeit durch den Verschleiß wichtiger Projektmitarbeiter leicht per produzierender Person bzw. Know-How-Träger fünf und mehr eher unproduktive Kollegen eingesetzt sein. Gerade in solchen Umgebungen ist die Gefahr gross, dass Projekte durch nicht mehr erfüllbare, aus den Anfangsunterlassungen resultierende, ChangeRequests und personelle Fluktuation während der oft viel zu langen Projektlaufzeit scheitern.

Fazit: Eine klassische IT/Organisationsabteilung im Großunternehmen mit althergebrachten Projektstrukturen ist relativ betrachtet zum ebenfalls suboptimalen Zusammenwirken eines Mittelständlers mit einem Softwarehaus um ein Vielfaches kostspieliger und unproduktiver.

Eine durchgreifend restrukturierte, schlanke und von Dogmen früherer Paradigmen befreite IT-/Organisationsabteilung unter der Leitung eines Organisationsarchitekten und der (ggf. projektrevolvierende) Einsatz von Softwarearchitekten minimiert die Projektrisiken und führt schneller zu verwendbaren Ergebnissen. Die Softwareproduktion selbst sollte (externen) Spezialisten überlassen werden, die im Projekt das zukünftige (interne) Betriebsteam ausbilden. Der Know-How-Transfer wird damit ressourcenschonend gewährleistet und die Qualität der Implementierung mit Bordmitteln verbessert.


As always: Every rule is meant to be broken. Knowing when to do so is one of the things that separates the general from the major.




Author: Sebastian
LastUpdate: February/2005





Literatur:

Internes CRM zwischen IT und Fachabteilung, Malte Dous, Universität St. Gallen Local PDF

Anforderungsmanagement durch kontinuierliche Veränderung, Ralf Fahney, Universität Siegen Local PDF

Schwerpunkt Softwaremanagement, Organisation und Gestaltung, Prof. Dr. K.-P. Fähnrich, Universität Leipzig Local PDF

Partizipative Modellbildung zur Optimierung der Softwareentwicklung, Mattias Rauterberg, Eidgenössische Technische Hochschule, Zürich Local PDF

Die Rolle der IT als Innovationstreiber, Dr. rer. nat. Roland Bloemer Local PDF

IT im Mittelstand, Studie der Universität Münster und IBM, Sonderdruck der Computerwoche Nr. 3 v. 31.1.2000 Local PDF

Verstehensprozesse bei der Softwareimplementierung, Eine soziologische Untersuchung am Beispiel einer Einführung von SAP R/3, Jutta Breitschwerd, Weißensee Verlag, Berlin 2003 (On-line Auszug) Local PDF



Diese Literaturhinweise verstehen sich nur als Ideengeber und Ausgangspunkt für weitere Recherchen. Zum Zeitpunkt der Veröffentlichung dieses Artikels ist die Funktion und Rolle des Organisationsarchitekten in der Literatur nicht existent, bzw. der Begriff 'Organisationsarchitekt' wird noch für eine von vielen Rollen/Fähigkeiten des IT-Projektleiters verwendet. Nur wenige Unternehmensberatungen und noch weniger Anwender haben bislang Organisationsarchitekten angeboten bzw. eingesetzt, und i.d.R. ist die Rolle/Position 'Organisationsarchitekt' uneinheitlich anders benannt.

· Home

· Smart Thoughts

· Architect of Organization

· Web Links

· Link to us

· Contact

· What's new

· Site map

· Get Help


Most popular:

· Site Feeds

· Database Design Guide

· Google Sitemaps

· smartDataPump

· Spider Support

· How To Link Properly

· Der Organisations-Architekt

· Home Page Checkliste

· DB Primärschlüssel


Free Tools:

· Sitemap Validator

· Simple Sitemaps

· Spider Spoofer

· Ad & Click Tracking



Search Google
Web Site

Add to My Yahoo!
Syndicate our Content via RSS FeedSyndicate our Content via RSS Feed



To eliminate unwanted email from ALL sources use SpamArrest!






Digg this · Add to del.icio.us · Add to Furl · We Can Help You!




Home · Categories · Articles & Tutorials · Syndicated News, Blogs & Knowledge Bases · Web Log Archives


Top of page

No Ads


Copyright © 2004, 2005 by Smart IT Consulting · Reprinting except quotes along with a link to this site is prohibited · Contact · Privacy