paź
27

Czym jest MVP w obszarze architektury korporacyjnej?

Źródło: Andrzej Sobczak
Print Friendly

mvpW świecie start-up’ów  w chwili obecnej dużą popularnością cieszy się zwrot:  “Minimum Viable Product” (MVP). Pojęcie to jest tłumaczone na język polski jako “produkt o minimalnej koniecznej funkcjonalności lub też “produkt posiadający tylko kluczowe funkcjonalności”.

Zostało ono wprowadzone do obiegu przez Erica Riesa, przedsiębiorcę z branży internetowej, autora m.in. książki “The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”.

Produkt będący MVP posiada wyłącznie takie funkcje, które są wymagane, żeby przynosić choć minimalną korzyść jednemu tylko typowi klientów – tj. “early adopters”. Są to liderzy opinii, którzy pierwsi chłoną nowości, testują je przez jakiś czas i na koniec dzielą się swoimi spostrzeżeniami z twórcą produktu. W praktyce ich zdanie w wielu wypadkach decydujące o dalszym rozwoju produktu.

Jaki problem rozwiązuje podejście bazujące na MVP? Pozwala ono odpowiedzieć na fundamentalne dla każdego przedsiębiorcy pytanie – tj. czy w ogóle istnieje potrzeba, którą produkt ma rozwiązywać. Z tego względu tak istotne jest wysłuchanie głosów, które otrzymuje on po udostępnieniu MVP i na tej podstawie zadecydowanie co dalej – czy rozwijać dany produkt zgodnie z przyjętymi założeniami, czy go prawie lub całkowicie przebudować, a w skrajnym przypadku należy wręcz go zarzucić.

Takie podejście ma chronić przedsiębiorcę przed tworzeniem produktów, które trafiają w tzw. “próżnię” – czyli nie będzie na nie zupełnie zapotrzebowania (mimo, że wydawało się , że jest to przysłowiowy “strzał w dziesiątkę”). MVP jest więc realizacją pewnej wizji produktu wyrażoną tylko i wyłącznie cechami, stanowiącymi o jego innowacyjności. MVP jest stosunkowo tani w utworzeniu i jeżeli okaże się nietrafioną inwestycją jego wycofanie nie będzie wiązało się z dużymi stratami finansowymi (ale również poświęceniem bardzo dużej ilości czasu)  dla producenta.

W kontrze do MVP jest tradycyjne podejście związane z wprowadzaniem produktu na rynek – czyli dokładne (ale  kosztowne  i długotrwałe) analizy i badanie rynku, następnie dopracowywanie nowego produktu na podstawie tak uzyskanych wyników – i dopiero po tych działaniach – wprowadzenie rozwiązania na rynek. Nie ma problemu – jeżeli produkt będzie wielkim sukcesem… Wówczas jego ojców jest dużo…. Gorzej jeżeli nowy produkt okaże się porażką.

W tym miejscu nie chcę przedstawiać dalszych szczegółów związanych z MVP. Nie ukrywam, że urzekła mnie ta idea (tak samo jak filozofia lean startup). Zacząłem się zastanawiać czy i jak dałoby się ją wykorzystać w przypadku architektury korporacyjnej. I tak narodził się pomysł nowego znaczenia MVP – czyli “Minimum Viable architecture Practice” –  a ponieważ założenia tego pomysłu zaprezentowałem na I Spotkaniu Architektów Finansowych i spotkał się on z pozytywnym odbiorem postanowiłem przybliżyć go Państwu.

Zacznijmy od definicji MVP dedykowanego architekturze. “Minimum Viable architecture Practice” to minimalny zakres praktyki architektonicznej wdrożony w organizacji, który dostarcza  pierwsze korzyści dla wybranej grupy interesariuszy ze stosowania koncepcji architektonicznych.

Jakie są cele MVP dedykowanego architekturze ? Po pierwsze MVP pozwala na sprawdzenie czy w ogóle działanie zgodnie z architekturą korporacyjną ma sens w konkretnej organizacji (czy organizacja potrzebuje zarządzania architekturą i czy jest na nie gotowa). Po drugie MVP pozwala szybko zweryfikować czy przyjęte założenia dotyczące organizacji praktyki architektonicznej są właściwe – w kontekście tej konkretnej organizacji.

Do kogo jest dedykowany MVP architektoniczny? Innymi słowy – na kim będziemy MVP architektoniczny “testować”? Na pewno w każdej organizacji istnieją departamenty (poza IT) bardziej lub mniej otwarte na zmiany. MVP jest dedykowane takim wewnętrznym (tj. korporacyjnym) early adopters. W banku może to być np.  departament bankowości elektronicznej, w firmie ubezpieczeniowej – departament zajmujący się np. bancassurance.

Jaki powinien być zakres MVP architektonicznego. Nie ma jednej odpowiedzi na to pytanie. Wszystko zależy od organizacji, sposobu jej działania, pomysłu na wykorzystanie architektury korporacyjnej. Na bazie dotychczasowej praktyki sądzę, że powinny to być określone modele – na bazie bardzo prostego metamodelu, 2-3 procesy architektoniczne oraz 2-3 role organizacyjne (podkreślam: role – nie etaty).

