Lade Inhalt...

Prüfung und Auswahl betrieblicher Informationssysteme für ein Beratungsunternehmen

Diplomarbeit 2005 70 Seiten

BWL - Controlling

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einleitung

2 Projektdefinition
2.1 Projektmanagement
2.2 Projektleiter
2.3 Bestandsanalyse
2.4 Zielbestimmung
2.5 Aufgabenstellung

3 Projektplanung
3.1 Strukturplan
3.2 Terminplan
3.3 Ressourcenplan

4 Projektdurchführung
4.1 Markterhebung
4.1.1 Vorgehensweise
4.1.2 Informationsquellen der Marktanalyse
4.2 Vorauswahl
4.2.1 Ausschreibung
4.2.2 Kontaktaufnahme
4.3 Detailevaluierung
4.3.1 Erfassung der Leistungsfähigkeit
4.3.2 Wirtschaftlichkeitsbetrachtung

5 Projektabschluss

6 Zusammenfassung

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Phasenweiser Projektablauf

Abb. 2: Anforderungsprofil des Projektleiters

Abb. 3: Geschäftsbereiche

Abb. 4: Prozess Controlling

Abb. 5: Erste Ebene des Strukturplanes

Abb. 6: Arbeitspakete

Abb. 7: Terminplan

Abb. 8: Beispiele für Softwarekataloge

Abb. 9: Beispiele für Informationsplattformen im Internet

Abb. 10: Beispiele zu Anbietern vergleichender Marktstudien

Abb. 11: Beispiele für IT-Messen

Abb. 12: Nutzwertanalyse

Abb. 13: Wirtschaftlichkeitsrechnung

Abb. 14: Nutzenkategorien

Abb. 15: Logische Gedankenkette einer Problemlösung

1 Einleitung

Unternehmen die sich im Markt behaupten wollen, müssen sich den hohen Anforderungen, die sich aus den rasch und ständig wechselnden wirtschaftlichen Rahmenbedingungen ergeben, stellen. Zu diesen zählen vor allem der beschleunigte Wertewandel, der Wandel der Kundenbedürfnisse sowie der vor allem international zunehmende Konkurrenzdruck.[1]

Um die Flexibilität und die Effizienz eines Unternehmens zu steigern, ist der Einsatz moderner Informationstechnologien unerlässlich geworden; sie ist im Kampf um die Erringung strategischer Wettbewerbsvorteile eine entscheidenden Waffe.[2]

Die stetig steigenden weltweiten Investitionen, im Jahr 2005 um circa fünf Prozent, in die Informationstechnologie, sind ein Indiz dafür, dass dies immer mehr Unternehmen erkennen und umsetzen.[3] Für Deutschland ist mit einem Anstieg um circa 3,4 Prozent zu rechnen.[4]

Nicht nur international agierende Konzerne setzen auf Informationstechnologie, sondern auch der Mittelstand. Über 40 Prozent der IT- Investitionen werden vom Mittelstand getätigt.[5]

Während vor einigen Jahrzehnten überwiegend Individualsoftware programmiert, also eine individuell auf die Bedürfnisse eines Unternehmens zugeschnittene Software entwickelt wurde, wird heute hauptsächlich Standardsoftware eingeführt.[6]

Bei der Standardsoftware handelt es sich um fertige, aus einer Menge von Programmen bestehendes Paket. Sie sind in der Lage einen vollständigen Geschäftsprozess oder ein abgeschlossenes Anwendungsgebiet (z.B. das Controlling) abzudecken. Es müssen nur noch wenige Anpassungen (Customizing) an die speziellen Anforderungen des Unternehmens vorgenommen werden.[7]

Die Vorteile einer Standardsoftware:

- Der Kauf ist kostengünstiger als die Eigenentwicklung.
- Sie ist sofort verfügbar und kann deshalb in kürzerer Zeit eingeführt werden.
- Risiken (Abstimmungsprobleme, Ausfall von Projektarbeitern, Terminüber- schreitungen, u. a.) die bei der Entwicklung von Individualsoftware auftreten entfallen weitgehend
- Spezielle IT-Fachkenntnisse, wie sie bei der Entwicklung von Individualsoftware benötigt werden, sind nicht nötig.

Natürlich ergeben sich auch Nachteile bei der Anschaffung einer Standardsoftware, diese werden aber weitgehend durch die Vorteile aufgewogen.[8]

Die stark zunehmende Komplexität und Menge des Datenmaterials erfordert den Einsatz und die Unterstützung durch geeignete Standardsoftware. Dies gilt insbesondere für den Bereich Controlling, der schnell, empfängerorientiert und situationsgerecht die Informationen zur Verfügung stellen muss um seiner Funktion gerecht zu werden.

Nur durch eine verbesserte und beschleunigte Informationsversorgung sowie einer zeitnahen Kontrolle kann das Unternehmen schnell auf geänderte wirtschaftliche Rahmenbedingungen reagieren und somit seine Wettbewerbsposition nachhaltig stärken.[9]

