Single source of truth integrācijās: kur glabāt galveno klienta, pasūtījuma un statusa informāciju

Galvenā informācija jāglabā sistēmā, kura atbild par konkrētā biznesa fakta radīšanu, pārbaudi un labošanu. CRM nav automātiski jābūt visu klienta datu īpašniekam, un ERP nav obligāti jānosaka katrs pasūtījuma statuss. Vienam klientam vai pasūtījumam dažādi lauki var piederēt dažādām sistēmām, taču katram laukam un statusa dimensijai jābūt vienam autoritatīvam avotam.

Tātad single source of truth integrācijās nenozīmē vienu datubāzi visam uzņēmumam. Tas nozīmē skaidru atbildību: kurš avots drīkst mainīt konkrēto faktu, kur glabājas tā aktuālā versija un kā pārējās sistēmas saņem kontrolētu kopiju. Šāda pieeja ļauj projektēt datu plūsmu bez minējumiem un nekontrolētas divvirzienu sinhronizācijas.

Ko praksē nozīmē single source of truth

Single source of truth jeb SSOT ir noteikums, ka noteiktam biznesa faktam ir viens autoritatīvs avots. Ja avoti savā starpā atšķiras, par pareizu uzskata šī avota vērtību, līdz tā tiek labota pēc definēta procesa.

Svarīgi nošķirt četrus jēdzienus:

•          Autoritatīvais avots glabā un apstiprina aktuālo biznesa faktu.
•          Kopija saņem datus izmantošanai citā sistēmā, bet pati tos nenosaka.
•          Lasīšanas modelis apvieno informāciju ērtai attēlošanai, meklēšanai vai atskaitēm.
•          Vēsturiskais momentuzņēmums saglabā faktu tādu, kāds tas bija konkrēta notikuma brīdī.

Piemēram, CRM var būt galvenais avots klienta kontaktpersonai, savukārt pasūtījums saglabā piegādes adreses momentuzņēmumu, kas bija spēkā pirkuma veikšanas brīdī. Vēlāka adreses maiņa CRM nedrīkst pārrakstīt jau izpildīta pasūtījuma vēsturi.

SSOT nav arī sinonīms datu noliktavai. Datu noliktava var būt autoritatīva apstiprinātiem vadības pārskatiem, bet tā parasti nav vieta, kur operatīvi labot klienta adresi vai mainīt izpildes statusu.

Kāpēc vienu sistēmu nevar automātiski pasludināt par galveno

Bieža kļūda ir izvēlēties sistēmu pēc tās nosaukuma: klienta dati pieder CRM, pasūtījumi — e-komercijas platformai, bet nauda — grāmatvedības programmai. Šāds sākumpunkts ir saprotams, taču ar sistēmas kategoriju nepietiek.

Autoritatīvo avotu nosaka pēc atbildības un procesa:

1. Kurā sistēmā fakts pirmoreiz rodas?
2. Kura loma drīkst to apstiprināt vai mainīt?
3. Kur tiek pārbaudīti obligātie lauki un biznesa noteikumi?
4. Kuras sistēmas nepieejamības gadījumā process faktiski apstājas?
5. Kur jāspēj izskaidrot, kas, kad un kāpēc vērtību mainīja?
6. Kura sistēma pārvalda konkrētā objekta dzīves ciklu?

Sistēma ar visvairāk lauku ne vienmēr ir galvenais avots. CRM var saturēt rēķina numuru ērtai apskatei, bet tas nepadara CRM par rēķina īpašnieku. Tāpat klientu portāls var rādīt apvienotu pasūtījuma stāvokli, lai gan tā komponentes nāk no pasūtījumu, noliktavas un maksājumu sistēmām.

Praksē ar objekta īpašnieka noteikšanu var nepietikt. Vajadzības gadījumā jānosaka arī lauka īpašnieks. Klienta komerciālās attiecības var pārvaldīt CRM, juridiskos rekvizītus — sistēma, kurā tie tiek pārbaudīti rēķinu sagatavošanai, bet mārketinga saziņas izvēles — risinājums, kurā šīs izvēles tiek iegūtas un administrētas.

Statuss nav viens universāls lauks

