Enostransko izhodišče za sistem za odpremo in izdajo računov po meri

Kaj razvijalci dejansko potrebujejo od vas: eno stran, ne specifikacije

Obseg določa, kaj razvoj vključuje in kaj namerno izpušča. Pripomoček za pripravo osnutka (ki ni obvezna oblika) je ena sama stran, o katere končni obliki se dogovorite z agencijo. Možna struktura uporablja štiri bloke: prikaz trenutnega procesa, pet do osem uporabniških zgodb, kriterije uspešnosti za vsako zgodbo ter preprosto zapisane mejne pogoje in seznam "ni v v1". Te bloke obravnavajte kot ponazoritev, ne kot samo izhodišče.

Niro Digital ni predložil študije primera iz primerljivega operativnega ali logističnega projekta, zato sta ta delovni list in praktični primer splošen pripomoček za pripravo osnutka in zamišljena ponazoritev, ne pa dokaz, da struktura izhaja iz zaključenega dela za stranke. Storitev razvoja programske opreme po meri, ki jo oglašuje Niro Digital, opisuje njihove rešitve kot CRMs, nadzorne plošče, orodja za zaposlene in logistične sisteme, prilagojene dejanskemu delovanju podjetja. Ta opis si lahko preberete na strani za razvoj programske opreme po meri.

Najprej preslikajte eno naročilo od telefonskega klica do računa

Ta članek je splošen pripravljalni delovni list, ne pa zapis s terena o izvedbi projekta za stranko Niro Digital. Izberite eno ponavljajoče se opravilo in sledite njegovemu posameznemu primeru, ne najbolj napornemu tednu. Za vsak korak zabeležite štiri stvari: kdo nekaj naredi, katere podatke prebere ali vnese, katerega orodja ali kanala se dotakne in kje delo čaka ali se podatki ponovno vnašajo. Brez diagramov. Dovolj je ena vrstica na korak.

Spodnje izpolnjene vrstice so le ponazoritev za vas, ne pa opis sodelovanja s stranko podjetja Niro Digital; vnesite svoje korake in orodja.

Preštejte podvajanja in čakanja; to so vaši cilji za avtomatizacijo.

Naj strošek na dotik določi, kaj gre v v1

Dotik je vsakič, ko oseba prebere, vnese ali kopira podatke. Ocenite vsak dotik glede na to, kako pogosto se zgodi, koliko časa traja in ali podatki že obstajajo nekje drugje.

Če uporabimo zamišljeno ponazoritev in ne vaših številk: če ponovni vnos naročila traja 10 minut na naročilo in pisarna porabi 12 ur na teden za kopiranje zaključenih naročil, teh 12 ur predstavlja plačan čas, porabljen za premikanje podatkov, ki že obstajajo v listu z naročili. Če izdaja računov čaka en teden, ker status dostave prejmete le po telefonu, to čakanje financira to vrzel. Preden se odločite za karkoli, zamenjajte vsako številko s svojimi izmerjenimi podatki.

Te tri ocene obravnavajte kot neobvezna vprašanja za razpravo z agencijo, ne pa kot pravilo, ki določa v1. Vprašajte, kateri dotiki se dogajajo najpogosteje, trajajo najdlje ali kopirajo podatke, ki že obstajajo, in katere od teh bi agencija najprej avtomatizirala znotraj vaše meje €20,000–€30,000. Prosite jo, naj oceni stroške teh možnosti, preden se zavežete obsegu. Primerjajte to mejo z okvirnimi cenovnimi razredi, ki jih Niro Digital objavlja na svoji strani s cenami; ti razredi odražajo običajne projekte. Oglejte si stran s cenami.

Zdaj zapišite pet do osem uporabniških zgodb v poslovnem jeziku

Uporabniška zgodba je en sam stavek v obliki: "Kot [oseba] želim [nekaj, kar sistem naredi], da lahko [poslovni rezultat]." Zgodba se imenuje zato, ker opisuje eno opravilo z vidika ene osebe, ne pa zato, ker bi bila lahko ohlapna. Izhodišče za odpremo/izdajo računov bi lahko vsebovalo zgodbe, kot so te:

• Kot dispečer želim, da se status naročila posodobi, ko voznik potrdi dostavo, da lahko izdam račun brez čakanja na telefonski klic.
• Kot pisarniški administrator želim, da se ob potrditvi dostave iz vrstic naročila ustvari osnutek računa, da ne bom ponovno vnašal istega naročila v datoteko za izdajo računov.
• Kot lastnik želim videti, katera naročila so pri voznikih in katera so dostavljena, da lahko odgovorim stranki brez klicanja dispečerja.

Zapišite le tiste zgodbe, ki iz vašega prikaza odstranijo dotik, čakanje ali napako. Če jih imate več kot osem, odvečne že zdaj premaknite na seznam 'ni v v1'.

Spremenite vsako uporabniško zgodbo v test uspešno/neuspešno, ki ga razvijalec lahko predstavi

Kriteriji sprejemljivosti so pogoji, ki jih boste preizkusili na predstavitvi: vsak od njih je ocenjen kot uspešen ali neuspešen, brez subjektivnih ocen.

Na predstavitvi prosite razvijalca, naj preizkusi vsak kriterij s testnim naročilom. Če se morata prepirati o tem, ali je bil uspešno opravljen, ga napišite znova. Če ne morete sami določiti [X], se o njem dogovorite z agencijo pred podpisom.