Die bisherigen Lösungen, vor allem im Mittelstand, bestanden aus Excel-Lösungen. Die letzten Jahre vollzog sich aber ein Wandel, der Anteil der ausschließlichen Excel-Nutzer sank von 52 auf 31 Prozent. Der Hauptgrund dafür war und ist die Erkenntnis, dass sich diese Excel-Konstrukte im Laufe der Jahre immer mehr zu wahren „Monstern“ entwickeln, die kaum noch von Mitarbeitern durchschaut werden können. Allerdings bleiben Programme wie Excel weiterhin die „Schwergewichte“ zur Unterstützung des Controllings im Mittelstand.

Von 223 befragten mittelständischen Unternehmen, planen 46 Prozent die Anschaffung neuer Software.[10]

Diese Daten zeigen, dass die Bereitschaft zu IT-Ausgaben auch bei den mittelständischen Unternehmen gestiegen ist. Der Praxispartner, die Valentum Consulting Group GmbH, hat aufgrund dieser Daten und einer gestiegenen Nachfrage seitens der Mandanten nach betriebswirtschaftlicher Standardanwendungssoftware entschieden, eine Software-Auswahl vorzunehmen. Der Praxispartner beschäftigt sich überwiegend mit mittelständischen Unternehmen und Start-ups. Ziel dieser Software-Auswahl ist es, die Excel-Lösungen die bisher angeboten werden, durch eine geeignete Standardsoftware zu ersetzen.

Die Scheiterquoten bei IT-Projekten bewegen sie je nach Land und Lage zwischen 50 und 80%.[11] Weiterhin sind nur 9 % der IT-Projekte on time and budget. Diese Zahlen stammen aus dem angelsächsischen Sprachraum, in dem Projektarbeit am weitesten verbreitet ist. Im deutschsprachigen Raum fehlen konkrete Erhebungen.[12]

Der häufigste Grund, laut einer Umfrage der IT-Knowledge-Internet-Seite www.gulp.de, ist der Mangel an präzisen Vorgaben.[13] Diese sind aber nötig um gezielt eine Auswahl auf dem Software-Markt, der über 500 Software-Lösungen und über 1.000 Anbieter beinhaltet, treffen zu können.[14] Beachtet man weiterhin dass die Einsatzdauer von Anwendungssoftware bei durchschnittlich 15 Jahren liegt, somit einen langfristigen Charakter hat, wird deutlich das dem Auswahlprozess einer Standardsoftware eine besondere Bedeutung zukommt.[15]

Um bei der Auswahl einer Standardsoftware strukturiert und vor allem logisch aufbauend vorgehen zu können empfiehlt es sich nach den Regeln des Projektmanagements vorzugehen.[16]

Darunter versteht das Deutsche Institut für Normung “die Gesamtheit von Führungsaufgaben, -organisation, -techniken und –mittel für die Abwicklung eines Projektes.“[17]

Im Kapitel 2 wird zunächst der Begriff Projekt definiert. Anschließend erfolgt die Bestandsanalyse, sie umfasst die Ist- und die Schwachstellenanalyse des Unternehmens. Die Zielbestimmung, die u. a. aus der Bestandsanalyse abgeleitet wurde, stellt die Basis für die darauffolgende Konkretisierung der Aufgabenstellung dar. In den Kapiteln 3 – 5 werden die „idealtypischen“ Phasen des Projektmanagements vorgestellt und praxisbezogen modifiziert. Abschließend erfolgt eine Darstellung der Ergebnisse woraus eine Empfehlung hinsichtlich der Standardsoftware abgeleitet wird.

2 Projektdefinition

Nach DIN 69 901 ist ein Projekt ein „Vorhaben, das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzungen gegenüber anderen Vorhaben [...].“[18]

In der Praxis wird ein Projekt auch als Vorhaben mit den folgenden Merkmalen charakterisiert:

- Bedeutung des Projektergebnisses

Das Projektergebnis sollte beispielsweise die Erfüllung der Geschäftsstrategie oder die Umsetzung konkreter Geschäftsziele maßgeblich unterstützen.

- Beteiligung mehrerer Organisationseinheiten

Ein Projekt beinhaltet in der Regel übergreifende Aufgabenstellungen, dies erfordert eine Zusammenarbeit zwischen den verschiedenen Fachbereichen. Bei größeren Unternehmen wird häufig eine spezielle Projektorganisation notwendig.

- Innovation

Die Art der Aufgabenstellung wurde vorher noch nie bewältigt.[19]

- Zeitliche Befristung

Bein einem Projekt handelt es sich nicht um eine permanente Aufgabe – wie z.B. den Einkauf oder die Buchhaltung- sondern, um eine Aufgabe die durch einen klar definierten Anfangs- und Endzeitpunkt definiert ist.

- Konkurrenz um begrenzte Mittel

