IT-Planung und Pflichtenheft

am Beispiel von Verbänden und Organisationen der Wirtschaft

Rainer Maschke

• Verlag: Books on Demand
• Jahr: 2015
• ISBN drucken: 9783738620436
• eBook-ISBN: 9783739274454
• Auflage: 1
• Thema: Technik & Maschinenbau
• Thema: Maschinenbau Allgemein

Das Buch richtet sich an die Zielgruppen: •Entscheider in Verbänden und Organisationen •IT-BeauftragteDer Entscheider soll in seiner Planung und Vorbereitung für den Einsatz einer neuen und zukunftsträchtigen Software unterstützt werden. Der Autor kann auf vierzig Jahre Erfahrung von Verbandsorganisation und Software-Entwicklung zurückgreifen. In den achtziger und neunziger Jahren hat er über diese Themen, speziell Datenbank-Entwicklungen, fünf Bücher veröffentlicht. Verbände und Organisationen stehen durchschnittlich alle zehn Jahre vor der Entscheidung, eine neue Software einzusetzen. Ob diese Notwendigkeit besteht, soll das Buch helfen zu ergründen. Da diese Entscheidungsvorgänge nicht zur Routine der Verbands– Geschäftsführung gehören, sind Ratgeber, meist externe, sinnvoll. Von Halbwissern ist abzuraten. Wird nun eine Entscheidung für ein Produkt getroffen, so setzt dies aber auch eine Vorbereitung in Form eines Pflichtenheftes voraus. Der gesamte Ablauf bis zum Einsatz der neuen Software sollte zeitlich, sachlich und finanziell klar sein, so wird es in diesem Buch gesehen und beschrieben. In die Entscheidungsprozesse sollte auch zumindest das Erahnen von zukünftigen Innovationen gehören, sonst wird später die Schere zwischen realer Verbandsleistung und möglicher Verbandsleistung auseinander klaffen.

1. Gründe für die Erstellung eines Pflichtenheftes

Grundsätzlich passen sich Software und Hardware den individuellen Anforderungen der Organisation an und dies ständig im Laufe der Nutzungszeit. Selten richtet sich die Organisation nach der Software oder der Hardware.

In der Praxis haben sich unterschiedliche Gründe für das Erstellen eines Pflichtenheftes bei der Planung einer neuen IT-Architektur ergeben. Dies gilt auch für das Überprüfen der aktuellen IT-Landschaft. Bei beiden Vorhaben stellen sich Fragen nach Machbarkeit, Wirtschaftlichkeit und Zweckmäßigkeit. Ein Negativbeispiel, bewusst etwas überspitzt dargestellt, soll die Notwendigkeit eines Pflichtenheftes verdeutlichen.

Der Verband „Besiedlung des Mare Imbrium“ wird durch seinen Geschäftsführer Neil Amstrong vertreten. In der Verbandsverwaltung nahe Cap Canaveral sind fünfzehn feste und drei freie Mitarbeiter beschäftigt. Der Verband betreut etwa zweitausend freiwillige Mitglieder und einhundertfünfzig Fördermitglieder. Die Hauptaufgabe des Verbandes ist es, eine dauerhafte Besiedlung im Mare Imbrium politisch, juristisch und praktisch vorzubereiten.

Aus den Reihen des Vorstandes wurde der Wunsch nach einer neuen IT-Architektur geäußert und die Geschäftsführung beauftragt Entscheidungsgrundlagen dafür herzustellen. Herr Amstrong betraute seine Mitarbeiterin Marlies Obama aus der Abteilung Politik und Öffentlichkeitsarbeit mit der Planung des neuen Vorhabens. Weder Herr Amstrong noch Frau Obama haben je ein derartiges Projekt vollzogen.

Frau Obama suchte im Internet nach Softwareanbietern. Dies waren Unternehmen, die auf Programmentwicklung für Telekomminikation, Grafik, Architektur, Buchhaltung und Adressenverwaltung spezialisiert waren. Auch ein Vorstandsmitglied konnte einen Beitrag leisten. Er empfahl ein Softwareunternehmen mit dem er schon länger zusammen arbeitet. Dieser Anbieter entwickelt Software für Lagerhaltung. Hier sollte jeder analytisch agierende Mensch schon ins Grübeln geraten.

