På denne side
En foreslået synkronisering har tyve bokse. Boks syv kopierer en status ind i et regneark. Boks otte tilpasser regnearket til en e-mailplatform. Boks ni sender en e-mail til en leder om at godkende importen. Planen spørger, hvilken agent der skal udføre boks syv til ni.
Det første spørgsmål er, hvorfor boksene findes. Det er et tænkt eksempel, ikke en gennemgang af et virkeligt team.
En samtale om design af arbejdsgange foreslår fire kategorier for arbejdet: slet trinnet, brug almindelig kode, brug en agent, eller lad et menneske beslutte. Det nyttige greb kommer før valget af model. Hvis et trin fjernes, kan behovet for alt maskineriet omkring det forsvinde.
Begynd med det resultat, kunden kan se
Nævn det resultat, arbejdsgangen skal levere. Ved en forbindelse fra butik til e-mail kan det være »en kunde, der har købt, får ikke længere en påmindelse om kurven«. Det resultat kræver tilstand, timing og en regel om udelukkelse. Det kræver ikke et regneark, en fuld eksport hver nat eller lederens indbakke.
Tajo-illustrationen nedenfor holder gennemgangen tæt på den foreslåede mapping og grænsen før aktivering. Den implementerer ikke undertrykkelse af påmindelser om indkøbskurven. For at opnå det skal den ansvarlige først definere købssignalet og undertrykkelsesreglen. Et ekstra mappet felt kan ikke erstatte nogen af de to beslutninger.
Gennemgå en synkronisering, før den kører
Synkroniser kundeopdateringer med min e-mailplatform.
Kundesynkronisering
| Kildefelt | Destinationsfelt | Regel |
|---|---|---|
email | EMAIL | Direkte |
first_name | FIRSTNAME | Direkte |
last_name | LASTNAME | Direkte |
Syntetisk forhåndsvisning bestået
3 felter mappet · Ingen skrivninger til destinationen
Illustrativt layout baseret på Tajos mappingværktøjer. En syntetisk forhåndsvisning og en gemt kladde aktiverer ikke en synkronisering.
Gå den eksisterende vej baglæns fra resultatet. Spørg for hvert trin, hvad der ville fejle, hvis det forsvandt. En reel kontrol har et svar: Samtykke ville gå tabt, en betalingsindsigelse ville blive overset, eller en afsendelse uden tilladelse kunne ske. En overdragelse af vane har måske kun et historisk svar: Det gamle system krævede en fil.
Kategorien for sletning giver ikke lov til at fjerne beskyttelse. Undersøg formålet med hvert trin, før det sættes i en kategori.
- Krævet resultatkundens resultatgå baglæns
- Undersøg trineneformål og kontrolfjern døde trin
- Beholdt arbejdeansvarligt og testbart
Gennemgangen finder det, der skal leveres, og de afhængigheder, der faktisk beskytter det. Hvis et regneark rummer en faglig vurdering, som ikke findes andre steder, skal vurderingen bevares, selvom filen forsvinder.
| Trintype | Spørgsmål | Eksempel i et tænkt kurv-flow |
|---|---|---|
| Fjern | Beskytter eller skaber det det krævede resultat? | En dobbelt eksport, ingen læser |
| Almindelig kode | Er reglen præcis og stabil? | Udeluk påmindelse ved et bekræftet køb |
| Modelvurdering | Kræver trinnet en afgrænset fortolkning? | Klassificer en fritekstanmodning til det rette team |
| Person eller godkendt politik | Giver valget beføjelser, eller har det væsentlige konsekvenser? | Godkend adgang til kundedata |
Tabellen er et designværktøj. Den fortæller ikke, hvordan en virksomheds faktiske trin blev klassificeret.
Læg præcise regler i kode
Et API-kald, kontrol af feltværdi, sammenligning af tidsstempler eller kontrol af tilladelse bliver ikke bedre, fordi en model improviserer det. Kode kan udtrykke en regel, køre på samme måde to gange og vise en fejl, der kan undersøges. Brug det, hvor reglen kan siges præcist.
I eksemplet med kurven kan en købshændelse komme sent eller to gange. Programmet skal finde ordren, sammenligne den aktuelle tilstand og afvise en påmindelse, når købet er kendt. Kan systemet ikke fastslå, om kunden købte, behøver det en tilstand for usikkerhed. En model kan ikke give sig selv lov til at gætte, at kunden ikke købte.
Noget arbejde modsætter sig præcise regler. En supportanmodning kan lyde: »Jeg købte det i går, men kvitteringen viser min gamle adresse.« At sende beskeden til rette team kan kræve en afgrænset vurdering af betydning. Output bør være et kendt team eller »usikkert«, ikke en fri instruktion om at ændre ordren. Hold modellens valg adskilt fra den kode, der håndhæver adgang og skriver tilstand.
Hvorfor én agent kan skjule trinene
»Én agent kan læse arbejdsgangen og gøre det hele.« En demo kan få det til at se enklere ud. I drift skal nogen stadig forklare, hvorfor agenten må se en post, hvilke handlinger den må udføre, og hvordan en forkert handling rulles tilbage. En bred agent gemmer ofte de samme trin inde i en prompt og fjerner de etiketter, der gjorde dem mulige at kontrollere.
En anden indvending er, at gennemgangen i fire kategorier selv tager tid. Det gør den. Hold den kort. Vælg ét kunderesultat, skriv de nødvendige trin, og spørg hvad hvert trin bidrager med. Øvelsen er kun værdifuld, hvis den gør arbejdet mindre eller ansvaret tydeligere. En omfattende gennemgang af alle tilstødende systemer bliver endnu en boks.
Test inddelingen med et normalt tilfælde og en fejl. Hvis et fjernet trin i hemmelighed var en kontrol, bør testen vise det. Hvis en modelvurdering ikke kan vurderes på eksempler, så gør den smallere eller giv beslutningen tilbage til en person. Hvis koden skal ændres ved hver kundeundtagelse, så skil de stabile mekanismer fra den lokale forretningsregel.
Gennemgangen behøver også en regel for, hvornår den stopper. Et team kan dele hver opgave i stadig mindre dele, indtil inddelingen koster mere end det sparede arbejde. Stop, når hvert trin, der beholdes, har en ansvarlig, en udløser og en testbar grund til at findes. Registrer den ene usikkerhed, der kunne ændre designet, og test den så i den mindste afgrænsede del af den virkelige drift. For en synkronisering kan det være, om en købshændelse når frem tidsnok til at stoppe en planlagt kurvpåmindelse. Integrationsguiden giver en bredere rækkefølge for planlægning; de fire kategorier forhindrer, at unødige trin overlever i den. Gennemgå inddelingen igen, når arbejdsgangen eller dens tilladelser ændres.
Det billigste trin er det, resultatet aldrig krævede.
Ofte Stillede Spørgsmål
Hvad bør fjernes før automatisering?
Et trin, der kun findes for at kompensere for en unødvendig overdragelse, en dobbelt post eller en rapport uden brugere, er en kandidat. Kontrollér dem, der bruger resultatet, og sikkerhedskontrollerne, før trinnet slettes.
Hvornår har et trin brug for en model?
Brug en model til en snæver vurdering af betydning, som ikke kan udtrykkes som en stabil og præcis regel, med synlige input, svar i fast form og en vej ved usikkerhed.
Hvilke beslutninger bør blive hos et menneske?
Valg, der kræver samtykke, giver tilladelser eller har følger uden for systemets godkendte omfang, bør ligge hos en ansvarlig person eller en udtrykkeligt godkendt politik.