BizDevOps ang. BizDevOps

BizDevOps - koncepcja zarządzania przedsiębiorstwem wychodzącą naprzeciw wymaganiom i potrzebom Gospodarki Cyfrowej (ang. Digital Economy). Istotą tego podejścia jest przeprowadzona na poziomie kulturowym, organizacyjnym i architektonicznym, konwergencja Biznesu i IT. U podstaw koncepcji BizDevOps leży założenie, że podstawowym sposobem dostarczania wartości biznesowej (Biz) jest cyfrowo udostępniana mikrousługa a kompetencje jej rozwoju (Dev), utrzymania (Ops) i zapewnienia jakości (QA) są organizacyjnie skoncentrowane w jednym zespole. Kolejnym kluczowym założeniem tej koncepcji jest konsolidująca rola Architektury Przedsiębiorstwa (ang. Enterprise Architecture).

Spis treści

BizDevOps jako rozszerzenie DevOps

DevOps jest metodą wytwarzania, implementacji i utrzymania oprogramowania, zainicjowaną przez Patricka DeBois i rozwijaną od 2009 roku. Kładzie ona nacisk na komunikację, współpracę i integrację specjalistów ds. rozwoju oprogramowania (Dev) i ekspertów z zakresu utrzymania IT (Ops). Zgodnie z tą definicją swoim zakresem obejmuje wyłącznie struktury IT.

Natomiast BizDevOps jest rozszerzeniem tej koncepcji poprzez włączenie na stałe do zespołów DevOps osób z Biznesu. Współpraca członków zespołu budowana jest w oparciu o udostępniane klientom usługi biznesowe, które realizowane są za pośrednictwem mikrousług (niewielkich, autonomicznych usług technologicznych). Każda mikrousługa wykonuje określoną funkcję biznesową oraz posiada lekki interfejs (np. http), które pozwala jej współpracować z innymi mikrousługami.



Istota koncepcji

Istotą koncepcji BizDevOps jest konwergencja Biznesu i IT zachodząca na poziomie architektonicznym, zarządczym, organizacyjnym i kulturowym.

Koncepcja kładzie nacisk na komunikację, współpracę i integrację osób odpowiedzialnych za biznes (np. marketing, sprzedaż), specjalistów z zakresu operacji IT oraz rozwoju oprogramowania w ramach zespołów BizDevOps. Zespoły BizDevOps wytwarzają usługi biznesowe i uczestniczą w pełnym cyklu ich życia, aż do wycofania. Kompetencje członków zespołów BizDevOps pozwalają na wypracowanie koncepcji usługi biznesowej, wykonanie i przetestowanie usługi a także na udział w procesie biznesowym, którego jest ona produktem. Koncepcja jest dostosowana do przedsiębiorstw cyfrowych, w których procesy biznesowe są w znaczącej części zautomatyzowane.

Platformą współpracy, zarówno wewnątrz zespołów BizDevOps jak i pomiędzy nimi, jest architektura przedsiębiorstwa. Dzięki niej zespoły stanowiące swego rodzaju mikrosilosy, zachowują spójność na poziomie celów biznesowych, standardów i kierunków rozwoju.

Uwarunkowania zewnętrzne

BizDevOps pozwala przedsiębiorstwom odpowiedzieć na szereg trendów rynkowych takich jak:
  • skrócenie czasu życia produktów i usług – wynikające z coraz szybszego zastępowania ich nowymi, bardziej nowoczesnymi rozwiązaniami;
  • konieczność konkurowania w nowych warunkach – nie tylko ceną i innowacyjnością, ale także nowymi modelami biznesowymi;
  • rosnące oczekiwania klientów w zakresie szerokiej dostępności usług w kontekście innych usług (np. dostęp do zakupów z poziomu portali społecznościowych);
  • pojawienie się nowych możliwości biznesowych – z upowszechnienia dostępu nowych usług i zaawansowanych technologii oraz z otwartości przedsiębiorstw na szeroką współpracę biznesową;
  • dywersyfikacja działalności rynkowej – przedsiębiorstwa coraz częściej oferują usługi w zupełnie innych dziedzinach niż dotychczas;
  • konieczność tworzenia usług ściśle dopasowanych do rzeczywistych potrzeb klientów – zanik dominującej dotychczas produkcji masowej;
  • skrócenie czasu od pomysłu do dostarczenia na rynek (tzw. Time to Market) – przedsiębiorstwa, które nie są w stanie sprostać oczekiwaniom klientów przegrywają z konkurencją;
  • zmniejszenie marży na produkcie – silna konkurencja cenowa, zmusza do ograniczenia kosztów wynikających między innymi z wydłużającego się procesu projektowego.