Ta navada ocenjevanja uspešno/neuspešno se sklada z objavljeno doktrino podjetja Niro Digital o avtomatizaciji z umetno inteligenco (AI): "Izhodnim podatkom modelov nikoli ne zaupamo slepo. Vsaka avtomatizacija vključuje deterministične preverbe, proračunske omejitve in človeško odobritev za nepovratna dejanja. Gradimo sisteme, kjer se izhodni podatki AI obravnavajo kot trditev, ki mora prestati preverjanja, preden se šteje za dokončano."

Navedite splošna pravila v preprostem jeziku

To so omejitve, ne funkcije. Razvijalec jih potrebuje za oceno obsega razvoja, vi pa jih lahko navedete tako, kot bi jih razložili sodelavcu.

• Uporabniki in naprave: na primer osem pisarniških uslužbencev na namiznih računalnikih, vozniki pa na telefonih med vožnjami.
• Hitrost: ko voznik potrdi dostavo, bi jo moral dispečer pri običajni pisarniški uporabi videti v roku [X] sekund; kriterij za predstavitev zapišite tako, ne pa kot "takoj". Vnos naročila ne sme blokirati dela v pisarni. Sami določite [X]; če ne morete, se o njem dogovorite z agencijo pred podpisom.
• Vloge: dispečerji vidijo vsa naročila, vozniki vidijo le svoje dodeljene vožnje, računovodja pa vidi polja za račune in VAT.
• Lastništvo podatkov: vi ste lastnik podatkov in jih lahko izvozite v običajnem formatu, kot je CSV.
• Varnost in dostop do podatkov: navedite, kdo lahko dostopa do podatkov o strankah, dostavah in računih, ali je treba dostop odstraniti, ko zaposleni odidejo, ter kakšno varnostno kopiranje in obnovitev pričakujete. Prosite agencijo, naj pred začetkom razvoja opredeli, katere zahteve GDPR in varnostne zahteve veljajo; to ni pravni nasvet ali nasvet glede skladnosti.
• Izdajanje računov in VAT: navedite, katera polja mora vsebovati račun, nato pa jih preverite pri svojem računovodji. Lokalna pravila za izdajanje računov in VAT se spreminjajo, to pa ni davčni nasvet.

Napišite seznam "ni v v1", preden karkoli podpišete

Ta seznam obravnavajte kot pisno mejo obsega za razpravo z agencijo, ne kot pravilo odločanja. Vsako točko zapišite kot "ni v v1, možno kasneje". Primeri izključitev:

• Ni v v1: samodejna optimizacija poti — dispečer še vedno dodeljuje vožnje; sistem le zabeleži dodelitev.
• Ni v v1: celovita aplikacija za voznike — vozniki uporabljajo preprosto mobilno stran za status dostave, ne pa za navigacijo ali fotografiranje.
• Ni v v1: zapletena finančna analitika — sprejmite seznam zapadlih naročil in izdanih računov, ne pa nadzorne plošče z maržami po poteh.

Omejite se na tri do pet izključitev. Če funkcija kasneje postane nujna, postane zahteva za spremembo, ne pa napaka.

Vaše enostransko izhodišče

Kopirajte spodnji blok na eno stran in ga uporabite kot pripomoček za pripravo osnutka: to je eden od možnih načinov za organizacijo prvega pogovora o zahtevah. To ni edina oblika, ki jo lahko ima izhodišče, o končni obliki pa se dogovorite z agencijo. V tej fazi od vas ne pričakujejo žičnih modelov, zasnov zaslonov ali shem podatkovnih baz.

• Varnost in podatki: navedite, kdo lahko dostopa do podatkov o strankah, dostavah in računih; ali je treba odstraniti dostop osebe, ki odide; ter kakšno varnostno kopiranje in obnovitev pričakujete. Pred začetkom razvoja vprašajte agencijo, katere zahteve GDPR in varnostne zahteve veljajo. To ni pravni nasvet ali nasvet glede skladnosti.

Delovni list za odpremo/izdajo računov in praktični primer v tem članku sta le ponazoritev za bralca, ne pa opis sodelovanja s stranko podjetja Niro Digital ali izmerjen rezultat.

Uporabite enostransko izhodišče za preizkus ponudbe agencije, nato pa vprašajte o nadzoru nad spremembami

Ponudba bi morala odgovoriti na izhodišče, ne pa ga nadomestiti. Preden jo podpišete, preverite štiri stvari: ali ponovno navaja vaš dejanski problem, ali navaja predpostavke, ki jih razvijalci sprejemajo, ali ločuje fiksni obseg od dodatkov in ali navaja, kaj ni vključeno.

• Kakšne predpostavke sprejemate o našem trenutnem procesu?
• Kaj ni vključeno v oceno?
• Ko po začetku projekta ugotovimo, da manjka kakšen korak, kako se določi cena in odobri sprememba?
• Ali lahko predstavite vsak kriterij sprejemljivosti, preden zapade končni račun?

Nadzor nad spremembami je le dogovorjen postopek za odločanje o tem, kaj se zgodi, ko se zahteva spremeni: kaj se zapiše, kdo to odobri in kako se premika proračun. Zahteve se bodo po začetku projekta razvijale; to je normalno. Tveganje ni odkrivanje novih zahtev, temveč neomejeno odkrivanje.

Vzemite enostransko izhodišče s seboj na naslednji pogovor z agencijo. Če želite, da ga Niro Digital pregleda, uporabite kontaktni obrazec in omenite, da ste pripravili enostransko izhodišče. Namen tega klica je preveriti, ali obseg ustreza vašemu proračunu, in kateri korak najprej digitalizirati — ne pa, da vam takoj prodajo sistem.