Es wurden über vier Wochen hin Gespräche mit den Anbietern geführt. Frau Obama und Herr Amstrong stellten den Verband vor und erklärten in den Gesprächen den Soll-Zustand der neuen IT-Architektur. Einige Anbieter baten um schriftliche Unterlagen. Diese haben sie auch überreicht bekommen. Es waren Broschüren über den Verband, Pressemitteilungen und Einladungen zu Veranstaltungen. Die Eindrücke von den Anbietern hat Frau Obama schriftlich festgehalten um eine Präsentation für das Entscheidungs-Gremium, dem Vorstand, vorzubereiten. Es wurde eine Entscheidung für das Softwarehaus FISKUS GmbH getroffen, ein Unternehmen das sich auf die Erstellung von Buchhaltungssoftware spezialisiert hat.

Nach sechs Monaten Entwicklungs- und Testzeit wurde die neue Hardware und Software beim Verband installiert. Die Hardware machte keine Probleme, Internet, FAX und Drucker funktionierten einwandfrei. Microsoft Office arbeitete wie erwartet. Zentrale Dokumente wurden auf dem Server gespeichert, für jeden Mitarbeiter einsehbar. Die Altdatenübernahme funktionierte gut. Es folgte die Schulung im neu entwickelten bzw. angepassten Verwaltungsprogramm.

Mit wenigen Ausnahmen erkannte kein Mitarbeiter seine Aufgaben in der Verwaltungssoftware wieder. Man sollte berücksichtigen, dass neue Programme fast immer auf leichten bis mittleren Widerstand stoßen, weil der Anwender erst eine gewisse Zeit für die Akzeptanz benötigt. Im Fall unseres fiktiven Verbandes war es kein Problem von Akzeptanz, sondern von falsch verstandenen Anforderungen, die sich in der neuen Software widerspiegelten. Eine geforderte Nachbesserung war nur eingeschränkt möglich, weil das Entwicklungsinstrument (Programmiersprache, Datenbank) nicht mehr gepflegt wurde. Einige Beispiele der Kommunikation zwischen Verband und Software-Entwickler:

„Die Beiträge werden völlig anders ermittelt, das habe ich ihnen gesagt.“

„Die Rundschreiben sollen per Email oder FAX, je nach Wunsch des Mitgliedes versandt werden, das liegt doch auf der Hand.“

„Wenn wir zu Veranstaltungen einladen, sollen auch Rechnungen und nicht nur Teilnehmerlisten erstellt werden.“

„Wo ist die Aufstellung der Beiträge pro Mitglied?“

„Wir haben schon drei Viertel an sie bezahlt, ohne eine brauchbare Gegenleistung.“

„Als wir sie fragten, welcher Mitarbeiter von uns die Software erstellen soll, haben sie sich für den neuen jungen Uniabsolvent entschieden. Der ist zwar preiswerter, hat aber noch nicht viel Erfahrung.“

„An Informationen haben sie uns nur ihre Satzung und Broschüren zur Verfügung gestellt.“

Das gesamte Vorhaben eskalierte, der Vorstand hat sich eingeschaltet und Herrn Amstrong trotz großer Verdienste früher als geplant in den Ruhestand geschickt. Das gesamte Vorhaben wurde nochmal mit einem neuen Anbieter und einem neuen Geschäftsführer vollzogen. Die Rückforderung der bereits geleisteten Zahlungen blieb trotz gerichtlicher Bemühung erfolglos. Was ist falsch gemacht worden?

Weder Herr Amstrong, noch Frau Obama, noch der Vorstand hatten nur annähernd ein Gespür oder Erfahrung für das Begleiten dieses neuen Projektes.

Von keiner Seite wurde auf ein gemeinsames Papier gedrungen, das für beide Seiten verständlich und bindend sein sollte.

Der verantwortliche Programmierer hatte zu wenig Erfahrung um das Projekt zum Erfolg zu führen.

Der Verband hat sich nicht für das Entwicklungsinstrument der Verwaltungssoftware interessiert, es hatte keine Zukunft.

Eine Kreditorenverwaltung, wie neu eingesetzt, ist keine Verbandsverwaltung.

