Nałożenie oprogramowania do danych na zepsuty proces daje tylko ładniejsze raporty, podczas gdy liczby pod spodem pozostają niewiarygodne

Najpierw zbudujcie rejestr punktów danych, następnie zaprojektujcie proces od źródła do raportu dla każdego punktu danych ze spójnymi definicjami między jednostkami, zamiast pozwalać każdej jednostce niezależnie rozwijać własną metodę zbierania. Niespójne definicje między jednostkami są często niewidoczne, dopóki ktoś nie spróbuje zsumować liczb na poziomie grupy, gdy wynikowa suma po cichu łączy liczby, które nigdy faktycznie nie mierzyły tego samego.

Najpierw napraw proces, własność, definicje, kontrole, zanim wprowadzicie jakiekolwiek narzędzie; narzędzie na wierzchu zepsutego procesu produkuje tylko czystsze niewiarygodne raporty, które wyglądają bardziej wiarygodnie, niż są. Arkusze kalkulacyjne właściwie nie są problemem; problemem jest brak jasnej własności, spójnych definicji i jakiejkolwiek kontroli nad tym, co liczy się jako ważna liczba, i żadne oprogramowanie tego samo nie rozwiąże.

Zaprojektujcie każdy proces zbierania z kontrolami, agregacją, normalizacją, obliczeniami i standaryzacją, tak by każda liczba była śledzalna do źródła, zamiast wchodzić do końcowego raportu jako niewyjaśniona liczba, której nikt nie może obronić, jeśli zostanie zakwestionowana. Weryfikowalny proces jest bardzo podobny do tego, jak finanse już zarządzają danymi finansowymi, ta sama dyscyplina tylko tradycyjnie nie była stosowana do danych o zrównoważonym rozwoju, dokładnie tę lukę wypełnia to podejście.

Dokumentowanie, dla każdego punktu danych, skąd pochodzi, jakie przetwarzanie przechodzi, i gdzie ląduje w końcowym raporcie, tak by cała droga od surowego źródła do opublikowanej liczby była wyraźna i weryfikowalna, zamiast czegoś, co naprawdę rozumie tylko jedna osoba w organizacji. Bez tego mapowania liczba w końcowym raporcie jest praktycznie czarną skrzynką, której nikt nie może niezależnie zweryfikować ani zrekonstruować, jeśli zostanie zakwestionowana.

Przypiszcie RACI dla każdego punktu danych i procesu, własność definicji po stronie zrównoważonego rozwoju, własność procesu i kontroli po stronie finansów, zamiast pozostawiać własność domyślną i zakładać, że ktoś naturalnie ją przejmie. Dane o zrównoważonym rozwoju mają szczególną tendencję do pozostawania bez właściciela, ponieważ wpadają między działy, z których każdy zakłada, że odpowiedzialny jest ten drugi, dokładnie temu ma zapobiec wyraźne RACI.

Ustalcie, które punkty danych faktycznie wymagają wasze istotne tematy i standard raportowania, i zarejestrujcie, co już istnieje, względem tego, co trzeba zbudować, zamiast próbować zebrać każdy możliwy punkt danych, na który standard teoretycznie pozwala. Rejestr ograniczony do faktycznej potrzeby, oparty na waszych konkretnych istotnych tematach, jest ułamkiem rozmiaru tego zbudowanego, by pokryć każde możliwe ujawnienie bez uwzględniania jego istotności.

Znormalizujcie definicję w fazie rejestru punktów danych, zanim zaprojektujecie jakikolwiek proces zbierania, ponieważ próba pogodzenia niespójnych definicji, gdy każda jednostka już zbudowała swój własny proces, jest znacznie bardziej zakłócająca. Wczesne uzgodnienie wspólnej definicji, choć zajmuje więcej czasu na początku, unika znacznie wyższego kosztu demontowania niekompatybilnych procesów później.

