Wrocławskie Przedsiębiorstwo Techniki Bankowej elba (nazwa pisana zwyczajowo z małej litery) zostało założone w

październiku 1988 r. jako spółka dwóch instytucji: NBP w Warszawie i Zakładów Elektronicznych Elwro we Wrocławiu. Spółkę sprywatyzowano w 1990 r. Firma do tej pory była znana z produkcji pojedynczych modułów do obsługi zasadniczych obszarów działalności banku, takich jak SAPOD/ADYS, Lokaty czy Kredyty. Obecnie w fazie zaawansowanych testów znajduje się jej nowy zintegrowany system skarb.

Elektroniką bankową firma zajmowała się od początku swojego istnienia. Był to jej jedyny obszar zainteresowań. Pracowali tu zarówno specjaliści od informatyki przemysłowej, mający za sobą doświadczenie wyniesione z Elwro, działali ludzie z NBP oraz naukowcy z Politechniki Wrocławskiej. Obecnie właśnie ta uczelnia jest najbardziej obfitym źródłem dopływu młodej kadry PTB elba.

Początki

były oczywiście trudne, jak życie większości ludzi, którzy chcieli zarobić, własnym intelekcie w epoce, gdy w

wytycznych resortowych centralnych planów badawczo-rozwojowych (CPBR-ów) znajdowały się passusy, iż sprzęt komputerowy należy kupować, a oprogramowanie "pozyskiwać innymi sposobami". Jeszcze w 1989 r. elba zatrudniała 14 osób, przy obrocie całkowitym równym 800 mln zł. Obecnie pracuje tu 51 osób, a obroty wyniosły 13,8 mld zł w 1991 r. i 10,0 w rok później. Ten ostatni spadek obrotów wynika najprawdopodobniej stąd, że elba już w 1992 r. zainwestowała istotny procent swojego potencjału w rozwój firmy i systemu skarb nowoczesnymi technikami.

To, że udziałowcem PTB elba był Narodowy Bank Polski stawiało przed firmą określone zadania, choć z drugiej

strony otwierało pewne możliwości. Należy sądzić, iż NBP wyemanował z siebie spółkę elba, ponieważ zrozumiał, że nie tylko może, ale musi skorzystać z dziejącej się rewolucji "pecetowej". Problemem głównym było zapewne, jak to zrobić. Prawdopodobnie oceniono, że dla ośrodka obliczeniowego NBP we Wrocławiu byłoby to za trudne z powodu bieżących zadań operacyjnych. Trzeba bowiem pamiętać, że dzienne przetwarzanie danych NBP odbywało się i odbywa za pomocą dużych komputerów IBM i 20-letniego już Systemu Operacji Bankowych (SOB).

SAPOD pół-zintegrowany

Pierwszym zadaniem spółki elba było zaprojektowanie i napisanie programów dla PC, pozwalających dostarczać w

trybie off-line dane do SOB. Tak powstał System Automatyzacji Procesu Opracowywania Dowodów Księgowych

SAPOD, który integrował stworzone równolegle inne moduły dla oddziału banku. Ważniejsze z tych modułów to ADYS (Arkusz Dysponenta), Lokaty, Kredyty i Sezam (kontrola zastrzeżeń). System został napisany w języku C wspomaganym kilkoma bibliotekami. Był (i jest) instalowany w dwóch środowiskach sieciowych: Novell NetWare i QNX. Ten drugi system to Unix czasu rzeczywistego, stosowany najczęściej w komputeryzacji procesów przemysłowych. Cechą charakterystyczną QNX są stosunkowo niewielkie jak na Unix wymagania sprzętowe.

Moduły związane z SAPOD mają obecnie bogatą listę referencyjną (ok. 400 pozycji). Korzystają z nich nie tylko

liczne oddziały NBP i banki które z niego wyrosły (Bank Przemysłowo-Handlowy w Krakowie, Bank Depozytowo-Kredytowy w Lublinie, Bank ?ląski), ale także banki powstałe całkiem niedawno.

Pojedyncze moduły współpracujące z systemem SAPOD działają na własnej bazie danych, co umożliwia włączanie fragmentów pakietu w inne systemy bankowe (np. miniSOB). Ma to największy sens w przypadku modułów elba Lokaty i Kredyty.

Zmiana podejścia