Uwarunkowania wewnętrzne

Poza uwarunkowaniami rynkowymi, również wewnątrz samych przedsiębiorstw pojawiły się przesłanki wskazujące na konieczność wprowadzenia zmian zarządczych i organizacyjnych. Wśród przesłanek tych można wymienić:
  • tendencje do zastępowania zintegrowanych systemów informatycznych, które są mało elastyczne i trudne w utrzymaniu, rozwiązaniami opartymi o mikrousługi;
  • coraz ściślejszą współpracę Biznesu i IT w zakresie tworzenia oferty produktowej oraz zasad jej udostępniania przy wykorzystaniu nowych technologii;
  • wzrost wiedzy informatycznej wśród pracowników biznesowych i wzrost świadomości biznesowej wśród pracowników IT;
  • konieczność stosowania nowych technologii i rozwiązań ułatwiających klientom dostęp do produktów i usług świadczonych w ramach ekosystemów gospodarczych (ang. Business Ecosystems);
  • dostępność narzędzi automatyzujących cykl życia usług IT lub jego etapy;
  • zmiany w kulturze organizacyjnej, a w szczególności w komunikacji, motywacji, stylu pracy i zarządzania związane przede wszystkim z pojawieniem się na rynku pracy Pokolenia Y i Pokolenia Z.


Pryncypia koncepcji BizDevOps

Zastosowanie podejścia BizDevOps wymaga spełnienia przez przedsiębiorstwo kilku, związanych z tą koncepcją, założeń:
  • strategia rynkowa firmy opiera się na dostarczaniu usług (klientom i partnerom biznesowym) przy wykorzystaniu rozwiązań cyfrowych;
  • w obszarze obsługi klienta podstawowym elementem struktury organizacyjnej są Zespoły BizDevOps, które łączą w sobie kompetencje biznesowe i informatyczne. Ich głównym zadaniem jest dostarczanie usług biznesowych, w sposób gwarantujący pozytywne doświadczenie klienta (ang. User Experience);
  • zespół BizDevOps, który opracował i stworzył usługę odpowiada za jej jakość, utrzymanie oraz dalszy rozwój w zakresie biznesowym i technologicznym.
  • zarządzanie zmianą, szczególnie w obszarze obsługi klienta, odbywa się w oparciu o metodyki zwinne;
  • Architektura Przedsiębiorstwa, rozumiana jako monolit obejmujący Architekturę Biznesową i Architekturę IT, pełni rolę konsolidacyjną (uspójniającą) w zakresie wyznaczania kierunków rozwoju oraz zwinnej realizacji zmian.


Architektura Przedsiębiorstwa w koncepcji BizDevOps

Dotychczas Architektura Przedsiębiorstwa (ang. Enterpise Architecture) kojarzona była głównie z Architekturą IT (ang.IT Architecture), która poza elementami infrastruktury i technologii, koncentrowała się głównie na aplikacjach i na zarządzaniu integracją. W koncepcji BizDevOps aplikacja (rozumiana jako monolit realizujący szereg funkcji biznesowych) zostaje zastąpiona zbiorem niezależnych pod względem funkcjonalnym i technologicznym mikrousług, które zaczynają stanowić główny komponent Architektury IT. W tym kontekście określenie biznesowego znaczenia mikrousług oraz wzajemnych, biznesowych zależności pomiędzy nimi, zaczyna mieć kluczowe znaczenie. Z pomocą przychodzi Architektura Biznesowa, która poprzez swoje komponenty – usługi i funkcje biznesowe (ang. Business Functions), pozwala na spójne opisanie rzeczywistości biznesowej oraz na jej jednolite postrzeganie. Architektura Biznesowa, tworząc „mapy” wzajemnie powiązanych funkcji biznesowych, pozwala na:
  • określenie kryteriów i zasad definiowania mikrousług oraz wskazanie wzajemnych zależności między nimi;
  • optymalne zaprojektowanie mikrousług oraz lepsze ich dostosowanie do potrzeb biznesowych;
  • odpowiednią granulację mikrousług, odpowiadającą granulacji funkcji biznesowych;
  • katalogowanie mikrousług w ramach potencjałów biznesowych (ang. Business Capability);
  • uwzględnienie w logice mikrousług kontekstu biznesowego (ang. Business Context) w jakim jest realizowana odpowiadająca im funkcja biznesowa;
  • określenie wzajemnych zależności pomiędzy mikrousługami, wynikających z procesów (ang. Business Processes) i reguł biznesowych (ang. Business Rules);
  • budowanie mikrousług w oparciu o jednolity model informacyjny.