Visvairāk pretrunu parasti rada lauks “statuss”. Vienam pasūtījumam vienlaikus var būt vairāki neatkarīgi stāvokļi:

•          pasūtījuma pieņemšanas statuss;
•          apmaksas statuss;
•          komplektēšanas vai pakalpojuma izpildes statuss;
•          piegādes statuss;
•          rēķina statuss;
•          klientam rādāmais kopsavilkuma statuss.

Ja visas šīs nozīmes ievieto vienā brīvā teksta laukā, integrācijai nav skaidrs, ko nozīmē “apstrādē” un kurš drīkst šo vērtību mainīt. Drošāks modelis ir sadalīt statusu dimensijās. Maksājumu sistēma nosaka maksājuma rezultātu, noliktavas vai darbu vadības sistēma — izpildes progresu, bet pārvadātāja sistēma — piegādes notikumus.

Klientam rādāmais statuss var būt atvasināta projekcija. Piemēram, saskarne var rādīt “gatavojam pasūtījumu”, pamatojoties uz apstiprinātu maksājumu un sāktu komplektēšanu. Šī projekcija ir noderīga komunikācijai, tomēr tā nedrīkst pārrakstīt pamatstatusus to avotos.

Katram statusam jādefinē atļautās pārejas. Ja pasūtījums ir atcelts, integrācija nedrīkst to nejauši atgriezt stāvoklī “jauns” tikai tādēļ, ka pienācis novēlots notikums. Datubāzes ierobežojumi var palīdzēt aizsargāt lokālus datu noteikumus. PostgreSQL dokumentācija apraksta, kā ierobežojumi uztur datu atbilstību noteiktām prasībām. Tomēr noteikumi starp vairākām ārējām sistēmām jāīsteno arī integrācijas un procesa līmenī.

Metode autoritatīvā avota noteikšanai

Lēmumu var pieņemt pārbaudāmā secībā, nevis arhitektūras sanāksmē vienkārši vienojoties par “galveno sistēmu”.

1. Izveidojiet biznesa faktu sarakstu

Nesāciet ar sistēmu nosaukumiem. Uzskaitiet faktus, kurus process izmanto: klienta identifikators, uzņēmuma nosaukums, kontaktpersona, piegādes adrese, pasūtījuma rindas, cena vienošanās brīdī, maksājuma rezultāts, izpildes posms un piegādes numurs.

Katram faktam pierakstiet, kur tas rodas, kur tiek labots, kam tas nepieciešams un vai jāglabā vēsture. Tas atklāj laukus, kuri pašlaik tiek rediģēti vairākās vietās bez prioritātes noteikuma.

2. Nosakiet biznesa īpašnieku pirms tehniskā īpašnieka

Datu bāzes atrašanās vieta nav tas pats, kas atbildība. Biznesa īpašnieks nosaka vērtības nozīmi, kvalitātes prasības un atļautās izmaiņas. Tehniskais īpašnieks uztur sistēmu un integrāciju.

Ja neviena loma nevar paskaidrot, kurš apstiprina klienta apvienošanu, pasūtījuma atcelšanu vai statusa labojumu, problēmu neatrisinās jauns API savienojums. Vispirms jāpieņem procesa lēmums.

3. Izveidojiet īpašumtiesību matricu

Katram laukam vai faktu grupai norādiet:

Tabulas vērtības jāpielāgo konkrētajam uzņēmumam. Tabula padara katra fakta atbildību redzamu, taču tajā norādītais nav universāls sistēmu sadalījums.

4. Vienojieties par identifikatoriem

Nosaukums vai e-pasta adrese nav drošs tehniskais identifikators. Katram klientam un pasūtījumam vajadzīgs stabils identifikators, bet integrācijai bieži jāglabā arī citu sistēmu identifikatoru atbilstība.

Jādefinē, kas notiek, ja klienti tiek apvienoti, ieraksts deaktivizēts vai pasūtījums izveidots pirms klienta kartītes. Identifikatoru kartēšana jāglabā kontrolētā vietā. Pretējā gadījumā viena klienta labojums var nonākt cita ierakstā.

5. Aprakstiet rakstīšanas un lasīšanas ceļu

