Podejście do efektywności komputerowych systemów wspomagających zarządzanie ulegało zmianie w ostatnich dekadach. W początkowym okresie rozwoju informatyki (lata 50., 60.) inwestycje w narzędzia IT traktowano podobnie jak zakup maszyn przetwarzających materię, a nie informacje. Wydatki na zakup komputera należało zbilansować oczekiwanymi oszczędnościami, w szczególności w sferze personalnej. Zwłaszcza zakupy drogiego oprogramowania traktowano z dużą podejrzliwością. W końcu wydawano spore pieniądze na coś, czego nie widać. Firmy software’owe pakowały więc z celową przesadą taśmę magnetyczną do pokaźnej a ciężkawej skrzyni, dopełniając ją kilogramami papierowych tomów referencyjnych. W ten sposób decydent miał nabierać przekonania, że nabywał coś solidnego i wartościowego.

W latach 70. osiągnięto apogeum inwestycyjnej biurokracji. Ustalano nawet minutowe normy dla napisania jednej linii kodu w określonym języku software’owym, przytomnie jednak rozróżniając instrukcje sterujące od komentarzy wewnątrz programu. Zmodyfikowane elementy takiego podejścia znajdziemy także dzisiaj i mogą być one pomocne w szacowaniu nakładów informatycznych (np. metryki punktów funkcyjnych). Pozostaje jednak kwestia udowodnienia rentowności przedsięwzięcia. Problem nie jest nowy i można było się z nim spotkać w epoce przedinformatycznej - podczas telefonizacji. Trudno było wykazać, jaki bezpośrednio zysk ona przynosi, ale zauważano, że wyłączenie telefonów w firmie dezorganizuje jej działalność.

Referencyjny holizm

W latach 80. zaczęto odchodzić od "siłowego" wykazywania, że informatyka jest opłacalna w kategoriach bezpośrednio materialnych i finansowych. Zauważono jej dyfuzyjność (przenikanie wszelkich działów przedsiębiorstwa) i kontekstowość (wartość danych zależy m.in. od ich interpretacji). Jednocześnie przetoczyła się dyskusja o "permanentnym kryzysie informatyki" i pojawiły się metody systemowej analizy strukturalnej, a następnie obiektowej. W ten sposób w latach 90. karierę zaczęły robić modele referencyjne ładu korporacyjnego. Pojawiło się jednak wiele systemów informatycznych o dużym stopniu złożoności i ogromnych kosztach, np. pakiety ERP.

Jak szacować ich efektywność?

Z pomocą przychodzi inżynieria wartości, korzystająca z podejścia tyleż referencyjnego, co holistycznego (całościowego). Implementacje IT także podlegają regułom klasycznego cyklu organizatorskiego: od sformułowania problemu projektowego, poprzez specyfikację zasobów niezbędnych dla jego realizacji, aż do końcowej kontroli wyników, prowadzącej z kolei do nowego cyklu.

Mamy zatem na początku projekt zgrubny systemu (draft), specyfikujący jego architekturę i modele badania jakości. To prowadzi do etapu wariantowania rozwiązań, którego wynikiem jest tzw. raport porównawczy, powstały na podstawie złożonych ofert (zewnętrznych/wewnętrznych). Na tej podstawie powstaje projekt szczegółowy (blueprint), a więc algorytmy modułów i ich integracji.

Elementy kwalifikowanej oceny systemu występują także (pośrednio lub bezpośrednio) w innych fazach jego cyklu życia (life cycle). Dotyczy to zwłaszcza fazy eksploatacji, kiedy uszczegóławiane są plany eskalacyjne włącznie z szacowaniem rodzajów ryzyka i możliwościami ich redukcji. W ten sposób charakterystyki pielęgnacyjne (maintenance) prowadzą do kolejnych wymagań dla wersji produktywnej (live).

Widzimy zatem, że całość systemu pozostaje w "magicznym trójkącie sił": czas, koszty, jakość (funkcjonalność) - podlegając dynamice cyklicznego ulepszania (CI - Countinous Improvement).

Modele wielodziedzinowe

Referencyjna implementacja IT w przedsiębiorstwie wymaga trzech modeli o charakterze interdyscyplinarnym:

1) modelu przedsiębiorstwa przedstawiającego jego stan faktyczny, tj. mapę procesów (mapping) z ich opisami;

2) modelu zmian, a więc tzw. mapy drogowej (road map), która ma prowadzić do określonego celu, czyli stanu wynikowego systemu;

3) modelu pomiarów, w szczególności informacji, jako podstawowego czynnika zmian (transformacyjnego).

