Doel van de proefdraai
De proefdraai moet bewijzen dat de nieuwe app tijd wint zonder de oude werking te breken. De veiligste start is een afgebakende test: een dag, een werknemer, een post of een beperkt type werk.
Gebruik het Legacy compatibiliteitscentrum om oude rekken read-only naast nieuwe dragers te zetten. Koppelen en overnemen schrijven alleen in de nieuwe database; het oude programma blijft onaangeraakt.
| Keuze | Waarom veilig? | Wat controleren? |
|---|---|---|
| Een werknemer | Je ziet snel of scannen en schermflow werkbaar zijn. | Badgebeleid, aantal scans, foutgevoeligheid. |
| Een werkpost | De rest van de fabriek kan blijven werken zoals vandaag. | Route naar juiste scherm, dragerkeuze, aantallen. |
| Een dag | Je krijgt echte productiegegevens zonder lange dubbele periode. | Overzicht, historiek, mails, rekbelasting. |
Afgesproken testrollen
| Rol | Doet wel | Doet niet | Waarom |
|---|---|---|---|
| Onthaal | Nieuwe kaart maken, klant/opdracht/onderdeel/aantal invullen, route kiezen, ontvangst noteren. | Geen oppervlakte of gewicht berekenen. | De kaart moet snel en foutarm starten zonder de oude berekenwijze te veranderen. |
| Verantwoordelijke | Oppervlakte, gewicht, meetbron, foto's/tekening en controle aanvullen. | Niet verplicht de onthaalstap opnieuw doen. | De vertrouwde berekening blijft bij de persoon die ze vandaag al bewaakt. |
| Werkvloer | Badge, werkpost en kaart scannen; acties boeken; dragers en aantallen juist zetten. | Geen administratieve correcties doen zonder reden. | De proefdraai moet tonen of de schermflow op de vloer natuurlijk werkt. |
| Compatibiliteit | Oude rekken vergelijken met nieuwe dragers, koppelen of gecontroleerd overnemen. | Niet terugschrijven naar de oude database. | De oude werking blijft veilig terwijl nieuwe dragers groeien. |
Belangrijke regel: oude data blijft bron van waarheid tot de test goedgekeurd is
Tijdens de proefperiode mag de nieuwe app niet zomaar oude records overschrijven. We behandelen oude gegevens eerst als read-only legacy data. De nieuwe app mag die tonen in overzichten en autocomplete, maar definitief mergen gebeurt pas na controle.
Datastand in Productieoverzicht
| Stand | Wat ziet de CEO? | Wanneer gebruiken? |
|---|---|---|
| Live: nieuwe + oude app | Nieuwe meereiskaarten en oude hangwaar-rekken naast elkaar. Oude rekken krijgen het label Oud programma en blijven read-only. | Standaard voor opvolging tijdens de overgang. |
| Legacy compatibiliteit | Oude rekken worden gematcht met nieuwe dragers. Een koppeling bewaart alleen een brugrecord in de nieuwe app. | Voor gecontroleerde overgang per rek. |
| Test: alleen nieuwe app | Alleen records die in de nieuwe app gemaakt zijn. | Voor een proef met een werknemer of een werkpost zonder ruis van oude data. |
Oude rekken krijgen geen verzonnen meereiskaart en geen verplichte badge. Als de oude database alleen een naam van de ingever heeft, tonen we die naam. Ontbrekende velden worden leeg of met een streepje getoond zodat de pagina bruikbaar blijft.
Compatibiliteit met de oude database
| Oude data | Nieuwe weergave | Risico | Aanpak |
|---|---|---|---|
| Klanten | Autocomplete, mailadres, overzicht per klant. | Dubbele klantnamen of ontbrekende e-mail. | Legacy klanten read-only tonen en later koppeltabel maken. |
| Werknemers | Badges en actieve/inactieve lijst. | Oude werknemers komen terug in lijsten. | Actief-vlag gebruiken, maar geschiedenis behouden. |
| Rekken | Dragers in nieuw overzicht en legacy compatibiliteitscentrum. | Oude reknummering en nieuwe productiedragers botsen. | Brugtabel gebruiken: oud rek versus nieuw rek, met expliciete koppeling. |
| Stukken/kaarten | Meereiskaarten en open werk. | Een oude kaart kan geen volledige nieuwe eventgeschiedenis hebben. | Legacy status tonen naast nieuwe events, niet doen alsof alles nieuw is. |
| Afgewerkte stukken | Klantoverzicht en historie. | Nieuwe app toont anders te weinig historiek. | Read-only legacy overzicht toevoegen aan Historie/Productieoverzicht. |
Voorstel technische overgang
- Stap 1 - lezen: nieuwe app krijgt een legacy-read service die oude klanten, oude kaarten en oude rekken kan opzoeken zonder te schrijven.
- Stap 2 - tonen: Productieoverzicht en Historie tonen nieuwe data en legacy data apart gelabeld.
- Stap 3 - koppelen: admin krijgt een scherm om oude klant/rek/kaart te koppelen aan nieuw record.
- Stap 4 - proef afronden: alleen goedgekeurde koppelingen worden gemerged.
- Stap 5 - oude app uitfaseren: pas wanneer zoeken, rekken en klanten in de nieuwe app volledig genoeg zijn.
Go/no-go checklist voor overschakelen
- Minstens een volledige testdag met echte kaarten is terug te vinden in Historie.
- Onthaal kan een kaart maken zonder hulp van de verantwoordelijke.
- De verantwoordelijke kan gewicht en oppervlakte apart aanvullen zonder de kaart te breken.
- Productie kan badge, werkpost en kaart scannen op de toestellen die echt gebruikt worden.
- Dragers, open aantallen en zware rekken zijn correct zichtbaar in Productieoverzicht.
- De live wiki toont de actuele schermen en knoppen, zodat nieuwe uitleg niet los staat van de app.
- Er is beslist welke oude data read-only blijft en welke data gekoppeld of gemigreerd wordt.
Wat we niet moeten doen
- Niet automatisch alle oude rekken als nieuwe open productiedragers behandelen.
- Niet oude werknemers definitief wissen omdat ze niet actief zijn.
- Niet oude klanten overschrijven op basis van alleen naam.
- Niet tijdens een proefperiode oude en nieuwe aantallen stilletjes optellen zonder bronlabel.
Wat de proefdraai moet opleveren
Na een goede testdag weten we: werkt scannen voor echte werknemers, zijn de schermen logisch, klopt het overzicht voor de CEO, worden aantallen op dragers juist bijgehouden, en welke oude data moet eerst zichtbaar worden voor een veilige overstap.