Ja lietotājs klientu portālā maina informāciju, tas vēl nenozīmē, ka portāls kļūst par tās avotu. Portāls var nosūtīt izmaiņu komandu autoritatīvajai sistēmai, saņemt apstiprinājumu un tikai pēc tam atjaunot attēlojumu.

Patērētājiem jāzina, vai saņemtā vērtība ir apstiprināta, gaida apstrādi vai ir tikai kešota kopija. Ja avots nav pieejams, izvēle jāizdara apzināti: bloķēt kritisku izmaiņu, ievietot pieprasījumu rindā vai ļaut tikai lasīšanu. Klusu ierakstīšanu lokālā kopijā ar cerību “vēlāk salabot” ir grūti kontrolēt.

6. Definējiet datu kontraktu

Datu kontraktā jāapraksta lauku nozīme, formāts, obligātums, atļautās statusu vērtības, laika zīmogu interpretācija, versija un dzēšanas vai apvienošanas semantika. Jānorāda arī tas, vai notikums satur pilnu objekta stāvokli vai tikai izmaiņu.

Bez šīs vienošanās divas sistēmas var tehniski apmainīties ar vienādu lauku, bet interpretēt to atšķirīgi. Piemēram, “pasūtījuma datums” var nozīmēt izveidošanas, apstiprināšanas vai apmaksas brīdi.

Ilustratīvs klienta un pasūtījuma modelis

Pieņemsim, ka uzņēmums izmanto CRM, pasūtījumu sistēmu, darbu vadības risinājumu un klientu portālu. Šis piemērs ilustrē atbildības sadalījumu un nav gatavs arhitektūras paraugs.

CRM pārvalda potenciālā un esošā klienta komerciālo profilu. Pasūtījumu sistēma izveido pasūtījumu un saglabā rindas, cenu, valūtu un pasūtījuma brīdī izmantotos rekvizītus. Darbu vadības sistēma nosaka faktiskās izpildes posmu. Portāls apkopo datus lasīšanai un nosūta izmaiņu pieprasījumus attiecīgajam īpašniekam.

Šādā modelī portālā nav “vēl vienas patiesības”. Ja klients lūdz mainīt aktīva pasūtījuma piegādes adresi, portāls nosūta pieprasījumu pasūtījumu sistēmai. Tā pārbauda, vai izpildes posmā izmaiņa vēl ir atļauta. CRM kontaktadreses maiņa pati par sevi nepārraksta pasūtījuma momentuzņēmumu.

Savukārt klientam rādāmo paziņojumu var aprēķināt no vairākiem avotiem. Svarīgi saglabāt iespēju izskaidrot, no kuriem pamatfaktiem tas radies, nevis glabāt tikai neskaidru kopsavilkumu.

Kā pārvietot datus starp sistēmām

Rakstīšanas pieprasījums jānovirza datu īpašniekam, bet par izmaiņām citas sistēmas var informēt ar notikumiem. Microsoft aprakstītais Publisher-Subscriber modelis atdala publicētāju no patērētājiem un ļauj vairākiem saņēmējiem reaģēt uz publicētu notikumu. Tas neatceļ vajadzību noteikt autoritatīvo avotu — notikuma publicētājam jābūt tiesībām paziņot konkrēto faktu.

Lokālas, savstarpēji saistītas datubāzes izmaiņas vēlams pabeigt vienā transakcijā. PostgreSQL transakciju dokumentācija skaidro transakcijas kā darbību kopumu, kas tiek izpildīts pilnībā vai neizpildās. Taču vairāku neatkarīgu sistēmu API izsaukumus nevar vienkārši uzskatīt par vienu lokālu datubāzes transakciju.

Ja process daļēji izpildās, vajadzīgi atkārtojumi, starpstāvokļi un reizēm kompensējošas darbības. Microsoft Compensating Transaction apraksts uzsver, ka eventual consistency vidē kompensēšana var būt atsevišķs biznesa process, nevis precīza tehniska darbību attīšana pretējā secībā.

Pāreja no vairākām “patiesībām” uz vienu avotu

Esošā vidē autoritatīvo avotu nevar droši ieviest tikai ar konfigurācijas maiņu. Praktiska pāreja ietver šādus soļus:

