Artykuł nr 29, Kategoria: Zarządzanie ryzykiem i decyzjami

Jak sprawdzić rekomendację przed zatwierdzeniem? Od danych do decyzji bez logicznych skrótów

Raport może zawierać prawidłowe dane.

Obliczenia mogą się zgadzać.

Źródła mogą być prawdziwe.

A rekomendacja nadal może być zbyt mocna.

To jeden z trudniejszych problemów w kontroli dokumentów.

Błąd nie zawsze znajduje się w:

liczbie;
formule;
przypisie;
dacie;
źródle.

Czasami pojawia się dopiero na ostatnim etapie:

między tym, co faktycznie wynika z dowodów, a tym, co autor rekomenduje zrobić.

Przykład:

„Wariant A uzyskał najniższy koszt w analizowanym scenariuszu.”

To może być poprawny wynik.

Ale czy wynika z niego:

„Należy wybrać wariant A”?

Niekoniecznie.

Być może wariant A:

ma największe ryzyko wdrożenia;
nie spełnia jednego wymagania krytycznego;
ma najdłuższy czas realizacji;
osiąga przewagę tylko przy jednym założeniu;
jest najmniej odporny na zmianę danych wejściowych.

Między:

EVIDENCE

RECOMMENDATION

istnieje więc jeszcze bardzo ważny obszar:

INFERENCE – sposób przejścia od dowodu do wniosku.

I właśnie ten fragment powinien być audytowany równie dokładnie jak same dane.

Prawidłowe dane nie gwarantują prawidłowej rekomendacji

Wyobraźmy sobie trzy zdania:

Fakt

System B kosztuje o 8% mniej niż system A.

Wniosek

System B jest korzystniejszy kosztowo.

Rekomendacja

Należy wdrożyć system B.

Pierwsze zdanie można zweryfikować na podstawie danych.

Drugie wymaga już interpretacji tego, co oznacza „korzystniejszy kosztowo”.

Trzecie wymaga znacznie więcej.

Trzeba wiedzieć również:

czy oba warianty zapewniają ten sam rezultat;
czy uwzględniono cały cykl życia;
jakie są ryzyka;
czy B spełnia wymagania krytyczne;
czy różnica 8% jest stabilna;
czy istnieją inne materialne kryteria.

Jedno zdanie rekomendacyjne może więc wymagać:

znacznie większej liczby dowodów niż zdanie opisujące pojedynczy fakt.

Najczęstszy skrót logiczny: „dane są prawdziwe, więc decyzja jest oczywista”

Nie jest.

Pomiędzy danymi a decyzją znajdują się:

kryteria;
założenia;
interpretacje;
alternatywy;
wartościowanie skutków;
ryzyko;
niepewność.

Właśnie dlatego evidence-based decision-making nie oznacza:

„znajdź dane i zrób to, co mówią”.

HakemZadeh i Rousseau opisują evidence-based decision-making jako korzystanie z najlepszych dostępnych dowodów pochodzących z wielu źródeł i zwracają uwagę, że rzeczywiste decyzje organizacyjne są zwykle wynikiem współpracy wielu osób dysponujących różnymi rodzajami wiedzy.

Eksperymentalne badania Criado-Perez i współautorów pokazują również, że sposób pozyskiwania i wykorzystywania dowodów oraz zdolność do refleksyjnego, a nie wyłącznie intuicyjnego przetwarzania informacji mają znaczenie dla trafności decyzji w zadaniach evidence-based management.

W praktyce oznacza to:

evidence jest podstawą osądu, ale nie zastępuje osądu.

Evidence-to-Decision Chain Expert Design

Do kontroli rekomendacji można zastosować autorski model:

QUESTION → OPTIONS → CLAIMS → EVIDENCE → INFERENCE → TRADE-OFF → RECOMMENDATION → CONDITIONS

To Evidence-to-Decision Chain Expert Design.

Nie jest to oficjalny standard IIA, GRADE ani ISO.

Jego celem jest znalezienie miejsc, w których rekomendacja:

wyprzedza dowód;
pomija alternatywę;
ukrywa założenie;
ignoruje kontrdowód;
zamienia prawdopodobieństwo w pewność;
przechodzi od jednego kryterium do całej decyzji.

ETAP 1. QUESTION – czy odpowiadamy na właściwe pytanie?

Zanim sprawdzimy rekomendację, trzeba wiedzieć:

jakie pytanie miała rozstrzygnąć analiza?

Przykład:

„Który system jest najtańszy?”

to nie to samo co:

„Który system powinniśmy wybrać?”

Pierwsze pytanie dotyczy:

kosztu.

Drugie może wymagać analizy:

kosztu;
bezpieczeństwa;
funkcjonalności;
czasu;
ryzyka;
dostawcy;
możliwości migracji.

Jeżeli analiza odpowiada na pierwsze pytanie, a rekomendacja na drugie:

pojawia się Question–Recommendation Gap.

