IKT nozare atšķiras no nozarēm ar rūpnīcām, autoparkiem vai ēkām. Programmatūras uzņēmumam nav domnicu un parasti nav nozīmīga sava biroja ēkas. Tas nozari uz pirmo acu uzmetienu padara vieglu emisiju ziņā, tomēr ilgtspējas dati nav pazuduši — tie ir pārvietojušies. Tie neatrodas pašu aktīvos, bet gan piegādes ķēdē, mākoņpakalpojumu sniedzēju līgumos un aprīkojumā, ko izmanto darbinieki. Kas IKT nozarē skatās vien uz savu biroju, palaiž garām lielāko daļu stāsta.
Daudziem IKT uzņēmumiem klimata ietekmes uzsvars ir pārcēlies uz iepirkto skaitļošanas jaudu. Kas izmanto AWS, Azure, Google Cloud vai vietēju hostinga partneri, faktiski iepērk energopatēriņu, kas tiek ražots un uzskaitīts citur. Dati par to parasti neatrodas iekšējā sistēmā, bet gan rēķinos, pakalpojumu sniegšanas līgumos un ilgtspējas pārskatos, kurus paši mākoņpakalpojumu sniedzēji publicē. Daži pakalpojumu sniedzēji sniedz emisiju rādītājus par klientu vai darba slodzi, citi tikai vispārēju vidējo rādītāju. Atšķirība starp šiem diviem nosaka, cik precīzi uzņēmums var pamatot savu ar mākoni saistīto emisiju apjomu — un šī atšķirība reti ir zināma tam, kas pārskatu sastāda.
Otra vieta, kur uzkrājas ilgtspējas dati, ir aprīkojums: klēpjdatori, serveri, tīkla aprīkojums, telefoni. Šie dati rodas vairākos dzīves cikla brīžos. Iepirkuma laikā informācija par materiālu izmantošanu un ražošanas emisijām atrodas pie piegādātāja, bieži produkta pasē vai vides deklarācijā, kas standarti netiek pieprasīta. Lietošanas laikā IT pārvaldība rada datus par datu centru un serveru telpu energopatēriņu, dažreiz saimniecisko sistēmu ietvaros, dažreiz IT aktīvu pārvaldības rīkos, kas nekomunicē ar finanšu nodaļu. Nolietošanas brīdī rodas jauni dati: atkārtotas izmantošanas rādītāji, pārstrādes sertifikāti, līgumi ar elektronisko atkritumu pārstrādātājiem. Trīs fāzes, trīs veidu avoti, un reti ir viena vieta, kur tie sanāk kopā.
Uzņēmumiem, kas primāri piegādā programmatūru vai digitālos pakalpojumus, ir papildu sarežģītība: viņu produktam pašam nav fiziskas pēdas nospieduma, bet tas darbojas uz infrastruktūras, kurai tāds ir. Jautājums, kāda daļa no mākoņa emisijām ir attiecināma uz kādu produktu vai klientu, prasa alokācijas metodes, kas bieži vēl nav noteiktas. Kas par to sniedz pārskatu, vispirms jānoskaidro, kurš datu punkts veido pamatu — skaitļošanas jauda, datu glabāšana, datu plūsma — pirms kaut ko var mērīt. Tā ir metodoloģiska izvēle, kas nav atkarīga no pārskata, bet tam gan nāk pirms.
Tā kā nozare ir darbaspēka intensīva un tai ir relatīvi mazi fiziski aktīvi, ar personālu saistītie posteņi bieži sver vairāk nekā industriālajās nozarēs: mājas-darba ceļš, attālinātais darbs, darījumu braucieni, biroju ēku energopatēriņš, kas dažkārt tiek dalīts ar citiem nomniekiem. Šie dati ir izkaisīti pa HR sistēmām, ceļojumu rezervēšanas platformām, saimnieciskajiem pakalpojumu sniedzējiem un dažkārt izklājlapās, ko uztur atsevišķs darbinieks. Apjoms uz posteni ir mazs, bet avotu skaits ir liels, un tas padara konsolidāciju laikietilpīgāku, nekā apjoms liktu domāt.
Nozarēs, piemēram, būvniecībā vai nekustamo īpašumu nozarē, dati bieži ir koncentrēti nedaudzās fiziskās vietās vai projektos. IKT nozarē ir tieši pretēji: dati ir plāni izklāti pa daudziem maziem, digitāliem un uz līgumiem balstītiem avotiem. Tas prasa citu pieeju datu punktu reģistra izveidē — nesākt no ēkām vai iekārtām, bet gan no līgumiem, sistēmām un jautājuma, kurš organizācijā pārvalda kuru ķēdes posmu.
Arī IKT uzņēmumā ar vairākām biznesa vienībām — piemēram, atsevišķu mākoņpakalpojumu, konsultāciju un programmatūras nodaļu — atkārtojas tas pats jautājums: kādi datu punkti jums patiešām nepieciešami vairākās biznesa vienībās un kur organizācijā šis datu punkts jau eksistē. Pirms atkārtoti tiek prasīts par mākoņpakalpojumu patēriņu vai aparatūras inventāru, ir vērts pārbaudīt, vai šis rādītājs jau kaut kur tiek uzturēts, piemēram, izmantojot kur datu punkts jau eksistē vairākās biznesa vienībās. Tas novērš, ka katra vienība veido savu, nedaudz atšķirīgu versiju no tā paša skaitļa.
Kārdinājums sadrumstalotu datu gadījumā ir vispirms iegādāties rīku, kas visu padara pārskatāmu. Tomēr rīks, kas tiek uzstādīts uz nesakārtota procesa, galvenokārt sniedz glītāku pārskatu par skaitļiem, kas pamatā vēl nav korekti. Vispirms noskaidrot, no kurienes nāk katrs datu punkts, kas par to ir atbildīgs un kādi kvalitātes noteikumi tam attiecas, ir solis, kas nāk pirms sistēmas izvēles, nevis pēc tās.
Tiklīdz ir skaidrs, kādi datu punkti pastāv, no kurienes tie nāk un kurš tos pārvalda, rodas arī pārskats par to, cik daudz manuāla darba tiem apkārt joprojām ir: pārrakstīšana, pārbaude, informācijas meklēšana pie kolēģa. Tas ir tieši tāds darbs, par kuru FTE TO AI, izmantojot darba uzdevumu skenēšanu, aprēķina, kādu daļu var pārņemt AI, papildinot ieskatu, ko datu punktu reģistrs jau sniedz.
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.