NIH i LRTW

Dobrze znane i opisane dwa tytułowe „syndromy”, w pewnych sytuacjach okazują się być antywzorcami a w innych już nie koniecznie. Dualność ta jest wysoce zastanawiająca. Jak to możliwe? Od czego to zależy?

Syndrom NIH (Not Invented Here) polega na zauważalnej niechęci w organizacjach do używania, korzystania z rozwiązań, koncepcji które powstały poza tymi organizacjami. Organizacje chcą być dumne z tego co tworzą, nie chcą powielać wyłącznie rozwiązań które stworzył ktoś inny. Organizacje chcą budować tożsamość na własnych rozwiązaniach, tożsamość tą biznesową ale także społeczną świadomość przynależności do czegoś wartościowego. Dokładnie tak samo wygląda to z punktu widzenia członków takich organizacji. Chcemy uczestniczyć w czymś co jest innowacyjne, kreatywne, a nie tylko odtwórcze.

Syndrom LRTW (Let’s Reinvent The Wheel) to skłonność do podejmowania decyzji stworzenia na nowo tego, co wydaje się już jest stworzone, dobrze znane i sprawdzone. Co popycha organizacje, czy nas samych, do takich działań? Zazwyczaj nadzieja i wiara, że to co zrobimy będzie lepsze niż to co wymyślono wcześniej. A gdyby tak się stało, otwiera to drogę do sukcesu organizacyjnego, osobistego poczucia dumy, spełnienia się czy realizacji ambicji. Aby to zobrazować, wyobraźmy sobie co myśleli i co czuli twórcy WhatsApp’a kiedy świadomi istnienia co najmniej kilku komunikatorów z ugruntowaną pozycją rynkową, gdzie wszystkie karty wydały się już rozdane, pomimo to, podjęli decyzję o stworzeniu kolejnego. Czy wymyślali koło na nowo? Niekonieczne. A czy dzisiaj próba wprowadzenia na rynek kolejnego komunikatora miała by szanse powodzenia? Czas pokaże.

Kiedy zatem warto unikać tych syndromów a kiedy nie? Zacznijmy od przeanalizowania możliwych strategii w sytuacji wystąpienia u nas pewnej potrzeby lub odkrycia potrzeby rynkowej.

Użycie – znamy lub jesteśmy w stanie poznać gotowe, istniejące rozwiązanie. Aplikujemy je w sposób domyślny, zalecany, ew dostosowujemy się (procesy w naszej organizacji) do wzorców które zaleca to rozwiązanie, uznając, że ma ono w sobie dużą wartość wiedzy nabytej na drodze stawania się rozwiązaniem rynkowo uznanym i dojrzałym. Przykład: użycie usługi Gmail do obsługi poczty firmowej.

Adaptacja – tu także znamy lub jesteśmy w stanie poznać gotowe, istniejące rozwiązanie. Jednak w trakcie procesu aplikacji, korzystając zazwyczaj z dostępnych w rozwiązaniu możliwości adaptacyjnych, staramy się „nauczyć” rozwiązanie naszej specyfiki, zaadaptować je tak aby spełniało nasze wymagania. Proces adaptacji może przyjąć różne formy, w branży IT zazwyczaj nazywamy go wdrożeniem. Przykład: wdrożenie JIRA’y do obsługi działu HotLine w firmie IT.

Kompozycja – w tym podejściu analogicznie jak poprzednio szukamy rozwiązań gotowych. Jednak żadne z nich nie jest w stanie sprostać w pełni naszym potrzebom. Udaje się jednak dostrzec obszary na których gotowe rozwiązania spełniły by oczekiwania, jednak wciąż pozostają nie zaspokojone potrzeby w innych obszarach. Możemy podjąć wtedy decyzję o zebraniu kilku rozwiązań, zarówno w podejściu Użycia czy Adaptacji, po czym w procesie integracji połączyć je, w celu kompleksowej realizacji potrzeb. Przykład: Integracja Streamsoft Verto z systemem planowania Preactor.

Zabudowa – jeżeli wszystkie poprzednie strategie wydają się nieskuteczne, i zbliżamy się do decyzji o stworzeni czegoś własnego, można pokusić się o „sprytny” manewr polegający na stworzeniu własnego rozwiązania, którego częściami składowymi będą rozwiązania gotowe (także, a nawet głównie, open-source). Daje nam to z jednej strony dużą elastyczność, bo tworząc coś własnego możemy spełnić 100% naszych wymagań, a z drugiej strony nie tworząc wszystkiego, tylko te brakujące elementy znacząco obniżamy koszty. Przykład: Użycie biblioteki Apache Camel i Apache ActiveMQ, oraz nadbudowy w postaci systemu zdarzeń i mechanizmów automatycznego konfigurowania procesów, do stworzenia Szyny ESB Streamsoft.

