01 Projektsteuerung

• Projekt Management Plan
• Technische Implementierungsstruktur

Projekt Management Plan

Projektübersicht

Projektziele/ Zielsetzungen

• Stichpunkartige Liste der übergeorneten Projektziele
  • Geplanter Zeithorizont
  • Geplantes Umsetzungsbudget (für erstes jahr/ geplanten module/ Gesamt?)
    • (wir arbeiten mit mit Agilen-Projektmanamgent Methoden und können laufende Kostenabschätzungen geben, arbeiten aber nicht zu Festpreisen)
  • Replizierung existierender Prozesse order erarbeitung neuer Prozesse

Hintergrund/ Motivation

• Stichpunktartige Liste der Projekthintergründe (Altsystem(e), Ineffizienz, mangelnde Transparenz, Kosten etc.
  • Aktuelle Systemlandschaft die ersetzt (oder ergänzt?) werden soll
  • Art des Unternehmens (Produktion vs Service vs Mischbetrieb etc.)
  • Verfügbarkeit von Prozessabläufen die repliziert/ erarbeitet werden sollen

Kritische System-Mindestanforderungen/ Ausschlusskriterien

Falls es kritische System-Mindestanforderungen/ Ausschlusskriterien geben sollte. Sollten diese zu allererst zumindest via einer Machbarkeitsstudie validiert werden, bevor mit der Arbeit der "Standard-Implementierung" begonnen wird.

• Auflistung möglicher kritischer Systemanforderungen ohne die die Implementierung aller anderen Umfänge keinen Sinn ergibt. zB. 
  • Spezielle Zertifizierungsanforderungen 
  • Integration in externes system (w.z.B. Kundenbestellsystem/ Zugang zu kritischen Datenbaken etc.)
  • Daten/ Material-Rückverfolgbarkeit

Projektstrategie/ Ansatz

• Stichpunktartige Definition der geplanten Projektstrategie/ Prioriäten z.B.
  • Priorisierung von Funktionen über 100% Abschluss von Umfängen (viele MVP Funktionen vs weniger Funktionen aber voll ausgereift)
    
  • Restriktive Nutzerrechte vs Mehr Berechtigungen/Vertrauen
  • Anzeige aller/ vieler Optionen vs Anzeige notwendiger Optionen/ Aufgeräumt 
  • Standardprozesse nutzen vs. individuelle Customization entwickeln
  • Schnelle Einführung vs langfristige Detailoptimierung
  • Anpassungen in der UI vs. reine Entwicklung über den Code 
  • Kundenselbstständigkeit (enablen von eigenen Änderungen im System) vs. volle Betreuung durch Phamos
  • Einteilung des Projekts in Phasen

Geplante Module

Modul	Beispielumfänge	Pflichtmodule	Soll Umgesetzt werden	Kommentar
Buchhaltung	Konten, Buchungen, Finanzberichte, Steuern	x
Benutzer	Benutzerverwaltung, Rollen, Berechtigungen	x
Verkauf	Kunden, Rechnungenen, zahlungsbedingungen etc.	(x)
Einkauf	Lieferanten, Bestellungen, Einkaufsrechnungen
Lager	Artikel, Lagerplätze, Bestandsverwaltung	(x)
Fertigung	Arbeitsauftrag, Artikel, Stücklisten
Qualität	Nichtkonformität, Qualitätsprüfungen etc.
Vertrieb	Angebote, zahlungsbedingungen etc.
Projekte	Projektplanung, Aufgaben, Zeitprotokollierung
Support	Kundensupport, Wartungsbesuche, Wartungsplan
Personalwesen	Abteilungen, Mitarbeiter, Arbeitszeiten etc
Vermögenswerte	Anlagen, Wartung etc.
Webseite	CMS, Website-Inhalte, Blog, E-Commerce
Lohn und Gehaltsabrechnung	Gehaltsabrechnung, Abzüge, Vergütungsberichte
LMS	Schulungen, Quizzes
CRM	Lead, Potenzielle Kunden

Die ERPNext Module sind Gruppierungen von Funktionen die teils in mehreren Modulen auftauchen. Es können Funktionen auch unabhängig von dem Modul implementiert werden.

Meilensteine

Meilenstein	Kurzbeschreibung	Zieltermin	Kommentar

Kommunikation

Hauptkontakte

Funktion	Kundenkontakt	Kontakt Details	Phamos Kontact	Kontact Details
Projektmanager
Projektsponsor/ Finanzen
Eskalation
IT/ Technisch

Meetings

• Regeltermine
  • Häufigkeit: Wöchentlich
  • Wann: 
  • Teilnehmer: 
• Meilenstein-Review
  
  • Häufigkeit: Wöchentlich
  • Wann: 
  • Teilnehmer: 
    

Projektsprache

Die allgemeine Projektsprache soll Deutsch sein. Dies gilt sowohl für die Termine, der Bookstack Dokumentation als auch für die Kundenkommunikation via Gitlab.

Die Kommunikation hin zu den Phamos Entwicklern in Gitlab "Child items" erfolgt in Englisch. 

Projekt-Kommunikations-Tools

Tool	Link	Kunden-User	Kommentar
GitLab			ERP Arbeitsabwicklungs-kommunikation
Frappe Cloud			ERP Entwicklungs- und Testumgebung
GitHub			ERP code/ Custom App Management
Bookstack			Prozess-Entwicklung und Dokumentation
Jitsi meet			Online Meetings

Rollen und Zuständigkeiten (RACI)

https://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Bereich	Kunde	Phamos
Anforderungsdefition	A/R	C
Lösungsausarbeitung	C	A/R
Luafendes Testing der Lösungsansätze	I	A/R
Implementierung in Enticklungsumgebung (Frappe.Cloud)	I	A/R
Abnahme-Testing in Entwicklungsumgebung	A/R	I
Implementierung in Kunden Produktiv-Test-System	A/R
Abnahme-Testing in in Kunden Produktiv-Test-System	A/R
Implementierung in Kunden Produktivumgebung	A/R	C
Abnahme-Testing in Produktivumgebung	A/R	I
Dokumentation	C	A/R
Projektplanung (Zeit)	C	AR
Projektplanung (Kosten)	C	AR
Freigabe Projektplanung	AR	C
Projekt Reporting	I	AR

• R - Responsible (Zuständig) - zuständig für die eigentliche Durchführung (Durchführungsverantwortung). Diese Person oder Personen, die die Initiative für die Durchführung (auch durch Andere) gibt bzw. geben. Sie kann die Aktivität auch selbst durchführen. Wird auch als Verantwortung im disziplinarischen Sinne interpretiert.

• A - Accountable (Verantwortlicher)- rechenschaftspflichtig (Kosten- bzw. Gesamtverantwortung), verantwortlich im Sinne von „genehmigen“, „billigen“ oder „unterschreiben“. Die Person, die im rechtlichen oder kaufmännischen Sinne die Verantwortung trägt. Wird auch als Verantwortung aus Kostenstellensicht interpretiert. Es kann nur eine Person Accountable sein und genau eine Person muss auch definiert werden. Ohne solch eine Person ist die Aufgabe nicht abschließend definiert.
  

• I -Inform (zu Informieren) - Eine Person oder Personen die berechtigt sind Informationen einzuholen bzw. informatiert zu werden.
  

• C - Consult (Beraten) - Eine Person, die vielleicht nicht direkt an der Umsetzung beteiligt ist, aber relevante Informationen für die Umsetzung hat und deshalb befragt werden soll oder muss.

Technische Implementierungsstruktur