Vorgehensmodell ERP-Projekt

Transkript

2 Management Summary Die Einführung oder Umstellung einer ERP/CRM-Software ist in jedem Fall ein Projekt, das hohen personellen Aufwand erfordert. Auch wenn die Investitionssumme in kleineren mittelständischen Unternehmen vielleicht nur in der Größe eines Mittelklasseautos liegt, sind die personellen Aufwände nicht zu unterschätzen. Um beim Beispiel Autokauf zu bleiben: Sobald der Kaufvertrag unterschrieben ist, kann sich der Besteller zurücklehnen und bis zur Auslieferung warten. Ist das Fahrzeug vor der Tür, steigt er ein und fährt los. Wenn die Entscheidung für ein ERP-Projekt gefallen ist, geht es dagegen mit der Arbeit erst richtig los. Lastenheft, Pflichtenheft, Mitarbeiter-Interviews, Test, Parallelbetrieb, Abnahme, Rollout und Schulung sind nur die wichtigsten Stichworte. Die gute Nachricht ist, dass der Verantwortliche des Auftraggebers einen großen Teil dieser Arbeiten an den Dienstleister auslagern kann, sofern dieser über die notwendige Expertise verfügt und es den Vertragspartnern gelungen ist, eine belastbare Vertrauensbasis zu finden. Die Vorstufe zum Projekt beginnt mit dem Kennenlernen von Auftraggeber und Dienstleister. Nur wenn beide auf Augenhöhe miteinander verhandeln können und die Sprache des anderen verstehen, kann das Projekt erfolgreich verlaufen. Mit anderen Worten: Die Chemie muss stimmen. Im Erstgespräch wird das Vorgehensmodell mit vier Phasen erläutert und der mögliche Zeit- und Budgetrahmen diskutiert. Es wird auch zumindest grob festgelegt, wer welche Aufgaben übernehmen kann und soll. Wenn es ein genehmigtes Budget gibt und der geplante Zeitrahmen passen kann, geht es um die Erstellung von Lastenheft und Pflichtenheft. Hier wird es individuelle Ausprägungen geben: Von der hemdsärmeligen Vorgehensweise nach dem Motto Wir fangen einfach mal an bis hin zu einem umfangreichen Pflichtenheft, in dem die Lage und Größe jedes Datenfeldes in der Benutzeroberfläche pixelgenau festgelegt ist. Man kann Argumente für beide Extreme finden, aber man bleibt immer im Spannungsfeld zwischen Flexibilität und Kosten sowie dem Zeitrahmen als drittem Parameter. ITSM versucht hier, den Auftraggeber von einer Mischform zu überzeugen. Bestimmte Punkte müssen vor Entwicklungsstart klar und deutlich festgelegt werden. Andere Dinge können bei der Umsetzung im Rahmen von Prototyping bestimmt werden. Es fühlt sich für den Anwender einfach besser an, tatsächlich einmal Stammdaten in einer Maske erfasst zu haben, als in einem Dokument zu lesen, wie die Maske aussehen soll. Wir beschreiben in diesem Dokument in aller Kürze die vier Phasen, die wir für die Durchführung eines ERP-Projekts definiert haben von der Konkretisierung der Aufgabenstellung über die Programmierung und Produktivsetzung bis hin zum Support nach der Einführung. / Praxisorientierter Ansatz Stand: Seite 2 von 8