Przykład Question–Recommendation Gap

Raport bada:

czas realizacji trzech wariantów.

Wynik:

wariant C jest najszybszy.

Rekomendacja:

wybrać wariant C.

Problem:

raport nie badał kosztu ani jakości.

Wniosek, który można obronić, brzmi:

„Jeżeli dominującym kryterium jest termin, wariant C ma przewagę.”

Nie:

„C jest najlepszym rozwiązaniem.”

Test pytania

Przed zatwierdzeniem rekomendacji warto zapytać:

Czy analiza rzeczywiście badała wszystkie kryteria konieczne do udzielenia odpowiedzi, którą teraz przedstawiamy?

Jeżeli nie:

rekomendacja powinna zostać:

zawężona;
warunkowa;
albo poprzedzona dodatkową analizą.

ETAP 2. OPTIONS – czy naprawdę przeanalizowaliśmy dostępne warianty?

Rekomendacja wymaga porównania.

Jeżeli istnieje tylko jeden wariant:

nie mamy jeszcze wyboru.

Mamy:

propozycję.

To nie zawsze jest problem.

Czasami istnieje tylko jedna realna opcja.

Ale trzeba to wykazać.

Najczęściej pomijana alternatywa: „nie robić nic”

Przykład:

Firma rozważa:

wdrożenie systemu A;
wdrożenie systemu B.

Raport porównuje oba.

Ale nie analizuje:

utrzymania obecnego systemu przez następne dwa lata.

Być może:

wariant 0

jest nieopłacalny.

Ale powinno to wynikać z analizy.

Nie z założenia.

Alternative Completeness Test

Sprawdzamy:

Czy istnieją realne alternatywy?
Czy każdą oceniono według tych samych kryteriów?
Czy uwzględniono status quo?
Czy nie stworzono sztucznie słabego wariantu tylko po to, aby preferowany wyglądał lepiej?
Czy wyjaśniono, dlaczego jakiś wariant został wykluczony?

Jeżeli rekomendacja wygrywa wyłącznie dlatego, że:

konkurencyjnych opcji nie przeanalizowano,

nie jest jeszcze mocną rekomendacją.

ETAP 3. CLAIMS – z jakich konkretnych twierdzeń zbudowana jest rekomendacja?

Zdanie:

„Rekomendujemy wariant B”

jest zbyt duże, aby audytować je jako pojedynczą jednostkę.

Trzeba je rozłożyć.

Na przykład:

C1

B ma najniższy koszt całkowity.

C2

B spełnia wszystkie wymagania krytyczne.

C3

B można wdrożyć w terminie.

C4

Ryzyka B są akceptowalne.

C5

B daje największą oczekiwaną wartość przy przyjętych kryteriach.

Dopiero teraz można pytać:

czy każdy claim jest prawdziwy?

Atomic Claim Test

Każdy claim powinien być:

możliwy do jednoznacznego zapisania;
możliwy do zweryfikowania;
powiązany z dowodem;
oddzielony od opinii.

Jeżeli jedno zdanie zawiera kilka twierdzeń:

rozbij je.

Przykład

Zdanie:

„Rozwiązanie jest tańsze, bezpieczniejsze i możliwe do szybszego wdrożenia.”

To trzy claims:

tańsze;
bezpieczniejsze;
szybsze.

Każdy może mieć:

inny status dowodowy.

Może się okazać:

koszt – VERIFIED;
bezpieczeństwo – PARTIAL;
termin – ASSUMPTION.

Rekomendacja wygląda wtedy zupełnie inaczej.

ETAP 4. EVIDENCE – czy dowody rzeczywiście wspierają claims?

To miejsce, w którym przydaje się Evidence Pack dla zarządu.

Dla każdego claimu tworzymy:

CLAIM → EVIDENCE

Przykład:

Claim	Dowód
B ma niższy TCO	model + oferty
B spełnia wymagania	macierz + POC
B wdrożymy w 9 miesięcy	harmonogram
ryzyko jest akceptowalne	risk assessment

Ale samo istnienie dowodu nie wystarcza.

Source ≠ Support

To jedna z najważniejszych zasad.

Raport może mieć:

przypis.

Ale przypis może:

nie potwierdzać dokładnie tej tezy;
dotyczyć innego okresu;
odnosić się do innej populacji;
zawierać znacznie słabszy wniosek.

Dlatego w artykule Weryfikacja źródeł w raporcie proponuję przejście od:

„źródło istnieje”

do:

„źródło rzeczywiście wspiera claim w takim zakresie, w jakim został zapisany”.

Evidence Strength powinno ograniczać Claim Strength

Jeżeli dowód mówi:

„wyniki sugerują możliwość poprawy”

rekomendacja nie powinna automatycznie mówić:

„wdrożenie na pewno przyniesie poprawę”.

Siła twierdzenia nie powinna być większa niż siła dowodu.

To prosta, ale niezwykle ważna zasada.

Claim Strength Ladder

