Potwierdzanie i obalanie hipotez to dla zespołu rozwojowego jedno ze źródeł pozyskiwania (ale i tworzenia) wiedzy. Źródła te można podzielić na wewnętrzne i zewnętrzne. Pierwsze to dorobek firmy. Skapitalizowana wiedza, wyniki testów zrealizowanych podczas już zakończonych projektów, wiedza o aplikacjach – do których firma dostarcza rozwijane i wytwarzane produkty. 

Źródła zewnętrzne to potencjalni klienci, nieznani do tej pory dostawcy, instytuty, uczelnie, zewnętrzne laboratoria, firmy konsultingowe, bazy danych o patentach…

Źródła wewnętrzne to z reguły wystarczający zasób wiedzy, dla zespołów które są zaangażowane w dwa typy projektów: dostarczenie zdefiniowanej funkcji przez Klienta, poprzez zbiór specyfikacji, które z jednej strony prowadzą zespół projektowy w kierunku finalnego produktu oraz sposobu testowania performance’u. Z drugiej jednak, są znacznym ograniczeniem kreatywności oraz swobody decyzyjnej, ponieważ każdą z nich musi zatwierdzić Klient. Drugi rodzaj projektów to innowacje przyrostowe. 

W zilustrowaniu kolejnych typów projektów, dla których wewnętrzne źródła wiedzy są absolutnie niewystarczające, przywołam znany podział projektów innowacyjnych.

Przedstawia on 4 rodzaje projektów innowacyjnych (Przyrostowe, Architektoniczne, Radykalne i Przełomowe), na które firma może się zdecydować. Każdy z nich definiują dwa parametry, przedstawione na osiach – Rynek oraz Technologia. Chcąc przyporządkować typ projektu do jednego z wykresu, możemy przyjąć punkt widzenia konkretnej firmy. Oznacza to, że projekt o tym samym zakresie i celach, dla jednej firmy może być np. projektem przyrostowym, a dla innej radykalnym. W takim przypadku możemy mówić o subiektywnym charakterze przyporządkowania. Możemy rownież przyjąć perspektywę wszystkich znanych nam podmiotów na rynku i w ten sposób określić rodzaj projektu. Wtedy przyporządkowanie będzie bardziej obiektywne, ale również trudniejsze do oceny wysiłku, jaki firma musi zainwestować w jego realizację. 

Dla potrzeb tego artykułu przyjmę podejście subiektywne, czyli opisujące perspektywę konkretnej firmy (nie całego rynku). 

Każdy parametr może przyjąć dwie wartości – „znany” oraz „nieznany”.

Rynek z punktu widzenia każdej firmy może być „znany” lub „nieznany”. „Znany” to ten, na którym firma  już funkcjonowała lub/i funkcjonuje nadal. To lista Klientów, do których obecnie dostarcza produkty lub/i usługi. To również dobre zrozumienie potrzeb oraz problemów obecnych Klientów. „Nieznany” rynek to cała jego pozostała część. 

Technologia podobnie, może być „znana”, tzn. firma rozumie i posiada technologię, którą wykorzystuje w procesach tworzenia produktów lub/i usług. Zatrudnia personel, który w sposób świadomy utrzymuje ją na poziomie aktualnie znanych na rynku standardów. Technologia może również być „nieznana”, co oznacza, że firma nie ma obecnie żadnych wewnętrznych ani zewnętrzych zasobów, które pozwalają na jej użycie. 

Teraz mogę przejść do projektów które bezwzględnie potrzebują zewnętrznych źródeł pozyskiwania wiedzy. Jak łatwo się domyślić, każdy projekt dla którego przynajmniej jeden z powyższych parametrów, przyjmuje wartość „nieznany” jest takim właśnie projektem. Innowacje, dla których oba parametry są nieznane – tzw. przełomowe – są najbardziej wymagającymi i trudnymi, ponieważ w ich przypadku firma musi pozyskać / uzupełnić wiedzę zarówno w obszarze technologii, jak również potencjalnych Klientów i ich aplikacji (w rozumieniu produktu i usług). W porównaniu do innowacji (projektów) przyrostowych, również te nazwane jako architektoniczne i radykalne są tymi, które potrzebują zewnętrznych źródeł wiedzy. Nie wchodząc w szczegóły, w jaki sposób można nawiązać relacje z potencjalnymi Klientami i dostawcami na bardzo wczesnych etapach rozwoju – a jest to często proces długi i wymagający bliskiej współpracy działów R&D, Marketingu i Sprzedaży – przejdę do istoty tego artykułu. 