3 Vier Phasen im ERP-Projekt Wir definieren bei ITSM vier Phasen in einem ERP-Projekt, die jedoch jeweils sehr individuell ausgestaltet sein können: 1. Definition der Aufgabenstellung (Lastenheft und Pflichtenheft) 2. Programmierung und Parametrisierung 3. Produktivsetzung mit Training on the Job 4. Support und ggf. Weiterentwicklung Lassen Sie uns diese vier Phasen nachfolgend etwas näher beschreiben. Aber bedenken Sie bitte, dass wir an dieser Stelle nur die wichtigsten Punkte anschneiden können. Jedes Projekt ist anders. Phase 1: Definition der Aufgabenstellung (Lastenheft und Pflichtenheft) Die Projektbeteiligten müssen gemeinsam das Projektziel definieren. Der Auftraggeber will natürlich wissen, was er geliefert bekommt, und der Dienstleister muss wissen, welchen Aufwand er zur Erreichung dieser Ziele kalkulieren muss. Die Anforderungen werden typischerweise in einem Lastenheft definiert. Dabei gilt der Grundsatz: Je genauer das spätere Angebot (und damit die Investitionssumme) sein soll, umso genauer muss das erwartete Ergebnis festgeschrieben werden. Eine Aussage wir müssen Auftragspapiere drucken können ist relativ vage. Dagegen ist die folgende Aussage schon deutlich präziser: Wir müssen Angebote, Lieferscheine, Auftragsbestätigungen, Rechnungen, Kontoauszüge, Zahlungserinnerungen und Mahnungen drucken können. Bei den Angeboten muss es die Möglichkeit geben, Artikelbilder in das Angebot aufzunehmen, und wir müssen das Angebot auch als PDF per versenden können. Bei den Rechnungen müssen individuelle Zahlungsziele möglich sein. Für jeden Artikel bzw. jede Produktgruppe muss ein Erlöskonto auswählbar sein. Es kommt gerade in kleineren mittelständischen Betrieben vor, dass keine Mitarbeiter für die Erstellung eines Lastenheftes zur Verfügung stehen. Diese Arbeit kann durchaus auch vom Dienstleister erbracht werden. Er wird die notwendigen Informationen dann in Interviews mit der Geschäftsleitung und den verantwortlichen Mitarbeitern aufnehmen und zu einem kombinierten Lasten- und Pflichtenheft zusammenfassen. In den Interviews müssen die betrieblichen Prozesse detailliert erläutert und am besten anhand der vorhandenen Abläufe gezeigt werden. Weitere benötigte Informationen: Müssen Daten übernommen werden? Gibt es eine Dokumentation zum bisherigen System? Sind Schnittstellen zu externen Systemen zu planen? Wieviel Benutzer werden mit dem System arbeiten? Sind Außenstellen zu berücksichtigen? Wie ist das Mengengerüst? Heute und in fünf oder zehn Jahren? Diese und weitere Fragen sind in der ersten Phase zu klären. Aus der Beantwortung entsteht das Pflichtenheft, das gleichzeitig die Basis für die Angebotskalkulation ist. Wichtig ist in dieser Phase auch vor dem Vertragsabschluss eine vertrauensvolle Zusammenarbeit der Partner. Dazu gehören klare Spielregeln. Kein Anbieter kann wirklich seriös ein Festpreisangebot machen, wenn das Pflichtenheft ungenau ist. Das Einholen und Verarbeiten aller benötigten Informationen zu einem Pflichtenheft - in einem Detaillierungsgrad, der eine Programmierung ermöglicht - stellt einen beträchtlichen Aufwand dar, der den Rahmen der normalen Vertriebsarbeit deutlich übersteigt. Die Erstellung des Pflichtenhefts ist daher regelmäßig eine kostenpflichtige Vorstufe. / Praxisorientierter Ansatz Stand: Seite 3 von 8

4 Phase 2: Programmierung und Parametrisierung ITSM!ERP arbeitet mit einem umfassenden Datenmodell im Microsoft SQL Server, in dem sich der größte Teil der üblichen kaufmännischen Prozesse abbilden lässt. Daher fängt die Programmierung nicht bei Null an. In aller Regel benötigt der Auftraggeber nicht alle Felder, die es im Datenmodell gibt. Aber es kann natürlich auch umgekehrt vorkommen, dass es spezielle Anforderungen gibt, die wir in bisherigen Projekten noch nicht angetroffen haben. Es sind also immer Anpassungen der Benutzeroberfläche zu programmieren, damit der Auftraggeber genau die Eingabemasken erhält, die er für sein Unternehmen benötigt. Für die Entwicklung der Benutzeroberfläche und der Druckausgaben haben wir uns auf Microsoft Access festgelegt. Dieses weit verbreitete Office-Produkt bietet alle Möglichkeiten, um eine moderne und benutzerfreundliche Bedieneroberfläche zu gestalten, und das in einer relativ kurzen Zeit. Wichtig: Die Datenspeicherung erfolgt dagegen im Microsoft SQL Server. ITSM!ERP nutzt also nicht die in Access vorhandene Möglichkeit der Datenspeicherung in einer Desktop-Datenbank. Eine Speicherung von unternehmenskritischen Daten in einer Desktop-Datenbank wie Microsoft Access ist keine empfehlenswerte Lösung und wird von ITSM auch nicht programmiert. ITSM verbindet mit dieser Kombination aus Entwicklungsumgebungen das Beste aus zwei Welten: Die einfache und schnelle Gestaltung der Benutzeroberfläche in Microsoft Access und die sichere Datenhaltung in einer skalierbaren Datenbank, die auch bei sehr großen Datenmengen gute Antwortzeitzeiten garantiert. Als weiterer Vorteil kommt dazu, dass es im Markt sehr viele IT-Professionals gibt, die sich gut mit diesen beiden Produkten auskennen. Üblicherweise stellen wir als Erstes die Maske für die Erfassung und Anzeige von Stammdaten als Prototyp zum Testen und gegebenenfalls zur Diskussion von gewünschten Designänderungen fertig. Wenn das Design grundsätzlich abgenommen ist, gehen wir an die Programmierung der weiteren Elemente der Benutzeroberfläche. Wir gehen dabei so vor, dass wir nach Möglichkeit rasch einen kompletten Arbeitsablauf abbilden können zum Beispiel von der Erfassung eines neuen Kunden über das Erstellen eines Angebots bis hin zur Rechnung und Übergabe der Buchungsdaten an die Buchhaltungsschnittstelle. Wenn Daten aus Altbeständen zu übernehmen sind, schlagen wir immer die Entwicklung eines Ablaufs vor, im dem die jeweils aktuellen Daten wiederholt in das neue System übernommen werden können. Diese Arbeit muss ohnehin getan werden, und man kann diesen Vorgang auch beliebig häufig wiederholen, damit der Benutzer beim Umgang mit einer Beispielmaske auf vertraute Daten stößt. Das erleichtert erfahrungsgemäß die Schulung der Mitarbeiter und fördert die Akzeptanz der neuen Software. Unter Parametrisierung verstehen wir das Einpflegen von Daten, die üblicherweise in Dropdown-Feldern zur Auswahl angeboten werden. Dies können zum Beispiel Produktgruppen, Mitarbeiter oder Erlöskonten sein. Diese Daten speichern wir in sogenannten Lookup-Tabellen, die auch vom Kunden später selber gepflegt werden können. / Praxisorientierter Ansatz Stand: Seite 4 von 8

