Niezależna ocena projektu przed podpisem: co zintegruje się z systemem finansowo-księgowym, ile naprawdę kosztuje w pięć lat i jak porównać dwie oferty na podstawie ustandaryzowanych kryteriów. Dla MPEC, wodociągów, spółek komunikacyjnych i portowych.
Spółka komunalna czy portowa ma zwykle własny dział informatyki i budżet inwestycyjny — ale decyzje o kierunku cyfryzacji zapadają na podstawie jednej rekomendacji, bez zewnętrznej weryfikacji ryzyka, kosztu i alternatyw.
Nie jesteście jednostką administracji. Logika spółki prawa handlowego różni się od logiki urzędu — inny jest horyzont decyzyjny, inny język uzasadnienia, inna presja wyniku. Współpracujemy w Waszym języku: ryzyko, koszt, ciągłość operacyjna — nie w języku administracyjnym.
Obowiązkowe fakturowanie ustrukturyzowane wymaga integracji z istniejącymi systemami finansowo-księgowymi, nie tylko zakupu nowego modułu.
Z inwentaryzacji: macierz integracji z systemem FK i lista systemów, które muszą wymieniać z nim dane.
Integracja nowego systemu z istniejącym systemem finansowo-księgowym to najczęstszy punkt zapalny — pytanie brzmi „czy da się to dopiąć", nie „czy wymienić wszystko".
Z inwentaryzacji: wymóg integracji opisany w specyfikacji od pierwszego dnia, nie doklejony aneksem po podpisie.
Każdy kolejny moduł albo wpina się w to, co macie, albo tworzy kolejną wyspę aplikacyjną, za którą spółka płaci dwa razy.
Z inwentaryzacji: kategorie A/B/C/D i kolejność wdrożeń.
Wiele spółek użyteczności publicznej — zwłaszcza z sektora energetyki cieplnej, wodociągów czy transportu — mieści się w katalogu podmiotów objętych nowelizacją ustawy o KSC, niezależnie od formy spółki prawa handlowego.
Z inwentaryzacji: rejestr systemów i rejestr ryzyk.
Duży, zintegrowany ERP brzmi bezpiecznie, ale bywa jednym wielkim uzależnieniem od dostawcy — bez zwinności i miejsca na nową informatykę. Nie ma jednej dobrej odpowiedzi: zależy od modelu biznesowego i wielkości spółki.
Z inwentaryzacji: co zostaje w ERP, a co lepiej wydzielić jako osobny, dobrze zintegrowany system.
Szef IT identyfikuje potrzebę, ale nie ma władzy nad szefami innych komórek, żeby wymusić współpracę — brakuje przełożenia, nie wiedzy.
Z inwentaryzacji: mandat zarządu dla zewnętrznego doradcy, żeby zebrać to, czego dział IT potrzebuje.
Bez wspólnej matrycy porównawczej porównuje się niewspółmierne rzeczy i wygrywa lepsza prezentacja, nie lepsza oferta.
Z inwentaryzacji: kryteria porównania ustalone przed spotkaniami z dostawcami, nie w trakcie.
Zanim spółka kupi kolejny moduł, pytam, po co i co będzie definicją sukcesu. Często okazuje się, że pod prośbą o jeden system kryje się proces, który trzeba najpierw uporządkować, a narzędzie jest dopiero drugim krokiem.
Prośba„Potrzebujemy systemu obiegu faktur pod KSeF.”
Jedna strona dla prezesa i głównej księgowej, prezentacja na posiedzenie Zarządu i komplet dokumentów do rozmów z dostawcami.
Szkic układu. Sesja 60–90 minut wliczona w cenę.
| Wasz plan | Co dostaje Zarząd | Jakie ryzyko to zamyka |
|---|---|---|
| Obieg faktur pod KSeF | Macierz integracji z FK, wymagania do specyfikacji, wariant integracji i wariant nowego systemu z kosztem w 5 lat. | Kolejna wyspa aplikacyjna obok FK, aneksy za integrację, podwójne wprowadzanie danych. |
| Integracja z systemem FK i ERP | Wymóg integracji opisany w specyfikacji od pierwszego dnia, pytania do dostawców. | Odkrycie po podpisie, że „nie da się dopiąć”, i wymiana systemu, którego nikt nie chciał wymieniać. |
| e-teczka i kolejne moduły | Kategorie A/B/C/D, kolejność wdrożeń, plan zarządzania zmianą. | Opór zespołu na starcie i moduły, które nie rozmawiają ze sobą. |
| Rada nadzorcza i właściciel | Jedna strona z rekomendacją, porównanie ofert na podstawie ustandaryzowanych kryteriów, koszt całkowity w 5 lat. | Decyzja podjęta „na prezentację” i pytanie o jej podstawy po fakcie. |
Zależnie od liczby systemów i działów. Dokładną wycenę ustalam po 30-minutowej rozmowie o skali spółki.
Podejmuje decyzję o projekcie IT na podstawie rekomendacji własnego działu — potrzebuje drugiej, niezależnej opinii przed podpisem, nie po fakcie.
Dostaje: jedną stronę z rekomendacją i dwa warianty decyzji z kosztem w 5 lat, do pokazania radzie nadzorczej.
Zyskuje: decyzję, którą obroni przed radą nadzorczą.
Odpowiada za integrację nowych systemów z istniejącym systemem finansowo-księgowym — to zwykle pierwszy i najtwardszy punkt sporu w każdym projekcie.
Dostaje: macierz integracji z FK i wymagania, których można wymagać od dostawcy w umowie.
Zyskuje: przewidywalny koszt i integrację bez aneksów.
Sojusznik, gdy niezależna ocena wzmacnia jego rekomendację liczbami i argumentami zarządczymi — nie konkurent, który przejmuje jego rolę.
Dostaje: rejestr systemów, metodykę do powtarzania i argumenty zarządcze do własnej rekomendacji.
Zyskuje: niezależne potwierdzenie własnej rekomendacji.
Ten sam wzorzec współpracy sprawdził się przy cyfryzacji terminalu kontenerowego: zewnętrzny, niezależny głos przy stole zarządu, obok — nie zamiast — kompetencji własnego działu IT.
Rejestr systemów, integracji i zależności — ze szczególnym naciskiem na system finansowo-księgowy i jego powiązania. Kategoryzacja A/B/C/D, mapa ryzyk. Jedna strona dla zarządu.
Zanim zarząd zatwierdzi rekomendację działu IT: druga opinia o ryzyku, koszcie całkowitym i alternatywach. Sygnalizowanie, gdzie inne firmy w podobnej sytuacji przepłaciły, bo nie przewidziały integracji, migracji danych albo oporu zespołu. Gdy prezes ma pomysł, ale nie ma czasu go rozpisać — 15–20 minut rozmowy wystarczy, żeby w ~2 dni wrócić z gotową koncepcją do oceny.
Matryca porównawcza dwóch (lub więcej) ofert na wspólnych kryteriach, pytania do zadania dostawcom, udział w spotkaniach jako przedstawiciel zarządu — żeby decyzja przed prezesem opierała się na porównywalnych danych, nie na sile prezentacji.
Udział w spotkaniach z dostawcami, opiniowanie kolejnych projektów równolegle do rekomendacji własnego IT, bieżące rozeznanie w tym, gdzie podobne spółki przepłaciły za decyzje o chmurze, API czy automatyzacji.
Dział prawny w tej samej organizacji ma dziś elektroniczne archiwum postępowań, obieg faktur z OCR, integrację z KSeF i moduł asysty prawnej — jako kolejne, narastające projekty zbudowane na tym samym mechanizmie: zarząd formułuje intencję, Krogis przekłada ją na działanie.
„Ten sam model działania co przy cyfryzacji terminalu kontenerowego — niezależny głos zarządu obok kompetencji własnego działu IT, nie zamiast niej.”
Wielojęzyczny system obsługi kontrahentów na platformie procesowej: rejestracja, zapytania, oferty i reklamacje — w użyciu do dziś. Identyfikacja celów, analiza wymagań i opracowanie koncepcji systemu zarządzania relacjami z interesariuszami. Doświadczenie z cyfryzacją dużego operatora infrastruktury.
Opracowanie, wdrożenie i uruchomienie platformy pracy grupowej i zarządzania procesami biznesowymi, obejmującej m.in.: elektroniczne archiwum postępowań, elektroniczny obieg dokumentów kosztowych, e-teczki pracownicze, zarządzanie korespondencją i asystę prawną.
Powtarzające się, zanonimizowane wątki z rozmów o cyfryzacji — nie cytaty z konkretnej spółki.
„Zanim ruszymy dalej, muszę wiedzieć, czy to się w ogóle zepnie z naszym systemem finansowo-księgowym — reszta jest drugorzędna.”
„Zawsze stawiamy dwie oferty obok siebie przed zarządem — potrzebujemy kogoś, kto pomoże je uczciwie porównać, nie tylko wybrać ładniejszą prezentację.”
„Nawet jak proces jest zautomatyzowany, chcę mieć realną możliwość ręcznej decyzji, kiedy uznam, że trzeba.”
„Nie chcemy, żeby ktoś zrobił z nas jednostkę publiczną — jesteśmy spółką, mamy inny rachunek ryzyka i wyniku niż urząd.”
W większości przypadków da się to zrobić przez API albo dedykowaną integrację, o ile wymóg integracji zostanie opisany w specyfikacji od pierwszego dnia, a nie doklejony aneksem po podpisaniu umowy. To jeden z najczęstszych punktów spornych w projektach IT w spółkach komunalnych — i jeden z najłatwiejszych do zaadresowania z wyprzedzeniem.
Wiele spółek użyteczności publicznej — zwłaszcza z sektora energetyki cieplnej, wodociągów czy transportu — mieści się w katalogu podmiotów objętych nowelizacją ustawy o KSC (NIS 2), niezależnie od tego, że działają w formie spółki prawa handlowego, a nie jednostki administracji. Warto to zweryfikować indywidualnie, bo kwalifikacja zależy od skali i rodzaju działalności.
Potrzebna jest wspólna matryca kryteriów — funkcjonalność, architektura i otwartość, bezpieczeństwo i zgodność, technologia i dostawca, koszt całkowity — ustalona przed spotkaniami z dostawcami, nie w trakcie. Bez niej porównuje się często niewspółmierne rzeczy i wygrywa lepsza prezentacja, nie lepsza oferta.
Tak — logika kodeksu spółek handlowych różni się od logiki administracji: inny jest horyzont decyzyjny, inna presja wyniku finansowego, a część obowiązków (np. zamówienia publiczne) może w ogóle nie dotyczyć spółki w tym samym zakresie co urzędu. Dlatego komunikacja i doradztwo dla spółek komunalnych powinny być prowadzone językiem biznesowym — ryzyko, koszt, ciągłość — nie administracyjnym.
Trzeba policzyć całkowity koszt posiadania w horyzoncie kilku lat — licencja, wdrożenie, utrzymanie, szkolenia, koszt integracji — i porównać go z faktycznym kosztem obecnych, rozproszonych systemów, a nie z ich ceną nominalną sprzed lat. Ogólne hasło o oszczędnościach z jednej platformy bez tego wyliczenia zwykle nie wytrzymuje konfrontacji z liczbami.
Najpierw spiszcie, z czym nowy system ma współpracować: system finansowo-księgowy, obieg faktur pod KSeF, systemy techniczne i obsługa klienta. Ustalcie, kto w spółce decyduje o procesach, i opiszcie wymagania, w tym integracje, zanim zaczniecie rozmowy z dostawcami. Oferty porównujcie w jednej matrycy i po koszcie całkowitym, a odbiór oprzyjcie na uzgodnionych scenariuszach testowych.
