Debiutant ze stażem

W praktyce oprogramowanie powstające poza IT podlega tym samym rygorom, których musi przestrzegać zespół developerski. Każda aplikacja przechodzi przez te same fazy produkcyjne i podlega tym samym punktom kontroli jakości i bezpieczeństwa, testom oraz procedurze wdrożenia. W innym przypadku IT nie mogłoby wziąć odpowiedzialności za jej utrzymanie, co oznacza, że de facto nie mogłaby być używana produkcyjnie.

Zazwyczaj prace developerskie zaczynają się od uzgodnienia technologii, w jakiej aplikacja zostanie wykonana. Główny architekt, którym jest szef departamentu rozwoju systemów, wskazuje zakres dopuszczalnych narzędzi i technologii, jaką wykorzystać bazę danych i z jakich gotowych komponentów można skorzystać. Jeśli w trakcie prac rozwojowych wystąpi problem, IT służy biznesowi wsparciem. Czasem będzie to tylko krótka konsultacja, innym razem może to być tworzenie przez zawodowych programistów frameworku, który przedstawiciele biznesu samodzielnie uzupełnią. Czasem może się okazać konieczne wykonanie integracji np. przygotowanego projektu ekranów z funkcjonującymi już rozwiązaniami.

Testy wszystkich rozwiązań w banku prowadzi odrębna komórka biznesowa. Nie podlega ona w żaden sposób IT. Tam też przeprowadzane są testy integracyjne z instytucjami zewnętrznymi oraz testy wydajnościowe badające wpływ nowych aplikacji na obciążenie infrastruktury. Ostatnim etapem jest przejęcie wyników testów przez szefa departamentu usług informatycznych odpowiedzialnego za utrzymanie systemów, uzyskanie akceptacji współuczestniczących w testach komórek biznesowych oraz ustalenie trybu i planu wdrożenia. „Dzisiaj na rynku dostępne są tak elastyczne i w zasadzie łatwe w obsłudze narzędzia, a ich użytkownicy po stronie biznesu posiedli tak wysokie umiejętności, że naprawdę nie ma powodu, aby IT zawłaszczało wszystkie procesy związane z rozwojem aplikacji” – mówi Grażyna Musiatowicz-Podbiał – „Taka współpraca przy wytwarzaniu rozwiązań pomaga nie tylko zrealizować zmiany szybciej niż gdyby miały czekać na swoją <<kolejkę>> w IT czy u dostawcy, ale również pozwala nam na lepsze wzajemnie zrozumienie potrzeb. Posługujemy się po prostu zbliżonym słownikiem pojęć, bo zmagamy się z podobnymi wyzwaniami.”

Prymat schematu

Opowiadając o planach CIO posługuje się schematem przedstawiającym trójwarstwową architekturę systemów informatycznych. „Tę koncepcję wypracowaliśmy na samym początku prac nad strategią banku i teraz jest dla nas jak święta. Czasem myślę, że możemy jeszcze zmienić wszystko oprócz tego schematu” – śmieje się CIO Meritum Banku.

Przejrzysty, blokowy schemat ilustruje spektrum aplikacji, których Meritum potrzebuje teraz i w przyszłości. W niektórych bloczkach diagramu widnieje nazwa produktu, który bank już zamówił. Tam gdzie jej nie ma, trwa jeszcze procedura wyboru albo pozostawiono miejsce na ewentualne wdrożenie rozwiązań w przyszłości. „Przygotowywane plany integracji wykraczają poza strukturę naszego banku. Dzisiaj rynek wymaga aktywnego uczestnictwa w łańcuchach finansowych, uzupełniania usług bankowych produktami innych instytucji. Chcemy być na to koncepcyjnie przygotowani ” – mówi Grażyna Musiatowicz-Podbiał. „Na nadarzające się okazje rynkowe trzeba reagować bardzo szybko i dobrze byłoby nie wywracać wtedy wszystkiego do góry nogami, tylko wypełnić przewidzianą w schemacie lukę”.

Początkowo w Meritum zakładano, że jeden producent dostarczy wszystkie niezbędne komponenty systemu informatycznego – system podstawowy tzw. core banking, bankowość elektroniczną i aplikacje obsługujące procesy sprzedaży. Takie rozwiązanie pozwoliłoby skupić się na pracy z jednym dostawcą. Po analizie ofert okazało się jednak, że na rynku trudno znaleźć dobre rozwiązane „wszystko w jednym”. Latem br. zapadła więc decyzja, że aplikacje poszczególnych warstw schematu będą dobierane od różnych dostawców, a część zostanie wykonana samodzielnie, wewnętrznymi siłami banku.


TOP 200