Załóżmy, że mamy już wypracowane i zdefiniowane kanały pozyskiwania wiedzy. Zdobyliśmy i zdobywamy kolejne informacje z zakresu aplikacji, do której planujemy dostarczać w przyszłości jakiś produkt lub usługę. Często informacje te będą szczątkowe, niespójne lub wzajemnie się wykluczające. Co w takiej sytuacji, może zrobić zespół projektowy? Może skorzystać z trójkąta weryfikacji hipotez.

Jak sama nazwa wskazuje, model ten ma trzy etapy, które tworzą wierzchołki tytułowego trójkąta. 

Są to kolejno: wstępne obliczenia, analiza numeryczna, (fizyczny) test weryfikacyjny. Te trzy etapy poprzedza zdefiniowanie hipotezy, która finalnie będzie potwierdzona lub obalona. 

Warto w tym miejscu zarysować sytuację zespołu projektowego pracującego nad innowacją architektoniczną, a w szczególności radykalną lub przełomową. Pracują nad produktem (lub usługą), które nie istnieją w portfolio(katalogu produktów) ich firmy. To nad czym pracują najprawdopodobniej nie będzie podobne do niczego, co w tym portfolio już się znajduje. Wszelkie przetarte wcześniej drogi kalkulacji i szacowania parametrów użytkowych (performance-u) nie działają. Nie wiadomo co i jak testować – przecież to produkt będący częścią aplikacji, której jeszcze nie rozumieją. W momencie określenia wielkości fizycznej, którą planują przetestować fizycznie, okazuje się, że w laboratorium nie ma takich urządzeń, a zewnętrzni dostawcy oczekują sprecyzowania procedury testowej. Komponenty i materiały potrzebne do zbudowania pierwszych prototypów są niedostępne w portfolio obecnych dostawców, muszą znaleźć nowych – którzy też oczekują specyfikacji tego co chcemy zamówić – a ich brak. Krótko mówiąc, obszar niewiedzy oraz zagadnień, które trzeba zdefiniować i przygotować do weryfikacji kolejnych hipotez są ogromne. To codzienne wyzwania, przed którymi stoją zespoły R&D pracujące nad wspomnianymi wcześniej projektami innowacyjnymi.

Dlatego tak istotne jest, aby kolejne hipotezy były weryfikowane w sposób usystematyzowany, który pomoże zapewnić efektywne wykorzystanie zasobów przy jednoczesnym kapitalizowaniu wiedzy.

Każdy z trzech etapów ma charakter iteracyjny (powtarzających się pętli – patrz rysunek powyżej). Ilość powtórzeń zależy od decyzji zespołu. Jeżeli dochodzą do wniosku, że kolejnym etapem powinien być test – planują wykonanie testu. Jeżeli decydują o konieczności zbudowania modelu numerycznego w celu weryfikacji hipotezy – planują co jest niezbędne do jego wykonania. 

Istotą trójkąta weryfikacji hipotez jest porównywanie wyników jakie generują jego kolejne wierzchołki. 

Zespół na początku projektu powinien ustalić (jeżeli nie ma takiego ustalenia na poziomie globalnym) jaki poziom korelacji (wzajemnego powiązania) pomiędzy poszczególnymi etapami będzie uznany za wystarczający, pozwalający na podjęcie decyzji o potwierdzeniu lub obaleniu hipotezy. Nieosiągnięcie tego poziomu pomiędzy wszystkimi etapami  będzie skutkowało koniecznością powrotu do każdego z nich i zastanowieniu się, dlaczego korelacja nie osiągnęła oczekiwanego poziomu. 

