Синхронизация на основните данни

Синхронизацията на основните данни е практиката всяка ключова единица във фирмата — клиент, продукт, доставчик — да има един-единствен достоверен запис, който всички системи споделят. На английски дисциплината се нарича управление на основните данни (master data management, MDM), а самият достоверен запис — източник на истината (source of truth). Звучи като задача за интеграция, но всъщност е задача за собственост: кой отговаря за всяко поле и чия версия печели, когато две системи не са съгласни.

Защо един и същ клиент изглежда различно във всяка система?

В типичната фирма един клиент живее едновременно на няколко места. В счетоводната програма е вписан с точното си фирмено име и ЕИК. В системата за връзки с клиентите (CRM) е записан по спомен от продавача — с малко по-различен изговор на името. В онлайн магазина се е регистрирал сам, с личен имейл и адрес за доставка, който няма нищо общо с адреса по регистрация. Всяка от тези системи е права по свой начин и никоя не знае за другите две.

Резултатът е тих, но скъп. Маркетингът праща една и съща оферта три пъти на един и същ човек, защото го брои като трима. Финансите не могат да сглобят пълната картина на задлъжнялостта, защото плащанията са пръснати по дублирани записи. Обслужването отваря разговор с клиент, без да вижда, че той има отворена рекламация в друга система. И когато някой попита „колко клиенти имаме всъщност“, всеки отдел дава различно число — и всяко е грешно.

Защо това не е проблем на интеграцията?

Първият инстинкт е да се свържат системите — да си говорят през приложни интерфейси (API), за да текат данните между тях. Това е нужно, но само по себе си не решава нищо. Ако свържете два записа, които се разминават, просто ще разпространите разминаването по-бързо и на повече места. Тръбата пренася вода, но не я пречиства.

Истинският въпрос е друг: щом системата А казва, че адресът на клиента е един, а системата Б казва друго — на коя вярваме? Докато няма отговор на този въпрос, всяка интеграция само мести объркването. Затова синхронизацията започва не с код, а с решение за собственост: за всяко поле се определя коя система е водеща, тоест чия версия е официалната. Техниката на свързването е важна и я разглеждаме отделно в ръководството за API интеграции — но тя идва след договорката, не преди нея.

Ключово

Източникът на истината не е система, а договорка. За всяко поле — име, адрес, ЕИК, кредитен лимит — трябва да е ясно коя система го притежава и коя само го отразява. Без тази договорка всяка интеграция просто разпространява грешката по-бързо.

Как се определя източникът на истината за всяко поле?

Логиката е проста: за всяко поле води системата, която го създава и поддържа най-добре. Официалното фирмено име и ЕИК идват от счетоводната система или директно от търговския регистър — те са водещи за юридическите данни. Адресът за доставка живее там, където се обработват поръчките. Кредитният лимит принадлежи на финансите. Историята на разговорите — на CRM. Веднъж определено, полето се синхронизира от своята водеща система към всички останали, а те нямат право да го променят самостоятелно.

Тук е ключът към уникалния запис: нужен е стабилен ключ, който да свързва един и същ клиент през всички системи. За фирмите това е ЕИК — той е уникален и не зависи от изписването на името. За физически лица служат комбинации от белези, защото телефон и имейл се менят. Веднъж въведен, този ключ прави сглобяването на пълната картина въпрос на справка, а не на догадки. Ако тепърва излизате от разпръснати таблици, добър предшестващ прочит е От Excel към система — защото основни данни, разпръснати върху дузина файлове, няма как да са едни.

Как се чистят дублираните записи?

Дедупликацията — сливането на дублиращите се записи в един — е упражнение, което трябва да се направи веднъж внимателно и после да се поддържа автоматично. Процесът минава през прехвърляне, преобразуване и зареждане на данните (на английски extract, transform, load, ETL): данните се извличат от всяка система, привеждат се към общ формат и се сливат по ключа.

1. Извличане и нормализиране — имената се привеждат към единен вид, интервалите и главните букви се изчистват, ЕИК се проверява за валидност срещу официалния регистър.

2. Съпоставяне по ключ — записите с еднакъв ЕИК се разпознават като един клиент, дори имената да се разминават леко.

3. Сливане с правила — при спор кое поле печели решават правилата за собственост, а не случайността: официалното име от счетоводството, последният активен адрес от поръчките.

4. Преглед на съмнителните — записите, които приличат, но нямат общ ключ, отиват при човек за решение, вместо да се слеят на сляпо.

5. Непрекъснат контрол — след еднократното изчистване правилата остават, така че нов дубликат се хваща при създаването си, а не след година.

Откъде да започне една фирма?

Не се започва с покупка на платформа, а с една единица данни и един болезнен въпрос. Изберете клиентите, начертайте къде живеят днес, договорете кой притежава всяко поле и чак тогава свързвайте. Първата чиста синхронизация обикновено носи най-голямото облекчение — изведнъж отчетите се сглобяват сами и числата спират да си противоречат. Точно този ред — първо ред в данните, после автоматика върху тях — е гръбнакът на услугата Дигитализация, а самата логика на процесите стъпва върху основите, описани в какво е автоматизация на бизнес процеси.

Ефектът се вижда веднага щом данните тръгнат чисти през целия поток. В нашето решение за автоматизация от поръчка до фактура синхронизираният запис на клиента е точно това, което позволява една поръчка да стигне до фактура без ръчно пипане — защото по пътя никоя система не спори коя е истината.

