CRIM-Log Vorlage für IFS Cloud (IDK-10)

Vorlage IDK-10, Version 1.0. Phase: Confirm Prototype (Bedarfe erfasst), Establish Solution (spezifiziert, gebaut, getestet).

So verwenden Sie diese Vorlage

CRIM steht für Configurations, Reports, Integrations und Modifications (Konfigurationen, Berichte, Integrationen und Modifikationen). Das Log ist das eine Register für alles in der Lösung, was nicht reine Standardfunktionalität ist.
Eröffnen Sie das Log im ersten Workshop. In Confirm Prototype erfassen Sie nur Bedarfe. Spezifikation und Build beginnen in Establish Solution, nachdem die Spalte „Entscheidung“ ausgefüllt ist.
Jede Zeile muss die Frage in der Spalte „Geprüfte Standardalternative“ beantworten. Eine Zeile ohne diese Antwort ist nicht entscheidungsreif.
Das Register besteht aus zwei Tabellen mit derselben ID: Abschnitt 5 behandelt Bedarf und Entscheidung, Abschnitt 6 Lieferung und Übergabe. In einer Tabellenkalkulation können beide eine breite Tabelle sein.
Prüfen Sie das Log in jedem wöchentlichen Abstimmungstermin der beiden Projektleitungen und legen Sie jedem Lenkungsausschuss die Zusammenfassung aus Abschnitt 8 vor.
Löschen Sie die mit Beispiel: markierten Zeilen, sobald eigene Zeilen vorhanden sind.

Metadaten der Vorlage
Feld	Wert
Vorlagen-ID	IDK-10
Phase	Confirm Prototype (Bedarfe erfasst), Establish Solution (spezifiziert, gebaut, getestet)
Verantwortlich	Projektleitung des Auftragnehmers, mit dem Technical Solution Manager
Freigabe	Projektleitung des Auftraggebers für Konfigurationen und Berichte, Lenkungsausschuss für Integrationen und Modifikationen
Qualification Gate	Solution Confirmed (Bedarfe erfasst), Solution Established (Objekte geliefert)
Version	1.0

Dokumentenlenkung

Feld	Wert
Projekt	[Projektname]
Verantwortlicher für das Log	[Name, Rolle]
Technical Solution Manager	[Name]
Projektleitung des Auftraggebers	[Name]
Ablageort	[Link]
Prüfrhythmus	Wöchentlicher Abstimmungstermin der Projektleitungen, Zusammenfassung an jeden Lenkungsausschuss

Version	Datum	Autor	Änderung
0.1	[JJJJ-MM-TT]	[Name]	Log eröffnet
[x.y]	[JJJJ-MM-TT]	[Name]	[Änderung]

1. Zweck und die Regel „Standard zuerst“

Das Projekt zielt darauf, jeden Prozessbedarf mit Standardfunktionalität von IFS Cloud zu decken und die Zahl der Modifikationen, Integrationen und Konfigurationen so niedrig zu halten, wie das Unternehmen es vertreten kann. Jedes CRIM-Objekt kostet beim Bau und bei jedem Update erneut. Das Log macht diese Kosten sichtbar, bevor sich jemand festlegt.

Die Regel, auf jede Zeile angewendet:

Beschreiben Sie den fachlichen Bedarf, nicht die gewünschte Lösung.
Zeigen Sie dem Anforderer die Standardfunktionalität im System. Halten Sie fest, was gezeigt wurde.
Halten Sie fest, warum der Standard nicht genügt, in den Worten des Anforderers und mit den Folgen für das Unternehmen.
Erst dann schlagen Sie ein CRIM-Objekt vor, auf der niedrigsten Anpassungsstufe, die den Bedarf deckt.
Lautet die Begründung „so funktioniert das Altsystem“, wird die Zeile abgelehnt oder zurückgegeben.

2. Typdefinitionen