Właśnie ostatni punkt dotyczy (analizy) inżynierii wartości (VE - value engineering), której stosowanie może prowadzić do efektów synergicznych w powiązaniu z innymi metodami zarządzania (jakością), np. Six Sigma. Holistyczne wartościowanie systemu oznacza bowiem także próbę pomiaru dla czynników trudnomierzalnych - do takowych właśnie należą informacje. Mogą one występować zarówno w postaci danych prostych, reprezentowanych jako podstawowe obiekty bazodanowe (np. pola rekordów), jak i w formie zagregowanej, czyli interpretowanej jako wiedza.

W praktyce inżynieria wartości opiera się na kilkufazowym cyklu obejmującym cztery elementy:

1) narzędzia o charakterze referencyjnym wyznaczające ramy tworzenia dokumentacji procesowej, np. standardy projektowe obejmujące schematy (template);

2) styl zarządzania (VM - value management) - dla tworzenia warunków dla osiągania zamierzonych celów, np. metody przydziału zasobów projektowych;

3) czynniki otoczenia organizacji (społeczne, gospodarcze, prawne) wpływające na czynności w zakresie inżynierii wartości (VE);

4) grupa projektowa definiowana według zasad VE, np. niewielkie zespoły z opcjonalnym udziałem użytkowników i ekspertów.

Do kluczowych faz inżynierii wartości należą:

- faza informacyjna, w której definiowane są ograniczenia (constraints), np. z użyciem analizy FMEA (Failure Modes and Effects Analysis);

- faza analityczna, dotycząca funkcji rozumianych jako cele, zadania czy oddziaływania kojarzone z produktem, np. techniki FAST (Function Analysis System Technique);

- faza kreatywna, generująca idee dla realizowanych funkcji, np. z użyciem techniki grupy nominalnej (nominal group technique - NGT);

- faza oceny, w której dokonuje się ewaluacji kosztu cyklu życia (LCC - Life Cycle Costing) z wykorzystaniem metryk wartości (value metrics).

Jak mierzyć

Praktyczny schemat opisywanego postępowania, w uproszczeniu, może wyglądać następująco:

1. benchmarking - identyfikacja sytuacji transformacyjnej i zdefiniowanie mierników wydajności;

2. business case - sytuacja gospodarcza i jej ocena ilościowa (kwantyfikacja) z użyciem określonych mierników dla kwalifikowanych szacowań efektów (np. racjonalizacyjnych);

3. priorytety - możliwe warianty rozwiązań i wyznaczenie strategii transformacyjnej na bazie kosztowo-efektowej;

4. walidacja planu projektu wraz z definicją szczegółowego studium transformacyjnego.

Kluczowe dla procesu decyzyjnego są pierwsze dwa punkty, które należy powiązać z referencyjnymi bazami danych, gromadzącymi informacje o projektach realizowanych w różnych przedsiębiorstwach. Po udzieleniu odpowiedzi na pytania kwestionariuszowe ustalany jest w takiej bazie profil organizacji, najbardziej odpowiadający już zakończonym projektom, co z kolei umożliwia prognozowanie efektów wdrożeniowych.

Dla przykładu, w systemie SVMC (SAP Value Management Center) kwerenda zawiera kilkadziesiąt punktów w następujących klasach:

- ogólna charakterystyka przedsiębiorstwa obejmująca: typ wytwórczości i metryki kosztowo-produktowe (obrót, asortyment) oraz logistyczne (np. procent realizowanych dostaw);

- koszty w podsystemach, np. dla wytwórczego - materiałów, robocizny, technologii, usług zewnętrznych;

- pracownicy bezpośrednio czy pośrednio wytwórczy, planiści, obsługa fabryki (plant maintenance), technicy, jakość, bezpieczeństwo i środowisko, zarządzanie, grupy optymalizacyjne czy integracyjne (focus teams);

- stosowane technologie IT (ERP/MES) - automatyka, poziom integracji procesowej czy elektronizacji logistyki, standaryzacja aplikacji;

- wdrażanie najlepszych praktyk (best practices) w planowaniu, wytwarzaniu (execution), zarządzaniu jakością, integracja (np. portale SCM), inteligencja wytwórcza (manufacturing intelligence), praktyki smukłe (lean), środowisko i bezpieczeństwo. Dla każdego z ostatniej grupy punktów specyfikowane są wagi danej praktyki dla przedsiębiorstwa (od 1 jako "nieistotnej" do 5 jako "ekstremalnie ważnej") oraz aktualnego poziomu jej stosowania (1="nie jest stosowana" do 5= "stosowana w pełni").