Kupec in uporabnik potrebujeta različna dokaza

V ponazoritveni trgovini oseba, zadolžena za trženje, ob petkih preverja, ali so nove stranke prispele v platformo za e-pošto. Predlagana sinhronizacija preverjanje nadomesti s poročilom in seznamom izjem. Osebo zanima, ali je seznam zanesljiv in kaj storiti, ko zapis manjka.

Lastnik, ki odobri nakup, sprašuje nekaj drugega: kaj se zgodi s podatki strank, kdo lahko aktivira občinstvo kampanje in kakšno delo bo ekipa prevzela?

Obe vprašanji sta upravičeni. En izdelek mora odgovoriti na obe.

Delavnica o vrednosti izdelkov to razliko izrecno opredeli: kadar se uporabnik in plačnik razlikujeta, vsak potrebuje korist v svojih pojmih. Vir govori o drugem kontekstu izdelka. Pri poslovni integraciji ta razlika pomaga preprečiti prodajno napako: dokazati, da funkcija deluje za izvajalca, in pri tem ne podpreti kupčeve odločitve.

Osebi, ki opravlja delo, pokažite nalogo

Dokaz za izvajalca je resničen potek dela. Izberite zapis ene stranke in pokažite njegovo pot od izvora do ciljnega sistema. Katero polje določa identiteto? Kateri atribut nosi privolitev? Kaj se zgodi, ko ciljni sistem zavrne vrednost? Ali izvajalec lahko najde neuspešen zapis in razume popravek?

Seznam podprtih aplikacij ne odgovori na nobeno od teh vprašanj. Prav tako ne število operacij API. Izvajalec potrebuje dokaz, da je konkretno tedensko opravilo krajše ali zanesljivejše.

Pri novi integraciji je najboljši dokaz morda omejen predogled. Pokažite deset reprezentativnih zapisov, predlagano preslikavo in nastala stanja v ciljnem sistemu. Vključite vsaj eno izjemo. Popoln vzorec desetih običajnih zapisov lahko skrije prav tisti del naloge, ki izvajalcu vzame največ časa.

Tajov vodnik za integracijo Brevo vodi skozi praktično povezavo. Vprašanje kupca in uporabnika stoji korak pred nastavitvijo: čigavo delo se izboljša in kdo mora spremembi zaupati, preden postane rutina?

Obe vrsti dokazov lahko zberete v enem pilotu, ne da bi se pretvarjali, da sta isto merilo. Izvajalec naj nalogo opravi na majhnem, reprezentativnem naboru zapisov. Hkrati zabeležite, katera dovoljenja so bila podeljena, kateri podatki so prečkali mejo in kdo lahko razveljavi napačno preslikavo. Gladka izvedba z nenadzorovanim dostopom ni uspešen pilot; prav tako ni uspešno popolnoma nadzorovano orodje, ki ga izvajalec ne zna uporabljati.

Osebi, ki nosi tveganje, ga pokažite

Kupec morda nikoli ne bo pregledal preslikave polj. Vseeno nosi strošek slabe preslikave. Če integracija stranko uvrsti v napačno občinstvo, lahko škoda traja dlje od nastavitvene seje. Zato kupec potrebuje kratek opis dostopa, odobritve, revizijske sledi in odgovornosti za odpravo napake.

To ne zahteva debele brošure o upravljanju. Zahteva odgovore, vezane na predlagano delo: kateri podatki zapustijo trgovino, kateri sistem jih prejme, kdo lahko spremeni preslikavo in kateri dokaz bo pokazal, da je sinhronizacija tekla pravilno? Če mora aktivacijo odobriti oseba, to točko jasno pokažite.

Pošten ugovor je: „Če je izvajalcu izdelek všeč, bo nakup sledil.“ Včasih. A uspešna predstavitev izvajalcu ne določa meje podatkov ali tekočih stroškov. Prav tako kupčeva odobritev še ne naredi slabega vsakodnevnega poteka uporabnega. Če katero od obeh obravnavate kot zadostno, se manjkajoča polovica pokaže po nakupu.

Vodnik za povezovanje več poslovnih orodij začne s potekom dela, sprožilcem in virom resnice. Te odločitve naj uredijo tudi dokaz za kupca. Ciljni sistem in lastnik podatkov sta poslovni dejstvi, ne skriti izvedbeni podrobnosti.

Nakupna odločitev ima tudi časovno težavo. Vsakodnevni uporabnik težave pri uvajanju občuti takoj; kupec lahko posledice napačnega občinstva vidi šele čez nekaj tednov. Predstavitev daje prednost temu, kar se pokaže hitro. Pilot naj zato vključuje poznejši pregled: ponovno preverite nastale zapise v ciljnem sistemu in vprašajte, ali je obljubljeno stanje obstalo. Tako predstavitev funkcije postane dokaz o dejanskem poteku dela.

Dokaz za izvajalca izid zapisa obravnava izjem

Pilotni zapis stanje v ciljnem sistemu stanje dovoljenja

Dokaz za kupca meja dostopa sprotna odgovornost

Izvajalec preveri, ali zapis doseže pravo stanje; kupec preveri strošek, pristojnost in tveganje. Pilotni zapis poveže oba dokaza.

Ne pozabite osebe, ki jo zapis predstavlja

Obstaja še tretji pogled: stranka, katere podatki se premikajo. Običajno je ni na nakupnem sestanku. Njena dovoljenja in pričakovanja vseeno določajo meje dejanj izvajalca in kupca.

Ponazoritvene stranke, ki je zavrnila trženje, ne smete šteti za „uspešno sinhronizirano“ zgolj zato, ker so vsa polja prispela v ciljni sistem. Pravilen izid vključuje stanje dovoljenja. Zato se kupčev dokaz o tveganju in izvajalčev dokaz o poljih srečata pri istem zapisu.

Koristno poročilo pilota ima zato lahko tri vrstice: čas izvajalčeve naloge ali število izjem, kupčev dokaz o strošku in nadzoru ter zaščiteno stanje končne stranke. Ne napolnite jih z izmišljenimi številkami. Pred pilotom se dogovorite o preverjanjih, nato zberite rezultate.

Cena tega pristopa je natančnejše raziskovanje potreb. Govoriti morate z ljudmi, ki potek izvajajo in odobravajo, ter upoštevati tiste, na katere vpliva. Dobiček je ocena izdelka po delu, ki ga spremeni, ne po seznamu funkcij, ki jih zna našteti.

Nakup ima lahko en podpis. Dokaz zanj ima več občinstev.