Преди да преместите данните, назовете техния собственик

За 1 минута

Когато една компания събере данните си на едно място, технологията не заменя споразумението кой отговаря за всеки набор от данни. Ако едно число излезе грешно, кой го поправя, в коя система и с какъв договорен приоритет? Практиката в бранша изисква три неща преди зареждането на данните: собственик с име, писмено споразумение между този, който произвежда данните, и този, който ги използва, и няколко правила за качество, които могат да се проверяват при всяко зареждане. Не всичко изисква еднаква строгост: при един-единствен източник и ограничена употреба можете да започнете леко.

Представете си средна по размер дистрибуторска компания. Тя е измислена, но прилича на много други. Продава през три канала, фактурира в една система, води наличностите в друга, а вземанията в трета. Всеки край на месеца Финансите и Търговският отдел идват на срещата с различно число за нетните продажби.

Ръководството решава да го уреди наведнъж: да събере всички данни в една платформа, с табла за всеки отдел. Проектът започва добре. След три месеца данните пристигат, таблата изглеждат добре и срещата… е същата. Сега спорят пред по-голям екран.

Какво се случи? Никой не зададе един прост въпрос, преди да се премести първата данна: кой отговаря за нея?

Тази статия е за онзи, който ще одобри — или вече е одобрил — проект за събиране на данните на компанията. Тя защитава една идея: преди да се премести една данна, се назовава нейният собственик, записва се какво обещава и се решава как се проверява. Технологията идва след това.

Защо данните без собственик се разпадат

Данните за продажбите ги произвежда един отдел (този, който фактурира), преобразуват ги други (този, който съгласува, този, който изготвя отчета), а ги използват много. Когато нещо излезе грешно, всеки може да посочи следващия. Ако никой не отговаря за това данните да са верни, грешката се поправя на ръка в отчета, всеки месец, и следващата се появява отново.

Браншът назовава този проблем от години. Zhamak Dehghani, в текста, дал началото на идеята за data mesh, предлага отговорността за данните да се разпредели между «people who are closest to the data» и всеки набор от данни да се третира като продукт, а неговите потребители — като клиенти [1]. Не е нужно да възприемете целия този подход, за да запазите същественото: данни, които се споделят, имат нужда от някой, който отговаря за тях, както продуктът има нужда от някой, който отговаря за качеството му.

Три неща, които се определят преди зареждането

1. Собственик с име, а не отдел

«Финансите го гледат» не е собственик. Собственик е човек с име, в отдела, който произвежда данните, или в онзи, който ги разбира най-добре, с три отговорности:

• Да каже какво означава данната. Какво е «нетна продажба»: със или без връщания? Със или без кредитни известия? По датата на фактурата или по датата на плащането?
• Да одобрява промените. Ако изходната система промени правило, собственикът решава дали и определението се променя и уведомява тези, които използват данните.
• Да отговаря, когато не се връзва. Когато една проверка се провали, някой трябва да отговори в договорен срок.

Рамката за качество на данните на правителството на Обединеното кралство възлага на собственика на данните решения като това дали данни, които вече не се използват, се архивират или унищожават, и изисква информацията за тяхното качество да се съхранява заедно с тях [3]. Това е публично ръководство, а не норма за вашата компания, но принципът важи също толкова: решенията за дадени данни имат отговорник.

2. Писмено споразумение между този, който произвежда, и този, който използва

Втората стъпка е да се запише какво обещава този набор от данни. Браншът го нарича договор за данни: споразумение между този, който произвежда данните, и този, който ги потребява. Отвореният стандарт за такива договори, Open Data Contract Standard (проект Bitol, към фондацията LF AI & Data), ги организира в раздели: основните сведения, структурата на данните, правилата за качество и каналите за поддръжка, между другото [2].

За един комитет не е нужен технически формат. Достатъчно е споразумението да отговори, на една страница:

• Какво съдържа: кои полета, с какво значение и в каква единица.
• Колко често пристига: в края на деня, всеки час, в момента, в който се случва.
• Какво качество обещава: правилата от следващия раздел.
• Кой се уведомява, когато нещо се променя или се проваля, и в какъв срок се обработва.

Споразумението защитава и двете страни. Който използва данните, знае какво да очаква; който ги произвежда, знае какво не може да променя, без да уведоми.

3. Няколко правила за качество, които се проверяват при всяко зареждане

Качеството не се декларира; проверява се. Британската рамка използва шест измерения, определени от DAMA UK: пълнота, уникалност, съгласуваност, навременност, валидност и точност [3]. Нейният пример е полезен: 300 ученици, 294 записани телефона за спешни случаи; полето е пълно на 98 %, но това не означава, че телефоните са верни. Пълно не е същото като вярно.