Често задавани въпроси

Кое поле определя, че два записа са за един и същ клиент?

За фирмите най-надеждният ключ е ЕИК — той е уникален и не се променя при разлики в изписването на името. Имена, телефони и имейли се менят и се пишат по различен начин, затова служат само като допълнителни белези. Дедупликацията тръгва от ЕИК и чак после сверява останалото.

Трябва ли да сменим системите си, за да имаме един източник на истината?

Не. Източникът на истината е решение за собственост върху данните, а не нова система. За всяко поле се определя коя система е водеща, останалите се синхронизират от нея, а вече наличните ERP и CRM остават на място. Смяна се налага само ако някоя система изобщо не позволява данните да влизат или излизат.

Master data synchronisation is the practice of giving every key entity in a company — a customer, a product, a supplier — one single trustworthy record that all systems share. The discipline is called master data management (MDM), and the trustworthy record itself is the source of truth. It sounds like an integration task, but it is really an ownership task: who is responsible for each field, and whose version wins when two systems disagree.

Why does the same customer look different in every system?

In the typical company one customer lives in several places at once. In the accounting software they are entered with their exact legal name and company registration number. In the customer relationship system (CRM) they were typed from memory by a salesperson — with a slightly different spelling of the name. In the online shop they registered themselves, with a personal email and a delivery address that has nothing to do with the registered one. Each of these systems is right in its own way, and none knows about the other two.

The result is quiet but expensive. Marketing sends the same offer three times to the same person, because it counts them as three. Finance cannot assemble the full picture of what is owed, because payments are scattered across duplicate records. Support opens a conversation with a customer without seeing that they have an open complaint in another system. And when someone asks "how many customers do we actually have", every department gives a different number — and every one of them is wrong.

Why is this not an integration problem?

The first instinct is to connect the systems — to have them talk through application interfaces (API) so the data flows between them. That is necessary, but on its own it solves nothing. If you connect two records that disagree, you simply spread the disagreement faster and to more places. The pipe carries the water, but it does not purify it.

The real question is different: if system A says the customer's address is one thing and system B says another — which do we believe? Until there is an answer to that question, every integration merely moves the confusion around. So synchronisation begins not with code but with an ownership decision: for each field, you name which system is the leading one, that is, whose version is the official one. The technique of connecting matters, and we cover it separately in the guide to API integrations — but it comes after the agreement, not before it.

Key point

The source of truth is not a system — it is an agreement. For every field — name, address, company number, credit limit — it must be clear which system owns it and which merely reflects it. Without that agreement, every integration just spreads the error faster.

How do you decide the source of truth for each field?

The logic is simple: for each field, the leading system is the one that creates and maintains it best. The official company name and registration number come from the accounting system or straight from the commercial register — they lead on the legal data. The delivery address lives where orders are processed. The credit limit belongs to finance. The history of conversations belongs to the CRM. Once decided, the field is synchronised from its leading system to all the others, and they are not allowed to change it on their own.

Here lies the key to a unique record: you need a stable key that links the same customer across all systems. For companies that is the registration number — it is unique and does not depend on how the name is spelt. For individuals, combinations of attributes serve instead, because phone and email change. Once that key is in place, assembling the full picture becomes a matter of a query rather than guesswork. If you are only now emerging from scattered spreadsheets, a good prior read is From Excel to a system — because master data spread across a dozen files can never be one.

How do you clean up duplicate records?

Deduplication — merging duplicate records into one — is an exercise you should do carefully once and then maintain automatically. The process runs through extracting, transforming and loading the data (extract, transform, load, ETL): the data is pulled from each system, brought to a common format, and merged on the key.

1. Extract and normalise — names are brought to a single form, spaces and capitalisation are cleaned up, the registration number is checked for validity against the official register.

2. Match on the key — records with the same registration number are recognised as one customer, even if the names differ slightly.

3. Merge by rules — when there is a dispute over which field wins, the ownership rules decide, not chance: the official name from accounting, the last active address from orders.

4. Review the doubtful ones — records that look alike but share no key go to a person for a decision, rather than being merged blindly.

5. Continuous control — after the one-off cleanup the rules stay in place, so a new duplicate is caught as it is created, not a year later.

Where should a company start?

You do not start by buying a platform, but with one data entity and one painful question. Pick customers, map where they live today, agree who owns each field, and only then connect. The first clean synchronisation usually brings the greatest relief — suddenly the reports assemble themselves and the numbers stop contradicting each other. That very order — order in the data first, automation on top of it second — is the backbone of our Digitalization service, and the logic of the processes rests on the foundations set out in what is business process automation.

The effect shows the moment the data starts flowing clean through the whole chain. In our case study on order-to-invoice automation, the synchronised customer record is exactly what lets an order reach an invoice without manual handling — because along the way no system argues about which version is the truth.

Frequently asked questions

Which field decides that two records are for the same customer?

For companies the most reliable key is the registration number (ЕИК) — it is unique and does not change with differences in how the name is spelt. Names, phones and emails change and are written in different ways, so they serve only as supporting attributes. Deduplication starts from the registration number and only then checks the rest.

Do we have to replace our systems to have a single source of truth?

No. The source of truth is a decision about data ownership, not a new system. For each field you decide which system leads, the others are synchronised from it, and your existing ERP and CRM stay in place. A replacement is needed only if a system does not let data in or out at all.

Синхронизация на основните данни: един клиент, едно име, една истина