Można wyróżnić:

LEVEL 1 – obserwacja

„W analizowanym okresie odnotowano…”

LEVEL 2 – zależność

„Wyniki wskazują na związek…”

LEVEL 3 – prawdopodobny wniosek

„Dostępne dowody wspierają…”

LEVEL 4 – silny wniosek

„Analiza potwierdza…”

LEVEL 5 – pewność

„Rozwiązanie zawsze / na pewno…”

Im wyżej:

tym mocniejszej podstawy potrzebujemy.

ETAP 5. INFERENCE – czy pomiędzy dowodem a wnioskiem nie ma logicznego skoku?

To serce całego audytu rekomendacji.

Przykład:

Evidence

72% ankietowanych preferuje rozwiązanie A.

Recommendation

należy wdrożyć A.

Czego brakuje?

Może:

kosztu;
reprezentatywności próby;
skutków dla pozostałych 28%;
technicznej wykonalności;
zgodności z wymaganiami.

Sam wynik ankiety nie musi wystarczać.

Evidence–Inference Gap

Pojawia się wtedy, gdy dowód jest prawdziwy, ale:

nie wystarcza do wniosku, który z niego wyprowadzono.

To jeden z najważniejszych rodzajów problemów w raportach.

Nie jest:

błędem źródła.

Nie jest:

błędem matematycznym.

Jest:

błędem przejścia między nimi a decyzją.

Test „dlatego”

Bardzo praktyczna metoda:

Połącz evidence z rekomendacją słowem:

„dlatego”.

Przykład:

„System B kosztuje o 8% mniej, dlatego należy go wybrać.”

Następnie zapytaj:

Czy część po słowie „dlatego” naprawdę wynika z części przed nim?

Jeżeli odpowiedź brzmi:

„tak, ale tylko jeśli…”

to właśnie znaleziono:

ukryty warunek.

Warunki powinny zostać ujawnione

Na przykład:

Rekomendujemy B, jeżeli:

zakres funkcjonalny jest równoważny;
koszt utrzymania został policzony poprawnie;
termin wdrożenia jest realny;
ryzyko migracji pozostaje akceptowalne.

To znacznie lepsza rekomendacja.

Bo pokazuje:

od czego zależy jej ważność.

ETAP 6. TRADE-OFF – czy rekomendacja uwzględnia to, co tracimy?

Prawie żadna poważna decyzja nie ma wariantu:

najlepszego we wszystkim.

Najczęściej jeden wariant:

jest tańszy;
ale wolniejszy.

Inny:

szybszy;
ale droższy.

Jeszcze inny:

bezpieczniejszy;
ale mniej elastyczny.

Dlatego rekomendacja musi ujawniać:

trade-offs.

Najbardziej niebezpieczna rekomendacja wygląda jak rozwiązanie bez kosztu alternatywnego

Jeżeli dokument mówi:

wariant B jest:

tańszy;
szybszy;
bezpieczniejszy;
prostszy;
bardziej elastyczny;
mniej ryzykowny;

warto szczególnie dokładnie sprawdzić:

czy wszystkie kryteria zostały zdefiniowane i zmierzone porównywalnie.

W realnych decyzjach całkowita dominacja jest możliwa.

Ale nie powinna być:

zakładana.

Trade-off Matrix

Kryterium	A	B	C
koszt	2	3	1
czas	3	2	1
bezpieczeństwo	2	3	3
elastyczność	3	2	2

Dopiero teraz możemy zapytać:

które kryteria są najważniejsze?

Wagi również są decyzją

Jeżeli raport przyjmuje:

koszt = 50%

bezpieczeństwo = 20%

to nie jest neutralny fakt.

To:

założenie wartościujące.

Zmiana wag może zmienić ranking.

Dlatego warto wykonać:

Weight Sensitivity Test

Przykład

Przy wadze kosztu 50%:

B wygrywa.

Przy wadze kosztu 30%:

A wygrywa.

Wniosek?

Nie:

„model jest błędny”.

Tylko:

rekomendacja jest wrażliwa na sposób wartościowania kryteriów.

To informacja, którą decydent powinien znać.

ETAP 7. RECOMMENDATION – czy język rekomendacji odpowiada sile dowodów?

Można rozróżnić kilka typów rekomendacji.

STRONG GO

„Rekomendujemy wybór B.”

CONDITIONAL GO

„Rekomendujemy B pod warunkiem…”

PREFERRED OPTION

„B ma obecnie najlepszy profil przy przyjętych kryteriach.”

NEED MORE EVIDENCE

„Nie ma obecnie wystarczającej podstawy do wyboru.”

HOLD

„Decyzję należy odroczyć do czasu wyjaśnienia…”

To znacznie bardziej precyzyjne niż wymuszanie:

TAK / NIE

dla każdego raportu.

Inspiracja: Evidence to Decision frameworks

Ciekawy punkt odniesienia stanowią opracowane przez GRADE Evidence to Decision frameworks.

