Agile Implementierung

Diese Umsetzung erfolgt in mehreren Schritten ( ~~Iterationen )~~Iterationen) auf Grundlage einer minimalen Einstiegslösung, die mindestens

den Beleg digital empfängt
den Absender zuordnet
die bereitgestellten Stamm- und Vorgangsdaten aus dem ERP-System für die manuelle Bearbeitung zur Verfügung stellt
Rückfragen mit anderen Mitarbeitern ermöglicht
die Ergebnisse der Bearbeitung an das Zielsystem vollständig oder zur weiteren Bearbeitung übergibt

Die Einstiegslösung kann nach der Installation und minimaler Einrichtung mit den vorhandenen Grundfunktionen bereits eingesetzt oder zunächst, mittels mehrerer Optimierungsschleifen (Change Requests, inklusive Workshops und Umsetzung), auf die Bedürfnisse angepasst werden.

Übersicht

Agile-Implementierung

Typische Ausgangssituation für die iterative Implementierung:Agile-Implementierung

Sie möchten schnell starten und sind agil aufgestellt, oder haben für die analytische Methode https://content.stratoz.de/books/automatisierte-belegverarbeitung/page/konzeptorientierte-implementierung-konzept-implementierung keine Zeit.
Sie stellen gerade auf ein neues ERP-System um und möchten eine Belegverarbeitung mit minimalen Grundfunktionen als Add-On zu Ihrem ERP-System erwerben und sich nicht in weiteren Workshops zum Thema Beleganalyse aufhalten.
Sie möchten Ihr bestehendes ERP-System zunächst um eine minimale Einstiegslösung zur Verarbeitung Ihrer Belege erweitern, mit dieser Lösung mindestens 6 bis 12 Monate arbeiten und dann zu einem späteren Zeitpunkt die notwendigen Optimierungen auf Grundlage von Change Requests durchführen.
Ihr Team hat großes Interesse die Sachbearbeitung zu automatisieren.
Die automatisierte Verarbeitung Ihrer Belege durch "Digitale Sachbearbeiter" ist für Sie ein wichtiger Schritt Ihrer digitalen Transformation.
Ihrem Team ist bewusst, dass es nicht nur um die Digitalisierung, sondern auch um die Transformation (Veränderung für mehr Effektivität und Effizienz) Ihrer Sachbearbeitung geht. Ihr Team steht Veränderungen offen gegenüber.

Ablauf bei der iterativenAgilen-Implementierung

~~Implementierung:~~

1. Projektstart

1.1. Workshop

Workshop
~~Workshops, in denen~~wird eine kleine Auswahl Ihrer Belege ~~betrachtet wird,~~betrachtet, um zu entscheiden, ob die Einstiegslösung vom Grundsatz funktioniert.

Ein "Ja" bedeutet nicht, dass kostenpflichtige Anpassungen ausgeschlossen werden.

1.2.
Erstellung (Richtwert)-Angebote für das Initial-Projekt:

Software-~~Angebot,~~Angebot mit den notwenigen Komponenten für die Einstiegslösung
Dienstleistungsangebot zur Einrichtung der Akzeptanzumgebung
- inklusive Kostenübernahmeerklä~~rung,~~rung mit Pauschalen und Kontingenten (Erfahrungswerten), die nach Aufwand abgerechnet werden.
- ~~Change Request-Angebote, werden im Projektverlauf abgegeben.~~
Dienstleistungsangebot zum Transport der Lösung aus der Akzeptanzumgebung in die Echtumgebung
- inklusive Kostenübernahmeerklärung mit Pauschalen und Kontingenten (Erfahrungswerten), die nach Aufwand abgerechnet werden.

Change Request-Angebote werden bei der Agilen-Implementierung im Verlauf, wenn es zu neuen Erkenntnissen/Anforderungen kommt, abgegeben und nach dem Initialprojekt umgesetzt.

1.3. Ihre Auftragserteilung

2. Projektvorbereitung

2.1. Vorbereitung der Installation und Einrichtung

Sie erhalten von uns einen wichtigen Fragebogen im Excel-Datei-Format (es handelt sich um notwendige Informationen für die Einrichtung unserer Produkte).

~~Projekt-Kick-Off-Meeting - hier stellen sich alle Teilnehmer vor. Es werden die nächsten Schritte abgestimmt.~~
Sie stellen uns alle notwendigen Informationen und Ressourcen zur Verfügung, dabei koordinieren Sie auch Ihre Dienstleister (z.B. proALPHA). Besonders wichtig für die Umsetzung sind:

2.2. Einplanung des Projektes bei StratOz

Planung der Umsetzung durch StratOz, wenn alle notwendigen Informationen, IT- und ~~Personalressourcen~~Personal-Ressourcen ~~bereitstehen~~bereit stehen