Typ	Umfasst	Erforderliche Spezifikation	Genehmigung vor dem Build
C: Konfiguration (Configuration)	Custom Fields, Custom Events, Page Configurations, Lobbys, Workflows (Business Process Automation), Custom Pages und ähnliche Objekte, die im Web-Client angelegt werden	Spezifikation für Konfiguration und Bericht (Vorlage IDK-12)	Projektleitung des Auftraggebers
R: Bericht (Report)	Quick Reports, Layouts operativer Berichte, Analysemodelle und andere Ausgaben über den Standard hinaus	Spezifikation für Konfiguration und Bericht (Vorlage IDK-12)	Projektleitung des Auftraggebers
I: Integration	Jeder Datenaustausch mit einem anderen System, in beide Richtungen, einschließlich Dateiübertragungen. Zusätzlich im Schnittstellenregister geführt (Vorlage IDK-13)	Funktionale Spezifikation (Vorlage IDK-11)	Genehmigung des Auftraggebers, kaufmännische Vereinbarung, Freigabe durch den Lenkungsausschuss
M: Modifikation (Modification)	Jede Änderung an ausgelieferter Anwendungslogik oder an Seiten, die über eine Konfiguration hinausgeht	Funktionale Spezifikation (Vorlage IDK-11)	Genehmigung des Auftraggebers, kaufmännische Vereinbarung, Freigabe durch den Lenkungsausschuss

3. Anpassungsstufen und Update-Auswirkung

Verwenden Sie diese Stufen in der Spalte „Anpassungsstufe“. Passen Sie die Begriffe an die Formulierungen an, die Sie mit Ihrem Einführungspartner vereinbart haben.

Auf der dreistufigen Skala von ifs-erp.com entspricht Standard der Stufe 1 Core, Konfiguration der Stufe 2 Configured und Modifikation der Stufe 3 Customized. Eine Schnittstellenerweiterung installiert nichts im Mandanten, der Kern bleibt also auf Stufe 1. Das aufrufende System trägt aber die unten gezeigte Pflicht zur erneuten Prüfung.

Stufe	Bedeutung	Auswirkung auf Updates
Standard	Mit Standardfunktionalität und Stammdaten gelöst. Nur zur Dokumentation der Entscheidung geführt.	Keine, über den normalen Regressionstest hinaus
Konfiguration	Im Web-Client angelegt, als Konfiguration gespeichert, als Konfigurationspakete zwischen Umgebungen bewegt	Gering. Nach jedem Release-Update erneut prüfen, vor allem Page Configurations und Objekte, die von bestimmten Feldern abhängen.
Schnittstellenerweiterung (veröffentlichte Schnittstellen)	Externe Logik oder Integration über Projektionen (REST/OData) oder IFS Connect, ohne ausgelieferten Code zu ändern	Mittel. Bei jedem Release-Update die genutzten Projektionen und Entitäten erneut prüfen.
Modifikation	Geänderter oder ergänzter Anwendungscode, über den Build Place gebaut und ausgeliefert	Hoch. Muss bei jedem Release-Update angehoben (Uplift), neu gebaut und neu getestet werden. Begrenzt die Zahl der Updates, die der Kunde durchführen kann.

4. Statuswerte

Status	Bedeutung
Identifiziert	Bedarf in einem Workshop erfasst. Noch keine Entscheidung.
Standard übernommen	Standardalternative akzeptiert. Zeile auf Standard geschlossen.
Abgelehnt	Bedarf nicht anerkannt. Grund festgehalten.
Zur Spezifikation freigegeben	Entscheidung zum Fortfahren getroffen. Die Spezifikation darf beginnen.
Spezifiziert	Spezifikation von der zuständigen Stelle freigegeben (siehe Abschnitt 2).
In Entwicklung	Build gestartet. Bei Integrationen und Modifikationen liegt die kaufmännische Freigabe vor.
Im Test	In die Testumgebung ausgeliefert. Testnachweise werden gesammelt.
Abgenommen	Der Kunde hat das Objekt anhand der Testnachweise abgenommen.
Übergeben	Aktuelle funktionale Spezifikation und Testspezifikation an den Support geliefert.

5. Register Teil A: Bedarf und Entscheidung

