Obstaja poseben občutek nelagodja, ko odprete pet let star izvoz strank. Polovica telefonskih številk ima predpono +386, polovica pa ne. Stolpec z imenom “Opombe” zmeša tri različne vrste informacij, odvisno od tega, kdo je bil tisti dan v naglici. Ime nekega podjetja je v dveh različnih vrsticah zapisano na dva različna načina, in vi dejansko ne veste, ali gre za isto stranko.
Ali ne bi bilo lepo, če bi lahko nered preprosto naložili takšnega, kot je, brez predhodnega čiščenja, brez preoblikovanja, sistem pa bi vam pošteno povedal, kaj je našel, kaj je uganil in česa ni mogel zapolniti? Zdaj lahko. Craft11 smo zgradili tako, da se prilagodi temu, kako resnična podjetja dejansko vodijo svojo evidenco, ne obratno.
Kako to dejansko deluje
Ko naložite datoteko (CSV, Excel, PDF, celo skeniran cenik), gre ta k Neu, delu Craft11, ki bere dokumente. Neo ne poskuša uskladiti vaše preglednice s togo shemo. Prebere dejansko vsebino in predlaga strukturirane zapise: to je videti kot ime, to je videti kot e-pošta, to je videti kot panoga ali kategorija. Vsak predlog nosi stopnjo zaupanja (visoka, srednja, nizka), tako da vam nikoli ni treba uganjati, za katera polja je prepričan in pri katerih razumno ugiba.
Nič se še ne ustvari. Najprej vidite pregledno tabelo. Pike zaupanja ob vsaki vrstici, urejanje na mestu, če je kaj narobe, jasno število tega, kaj je popolno in kaj ni. Potrdite tisto, kar je dobro. Tipkarsko napako lahko popravite takoj na mestu, ali pa jo preprosto pustite in popravite pozneje. Oboje je v redu.
To je del, ki ljudi preseneti: nikoli vas ne blokira zaradi nepopolnih podatkov. Če 47 od vaših 300 kontaktov nima telefonske številke, se ostalih 253 vseeno uvozi brezhibno, vi pa dobite pošten, konkreten seznam tistih 47, ne nejasnega opozorila tipa “nekateri zapisi so morda nepopolni”, temveč dejansko število, ki ne izgine, dokler ni dejansko rešeno. Stark vam lahko pomaga to razrešiti pogovorno, kadar koli imate nekaj minut. Ta vrzel je informativna, ne ovira.
Problem podvajanja, o katerem nihče ne govori
Tukaj je nekaj, kar se ne pojavi v večini predstavitev orodij za uvoz: kaj se zgodi, če isti seznam naložite dvakrat? Ali ko je sodelavec stranko že napol ročno vnesel, zdaj pa je množični uvoz na robu tega, da ustvari drugo kopijo iste osebe pod nekoliko drugačnim zapisom?
To rešujemo z namerno preprostim pravilom, ki se samodejno uporabi, preden sploh vidite zaslon za pregled. Za uvoz strank gre za ujemanje e-pošte, ne glede na velike in male črke, z vašimi obstoječimi zapisi. Za katalog virov gre za ujemanje naziva, ne glede na velike in male črke. Vsaka vrstica, ki je videti kot verjetna podvojitev, se označi in privzeto ostane neizbrana v pregledni tabeli: ni blokirana, ni samodejno združena, le neoznačena je. Še vedno lahko obkljukate polje in jo vseeno uvozite, če ste to res nameravali. Sistem tega ne sme odločiti namesto vas. Le poskrbi, da nesreča ne zdrsne skozi neopazno.
To smo neposredno testirali: naložili smo datoteko s kontaktom, katerega e-pošta se je natančno ujemala z obstoječo stranko, poleg res novega kontakta. Podvojitev je bila označena in ostala neizbrana. Nov kontakt se je uvozil brezhibno. Ponovni zagon iste datoteke drugič ni ustvaril ničesar dodatnega. V tem je bistvo: ponovno nalaganje ne bi smelo biti nekaj, pri čemer morate biti previdni.
Prava napaka, odkrita na pošten način
Rad bi vam povedal o nečem, kar je med gradnjo dejansko šlo narobe, ker bi bila alternativa, pretvarjati se, da je vse od začetka delovalo popolno, prav tista vrsta tržne neiskrenosti, ki se ji poskušamo izogniti.
Uvoznik kataloga virov ima polje za stopnjo DDV. Naša podatkovna baza to zahteva. Privzeta vrednost je 25 %, standardna stopnja, zato bi moral vir brez izrecno navedene stopnje samodejno uporabiti to privzeto vrednost. Le da je ni. Če ste naložili cenik brez stolpca DDV (kar je izjemno pogosto, veliko cenikov ga preprosto nima), bi uvoz podrl surovo napako strežnika v trenutku, ko bi ga poskusili aktivirati.
Razlog je bil subtilen: privzeta vrednost podatkovne baze se sproži le, kadar je polje pri vstavljanju v celoti izpuščeno. Naša koda je v to polje izrecno pisala null, namesto da bi ga preprosto izpustila, kar je pomenilo, da varnostna mreža podatkovne baze tega nikoli ni imela priložnosti ujeti. To smo odkrili le zato, ker smo izvedli pravi test od začetka do konca, z realistično datoteko, ki resnično ni imela stolpca DDV (ne hipotetično, temveč dejanski nalog), in opazovali, kako je spodletelo. Popravek je bil ena vrstica: privzeto 25 % v kodi, isto število, ki ga podatkovna baza sama dokumentira kot standardno, samo takrat, ko izvorna datoteka o tem res molči.
To vam povem ne, ker bi bila to laskava zgodba, temveč ker je to dejanska tekstura poštenega gradnje nečesa takega. Instinkt, da to napako odkrijemo tako, da dejansko testiramo neurejeno resnično datoteko, namesto da predpostavimo idealen potek, je isti instinkt, ki stoji za celotno funkcijo. Programska oprema, ki je samozavestna glede podatkov, ki jih dejansko še nikoli ni videla, je natanko tista vrsta programske opreme, ki se ji poskušamo izogniti.
Vse skupaj smo preizkusili na podjetju, ki še ne obstaja
Preden je bilo to objavljeno, smo izvedli popolnoma simuliran mesec uporabe za štiričlansko svetovalno ekipo: resnične poizvedbe, ki prihajajo, resnični pogovori s strankami, resnični uvozi katalogov, na namenskem testnem najemniku, ves čas z uporabo resničnega AI modela, ne skripte. To smo lahko izvedli tako temeljito, ker smo že od prvega dne vnesli velik, realističen sklop podatkov in zgradili Velvet, naš lastni simulator za testiranje, prav zato, da nismo bili omejeni na preverjanje enega robnega primera naenkrat. V istem mesecu je teklo več neurejenih scenarijev hkrati: CSV s kontaktom, ki je že obstajal, pomešanim z resnično novimi, poleg vsega drugega, kar je ta mesec vrgel na sistem.
Skupni strošek AI za celoten ta simulirani mesec, za štiri osebe, je znašal manj kot dolar. To omenjamo, ker imajo orodja za uvoz “z AI pogonom” sloves, včasih zaslužen, da postanejo draga naročnina-znotraj-naročnine. Pri tem obsegu se ta strah preprosto ne drži.
Česa to ne počne
V duhu, da tega ne olepšujemo: to ni čarovnija OCR za resnično neberljive sken, in ne bo uganilo polja, ki ga v izvorni datoteki nikoli ni bilo. Strukturirani PDF-ji in urejene preglednice delujejo dobro; fotografiran, ročno pisan račun iz leta 2019 potrebuje več človeškega pregleda, sistem pa to pošteno pove, namesto da si izmisli uganko.
Prav tako namerno ne združuje podvojitev samodejno. To ostaja odločitev človeka, ne programske opreme. Jasno označevanje in privzeto “tega ne uvozi dvakrat” je prava mera pomoči.
Če trenutno strmite v svoj lastni neurejen izvoz
Pošten odgovor na “koliko časa bo to trajalo” je: verjetno popoldne, ne teden dni. Naložite datoteko. Preglejte, kaj je Neo našel. Potrdite, kar je pravilno, popravite, kar ni, vrzeli pa pustite za pozneje, če želite. Še vedno bodo tam, jasno prešteta, kadar koli boste pripravljeni. Namen nikoli ni bil narediti vaših podatkov popolnih, preden začnete. Bil je preprečiti, da bi popolni podatki postali cena vstopnice.
Craft11-ov Migracijski pogon obravnava tako uvoz strank kot uvoz virov z isto arhitekturo, opisano zgoraj: pridobivanje podatkov z oceno zaupanja, zaznavanje podvojitev in pošteno sledenje vrzelim. Oglejte si to v vodenem ogledu izdelka →