Są one przeznaczone przede wszystkim do decyzji i rekomendacji w ochronie zdrowia oraz zdrowiu publicznym, więc nie należy traktować ich jako gotowego standardu audytu decyzji biznesowych.

Ich logika jest jednak bardzo wartościowa.

GRADE zwraca uwagę, że transparentne przejście od evidence do recommendation powinno obejmować nie tylko efekty, ale także takie kryteria jak:

pewność dowodów;
korzyści i szkody;
wykorzystanie zasobów;
wykonalność;
akceptowalność.

Framework ma jasno pokazywać zarówno dokonywane osądy, jak i dowody, które je wspierają.

Metodologiczny wniosek dla organizacji jest prosty:

rekomendacja powinna ujawniać kryteria, które doprowadziły do jej powstania.

ETAP 8. CONDITIONS – kiedy rekomendacja przestanie być aktualna?

To element często pomijany.

Raport mówi:

„rekomendujemy wariant B”.

Ale na jak długo?

Co jeśli:

cena wzrośnie o 20%;
wdrożenie opóźni się o pół roku;
zmieni się prawo;
test techniczny nie zostanie zaliczony;
pojawi się nowa oferta?

Dobra rekomendacja ma:

boundary conditions.

Recommendation Validity Envelope

To autorski element modelu.

Opisuje:

warunki, w których rekomendacja pozostaje ważna.

Przykład:

B jest rekomendowany, jeżeli:

CAPEX ≤ 20 mln zł;
wdrożenie ≤ 12 miesięcy;
test wydajności PASS;
wszystkie wymagania krytyczne spełnione;
koszt utrzymania nie przekracza X.

Jeżeli któryś warunek przestaje być prawdziwy:

należy ponownie ocenić decyzję.

Rekomendacja powinna mieć datę ważności logicznej, nawet jeśli nie ma formalnego terminu ważności

Nie chodzi o zapis:

„ważne do 31 grudnia”.

Chodzi o warunki.

Rekomendacja przygotowana w czerwcu może być nadal aktualna w grudniu.

Albo może stracić ważność dzień później, jeśli:

zmieni się kluczowa oferta.

Dlatego trzeba monitorować:

założenia krytyczne.

Recommendation Integrity Gate – 10 pytań przed zatwierdzeniem

Przed przekazaniem rekomendacji do zarządu warto zadać:

Czy pytanie decyzyjne zostało jednoznacznie zdefiniowane?
Czy przeanalizowano realne alternatywy?
Czy rekomendację rozbito na weryfikowalne claims?
Czy każdy materialny claim ma wystarczający dowód?
Czy siła claimu nie przekracza siły dowodu?
Czy pomiędzy evidence i wnioskiem nie ma ukrytego założenia?
Czy pokazano istotne kontrdowody?
Czy trade-offs są jawne?
Czy wynik jest odporny na rozsądną zmianę kluczowych założeń?
Czy wiadomo, kiedy rekomendację trzeba ponownie ocenić?

To Recommendation Integrity Gate Expert Design.

Jedno krytyczne „NIE” może być ważniejsze niż dziewięć odpowiedzi „TAK”.

Nie rób z Recommendation Integrity Gate kalkulatora

Nie oznacza to:

9/10 = 90% jakości rekomendacji.

Jeżeli jedynym brakującym elementem jest:

dowód na możliwość technicznego wdrożenia,

a rekomendacja dotyczy:

rozpoczęcia wdrożenia,

problem może być blokujący.

Dlatego zawsze potrzebna jest:

ocena materiality.

Kontrdowód nie jest problemem – jego brak może nim być

Silna analiza nie powinna eliminować informacji niewygodnych dla rekomendacji.

Powinna je:

ujawniać i oceniać.

Przykład:

Evidence FOR

B ma o 12% niższy TCO.

Evidence AGAINST

B ma najdłuższy czas migracji.

Final Judgment

Niższy TCO przeważa, ponieważ termin pozostaje wewnątrz dopuszczalnego limitu.

To jest:

przejrzysta argumentacja.

Znacznie silniejsza niż:

„B jest najlepszy”.

Contrary Evidence Test

Dla każdej rekomendacji HIGH zadaj:

Jaki jest najsilniejszy dowód przeciwko niej?

Jeżeli odpowiedź brzmi:

„nie ma żadnego”,

warto sprawdzić, czy rzeczywiście:

nie istnieje;

czy po prostu:

go nie szukano.

To bezpośrednio łączy się z confirmation bias

W artykule Dlaczego autor nie widzi własnych błędów? opisałem confirmation bias i anchoring.

Przy rekomendacji problem może wyglądać tak:

najpierw wybieramy wariant,

a potem:

szukamy argumentów.

Dlatego bezpieczniejszy proces to:

EVIDENCE FREEZE → OPTIONS ASSESSMENT → RECOMMENDATION

a nie:

