Każda instytucja finansowa prędzej czy później staje przed tym samym pytaniem: kupić gotowe oprogramowanie, zbudować własne czy połączyć oba podejścia. Odpowiedź rzadko jest zerojedynkowa. Najlepsze decyzje zapadają proces po procesie, a nie raz dla całej organizacji.
W tym artykule pokazujemy trzy drogi, pięć pytań decyzyjnych i najczęstsze błędy, które sprawiają, że dobry pomysł kończy się drogim kompromisem.
Trzy drogi, nie dwie
Klasyczna debata „build vs buy” pomija trzecią, najczęściej wybieraną opcję. Analitycy Gartnera proponują model, w którym instytucja kupuje tam, gdzie może, buduje tam, gdzie to ją wyróżnia, i integruje całość. Według tych samych analiz 60-75% potrzeb przedsiębiorstw w usługach finansowych można pokryć oprogramowaniem komercyjnym.
To ważna liczba, bo pokazuje dwie rzeczy jednocześnie. Większości funkcji nie warto budować od zera. Ale pozostała część – często ta, która decyduje o przewadze – nie pasuje do żadnego pudełka.
- Buy: gotowy system lub platforma SaaS. Szybki start i przewidywalny koszt licencji, ale proces dopasowuje się do narzędzia.
- Build: oprogramowanie dedykowane. Pełne dopasowanie i własność rozwiązania, ale dłuższy czas dojścia do pierwszej wersji.
- Blend: gotowa platforma lub system core plus warstwa dedykowana – procesy, integracje, interfejsy. Dziś najczęstszy wybór w bankowości i ubezpieczeniach.
Pięć pytań decyzyjnych
1. Czy ten proces buduje przewagę?
Jeśli klient lub pośrednik odczuwa różnicę między Tobą a konkurencją właśnie w tym procesie – czas decyzji, wygoda obsługi, elastyczność oferty – to kandydat do rozwiązania dedykowanego. Jeśli proces jest regulacyjnym lub operacyjnym standardem, zwykle lepiej go kupić.
2. Czy gotowe narzędzie spełni wymagania regulacyjne bez obejść?
W sektorze finansowym zgodność nie jest dodatkiem. DORA, wymagania KNF i AI Act wpływają na to, jak system loguje zdarzenia, przechowuje dane i jak można go testować. Jeśli gotowy produkt wymaga obejść, ich koszt pojawi się przy pierwszym audycie.
3. Z iloma systemami trzeba się zintegrować?
Im więcej systemów źródłowych, tym większa szansa, że to integracja, a nie sama funkcja, będzie największym kosztem. W takich przypadkach dedykowana warstwa procesowa wokół istniejących systemów często daje więcej niż wymiana któregokolwiek z nich.
4. Czy ufamy roadmapie dostawcy?
Kupując produkt, kupujesz też plany jego producenta. Jeśli kluczowa funkcja jest „w planach na przyszły rok”, a Twój biznes potrzebuje jej teraz, model blend daje możliwość zbudowania jej samodzielnie bez rezygnacji z produktu.
5. Kto będzie utrzymywał rozwiązanie za pięć lat?
Oprogramowanie dedykowane wymaga właściciela po stronie biznesu i kompetencji technicznych – własnych lub partnera. Bez tego nawet najlepszy system zamienia się w kolejny system legacy.
Model blend w praktyce
Dobrym przykładem jest automatyzacja procesów na platformie BPM. Gotowa platforma – taka jak Flowee – dostarcza silnik procesów, formularze i monitoring. Elementy dedykowane obejmują reguły biznesowe, integracje z systemami core i interfejsy dla konkretnych grup użytkowników.
Dzięki temu instytucja nie buduje od zera tego, co jest standardem, a jednocześnie nie rezygnuje z tego, co ją wyróżnia. Ten sam schemat sprawdza się w obsłudze kredytów, likwidacji szkód czy onboardingu klientów.
Najczęstsze błędy decyzji
- Decyzja raz dla całej organizacji zamiast osobno dla każdego procesu.
- Porównanie ceny licencji z ceną budowy bez uwzględnienia kosztów integracji, zmian i utrzymania w horyzoncie kilku lat.
- Wybór na podstawie demo, które pokazuje „szczęśliwą ścieżkę”, a nie wyjątki, w których powstają koszty.
- Brak analizy wymagań regulacyjnych przed wyborem dostawcy.
- Budowa „na wszelki wypadek” funkcji, które istnieją jako dojrzały standard rynkowy.
Od czego zacząć
Zacznij od listy procesów, a nie od listy systemów. Dla każdego procesu odpowiedz na pięć pytań powyżej i zaznacz, czy prowadzą do kupienia, zbudowania czy połączenia obu podejść. Dopiero tak przygotowana mapa pozwala sensownie porównywać oferty dostawców.
Jeśli proces łączy kilka systemów i ma realny wpływ na klienta, warto zweryfikować pomysł prototypem, zanim zapadnie decyzja budżetowa. Piszemy o tym w artykule Prototyp zamiast specyfikacji.
