Веднага щом данните за устойчивост идват от повече от една бизнес единица, проблемът се появява преди да съществува регистърът. Всяка единица има собствени системи, собствени таблици, собствени определения за това какво означава дадена точка от данни. Регистър, който не подрежда това, скоро ще преброи един и същ поток три пъти или ще го пропусне изцяло.
Регистър на данни не е списък с теми за отчитане, а регистър на нивото на отделната точка от данни: емисиите от обхват 2 на обект A, броят на служителите на пълно работно време с временен договор в единица B, потреблението на вода на локация C. За всяка точка от данни трябва да бъде фиксирано какво точно измерва, в каква единица, за какъв период и за коя единица. Без тези четири елемента точката от данни не е проследима и следователно не е проверима.
Осен това регистърът съдържа за всяка точка от данни източника: системата, файла или лицето, от което идва числото. Това не винаги е толкова просто, колкото звучи. При множество бизнес единици редовно се случва точка от данни да бъде попълнена, без никой да може да посочи откъде идва; какво правите с точка от данни без установим източник е следователно въпрос, на който самият регистър трябва да може да отговори, а не нещо, което се проучва впоследствие.
Изкушението при множество бизнес единици е да се остави всяка единица поотделно да предостави списък, а след това тези списъци да се обединят. Това не работи, защото единиците рядко използват едни и същи определения. Едната единица отчита енергийното потребление по обект, другата — по производствена линия. Едната включва временните работници в персонала, другата не. Когато тези списъци се обединят, без първо да се изравнят определенията, се получават дублирания, които не могат да бъдат разпознати като такива.
Редът, който действително работи: първо се определя кои точки от данни наистина имат значение за организацията като цяло, независимо от това коя единица ги предоставя. Това е въпрос на необходимост, а не на наличност — кои точки от данни ви са наистина необходими е различен въпрос от кои точки от данни вече се намират някъде в таблица. Само след това се определя за всяка точка от данни коя единица, коя система и кое лице е източникът. Така се получава един регистър с едно определение за всяка точка от данни, в който множество единици предоставят входни данни, без самата точка от данни да се дублира.
Разпознаването на дублирания остава необходимо след това, защото дори с добри определения две единици могат неволно да записват един и същ основен факт под различно име. Как да го забележите — как разпознавате дублирана точка от данни между бизнес единици — е проверка, която се извършва върху самия регистър, а не върху отчета, който по-късно произтича от него.
Честа грешка е присвояването на собствеността на ниво единица: единица A е отговорна за всички данни от единица A. Това работи, докато единиците остават обозрими, но при множество бизнес единици с припокриващи се процеси — общ отдел за покупки, централен автопарк — това разпределение бързо става неясно. По-добре е собствеността да бъде за всяка точка от данни: едно име, което може да обясни откъде идва числото, каква е единицата и кога е било последно актуализирано. Това име не трябва да е лицето, което вписва числото, но трябва да е лицето, което познава източника.
Колко от съществуващите точки от данни вече имат такъв установим източник, обикновено е първият въпрос, който се появява веднага щом това се проверява систематично. Колко от вашите точки от данни имат източник е точно въпросът, на който трябва да се отговори поотделно за всяка бизнес единица, защото отговорът може значително да варира между единиците.
При множество бизнес единици изкушението е да се изчака, докато всички единици имат еднаква степен на задълбоченост, преди регистърът да се счита за готов. Това не е реалистичен критерий. Регистър е готов, когато за всяка точка от данни е ясно кой е собственикът, какъв е източникът и какво правило за качество се прилага към нея — дори ако този отговор за някои точки от данни временно е „неизвестен източник, действие при единица X“. Непълнотата, която е видима и разпределена, е работеща; непълнотата, която остава скрита зад попълнено число, не е. Какво точно означава този критерий, е разработено под кога регистър е готов при множество бизнес единици.
Колко време отнема изготвянето на такъв регистър, зависи от броя бизнес единици, броя системи за всяка единица и степента, в която определенията вече съвпадат. При организация с няколко единици и обозрими източници това е значително по-малко работа, отколкото при организация с десетки единици в различни ERP системи. Индикация за произхода на тази работа е дадена в колко време отнема да се приведе тема в ред.
Изготвянето и поддържането на регистър на данни за множество бизнес единици се състои от серия от разпознаваеми задачи: изискване на определения, установяване на източници, назначаване на собственици, откриване на дублирания. Част от тази работа е достатъчно повторяема, за да бъде автоматизирана, друга част изисква преценка, която трябва да остане при човек. Работният скенер на FTE TO AI изчислява за всяка задача каква част от тази работа може да бъде поета от AI, така че да стане ясно къде остават необходими човекочасове и къде не е така.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.