Der neue Geschäftsführer Alan Shepard wurde vom Vorstand angewiesen, erst einen externen Berater zu konsultieren bzw. zu beauftragen und dann mit einer weiteren und neuen Softwarefindung zu beginnen. Dies führte dann zum Erfolg, obwohl das ursprünglich geplante Budget weit überschritten wurde.

Der Weg mit einer externen Beratung vereinfachte das Analysieren, Begleiten und Unterstützen bis zur Entscheidungsreife sehr und schaffte Transparenz. Die Verfügbarkeit und die Kommunikation zwischen den Verbands-Mitarbeitern und dem Auftragnehmer hat das gesamte Vorhaben weiter abgesichert. Da die Erfahrungen in der Planung neuer IT-Architekturen bei „Verbänden und Organisationen der Wirtschaft“ sehr vielfältig sein können, stellte man die Planung und die Realisierung nun auf sichere Beine.

Dies war ein sicherlich etwas übertriebenes, aber durchaus realitätsnahes Beispiel. Der Autor hat im Laufe seiner Beratungs- und Entwicklungstätigkeit eine große Spannweite an Voraussetzungen für die Realisierung von Projekten kennengelernt. Dies reichte von völliger „Naivität“ und „Fehleinschätzung“ bis zur „Professionalität“.

Wenn im Folgenden von Verband gesprochen wird, so können dies auch Vereine, Körperschaften des öffentlichen Rechts, Genossenschaften und angegliederte Kapitalgesellschaften sein. Sinn macht die Erstellung eines Pflichtenheftes nur bei Verbänden ab einer gewissen Größenordnung. Ein Turnverein in einer zehntausend-Seelen-Gemeinde wäre damit sicher überfrachtet. Hier sind einfache Programme sicherlich besser platziert.

2. Überprüfung und Planung der IT

In Abständen von fünf bis zehn Jahren sollte sich in einer Verbandsorganisation immer wieder die Frage gestellt werden, ob die derzeitige IT-Architektur (Hardware und Software) für die Organisation ausreichend und vor allem verbesserbar ist, und dies immer unter Abwägung von Leistung und Kosten. Ein sehr oft schwieriges Vorhaben, zumal in kleinen und mittleren Verbänden etwa alle zehn Jahre eine Entscheidung für eine neuen IT-Architektur gefällt wird. Hier fehlt dann immer der Faktor Erfahrung, um eine gesicherte Entscheidung zu treffen. Größere Verbände verfügen in den meisten Fällen über eine eigene IT-Abteilung, die den Entscheidungsprozess strukturiert vorantreibt. Aber auch hier trifft das Gleiche zu, dass diese Art des Entscheidungs-Prozesses ca. alle zehn Jahre ansteht. Es stellt sich daher sehr oft für Verbandsentscheider die Frage nach einer externen Beratung. Vorausgesetzt, dass der Berater über die erforderliche Kompetenz, Erfahrung und Einfühlungsvermögen verfügt, ist dieser Weg der sicherste. Dieser Einsatz ist aber mit zusätzlichen Beratungs-Kosten verbunden. Ob sich diese externe Unterstützung lohnt und sinnvoll ist, können nur die Entscheidungsträger im Verband erahnen.

Durch eine Überprüfung des Status quo sollte zuerst die aktuellen Organisation schriftlich niedergelegt werden. Dies darf und sollte mit den Worten – in der Sprache – des Verbandes erfolgen, wohlwissentlich, dass der Software-Anbieter einen anderen Wortschatz benutzt. Das Nichtverstehen von Verband und Software-Anbieter ist ein Problem, welches nicht unterschätzt werden sollte. Für das Erarbeiten des Papieres über die aktuelle Organisation ist das Zusammenspiel zwischen Geschäftsführung und den verantwortlichen Mitarbeitern von großer Bedeutung. Es kann durchaus ein Mitarbeiter mit der Erstellung beauftragt werden. Dieser sollte mit den entsprechenden Kollegen und der Geschäftsführung unbedingt seine Interviews führen. Das Ziel dieser Arbeit ist es, einen Prozentsatz zu ermitteln, der besagt:

