Za gdyńskim Prokomem stały doświadczenia firmy, która zaczęła tworzyć systemy zarządzania przedsiębiorstwem od 1987 r. Prokom zgodnie z uprawnieniami nadanymi mu przez Informix Software, kopiuje dyskietki z jego oprogramowaniem, z następnie prowadzi ich dystrybucję. Jest również dystrybutorem niezawodnego, ale i drogiego sprzętu komputerowego (m.in. Compaqa). Od lutego 1992 r. pod nazwą Prokom działają 2 firmy: Prokom Computer i Prokom Software. W 1991 r. w Prokomie uznano, iż firma powinna zainwestować w rozwój pakietu dla sektora bankowego.

Oprogramowanie z Prokomu powstawało już w 1987 r. Były to wówczas systemy do zarządzania przedsiębiorstwem. Każdy z tych systemów następnie pączkował. Zaczynano od pakietów FK, kadr, płac i technicznego przygotowania produkcji (TPP). Na początku lat 90. bankowość była dla Prokomu dziedziną nową.

Zdawano sobie natomiast sprawę, że do prac nad Probankiem trzeba będzie zatrudnić ludzi z zewnątrz. Złożyły się na to dwie przyczyny:

- osoby zatrudnione do tej pory, były zaabsorbowane innymi zajęciami

- wewnątrz firmy nie pracowali jeszcze fachowcy o wiedzy bankowej dostatecznej do tworzenia systemu od podstaw.

Organizacja pracy

W lipcu 1991 r. zespół fachowców do tworzenia nowego systemu został skompletowany. Zbudowano go praktycznie od zera. Część osób przyszła z Politechniki Gdańskiej, inna znowu grupa miała doświadczenie w bankowości. Na początku przy Probanku pracowały 4 osóby zatrudnione na stałe. Obecnie system jest rozwijany przez 7-osobowy trzon specjalistów.

Na stałe z pakietem jest związanych 12 osób z systemem Probank. Oprócz osób stale zatrudnionych, korzystano z

doradztwa pracowników Banku Gdańskiego. Potem do grupy konsultantów dokooptowano pracowników z banków małych i średnich. Bardzo pomocna okazała się współpraca z informatykami bankowymi. Byli to właściwie jedyni ludzie, którzy w pełni rozumieli uwarunkowania (i możliwości) firmy software'owej, a jednocześnie znali "od podszewki" zapotrzebowanie bankowców. Zatrudnieni konsultanci korzystali często z rad swoich kolegów, którzy pracują w banku na co dzień.

Przeznaczeniem tworzonego systemu były banki duże i średnie. W 1991 r. grupa banków średnich dopiero się krystalizowała, przejmując część kadry z dużych banków. Właśnie wówczas kształtowała się specyfika postępowania w średnich bankach. Nieraz okazywało się, iż pragmatyka przenoszona z dużego banku do banku średniego nie pasuje do potrzeb. Szef działu systemu Probank w Prokom Software, Zenon Beker zauważa: "W

dużym banku kładzie się nacisk na kontrolę końcowego wykonawcy (dysponenta), co znacznie ogranicza jego

możliwości. W szczególności jest bardzo ściśle wyznaczona kolejność działań. Często pytaliśmy konsultantów mających doświadczenie w dużych bankach, dlaczego ludzie postawieni tam przy ladzie są tak mocno ograniczeni. Odpowiedź teraz już znamy. W dużym banku pragmatyka jest znacznie bardziej zhierarchizowana niż w mniejszych organizacjach finansowych. W systemie Probank w niektórych przypadkach obecnie wycofujemy się z pewnych rozwiązań wzorowanych na bankach dużych, gdzie był kładziony przesadny nacisk na bezpieczeństwo. Dzieki temu system nasz staje się teraz bardziej elastyczny".

Predyspozycje kadry

Pracę nad systemem bankowym rozpoczęli ludzie, którzy znali się na bazach danych i projektowaniu systemów