ID	Typ	Lösungsbereich und Prozess	Fachlicher Bedarf	Geprüfte Standardalternative (was gezeigt wurde, warum sie nicht genügt)	Entscheidung	Entschieden von, Datum	Anpassungsstufe	Hinweis zur Update-Auswirkung
Beispiel: CRIM-001	C	Einkauf, Bestellung bis Wareneingang	Einkäufer brauchen eine Sicht auf Bestellpositionen, die der Lieferant nicht bestätigt hat	Die Standardübersicht der Bestellpositionen mit gespeicherter Suche wurde gezeigt. Sie funktioniert, aber die Einkäufer wollen Anzahlen und Alter auf ihrer Startseite.	Als Lobby genehmigt	[Projektleitung Auftraggeber], [JJJJ-MM-TT]	Konfiguration	Die Datenquelle der Lobby liest Daten der Bestellpositionen. Elemente nach jedem Release-Update erneut prüfen.
Beispiel: CRIM-002	M	Einkauf, Freigabe von Anforderungen	Der Anforderer wünscht einen eigenen Freigabebildschirm wie im Altsystem	Standard-Autorisierungsregeln mit einer Lobby für Freigebende wurden gezeigt. Sie decken die Befugnisregelung (Delegation of Authority) vollständig ab.	Abgelehnt, Standard übernommen	[Lenkungsausschuss], [JJJJ-MM-TT]	Standard	Keine
Beispiel: CRIM-003	I	Lager, Bestandssicht	Der Webshop muss die verfügbare Menge je Lagerartikel anzeigen	Die Standardprojektion für die Verfügbarkeit von Lagerartikeln wurde geprüft. Ein Standardkonnektor zum Webshop existiert nicht.	Zur Spezifikation freigegeben, nur lesend	[Lenkungsausschuss], [JJJJ-MM-TT]	Schnittstellenerweiterung	Namen von Projektion und Entity Set bei jedem Release-Update erneut prüfen. Siehe Schnittstellenregister [ID].
[ID]	[C/R/I/M]	[Bereich, Prozess]	[Bedarf]	[Alternative und Begründung]	[Entscheidung]	[Name, Datum]	[Standard / Konfiguration / Schnittstellenerweiterung / Modifikation]	[Hinweis]

6. Register Teil B: Lieferung und Übergabe

ID	Link zur Spezifikation und Version	Aufwandsschätzung und kaufmännische Freigabe (I und M)	Entwickler	Status	Testnachweis (Skript, Ergebnis, Tester, Datum)	Abgenommen von, Datum	Stand der Übergabe
Beispiel: CRIM-001	[Link], v1.0	Nicht zutreffend	[Technischer Analyst des Auftraggebers]	Abgenommen	SAT-Skript [ID], bestanden, [Tester], [JJJJ-MM-TT]	[Prozessverantwortlicher], [JJJJ-MM-TT]	Spezifikation und Testfall am [JJJJ-MM-TT] an den Support übergeben
Beispiel: CRIM-003	[Link], v1.2	Schätzung `[im Projekt festlegen]`, Change Request [ID] genehmigt am [JJJJ-MM-TT]	[Entwickler]	Im Test	Integrationstest [ID], offener Fehler [ID]		Nicht begonnen
[ID]	[Link]	[Referenz]	[Name]	[Status]	[Nachweis]	[Name, Datum]	[Stand]

7. Entscheidungsbefugnis und Änderungssteuerung

Situation	Wer bereitet vor	Wer prüft	Wer entscheidet
Neuer Bedarf an Konfiguration oder Bericht	Fachteam: Bedarf, Alternativen mit Vor- und Nachteilen, Vorschlag	Solution Architect, Technical Solution Manager	Projektleitung des Auftraggebers
Neuer Bedarf an Integration oder Modifikation	Fachteam: Bedarf, Alternativen mit Vor- und Nachteilen, Vorschlag	Solution Architects, danach beide Projektleitungen zu den Kosten	Der Sponsor stimmt der Vorlage zu, der Lenkungsausschuss genehmigt oder lehnt ab
Änderung an einer genehmigten Spezifikation	Autor der Spezifikation	Beide Projektleitungen	Dieselbe Stelle wie bei der ursprünglichen Genehmigung, über einen schriftlichen Change Request
Bedarf nach Solution Confirmed gemeldet	Wie oben	Wie oben	Immer über die Änderungssteuerung gegen die Umfangs-Baseline