RECOMMENDATION → EVIDENCE SEARCH

Recommendation-First Bias

To autorska nazwa bardzo prostego błędu procesowego:

rekomendacja istnieje wcześniej niż analiza.

Nie oznacza to automatycznie manipulacji.

Może się zdarzyć, że:

zarząd ma preferencję;
zespół już inwestował w jeden wariant;
rozwiązanie jest organizacyjnie wygodne.

Wtedy szczególnie ważny jest:

Independent Challenge.

Jak wykonać Independent Challenge rekomendacji?

Reviewer dostaje:

pytanie;
dane;
kryteria;
alternatywy.

Nie dostaje od razu:

preferowanego rozwiązania.

Najpierw tworzy własny wynik.

Dopiero później porównuje go z rekomendacją autora.

To pozwala sprawdzić:

czy oba procesy prowadzą w podobne miejsce.

Co jeśli dwa review prowadzą do dwóch różnych rekomendacji?

To nie musi oznaczać, że jeden jest błędny.

Trzeba sprawdzić:

czy użyto tych samych danych;
czy przyjęto te same kryteria;
czy nadano im te same wagi;
czy assumptions są identyczne;
czy różnie oceniono ryzyko.

Rozbieżność może ujawnić:

ukrytą decyzję wartościującą.

Przykład

Reviewer A:

rekomenduje system A.

Reviewer B:

system B.

Dlaczego?

A nadaje największą wagę:

czasowi wdrożenia.

całkowitemu kosztowi.

Problem nie znajduje się więc w danych.

Znajduje się w:

priorytetach decyzyjnych.

To powinien rozstrzygnąć decydent.

Rekomendacja nie powinna ukrywać decyzji wartościującej pod językiem „obiektywnej analizy”

To szczególnie ważne.

Zdanie:

„model jednoznacznie wskazuje B”

może w rzeczywistości oznaczać:

„B wygrywa przy wagach, które przyjęliśmy”.

Te dwie rzeczy nie są równoważne.

Lepszy zapis:

„Przy przyjętej wadze kosztu 40%, ryzyka 35% i czasu 25% wariant B uzyskuje najwyższy wynik.”

Teraz rekomendacja jest:

audytowalna.

Jak sprawdzić model punktowy?

Jeżeli rekomendacja wynika z scoringu:

sprawdź kryteria;
sprawdź skale;
sprawdź wagi;
sprawdź dane wejściowe;
przelicz wynik;
wykonaj sensitivity;
sprawdź, czy istnieją kryteria dyskwalifikujące.

To ostatnie jest szczególnie ważne.

Średnia punktów nie powinna ukrywać warunku krytycznego

Przykład:

System otrzymał:

92/100 punktów.

Ale nie spełnia:

jednego obowiązkowego wymagania bezpieczeństwa.

Średnia 92 może wyglądać znakomicie.

Rekomendacja nadal może być:

NO-GO.

Dlatego przed agregacją wyników trzeba rozróżnić:

Compensatory Criteria

słabszy wynik można zrównoważyć innym.

Non-Compensatory Criteria

niespełnienie powoduje eliminację.

To fundamentalna różnica.

Rekomendacja warunkowa bywa silniejsza niż „stanowcza”

Czasami autorzy obawiają się zdania:

„rekomendujemy, pod warunkiem że…”

bo wygląda mniej zdecydowanie.

W rzeczywistości może być bardziej profesjonalne.

Pokazuje:

świadomość ograniczeń;
związek rekomendacji z dowodami;
moment ponownej kontroli.

Na przykład:

„Rekomendujemy przejście do wdrożenia po potwierdzeniu wydajności w teście obciążeniowym.”

To jest jasne.

I wykonalne.

Kiedy rekomendacja jest za słaba?

Problem może działać również odwrotnie.

Dowody mogą jednoznacznie wskazywać:

istotne ryzyko.

A dokument mówi:

„warto rozważyć dalszą analizę”.

Jeżeli problem wymaga:

HOLD,

nadmiernie miękki język również może zniekształcać decyzję.

Dlatego Recommendation Audit powinien badać:

zgodność siły języka z siłą ustalenia

w obie strony.

Strong Evidence / Weak Recommendation Gap

Przykład:

krytyczne źródło danych jest błędne;
wynik finansowy nie daje się odtworzyć;
rekomendacja zależy od tego wyniku.

Dokument kończy:

„zaleca się zachowanie ostrożności”.

To może być zbyt słabe.

Bardziej adekwatne:

„Nie zatwierdzać decyzji do czasu odtworzenia wyniku.”

Recommendation Status Matrix

Evidence	Materiality	Możliwy status
mocne	niska niepewność	GO
mocne, ale warunek otwarty	wysoka	CONDITIONAL GO
mieszane	wysoka	FURTHER REVIEW
brak krytycznego dowodu	wysoka	HOLD
dowód przeczy rekomendacji	wysoka	NO-GO / REASSESS

