Agile Implementierung

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

• den Beleg digital empfängt 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 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 Agilen-Implementierung

 

1. Projektstart

1.1. Workshop

Im Workshop wird eine kleine Auswahl Ihrer Belege 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:

1. Software-Angebot mit den notwenigen Komponenten für die Einstiegslösung
2. Dienstleistungsangebot zur Einrichtung der Akzeptanzumgebung Akzeptanzumgebung 
   • inklusive Kostenübernahmeerklärung mit Pauschalen und Kontingenten (Erfahrungswerten), die nach Aufwand abgerechnet werden.
3. 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 Angebote werden bei der Agilen-Implementierung abgegeben nachdem Sie mit der Einstiegslösung mindestens 6 bis 12 Monate im Echtbetrieb arbeiten.

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)
• 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:
  1. 1. der vollständig beantwortetet Fragebogen (siehe oben)
     2. ein installierte Systemumgebung für Test- und Echtsystem unserer Lösung gemäß Systemanforderungen: https://content.stratoz.de/books/systemanforderungen-der-stratoz-produkte/page/notwendige-systemumgebung-fur-die-verifierpro-belegverarbeitung
     3. Funktionsfähiges ERP-Testsystem, welches eine 1:1 Kopie des ERP-Echtsystems enthält
     4. Eingerichtete und funktionsbereite Adapter auf der ERP-Seite im Test- und Echtsystem
        
     5. Belege für die fachliche Integration, die zu den noch nicht bearbeiteten Daten im ERP passen

2.2. Einplanung des Projektes bei StratOz

• Planung der Umsetzung durch StratOz, wenn alle notwendigen Informationen, IT- und Personal-Ressourcen 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 Meeting 

1. • 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 gung 

 

3. Projektdurchführung & Projektabschluss

3.1. Installation

1. 1. Grundinstallation der Basiskomponenten Basiskomponenten 
   2. Installation der Schnittstelle
   3. Einrichtung der Lösung
      • inkl. Bereitstellung der im Angebot enthaltenen Change Requests (oder später, je nach Vereinbarung)

3.2. Integrationstest inklusive Schulung des Admins und Installation eines Beispiel-Clients mit dem Admin Admin 

• Technischer Integrationstest mit dem Anwendungsadministrator Anwendungsadministrator 
  
• Unterweisung des Admins

• Installation eines Beispiel-Clients mit dem Admin Admin 

3.3. Einrichtung der Clients durch Ihre IT

3.4. Schulung der Key User

• Integration auf Grundlage der Belege (aktuelle 1:1 Abbildung), die im Rahmen der Beleganalyse als P1 deklariert wurden.
• Akzeptanz der Lösung, wenn Belege, gemäß Konzept und Beleganalyse, verarbeitet werden

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
    
  • 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

• Mit der Abnahme der Akzeptanzumgebung ist das Projekt abgeschlossen
  • Es erfolgt die Abrechnung des Initialprojektes inkl. erbrachter Dienstleistungen und evtl. Mehraufwendungen
  • Die Wartung beginnt

 

4. Echtbetrieb Echtbetrieb 

Nachdem die Akzeptanzumgebung erfolgreich abgenommen 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 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.

 

5. Umsetzung notwendiger Change Requests

Nachdem die Akzeptanzumgebung erfolgreich abgenommen wurde und Sie mindestens 6 bis 12 Monate im Echtbetrieb mit der Einstiegslösung arbeiten, sind wir jetzt bereit durch weitere Change Requests den Automatisierungsgrad zu erhöhen.

5.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….

5.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

5.3. Ihre Auftragserteilung

5.4. Entwicklung (sofern notwendig)  

• Die Entwicklung wird nach der Auftragserteilung eingeplant
• Der Kunde wird nach der Einplanung über den Entwicklungszeitraum informiert

5.5. Bereitstellung des Change Requests in der Akzeptanzumgebung

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

5.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

5.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

Rahmenbedingungen für die 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 Agilen-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 Agilen-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 Agilen-Implementierung

 

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