Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Books on Demand
- Kategorie: Fachliteratur
- Sprache: Deutsch
- Veröffentlichungsjahr: 2015
Das Buch richtet sich an die Zielgruppen: • Entscheider in Verbänden und Organisationen • IT-Beauftragte Der 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.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 76
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Inhaltsverzeichnis
1. Gründe für die Erstellung eines Pflichtenheftes
2. Überprüfung und Planung der IT
3. Grundsätzliches zur Planung
3.1 Alternative: externer Berater
3.2 IT-Beratung für Verbände
3.3 Welche Planungs-Themen interessieren?
3.4 Geschäftsprozesse
3.5 Lösungswege
3.6 Grundsätzliche Themen zum Pflichtenheft
3.7 Welche Themen berühren eine Software?
3.8 Beispiel einer Verbandsverwaltung
3.9 Daten-Beziehungen einer Software
3.10 Eine Teilnehmeranmeldung (im Internet)
3.11 Eine Verbandsbuchhaltung (im Internet)
3.12 Bewertungskriterien von Entwicklungstools
4. Warum RAD und TCO ROI verbessert
4.1 Traditionelle Entwicklung versus RAD
4.2 Eine kleine Personenverwaltung
4.3 Traditionelle Software (VFP) versus RAD
4.4 Beispiel: RAD auf iPHONE und iPAD
4.5 Lebenslauf einer Software:
4.6 Planungs-Fehler
4.7 Tipps
5. Ist-Zustand
5.1 Vorstellung des Auftraggebers/Verbandes
5.2 Organisation, Abteilungen, Personal
5.3 Hardware
5.4 Software
5.5 Grund für eine neue IT-Architektur
6. Soll-Zustand
6.1 Organisation und Aufgaben
6.2 Hardware
6.3 Software 1
6.4 Outsourcing
6.5 Sicherheit
6.6 Budget
6.7 Organisation gibt die Software vor
6.8 Software 2
6.9 Zukunftsträchtigkeit, Erweiterbarkeit
6.10 Software im Detail
a. Datenstrukturen und Beziehungen, Eingabe
b. Zugriffsregelung
c. Funktionen und Berechnungen, Abhängigkeiten
d. Prüfungen (Validierungen)
e. Output (Druck, Email, FAX, Telefon, …)
f. Sicherheit
g. Schnittstellen
h. Schulung
i.Altdatenübernahme
j. Test
6.11 Hardware
a. Arbeitsstationen (PC, apple, …)
b. Drucker
c. Internetanschlüsse, WLAN
d. Sicherheit
e. Telefon
f. Server
g. Outsourcing
h. individuelle Hardware, sonstige
7. Datenbanken der Zukunft, Wirtschaftlichkeit
7.1 Zusammenfassung
7.1.1 Probleme der traditionellen Entwicklung
7.1.2 Die Lösung mit Rapid Application Development
7.2 Versteckte Kosten traditioneller Tools
7.3 Mit RAD den TCO und ROI verbessern
7.4 RAD am Beispiel der FileMaker-Plattform
7.4.1 FileMaker-Lösungen als Beispiel
7.5 RAD, schnelle Entwicklung
7.5.1 Schnelle Entwicklungszyklen
7.5.2 Entwicklung ohne Code
7.5.3 Integrierte Entwicklungsumgebung
7.5.4 Geringer Trainingsbedarf
7.5.5 Integrierte Datenbank
7.5.6 Externe Datenbank-Konnektoren
7.5.7 Plattformübergreifender Einsatz
7.5.8 Einfache Administration
7.5.9 Integrierte Wartungswerkzeuge
7.5.10 Webbasierende Anwendungen
7.6 Betriebliche Vorteile von RAD/FileMaker
7.7 Wettbewerbsanalyse: Drei-Jahre-TCO-Studie
7.8 ROI-Anwenderbeispiel
7.8.1 Die Lösung:
7.8.2 Die Vorteile und Auswirkungen auf die Rendite:
7.8.3 Projektvorgabe:
7.8.4 Die präzise Planung und der Auswahlprozess:
7.8.5 Kundenvorteile:
7.9 Die Methode „Total cost of ownership"
7.9.1 Datenbank-Lizenzierungskosten:
7.9.2 Entwicklungsumgebung:
7.9.3 Entwicklungskosten:
7.9.4 Zwei Anwendungsupgrades:
7.9.5 Kosten für den Einsatz und im Betrieb:
7.9.6 Kosten für die Datenbankverwaltung:
7.9.7 Trainings für die Entwicklungsumgebung:
7.9.8 Anwendungsupgrades:
7.9.9 Support:
8. Zeitplan und Kosten
8.1 Vorgehensweise und Kosten (10 Jahre)
8.2 Organisationsgespräche, Pflichtenheft
8.3 Verantwortlichkeiten
8.4 Erstellung Pflichtenheft
8.5 Anbietersuche
8.6 Vorauswahl Anbieter
8.7 Erstellung Beurteilungskatalog
8.8 Auswertung der Beurteilungskataloge
8.9 Besprechung der Gesamt-Auswertung
8.10 Weitere Auswahleingrenzung der Anbieter
8.11 Gespräche mit den Anbietern, Angebote
8.12 Erstellung eines Entscheidungspapieres
8.13 Präsentation der Entscheidungsgrundlagen
8.14 Auftragsvergabe
9. Testphase
10. Schulung
11. Start des Betriebes
12. Nachbereitung
13. Support (Hotline), Lizenzen
14. Mögliche Phasen
14.1 Vorgehensweise vor der Entscheidung
14.2 Vorgehensweise nach der Entscheidung
14.4 Von der Idee bis zur Entscheidung
14.5 Von der Entscheidung bis zum Einsatz
15. Pflichtenheft-Typen
16. Andere Ansätze eines Pflichtenheftes
16.1 Theoretische Ansätze
16.2 Praktische Ansätze
17. Quellenverweise
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“.