Przy określaniu relacji pomiędzy funkcją biznesową a mikrousługą powinna istnieć zasada, iż każda mikrousługa realizuje jedną funkcję biznesową a każda funkcja biznesowa może być realizowana przez jedną lub wiele mikrousług.

Ścisła współpraca Architektury Biznesowej i Architektury IT sprawia, że w koncepcji BizDevOps nie są już one rozpatrywane odrębnie, ale konwergentnie, w ramach ujednoliconej Architektury Przedsiębiorstwa, której cechami są:
  • sieciowość rozumiana jako ustanowienie relacji równorzędności pomiędzy podstawowymi jej komponentami - funkcjami biznesowymi/mikrousługami (analogicznie do architektury Internetu);
  • otwartość polegająca na możliwości komunikowania się komponentów architektonicznych różnych przedsiębiorstw poprzez interfejsy definiowane na poziomie biznesowym i technologicznym (również analogicznie do podejścia internetowego).


BizDevOps a zarządzanie przedsiębiorstwem

Przyjęcie koncepcji BizDevOps jest dużą zmianą architektoniczną, organizacyjną i kulturową, jednak zakres jej stosowania w przedsiębiorstwie może mieć różny zasięg i różną głębokość.

Nawiązując do struktury zarządczej przedsiębiorstwa zaproponowanej przez Henry’ego Mintzberg’a obszarem, w którym najbardziej uzasadnione jest pojawienie się zespołów BizDevOps w pierwszej kolejności, jest Obszar Biznesu. W łańcuchu wartości to on bezpośrednio współpracuje z Klientami i Partnerami Biznesowymi.

Dużo bardziej skomplikowane jest wdrożenie zespołów BizDevOps w Obszarze Operacji stanowiącym realizacyjne zaplecze dla Obszaru Biznesu. Trudność ta wynika głównie z dużego znaczenia zintegrowanych i trudnych do zastąpienia, systemów informatycznych oraz związanej z nimi struktury organizacyjnej i zasad zarządzania (np. w zakresie ustalania właścicielstwa biznesowego systemów operacyjnych). Jednak sukcesywne wdrażanie podejścia BizDevOps w Obszarze Biznesu i Zarządzania Architekturą powinno znacznie ułatwić proces dostosowania Obszaru Operacji do zasad BizDevOps.

W Obszarze Wsparcia Biznesu (do którego należy m.in. obsługa finansowo-księgowa, operacyjny HR, logistyka), który bezpośrednio nie wpływa na budowanie przewagi konkurencyjnej, funkcje biznesowe mogą zostać oddane w ousourcing lub być wsparte rozwiązaniami wykupionymi w chmurze. Jednak ze względu na fakt, że obszar ten bezpośrednio nie współpracuje z klientami i partnerami biznesowymi, może stać się obszarem „proof of concept” - pozwalającym zweryfikować czy koncepcja ta sprawdzi się w kulturze danego przedsiębiorstwa.

Wdrożenie koncepcji BizDevOps ma również istotny wpływ na Obszar Zarządzania Strategicznego. Z punktu widzenia kultury organizacyjnej podejście BizDevOps wymaga otwartego, wspierającego i delegującego stylu zarządzania, opartego głównie na zaufaniu i dominującej roli przywództwa, coachingu i mentoringu. Jedno z głównych założeń BizDevOps, mówiące o cyfrowo udostępnianej usłudze biznesowej, ma bardzo duży wpływa na zarządzanie kontrolingiem, informacją finansową a także na strategie sprzedażowe i zakupowe. Również obsługa prawna powinna koncentrować się na aspektach związanych z dostarczaniem/wymianą usług oraz współpracą trybie agile.