Halten Sie jede Uneinigkeit schriftlich fest. Schriftlich dargelegte Alternativen können die Frage klären, bevor sie den Lenkungsausschuss erreicht.

8. Zusammenfassung für den Lenkungsausschuss

Typ	Identifiziert	Standard übernommen oder abgelehnt	Genehmigt	Spezifiziert	In Entwicklung oder im Test	Abgenommen	Übergeben
Konfigurationen	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]
Berichte	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]
Integrationen	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]
Modifikationen	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]	[Anzahl]

Entwicklung seit dem letzten Lenkungsausschuss: [Text]. Zeilen, die heute eine Entscheidung des Lenkungsausschusses brauchen: [IDs, jeweils mit einer Entscheidungsvorlage von einer Seite].

9. Prüfung der Update-Auswirkung

Führen Sie diese Prüfung bei der Planung jedes Release-Updates durch, bei Service-Updates in einer leichteren Form. Jede Zeile vom Typ Schnittstellenerweiterung oder Modifikation verlängert die Prüfung und verringert die Zahl der Updates, die der Kunde durchführen kann. Sagen Sie das offen, wenn eine neue Zeile vorgeschlagen wird.

Prüfpunkt	Verantwortlich	Erledigt
Alle Zeilen auf Konfiguration, Schnittstellenerweiterung und Modifikation mit ihrem Hinweis zur Update-Auswirkung aufgelistet	[Rolle]	[ ]
Release Notes gegen die Objekte, Projektionen und Seiten gelesen, von denen jede Zeile abhängt	[Rolle]	[ ]
Regressionstestfälle aus der Spalte Testnachweis im Testplan des Updates eingeplant	[Rolle]	[ ]
Modifikationen: Aufwand für den Uplift geschätzt und vereinbart, bevor der Update-Termin zugesagt wird	[Rolle]	[ ]
Zeilen, die entfallen, weil der Standard den Bedarf inzwischen deckt: zur Stilllegung vorgeschlagen	[Rolle]	[ ]

10. Checkliste zur Übergabe

Der Support kann eine Korrektur ohne Testspezifikation nicht prüfen. Kontrollieren Sie vor der Übergabe jede abgenommene Zeile.

Prüfpunkt	Erledigt
Aktuelle genehmigte Spezifikation am Link in Teil B abgelegt	[ ]
Testspezifikation mit erwarteten Ergebnissen daneben abgelegt	[ ]
Dokumente liegen auf Englisch vor	[ ]
Integrationen stehen zusätzlich im Schnittstellenregister, mit benanntem Verwalter der Zugangsdaten	[ ]
Verantwortlicher nach dem Go-live auf Seiten des Auftraggebers benannt	[ ]
Zeilenstatus erst nach dem Übergabetermin auf „Übergeben“ gesetzt	[ ]

11. Freigabe

Die Freigabe dieses Logs an einem Gate bestätigt, dass die Liste der CRIM-Objekte für die Phase vollständig ist und dass die festgehaltenen Entscheidungen von der benannten Stelle stammen. Sie ist keine Freigabe einzelner Spezifikationen.

Gate	Rolle	Name	Entscheidung	Datum
Solution Confirmed	Projektleitung des Auftraggebers	[Name]	[Freigegeben / Freigegeben mit Anmerkungen / Abgelehnt]	[JJJJ-MM-TT]
Solution Confirmed	Vorsitz des Lenkungsausschusses	[Name]
Solution Established	Projektleitung des Auftraggebers	[Name]
Solution Established	Vorsitz des Lenkungsausschusses	[Name]

Anmerkungen und Bedingungen: [Text]

Unabhängige Vorlage, ausgerichtet an der IFS-Einführungsmethodik. Kein offizielles IFS-Dokument. IFS ist eine eingetragene Marke der IFS AB.

Marktplatz