Unsere derzeitige IT-Architektur deckt X % unserer aktuellen Organisationsanforderung ab. Es stellt sich die theoretische Frage:

95 % wäre hier ein brauchbarer Wert, der aber von der jeweiligen Organisation und den damit verbundenen Arbeiten und der Datenhaltung bestimmt wird. Das Ermitteln und die Aussage-Qualität dieses Prozentsatzes hängen von vielen Faktoren ab. Hier einige Beispiele dafür:

• die Qualität der Mitarbeiter, ihre Aufgabengebiete zu strukturieren
• der Aufwand, an gesicherte Informationen zu gelangen
• die Gewichtung von einzelnen Organisationsfaktoren
• Bedarf

Wohlwissentlich, dass dieser Prozentsatz nur die Aussage einer Annäherung darstellt, so sollte er aber doch als Parameter für Entscheidungen dienen. Steht dieser Prozentsatz zur Verfügung, stellt sich die nächste Frage, die Frage nach dem Aufwand und dem Ertrag. Wenn dies auch Begriffe aus dem Rechnungswesen sind, so treffen sie hier genau den Punkt.

Lässt sich diese Waagschale über „für“ und „wider“ quantifizieren und gewichten, so nähert man sich den gesicherten Entscheidungsgrundlagen. Das gesamte Vorhaben zur Erlangung weitestgehend gesicherter Entscheidungsgrundlagen stehen und fallen u.a. mit der Konsequenz dieser Analysen. Man bedenke, dass es sich hierbei zunächst nur um die Überprüfung des Status quo handelt. Es steht also hinter dem Vorhaben kein direkter Zugzwang. Diese Prüfungen von Zeit zu Zeit anzustreben hängen u.a. vom Weitblick der Geschäftsführung oder des Vorstandes ab. Ein Beispiel soll dies besser verdeutlichen:

An ein bestehendes Haus wurde eine Terrasse angebaut und mit Fliesen belegt. Nach drei Monaten stellt sich heraus, dass das Fugenmaterial ungeeignet für diese Terrasse ist.

Regenwasser drang durch das Fugenmaterial bis in die Betonplatte und es zeigten sich Wasserschäden. Die Garantie mal außer Acht gelassen, hätte die sofortige Reparatur 10.000,- € Kosten verursacht. Diese Reparatur wurde aber erst drei Jahre später vorgenommen, drei Jahre mit tiefen Wintertemperaturen. Die Schäden waren erheblich angewachsen. Die Reparatur nach diesen problematischen drei Jahren verursachte 30.000,- € Kosten.

Bei unserem Thema der sporadischen IT-Prüfung ist oberflächlich kein Schaden zu erkennen. Da aber Organisationen sich nicht statisch verhalten und das IT-Angebot sich in rasanter Geschwindigkeit verändert, kann bei Missachtung einer Prüfung versteckter Schaden entstehen. Verweigert man sich der Innovation, so kann das Hinauszögern von IT-bezogenen Entscheidungen ein Kumulieren von anstehenden Problemen verursachen.

3. Grundsätzliches zur Planung

3.1 Alternative: externer Berater

In einem ersten Planungs-Gespräch sollte gemeinsam mit den Mitarbeitern des Auftraggebers das grobe Ziel einer externen Beratung bzw. einzusetzenden Software festgelegt werden.

Der Weg einer externen Beratung wird das Analysieren, Beraten, Begleiten und Unterstützen bis zur Entscheidung ...

Inhaltsverzeichnis

• Inhaltsverzeichnis
• 1. Gründe für die Erstellung eines Pflichtenheftes
• 2. Überprüfung und Planung der IT
• 3. Grundsätzliches zur Planung
• 4. Warum RAD und TCO ROI verbessert
• 5. Ist-Zustand
• 6. Soll-Zustand
• 7. Datenbanken der Zukunft, Wirtschaftlichkeit
• 8. Zeitplan und Kosten
• 9. Testphase
• 10. Schulung
• 11. Start des Betriebes
• 12. Nachbereitung
• 13. Support (Hotline), Lizenzen
• 14. Mögliche Phasen
• 15. Pflichtenheft-Typen
• 16. Andere Ansätze eines Pflichtenheftes
• 17. Quellenverweise
• Impressum