Die Ressourcen zur Durchführung eines Projektes sind begrenzt. Weiterhin besteht eine Art Konkurrenzsituation zu anderen Projekten und zu andauernden Aufgaben um personelle, finanzielle und andere Mittel.

- Risikobehaftung

Die bereits genannten Merkmale, insbesondere die zeitliche Befristung und Innovation bedingen, dass ein Projektvorhaben grundsätzlich risikobehaftet ist.[20] Dabei lassen sich die Risiken aufteilen in ein Termin-, Kosten- und ein Qualitätsrisiko.[21]

Weiterhin sind Projekte als eigenständige soziale Systeme anzusehen, die in ein projektspezifisches Umfeld eingebettet sind. Man kann sie als eigenständige soziale Systeme bezeichnen, weil sehr häufig Arbeitsformen, Handlungsmuster, Kommunikationsflüsse und Regeln entstehen, die sich von der Kultur des gesamten Unternehmens unterscheiden.

Die Einbettung in ein projektspezifisches Umfeld bedeutet in diesem Zusammenhang, dass man Projekte nie losgelöst von Umfeldeinflüssen sehen darf. Denn erst durch die bewusste Berücksichtigung dieser Umfeldeinflüsse, entsteht eine Gesamtsicht des Projekts.[22]

In der Literatur werden verschiedene Projektarten anhand zusätzlicher spezifischer Merkmale und Risiken unterschieden. Sogenannte IT-Projekte können in Abhängigkeit von ihren Zielsetzungen einen völlig unterschiedlichen Inhalt haben. Folgende Zielsetzungen sind möglich:

- Die Neuentwicklung einer Software. Eine solche Software kann sowohl eine Individualentwicklung sein, die speziell für einen Anwender entwickelt wird, als auch eine Standardlösung, die für einen breiteren Markt von Anwendern gedacht ist.
- Die Auswahl und ggf. Anpassung sogenannter COTS-Software.[23] Der Begriff steht dabei für Software, die in einer gegebenen Grundversion „aus dem Regal“ eines Softwareanbieters gekauft werden kann. Sie reichen von so genannten Office-Paketen bis hin zu ERP[24] -Systemen.[25]
- Die Analyse der Geschäftsprozesse und Geschäftprozessoptimierung mit anschließender Automatisierung der Prozesse durch IT-Systeme.
- Aufbau von Internet-Marktplätzen und E-Business, die mit einem IT-System unterstützt werden können.

„Unter einem IT-Projekt wird im folgenden ein Vorhaben mit den dargestellten Projektmerkmalen verstanden, bei dem zusätzlich der Erfolg des Projektes maßgeblich von der Einführung oder Veränderung eines Informations- oder Kommunikationssystems abhängt.“[26]

Aufgrund der theoretischen Grundlagen wird das Vorhaben der Prüfung und Auswahl betrieblicher Informationssysteme, im folgenden „Projekt PABI“ genannt, zu einem IT-Projekt deklariert. Die genaue Prüfung, ob ein Projekt vorliegt oder nicht ist enorm wichtig für den Projekterfolg. Häufig werden Prozesse mit Projekten verwechselt. Der Unterschied besteht darin, das ein Prozess zwar ein Endergebnis hat, aber er lässt sich nicht wie ein Projekt auf einen Stichtag fixieren. Ein Prozess liegt immer dann vor, wenn sich die Organisationsstruktur oder ein –ablauf ändert oder wenn Menschen ihr Verhalten ändern müssen. Ein Pseudoprojekt ist beispielsweise, die Einführung einer Wissensdatenbank für ein Unternehmen. Diese wird zwar technisch und physisch bis zu einem bestimmten Stichtag erstellt, aber was nützt sie dem Unternehmen, wenn sie keiner benutzt? Der Erfolg liegt also nicht in der Erstellung einer Datenbank, sondern in einer hohen Nutzungsrate durch die Mitarbeiter. Diese hängt natürlich von der Bereitschaft der Mitarbeiter ab. Wann diese Bereitschaft eintritt, kann nicht genau auf einen Stichtag fixiert werden, es kann lediglich ein Zielkorridor vorgegeben werden. Deswegen ist die Vorgehensweise bei einem Prozess anders, als bei einem Projekt. Dies erklärt auch die Notwendigkeit der Abgrenzung zwischen einem Projekt und einem Prozess.[27]

Bei dem vorliegenden Projekt PABI handelt es sich um ein kleines Projekt, da die Laufzeit kleiner als ein halbes Jahr ist und weniger als sechs Mitarbeiter beteiligt sind.[28]

2.1 Projektmanagement