Jaki jest nakład potrzebny do opracowania MVP architektonicznego? Sądzę, że osoby które mają doświadczenie we wdrażaniu i praktyki architektonicznej powinny go przygotować w przeciągu góra 10 dni roboczych.

Kto opracowuje MVP architektoniczny? Osoba, która widzi się w roli głównego architekta (lub jest widziana do pełnienia tej roli). Zwykle jest to poziom specjalisty w organizacji.

Kto ocenia wyniki działania MVP architektonicznego? Na pewno osoba, która go stworzyła (czyli główny architekt in spe) oraz ew. potencjalny sponsor prac architektonicznych (zwykle jest to poziom dyrektora w organizacji).

Co się dzieje, jeżeli MVP architektoniczny zaczyna działań? Na pewno warto pomyśleć o upowszechnieniu podejścia  architektonicznego na inne obszary organizacji i doskonaleniu obecnej praktyki – ale trzeba mocno uważać, aby nie zepsuć uzyskanych rezultatów – czyli każdą zmianę w MVP architektonicznym – testujemy – np. na poziomie pojedynczego projektu…

Co się dzieje, jeżeli MVP architektoniczny NIE działa? Tutaj scenariusze są dwa. Albo próbujemy go poprawić – czyli zmienić podejście do procesów, modeli, ról i odpowiedzialności i ponownie poddajemy się osądowi organizacji. Drugim scenariuszem jest zarzucenie podejścia architektonicznego – przynajmniej w danym momencie (być może organizacja nie jest jeszcze na nie gotowa, lub wręcz go nie potrzebuje).

Oczywiście będę wdzięczny za Państwa opinie na temat podejścia architektonicznego. Prosiłbym o ich umieszczenie w komentarzach lub bezpośredni kontakt. A może ktoś z Państwa chciałby spróbować zastosować to podejście u siebie w organizacji :)?

Andrzej Sobczak

Profesor, kierownik Zakładu Zarządzania Informatyką w Instytucie Informatyki i Gospodarki Cyfrowej SGH. Ma ponad 8 letnie doświadczenie we wdrażaniu koncepcji architektury IT i architektury korporacyjnej. Posiada certyfikaty TOGAF 8/9, ArchiMate 2.0, ITIL, MSP.

Polecane wpisy

TAGI DLA WPISU

Dyskusja do artykułu “Czym jest MVP w obszarze architektury korporacyjnej?

  1. Witam.
    W pierwszej chwili byłem dość sceptycznie nastawiony do pomysłu, żeby Architekturę Korporacyjną wdrażać jako beta produkt wdrażany testowo w ograniczonym obszarze, który dopiero dalej powinien być rozwijany (lub nie).
    Po dalszych przemyśleniach i obejrzeniu się wstecz zauważyłem, że moje działania można spokojnie powiązać z tą koncepcją. To wszystko co mi się do tej pory udawało było realizowane zbieżnie z tą koncepcją. Oczywiście to może wynikać z dojrzałości organizacji. Przy niskim stopniu dojrzałości wyzwaniem jest wytłumaczenie (udowodnienie), że zarządzanie (governance & praktyka architektoniczna) ma w ogóle sens. W organizacjach o wyższym stopniu dojrzałości skupiamy się bardziej na udowadnianiu dlaczego do budowy praktyki przyjęliśmy takie a nie inne pryncypia.
    Jednak w mojej praktyce zawodowej są też różnice względem opisanego tu podejścia (nie znam całości koncepcji). Ja wykorzystuje to bardziej jako budowanie przyczółków mając jednocześnie wizję całości (oczywiście na wysokim stopniu ogólności). Potem poszczególne przyczółki podlegają umacnianiu i w miarę jak prezentują swoje korzyści są rozbudowywane – często już organizacja samoistnie jest tym zainteresowana. Ja bym to nazwał strategią zdobywania przyczółków.

    Dla pokazanego tutaj podejścia widzę też inną zaletę – można w ten sposób zdobywać doświadczenie, budować warsztat architektoniczny realizując zadania o mniejszej złożoności – co powoduje mniejsze ryzyko błędów (i ich impakt).

  2. Koncepcja Minimum Viable Product (MVP) wydaje się być dla rozwoju produktu biznesowego tym, czym podejście Agile dla produktu informatycznego. Zamiast Big Design Up Front, czy też podejścia waterfall’owego, iteracyjnie dochodzimy do tego, co jest potrzebne. Nasze początkowe hipotezy dotyczące produktu i potrzeb jakie ma zaspokoić, a przede wszystkim popytu na nasz produkt, testujemy z każdą nową iteracją, każdym nowym releasem.

    Ja też jestem wielkim fanem MVP, Lean Startup, jak również Agile, dlatego kibicuję wszelkim próbom zastosowania tych koncepcji także w innych obszarach :)

Dodaj komentarz

W celu wzięcia udziału w dyskusji jako zalogowany użytkownik możesz zalogować się poprzez jeden z poniższych serwisów.

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Captcha Captcha Reload

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>