Proof of Concept (PoC) - dowód koncepcji - to mała, ograniczona w czasie weryfikacja, czy coś jest w ogóle wykonalne: czy technologia działa, czy systemy da się zintegrować, czy pomysł nie rozbija się o twardą ścianę. PoC odpowiada na pytanie "czy się da?", celowo ignorując jakość produkcyjną, skalowalność i opłacalność.
Analityk spotyka PoC przed decyzjami inwestycyjnymi i przy wymaganiach obarczonych ryzykiem technicznym. Jego rola jest konkretna: sformułować pytanie, na które PoC ma odpowiedzieć, i kryteria sukcesu - zanim ktokolwiek zacznie kodować. PoC bez pytania to po prostu dwutygodniowa zabawa technologią.
Przykład (MediFlow). Największe ryzyko projektu e-rejestracji: czy API systemu gabinetowego, używanego przez 12 przychodni, pozwala rezerwować sloty w czasie rzeczywistym? PoC: dwa tygodnie, jeden programista, jedno pytanie, kryterium sukcesu - rezerwacja widoczna w grafiku lekarza w mniej niż 5 sekund. Wynik: da się, ale API ma limit 10 zapytań na sekundę, co przy porannym szczycie będzie za mało. Wniosek wchodzi do wymagań jako konieczność kolejkowania żądań. Koszt wiedzy: dwa tygodnie. Koszt tej samej wiedzy odkrytej na produkcji: nie do policzenia przy okienku z kolejką pacjentów.
Częsta pomyłka. PoC bez zdefiniowanego kryterium sukcesu ("zróbmy PoC i zobaczymy") - po dwóch tygodniach nikt nie umie powiedzieć, czy wynik jest dobry. Druga, plaga branży: wdrażanie kodu z PoC na produkcję, bo "przecież działa". PoC z definicji pomija bezpieczeństwo, obsługę błędów i skalę - to szkic, nie budynek. Trzecia: mylenie PoC z pilotażem i z Proof of Value; PoC sprawdza wykonalność, PoV - czy rozwiązanie przynosi mierzalną korzyść.