Der Begriff des Projektes wurde im vorrangegangenen Kapitel bereits abgehandelt. „Management ist die Leitung soziotechnischer Systeme in personen- und sachbezogener Hinsicht mit Hilfe von professionellen Methoden. In der sachbezogenen Dimension des Managements geht es um die Bewältigung der Aufgaben, die sich aus den obersten Zielen des Systems ableiten, in der personenbezogenen Dimension um den richtigen Umgang mit allen Menschen, auf deren Kooperation das Management zur Aufgabenerfüllung angewiesen ist.“[29] Zu den Aufgaben des Managements zählen Ziele setzen, Planen, Entscheiden, Realisieren und Kontrollieren.[30] Demnach ist unter Projektmanagement ein Leitungs- und Organisationskonzept zu verstehen, mit dessen Hilfe versucht wird, die zahlreichen, sich teilweise gegenseitig beeinflussenden Projektelemente und –abläufe zu strukturieren und bestimmte Projektzustände zu vorher festgelegten Zeitpunkten planmäßig herbeizuführen.

Als Problemfelder des Projektmanagements können folgende Bereiche identifiziert werden:

- Aufgabenmängel

Hierzu zählen u.a. unklare Auftrags- und Zieldefinitionen; die Steuerung erfolgt nur nach Termin- und Kostenvorgaben nicht aber nach inhaltlichen Vorgaben und aufgrund mangelhafter Problemanalyse werden falsche Probleme beseitigt.

- Informations- und Kommunikationsdefizite

Dies beinhaltet vor allem die lückenhafte Abstimmung des Projektes mit dem Auftraggeber und dem Bereich; mangelhafte Projekttransparenz infolge ungenügender projektinterner Information und unvollständige personenabhängige Dokumentation.[31]

Zwischen dem herkömmlichen Projektmanagement und dem IT-Projektmanagement gibt es viele Gemeinsamkeiten, aber auch beinahe so viele Unterschiede. Einer der größten Unterschiede ergibt sich aus der großen Unsicherheit der Aufwands- und Kostenschätzung. Einerseits liegt dies an dem sehr hohen Innovationstempo und den daraus resultierenden ständigen Änderungen der technologischen und anwendungsseitigen Rahmenbedingungen. Zum anderen ergibt sie sich aus den relativ geringen Erfahrungen mit solchen Projekten.

Ein weiterer Unterschied ergibt sich aus der Schwierigkeit der projektbegleitenden Qualitätssicherung. Die primäre Ursache hierfür, Software ist ein immaterielles Gut. Materielle Zwischenergebnisse sind meist nicht genau definierbar, daher wird eine Prüfung oft nur intuitiv vorgenommen.[32]

Häufig wird bei kleineren Projekten das Projektmanagement überhaupt nicht oder nur halbherzig angewandt. Die Argumentation der Verantwortlichen ist, dass der Einsatz des Projektmanagements wegen des hohen Aufwands nicht sinnvoll sei.

Dabei ist besonders bei kleinen, internen Projekten ein systematisches planen und überwachen wichtig, da diese oftmals einfach im „Sande“ verlaufen, weil sich keiner verantwortlich fühlt.

Natürlich muss für solche Projekte nicht das gesamte Instrumentarium des Projektmanagements eingesetzt werden, vielmehr sollte es sinnvoll an die Größe des Projekts angepasst werden.[33] Dies wurde bei der vorliegenden Arbeit berücksichtigt.

Um ein Projekt plan- und kontrollierbar machen zu können, muss es zuerst strukturiert werden. In der Projektmanagement-Literatur existieren verschiedene Vorgehensmodelle, mit deren Hilfe eine hierarchische Gliederung des Projektes vorgenommen werden kann.

Sie dienen in erster Linie der allgemeinen Ablaufmodellierung, die einen genauen Überblick über das Gesamtprojekt ermöglicht.[34] Bei der Anwendung solcher Vorgehensmodelle, muss unbedingt beachtet werden, das sie, wie der Name schon sagt, nur als Modell verstanden werden dürfen. Jedes Vorgehensmodell muss für das jeweilige Projekt angepasst werden, auch eine Kombination verschiedener Modelle ist möglich.[35]

Für das vorliegende IT-Projekt wurde das Phasen- oder Wasserfallmodell gewählt.

Bei dieser Vorgehensweise wird das Projekt zuerst in einzelne, sequentielle Phasen aufgeteilt.

Unter einer Phase wird eine Aneinanderreihung von arbeitsteiligen Aufgaben verstanden, die in sich abgeschlossen sind. In der Literatur existieren zahlreiche Varianten dieses Modells mit im Detail durchaus unterschiedlichen Aufteilungen und Untergliederungen. Das vorliegende IT-Projekt PABI wurde in folgende Phasen aufgeteilt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Phasenweiser Projektablauf

Im klassischen Wasserfallmodell werden die Phasen in einer linearen Abfolge durchlaufen. Bei der vorliegenden Arbeit wurde dieses ergänzt durch Rücksprunge und Iterationen.[36] Rücksprünge erschweren zwar die Planung eines Projektes, sind aber in der Praxis oft nicht zu vermeiden. In der Praxis kann es aus zwei Gründen notwendig werden, erneut in eine Phase einzutreten, die bereits abgeschlossen ist. Einerseits werden nachträglich Fehler im Ergebnis einer bereits abgeschlossenen Phase festgestellt. In diesem Fall ist die Überarbeitung dieses Ergebnisses erforderlich. Dabei sollte sehr restriktiv vorgegangen werden, d.h. man sollte sich nur auf die Behebung „wirklicher“ Fehler beschränken.

