Wzrastająca złożoność systemów i coraz silniejsze zależności między elementami informatycznej układanki w przedsiębiorstwie będą wymuszać coraz większy akcent położony na jakość.

Rok 2003 był pierwszym od kilku lat rokiem wyraźnego wzrostu rynku. Rozpoczynające się ożywienie nie oznacza, że dobre czasy wrócą dla wszystkich. Rok temu, gdy recesja jeszcze była odczuwalna, przewidywano, że ci, którzy wykorzystali spowolnienie na rynku do głębokiej przebudowy swoich procesów biznesowych oraz zwiększyli wysiłki na rzecz jakości, zbiorą największe żniwa, kiedy tylko rynek odzyska witalność. Dziś nadszedł taki czas i każda firma powinna zadać sobie pytanie: Co zrobiliśmy dla lepszej jakości?

Wysiłki, które w poprzednich latach włożono w podniesienie jakości systemów informatycznych, nadal czekają na mierzalny zwrot z inwestycji. Jeżeli zwrotu takiego trudno się doliczyć, należy sobie postawić pytanie: Czy podjęcie tych wysiłków miało cel inny niż marketingowy? Jeżeli ktoś cztery lata temu zdobył certyfikat ISO 9001, to czemu - poza umieszczeniem gustownej naklejki na folderach reklamowych - to służyło? Klienci, którzy jeszcze trzy lata temu pytali: "Jakie certyfikaty jakości ma Państwa firma", zaczęli stawiać inne, dalece poważniejsze pytanie: "Proszę pokazać, jaką wartość dodaną przynoszą nam certyfikaty jakości posiadane przez Państwa firmę". Biada tym, których takie pytanie zaskoczy i nie będą potrafili na nie odpowiedzieć.

Parametry i harmonogramy

To, co kiedyś stanowiło o przewadze konkurencyjnej, w roku 2003 stało się standardem oferty. Niegdyś elementami kontraktu były specyfikacja dostarczonych produktów i usług oraz ich wycena. Dziś, dodatkowo, kluczowe stają się dwa elementy: harmonogram i parametry jakościowe.

Harmonogram kontraktu to nie tylko kilka punktów w czasie, określających najważniejsze zdarzenia podczas realizacji umowy, ale konkretne, obserwowalne i mierzalne zdarzenia. Z reguły to grupa dokładnie opisanych krok po kroku testów, które rozwiązanie musi przejść w określonym momencie. W 2003 r. wiele przedsiębiorstw integracyjnych, szczególnie wielkich międzynarodowych korporacji, oferowało swoim klientom usługi, w myśl których płatność następowała dopiero po spełnieniu takich parametrów. Szef informatyki, który w typowej firmie odpowiada za stabilność i dostępność systemów, mając do wyboru umowę standardową czy umowę z płatnościami ściśle związanymi z mierzalnymi parametrami i postępem harmonogramu, wybierze tę drugą, choćby nawet miał więcej zapłacić. Właśnie taka postawa przesądziła o tym, że to "wielcy" zebrali konfitury z budzącego się rynku w minionym roku.

Wreszcie, standardem stają się umowy SLA. I znowu rolę prymusów grają międzynarodowe firmy obecne na polskim rynku, które "importują" umowy SLA, starając się je ewentualnie przystosować do polskich warunków, np. ogólnie niższego poziomu infrastruktury telekomunikacyjnej oraz mniejszej stabilności otoczenia makroekonomicznego i instytucjonalnego.

Warto dodać, że w roku 2003 świadomość klientów nie była jeszcze na tyle wysoka, żeby pozwalała samemu formułować oczekiwania klienta w takich umowach. Z reguły wyglądało to tak, że partner informatyczny wraz z produktem oferuje standardową umowę SLA i kwestią negocjacji jest jedynie poziom parametrów oraz opłaty za nie. Rok 2004 najprawdopodobniej przyniesie coraz większą świadomość klientów i - co za tym idzie - ich bardziej aktywną rolę w procesie negocjacji takich umów. Zamiast być skazani na to, co oferuje wykonawca, zaczną stawiać wymagania, których źródłem będą ich potrzeby biznesowe i rynek, na którym funkcjonują. Umowy SLA staną się więc pochodną procesów biznesowych, a nie prostym wypełnieniem szablonów dostarczanych przez korporacje.

Jakość z rządu

Wraz z powstaniem Ministerstwa Nauki i Informatyzacji pojawiła się szansa, iż polski rząd wreszcie zacznie robić to, od czego tak naprawdę należało zacząć informatyzację: czyli zacznie publikować standardy i normy jakościowe, które będą obowiązywały w kontaktach z instytucjami publicznymi. Przedsiębiorstwa, które chcą działać na rynku publicznym, muszą podporządkowywać się tym standardom. Po pewnym czasie zaczynają je stosować między sobą i w ten sposób standardy rządowe rozpowszechniają się także na rynek B2B.

Na razie jednak działania osób odpowiedzialnych za informatyzację wzbudzają mieszane uczucia. Z jednej strony, pojawiają się prawdziwa troska o jakość oraz pragnienie uporządkowania kontaktów publiczno-prywatnych w sferze informatycznej, którego wyrazem jest ustawa o informatyzacji, z drugiej, widać wyraźnie, że wprowadzenie porządku w informatyzacji decydenci widzą przede wszystkim w represyjnym prawie i policyjnej kontroli. Warto przypomnieć, że te standardy rządowe, które stały się rzeczywistymi normami przemysłowymi, odniosły sukces nie dlatego że przewidywano kary za ich niestosowanie, a dlatego że były po prostu dobre. Memento niechaj stanowi Ustawa o podpisie elektronicznym, która tak naprawdę do dzisiaj pozostaje martwym prawem. To, że do dziś nie mamy w komputerach czytników kart i nie załatwiamy spraw publicznych za pomocą karty chipowej z kluczem prywatnym, jest wynikiem represyjnej i niejasnej ustawy oraz wymuszonych przez nią nadmiernych kosztów związanych z infrastrukturą oraz użytkowaniem podpisu elektronicznego.