To nie jest automatyczna tabela decyzyjna.

Pokazuje logikę.

Profesjonalny audyt nie powinien podejmować decyzji za zarząd

To ważne rozgraniczenie.

Audytor może ustalić:

rekomendacja nie wynika z przedstawionych dowodów.

Może wykazać:

wariant B wygrywa tylko przy określonych wagach.

Może powiedzieć:

wynik jest bardzo wrażliwy na założenie A1.

Ale pytanie:

czy organizacja akceptuje dane ryzyko

może pozostać decyzją zarządu.

Global Internal Audit Standards również rozróżniają findings, conclusions oraz recommendations

Aktualne Global Internal Audit Standards opisują prowadzenie prac audytowych jako proces obejmujący rozwijanie findings i conclusions oraz współpracę z managementem przy określaniu recommendations lub action plans odnoszących się do ustaleń.

Nie oznacza to, że każdy raport biznesowy jest raportem internal audit.

Wskazuje jednak na bardzo użyteczną zasadę:

ustalenie, wniosek i rekomendacja to różne warstwy procesu.

Nie powinny być mieszane w jedno zdanie.

Finding ≠ Recommendation

Przykład:

Finding

Koszt utrzymania nie został uwzględniony w TCO.

Conclusion

Ranking wariantów kosztowych nie jest obecnie wiarygodny.

Recommendation

Uzupełnić TCO i ponownie obliczyć ranking przed zatwierdzeniem wariantu.

To logiczny łańcuch.

Słaby zapis

„Brakuje kosztu utrzymania, dlatego należy wybrać wariant A.”

To logiczny skok.

Brak kosztu B może oznaczać:

nie możemy jeszcze wybrać.

Nie:

automatycznie wybieramy A.

Recommendation Traceability Matrix

Przy ważnych decyzjach warto przygotować:

ID	Claim	Evidence	Inference	Trade-off	Recommendation
R1	B tańszy	E1/E2	TCO niższy	wolniejszy	B warunkowo
R2	B bezpieczny	E3	spełnia minimum	brak peak test	test przed GO
R3	B terminowy	E4	plan wykonalny	mały bufor	monitoring

Taka tabela pokazuje:

gdzie dokładnie powstaje rekomendacja.

Recommendation Traceability różni się od Evidence Pack

Evidence Pack odpowiada:

jakie dowody stoją za decyzją?

Recommendation Traceability odpowiada bardziej precyzyjnie:

czy przejście od tych dowodów do konkretnej rekomendacji jest logicznie uzasadnione?

To kolejna warstwa kontroli.

Przykład: rekomendacja inwestycyjna

Raport mówi:

rekomendujemy budowę nowej linii.

Claim 1

popyt wzrośnie o 20%.

Evidence:

prognoza rynkowa.

Claim 2

wykorzystanie przekroczy 80%.

Evidence:

model wewnętrzny.

Claim 3

projekt wygeneruje dodatnie NPV.

Evidence:

model finansowy.

Ale sensitivity pokazuje:

przy wzroście popytu 12% NPV staje się ujemne.

Rekomendacja nie musi być błędna.

Ale powinna powiedzieć:

projekt jest silnie zależny od założenia wzrostu popytu.

Bez tego:

Recommendation Strength > Evidence Strength.

Przykład: rekomendacja dla zarządu

Raport:

„Należy zamknąć oddział X, ponieważ ma najniższą rentowność.”

Pytania:

Czy oddział obsługuje klientów strategicznych?
Czy jego zamknięcie zmieni rentowność innych oddziałów?
Jakie są koszty zamknięcia?
Czy niska rentowność jest trwała?
Jakie istnieją alternatywy?

Może się okazać:

fakt jest prawdziwy,

ale:

rekomendacja nadal przedwczesna.

Przykład: rekomendacja z raportu ankietowego

Badanie:

64% respondentów wybiera A.

Rekomendacja:

wdrożyć A.

Przed zatwierdzeniem trzeba sprawdzić m.in.:

próbę;
sposób doboru respondentów;
treść pytania;
brak odpowiedzi;
różnice między grupami;
znaczenie pozostałych kryteriów.

Wynik ankiety jest:

evidence.

Nie jest jeszcze:

decyzją.

Przykład: rekomendacja techniczna

Test:

system działa przy 5000 użytkowników.

Rekomendacja:

gotowy do produkcji.

Ale wymaganie:

15 000 użytkowników.

Test może być wykonany prawidłowo.

Wniosek:

nieuzasadniony.

To klasyczny:

Evidence–Decision Scope Mismatch.

Jak wykrywać logiczne skróty za pomocą pięciu słów?

Przy każdej rekomendacji zadawaj kolejno:

DLACZEGO?

Jaki claim ją wspiera?

SKĄD?

Jaki dowód wspiera claim?

CZYLI?

Czy wniosek naprawdę wynika z dowodu?

ALE?

Jaki jest najsilniejszy kontrargument?

JEŚLI?