Der zweite Grund für einen erneuten Eintritt in eine bereits abgeschlossene Phase können neue Anforderungen an das System sein. Sich ständig wandelnde Anforderungen sind eine der Hauptursachen für das Scheitern von IT-Projekten.[37]

Nach der Aufteilung des Projektes in einzelne Phasen, erfolgt die Definition der Inhalte also der Aufgaben. Bei der Definition einer Aufgabe innerhalb des Vorgehensmodells ist darauf zu achten, dass zumindest folgende Fragen geklärt sind:

- Worauf baut sie auf?
- Was soll bei der Bearbeitung untersucht und/oder entwickelt werden?
- Wie soll dies geschehen?
- Welche Ergebnisse sind zu erarbeiten?[38]

Die Abarbeitung der einzelnen Aufgaben erfolgt nacheinander, d.h. erst wenn eine Aufgabe erledigt ist, wird mit der nächsten begonnen.

Bei dem phasenweisen Projektablauf werden einzelnen Phasen definiert, die durch Entscheidungssituationen miteinander verbunden sind. Weiterhin wird ein Prozess der zunehmenden Konkretisierung und Detaillierung durchlaufen. Vorteil einer solchen Vorgehensweise ist die Erzielung einer hohen Transparenz gleich zu Beginn des Projekts.[39]

Eine klare Projektdefinition ist die Grundvoraussetzung für das Gelingen des Projektes.[40]

Sie sollte kurz und prägnant die projektrelevanten Gesamtzusammenhänge beschreiben.[41]

Im folgenden werden die wesentlichen Bestandteile einer Projektdefinition näher vorgestellt.

2.2 Projektleiter

Projektmanagement setzt sich zusammen aus personellen und funktionellen Regelungen, wie sie bereits im vorherigen Kapitel abgehandelt wurden. Der Projektleiter stellt das Kernstück des personellen Projektmanagements dar. Er greift bei seiner Arbeit auf die Instrumente des funktionellen Projektmanagements zurück.[42]

Die Projektleitung wird von der Unternehmensleitung ernannt. Sie sollte ganz am Anfang eines Projektes bestimmt werden. Bei kleineren Projekten wird die Projektleitung nur durch eine einzige Person, dem Projektleiter, repräsentiert.

Die Suche nach einem fähigen Projektleiter sollte sich in erster Linie auf die Mitarbeiter des Unternehmens beschränken. Dabei ist selbst dann dem bekannten Mitarbeiter aus den eigenen Reihen der Vorzug zu geben, wenn er keine oder nur wenig praktische Projektleitungs-Erfahrungen hat. Denn neu eingestellte Projektleiter benötigen zusätzlich kostbare Zeit, um das Unternehmen und seine Mitarbeiter kennen zu lernen und um akzeptiert zu werden.[43] In der Literatur existieren viele Anforderungsprofile für Projektleiter, diese geforderten Qualifikationen in einer Person zu finden, ist fast unmöglich. Deshalb sollten solche Anforderungsprofile als „Ideal“ angesehen werden, dem der Projektleiter möglichst nahe kommen sollte. Es folgt die Darstellung eines gekürzten Anforderungsprofils.[44]

Abbildung in dieser Leseprobe nicht enthalten

In Anlehnung an: Patzak, G./Rattay, G., Leitfaden, 1997, S.130f.

Abb. 2: Anforderungsprofil des Projektleiters

Als Projektleiter für das Projekt PABI wurde eine qualifizierte Diplomandin von der Geschäftsführung ausgewählt, da intern keine personellen Ressourcen vorhanden waren.

Die Aufgaben des Projektleiters umfassen die Planung, Überwachung und Koordination des Projektes. Weiterhin trägt er die persönliche Verantwortung für die Einhaltung des Projekttermins und des Projektbudgets.[45] Wichtigste Aufgabe des Projektleiters ist die Vermittlung zwischen den betroffenen Gruppen, also dem Management, den Anbietern und den Benutzern. Die Schwierigkeit besteht darin, dass die betroffenen Gruppen äußerst unterschiedliche Wünsche und Forderungen verfolgen.[46]

Dies zeigt, das ein Projektleiter eben nicht nur ein Projektleiter ist. Viele, vor allem unerfahrene Projektleiter konzentrieren sich lediglich auf die Rolle des Leiters, d.h. sie beschränken sich „nur“ auf die Planung, Überwachung und Koordination des Projektes. Für den Projekterfolg ist dies zu wenig, denn nur 20 Prozent hängen vom Management des Projektes ab. Die restlichen 80 Prozent hingegen hängen von den übrigen Rollen des Projektleiters ab. Die Rollen im einzelnen:

