Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

22.09.1978 - 

IKD-Workshop "DV im Rahmen der Unternehmens- und Personalpolitik":

An mangelhafter Projektorganisation scheitern viele EDV-Vorhaben

BERLIN (de) - Rudolf Baer vom Institut für Betriebswirtschaft St. Gallen hat IKD-Erfahrung: Der dynamische DV-Wissenschaftler war Referent beim 2. IKD im Jahre 1976. Als Gastredner der Workshopreihe I (DV im Rahmen der Unternehmens- und Personalpolitik) berichtet Baer diesmal über "Praktische Erfahrungen mit unterschiedlichen Projektorganisations-Modellen".

Hier ein Auszug aus seinem Referat, in dem er die Projektorganisation eines schweizerischen Elektronik-Unternehmens vorstellte. Die Kurzfassung beschränkt sich auf die Einleitung und einige - nach Ansicht Baers - allgemeingültige Hinweise zur Problematik eines Projektorganisations-Modells (PM).

Mit der Betonung der Benutzer-Orientiertheit der Datenverarbeitung ist es eindeutig klargeworden, daß es nicht länger Sache der DV- oder anderer Spezialabteilungen sein kann, neue Lösungen "im stillen Kämmerlein" auszubrüten und diese fix und fertig den Anwendern zu präsentieren. So ist es kaum verwunderlich, daß in keinem Bereich des Geschäftslebens soviel von Projektorganisation, von Zusammenarbeit der verschiedenen Abteilungen und Fachgebiete gesprochen wird wie in der Informationsverarbeitung. Jeder Computerhersteller, jede Schulungsinstitution, ja fast jeder größere Anwender hat sich ein eigenes Projektorganisations-Modell (PM) zurechtgelegt und handelt danach - oder gibt mindestens vor, danach zu handeln.

Und trotzdem liegen die Ursachen für das Scheitern von EDV-Projekten vielfach in einer mangelhaften Projektorganisation:

þSo wird in vielen PM viel über das Projektteam und dessen Struktur und nichts oder zuwenig über die weiteren Problemlösungsträger, die auf irgendeine Art und Weise mit dem Projekt in Berührung kommen, ausgesagt. Und gerade diese zukünftigen "Betroffenen" sind es, die letztendlich über Erfolg oder Mißerfolg eines Projektes entscheiden.

þGewisse PM sind zu bürokratisch und würden bei einer Befolgung der postulierten Richtlinien zu unübersehbaren Projekt-Organisationsstrukturen und Papierfluten führen. Werden diese dann aus praktischen Gründen "abgemagert", so fehlen dann meistens entscheidende Elemente für den Erfolg.

þDem "gesunden Menschenverstand" zuwiderlaufende Organisationsformen führen zu mindestens passivem Widerstand.

þAus einmaligen Situationen entstandene PM-Prototypen werden übertragen, ohne Gültigkeit erlangt zu haben.

Durch die notwendige Aufteilung der komplexen Informationssysteme in relativ autonome Subsysteme entsteht die Tendenz, zu viele Subsysteme gleichzeitig auf unterer Ebene zu behandeln, da man ja letztendlich ein Gesamtsystem realisieren möchte. Dadurch entsteht ein übermäßiger, kaum zu bewältigender Koordinationsaufwand. Anstatt nun aber ein Subsystem nach dem anderen nach der "lnselmethode" zu realisieren, muß nach Systemmethode vorerst auf höherer Ebene ein Grobentwurf des Ganzen gemacht werden.

Das inkrementale, sprunghafte, "systemorientierte" Denken erfordert bedeutend mehr Denkdisziplin als das "klassische" Vorgehen "Ist - Istkritik - Sollkonzept".

Für die Realisierung in kleinen Schritten - unter Voraussetzung eines Gesamtkonzeptes - spricht:

þÜbersicht durch Behandlung kleinerer Einheiten,

þTeilerfolge nach kurzer Zeit = Motivation,

þman kann aus den Erfahrungen lernen,

Folgendes Verhalten erschwert die Erarbeitung neuer Lösungen:

þMengenmäßiger Output wird zu stark belohnt,

þallfällige Fehler werden übermäßig bestraft,

þzu großer Zeitdruck,

þzu hohe Anforderungen an die vorgelegten Informationen.

Das Projekt-Team, dessen Größe je nach Unternehmung und Problemstellung zwischen zwei und sechs Leuten sein sollte, muß die folgenden drei Hauptfähigkeiten aufweisen:

- kybernetisches Denkvermögen und Fachwissen

- Fähigkeit, Macht auszuüben

- Fähigkeit, Unterstützung zu sichern sowohl von "oben" als auch von "unten".

Einige Persönlichkeitsmerkmale der Teammitglieder (die Reihenfolge entspricht ungefähr der Wichtigkeit):

- Bereitschaft, die Ideen anderer vorbehaltlos entgegenzunehmen

- anerkannt in der Unternehmung als einer, der "drauskommt"

- geeignet als Teammitglied

- Fähigkeit, zu gliedern und zu strukturieren

- belastbar

- gut motiviert/kann andere motivieren

- kein übermäßiger Streber.

Im Team sollten je nach Aufgabenstellung Kenntnisse über die miteinbezogenen Fachbereiche und über DV vorhanden sein.

Es liegt auf der Hand, daß Mitarbeiter, die diesem Profil entsprechen, dünn gesät sind. Eine Geschäftsleitung muß sich aber die Frage stellen, ob es nicht die beste Zukunftsinvestition darstellt, gerade diese Leute für ein neues Informationssystem-Konzept einzusetzen, anstatt mit nur halbwegs geeigneten Leuten ein nur halbwegs geeignetes Konzept zu erstellen.