Od jakiego warunku zależy rekomendacja?

Te pięć pytań potrafi bardzo szybko ujawnić słabe miejsce.

Test DLACZEGO → SKĄD → CZYLI → ALE → JEŚLI

Przykład:

Wybierz B.

DLACZEGO?

Bo ma najniższy TCO.

SKĄD?

Model kosztowy.

CZYLI?

Przy obecnych założeniach jest najtańszy.

ALE?

Ma większe ryzyko migracji.

JEŚLI?

Jeżeli migracja potrwa ponad 6 miesięcy, przewaga kosztowa znika.

Teraz rekomendacja może brzmieć:

„Rekomendujemy B pod warunkiem potwierdzenia planu migracji ≤6 miesięcy.”

To jest znacznie mocniejsze decyzyjnie.

Kiedy audyt rekomendacji powinien zakończyć się PASS?

Gdy:

pytanie jest zgodne z rekomendacją;
alternatywy są wystarczająco kompletne;
claims mają dowody;
dowody są aktualne i trafne;
inference jest jawna;
kontrdowody zostały rozważone;
trade-offs są widoczne;
sensitivity nie ujawnia krytycznej niestabilności albo jest ona ujawniona;
warunki rekomendacji są jasno opisane.

Nie oznacza to:

„decyzja na pewno okaże się najlepsza”.

Oznacza:

rekomendacja ma odtwarzalną i adekwatną podstawę.

Kiedy potrzebny jest HOLD?

Na przykład gdy:

brakuje dowodu dla kluczowego claimu;
analiza nie obejmuje realnej alternatywy;
rekomendacja zmienia się przy minimalnej zmianie assumption;
wynik zależy od niezatwierdzonego kryterium;
istnieje silny kontrdowód, którego dokument nie analizuje;
źródła wspierają znacznie słabszy wniosek niż finalna rekomendacja.

Wtedy warto zatrzymać:

zatwierdzenie.

Nie cały projekt.

Czasami potrzebna jest tylko korekta języka rekomendacji

Przykład:

Dokument mówi:

„analiza potwierdza, że rozwiązanie B jest optymalne”.

Dowody pokazują:

B ma najwyższy wynik w analizowanym modelu przy przyjętych wagach.

Możliwe rozwiązanie:

„Przy przyjętych kryteriach, wagach i danych wejściowych wariant B uzyskuje najwyższą ocenę.”

To drobna zmiana językowa.

Ale ogromna zmiana jakości epistemicznej dokumentu.

Nie usuwamy niepewności. Nazywamy ją

Profesjonalna rekomendacja może powiedzieć:

„dowody są niepełne”.

Może powiedzieć:

„wynik jest wrażliwy”.

Może powiedzieć:

„wariant B jest obecnie preferowany”.

To nie jest słabość.

To transparentność.

GRADE Evidence to Decision pokazuje na przykładzie decyzji zdrowotnych, że strukturyzowane przejście od evidence do recommendation powinno czynić osądy i ich podstawy jawnymi, zamiast ukrywać je pomiędzy źródłami a końcową konkluzją.

60-sekundowy Recommendation Check przed wysłaniem dokumentu

Weź ostatnią rekomendację i odpowiedz:

Jakie pytanie rozstrzyga?
Jakie były realne alternatywy?
Jakie trzy claims ją podtrzymują?
Jaki dowód potwierdza każdy claim?
Jakie assumption ma największy wpływ?
Jaki jest najsilniejszy argument przeciw?
Co tracimy, wybierając ten wariant?
Czy niewielka zmiana danych zmienia wynik?
Jakie warunki muszą pozostać prawdziwe?
Co powinno spowodować ponowną ocenę?

Jeżeli na jedno z pierwszych pięciu pytań odpowiedź brzmi:

„nie wiem”

rekomendacja prawdopodobnie nie jest jeszcze gotowa do zatwierdzenia.

Najczęstsze pytania

Czy rekomendacja może być błędna, jeśli wszystkie dane są poprawne?

Tak. Problem może znajdować się w przejściu od danych do wniosku, pominięciu alternatywy, założeniach albo sposobie ważenia kryteriów.

Czy rekomendacja zawsze musi wynikać jednoznacznie z danych?

Nie. Wiele decyzji wymaga profesjonalnego osądu i wartościowania. Ważne, aby te elementy były jawne.

Czy brak pewności oznacza, że nie można rekomendować?

Nie. Można stosować rekomendację warunkową i jasno opisać niepewność.

Czy GRADE można stosować bezpośrednio do decyzji biznesowych?

Nie jako gotowy standard. Evidence to Decision frameworks zostały opracowane dla rekomendacji i decyzji przede wszystkim w ochronie zdrowia i zdrowiu publicznym. Ich zasady przejrzystości i jawnego przejścia od evidence do judgment stanowią jednak wartościowy punkt odniesienia.

Czy wysoki wynik w modelu punktowym wystarcza do rekomendacji?