Die Projekt-Umsetzung erfolgt in einem festgelegten, kurzen Zeitfenster. Es kommt zur Unterbrechung der Umsetzung und Neu-Einplanung, wenn nicht alle notwendigen Informationen, IT- und Personal-Ressourcen zur Umsetzung bereit stehen.

2.3. Projekt-KickOff-Meeting

- Hier stellen sich alle Teilnehmer vor
- Es werden die nächsten Schritte und Termine abgestimmt.
- Sie stellen uns die verbliebenen notwendigen Informationen und Ressourcen gemäß 2.1. zur Verfügung

3. Projektdurchführung & Projektabschluss

3.1. Installation (Akzeptanzumgebung)

1. Grundinstallation der Basiskomponenten
2. Installation der Schnittstelle
3. Einrichtung der Lösung

3.2. Technischer Integrationstest mit dem Anwendungsadministrator

Technischer Integrationstest mit dem Anwendungsadministrator
~~Fachliche~~Unterweisung ~~Integration~~des Admins

Installation eines Beispiel-Clients mit dem Admin

3.3. Einrichtung der LösungClients mitdurch denIhre IT

3.4. Schulung der Key UsernUser

Integration auf Grundlage ~~einiger~~der ~~Belege.~~kleinen Auswahl Ihrer Belege aus dem Workshop (siehe 1.1.)

3.5. Abnahme der Akzeptanzumgebung

Die Akzeptanzumgebung dient dazu, die Software aus der Sicht der Endbenutzer zu überprüfen und sicherzustellen, dass sie den Angebotsumfang entspricht. Diese Umgebung wird für die Abnahme des Systems durch den Kunden verwendet.

Akzeptanz der Einstiegslösung (nachfolgend die Akzeptanzkriterien), wenn:
- Belege abgeholt werden
- Stamm- und Vorgangsdaten aus dem Zielsystem zur Verfügung stehen
- Belege und Belegdaten dem Anwender zur Bearbeitung zur Verfügung gestellt werden
- ~~Rückfragen zu den Belegen an Kollegen gestellt werden können (gilt nicht für alle Einstiegslösungen)~~
- Belege und Belegdaten an das Zielsystem übergeben werden können

Abnahmeverhindernde Fehler müssen als Ticket gemeldet werden, damit diese Fehler für die Abnahme beseitigt werden.

3.6. Abrechnung des Initialprojektes

~~Einrichtung~~Mit der ~~Clients~~Abnahme ~~durch~~der ~~Ihre~~Akzeptanzumgebung IT

ist das Projekt abgeschlossen

~~Anwenderschulung~~Es ~~durch~~erfolgt die ~~Key User, bei Bedarf mit unserer Unterstützung~~

~~Transport der Lösung aus der Test-(Akzeptanz-)Umgebung in die Echtumgebung~~

Abrechnung des Initialprojektes ~~(der~~inkl. ~~letzten~~erbrachter ~~Dienstleistungen,~~Dienstleistungen und evtl. ~~Mehraufwendungen):~~Mehraufwendungen

~~Das~~

Die ~~Initialprojekt~~Wartung ~~wurde von uns an dieser Stelle vereinbarungsgemäß umgesetzt und abgerechnet.~~beginnt

4. Umsetzung notwendiger Change Requests;Requests

~~Wir~~

Nachdem die Akzeptanzumgebung erfolgreich abgenommen wurde, sind wir jetzt bereit Ihre Besonderheiten zu betrachten und uns Ihrer zukünftigen Lösung durch mehrere Change Requests zu nähern, bis wir Ihren angestrebten Automatisierungsgrad erreicht haben.

4.1. Beschreibung des Change Requests

Der Kunde beschreibt das Change Request mithilfe der von StratOz bereitgestellten Vorlage:

Change Request Vorlage zur Verwendung in Word

1. Beschreibung der Ausgangssituation/Umgebung

Hinweis: Dieser Schritt ist entscheidend, um den Kontext des Change Request zu verstehen. Er stellt sicher, dass alle Beteiligten eine klare Vorstellung von der aktuellen Situation haben, bevor die Änderungen besprochen werden.

Beschreibung…..

2. Beschreibung der gewünschten Änderung

Hinweis: Eine detaillierte Beschreibung dessen was geändert werden soll, ist zentral für jeden Change Request. Sie ermöglicht allen Beteiligten genau zu verstehen, was geändert werden soll.

Beschreibung….

3. Begründung für die Änderung

Hinweis: Dieser Punkt ist wichtig, um die Notwendigkeit und den Wert der Änderung zu verstehen und zu unterstreichen. Eine gut begründete Änderung hat höhere Chancen, von allen Beteiligten akzeptiert zu werden.

Beschreibung….

4. Weitere mögliche Auswirkungen der Änderung