- Produktionsleiter, entspricht der Rolle des Arbeitspakete-Managers.
- Vertriebs- und Marketingleiter, denn ein erfolgreicher Projektleiter muss sein Projekt auch verkaufen können. Dies ist besonders wichtig, wenn es um die Verteilung der knappen internen Ressourcen geht. Der Projektleiter ist dafür zuständig, das sozusagen in engen Märkten genügend zahlungskräftige Kunden für das Projekt gefunden werden, die Personal, Budget und andere Ressourcen abstellen.
- Forschungs- und Entwicklungsleiter, diese Rolle beinhaltet das entwickeln, sichern und dokumentieren des Wissens und die Verteilung an die entsprechenden Stellen.[47]
- Personalchef, d.h. er sollte sich für die Humanressourcen, die ihm zur Verfügung gestellt wurden, verantwortlich fühlen. Wie im Anforderungsprofil schon erwähnt, sollte er daher über genügend Sozialkompetenz verfügen.
- Finanzchef und Controller, denn der Projektleiter muss sein Budget planen, kalkulieren und überwachen können.
- Geschäftsführer des Projekts, d.h. er muss seinem Auftraggeber, dem Management, voll verantwortlich Rede und Antwort über das Projekt und seine Fortschritte oder Schwierigkeiten stehen.[48]

Um eine reibungsfreie Arbeit des Projektleiters zu ermöglichen, müssen klare Kompetenzverhältnisse geschaffen werden. Projektleiter sollten auf eine schriftliche Kompetenzfestlegung bestehen, um späteren Konflikten vorzubeugen.[49]

Für ein erfolgreiches Agieren ist weiterhin die volle Unterstützung der Geschäftsleitung nötig, diese muss auch nach außen, d.h. gegenüber den Mitarbeitern, gelebt werden. Nur so wird eine Basis der Akzeptanz und Bereitschaft zur Mithilfe an dem Projekt geschaffen, die wiederum die Grundlage für den Erfolg des Projektes darstellt.[50]

2.3 Bestandsanalyse

Die Bestandsanalyse umfasst die Analyse der Ist-Situation und die der Schwachstellen. Durch dieses Vorgehen wird die Problemstellung, die zum Start des gegenständlichen Projekts geführt hat ganzheitlich erfasst. Einerseits ist die Formulierung der Problemstellung die wesentliche Grundlage für eine realistische Zielfestlegung (vgl. Kapitel 2.4), andererseits ist sie vor allem in späteren Phasen, wenn Umfeldgruppen die nicht von Anfang an dabei waren, in das Projektteam integriert werden, ein wichtiges Mittel, um das Zustandekommen der spezifischen Projektziele nachvollziehen zu können.[51]

Wie schon in der Einleitung erwähnt, ist die Valentum Consulting Group GmbH eine Unternehmensberatungsgesellschaft, die sich überwiegend mit mittelständischen Unternehmen und Start-ups beschäftigt. Die Branchenschwerpunkte liegen in der Automobilindustrie und dem Gesundheitswesen.

Die Geschäftsbereiche lassen sich wie folgt untergliedern:

Abbildung in dieser Leseprobe nicht enthalten

Abb.3: Geschäftsbereiche

Bei der Ist-Analyse des Unternehmens wurde folgendes getan:

- Erhebung der Aufgaben und Arbeitsabläufe
- Dauer der Aufgaben
- Informationsfluss
- Schnittstellen.[52]

Es wurden verschiedene Erhebungstechniken angewandt, um den Ist-Zustand des Unternehmens ganzheitlich zu erfassen. Zuerst erfolgte eine mündliche Befragung der Geschäftsleitung. Dafür sollte vorher ein schriftlicher Fragebogen erstellt werden. Dieser erleichtert auch die Protokollierung der Antworten.

Zusätzlich wurde eine Besprechung mit allen Beteiligten durchgeführt. Hier wurden restliche Fragen und Unklarheiten abgeklärt. Durch die aktive Einbeziehung aller Beteiligten, wird als positiver Nebeneffekt, die Akzeptanz und die Motivation für das Projekt erhöht.

Ergänzt wurde die Datenerhebung durch die Beobachtung der Arbeitsabläufe.[53]

Bisher wurden zur Bewältigung von controlling- bzw. rechnungswesenrelevanten Sachverhalten MS-Excel Tools eingesetzt. Für die Erstellung dieser Tools wurden circa 2-3 Wochen benötigt. Die Anpassungen, die für jeden neuen Mandanten vorgenommen werden müssen, dauern 1-2 Tage. Weiterhin wird 1 Tag benötigt, um dieses Tool mit den benötigten Informationen manuell zu bestücken um letztendlich die gewünschte Auswertung zu erhalten.