Zdefiniujcie, jak wygląda ważna wartość dla każdego punktu danych, i jakie odchylenie wywołuje alert, ta sama dyscyplina, jaką mają już dane finansowe, rozszerzona na dane o zrównoważonym rozwoju, historycznie zbierane ze znacznie mniejszą rygorystycznością. Ramy kontroli nie muszą być rozbudowane, by być skuteczne; muszą określać, dla każdego punktu danych, jak wygląda prawdopodobny zakres i co się dzieje, gdy liczba wypada poza niego.

Upewnijcie się, że każda liczba ma śledzalne źródło i wyznaczonego właściciela od pierwszego dnia, jej rekonstrukcja później jest znacznie droższa, zwłaszcza gdy osoba, która pierwotnie skompilowała liczbę, zmieniła rolę lub całkowicie opuściła organizację. Dostawcy zapewnienia szczególnie szukają tego rodzaju śledzalności, a jej brak jest jednym z najczęstszych powodów, dla których raport o zrównoważonym rozwoju nie otrzymuje czystej opinii zapewnienia.

Najpierw naprawcie proces. Wymagania funkcjonalne narzędzia powinny pochodzić z zaprojektowanego procesu, nie odwrotnie, ponieważ wybór oprogramowania, zanim proces istnieje, oznacza zgadywanie wymagań zamiast definiowania ich na podstawie rzeczywistego, przetestowanego sposobu pracy. Narzędzia wybrane w ten sposób często okazują się brakować zdolności, których proces faktycznie potrzebuje, lub zawierają długą listę funkcji, których proces nigdy nie używa.

Zdefiniujcie wymagania funkcjonalne na podstawie zaprojektowanego procesu zbierania, następnie przeprowadźcie selekcję, nigdy przed istnieniem procesu, ponieważ demo dostawcy jest znacznie bardziej przekonujące niż jasna ocena tego, czego wasze konkretne zbieranie danych faktycznie potrzebuje. Wymagania zdefiniowane na podstawie rzeczywistego procesu są zazwyczaj bardziej konkretne i użyteczne podczas oceny dostawców niż generyczna lista funkcji skopiowana z raportu branżowego.

Własność definicji należy do zrównoważonego rozwoju; własność procesu i kontroli należy do finansów, które już mają do tego systemy i dyscyplinę, ponieważ finanse spędziły dekady budując rygorystyczność, którą raportowanie o zrównoważonym rozwoju musi teraz osiągnąć. Ten podział unika częstego błędu, gdzie zrównoważony rozwój posiada zarówno definicje, jak i proces, bez systemów, które finanse już mają, by niezawodnie prowadzić ten proces na dużą skalę.

Użyjcie tego samego rejestru punktów danych i projektu procesu jako szablonu, dostosowanego dla każdej jednostki, ale nigdy redefiniowanego dla każdej jednostki, tak by agregacja na poziomie grupy pozostała sensowna zamiast mozaiki lokalnie na nowo wymyślonych podejść. Dostosowanie do lokalnego kontekstu jest w porządku i często konieczne; redefiniowanie samego punktu danych czy jego definicji lokalnie jest tym, co niszczy porównywalność na poziomie grupy.

Tygodnie dla jednego tematu; w pełni wdrożony program na poziomie grupy z zarządzaniem mierzy się w kwartałach, napędzany głównie liczbą zaangażowanych jednostek i stron bardziej niż techniczną złożonością samych danych. Harmonogram skaluje się znacznie bardziej z koordynacją organizacyjną niż z trudnością samego pomiaru, więc projekt pilotażowy na jednym temacie może posuwać się znacznie szybciej niż pełne wdrożenie.

Utrzymujcie mapowanie od źródła do raportu i ramy kontroli jako samą dokumentację, zbudowaną gotową do audytu od projektu, zamiast traktować dokumentację jako osobne zadanie do ukończenia, gdy proces już trwa. Dodawanie dokumentacji później do już istniejącego procesu jest zazwyczaj wolniejsze i mniej precyzyjne niż budowanie dokumentacji jako naturalnego produktu ubocznego dobrego projektu procesu od początku.