5 Phase 3: Produktivsetzung mit Training on the Job Nach erfolgreichem Abschluss der Phase 2 gilt es, die neue Software in die normalen Arbeitsabläufe einzubinden. Dies beginnt mit dem hoffentlich letztmaligem Überspielen der Altdatenbestände in das neue System. Danach werden neue Transaktionen ein neuer Kunde, ein neues Angebot usw. für einen definierten Zeitraum sowohl im alten System als auch im neuen System erfasst. Diese Maßnahme dient der letztmaligen Kontrolle, dass alle im bisherigen System erforderlichen Daten auch sicher im neuen System landen, und die Druckausgaben, wie zum Beispiel Rechnungen, inhaltlich mit dem alten System übereinstimmen. Je länger und intensiver bereits in der Phase 2 mit den Testdaten gearbeitet wurde, umso kürzer kann die Dauer des Parallelbetriebs festgelegt werden. Das sollte auch das Ziel sein, da die Doppelerfassung der Transaktionen ja zu einem deutlichen Mehraufwand führt. Die Phase 3 wird zumindest zeitweilig von ITSM-Mitarbeitern begleitet, die sofort vor Ort etwaige Fragen klären können. Es kann auch durchaus sein, dass zu diesem Zeitpunkt noch Verbesserungsvorschläge oder Erweiterungswünsche kommen. Diese werden aufgenommen und dokumentiert, jedoch im Rahmen dieser Phase nicht mehr umgesetzt. Sie führen als Anforderungsänderung (Change Request, siehe grafische Darstellung auf der letzten Seite) zu einem neuen Angebot. ITSM gibt dem Training on the Job aus Erfahrung den Vorzug vor einer formalen Schulung. Es ist für den Anwender einfach interessanter und lehrreicher, einen tatsächlich benötigten Vorgang mehrfach selber durchzuführen, als in einer stunden- oder tagelangen formalen Schulung zu sitzen. Ganz abgesehen davon, dass die Mitarbeiter in einer Präsenzschulung dem laufenden Tagesgeschäft entzogen sind. Es mag dann zwar sein, dass die vom Entwickler oder Projektleiter begleitete Erfassung eines neuen Kunden einmal 30 Minuten statt einer Minute dauert, aber beim zweiten Mal geht es schon schneller, und beim zehnten Kunden ist es bereits zur Gewohnheit geworden. Diese Effizienz ist mit einer herkömmlichen Schulung nicht zu erreichen. Zudem liegt häufig zwischen einer Schulung und der Inbetriebnahme der neuen Software eine gewisse Zeit, in der geschultes Wissen unter Umständen schon wieder in Vergessenheit geraten ist. / Praxisorientierter Ansatz Stand: Seite 5 von 8

