Z formalnego punktu widzenia, systemy komputerowego wspomagania zarządzania współczesnym przedsiębiorstwem opierają się na rozwiązaniach standardowych. Dotyczy to nie tylko oprogramowania narzędziowego, takiego jak określone typy baz danych, ale także aplikacji dla końcowego użytkownika, np. wspomagających dział sprzedaży. Opisywana zależność jest wprost proporcjonalna do wielkości przedsiębiorstwa: im większa firma, tym większe prawdopodobieństwo, że korzysta ona z uniwersalnych modułów ERP lub ich odpowiedników (pakiety innych systemów o podobnej funkcjonalności). Z drugiej strony procesy globalizacyjne powodują, że nawet małe firmy korzystają z informatycznych standardów, stając się bezpośrednio lub pośrednio częścią koncernów lub ich partnerami.

Czy zatem software’owy standard ma same zalety w porównaniu z rozwiązaniem indywidualnym? Przede wszystkim samo pojęcie „standardu“ jest wieloznaczne. W przypadku rozwiązań technicznych (np. protokoły teleinformatyczne) mamy jedynie do czynienia z minimalnymi wymogami ramowymi i zapewniającymi wymianę danych między nadawca a odbiorcą, bez definiowania ich zawartości. Również standardy aplikacyjne, np. EDIFACT (Electronic Data Interchange For Administration Commerce and Transport), nie zagwarantują nam automatycznie poprawności wystawianych rachunków. W praktyce użycie standardów informatycznych powinno wynikać z analizy procesów biznesowych na drodze postępowania referencyjnego (zdefiniowana metodyka i modele).

Niezbędna jest przy tym kastomizacja systemu (customizing), czyli jego firmowa indywidualizacja, począwszy od lokalizacji językowej (np. jednoznaczność stosowanej terminologii) aż do oprogramowania interfejsowego, integrującego podsystemy. Dotykamy tu zatem działań wdrożeniowych, tj. indywidualnych dopasowań programistycznych z wykorzystaniem własnego lub zewnętrznego personelu (doradcy).

Przedsiębiorstwo 1.0

W efekcie zakupiony standard typu „System X wersja Y kropka Z“ przekształca się w unikalne rozwiązanie, które można opatrzyć etykietką: „Nasza Firma 1.0”. Czy mamy tu jeszcze do czynienia ze standardem czy jednak już z rozwiązaniem indywidualnym? Na pewno mamy aplikację, co najmniej standardowo-bazowaną a to stanowi istotną i pozytywną różnicę w porównaniu z systemem wyłącznie indywidualnym. Z reguły bowiem w typowym przedsiębiorstwie korzystniejsze jest unikanie stosowanie rozwiązań indywidualnych. Wiąże się to również z generalną zasadą outsourcingu: nie delegujemy na zewnątrz tego, w czym mamy tak wysokie kompetencje, że sami możemy świadczyć innym usługi. Innymi słowy, pytanie brzmi: czy jako przedsiębiorstwo przemysłowe jesteśmy w stanie tworzyć profesjonalne oprogramowanie zarządzania produkcją, czy też lepiej powierzyć to zadanie wyspecjalizowanym firmom?

Przykład. Jeżeli produkujemy drzwi, to w tym obszarze powinniśmy szukać największych możliwości biznesowych, zostawiając programowanie branży software’owej. Jej programiści również będą zaopatrywać się w stolarkę u specjalisty, zamiast zbijać sobie własną, z surowych desek. Porównanie nie jest do końca trafne, bo chociaż firmy software nie mają własnego działu stolarzy, to jednak przedsiębiorstwa meblarskie jak najbardziej mogą mieć własnych informatyków. Użyta metafora ma zwrócić uwagę na niebezpieczeństwa związane z niekontrolowanym przekształcaniem się informatycznego działu przedsiębiorstwa przemysłowego w rodzaj szybko rozrastającej się firmy software’owej.

Mówimy także o granicach modyfikowalności standardów, a więc zdefiniowaniu tego, co wolno nam zrobić, bez utraty kompatybilności z ich przyszłymi wersjami. Taka strata pociąga bowiem za sobą dodatkowe koszty migracyjne. Tymczasem w opłacanych przez nas umowach serwisowych mamy też opcje przechodzenia do nowszego oprogramowania, które z czasem stają się obligatoryjne (brak wspomagania starszych wersji). Pamiętajmy również, że rozbudowane oprogramowanie, zależne od jednego pracownika, dobrze funkcjonuje tylko tak długo, jak długo jest przez niego pielęgnowane. Niestety, zdarza się, że dopiero gdy taka osoba przestaje pracować w naszej firmie, występuje „efekt aha”, którego konsekwencje zawarto w tabeli 1.

Opóźnienie przez przyspieszenie

Pokazane przykłady dotyczą „syndromu błędnych kół”, w jakie wpadają projektanci oprogramowania i ich menedżerowie, jeśli nie stosują referencyjnych metodyk. Rzeczywistość informacyjna oznacza bowiem wszechzwiązki połączeń na zasadzie „wszystkiego ze wszystkim” – każdy błąd pociąga następny. W skrajnym przypadku może prowadzić to do niekontrolowanego wysypu problemów na zasadzie: „stary program to stare błędy, nowy program to nowe błędy i… stare błędy”. Dla ilustracji pokażemy sytuację określaną jako „opóźnienie wskutek przyspieszenia”:

- zespół projektowy znajduje się pod presją z przyczyn organizacyjnych (oczekiwania

kierownictwa);

- czas projektu zostaje zdefiniowany nierealistycznie (niedoszacowany);

- błędne szacowania czasów projektu (poszczególnych faz) powodują kumulację

opóźnień;

- w celu redukcji opóźnień podjęta zostaje decyzja o powiększeniu grupy projektowej;

- większy personel oznacza ponadplanowy wzrost kosztów przedsięwzięcia;

- dodatkowy czas jest niezbędny na integrację projektową nowych członków zespołu;

- wzrost opóźnienia może prowadzić do, pozornie konsekwentnego, rozszerzania liczby członków zespołu;

- w efekcie występuje możliwość słabo kontrolowanego wzrostu chaosu organizacyjnego;

- w skrajnej sytuacji dochodzi do załamania projektu.

Zalecanym wyjściem z pułapki jest „ucieczka do przodu”: podjęcie decyzji o całościowej reorganizacji projektu. W praktyce oznacza to przerwanie pierwotnie założonego planu i zastąpienie go nowym, realistycznym. Z przyczyn politycznych, tj. pozatechnicznych, takie opcje są mało popularne. Oznaczają przecież przyznanie się do popełnienia błędów organizacyjnych ze strony kierownictwa.

Warto zatem korzystać już w fazie planowania z metryk oferowanych w ramach inżynierii oprogramowania. Przykładem takiej metryki jest rozkład gęstości prawdopodobieństwa Weibulla-Rayleigha, stosowany także w innych dziedzinach, np. podczas analizy niezawodności urządzeń. Bez podawania literaturowych formuł statystycznych można stwierdzić, że krzywa ilości znajdowanych błędów oprogramowania narasta w miarę przebiegu projektu, osiągając maksimum odpowiadające fazie testów integracyjnych (intensywne badanie kodu, debugging). Z kolei zakończenie tego etapu oznacza w praktyce wyeliminowanie większości możliwych problemów (ok. 60–70%). Uwzględnianie tej i innych metryk software’owych pozwala zatem na lepsze rozłożenie zmiennych potrzeb czasowo-osobowych dla realizacji przedsięwzięcia.