Najwyższy czas, byśmy - mówiąc o czymś "standard rządowy" - mieli na myśli nie tylko nieudolność, niekompetencję i korupcję, lecz także prawdziwe standardy techniczne i organizacyjne, takie choćby jak amerykańskie (CMM, HACCP) albo brytyjskie (PRINCE2, ITIL). Duża nadzieja w Unii Europejskiej, która posiada spory dorobek standaryzacyjny. De iure przyjmiemy te standardy już w maju br., a de facto w ciągu najbliższych kilku lat. Rok 2004 powinien przynieść odpowiedź na pytanie: Czy rzeczywiście integracja z UE przyniesie Polsce tak potrzebne publiczne standardy informatyczne, a także czy fundusze unijne przewidziane na poprawę jakości w przedsiębiorstwach zostaną właściwie wykorzystane.

Testowanie z narzędziem

W roku 2003 miał miejsce fakt bardzo doniosły w swojej symbolice. Otwarto w Polsce biuro firmy Compuware, dostarczającej narzędzia do testowania. Najwyższy czas, chciałoby się powiedzieć! O ile w Polsce od dawna działały przedstawicielstwa firm dostarczających narzędzia do zarządzania wymaganiami, analizy i projektowania systemów, programowania, a także zarządzania już wdrożonymi produktami, o tyle testowanie pozostawało zaniedbanym ugorem, który należało zaorać i obsiać. Ziarno zasiane w roku ubiegłym przyniesie owoce za kilka lat. "Tester" przestanie powoli być niższym, skrycie lekceważonym gatunkiem informatyka, zaś testowanie stanie się jedną z najistotniejszych faz przedsięwzięcia informatycznego. Widać to już dzisiaj po ofercie kursów: testowanie oprogramowania stało się jednym z istotniejszych i popularniejszych tematów. W roku 2004 powinniśmy obserwować, jak nazwy narzędzi i metodyk testowania zaczynają funkcjonować w potocznym obiegu.

Dużo jednak zależy od samych klientów. Jeżeli wierzyć szefom projektów informatycznych, wielu z nich, widząc pozycję "testowanie" w cenniku systemu, proponowało zrezygnowanie z tego elementu w celu obniżenia całkowitej ceny oferty. Oczywiście, potem płacili tę cenę w dwójnasób, ale nie w tak widoczny sposób i rozłożoną na lata.

Wzrastająca złożoność systemów oraz coraz silniejsze zależności między elementami informatycznej układanki w przedsiębiorstwie będą wymuszać coraz większy akcent położony na testowanie. Jeżeli firma dysponuje systemem finansowo-księgowym zasilanym danymi z systemów obsługujących sprzedaż, zamówienia, produkcję, logistykę i planowanie, to każda zmiana wykonana w tym systemie może potencjalnie wywoływać błędy w działaniu któregoś ze zintegrowanych systemów. Wdrożenie nowej wersji jednego z tych systemów musi być poprzedzone gruntowym zaplanowaniem oraz przetestowaniem całości. Jak to zrobić bez narzędzia? Można oczywiście skłonić eksperta, aby narysował ścieżki regresji w takim złożonym systemie, a następnie zatrudnić sztab ludzi, by pracowicie wykonał wszystkie niezbędne testy. Można też od początku użyć specjalizowanego systemu informatycznego, w którym odwzoruje się współzależności komponentów informatycznych, zamodeluje odpowiednie scenariusze, a następnie zasymuluje działanie użytkowników. Można być pewnym, że w 2004 r. i nadchodzących latach coraz więcej przedsiębiorstw będzie wybierać ten drugi wariant. Wiąże się on z pewnymi inwestycjami (tak w narzędzia, jak i wiedzę), ale w długim okresie się opłaca.

Sprzężenie zwrotne

Inwestycje w jakość systemów informatycznych dopiero się zaczynają. W roku 2003 widać je było po ofercie kursów, ale jeszcze nie po produktach i usługach informatycznych. To dobrze, że organizacje zasilają się wiedzą; nie ma natomiast wątpliwości, iż to dopiero początek.

Wiadomo po czym można poznać, że jakość jest ważna dla wszystkich graczy na rynku - zarówno dla klientów, jak i dostawców. To moment, gdy pojawia się dodatnie sprzężenie zwrotne. Odbiorcy domagają się gwarancji jakości od swoich dostawców; ci zaś uważają za naturalne, że takich gwarancji udzielają. Na rynku obecne są szeroko akceptowane standardy i poziomy serwisów (SLA) oraz przynajmniej kilkanaście równorzędnych firm, które są w stanie dostarczać produkty i usługi na danym poziomie. Klient nie pyta: "Czy system będzie działał?", tylko: "Ile muszę zapłacić za dostępność na poziomie 99,99%". Do takiego stanu zmierzamy i na tę chwilę wydaje się, że rok 2004 przesunie nas w tym kierunku tak bardzo jak żaden wcześniejszy.

Za rok zweryfikujemy, czy rzeczywiście tak się stało. Wiemy, co będzie oznaczało, jeśli nie.