Wprowadzenie

Skrót VSM zaczyna się od pewnego czasu pojawiać także w inżynierii oprogramowania, ma on jednak stary, ponad 30-letni rodowód.

Mapowanie strumienia wartości (ang. Value-stream Mapping, VSM), znane od 30 lat, ostatnio także jako mapowanie przepływu materiałów i informacji (ang. material- and information-flow mapping). Jest to metoda mająca swoje początki w Lean Management, służąca do analizy stanu obecnego i projektowania stanu przyszłego dla serii zdarzeń, które prowadzą produkt lub usługę od zamówienia do momentu dostarczenia klientowi.

Mapa strumienia wartości to graficzne podejście, które pokazuje wszystkie krytyczne kroki w określonym procesie i określa ilościowo czas i koszt na każdym etapie, oraz ilości. Mapy strumienia wartości pokazują przepływ zarówno materiałów, jak i informacji w miarę postępu procesu powstawania produktu końcowego. W literaturze spotkamy opisy VSM już w 1993 roku . Przykład takiej mapy łańcucha przepływu wartości:

Jak widać jest to niesformalizowany schemat blokowy opisujący kluczowe operacje oraz ich cechy (głównie czas trwania i koszt). W dzisiejszej nomenklaturze taki ciąg zadań nazywa się marszrutą w toku produkcji. Nadrzędnym łańcuchem wartości jest rynkowy łańcuch wartości, co pokazuje kolejny standard (model referencyjny) jakim jest SCOR (Supplay-chain Operation Reference), graficznie przedstawiany tak:

Model na pierwszym prezentowanym schemacie obrazuje wnętrze tego co powyżej nazwano “Make”.

Podczas gdy mapa strumienia wartości reprezentuje procedurę powstawania produktu, model procesów biznesowych pokazuje obraz wszystkich działań w firmie, prowadzących od zamówienia do dostarczenia produktu. Pozostałe działania biznesowe (pozaprodukcyjne) mogą być reprezentowane na modelach procesów biznesowych, co pokazamno poniżej:

Proces VSM to jedynie Realizacja Produkcji na diagramie powyżej (obszar oznaczy VSM). Proces ten szerzej opisałem w artykule Przeciążanie BPMN czyli jak nie modelować produkcji.

Metoda VSM obecnie jest stosowana nie tylko w typowej produkcji ale także w wielu innych sektorach gospodarki:

Bardzo ciekawy przykład można znaleźć na stronie NHS (państwowy system zdrowia w UK), gdzie podjęto próbę poprawy efektywności tej instytucji .

VSM w inżynierii oprogramowania

W lutym tego roku napisałem:

Powoli koń­czy się era ??świę­tych krów? inży­nie­rii. Inżynieria opro­gra­mo­wa­nia, po pra­wie 20 latach ??zwin­ne­go? podej­ścia do tej gałę­zi inży­nie­rii, zaczy­na doj­rze­wać do bycia ??praw­dzi­wą inży­nie­rią? z ana­li­za­mi, pro­jek­to­wa­niem i testo­wa­niem na ??desce kre­ślar­skiej?, jaką są sys­te­my CASE i podej­ście MBSE, które sta­no­wią uni­wer­sal­ne sys­te­mo­we podej­ście do mul­ti­dy­scy­pli­nar­nej inży­nie­rii (mecha­troni­ka) (Rosenberg, 2023). Organizacje to też sys­te­my i ich inży­nie­ria: mamy inży­nie­rię pro­ce­sów biz­ne­so­wych, inży­nie­rię zaso­bów, inży­nie­rie finan­so­wą. Organizacje to sys­te­my i tak nale­ży je trak­to­wać i mode­lo­wać (Koźmiński, 1979). Koszty utrzy­ma­nia i roz­wo­ju sys­te­mów IT to już ponad 8% przy­cho­dów fir­my i war­tość ta powo­li ale nadal sta­le rośnie. Rośnie tak­że dys­cy­pli­na ich two­rze­nia, wdra­ża­nia i zarzą­dza­nia ich kosztami.

Źr.: Organizacja jako mechanizm czyli słoń w pokoju – Jarosław Żeliński IT-Consulting

Produkty w przemyśle to już nie tylko elektromechaniczne urządzenia, coraz więcej urządzeń zawiera komputer jako składnik konstrukcji, co oznacza, że “półwyrobem” jest oprogramowanie. To zaś oznacza, że oprogramowanie zaczyna podlegać takim samym rygorom procesu produkcji i kontroli jakości jak urządzenie, którego jest częścią. Od kilkunastu lat obrazowane jest to tak jak na schemacie poniżej:

Kolejny poziom postrzegania oprogramowania to uznanie, że jest ono częścią firmy. Czy to coś zmienia? Okazuje się, że nie bo niezależnie od tego czy oprogramowanie jest produktem kupionym na rynku, czy produktem własnego działu IT, powstaje ono w identyczny sposób.

Schemat blokowy, przytoczony na początku tego artykułu, można z powodzeniem zastosować do produktu będącego w 100% oprogramowaniem z prostego powodu: on musi powstać, a to także wymaga czasu i zasobów.

W tym momencie pojawia się pytanie: jakie etapy ma taki proces i jak je pokazać? Jeżeli produkt jest monolitem, to po prostu jest to jeden “wielki etap”. Jeżeli chcemy opisać tworzenie oprogramowania jako VSM to ono musi być zaprojektowane jako komponentowy system, a komponenty te muszą być niezależne (każdy można albo stworzyć od zera albo kupić na ryku jako COTS).

Jeżeli tak, to wkraczamy w komponentowe systemy i wzorce projektowe, takiej jak opisywane tu nie raz: MVC, architektura heksagonalna czy architektura C4.

Podsumowanie

Zarządzanie oprogramowaniem metodą Value Stream Mapping jest możliwe tylko wtedy gdy opracujemy i udokumentujemy architekturę aplikacji i proces jej wytwarzania, o ile oczywiście jest ona komponentowa a nie monolityczna.

W przypadku systemów, także oprogramowania, coraz częściej pojawia sie V model, który opiałem między innymi w artykule Czym są testy oraz kto i co testuje:

Jak widać tu także mamy etap projektowania oraz implementacji i cyklicznego (iteracyjnego) rozwoju. Starszą niż VSM wersją podejścia procesowego jest łańcuch wartości dodanej M. E. Portera, który – mimo że ma rodowód sięgający 1985 roku – jest nadal przytaczany :

To co obecnie nazywamy VSM to, na diagramie powyżej, wewnętrzny łańcuch wartości, oznaczany tu jako “Primary (Core) Activities”.

Jak więc widać, że mimo różnorodności nazw metod i ich autorów, cały czas mówimy o tym samym wewnętrznym łańcuchu wartości.

Źródła