Die manuelle Eingabe der Daten ist notwendig, da das Unternehmen über keine Schnittstellen zu den Mandanten, für die vorhandenen Excel-Tools, verfügt. Ein weiterer Grund für die manuelle Eingabe ist die Tatsache, dass die meisten Mandanten ihre Finanzbuchhaltung nicht selbst, sondern von Dritten, in den meisten Fällen von Steuerberatern, durchführen lassen. Diese verwenden überwiegend DATEV-Software zur Erfassung der Buchungen, bislang ist aber auch hier noch keine Schnittstelle vorhanden.[54]

Diese Ist-Analyse lässt schon einige Schwachstellen deutlich werden.

Die größte Schwachstelle stellt der enorme Zeitaufwand dar, der aus fehlenden Schnittstellen zu den Mandanten und zu den Steuerberatern resultiert. Allein für die Anpassung und die manuelle Eingabe der Informationen werden ca. 2 Tage benötigt. Die Zeit für die eigentliche Beratung nicht inbegriffen. Für die Anpassungen der vorhandenen Excel-Tools ist fortgeschrittenes Ecxel-Know-How notwendig, da die bestehenden Vorlagen auf Makros basieren. Anpassungen sind notwendig, da eine Standardauswahl von Kennzahlen, aufgrund der Begrenztheit von Excel, nicht möglich ist. Da, wie eben schon erwähnt, einige Mandanten ihre gesamte Buchführung und Bilanzierung an Dritte weitergegeben haben, ist auch die Generierung von Informationen nur unter Zwischenschaltung dieser Dritten möglich. Der Informationsfluss ist somit nicht optimal.[55]

Diese Problemstellung bildet die wesentliche Grundlage für die folgende Zielbestimmung.

2.4 Zielbestimmung

Eine Definition der Projektziele sollte gleich zu Anfang eines Projektes erfolgen, denn diese stellen die wesentlichen Weichen im Projekt. Sie sollten klar und präzise den Zustand beschreiben, der am Projektende vorliegen soll. Die Nachbesserung von Zielen während eines Projektes ist mit einem sehr hohen Aufwand verbunden, und können den Projekterfolg erheblich gefährden.[56]

Klare Ziele stellen in hektischen Phasen einen Anhaltspunkt zur Rückbesinnung, Neuorientierung und Fokussierung auf das Wesentliche dar.[57] Weiterhin sind sie eine Art Messlatte, anhand derer sich später überprüfen lässt, ob die gefundene Lösung tatsächlich den Zielen entspricht.[58]

Die Theorie gibt unter anderem folgende Regeln für die Zielbestimmung vor:

- Sie sollten lösungsneutral sein, um nicht bereits am Anfang etwaige Lösungen auszuschließen.
- Die Zielformulierung sollte realistisch sein, so das sie zwar fordert, aber nicht demotiviert.[59]
- Ziele sollten operational[60] sein, um als Maßstab für die Überprüfung und Beurteilung des Ergebnisses dienen zu können.[61]

Eine der ersten Aufgaben bei der Zielbestimmung ist die Konkretisierung der Strategie, die das Unternehmen verfolgt. Nur wenn die Strategie des Unternehmens genau bekannt ist, kann eine Software ausgewählt werden, die eben diese Strategie so gut wie möglich unterstützt. Dazu werden die im Unternehmen vorhandenen Vorstellungen (Visionen) zur Gestaltung der Zukunft festgehalten. Daraus können dann die relevanten Ziele abgeleitet werden.[62]

Das strategische Ziel des Unternehmens besteht in der Erhöhung der Wettbewerbsvorteile.[63]

Dieses strategische Ziel kann wie folgt untergliedert werden:

- Erhöhung der Qualität der Auswertungen
- Verbesserung des Informationsflusses
- Reduktion der Fehlerhäufigkeit
- Schaffung eines Standards
- „interne“ Fortbildung
- Zeit- und Ressourceneinsparung

[...]


[1] Vgl. Ogger, G., Manager, 1995, S. 225

[2] Vgl. Bär, A.-M., Einführung, 2001, S.1

[3] Vgl. IHK-Regensburg, IT-Ausgaben, 2004

[4] Vgl. Schmitz, A., Modelle, 2004

[5] Vgl. Computerwoche, Mittelstand, 2004

[6] Vgl. Bär, A.-M., Einführung, 2001, S.1

[7] Vgl. Stahlknecht, P./ Hasenkamp, U., Wirtschaftsinformatik, 2004, S.213

[8] Vgl. Stahlknecht, P./Hasenkamp, U., Wirtschaftsindormatik, 2004, S. 296 f.

[9] Vgl. Daum, E., Unternehmens-Controlling, 1998, S. 1

[10] Vgl. KuL Studie, 2003/04, S. 1 ff.

[11] Vgl. Teich, I./Kolbenschlag, W., Richtige Software, 2003, S. 17

[12] Vgl. Standish Group, 1995

[13] Vgl. Gulp, Umfrage, 2002