wielodostępnych, czy przeszli od zagadnień systemów czasu rzeczywistego. Ale trzeba sobie zdawać sprawę, że stało za nimi kilkuletnie doświadczenie firmy. Główny projektant systemu finansowo-księgowego (FK'X) Tadeusz Dyrga był osobą wiodącą w tworzeniu projektu Probank. Nie korzystano oczywiście w najmniejszym stopniu z kodu źródłowego FK'X, ale doświadczenia tam zdobyte były istotne dla rozwoju Probanku. W systemie powstawały kolejno następujące moduły:

- ewidencja klientów i ich rachunków

- rejestrowanie dyspozycji

- obsługa kasowo-skarbcowa

- weryfikacja i księgowanie

- sporządzanie zestawień

- analiza i sprawozdawczość.

Moduły te oparto na głównej strukturze bazy zawierającej rachunki własne banku: w tej strukturze znajdują się także

rachunki klientów - osób fizycznych. Trzecia kartoteka, która jest oddzielona od pozostałych, zawiera dane klientów

o statusie osoby prawnej.

Całość Probanku napisano w dwóch narzędziach: dosyć tanim lecz aktualnie nie rozwijanym Informix Standard Engine oaz standardowym środowisku Informix Online. Do tego powstawały procedury wykorzystywane we wszystkich aplikacjach, potrzebne do prowadzenia takich czynności jak wstawianie nowych danych do struktury bazy, modyfikacje bazy, wyprowadzanie i usuwanie danych. Jak wiadomo sortowania w Informixie nie trzeba programować w aplikacji. To jest typowe żądanie do motoru bazy danych (Engine). Informix realizuje sortowanie jako standard SQL (Structured Query Language).

Co daje Informix

W Informix Standard Engine baza ma formę plików zorganizowanych zgodnie z wymogami systemu operacyjnego nad

którym jest posadowiona. Na przykład w Unixie są używane zarówno pliki odpowiadające nazwom tablic, jak i zbiorom organizacyjnym, przechowującym informacje o tym jakie dane można znaleźć w jakich kolumnach. Engine korzysta z pośrednictwa systemu operacyjnego. Jest to system tańszy, ale zarazem mniej efektywny.

Natomiast Informix Online w momencie instalacji "wydziera" z systemu operacyjnego część dysku i od tej pory system

operacyjny w ogóle jej nie widzi. Całkowitą kontrolę nad tą częścią pamięci masowej przejmuje system bazy danych

Informix. Zarządzanie częścią dysku wymaga większej wiedzy programistycznej. Tutaj trzeba wszystkie mechanizmy

zaprogramować samemu. Gdy np. zostanie zapisany cały dysk jako bufor pamięci, to nikt poza programistą tego nie

kontroluje. A więc w przypadku nieumiejętnej obsługi może to prowadzić do utraty danych. W zamian uzyskuje się oczywiście większą szybkość operacji.

System bankowy a FK

Początkowa koncepcja Probanku zakładała, że wszystkie operacje na jego bazie danych mają charakter transakcji.

Dotyczyło to zarówno dekretu księgowego, jak i zmiany imienia czy nazwiska. Założenie okazało się jednak dosyć

pracochłonne i na razie nie doczekało się realizacji. Kłopot wynikł stąd, iż na początku projektu nie udało się objąć

rejestrem wszystkich czynności. A mechanizm transakcji, żeby miał sens, musi być w aplikacji jednorodny.

Standardowy format transakcji daje się znacznie łatwiej zorganizować w systemie FK dla przedsiębiorstwa. Tam każdy dekret o tym kto jest "Winien", kto "Ma" i jaką kwotę, wprowadza konkretny człowiek. Każdy dokument składa się z 1, 2, 3 dekretów i dopiero te dekrety są wejściem dla FK. W przedsiębiorstwie dokumenty można obsługiwać w trybie off-line - pod nieobecność klienta. W banku czeka kolejka i niedopuszczalne jest, żeby rola systemu zaczynała się w momencie dekretu, który niejednokrotnie przeprowadza sama maszyna. To za późno. W banku trzeba wspomagać czynności już przy ladzie. Bo ileż pracy ręcznej zadałby sobie dysponent, gdyby jego klienci w ogóle zgodzili się korzystać z jego usług. Dlatego w systemie bankowym najważniejsze jest dobre obudowanie głównych czynności dekretowych bardzo wieloma drobnymi funkcjami typu: przyjęcie wpłaty, założenie rachunku terminowego, wypłata czy rozliczenie odsetek.

Dopiero w wyniku takich prostych operacji - niejako w tle - wykonuje się 1, 2 lub więcej dekretów.

Transakcyjność

Pojęcie transakcji w systemie FK dotyczy tylko dekretu. Tam nie ma adresów klientów. We własnej księgowości

przedsiębiorstwa, nawet jeśli gdzieś występują kontrahenci, to przydziela się im osobną kartotekę, przez co w dekrecie występują tylko we fragmencie identyfikatora konta. W banku natomiast pełne dane klienta występują zawsze. Oprócz danych typu księgowego pojawiają się informacje typu adresowego, kredyty, terminarze itd. Ponadto jest w banku wiele operacji, które, mimo że mają charakter transakcji, nie są operacjami typowo księgowymi.

Wprowadzenie jednolitej konwencji transakcji w dłuższej perspektywie rozwoju będzie więc zadaniem niezbędnym. Przy ujednoliconych definicjach transakcji wystarczy bowiem wówczas jedna tablica do obsługi historii wszystkich

operacji. Prowadzenie dla każdego pola oddzielnej tablicy uczyni system mało efektywnym, a także odpornym na

modyfikacje. Dla części danych, które stanowią wyjątek od ogólnych zasad prowadzenia transakcji, w miare rozbudowy systemu trzeba by było w takim przypadku dobudowywać dodatkowe struktury uwzględniające nowsze modyfikacje.

Narzędzia planowania i dokumentacji

Rozwinąć system bankowy to mało. Ale sprzedać tylko raz to też nie wszystko. Firma zamortyzuje nakłady na produkcję własnego systemu bankowego wtedy, gdy będzie go sprzedawała stale. Z kolei referencje dostawcy oprogramowania rosną dopiero wówczas, gdy on sam będzie się rozwijał. Chodzi o ochronę i zaspokojenie zmieniających się potrzeb klienta.

Prokomowy Probank składa się w tej chwili z ok. 130 odrębnych programów napisanych w Informixie. Każdy z

pracowników opiekuje się kilkunastoma programami. A program się dalej rozrasta i będzie się rozrastał. Trzeba więc

zwiększać liczbę zatrudnionych przy utrzymywaniu systemu i wtedy być bardziej narażonym na fluktuacje albo zdecydować się na lepsze narzędzia. Właśnie narzędzia CASE (Computer Aided Software Engineering) pozwalają opanować rozrastający się system. Prokom przygląda się obecnie produktowi holenderskiemu West Mount CASE, który nawet pozwala "cofać się do tyłu" od kodu napisanego dotąd bez CASE (nie tylko zresztą w Informixie) do jego pełnej dokumentacji. Generacja takich "post mortemów" wymaga odpowiedniego sterowania, gdyż trzeba podpowiadać systemowi "co właściwie autor miał na myśli".

Obecnie Prokom jeszcze w CASE nie pracuje. Być może m.in. dlatego, że Informix nie oferuje własnego narzędzia tej

kategorii, a jedynie interfejs. Tym niemniej już w tej chwili w Prokomie działa napisane w Informixie firmowe

narzędzie do wspomagania pracy dużego systemu. Jego działanie polega na tym, że każdy użytkownik zapisuje w

systemie notatkę o tym, co dzieje się niezgodnie z jego oczekiwaniami. Informacje te można wprowadzać mając nawet

bardzo niski priorytet dostępu. Można także wpisywać fragmenty wydruku, listingu itd. Co pewien czas szefowie

działu programistów przeglądają takie zgłoszenia, po czym następuje przydział zadań na zasadach podobnych do

prowadzenia projektu w pakiecie Microsoft Project.

Oczywiście przewidywania podziału czasu trzeba również rewidować, ale tego nawet najlepszy CASE nie uniknie, a co najwyżej przyspieszy.

(Z przyczyn telekomunikacyjnych, tekst nie został

autoryzowany przez firmę Prokom.)