På denne siden
«Ordrer flyttes automatisk» høres ut som en fullstendig beskrivelse av arbeidsflyten. I et tenkt spor finnes hver ordre i begge systemer. Så dukker en kolonne i et regneark opp mellom dem. En medarbeider endrer kolonnen før opplastingen fordi statusen i butikken ikke betyr det e-postteamet forventer.
Diagrammet var riktig når det gjaldt boksene. Det overså jobben.
En samtale om å lære arbeidsflyter fra systemene som eier postene beskriver å bygge en fungerende prosedyre ved å se hva som kommer inn i et system og hva som blir rettet. Det er en nyttig start. Det betyr ikke at en logg kan forklare et menneskes hensikt, eller at et team bør få bred tilgang til kundeposter bare for å observere dem.
Start med et spor, ikke et prosessnavn
«Ordresynkronisering» høres ut som én operasjon. Følg en enkelt ordre, og den blir en rekke hendelser. Når ble den opprettet? Hvilken status ble skrevet først? Endret betaling eller avbestilling den? Hvilket felt nådde målsystemet? Hva gjorde målsystemet med feltet? Hva rettet et menneske etterpå?
Skriv hendelsene i tidsrekkefølge. Behold identifikatoren til kildeposten ved hvert steg. Hvis en verdi endres to ganger, registrer begge endringene. Hvis målsystemet bare har den nyeste verdien, finn ut hva som skjedde mellom dem. Målet er ikke et polert prosesskart. Det er et spor en annen person kan utfordre.
Det første sporet bør være vanlig. Det andre bør være et unntak: en avbestilling, en sammenslått kunde, en retur, sen betaling eller noe annet de som utfører jobben, sier er viktig. To spor fastslår ikke hyppighet. De viser spørsmålene en spesifikasjon må besvare.
- Butikkpoststatus kommer innobservert
- Medarbeiderens rettelsebetydningen sjekkesbekreftet
- E-postsystemgodtatt tilstand
| Hva teamet sier | Hva et spor kan vise | Spørsmål som bør stilles |
|---|---|---|
| «Ordrer synkroniseres automatisk» | En manuell fil lastes opp senere | Hvilken omforming gjør filen? |
| «Kundestatusen er oppdatert» | En eldre verdi skrives over av en senere hendelse | Hvilket system eier sluttilstanden? |
| «Feil går til kundestøtte» | En rettelse gjøres i kilden uten en sak | Hvordan får målsystemet vite om den? |
Dette er tenkte muligheter, ikke observerte hendelser hos kunder. Integrasjonsguiden hjelper med å velge en tilkoblingsmåte når den faktiske veien er forstått.
Poster viser atferd; medarbeidere forklarer mening
En post kan vise at en verdi ble endret fra pending til complete. Den kan ikke fortelle om endringen betydde at betalingen var gjort opp, at ordrebehandlingen var ferdig, eller at noen rettet en skrivefeil. Feltnavnet er ikke forretningsregelen.
Derfor hører observasjon og intervju sammen. Be en medarbeider gå gjennom en sak som sporet gjør vanskelig å forstå. La dem forklare unntaket og vise skjermen de har lov til å bruke. Prøv så regelen mot et annet utvalg. En spesifikasjon bygd på ett sterkt eksempel kan gjøre én persons omvei til regel for hele bedriften.
Tilgang betyr noe. Bruk minst mulig data for å svare på spørsmålet. Arbeid med godkjent tilgang, og skjul personlige felt når det er mulig. Å utforme en synkronisering gir ingen grunn til å eksportere en kundedatabase til en notatbok for undersøkelser. Hvis systemet har revisjonshendelser eller et testmiljø, begynn der. Hvis ikke, la en ansvarlig vise veien med passende poster.
Skillet hindrer også en vanlig feil ved automatisering: å fjerne et tungvint manuelt steg før du forstår hvilken vurdering det bærer. Kolonnen i regnearket kan være unødvendig dobbeltarbeid. Den kan også være det eneste stedet et menneske markerer at en omstridt ordre ikke må utløse en kampanje. Sletter du den uten å undersøke, kan den nye synkroniseringen utføre feil handling raskere.
Gjør sporet til en kontrakt
Når veien er synlig, beskriv tilkoblingen med tilstander og ansvar. Definer hvilket system som er fasit for hvert felt, hvilken hendelse som flytter det, hvordan sene eller gjentatte hendelser håndteres, og hva som skjer når resultatet er usikkert. Navngi personen eller teamet som kan rette hvert avvik.
Kontrakten bør skille registrerte fakta fra forretningsmessig tolkning. «Butikken sendte fulfilled klokken 14.03» er en registrert hendelse. «Denne kunden bør få en forespørsel om å skrive en anmeldelse» er en beslutning som også kan avhenge av returer, samtykke og lokale regler. Ved å holde dem adskilt blir senere endringer tryggere.
En feltkartlegging gjør en del av kontrakten synlig. I denne Tajo-illustrasjonen viser hver rad et kildefelt, et målfelt og en oversettelsesregel. Den viser også hva som ikke er avklart. En kjøpshendelse trenger en egen regel før den kan føre til en forespørsel om omtale eller en kampanjeavgjørelse.
Gå gjennom en synkronisering før den kjøres
Synkroniser kundeoppdateringer med e-postplattformen min.
Kundesynkronisering
| Kildefelt | Målfelt | Regel |
|---|---|---|
email | EMAIL | Direkte |
first_name | FIRSTNAME | Direkte |
last_name | LASTNAME | Direkte |
Syntetisk forhåndsvisning bestått
3 felt kartlagt · Ingen skriving til målsystemet
Illustrativ utforming basert på Tajos kartleggingsverktøy. En syntetisk forhåndsvisning og et lagret utkast aktiverer ikke en synkronisering.
En praktisk akseptansetest bruker selve sporet. Spill av en vanlig ordre og et unntak i et testmiljø. Bekreft sluttilstanden i målsystemet, ikke bare at et API-kall lyktes. Prøv så veien for retting. Hvis kildeposten endres etter at målsystemet har handlet, kan systemet rette opp forskjellen?
Innvendingen er rimelig: «Vi kan ikke studere hvert særtilfelle før vi bygger.» Riktig. Målet er ikke en fullstendig opptelling. Det er å finne de få skjulte stegene som avgjør om første versjon virker. Begynn med veiene der konsekvensen er størst, skriv ned hva som fortsatt er ukjent, og legg inn måling slik at nye unntak kan sees.
Et diagram over arbeidsflyten blir nyttig når de som utfører jobben, kan peke på boksen som mangler.
Ofte Stilte Spørsmål
Hvorfor er ikke et intervju nok for å beskrive en arbeidsflyt?
Folk kan beskrive den planlagte prosessen riktig, men utelate sjeldne unntak eller vanlige omveier. Sammenlign fortellingen med poster dere har lov til å se, og be dem forklare forskjellene.
Kan systemlogger vise hele arbeidsflyten?
Nei. Logger viser registrerte handlinger, ofte uten grunner, arbeid utenfor systemet eller beslutninger tatt andre steder. Bruk dem til å lage spørsmål til den som gjør jobben, ikke til å gjette hensikten alene.
Hva bør det første sporet for en synkronisering inneholde?
Følg én vanlig post og ett unntak gjennom kildedata, endringer, overleveringer og tilstander i målsystemet. Noter hvem som kan rette et avvik, og hva som beviser sluttresultatet.