Een koppeling moet werk uit handen nemen. Je wilt informatie op één plek aanpassen en erop kunnen rekenen dat die op de juiste andere plek terechtkomt. Toch vraagt dat vooraf om een paar duidelijke afspraken.
Waar voer je een wijziging in? Welk systeem moet die overnemen? En wat gebeurt er als iemand de informatie aan beide kanten aanpast?
Dat zijn de vragen die ik eerst zou uitwerken voordat we een koppeling bouwen. Anders kun je straks gegevens uitwisselen, terwijl je medewerkers nog steeds moeten uitzoeken welke versie klopt.
Begin bij het werk dat makkelijker moet
Schrijf eerst op welke handeling je nu dubbel uitvoert. Welke informatie neem je over, wie doet dat en wanneer is de volgende medewerker ermee geholpen?
Een lijst met alle beschikbare gegevens is daarvoor nog geen werkproces. Je wilt weten wat er na een wijziging moet gebeuren en welke informatie daarvoor werkelijk nodig is.
Bij maatwerksoftware gebruiken we zo'n concrete handeling als vertrekpunt. Daarmee kun je beoordelen wat de koppeling moet oplossen en welke onderdelen je voorlopig kunt laten zoals ze zijn.
Bepaal per gegeven waar je het aanpast
Het ene systeem hoeft niet voor alle informatie leidend te zijn. Je kunt bijvoorbeeld een omschrijving in de ene omgeving beheren, terwijl een andere omgeving bepaalt welke status bij het werk hoort.
Leg dat per onderdeel vast. Een medewerker moet kunnen zien waar een wijziging thuishoort. Het andere systeem neemt die informatie vervolgens volgens de gemaakte afspraak over.
Dat vraagt ook om een keuze wanneer beide kanten iets kunnen aanpassen. Mag een automatische update een handmatige correctie vervangen? Of moet die correctie blijven staan totdat iemand de bescherming bewust opheft?
Ik zou die keuze niet laten afhangen van welk systeem toevallig het laatst een bericht verstuurt. Spreek af welke bron voorrang krijgt en maak een afwijking zichtbaar. Dan weet je ook waar je een fout moet herstellen.
Maak verschil tussen ontbrekende en verwijderde informatie
Stel dat een systeem bij een update geen omschrijving meestuurt. Betekent dat dat de omschrijving weg moet? Of is dat onderdeel bij deze update gewoon niet meegestuurd?
Dat verschil moet de koppeling kunnen verwerken. Anders kan een onvolledige update informatie wissen die nog gewoon bruikbaar is.
Spreek daarom apart af hoe een echte verwijdering wordt doorgegeven. Ontbrekende informatie, een bewust leeggemaakt veld en een verwijderde vermelding kunnen verschillende situaties zijn. Vooraf vastleggen wat ieder geval betekent, maakt de verwerking beter te controleren.
Houd actuele gegevens en eerdere vastleggingen uit elkaar
Informatie die je vandaag wijzigt, hoeft niet overal met terugwerkende kracht te veranderen.
Een eerder verstuurd document kan bijvoorbeeld de gegevens moeten bewaren die op dat moment golden. Het actuele overzicht mag ondertussen wel worden bijgewerkt.
Neem dat mee bij het ontwerp. Welke informatie moet steeds actueel blijven en wat hoort bij een afgeronde handeling? Als daar een correctie nodig is, wil je die bewust kunnen uitvoeren en kunnen terugvinden wat er is aangepast.
Zo voorkom je dat een gewone wijziging ongemerkt ook je eerdere vastleggingen verandert.
Laat zien wat werkelijk is verwerkt
Een instelling die aanstaat, vertelt je nog niet of de laatste wijziging goed is overgenomen. Ook een geslaagde verbinding bewijst niet dat alle bedoelde informatie is verwerkt.
In het beheer wil je daarom kunnen zien wanneer iets voor het laatst goed ging en welk onderdeel nog aandacht nodig heeft. Is informatie niet beschikbaar, dan hoort dat ook duidelijk te zijn. Een onbekende status moet geen geruststellend vinkje worden.
Bespreek bovendien hoe snel een wijziging normaal wordt overgenomen. Gebeurt dat direct na een handeling of op vaste momenten? Dan weet je wanneer wachten normaal is en wanneer iemand moet kijken.
Bij automatisering hoort die uitleg bij de inrichting. Je moet zelf kunnen beoordelen of het werk doorgaat zoals afgesproken.
Spreek af wie een afwijking oppakt
Niet iedereen hoeft instellingen te kunnen aanpassen of een verwerking opnieuw te starten. Voor iemand die alleen het dagelijkse werk uitvoert, kan een duidelijke melding voldoende zijn.
Bepaal wie de oorzaak onderzoekt en wie een correctie mag uitvoeren. Controleer bij een onduidelijke uitkomst eerst wat er al aan de andere kant is gebeurd. Daarna kun je bepalen welke vervolgstap nodig is.
Die afspraken helpen ook bij de overdracht. Als de vaste medewerker afwezig is, moet een collega kunnen zien wat er speelt en bij wie die terechtkan.
Werk eerst één gegevensstroom uit
Je hoeft niet direct iedere mogelijke uitwisseling mee te nemen. Kies één terugkerende handeling en beschrijf waar de informatie begint, waar die terechtkomt en wat je daar wilt kunnen controleren.
Controleer vóór de bouw ook of de bestaande systemen de benodigde toegang en functies beschikbaar stellen. Dat een gegeven op een scherm staat, betekent niet automatisch dat een koppeling het kan uitlezen of aanpassen.
Met zo'n afbakening kun je gericht beginnen en later uitbreiden. Wil je weten wat bij jouw systemen mogelijk is? Neem gerust contact met ons op. Dan kijken we samen welke informatie je wilt verbinden en welke afspraken daarvoor nodig zijn.