W koncepcji Biz DevOps kluczową rolę odgrywają obszary Zarządzania Architekturą Przedsiębiorstwa oraz Zarządzania Zmianami. Zarządcza rola architektury (ang. Architecture Govermnace), poza procesami ustalania pryncypiów i standardów biznesowych i technologicznych, koncentruje się na definiowaniu i wdrażaniu zasad komunikacji i współpracy pomiędzy jednostkami uczestniczącymi w rozwoju przedsiębiorstwa. W koncepcji BizDevOps nadzór architektoniczny jest o tyle istotny, że pozwala zachować spójność realizowanych rozwiązań i zgodność z przyjętą strategią i kierunkami rozwoju, w środowisku licznych autonomicznych zespołów, współpracujących ze sobą w trybie agile. Organem wykonawczym dla nadzoru architektonicznego jest Obszar Zarządzania Zmianami, który w ramach wdrażania poszczególnych zmian jest odpowiedzialny za stosowanie wypracowanych standardów i zasad współpracy. Dba on jednocześnie o zapewnienie poszczególnym zespołom wymaganych zasobów oraz harmonizację terminów realizacji zadań w ramach danej zmiany. Jednak w świecie BizDevOps największym wyzwaniem dla Obszaru Zarządzania Zamianami, jest zapewnienie synchronizacji zmian pomiędzy obszarami „dwóch prędkości” – zwinnego Biznesu i „wolno zmiennych” Operacji. Garhner określa to zjawisko jako zjawisko BiModal IT.

Zespół BizDevOps

Jednym z głównych założeń koncepcji BizDevOps w aspekcie organizacyjnym są specyficznie zorganizowane zespoły, które w pierwszej kolejności powinny zostać powołane w Obszarze Biznesu. Poniżej zostały przedstawione główne zasady w oparciu, o które powinny być budowane zespoły BizDevOps:
  • Nadzór – zespoły realizują strategię firmy, wykonując powierzone zadania. Zarządzanie architekturą zapewnia standardy architektoniczne biznesowe i techniczne oraz nadzoruje ich przestrzeganie. Zespół solidarnie odpowiada za realizację powierzonych zadań.
  • Specjalizacja zespołów traktowanych jako całość jest bezpośrednio związana z biznesem widzianym od strony klienta końcowego, np. produktem czy funkcjonalnością biznesową. Na przykład dany zespół może specjalizować się w mikrousługach związanych z płatnościami, inny w mikrousługach wyświetlania zdjęć sprzedawanych produktów, jeszcze inny w mikrousługach zapewniających wysyłanie potwierdzeń itd. Bardzo ważne jest rozumienie biznesu, w którym się działa, a z drugiej strony otwartość i kreatywność.
  • Multidyscyplinarność dotyczy poszczególnych członków zespołu BizDevOps. Obejmuje ona różne kompetencje (co nie jest tożsame z etatami), w tym biznesowe (marketing, sprzedaż, branżowe), programistyczne, testerskie itp. Multudyscyplinaność w dużym stopniu, choć nie w zupełności, umożliwia wzajemną zastępowalność członków zespołu oraz pozwala na to, że dany zespół jest w stanie wymyślić mikrousługę, zaprojektować ją biznesowo i technicznie, zbudować, przetestować, wdrożyć, utrzymywać, rozwijać i wykorzystywać (użytkować) ją w ramach procesu biznesowego.
  • Elastyczność – członkowie zespołu specjalizują się w poszczególnych dziedzinach, np. jeden jest lepszym marketingowcem, inny lepszym grafikiem, jeszcze inny lepszym programistą, jednak w zespole nie ma sztywnego podziału zadań i w razie potrzeby różne osoby wykonują różne czynności. Członkowie uczą się od siebie uzupełniając swoje umiejętności.
  • Wielkość zespołu – liczebność i zakres odpowiedzialności zespołu uzależnione są od poziomu granulacji mikrousług (czyli architektury rozwiązania). W ramach cyklu życia mikrousługi zespół może wnioskować o zmniejszenie lub zwiększenie zasobów, zmianę liczebności i kompetencji. Jako, że zespoły są biznesowo-techniczne mają świadomość zarówno potrzeb, jak i efektywności swojej pracy – mają na uwadze wynik finansowy.
  • Samoorganizacja – w zespołach nie ma zdefiniowanych ról, zadania nie są przypisane do poszczególnych członków zespołu. Sami dokonują oni wyboru realizowanych zadań według wspólnych ustaleń, umiejętności czy innych preferencji.
  • Autonomiczność – polegająca na tym, że zespoły są oceniane jako całość, natomiast ocena poszczególnych członków jest sprawą wewnętrzną zespołu. Wymaga to odpowiedniego dostosowania systemu wynagrodzeń oraz zasad rekrutacji i zwalniania pracowników.
  • Sposoby motywowania – są dostosowane do opisanych wyżej zasad organizacji. Opierają się na trzech filarach: autonomii, mistrzostwie i poczuciu celu. Autonomia dotyczy wolności podejmowania decyzji – członkowie zespołu sami decydują co robią, kiedy robią i jak robią. Mistrzostwo opiera się na założeniu, że ludzie chcą się rozwijać w obszarach, które uważają za ważne dla siebie. Natomiast poczucie celu zakłada, że ludzie chcą uczestniczyć w rozwijaniu czegoś więcej niż tylko samego siebie. (Daniel H. Pink: Drive. Kompletnie nowe spojrzenie na motywację, Wydawnictwo Studio EMKA, Warszawa 2011)
  • Wspólna praca – stanowiska pracy są ustawione tak, że członkowie zespołu widzą się wzajemnie i mogą swobodnie rozmawiać w trakcie pracy.
  • Techniki pracy – zespoły BizDevOps mogą korzystać z różnych technik pracy. Mogą one być zapożyczane z metod Agile, Lean IT lub DevOps. O wykorzystaniu poszczególnych technik decyduje zespół.


