Procurement Study ERP System

Transkript

1 Procurement Study ERP System Andreas Math Rebekka Bodon Sarah Dierks Annahmen Wir sind ein mittelständiges Softwareunternehmen, welches sich auf GUI-Entwicklung spezialisiert hat. Wir entwickeln die GUI des ERP-Systems selbst. Es soll außerdem als Referenz für das Können unseres Unternehmens stehen. Um eine funktionierende Anwendungslogik gewährleisten zu können, muss diese von einem Drittanbieter erworben werden.

2 Plan Procurement 1. Anforderungsanalyse Da zur Zeit noch nicht genau feststeht, welche Geschäftsprozesse im ERP abgebildet werden sollen, müssen diese erst in der Anforderungsanalyse identifiziert werden. Da sich unsere Firma auf insgesamt 3 Standorte verteilt, müssen die Prozesse standortübergreifend als auch nach Standorten getrennt, ausfindig gemacht werden und in einem Dokument festgehalten werden. Kategorisierung der Anforderungen in die drei Kategorien must have, need to have und nice to have. Die Anforderungsanalyse wird von unseren Mitarbeitern durchgeführt und es sind für jeden Standort sieben Arbeitstage dafür geplant. Rollen: Der Business Analyst, CIO, CEO, Financial Director 2. Bestandsanalyse In diesem Schritt geht es darum, zu analysieren, auf welcher Plattform die Software später laufen soll. Außerdem muss geprüft werden, ob Hardware beschaffen werden muss oder ob die momentan vorhandene ausreicht. Es muss überlegt werden, ob es später einen gemeinsamen Server für alle Standorte geben soll. Für diese Analyse stehen 3 Arbeitstage zur Verfügung. Rollen: Die IT-Abteilung und insbesondere der CIO führen die Analyse durch und machen einen Vorschlag für eventuelle Neubeschaffungen. Der Financial Director überprüft den Vorschlag und genehmigt ihn / lehnt ihn ab. 3. Make & Buy Analyse Da sich unsere Firma auf die Entwicklung von GUIs spezialisiert hat, erstellen wir die GUI für das ERP-System selbst. Um eine funktionsfähige Anwendungslogik gewährleisten zu können, muss eine Firma gesucht werden, die die erforderlichen ERP-Module bereitstellt. Die ERP Module sollen die Geschäftsprozesse aus der Anforderungsanalyse abdecken. Die Module sollen in einem Gesamtpaket gekauft werden. Für den Erwerb des Gesamtpakets steht ein Budget von zur Verfügung. Weitere sind für die Entwicklung der GUI angesetzt. Rollen: CIO, Developer, Financial Director 4. Öffentliches Ausschreiben An dieser Stelle wird als erstes ein Dokument erstellt, in dem alle Anforderungen niedergeschrieben sind. Auf dieser Grundlage wird eine Ausschreibung veröffentlicht. Ziel dabei ist, dass sich potentielle Anbieter mit uns in Verbindung setzen, um Lösungsvorschläge und Kostenvoranschläge zu unterbreiten. In der Ausschreibung sei erwähnt, dass als Vertragsformen nur FFP und FPI akzeptiert werden, damit das zur Verfügung stehende Budget nicht überschritten wird. Die Ausschreibung sollte sowohl auf unserer Homepage als auch in bekannten Fachmagazinen veröffentlich werden. Für diesen Schritt steht zunächst ein Budget von bereit. Die Ausschreibung läuft einen Monat. Sollten sich in dieser Zeit keine Anbieter gemeldet haben, wird die Ausschreibung einen weiteren Monate verlängert und der CEO sucht zusätzliche Möglichkeiten das Ausschreiben geschickt auf dem Markt zu platzieren. Sollte sich nach den 2 Monaten kein Anbieter gefunden haben, wird ein externer

3 Dienstleister beauftragt unsere Ausschreibung an potenzielle Kandidaten zu vermitteln. Rollen: CEO und Financial Director 5. Evaluierung und Auswahl potentieller Kandidaten Nachdem verschiedene Lösungsvorschläge eingegangen sind, muss intern überlegt werden für welchen Anbieter man sich entscheidet und nach welchen Kriterien dabei vorgegangen werden soll: möglichst viele Geschäftsprozesse sollen erfasst werden (20 % ; da es unser Ziel ist) internationalisierte Software (5% ; nice to have) namenhafte ERP-System-Hersteller priorisiert (10% ; bürgt für Qualität und als bekannter Geschäftspartner) schnelle Lieferung erwünscht (15% ; soll möglichst schnell in Betrieb genommen werden, um die Arbeit zu erleichtern) eine gut dokumentierte API sollte vorhanden sein (20% ; um die GUI-Entwicklung zu vereinfachen) Wartung, Pflege und Support sollte für längere Zeit verfügbar sein (15% ; um Langlebigkeit des Systems zu garantieren) möglichst günstig sowohl bei Anschaffung als auch bei Support/Updates etc. (15% ; um die Kosten niedrig zu halten) Nachdem die Entscheidung für einen Hersteller feststeht, muss den anderen Bewerbern eine Absage erteilt werden. Der Hersteller soll innerhalb von 3 Monaten nach Vertragsschluss das Gesamtpaket liefern. Für die Evaluierung stehen 5 Arbeitstage zur Verfügung. Rollen: IT-Abteilung, CEO, CIO 6. Entwicklung und Kontrolle Da wir die GUI unseres ERP-Systems selbst entwickeln, ist eine enge Zusammenarbeit unserer Entwicklungsabteilung mit dem Hersteller der Anwendungslogik nötig. Deshalb sind wir auf regelmäßige Zwischenberichte angewiesen. Diese sind alle drei Wochen fällig. Die Teile der API, die für die Benutzeroberfläche relevant sind, sollen mit unseren Entwicklerteams so früh wie möglich spezifiziert werden. 7. Überprüfung der Deliveries Nachdem nun das Gesamtpaket geliefert wurde, überprüft die IT-Abteilung die Plattformanforderungen. Der CEO prüft die Funktionalität der Module und ob alle gewünschten Geschäftsprozesse erfasst wurden. Unsere Entwicklungsabteilung befasst sich mit der API und der Qualität der Dokumentation, die sie mit einer geeigneten Metrik sicherstellt. Diese Metrik wird zusammen mit dem Hersteller gefunden. Die Deliveries werden auf einer Abschlusspräsentation vorgestellt und überreicht. Die Präsentation findet in unserem Headquarter zusammen mit unserem CIO, CEO und dem Entwicklungsleiter statt. Die Präsentation wird von dem Hersteller vorbereitet und soll mindestens eine Live-Demonstration der Funktionalität beinhalten. 8. Einweisung der zukünftigen Nutzer Da unsere Entwicklungsabteilung die GUI entwirft und implementiert, kann es zu Verzögerungen zwischen der Abgabe des Herstellers und dem produktiven Einsatz des ERP-

