Число в отчет за устойчивост почти никога не е число директно от източник. То обикновено е резултат от събиране, осредняване, тегловно изчисление или преразпределение по локации, периоди или единици. Тази стъпка се нарича агрегация, и от всички операции между източник и отчет тя често е най-невидимата. Формула в електронна таблица събира дванадесет месечни числа в годишно число, или работен лист осреднява емисионни фактори за няколко доставчика. Никой не записва при това какво предположение се съдържа в него.
Между суровото измерване и публикуваното число има няколко стъпки. Първо се събират данни от системи или електронни таблици, след което се преизчисляват в обща единица, а след това се обединяват до ниво, което се вписва в отчета — бизнес звено, държава или общо. Всяка стъпка може да съдържа избор, който променя крайното число: включвате ли сливане от датата на придобиване или за цялата година, осреднявате ли по тегло спрямо оборота или спрямо броя на служителите, закръглявате ли по източник или само в общото. Какви точно операции стоят между източника и отчета, зависи от индикатора и структурата на организацията, и на какви операции стоят между източник и отчет, когато източникът има няколко източника, този списък става по-дълъг, отколкото повечето организации очакват.
Агрегацията е избор, а изборите, които не са документирани, се правят отново при следващия отчетен цикъл — често от друг човек, с друго предположение. Резултатът е, че число от предходната година не може вече да бъде проследено до същата логика, и че контролер или одитор не може да установи дали промяна в числото е реална промяна или промяна в метода на изчисление. Документиране тук не означава: описване на процес в общи термини. То означава: за всяка отчетна точка да се записва какви източници са включени, с каква тегловна стойност, за какъв период, и кой е взел това решение.
Агрегацията често се бърка с нормализацията, но това са две отделни стъпки. Нормализацията прави данните сравними — например чрез преизчисляване на различни енергийни единици в един стандарт. Агрегацията след това обединява тези сравними данни в по-високо ниво. Грешка в нормализацията се разпростира във всяка следваща агрегация, което означава, че тези две стъпки трябва да се проверяват отделно. Как да направите това, е описано на как документирате нормализация.
Повечето организации не разполагат с изходни данни, които идват подредено от една система. Част от данните за устойчивост са във фактури, част — в електронна таблица, изпратена по имейл от доставчик на енергия, част — в експорт от ERP система. Агрегация между тези източници означава, че трябва ръчно да установите кой ред отговаря на кой период и кой ред е преброен двойно. На какво е source-to-report mapping, когато източникът е електронна таблица е описано как картографирате тази връзка между суровия източник и отчетната точка, а на как документирате агрегация, когато източникът е електронна таблица е описано конкретно как документирате тази стъпка с електронната таблица, така че самата агрегация да стане възпроизводима, дори без човека, който първоначално е създал формулата.
Документирането на агрегацията не изисква софтуер. То изисква дисциплина: при всяка изчислителна стъпка да се записва какво е влязло, какво правило е приложено и какво е излязло. Това може да стане в регистър до съществуващите електронни таблици, преди да се закупи каквато и да е система. Как изглежда това без инструменти, е описано на как създавате lineage без инструмент. Който прескочи тази стъпка и директно закупи софтуерен пакет за отчитането, слага само по-подреден слой върху същата неясна агрегация — отчетът изглежда по-добре, но въпросът дали числото е правилно, остава без отговор.
Правило за агрегация, което не е документирано, е също контролна точка, която липсва. При външна проверка или вътрешен преглед някой трябва да може да покаже защо число е съставено по начина, по който е съставено, а не само че числото съответства на резултата от калкулатора. Тази разлика — между число, което е правилно, и число, което може да бъде обосновано — е точно това, за което служи одитна пътека (audit trail), и защо тя съдържа повече от прост дневник на промените, както е обяснено на защо одитна пътека е повече от дневник.
Веднъж когато правилата за агрегация са документирани — какви източници, каква тегловна стойност, какъв период, кой е взел решението — се създава основа за определяне коя част от тази работа е повторима и следователно подходяща за прехвърляне към система. Това е различен въпрос от дали правилата са правилни; това е въпросът колко от прилагането на тези правила трябва да остане човешка работа. Работният скан на FTE TO AI изчислява за всяка задача каква част от работата може да бъде поета от AI, и агрегацията — със своите фиксирани стъпки на събиране, тегловно изчисление и обединяване — е точно от типа задачи, при които резултатът често е изненадващ.
Data Readiness Scan на csrdready.net е в процес на разработка. Който вече сега иска да въведе ред в регистъра на данните точки и свързаните с него правила за агрегация, може да се запише в списъка на изчакване и ще бъде информиран веднага щом сканирането стане достъпно.
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.