Hinweis: Eine Änderung hat in der Regel immer positive als auch negative Auswirkungen. Die Betrachtung der Auswirkungen ist entscheidend, um zu verstehen, wie sich die Änderung auf das bestehende unternehmerische Gesamtsystem, die Organisation (Aufbau- bzw. Ablauforganisation) die Anwendungslandschaft, die Mitarbeiter, Kunden, Lieferanten und andere Partner oder Projekt auswirken wird. Dies beinhaltet sowohl positive als auch mögliche negative Folgen.

Folgende Auswirkungen….

5. Erkenntnisse aus Workshop

Hinweis: Workshops sind notwendig, wenn es die Komplexität der Anforderung notwendig macht und Details bzw. viele Fall-Beispiele betrachtet werden müssen. Eine übliche Methode ist die StratOz - Dokumentenanalyse, in der unterschiedliche Fälle auf Grundlage von zugehörigen Dokumenten, Screenshots und Vorgängen betrachtet werden.

Workshop-Ergebnisse….

6. Realisierungskonzept / Lösungsskizze zur Änderung

Hinweis: Hier geht es um die Darstellung der notwendigen Änderungen aus der Perspektive des Endanwenders. Diese Beschreibung hilft, die Lösung zu verstehen und die Benutzerfreundlichkeit sowie die praktische Anwendbarkeit der vorgeschlagenen Änderungen zu bewerten.

Realisierungskonzept….

4.2. Erstellung Konzept inkl. Kalkulation und Angebot

Auf Basis des vom Kunden formulierten Change Request wird ein Konzept erstellt und mit dem Kunden abgestimmt.

Das abgestimmte Konzept wird kalkuliert und angeboten

4.3. Ihre Auftragserteilung

4.4. Entwicklung (sofern notwendig)

Die Entwicklung wird nach der Auftragserteilung eingeplant

Der Kunde wird nach der Einplanung über den Entwicklungszeitraum informiert

4.5. Bereitstellung des Change Requests in der Akzeptanzumgebung

Nachdem die Entwicklung abgeschlossen wurde, wird das Change Request in der Akzeptanzumgebung eingerichtet und bereitgestellt

4.6. Abnahme des Change Requests in der Akzeptanzumgebung

Der Kunde erhält, sofern notwendig, eine kurze Einweisung (und wenn vereinbart Dokumentation) zur Handhabung.

Der Kunde testet das Change Request in der Akzeptanzumgebung

4.7. Abrechnung des Change Requests

Mit der Bereitstellung des Change Requests in der Akzeptanzumgebung ist der Auftrag abgeschlossen

Es erfolgt die Abrechnung inkl. erbrachter Dienstleistungen und evtl. Mehraufwendungen

Die Wartung beginnt

5. Echtbetrieb

Nachdem die Akzeptanzumgebung erfolgreich abgenommen und der angestrebte Automatisierungsgrad durch die Umsetzung notwendiger Change Requests erreicht wurde, kann in gemeinsamer Absprache der Transport der Lösung aus der Akzeptanzumgebung in die Echtumgebung eingeplant werden.

5.1 Einplanung Transport der Lösung aus der Akzeptanzumgebung in die Echtumgebung

Diese Arbeiten müssen mit allen Stakeholdern eng abgestimmt werden.

5.2. Transport der Lösung aus der Akzeptanzumgebung in die Echtumgebung

Hier muss die Installation der proALPHA Schnittstelle für das Echtsystem bereits erfolgt sein.

5.3. Abrechnung der Dienstleistungen und evtl. Mehraufwendungen & Echtbetireb

Sie starten den Echtbetrieb und nutzen bei Bedarf das Ticketsystem.

Rahmenbedingungen für die iterative Implementierung:Agile-Implementierung

