Potek dela med polji na diagramu

„Naročila se premikajo samodejno“ zveni kot popoln opis poteka dela. V ponazoritveni sledi se vsako naročilo pojavi v obeh sistemih. Nato se med njima pokaže stolpec v preglednici. Izvajalec ga pred nalaganjem spremeni, ker status trgovine ne pomeni istega, kar pričakuje ekipa za e-pošto.

Diagram je bil pravilen na ravni polj. Zgrešil je delo.

Razprava o spoznavanju potekov iz sistemov z izvornimi zapisi opisuje gradnjo delujočega postopka z opazovanjem, kaj vstopa v sistem in kaj se popravi. To je uporaben začetek. Ne pomeni pa, da dnevnik lahko pojasni človekov namen ali da naj ekipa dobi širok dostop do zapisov strank zgolj za opazovanje.

Začnite s sledjo, ne z imenom procesa

„Sinhronizacija naročil“ zveni kot ena operacija. Sledite enemu naročilu in postane zaporedje. Kdaj je nastalo? Kateri status je bil zapisan prvi? Ga je plačilo ali preklic spremenil? Katero polje je doseglo ciljni sistem? Kaj je ta sistem s poljem naredil? Kaj je človek popravil pozneje?

Dogodke zapišite v časovnem vrstnem redu. Ob vsakem koraku ohranite identifikator izvornega zapisa. Če se vrednost dvakrat spremeni, zabeležite obe spremembi. Če ciljni sistem hrani le zadnjo vrednost, ugotovite, kaj se je zgodilo vmes. Cilj ni lep zemljevid procesa. Cilj je sled, ki jo lahko druga oseba preveri.

Prva sled naj bo običajna. Druga naj bo izjema: preklic, združena stranka, vračilo, pozno plačilo ali drug primer, ki ga izvajalci označijo za pomembnega. Dve sledi ne določita pogostosti. Razkrijeta vprašanja, na katera mora specifikacija odgovoriti.

1. Zapis trgovine

   status prispe
   opaženo
2. Popravek izvajalca

   pomen je preverjen
   potrjeno
3. Ciljni e-poštni sistem

   sprejeto stanje

Kaj ekipa pove	Kaj lahko razkrije sled	Vprašanje
„Naročila se sinhronizirajo samodejno“	Ročna datoteka se naloži pozneje	Katero pretvorbo opravi datoteka?
„Status stranke je aktualen“	Poznejši dogodek prepiše starejšo vrednost	Kateri sistem ima v lasti končno stanje?
„Napake gredo podpori“	Popravek nastane v izvoru brez zahtevka	Kako ciljni sistem izve zanj?

To so ponazoritvene možnosti, ne opaženi incidenti strank. Vodnik za integracijo pomaga izbrati način povezave, ko dejansko pot razumete.

Zapisi kažejo vedenje; izvajalci pojasnijo pomen

Zapis lahko pokaže, da se je vrednost spremenila iz pending v complete. Ne pove pa, ali je to pomenilo potrjeno plačilo, dokončano obdelavo naročila ali popravek tipkarske napake. Ime polja ni poslovno pravilo.

Tu opazovanje in intervju sodita skupaj. Izvajalca prosite, naj vas vodi skozi primer, ki ga sled naredi nejasnega. Naj pojasni izjemo in pokaže dovoljen zaslon, ki ga uporablja. Nato pravilo preverite še na drugem vzorcu. Specifikacija iz enega prepričljivega primera lahko obvod ene osebe spremeni v politiko podjetja.

Dostop je pomemben. Za vprašanje uporabite najmanj podatkov, kolikor jih potrebujete. Delajte z odobrenim dostopom in, kjer je mogoče, prekrijte osebna polja. Zasnova sinhronizacije ni opravičilo za izvoz zbirke strank v raziskovalni zvezek. Če sistem ponuja revizijske dogodke ali preizkusno okolje, začnite tam. Sicer naj lastnik pokaže pot s primernimi zapisi.

Razlika prepreči tudi pogosto napako pri avtomatizaciji: odstranitev neprijetnega ročnega koraka, preden razumemo presojo, ki jo nosi. Stolpec v preglednici je morda nepotrebno podvajanje. Morda pa je edino mesto, kjer človek označi, da sporno naročilo ne sme sprožiti kampanje. Če ga odstranite, ne da bi to ugotovili, lahko nova sinhronizacija samo hitreje opravi napačno dejanje.

Sled spremenite v tehnično specifikacijo

Ko je pot vidna, povezavo opišite s stanji in lastniki. Določite, kateri sistem je avtoritativen za posamezno polje, kateri dogodek ga premakne, kako obravnavate pozne ali ponovljene dogodke in kaj se zgodi ob negotovem rezultatu. Poimenujte osebo ali ekipo, ki sme popraviti vsako neskladje.

Tehnična specifikacija naj loči zapisano dejstvo od poslovne razlage. „Trgovina je ob 14:03 poslala fulfilled“ je zabeležen dogodek. „Ta stranka naj prejme prošnjo za oceno“ je odločitev, ki je lahko odvisna tudi od vračil, privolitve in lokalnih pravil. Ločitev olajša poznejše spremembe.

Preslikava polj razkrije en del dogovora. V tej ponazoritvi Tajo vsaka vrstica navede izvorno polje, ciljno polje in pravilo pretvorbe. Pokaže tudi, kaj še ni določeno. Dogodek nakupa potrebuje ločeno pravilo, preden postane poziv za oceno ali odločitev o kampanji.

TajoPonazoritev zasnove · Vzorčni podatki

Preglejte sinhronizacijo pred zagonom

Sinhronizirajte spremembe podatkov strank z mojo platformo za e-pošto.

Aplikacija Tajo MCPOsnutek

Sinhronizacija strank

TrgovinaPlatforma za e-pošto

Preslikava polj

Izvorno polje	Ciljno polje	Pravilo
email	EMAIL	Neposredno
first_name	FIRSTNAME	Neposredno
last_name	LASTNAME	Neposredno

Sintetični predogled je uspel

Preslikana so 3 polja · Brez zapisov v cilj

Aktivacija zahteva odobritev.

Predogled preslikaveUstvarite osnutek

Ponazoritveni prikaz temelji na orodjih Tajo za preslikavo. Sintetični predogled in shranjeni osnutek ne aktivirata sinhronizacije.

Praktičen sprejemni preizkus uporabi samo sled. V preizkusnem okolju ponovite običajno naročilo in izjemo. Potrdite končno stanje v ciljnem sistemu, ne le uspešnega klica API. Nato preizkusite pot popravka. Če se izvorni zapis spremeni po tem, ko je ciljni sistem že ukrepal, ali ga sistem zna uskladiti?

Ugovor je pošten: „Pred gradnjo ne moremo preučiti vsake izjeme.“ Drži. Cilj ni popoln popis. Poiščite nekaj skritih korakov, ki odločajo, ali prva različica deluje. Začnite s potmi z največjimi posledicami, zabeležite neznanke in povezavo opremite tako, da boste opazili nove izjeme.

Diagram poteka dela postane koristen, ko ljudje, ki delo opravljajo, lahko pokažejo na manjkajoče polje.