Nie zawsze. Trzeba sprawdzić kryteria, wagi, sensitivity oraz ewentualne wymagania dyskwalifikujące.

Czy audytor powinien sam wskazać, jaki wariant wybrać?

Zależy od zakresu zlecenia. Audyt może weryfikować podstawę rekomendacji i wskazywać jej ograniczenia bez przejmowania odpowiedzialności decyzyjnej zarządu.

Czy Evidence-to-Decision Chain jest oficjalnym standardem?

Nie. To autorski model Expert Design służący do kontroli logicznego przejścia od pytania i dowodu do rekomendacji.

Rekomendacja jest dobra nie wtedy, gdy brzmi zdecydowanie, lecz wtedy, gdy można odtworzyć drogę prowadzącą do niej

To najważniejszy wniosek.

Nie wystarczy:

DATA → RECOMMENDATION

Pomiędzy nimi powinien istnieć kontrolowany łańcuch:

QUESTION → OPTIONS → CLAIMS → EVIDENCE → INFERENCE → TRADE-OFF → RECOMMENDATION → CONDITIONS

To właśnie Evidence-to-Decision Chain Expert Design.

Jeżeli któryś element znika, powstaje ryzyko logicznego skrótu.

Dlatego przed zatwierdzeniem raportu warto wykonać prosty test:

Czy osoba, która nie uczestniczyła w przygotowaniu analizy, może przejść od rekomendacji wstecz do danych i zrozumieć każdy krok rozumowania?

Jeżeli tak:

mamy ślad decyzyjny.

Jeżeli nie:

prawdopodobnie istnieje Evidence–Inference Gap, ukryte assumption albo nieujawniony trade-off.

Przy decyzjach wysokiej wartości często nie potrzeba kolejnego pełnego audytu wszystkich 300 stron.

Można przeprowadzić:

Recommendation Integrity Review

obejmujący:

kluczowe claims;
dowody;
assumptions;
kontrdowody;
trade-offs;
sensitivity;
warunki finalnej rekomendacji.

A jeżeli problem znajduje się wcześniej, w samych źródłach, warto zacząć od weryfikacji źródeł i dowodów.

Jeżeli natomiast raport jest już gotowy do wysłania, ostatnią warstwą może być audyt raportu przed przekazaniem zarządowi lub klientowi.

Opisz rekomendację lub raport do niezależnej weryfikacji

Źródła i podstawa merytoryczna

HakemZadeh F., Rousseau D.M., Evidence-based decision-making is a social endeavor, Behavioral Science & Policy, 2024 – publikacja dotycząca evidence-based decision-making jako procesu wykorzystującego najlepsze dostępne dowody z wielu źródeł i angażującego różne osoby oraz kompetencje w organizacji.

Criado-Perez C. i wsp., Cognitive Reflection and Decision-Making Accuracy: Examining Their Relation and Boundary Conditions in the Context of Evidence-based Management, Journal of Business and Psychology, 2024 – trzy badania eksperymentalne dotyczące związku między refleksyjnością poznawczą, pozyskiwaniem dowodów i trafnością decyzji oraz wpływu obciążenia poznawczego i emocjonalnego.

Criado-Perez C., Jackson C., Collins C.G., Evidence collection and use when making management decisions, Applied Psychology, 2024 – badania eksperymentalne dotyczące czynników wpływających na zbieranie i wykorzystanie dowodów w ramach evidence-based management.

Alonso-Coello P. i wsp., GRADE Evidence to Decision frameworks: a systematic and transparent approach to making well informed healthcare choices, BMJ, 2016 – opracowanie opisujące transparentne przejście od pytania i dowodów przez ocenę kryteriów do rekomendacji lub decyzji. Framework dotyczy przede wszystkim ochrony zdrowia i w niniejszym artykule stanowi punkt odniesienia metodologicznego, a nie gotowy standard decyzji biznesowych.

The Institute of Internal Auditors, Global Internal Audit Standards, 2024 – aktualne standardy internal audit rozróżniają proces tworzenia findings i conclusions od recommendations lub action plans oraz wymagają efektywnego planowania, prowadzenia i komunikowania wyników prac audytowych. W artykule stanowią punkt odniesienia procesowego, a nie normę dla wszystkich decyzji zarządczych.

Dane SEO

1. Meta title: Jak sprawdzić rekomendację przed zatwierdzeniem?

2. Meta opis: Jak sprawdzić, czy rekomendacja naprawdę wynika z danych? Poznaj Evidence-to-Decision Chain, kontrdowody i test warunków.

3. Tagi: weryfikacja rekomendacji, rekomendacja dla zarządu, Evidence-to-Decision Chain, podejmowanie decyzji, evidence based management, audyt raportu, analiza rekomendacji, decyzje zarządcze, kontrdowody

4. Fraza kluczowa: weryfikacja rekomendacji

5. Uproszczona nazwa: weryfikacja-rekomendacji