1. Inventarizēt laukus, integrācijas un vietas, kur lietotāji tos labo.
2. Atrast konfliktējošās vērtības un noteikt, kā tās tiks izšķirtas.
3. Izvēlēties īpašnieku katram faktam un dokumentēt izņēmumus.
4. Sakārtot identifikatoru atbilstību starp sistēmām.
5. Pārtraukt nekontrolētu divvirzienu rediģēšanu.
6. Sinhronizēt sākotnējos datus un pārbaudīt izlasi pēc biznesa noteikumiem.
7. Pārslēgt rakstīšanas ceļu uz izvēlēto avotu.
8. Uzraudzīt kļūdas, aizturi un manuālos labojumus, pirms veco ceļu izslēgšanas.

Konfliktus nevajadzētu automātiski atrisināt ar jaunāko laika zīmogu. Vēlāks ieraksts var būt novecojis imports vai kļūdaina manuāla izmaiņa. Prioritātei jāizriet no datu īpašumtiesībām, statusa pāreju noteikumiem un, ja nepieciešams, cilvēka pārbaudes.

Kā pārbaudīt, vai modelis darbojas

SSOT ieviešanas rezultātu var vērtēt ar operatīviem rādītājiem:

•          ierakstu skaits bez atbilstoša ārējā identifikatora;
•          gadījumi, kuros vienam faktam avotos ir atšķirīgas vērtības;
•          sinhronizācijas aizture un neveiksmīgo notikumu rinda;
•          neatļautu statusa pāreju skaits;
•          manuālu datu labojumu un atkārtotas ievades gadījumi;
•          izmaiņas, kurām nevar noteikt avotu vai iniciatoru.

Ar kopiju vienādumu nepietiek. Jāpārbauda, vai biznesa process turpinās paredzami arī tad, ja kāda sistēma vai integrācija īslaicīgi nav pieejama.

Ierobežojumi un riski

Viens autoritatīvs avots var kļūt par procesa atkarības punktu. Tāpēc jāplāno tā pieejamība, rezerves darbības režīms un atjaunošana. Tomēr rezerves režīms nedrīkst nemanāmi radīt otru pastāvīgu avotu.

Ne visus datus drīkst vienmēr pārrakstīt ar pašreizējo vērtību. Pasūtījumiem, līgumiem un citiem vēsturiskiem darījumiem var būt vajadzīgi momentuzņēmumi. Jānošķir aktuālais klienta profils no fakta, kas tika izmantots konkrētā darījumā.

Arī audita žurnāls parasti nav operatīvā fakta avots. Tas palīdz izskaidrot izmaiņu vēsturi, bet aktuālā vērtība jānosaka domēna sistēmai. Savukārt analītikas platformas dati var būt apzināti aizkavēti un nederēt operatīva lēmuma pieņemšanai.

Kopiju skaits palielina pārvaldības un piekļuves risku. Katrai kopijai jābūt pamatotam lietojumam, piekļuves noteikumiem, glabāšanas termiņam un dzēšanas procesam. SSOT neatrisina sliktu datu kvalitāti automātiski: kļūdains ieraksts autoritatīvajā avotā tikai konsekventāk izplatīsies tālāk.

Kontrolsaraksts pirms integrācijas ieviešanas

Pirms izstrādes komandai jāspēj nepārprotami atbildēt:

•          Kas ir katra lauka un statusa autoritatīvais avots?
•          Vai citas sistēmas glabā kopiju, momentuzņēmumu vai atvasinātu projekciju?
•          Kurš drīkst ierosināt un kurš apstiprina izmaiņu?
•          Kā tiek sasaistīti identifikatori?
•          Kas notiek ar novēlotu, atkārtotu vai neatļautu izmaiņu?
•          Kā process darbojas avota nepieejamības laikā?
•          Kā tiks atrasti konflikti un izmērīta sinhronizācijas kvalitāte?

Secinājums

Pareizā vieta galvenajiem datiem nav obligāti tehniski centrālākā sistēma. Tā ir sistēma, kurai uzticēta konkrētā fakta biznesa atbildība un dzīves cikls. Ja katram laukam un statusa dimensijai ir viens īpašnieks, pārējās sistēmas var veidot kā kontrolētus patērētājus, nevis konkurējošus patiesības avotus.