Ograniczenia systemu informatycznego mogą być pułapką dla firmy.

Wyobraźmy sobie wdrożenie idealne. Grupa menedżerów wyższego i średniego szczebla wykonuje analizę swoich potrzeb. Następnie wybierają konsultanta, który przeprowadza w imieniu klienta studium wykonalności, a po nim przetarg. W efekcie wyłoniony zostaje dostawca, który rozpoczyna przygotowanie wdrożenia. Opisane zostają odpowiednie procesy biznesowe, wykonane zostają odpowiednie aplikacje oraz wspierająca je dokumentacja i infrastruktura, system jest instalowany, użytkownicy i personel techniczny są szkoleni, system jest uruchamiany i... określonego dnia działa. Strzelają korki od szampana, przelewy wędrują po bankowych łączach, zaś prasa branżowa opisuje success story na pierwszych stronach.

Wdrożenie idealne? Niedługo później zaczynają się problemy. Zmienia się nagle potrzeba biznesowa: firma, która pozyskiwała dotychczas klientów bezpośrednio, zaczyna korzystać z pośrednictwa agentów. Pojawia się potrzeba integracji jej procesów biznesowych z procesami biznesowymi innej organizacji. Zadanie, które wcześniej było do rozwiązania za pomocą kilku poleceń, małej reorganizacji i ustalenia zasad współpracy, nagle wiąże się ze zmianą systemu informatycznego.

Szczęśliwy, komu dostawca powie, że nie ma problemu, dokona odpowiednich zmian za niewygórowaną sumę i wdroży zmianę w rozsądnym czasie. Niestety, bardziej prawdopodobny jest inny scenariusz: dostawca powie, że zmianę - owszem - jest w stanie wykonać i wdrożyć, ale nie zaraz i nie za rozsądną kwotę. Jest także wariant pesymistyczny - dostawca powie, że tego rodzaju integracja jest niemożliwa bez zmiany architektury całego systemu, a to kosztuje... tyle, co nowy system.

Dlaczego wdrożenie, które w krótkim okresie wyglądało na ideał, w długim okazało się porażką? Dlaczego firma nie uwzgędniła elastyczności systemu w wymaganiach? Jak poważne mogą być dla firmy ograniczenia, które wymusza system informatyczny?

Zwyczajne ograniczenie

Idealizm menedżerów i informatyków każe im sądzić, że informatyzacja przedsiębiorstwa wiąże się dla niego z bezsprzecznymi korzyściami. Rzeczywiście - mądrze pomyślana i dobrze przeprowadzona informatyzacja to kapitalne atuty dla firmy. W dzisiejszych czasach zresztą oparcie procesów biznesowych na technologiach informatycznych nie jest żadną zaletą ani przewagą na rynku, a standardem - trudno wyobrazić sobie księgowość średniej firmy prowadzoną bez użycia komputerów.

Ale informatyka to także ograniczenie. Zmiana natury całego systemu biznesowego z czysto ludzkiego na ludzko-technologiczny zmienia reguły gry. Rzecz nie w tym, żeby budować systemy, które będą w stanie każdą wyobrażalną i niewyobrażalną zmianę swobodnie przetrwać. Rzecz w tym, by zdawać sobie sprawę z ograniczeń, jakim podlega nasz system (albo nasza grupa systemów) i dobrze rozumieć, co te ograniczenia znaczą dla przedsiębiorstwa.

A więc po kolei. Najczęściej spotykane ograniczenie, podane jako przykład powyżej, to elastyczność systemów. Zmiana w procesach, które wspierają dany system, wymaga modyfikacji systemu. Taka zmiana dla systemów kupowanych "z półki" jest niemożliwa; natomiast dla rozwiązań dopasowywalnych ("customizowalnych"), do których można zaliczyć większość systemów ERP, wymaga przemyślenia, przetestowania i planowanego wdrożenia. Pociąga też za sobą koszty. Czas koniecznych modyfikacji i nakłady na nie muszą być uwzględniane, gdy organizacja planuje konieczne zmiany.

Skalowalność systemu to kolejne źródło ograniczeń. Menedżerowie (w szczególności w Polsce, gdzie system edukacji ekonomicznej nadal oparty jest niemal wyłącznie o przykłady z dziedziny masowej produkcji przemysłowej) posługują się prostym schematem: zwiększony popyt -> zwiększone zasoby -> zwiększona produkcja -> większy zysk. Zaś funkcja, którą stosują w takim myśleniu, z reguły jest liniowa (dwa razy większy popyt = dwa razy większa produkcja = dwa razy większy zysk). Tymczasem informatyk musi takiemu menedżerowi powiedzieć, że np. dwukrotne zwiększenie skali działania systemu (np. zastosowanie go dla nowej grupy klientów) wymaga jedynie nakładów o 30% większych i nowe możliwości dostępne będą w ciągu dni. Natomiast już czterokrotne zwiększenie skali wymaga poniesienia nakładów czterokrotnie większych, zaś czas zmiany liczy się w tygodniach. A gdy skala zwiększy się dziesięciokrotnie, konieczne będzie poniesienie kosztów dziesięciokrotnie większych i odczekanie od roku do półtora. Dla informatyka to proste: w drugim przypadku trzeba wzmocnić infrastrukturę (np. dokupić nowy serwer). W trzecim zaś - całkowicie zmienić architekturę aplikacji (czyli przepisać ją od nowa). Dla menedżera to po prostu niezrozumiałe.

