Promjena šifre kupca u integraciji nije samo izmjena jednog polja u ERP-u. Siguran postupak mora povezati stari i novi identifikator, provjeriti sve reference koje koriste šifru te jasno razlikovati tehničko preimenovanje od spajanja dvaju stvarnih poslovnih subjekata. Povijest narudžbi, računa, isporuka, otvorenih stavaka i poruka prema povezanim sustavima mora ostati razumljiva nakon promjene.
Šifra kupca često služi u više uloga odjednom. Može biti poslovno vidljiva oznaka na dokumentu, ključ za razmjenu podataka, vrijednost u izvještaju ili referenca u drugom sustavu. Zato promjena može utjecati na više procesa, čak i kada korisnik u sučelju vidi samo jedno polje.
Prvo pitanje nije "kako promijeniti šifru", nego "što nova šifra predstavlja".
Postoje dva različita slučaja:
Ta dva slučaja ne smiju dijeliti isti proces samo zato što oba završavaju jednom aktivnom šifrom. Tehničko preimenovanje traži kontinuitet identiteta. Spajanje traži poslovnu odluku o tome koji zapisi pripadaju kojem subjektu i od kojeg trenutka.
Za tehničko preimenovanje potrebno je voditi eksplicitno mapiranje starog i novog identifikatora. Minimalni zapis uključuje:
Mapiranje nije samo pomoćna Excel datoteka uz projekt. Ono je poslovni dokaz kako sustavi tumače povijesne i nove poruke. Ako integracija primi staru šifru nakon prijelaza, sustav mora imati unaprijed određeno ponašanje: prihvatiti je i prevesti, odbiti je uz povratnu informaciju ili poslati na ručnu obradu. Odgovor ovisi o procesu, ugovorenom načinu razmjene i riziku pogrešnog knjiženja.
Dobro je odvojiti poslovnu šifru od trajnog tehničkog identiteta gdje to arhitektura dopušta. Tada promjena vidljive šifre ne mora automatski mijenjati vezu svakog povezanog zapisa. To nije univerzalno rješenje za postojeće sustave, ali je korisno pitanje pri dizajnu promjene.
Popis referenci mora obuhvatiti više od glavne evidencije kupaca. Provjerite najmanje sljedeće skupine:
Ovaj popis nije tvrdnja da svaki ERP ima iste objekte. Njegova je svrha usmjeriti provjeru na mjesta gdje se identifikator može pojaviti kao ključ, atribut ili tekstualna vrijednost.
Ograničenja podataka mogu pomoći pri provjeri jedinstvenosti, obveznih polja i veza među zapisima. PostgreSQL, primjerice, opisuje ograničenja poput UNIQUE , NOT NULL , primarnih i stranih ključeva u dokumentaciji Constraints . Takve provjere ne određuju poslovno značenje promjene. Pravilo o prihvatu stare šifre, razdoblju paralelnog rada ili dopuštenom spajanju zapisa mora biti definirano zasebno i imati imenovanog vlasnika.
Prije tehničke pripreme okupite vlasnika matičnih podataka, financije, vlasnika prodajnog procesa, vlasnika integracije i osobu odgovornu za ERP transakcije. Zatim odgovorite na sljedeća pitanja.
Hipotetski scenarij: kupac promijeni internu oznaku s K-104 na K-778 , bez promjene poslovnog subjekta. Registar mapiranja povezuje obje oznake s istim trajnim identitetom. Nova prodajna dokumentacija koristi K-778 , dok povijesni dokumenti mogu zadržati izvorno evidentiranu oznaku ako je to poslovno pravilo. Integracija pritom mora prepoznati koju oznaku partner šalje i evidentirati rezultat obrade.
Drugi hipotetski scenarij uključuje dva zapisa nastala zbog dvostrukog unosa. To nije automatski preimenovanje. Prije spajanja potrebno je provjeriti poslovne podatke, otvorene transakcije i posljedice za izvještavanje. Ako postoji nesigurnost o identitetu subjekta, zapis treba ostati u iznimci do poslovne odluke.
Praktičan redoslijed smanjuje rizik od prekida i pogrešnog povezivanja povijesnih zapisa.
Automatsko preusmjeravanje stare šifre može olakšati prijelaz partnerima, ali može i sakriti zastarjelu konfiguraciju. Strogo odbijanje stare šifre brže otkriva problem, ali može zaustaviti poslovni tok. Razdoblje paralelnog prihvata zato nije čisto tehnički parametar. Ono je odluka vlasnika procesa uz procjenu utjecaja na transakcije i podršku.
Jednako vrijedi za izmjenu povijesnih dokumenata. Prikaz nove šifre kroz cijelu povijest olakšava jedinstveni pogled na kupca. Zadržavanje izvorne šifre čuva kontekst dokumenta iz vremena nastanka. Potrebno je odlučiti što korisnici trebaju vidjeti u operativnom radu, izvještajima i analizi odstupanja.
Kad opseg nije poznat ili odgovornosti nisu jasne, Screening poslovnog procesa može strukturirati vlasnike, tokove i odluke prije tehničke izmjene.
Prije početka rada pripremite sljedeće ulaze:
Dodijelite odgovornosti:
Evidentirajte iznimke poput nepoznate stare šifre, sukoba s već postojećom novom šifrom, više mogućih odredišta, nedostajućeg obveznog podatka i neriješene odluke o spajanju.
Kriterij prihvata može biti provjerljiv bez proizvoljnog ciljnog broja: svaki zapis iz odobrenog opsega mora imati jednoznačno evidentiranu odluku, svaka testirana referenca mora se razriješiti prema odobrenom pravilu, a svaka iznimka mora imati vlasnika i status. Nakon toga promjena šifre kupca postaje upravljan proces povezivanja povijesnih zapisa, a ne izolirana izmjena polja.
Za proces s više ERP-ova ili nejasnim vlasništvom nad podacima, sljedeći korak je zajednički pregled toka i odgovornosti s ORKA timom .