Tylko osiągnięcie wystarczającego poziomu korelacji pozwala na użycie uzyskanych wyników w kolejnych krokach projektowych. Uzyskanie takiego poziomu zespół traktuje jako potwierdzenie, że to co obliczyli, zweryfikowali w analizie numerycznej oraz przetestowali fizycznie jest spójne. W ten sposób potwierdzają, że zbudowali „fragment” nowej wiedzy, który mogą wykorzystać w bieżącym lub przyszłym projekcie. Odrzucają w ten sposób metody testowe, modele FEA oraz wyniki, które ze względu na brak korelacji mogłyby być całkowicie mylące i prowadzić do fałszywych wniosków. Te z kolei do błędnych decyzji i w konsekwencji zbudowania produktu, który nie spełnia celów projektowych, i co najważniejsze – oczekiwań potencjalnych klientów. 

W idealnej sytuacji wszystkie trzy „wierzchołki” powinny osiągnąć wystarczający poziom korelacji. Dopuszczam jednak uproszczenie polegające na korelacji dwóch „wierzchołków” – pod jednym warunkiem, że jednym z tych etapów jest fizyczny test weryfikacyjny. Jest to szczególnie uzasadnione w przypadkach, w których wstępne obliczenia lub analiza numeryczna z punktu widzenia dostępnej wiedzy, umiejętności, posiadanych narzędzi (licencji) jest praktycznie niemożliwa do wykonania. W takich sytuacjach konieczne byłyby znaczące uproszczenia, te z kolei mogłyby być źródłem dużych rozbieżności. 

Uproszczenia budowania nowej wiedzy, polegające na bazowaniu na wynikach tylko jednego etapu (wierzchołka) są bardzo niebezpieczne, ze względu na bardzo dużą niepewność jakimi są obarczone. Z zasady powinny być odrzucane przez szefa projektu lub zweryfikowane drugim, innym „wierzchołkiem trójkąta”. 

Wyzwania związane ze stosowaniem tego modelu:

• Umiejętność formułowania hipotez, które przybliżają zespół do celu projektowego – błędnie postawiona hipoteza może prowadzić do błędnych wniosków, dlatego warto na tym etapie zweryfikować treść hipotezy z szerokim zespołem projektowym. 
• Systematyczność i wytrwałość w obliczu dostępnego czasu w projekcie – może pojawiać się pokusa do pójścia drogą „na skrót” i nie używania tego modelu, szczególnie w sytuacji, kiedy dostępne zasoby są mocno ograniczone. Nie twierdzę, że nie można tak postąpić. Ważne jest, aby była to decyzja całego zespołu (core team-u) w oparciu o transparentne i obrazowe przedstawienie ryzyk jakie z taką decyzją się łączą.
• Konsekwencja – czasem można napotkać na „opór” zespołu, który nie widzi wartości dodanej w potwierdzeniu uzyskanych wyników z jednego „wierzchołka” kolejnym testem. To co może zapobiec takiej sytuacji, to określenie sposobu pracy przy weryfikacji hipotez na początku projektu przez szefa projektu. 
• Wybór 1, 2 lub 3 wierzchołkowego modelu – podobnie jak w poprzednich wyzwaniach, mogą z różnych stron pojawiać się „sugestie” minimalizacji użycia modelu. Uważam, że to szef projektu powinien podejmować ostateczną decyzję. Może i powinien ją konsultować, ale to jego decyzja powinna być wiążąca – to on ma najlepszy ogląd na wszystkie prowadzone akcje w projekcie, które finalnie prowadzą do minimalizacji ryzyk. 

Model ten może być stosowany w ramach każdej aktywności działu R&D. Biorąc jednak pod uwagę specyfikę radykalnych i przełomowych projektów innowacyjnych uważam, że jest to niezbędne narzędzie, które powinien wykorzystywać każdy szef projektu. Gdzie celem projektu jest nie tylko dostarczenie nowego produktu do portfolio ale również zdobycie i skapitalizowanie wiedzy, która będzie niezbędna na poźniejszych etapach akwizycji i produkcji seryjnej.