Auf beiden Seiten sind jeweils Projektkoordinatoren benannt, die für die Koordination der Termine, die Abarbeitung der jeweiligen Aufgaben und Statusmeldungen zuständig sind.
Beide Seiten sorgen dafür, dass die geplanten Aufwände nicht überschritten und Zeiten eingehalten werden. Abweichungen sind unverzüglich anzuzeigen.
Die Softwarekosten sind nach Lieferung und Rechnungsstellung sofort und in vollem Umfang fällig.
Wartungs- bzw. Mietkosten sind nach Installation der Software und Rechnungsstellung sofort und in vollem Umfang fällig.
Dienstleistungen sind nach Erbringung und Rechnungsstellung sofort und in vollem Umfang fällig.
- Pauschalen; ohne detaillierten Leistungsnachweis
- Angebotene Kontingente; bei Bedarf mit Leistungsnachweis, wenn der Zeitraum nicht länger als 2 Monate zurückliegt. Die Projektkoordinatoren haben sich zeitnah und regelmäßig über den aktuellen Kontostand (Kontingent und Verbrauch) auszutauschen.
Change Requests sind nach Erbringung und Rechnungsstellung sofort und in vollem Umfang fällig.
Angebote für Change Requests zeigen einen Richtwert an, der durch neue Erkenntnisse bei der Umsetzung und Implementierung oder durch weitere Wünsche steigen kann.
Weitere ungeplante Change Requests und alle damit verbundenen Tätigkeiten sind kostenpflichtig. Angefallene Tätigkeiten werden auch dann abgerechnet, wenn der Change Request nicht umgesetzt oder abgebrochen wird.
Wir unterscheiden folgende Change Requests:
- Erfolgsnotwendige Änderungen (Change Requests); ein für den Projekterfolg notwendiger Aspekt (Typischer Wortlaut: die Lösung kann so nicht genutzt werden) wurde im Workshop nicht genannt oder wurde vergessen, ist den Vertragsunterlagen nicht zu entnehmen oder wurde nicht angeboten. Diese Situation kann ein Projekt verzögern. Bitte prüfen Sie die Angebotsunterlagen und die Belegbeispiele daher sorgfältig, um Unstimmigkeiten zu vermeiden. Wichtig ist: die erfolgsnotwendige Änderung oder Anpassung ist nicht kostenlos.
- Erfolgserweiternde Änderungen (Change Requests); ein für den Projekterfolg nicht notwendiger Aspekt, sondern eine Erweiterung, die im Workshop nicht genannt oder vergessen wurde, den Vertragsunterlagen nicht zu entnehmen ist oder nicht angeboten wurde. Diese Situation kann auch ein Projekt verzögern. Dies ist der Grund, warum wir diese Anforderungen auf die Zeit nach dem Projekt verschieben (vergl. Einleitung in diesem Kapitel). Bitte prüfen Sie die Angebotsunterlagen und die Belegbeispiele sorgfältig, um Unstimmigkeiten zu vermeiden. Wichtig ist: die erfolgserweiternde Änderung oder Anpassung ist nicht kostenlos.
Bitte verwenden Sie für Ihre Change Requests die StratOz - Change Request-Arbeitsbögen, damit eine zeitnahe Bearbeitung erfolgen kann.
Für unsere Produkte bzw. Lösungen gelten grundsätzlich die nachfolgenden Bedingungen: https://content.stratoz.de/books/rahmenbedingungen-fur-die-erfolgreiche-automatische-verarbeitung-von-dokumenten?shelf=18
Sie sind Betreiber der Lösung und damit für den ordnungsgemäßen Betrieb Ihrer Infrastruktur zuständig. Ihnen ist bewusst, dass Sie geeignete Backup-Strategien wählen und umsetzen, die im Fehlerfall für eine geringe Ausfallzeit sorgen. Sie müssen darüber hinaus vor jeder Änderung an ihrer Lösung (z.B. Überarbeitung der Einrichtung, Patches, Fixes, Change Requests oder Updates) ein Backup erstellen.

Vorteile der iterativen Implementierung:

Keine initiale Vorarbeit: die Mitarbeiter müssen keinen Aufwand im Vorfeld betreiben
Mitarbeiterakzeptanz: die Mitarbeiter können schon etwas sehen bzw. anwenden
Kurzfristige Verfügbarkeit: Ein Produkt (nach Initial-Projekt-Installation) steht sehr schnell zur Verfügung
Flexibilität im Projektverlauf: die Mitarbeiter haben den Freiraum Wünsche zu formulieren
Lösung passt final zu ca. 90 %: weil alle Wünsche erfüllt wurden

Nachteile der iterativen Implementierung:

Risiko, viele mögliche ungeplante Change Requests im Projektverlauf: Change Request werden wahllos formuliert, schnell umgesetzt und später evtl. verworfen.
Risiko, Klarheit und Struktur fehlen: Das große Ziel kann fehlen, oder sich unbemerkt verändern.
Risiko, Projektkosten steigen: großer Koordinations- und Abstimmungsaufwand.
Risiko, Start des Echtbetriebs verzögert sich: Neue Ideen und Wünsche werden plötzlich als KO-Kriterien formuliert
Risiko, Fehleinschätzung durch die Mitarbeiter: Mitarbeiter können sich die zukünftige Lösung noch nicht im Tagesablauf vorstellen
Mitarbeiterakzeptanz schwindet mit langen Umsetzungszeiten: wenn die Change Requests beliebig zugelassen werden, werden sich Diskussionen entwickeln und dadurch Freigaben verzögern

Notwendige Projektunterlagen der iterativen Implementierung:

Angebotsunterlagen für die Initial-Installation (Software-Angebot, Dienstleistungsangebot)
Viele Change Request - Beschreibungen und zugehörige Angebote für die Iterationen