4 Systems kommen. Unsere Entwicklungsabteilung bekommt nach Übergabe weitere zwei Monate Zeit, zum Anpassen und Fertigstellen der GUI. Nachdem die Software nun fertiggestellt ist, muss diese den zukünftigen Nutzern vorgestellt werden. Ihnen muss die Funktionsweise und der Umgang mit dem ERP-System vermittelt werden. Hierzu wird unsere Entwicklungsabteilung beauftragt, da sie sich am intensivsten mit dem System auseinandergesetzt hat. Für fachliche Rückfragen sollte bei der Einweisung ein Ansprechpartner der Herstellers telefonisch erreichbar sein. Für die Einweisung sind je Standort zwei Arbeitstage angesetzt. Rollen: Developer, CIO 9. Abschluss des procurement In diesem Schritt soll der Procurement Process nocheinmal rekapituliert werden, um aus eventuell gemachten Fehlern zu lernen, so dass diese in Zukunft vermieden werden können. ( lessons learned ) Rollen: alle Conduct Procurement Bei der Evaluierung und der Auswahl eines passenden Zulieferers benötigt unsere Firma keine externe Hilfe. Wir nehmen an, die Zeit dafür aufbringen zu können, die Bewerbungsunterlagen eigenständig zu prüfen und zu bewerten. Falls unsere ausgewählten Firmen Rückfragen zu den Dokumenten haben sollten, würden wir ein Telefonat oder verkehr vorziehen, da auf diese Weise Problemstellungen ausreichend dargestellt werden können und Fragen schnell und verständlich beantwortet werden können. Falls eine Firma ein persönliches Treffen verlangen sollte, würden wir dieser Bitte nicht nachkommen wollen, da dies nicht fair für die anderen Mitstreiter wäre. Sollte sich noch ein weiteres Unternehmen, mit welchem vorher noch kein Kontakt bestanden hat, bei uns auf die Ausschreibung melden, würden wir uns deren Angebot anschauen, sofern das Unternehmen unseren Anforderungen entspricht. Administer Procurement Bei allgemeinen vertraglichen Fragen ist der CIO der Ansprechpartner. Er hält die Beziehungen zu unserem Vertragspartner aufrecht. Je nachdem um welche vertragliche Angelegenheit es sich handelt, kommen auch andere Firmenmitglieder als Gesprächspartner in Frage, wie zum Beispiel die IT-Abteilung, der Financial Director oder Andere. Falls Probleme bei der Entwicklung, zum Beispiel einzelner Module, auftreten sollten, muss geprüft werden wie schwerwiegend diese sind und was dies für unsere Firma und die angesetzten Kosten bedeutet. Die Kosten für die Beseitigung schwerwiegender Fehler müssen von unserem Vertragspartner getragen werden. Falls die Software nicht in der vereinbarten Zeit geliefert wird, werden wir den vereinbarten Preis reduzieren. Sollte die Software schneller als vereinbart und in besonders hochwertiger Qualität geliefert werden,

5 wäre unser Unternehmen bereit, einen Bonus zu zahlen. Boni: pro Arbeitstag schneller ,- Strafe: pro Arbeitstag später 5.000,- Fehlende must-have Funktionalität führt zu anteilmäßiger Kürzung des Gesamtbudgets. Falls die need-to-have und must have Funktionalitäten implementiert sind, gibt jede weitere nice-to-have Funktionalität einen Bonus von Sollte die Partnerfirma Änderungen am Vertrag vornehmen wollen, müssen diese diskutiert und mit unserem CEO Abgestimmt werden.. Closing Die Beschaffung ist fertiggestellt, wenn das ERP-System zu min. 95% fehlerfrei funktioniert. der Abnahmetest, der vom Hersteller vorbereitet wird, bestanden ist und alle Kosten beglichen sind. Ein Closing findet auch statt, wenn der Hersteller mit Deliveries um mehr als einen Monat in Verzug ist.