6 Phase 4: Support und ggf. Weiterentwicklung Auch nach der Produktivsetzung Ihrer neuen Softwarelösung haben Sie selbstverständlich Zugriff auf unseren Support. Unsere Schwestergesellschaft, die ITSM GmbH, nimmt Störungen und Fragen an der Hotline auf und gibt sie bei Bedarf an die Entwicklung weiter. Die Hotline ist montags bis freitags von 7:00 bis 18:00 Uhr besetzt. Sie dokumentiert jede Anfrage in einem sogenannten Ticket, das Sie auf Wunsch auch online über unser Web-Portal eingesehen können. In diesem Ticket werden alle Arbeitsschritte mit dem jeweiligen zeitlichen Aufwand dokumentiert, die zur Lösung der Störung bzw. zur Beantwortung Ihrer Anfrage erforderlich wurden. Supportanfragen sind gemäß der grafischen Darstellung auf der folgenden Seite in bestimmten Fällen kostenpflichtig (gelber Streifen am rechten Kästchenrand). Davon abgesehen gibt es für ITSM!ERP keine monatlichen oder jährlichen Wartungsgebühren. Wenn das Projekt abgeschlossen und abgerechnet worden ist, erhalten Sie den offenen Quellcode Ihrer individuellen Anwendung. Voraussetzung ist der Abschluss eines Vertrags, in dem Sie sich verpflichten, den Quellcode nicht an Dritte herauszugeben, die nicht in Ihrem Auftrag handeln. Ausgenommen von der Offenlegung des Quellcodes ist lediglich unsere Funktionsbibliothek, die wir verschlüsselt ausliefern. Sie enthält von uns entwickelte, häufig benutzte Standardfunktionen. Diese können Sie zwar nutzen, aber nicht als Quellcode einsehen oder ändern. Während der Garantiezeit empfehlen wir Ihnen, nichts am Quellcode zu ändern. Sie würden damit Ihren Garantieanspruch verlieren. Sie möchten nach Abschluss des Einführungsprojekts eine Änderung oder Erweiterung? Dann haben Sie folgende Möglichkeiten: Sie verfügen über entsprechendes Know-how und führen die Änderung selber durch, Sie beauftragen einen Dritten mit der Durchführung Ihres Änderungswunsches, Sie beauftragen uns, und nur dann erhalten Sie von uns nach dem Einführungsprojekt eine Rechnung. Mehr Sicherheit geht nicht. / Praxisorientierter Ansatz Stand: Seite 6 von 8

7 Die folgende Grafik zeigt links die Ereignisse (E.10 bis E.30 und B.10), die bei der Entwicklung von Software und im laufenden Betrieb eintreten können. Blau markierte Einträge erfordern die Anlage eines Tickets, gelb markierte Einträge führen zu kostenpflichtigen Aktionen. Die Ereignisse E.40, B.40 und B.50 (rote Pfeile) können zu einer neuen Anforderung führen. / Praxisorientierter Ansatz Stand: Seite 7 von 8

8 Über ITSM Die ITSM Gesellschaft für Informationstechnologie und Services Meiß mbh ist ein 1998 gegründetes IT-Systemhaus in Langenfeld/Rheinland, das mittelständische Unternehmen in allen Fragen der Informationsverarbeitung und Telekommunikation berät und unterstützt. Die Gesellschaft bedient schwerpunktmäßig die Themen Server Based Computing und Local Cloud Hosting, die erhebliches Einsparungspotenzial bei Investitionen und laufendem Betrieb aufweisen. ITSM plant und realisiert als Microsoft Partner individuell ausgelegte Netzwerkinfrastrukturen, die auch in deutschen Rechenzentren gehostete Server und Speicher umfassen. In 2015 wurde die Softwareentwicklung in die Schwestergesellschaft ITSM OHG ausgegliedert. Hier erfolgt die kontinuierliche Weiterentwicklung des Kernprodukts ITSM!ERP. Neben dieser individuell anpassbaren ERP/CRM-Lösung auf Basis der Produkte Microsoft SQL Server und Microsoft Office bietet die ITSM OHG auch Auftragsprogrammierung wie zum Beispiel Schnittstellen oder Webservices an. Beide Unternehmen arbeiten an einem gemeinsamen Standort in Langenfeld/Rheinland also in zentraler Lage zwischen Düsseldorf und Köln eng zusammen und stehen unter gemeinsamer Leitung. Seit Jahren bildet ITSM selber Fachinformatiker mit dem Ziel der späteren Übernahme als feste Mitarbeiter aus. Anfang 2016 beschäftigt ITSM 15 Mitarbeiter. / Praxisorientierter Ansatz Stand: Seite 8 von 8