Po trzech latach rozwijania pojedynczych modułów, w PTB elba nadszedł czas na nowe idee. Podjęto decyzję o stworzeniu innego systemu obsługi banku, tym razem działającego niezależnie od "cudzych. Nadano mu nazwę System Kompleksowej Automatyzacji Rachunków Bankowych skarb.

System zaczął powstawać w 1992 r. w, relacyjnej bazie danych Informix z wykorzystaniem języka czwartej generacji oraz strukturalnego języka zapytań SQL, na platformie sprzętowej komputerów Sun Microsystems pracujących pod terminalowym systemem operacyjnym SunOS. Język 4GL umożliwia szybsze programowanie, ale sam w sobie nie zapewnia sprawniejszej organizacji pracy i kodyfikacji potrzeb. Do tych zagadnień użyto narzędzia CASE pn. System Architect, pochodzącego z amerykańskiej firmy Popkin oraz FourGen Case Tools.

Przydziału zadań w poszczególnych grupach pilnował i pilnuje do dziś Microsoft Project, z którego na co dzień korzysta dział marketingu i rozwoju.

W okowach formalizmu

Projekt skarb został poddany formalizacji już we wczesnych etapach rozwoju. Dla potrzeb analizy ustalono język opisu obiektów stanowiący wnętrze i zewnętrze banku (oddziału/centrali), a następnie przystąpiono do niezwykle

precyzyjnego opisu prowadzonych w banku działań i czynności (rozumianych jako działanie elementarne, nierozkładalne). Każda czynność była opisywana w specjalnych formularzach o logicznej konwencji numerowania (identyfikatory). Formularz taki zawierał specyfikacje techniczne (z identyfikatorami) dla przepływu danych towarzyszących każdej czynności.

Analizę prowadzono w wybranych oddziałach i centralach banków przy istotnym współudziale pracowników banku (nie trzeba dodawać, że zarówno nazwy banków, jak i treść wypełnianych danych ma charakter poufny). Dzięki założonej formalizacji, wiedzę zebraną w formularzach można już w miarę łatwo wprowadzać do komputera.

Cała analiza była prowadzona metodą "z góry na dół". Zaczynano ją od struktury organizacyjnej banku, poprzez

określenie jego funkcji, aż do szczegółowego opisu pojedynczych czynności. Stwierdzono, że nie jest możliwe

wykonanie pełnej analizy w jednym kroku realizacyjnym, dlatego praca została podzielona na etapy:

1. Opracowanie podstawowego zestawu dokumentów analitycznych, tj.

- definicja struktury organizacyjnej

- wykaz funkcji:

- - produkty

- - sfery funkcjonalne

- schemat obiegu dokumentów;

2. Wprowadzenie danych zgromadzonych w postaci tabel i poddanie ich analizie komputerowej, w wyniku której

powstaną:

- wykazy poszczególnych elementów analizy

- wydruki zawierające szczegółowe opisy poszczególnych elementów

- raporty obrazujące powiązania między elementami;

3. Analiza materiałów uzyskanych w etapie 2, w tym:

- opracowanie brakujących załączników

- weryfikacja zawartości tabel

- korekta danych zgromadzonych na nośnikach komputerowych;

(prace etapów 2 oraz 3 były powtarzane do momentu uzyskania zadowalających rezultatów)

4. Opracowanie założeń dla sformalizowanego języka transakcji komputerowych i struktury bazy danych;

5. Ocena kompletności przeprowadzonej analizy oraz decyzja zamknięcia tej fazy a rozpoczęcia fazy projektowej.

Dalej - z górki?

Dobrze udokumentowana analiza jest o wiele cenniejszym produktem niż kod źródłowy programu. Widać to dobrze na

schemacie opracowywania systemu skarb, gdzie najwięcej korekt i powrotów do poprzednich faz produkcji programu

(strzałki w górę) można znaleźć w fazie analizy i projektowania systemu. Nawet generowanie diagramów przepływu

danych (Gane-Sarsona), struktur bazy danych (entity-relationship) i struktury oprogramowania (structured chart)

- sam w sobie temat na osobną książkę - wydaje się w takim projekcie już tylko maszynką do tworzenia systemów

informatycznych w języku Informix.

Na ile elastyczny jest ten język i ilu wymaga protez dopisywanych w językach niższych poziomów (C, C++, Pascal

czy asembler) będą mogli powiedzieć już tylko sami programiści z PTB elba po zakończeniu pierwszego wdrożenia

nowego systemu.