BizDevOps a skalowalność

W koncepcji BizDevOps problem skalowania na poziomie technologicznym nie występuje ze względu na samą specyfikę mikrousług (niezależność, współpraca w oparciu o architekturę sieciową). W przeciwieństwie do systemów monolitycznych (im większy system tym problem skalowalności jest większy) mikrousługa, która jest w pełni autonomiczna, może być wdrożona niezależnie od innych mikrousług. W podejściu BizDevOps nie istnieje scentralizowane zarządzanie mikrousługami, konieczne jest natomiast ustalenie standardów architektonicznych, określenie kierunków rozwoju i zapewnienie wynikających z nich zasobów realizacyjnych. Na poziomie zarządczym zjawisko skalowalności w koncepcji BizDevOps wynika z jej otwartości na szeroką współpracę w ramach ekosystemów gospodarczych (ang. Business Ecosystems). Tego typu współpraca wymaga jednak dodatkowych ustaleń technologicznych, finansowych i prawnych (np. w zakresie dostępu do danych osobowych).

BizDevOps a kultura organizacyjna

BizDevOps to nie tylko zmiany w podejściu do architektury czy struktury organizacyjnej. To także, a może przede wszystkim, zmiana kultury organizacyjnej polegająca na wzajemnym przenikaniu się sposobów myślenia biznesu i technologii. Ta mentalna konwergencja Biznesu i IT z jednej strony polega na postrzeganiu technologii w kontekście dostarczania wartości biznesowej z drugiej zaś na stosowaniu w Biznesie systemowego sposobu myślenia (ang. System Thinking). Pozwala to na szerokie spojrzenie w czasie (uwzględnienie korelacji pomiędzy zmianami dotychczasowymi i planowanymi) i przestrzeni (uwzględnienie wpływu zmian wprowadzanych przez inne jednostki i partnerów biznesowych).

BizDevOps jest również propozycją odpowiedzi na zmianę pokoleniową i wynikającą z niej zmianę podejścia do trybu pracy. Koncepcja BizDevOps odpowiada na oczekiwania pokolenia Y i Z zarówno w zakresie szybkości dostarczania końcowych produktów działania (szybko wytworzona wartość biznesowa) jak i w zakresie zasad współpracy (określanych jako „inteligent swarming”). Koncepcja BizDevOps nie narzuca również sztywnych organizacyjnych reguł pracy, w pełni akceptuje współpracę rozproszoną, odpowiadająca stylowi życia „nomadów”.

Autorzy

Pomysł BizDevOps zrodził się podczas przygotowywania programu 8 Kongresu itSMF Polska, który odbył się 26 października 2016 r. w Warszawie, w oparciu o idee zaprezentowane przez Ewę Zaleską podczas Forum SPEED IT 21 czerwca 2016 r. Autorami koncepcji i powyższego hasła są:

Szereg uwag merytorycznych i istotny wkład do pierwszej wersji wnieśli Recenzenci:

Hasła (opisy encyklopedyczne) i artykuły (np. opisy case studies) są dostępne na licencji CC-BY-SA 3.0.

Artykuły, uwagi, komentarze i opinie prosimy przesyłać na adres ewa.zaleska@op.pl i kbtomkiewicz@gmail.com.
ostatnia modyfikacja 4 maja 2017 r.