Nie prościej niż prosto

Opisywany fenomen znany jest jako paradoks efektywności IT i polega na braku jednoznacznej korelacji między produktywnością przedsiębiorstwa a: udziałem nakładów na informatykę w całości inwestycji przedsiębiortswa, nakładami na informatykę w przeliczeniu na zatrudnionego, nakładami na informatykę w skali makro.

Tymczasem ocena efektywności wdrożenia IT wymaga określenia nakładów i efektów, zarówno ekonomicznych, jak i pozaekonomicznych. Precyzja stosowanych przy tym formuł matematycznych nie wyklucza możliwości manipulowania wiązanymi przez nie wartościami. Zatem ta sama innowacja może być uznana za efektywną bądź nieefektywną, w zależności od przyjętych kryteriów.

Widzimy więc, że einsteinowski aforyzm "wszystko należy robić tak prosto jak tylko możliwe, ale nie prościej" niewiele nam tu pomoże. Praktyczną trudnością nie są przede wszystkim zbyt proste modele przedsiębiorstwa, ale ich wątpliwe interpretacje. Większym problemem wydaje się być nawet nadmierna złożoność stosowanych modeli prowadząca do tzw. syndromu MINO (Model In Name Only), czyli modelu tylko z nazwy, tzn. wybiórczego stosowania modelu w odniesieniu do pojedynczych składników, bez głębszej analizy i zwracania uwagi na całość metodyki.

W takiej sytuacji dokumentacja, która jest nieodzowna podczas stosowania modelu referencyjnego, staje się celem samym w sobie, prowadząc nawet do niepowodzeń projektowych, wskutek przerostów biurokracji organizacyjnej (problem bardzo dużych firm). Jednocześnie konieczność regularnej wymiany informacji między uczestnikami projektu prowokuje niekończące się ciągi bezproduktywnych spotkań, ograniczające ilość czasu na rzeczywiste implementacje. Z kolei dla małych projektów, zbyt ścisłe przestrzeganie procedur referencyjnych może być bardzo pracochłonne i w takim przypadku niezbędna jest adaptacja modelu, uwzględniająca lokalne realia biznesowe.

Wspólny język

Kluczowe znaczenie dla modelowania mają zatem konwencje językowe. W sferze IT swoistym modelem może być kod aplikacji lub jego fragmenty. Złożoność/nieczytelność takiego kodu, tym większa im niższy poziom zastosowanego narzędzia programistycznego, wyklucza w praktyce posługiwanie się nim jako modelem. Natomiast jego dokumentacja, w sensie inżynierii software’owej, może być wartościowym modelem procesu biznesowego i tworzona jest także z wykorzystaniem języków (konwencji) sztucznych. Wymieńmy tu takie metody dokumentowania kodu jak: schematy blokowe (normowane, flowcharts, ISO5807); diagramy przepływu DFD (Data Flow Diagram); schematy organizacyjne (organigramy, struktogramy Nassi-Schneidermann); pseudokod (języki uproszczone np. Pidgin Algol); notacje - UML (Unified Modeling Language), ERM (Entity Relationship Model), OOA (Object-Oriented Analysis).

Nieprzypadkowo znajdziemy je także w modelach przedsiębiorstwa, mimo że dokumentacja oprogramowania firmy nie jest automatycznie jej modelem. Inny jest z założenia cel tworzenia modeli przedsiębiorstwa, a inny modeli systemów informatycznych. Niemniej, zarządzanie może być interpretowane jako przetwarzanie informacji, stąd zbieżność obu podejść - modelowania IT i przedsiębiorstwa.

Jednocześnie kontekst dokumentacji nie wystarcza, aby w każdej sytuacji zidentyfikować znaczenie terminu biznesowego. Można co prawda w razie potrzeby poprosić określone osoby o komentarz, ale wiąże się to z dodatkowym czasem. Warto więc zdefiniować określone konwencje terminologiczne (słowniki), pozwalające na oszczędność słów bez strat precyzji przekazu. Jedną z nich może być stosowanie warstwowości terminologicznej w modelowaniu procesu biznesowego.