Implementacja – w sytuacji kiedy nie jesteśmy w stanie znaleźć gotowego rozwiązania albo rozwiązania gotowe nie spełniają oczekiwań, wtedy możemy rozważyć strategie implementacji. Jest to najbardziej kosztowna strategia. Należy stosować ją rozważnie i w ostateczności. Jakie sygnały pozwalają nam myśleć o własnym rozwiązaniu?

• Brak gotowych rozwiązań gotowych do Użycia, Adaptacji czy Kompozycji.
• Bliskość, silne pokrewieństwo naszemu „klu biznesu”.
• Posiadanie kompetencji z tej dziedziny lub wiedzy jak je pozyskać.
• Specyficzność, unikalność potrzeby, a nie typowość czy powszechność.
• Wysoka innowacyjność rozwiązania, szczególnie w zaspokojeniu głównej potrzeby.
• Wyraźna wartość dodana, która będzie unikalna i może stać się rynkowym wyznacznikiem, wyróżnikiem naszego rozwiązania.

Poniżej na wykresie widzimy zależność ponoszonych kosztów, potencjalnego stopnia realizacji potrzeby oraz stopnia innowacji od przyjętej strategii

Jak widać od razu, dwie najciekawsze strategie to Kompozycja i w szczególności Zabudowa. Obie pozwalają na realizację 100% potrzeb przy stosunkowo niskich kosztach. Obie oddalają od nas oba syndromy NIH i LRTW. Zabudowa daje także znaczącą szanse na innowacje, a to w przypadku kreowania nowych produktów jest niebanalna zaletą. Kto korzysta z strategii zabudowy? Jednym z koronnych przykładów jest system Android. W jego wnętrzu działa jądro Linux’a, a platformą aplikacyjną jest Java. Obie technologie zostały zabudowane wewnątrz, po czym dopisano warstwę GUI jako nie dającą się zaadaptować. Co prawda istniały już implementacje GUI mobilnego ale albo nie spełniały wymagań albo były rozwiązaniami własnościowymi, nie dostępnymi dla Android’a. Działanie takie spowodowało ogromne zmniejszenie kosztów, znacząco skrócił się „Time To Market”, co wydaje się kluczowe. W efekcie produkt odniósł ogromny sukces rynkowy.

Co z Implementacją? To najbardziej kosztowna strategia, dająca szanse na pokrycie 100% potrzeb i szanse na 100% innowacyjność ale generująca największe koszy i ryzyko, że to nie będzie miało sensu. Wszystko zależy od efektu końcowego. Jest tu podobnie jak w dobrze znanej zasadzie dotyczącej ryzyka:

„… jeżeli zaryzykujesz i ci się uda, zostajesz człowiekiem pełnym odwagi, wizjonerem, a jak się jednak nie uda, okazuje się że byłeś nierozsądny a nawet głupi … ”

Te same działania, różny efekt, różna ocena. W strategii Implementacji także sam stosunek ryzyka do wielkości potencjalnego sukcesu lub porażki pozostaje w liniowym związku, im bardziej jesteś gotowy zaryzykować tym możesz osiągnąć większy sukces lub większą porażkę.

Pozostały nam dwie pierwsze strategie, Użycie i Adaptacja, czy nie są godne uwagi? Oczywiście są. W rozwiązywaniu typowych powtarzalnych problemów, nie związanych z „klu” działalności organizacji, nie ma lepszego i bardziej optymalnego podejścia.

Jak zatem postępujemy w Streamsoft NEXT i VERTO? W zakresie NEXT, stosujemy wszędzie gdzie się da „Zabudowę” i także „Kompozycję”, niechętnie ale zdarza się, że nie ma innego wyjścia i decydujemy się na „Implementację”. W VERTO główną strategią jest „Użycie” i „Adaptacja”, na taki profil postępowania pozwala nam posiadanie własnej platformy programistycznej. W fazie wdrażania systemu VERTO stosowane są wszystkie strategie zależnie od potrzeb, ale generalnie im bliżej „Użycia” tym lepiej. Jako zespół, uznajemy dobór odpowiedniej strategii do konkretnej sytuacji jako jedną z kluczowych decyzji.

Podsumowując zdecydowani zalecałbym świadome podejmowanie decyzji o wyborze konkretnej strategii. Oczywiste jest także, że w większej skali nie da się podjąć jednej, zawsze słusznej. W różnych produktach i różnych obszarach tych bardziej złożonych produktów powinniśmy podejmować je różne i to będzie zdecydowanie dobre.