Dostępność - kolejne źródło ograniczeń - częściowo związana jest ze skalowalnością, choć dotyczy też jakości. Podajmy przykład aplikacji sprzedażowej, która dotychczas stosowana była przez przedsiębiorstwo w głównej siedzibie i w regionalnych centrach dystrybucyjnych. Teraz firma powołuje call center, w którym chce prowadzić sprzedaż przez 16 godzin na dobę. Udostępnienie tej samej funkcjonalności - "to samo, ale w innym miejscu i dłużej", może mieć takie same konsekwencje jak zmiana skali: niewielki wzrost kosztów i niedługi czas na przystosowanie, istotne zmiany w kosztach poprzedzone średnim okresem przystosowania albo całkowita zmiana systemu.

Nawiasem mówiąc, problemy informatyków z elastycznością aplikacji nie są niczym nowym. Podobną zmianę przechodziła ludzkość w XIX i na początku XX wieku, kiedy w fabrykach na dobre zagościły maszyny i poważna zmiana w procesie wymagała nie tylko przeszkolenia ludzi, ale i wymiany maszyn. To, co było błogosławieństwem dla działającego niezmiennie procesu produkcyjnego, stało się przekleństwem przy zmianie... czy to nie brzmi znajomo?

Klucz w ręku informatyków

Każda zmiana w systemie oznacza czas i nakłady. Organizacja jest zainteresowana, żeby zmiana była wdrożona szybko i tanio; informatycy chcieliby wesprzeć biznes, ale podlegają ograniczeniom swoich systemów. Czy można coś z tym zrobić?

Oczywiście, można. Najwięcej mogą zrobić sami informatycy, choć oni sami pewnie chcieliby myśleć, że więcej do zrobienia jest po stronie odbiorcy biznesowego. A więc - przede wszystkim powinniśmy jasno komunikować, jakie systemy mają ograniczenia i co z nich wynika.

Jeśli więc mamy aplikację dwuwarstwową, samodzielnie wykonaną przez personel firmy w technologii grubego klienta, przy użyciu narzędzi takich jak Visual Studio, ODBC i SQL Server, komunikat sformułowany do tzw. biznesu powinien brzmieć następująco: możemy w miarę łatwo i szybko robić przyrostowe zmiany do aplikacji oraz zwiększyć jej skalę do 50%, pod warunkiem, że wszyscy użytkownicy będą pracowali w siedzibie firmy. Aby podnieść jej niezawodność i bezpieczeństwo, trzeba będzie zainwestować ok. 200 tys. złotych w infrastrukturę, zaś zrobienie poważnej rozbudowy musi trwać od trzech miesięcy wzwyż. Taki komunikat nie jest oparty o "technikalia", a katogorie biznesowe (czas, pieniądze, ryzyko), a jednocześnie jasno informuje, co można, a czego nie.

Jeśli jednocześnie informatycy będą angażować się w każde przedsięwzięcie, które rozpoczyna strona biznesowa, odpowiednio wcześnie będą w stanie zrecenzować plany pod kątem systemów: to jest możliwe, pod warunkiem, że wzmocnimy główny serwer i sieć rozległą. To będzie kosztować między 30 a 50 tys. złotych i trwać ok. 6 tygodni. Tego rodzaju rady oczekuje strona biznesowa.

Jednocześnie wyraźne powiązanie inwestycji w informatykę z przedsięwzięciem biznesowym (i jego korzyścią) pozwala osiągnąć to, czego informatykom zawsze brakuje - a więc zrozumienie potrzeby inwestycji informatycznych przez tych, którzy te inwestycje finansują.

Patrzeć na systemy strategicznie

Ale najbardziej pełna odpowiedź jest jednocześnie najmniej "poprawna politycznie". Otóż informatyków uczy się, by robili systemy zgodne z wymaganiami odbiorców. Problem polega na tym, że wymagania odbiorców się zmieniają, a i sami odbiorcy nie zawsze potrafią podać pełne i kompletne wymagania. Menedżerowie mają tendencję do myślenia w krótkiej perspektywie i znajdują się pod presją wyniku finansowego na najbliższy kwartał. Nie na darmo John Maynard Keynes, ojciec makroekonomii, mawiał: w długim okresie wszyscy będziemy martwi.

Jeśli menedżerowie informatyki mają dużo wyobraźni i siły przekonywania, antycypują potencjalne kierunki zmian i tak budują (albo zamawiają) system, by mógł się rozwijać w tych kierunkach. Jeśli nie (i jeśli podlegają ścisłym ograniczeniom budżetowym) zamawiają lub budują system dokładnie pod wymagania - nieaktualne w momencie wdrożenia systemu (jeśli nie wcześniej). Dlatego tak naprawdę na rozwój systemów informatycznych powinno się patrzeć bardziej dłufofalowo, rozwijając je nie w rytmie konkretnych projektów biznesowych (czyli patrząc w perspektywie kilkumiesięcznej), a w rytmie strategicznych kierunków rozwoju biznesu.