Versionswechsel der Klassifikation
eCl@ss veröffentlicht etwa zweimal im Jahr eine neue Version. ETIM bewegt sich etwa jährlich. Ihre Kunden wechseln nach ihrem eigenen Zeitplan, der keiner von beiden ist. Dieser Artikel zeigt, wie Sie aktuell bleiben, ohne alle sechs Monate neu zu bauen.
Was eine neue Version tatsächlich ändert
| Änderung | Wirkung auf Sie | Wie oft |
|---|---|---|
| Neue Klassen | Produkte, die Sie nicht präzise klassifizieren konnten, können es jetzt | Jede Version |
| Abgekündigte Klassen | Ihre zugewiesene Klasse existiert in der neuen Version nicht mehr | Jede Version, eine Handvoll |
| Geteilte Klassen | Eine alte Klasse wird zwei oder drei; Ihre Produkte müssen verteilt werden | Gelegentlich, und das ist die schmerzhafte |
| Zusammengelegte Klassen | Zwei werden eine; mechanisch | Gelegentlich |
| Neue Merkmale auf bestehenden Klassen | Neue Lücken in Ihrer Vollständigkeit, womöglich Pflicht | Jede Version |
| Geänderte Wertelisten | Ihr Werte-Mapping zeigt auf einen Code, der umgezogen ist | Jede Version |
| Geänderte Einheiten | Ein Merkmal erwartet jetzt eine andere Einheit | Selten, und am häufigsten übersehen |
Die letzte Zeile ist die leise. Eine Einheitenänderung validiert sauber, wenn Sie nie eine Umrechnung deklariert haben — die Zahl geht unverändert hinaus und bedeutet etwas anderes. Prüfen Sie Einheitenänderungen ausdrücklich gegen Ihr Mapping.
Zwei Versionen gleichzeitig fahren
Das ist normal, kein Behelf. Ein Kunde ist auf eCl@ss 12.0 und bleibt es noch zwei Jahre; ein anderer ist auf 14.0 umgestiegen. Beide brauchen eine korrekte Datei.
Halten Sie beide Versionen geladen, und lassen Sie jedes
Exportprofil die Version
benennen, gegen die es exportiert. Produkte tragen ihre Klasse je Version —
ein Artikel kann in der einen 23-11-01-01 sein und in der anderen etwas
anderes.
Die Kosten: Die Lücken verdoppeln sich. Ein in 12.0 vollständiges Produkt kann in 14.0 unvollständig sein, weil 14.0 ein Pflichtmerkmal ergänzt hat. Deshalb wird der Vollständigkeitsreport je Version gelesen — und deshalb laden Sie keine Version, nach der niemand gefragt hat.
Die Migration, Schritt für Schritt
- Die neue Version laden, neben der aktuellen. Noch für keinen Export aktivieren.
- Den Differenzreport fahren. Er sagt Ihnen, welche Ihrer zugewiesenen Klassen abgekündigt, geteilt, zusammengelegt oder unverändert sind. Die meisten sind unverändert; das ist die gute Nachricht.
- Unveränderte Klassen behandeln. Nichts zu tun — aber neu validieren: Merkmale und Wertelisten können sich unter einer Klasse bewegt haben, die ihren Code behalten hat.
- Zusammengelegte und umbenannte Klassen behandeln. Mechanisch. Auf Familienebene neu zuweisen, die Produkte folgen.
- Geteilte Klassen behandeln. Das ist die Arbeit. Eine alte Klasse ist jetzt zwei, und die Entscheidung, welches Ihrer Produkte wohin gehört, braucht meist ein Attribut, das sie unterscheidet. Haben Sie es: filtern und massenbearbeiten. Haben Sie es nicht, legen Sie erst ein Attribut an und füllen es, bevor Sie migrieren können — planen Sie das ein; es ist der Teil, der aus zwei Tagen zwei Wochen macht.
- Abgekündigte Klassen ohne Nachfolger behandeln. Selten und unbequem. Die nächstliegende überlebende Klasse finden und die Entscheidung festhalten; in einem Jahr fragt jemand danach.
- Merkmale und Werte neu zuordnen, wo die neue Version sie geändert hat. Besondere Aufmerksamkeit den Einheiten.
- Den ganzen Katalog gegen die neue Version validieren und die neuen Pflichtmerkmal-Lücken nach Attribut abarbeiten, wie in Produkte klassifizieren.
- Eine Testdatei mit 20 Artikeln in der neuen Version exportieren und vom Kunden das Laden bestätigen lassen.
- Das Exportprofil umstellen auf die neue Version. Die alte geladen lassen, für die Kunden, die noch auf ihr sind.
Neu validieren ist nicht optional
Der häufigste Weg, auf dem eine Klassifikation leise bricht, ist ein Versionswechsel, bei dem die Klassen neu zugeordnet und sonst nichts geprüft wurde. Ein Klassencode kann eine Version überleben, während seine Merkmalsliste, seine Pflicht-Flags und seine Wertelisten sich alle ändern.
Nach jeder Migration, und vor jeder ersten Lieferung in einer neuen Version:
- Vollvalidierung gegen die neue Version, katalogweit.
- Manuelles Lesen von drei Produkten je Hauptfamilie — Klasse, Merkmale, Werte, Einheiten —, wie das System eines Kunden sie sähe.
- Vergleich der exportierten Artikelanzahl mit dem Export der vorherigen Version. Ein großer Einbruch heißt: Artikel werden an einem neuen Pflichtmerkmal ausgeschlossen.
Damit es kein Projekt wird
Zweimal im Jahr, wenn eine Version veröffentlicht wird:
- Lesen Sie die Release Notes für die Klassen, die Sie verwenden — nicht die ganze Version. Das ist eine kurze Liste.
- Notieren Sie alles, was Sie betrifft, in einem Ticket, auch wenn Sie nicht migrieren.
- Fragen Sie Ihre drei größten Katalogkunden, auf welcher Version sie sind und wann sie wechseln wollen. Diese eine Frage, jährlich gestellt, nimmt dem ganzen Bereich die meisten Überraschungen.