Implementierungsrichtlinien 

Die dargestellten Richtlinien gelten als Basis für Implementierungsprojekte und sind somit Bestandteil der Beauftragung.

    

1. Allgemeine Voraussetzungen und Abgrenzung

1.1 Projektinhalte und -umsetzung

Im Zuge des gemeinsamen Analyse-Workshops werden, auf Basis der Gap-Analyse, Projekt-Ziele, Nicht-Ziele sowie Akzeptanzkriterien definiert. Diese grenzen den Inhalt des Projekts klar ab.

Kommen im Laufe der Umsetzung Zusatzanforderungen auf, müssen diese entsprechend bewertet werden. Nach Evaluierung der Auswirkungen auf Projekt-Inhalt, -Zeitraum und -Budget erfolgt die Entscheidung zur Umsetzung.

Bei den im Requirement-Dokument abgebildeten Lösungsvorschlägen handelt es sich um Ansätze, die auf dem Wissenstand der Vorprojektphase basieren. Sollte sich im Zuge der Realisierung herausstellen, dass die Komplexität einzelner Anforderungen wesentlich höher ist als erwartet, verpflichtet sich SUPPLiot den Auftraggeber über potenzielle Auswirkungen hinsichtlich Kosten- und Terminplanung ehestmöglich zu informieren.

1.2 Admin-User

Neben den vom Auftraggeber nominierten Usern wird ein zusätzlicher User für Admin-Tätigkeiten eingerichtet. Dies soll sicherstellen, dass im Zuge von Konfigurationsarbeiten keine Rollenkonflikte im System auftreten.

1.3 Übersetzungen

Im Falle, dass das System in mehreren Sprachen zur Verfügung stehen soll, wird (sofern nicht explizit im Projektumfang spezifiziert) auf die Standard-Übersetzungsfunktionalität von Odoo zurückgegriffen.

1.4 Datenlieferungen und -importe

Bei der Abgrenzung der Projektinhalts sind die Anzahl der notwendigen Datenimports zu definieren, um diese entsprechend in der Angebotskalkulation zu berücksichtigen.

Die Bereinigung von Import-Daten ist, sofern nicht explizit im Angebot festgehalten, nicht Bestandteil des Projektumfangs. Bei mehreren verschiedenen Datenquellen ist unbedingt ein eindeutiger Primärschlüssel notwendig.

Wenn in den Anforderungen nicht explizit anders spezifiziert, dürfen maximal 20.000 Datensätze pro Datenart geliefert werden. Je Datenart (Kunden, Produkte etc.) ist ein File zu übermitteln. 

1.5 Inhaltliche Korrekturen

Für das Einbetten von vordefinierten Texten oder Dokumenten-Layouts sind maximal zwei Korrekturschleifen vorgesehen. Die Korrektur von Textvorlagen ist, sofern nicht explizit im Angebot festgehalten, nicht Bestandteil des Projektumfangs.

1.6 Schulungen und Schulungsunterlagen

Schulungen können folgende Materialien/Aktivitäten beinhalten:

  • Dokumentation der Odoo-Standardfunktionalität


  • Video-/Screenshot-Dokumentation


  • User-Schulung 

Die Odoo-Standardfunktionalität ist auf www.odoo.com dokumentiert. Jene Schulungsunterlagen sind nur in englischer Sprache verfügbar. Einzig Individualentwicklungen können per Video auch in deutscher Sprache dokumentiert werden. Die geschätzte Schulungsdauer basiert auf Erfahrungswerten vergangener Projekte. Der tatsächlich notwendig Schulungsaufwand variiert abhängig vom Erfahrungsgrad und der Affinität der User. Dieser wird im Laufe des Projekts bedarfsorientiert angepasst..

1.7 Support

Tätigkeiten nach Abschluss des Implementierungsprojekts fallen in den Bereich des Supports. Da Support-Tätigkeiten nicht im Rahmen des beauftragten Projekts beinhaltet sind, werden diese nach Aufwand verrechnet. Erfahrungsgemäß lassen sich Support-Aufwände, durch Einsatz eines Key-Users (siehe unten), stark reduzieren.  Gebuchte Support-Pakete beinhalten lediglich die im Paket angebotenen Aufwände (zzgl. 20 % Toleranz). Überschreiten die angefallenen Aufwände den Toleranzwert, werden etwaige Mehraufwände nachverrechnet.

Gemäß der auf www.suppliot.eu/support definierten Richtlinien erfolgen Support-Tätigkeiten nur an österreichischen Werktagen. Montag bis Donnerstag zwischen 09.00 und 17.00 Uhr (CET) und freitags zwischen 09.00 und 15.00 Uhr (CET). Wenn nicht explizit anders vereinbart, erfolgen Support-Tätigkeiten nur auf Deutsch.

2. Mitwirkungspflichten des Auftraggebers

2.1 Key User

Auf Auftraggeberseite ist die Rolle des „Key-User“ zu besetzen.

Die Rolle des „Key-User“ beinhaltet:

  • das Fungieren als zentraler fachlicher Ansprechpartner auf Auftraggeberseite,


  • die Durchführung des First-Level-Supports auf Auftraggeberseite während des Projekts und darüber hinaus und


  • die Durchführung der funktionalen Tests und der Abnahmetests.

2.2 Abnahmetests

Voraussetzung zur Durchführung von Abnahmetests ist die Erstellung eines Testfallkatalogs. Ziel des Testfallkatalogs ist es, Testfälle für alle umzusetzenden Anforderungen zu definieren, um die Funktionalität der umgesetzten Entwicklungen zu überprüfen. Der für die Abnahmetests gültiger Testfallkatalog, muss vor Beginn der Tests von Auftraggeberseite abgenommen werden.

Im Zuge der Abnahmetest-Phase hat der Auftraggeber Gelegenheit zu überprüfen, ob die für das Projekt definierten Anforderungen gemäß den vereinbarten Funktionalitäten umgesetzt wurden. Die Ergebnisse der Abnahmetests dienen als Basis für etwaige Fehlerkorrekturen. Erfolgreich durchgeführte Abnahmetests bedingen eine Abnahme der Projektergebnisse durch den Auftraggeber.