Преведени за една компания, първите правила обикновено са прости:

Примерни правила за илюстрация; тези на вашата компания ги определя всеки собственик.

Като отправна точка изберете правилата, които покриват най-съществените рискове за тези данни — липсващи записи, дубликати, разлики спрямо източника —, договорете кога се проверяват и кой обработва провала и направете така, че резултатът да бъде видян от този, който използва данните, преди да ги използва.

Кога е нужно всичко това и кога не

Назоваването на собственици и писането на споразумения струва време на заети хора. Не във всеки случай си струва.

Можете да започнете леко, ако:

• Отчетите ви излизат от една-единствена система, с ограничена употреба и определен отговорник.
• Това е еднократен анализ, който никой няма да повтаря и да използва, за да решава за пари.
• Това е експеримент с тестови данни, без ефект върху работата.

Дори и в тези случаи, и още повече ако има лични данни или регулаторно задължение, запишете какво означават данните, кой отговаря за тях и кой може да ги вижда.

Добре е да го направите преди зареждането, ако:

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

Какво отхвърляме и защо

• «Първо зареждаме всичко, после ще видим.» Това е най-честото изкушение, защото изглежда като напредък. Проблемът е, че управлението, добавено по-късно, върху данни, които вече се използват, се договаря с отдели, които вече са изградили отчети върху различни определения.
• «ИТ отделът да е единственият собственик на данните.» ИТ отделът може да отговаря за работата на системите, сигурността и достъпите, но не е негова работа да решава дали едно връщане се приспада през месеца на продажбата или през този на кредитното известие. Това значение, употребата и качеството на данните принадлежат на бизнес отдела. Запишете двете роли и кой решава, когато не съвпадат.
• «Комитет по данните решава всичко.» Комитетът помага да се уреждат конфликти между отдели, но ако всяка промяна чака месечното му заседание, хората се връщат към електронната таблица. Собственикът решава промените в своята област; ако една промяна засяга споделено определение, достъпите, поверителността или друг отдел, комитетът я решава, с отговорник и дата.
• «Купуването на инструмент за каталог урежда управлението.» Инструментът съхранява определенията; той не ги пише и не ги налага. Без собственици каталогът се пълни с полета без описание.

Пет въпроса за следващия комитет

1. Кой, с име, отговаря за всяко от петте числа, които най-много се обсъждат на срещата?
2. Записано ли е какво означава всяко и одобрил ли го е собственикът му?
3. Кои правила се проверяват при всяко зареждане и кой вижда резултата, преди числото да се използва?
4. Когато едно правило се провали, кой се уведомява и в какъв срок се обработва?
5. Ако изходната система промени правило, кой научава за това, преди отчетът да излезе грешен?

Ако повечето отговори са «никой» или «зависи», проектът за данни още не е готов да расте.

Откъде да започнете тази седмица

Вземете трите набора от данни зад числата, които най-много се обсъждат — фактурите, плащанията, наличностите, които и да са — и попълнете по един лист за всеки:

• Собственик: име и отдел; и, отделно, кой го поддържа в ИТ отдела.
• Кой го използва: кои отдели и за какви решения.
• Какво обещава: какво съдържа и колко често пристига.
• Правила: как се разбира, че е пълен, без дубликати и съгласуван с източника си.
• Достъп: кой може да го вижда.
• Известяване: кого уведомяват, когато не се връзва, и с какъв приоритет се обработва.

Ако някое поле остане празно, това е първата задача, преди да купите или изградите каквото и да е.

Какво прави Hábil

В Hábil изграждаме по мярка системите и интеграциите, които движат данните на вашата компания, и управляваме платформата, в която тези данни се събират.

Ако компанията ви има нужда от една-единствена версия на вашите числа, предложението е в Hábil Lake. Избираме заедно трите до пет въпроса, които днес ви струват най-много. За всеки от тях записваме от коя система идва всяко число, как се изчислява и с какво се съгласува. Всяко зареждане се сравнява с изходната система —бройки, суми, общи стойности по дата— и резултатът остава видим като светофар: връзва се или не се връзва. Всяка таблица има описание, изходна система и запис на таблиците, от които произлиза, а достъпът се дава по роля.

Разговорът може да започне с вашите три листа, дори наполовина попълнени: кои данни, кой ги произвежда и къде се разделят числата. С това заедно преглеждаме откъде си струва да се започне. Пишете ни в WhatsApp; за да защитим информацията, не споделяйте по този канал данни на клиентите си или на системите си: в разговора ще договорим канала за случая.

Поискайте първия си разговор, безплатно.

Прегледани на 13 ноември 2026 г. Всеки източник е с ниво на доверие: високо (прочетен първичен източник).