[14] Vgl. Sontow, K., Millionengrab, 2004, S.3

[15] Vgl. Bange, C./Keller, P., Software-Auswahl, 2003, S. 7

[16] Vgl. Bär, A.-M., Einführung, 2001, S.2

[17] DIN 69901, Projektwirtschaft, 1987

[18] DIN 69901, Projektwirtschaft, 1987

[19] Vgl. Gaulke, M., IT-Projekte, 2002, S.9f.

[20] Vgl. Henrich, A., Softwareprojekte, 2002, S.7f.

[21] Vgl. Wischnewski, E., Aktives Projektmanagement, 2002, S.25

[22] Vgl. Patzak, G./Rattay, G., Leitfaden, 1997, S.5

[23] COTS = commercial of the shell

[24] ERP = Enterprise Resource Planning

[25] Vgl. Henrich, A., Softwareprojekte, 2002, S.11

[26] Vgl. Gaulke, M., IT-Projekte, 2002, S.10

[27] Vgl. Reiter, W., Wahrheit, 2003, S.38ff.

[28] Vgl. Litke, H.-D., Projektmanagement, 1995, S.84 f.

[29] Ulrich, P./Fluri, E., Management, 1984, S.36

[30] Vgl. Wöhe, G., Betriebswirtschaftslehre, 2000, S.107

[31] Vgl. Daum, E., Unternehmens-Controlling, 1998, S.57f.

[32] Vgl. Henrich, Softwareprojekte, 2002, S.12f.

[33] Vgl. Schelle, H., Projekterfolg, 2004, S. 43 f.

[34] Vgl. Henrich, A., Softwareprojekte, 2002, S.34

[35] Vgl. Reiter, W., Wahrheit, 2003, S.48

[36] Vgl. Henrich, A. Sofwareprojekte, 2002, S. 39ff.

[37] Vgl. Feyhl, A./Feyhl, E., Softwareprojekt, 1996, S.15f.

[38] Vgl. Henrich, A., Softwareprojekte, 2002, S.33

[39] Vgl. Litke, H.-D., Projektmanagement, 1995, S.25f.

[40] Vgl. Wolf, M./Mlekusch, R./Broks, H., Live, 1997, S. 24

[41] Vgl. Patzak, G./Rattay, G., Leitfaden, 1997, S. 91

[42] Vgl. Grupp, B., IT-Projektleiter, 2003, S.22

[43] Vgl. Rinza, P., Projektmanagement, 1998, S.135

[44] Vgl. Feyhl, A./Feyhl, E., Softwareprojekt, 1996, S.29f.

[45] Vgl. Schelle, H., Projekterfolg, 2004, S.67f.

[46] Vgl. Henrich, A., Softwareprojekte, 2002, S.133

[47] Vgl. Reiter, W., Wahrheit, 2003, S.34f.

[48] Vgl. Patzak, G./Rattay, G., Leitfaden, 1997, S.113ff.

[49] Vgl. Kellner, H., Konfliktfrei, 1996, S.34

[50] Vgl. Rinza, P., Projektmanagement, 1998, S.140f.

[51] Vgl. Patzak, G./Rattay, G., Leitfaden, 1997, S.92

[52] Vgl. Stahlknecht, P./Hasenkamp, U., Wirtschaftsinformatik, 2004, S. 227 f.

[53] Vgl. Feyhl, W./Feyhl, E., Softwareprojekt, 1996, S. 63f.

[54] Vgl. Stahlknecht, P./Hasenkamp, U., Wirtschaftsinformatik, 2004, S. 228 ff.

[55] Vgl. Feyhl, A./Feyhl, E., Softwareprojekt, 1996, S. 65

[56] Vgl. Patzak, G./Rattay, G., Leitfaden, 1997, S. 92

[57] Vgl. Heche, D., Praxis, 2004, S. 37

[58] Vgl. Wolf, M./Mlekusch, R./Broks, H., Live, 1997, S. 42

[59] Vgl. Schelle, H., Projekterfolg, 2004, S. 87

[60] operationale Ziele: qualitative und/oder quantifizierbare Ziele

[61] Vgl. Patzak, G./Rattay, G., Leitfaden, 1997, S. 92

[62] Vgl. Teich, I./Kolbenschlag, W., Richtige Software, 2003, S.63f.

[63] Vgl. Daum, E., Unternehmens-Controlling, 1998, S.67

Details

Seiten
70
Jahr
2005
ISBN (eBook)
9783638368124
ISBN (Buch)
9783656157854
Dateigröße
763 KB
Sprache
Deutsch
Katalognummer
v37484
Institution / Hochschule
Hochschule Merseburg
Note
1,5
Schlagworte
Prüfung Auswahl Informationssysteme Beratungsunternehmen Controlling

Autor

Teilen

Zurück

Titel: Prüfung und Auswahl betrieblicher Informationssysteme für ein Beratungsunternehmen