3 godzin temu
Modernizacja infrastruktury zmienia dziś nie tylko technologię, ale także strukturę kosztów, sposób działania IT i odporność całej firmy. Wybór partnera przestaje więc być zwykłym zakupem usług. To decyzja o tym, kto przez kolejne lata będzie wpływał na tempo rozwoju przedsiębiorstwa i jego zdolność do działania podczas awarii.
Największym błędem pozostaje ocenianie partnerów głównie przez liczbę certyfikatów, statusy producentów i wielkość zespołu. Takie informacje potwierdzają znajomość technologii, ale nie pokazują, czy dostawca potrafi dopasować ją do biznesu, ograniczyć koszty i pozostawić firmę zdolną do samodzielnego zarządzania środowiskiem.
Dobry partner nie buduje swojej przewagi na trwałej zależności klienta. Jego wartość widać po tym, czy firma rozumie nowe środowisko, kontroluje je i potrafi dalej rozwijać bez stałej obecności zewnętrznych konsultantów.
Najpierw wynik, później technologia
Firmy często zaczynają modernizację od pytania, którą chmurę lub platformę wybrać. Tymczasem technologia jest narzędziem, a nie celem projektu.
Punktem wyjścia staje się odpowiedź na pytanie, co modernizacja ma zmienić. Może chodzić o skrócenie czasu wdrażania usług, poprawę dostępności, ograniczenie kosztów, zwiększenie bezpieczeństwa albo przygotowanie infrastruktury pod zastosowania AI. Bez jasno określonego rezultatu każdy dostawca interpretuje potrzeby klienta przez pryzmat własnej oferty.
Partner specjalizujący się w jednej chmurze będzie naturalnie skłonny rekomendować właśnie ją. Firma zarabiająca na licencjach może preferować architekturę wymagającą większej liczby produktów, a dostawca usług zarządzanych rozwiązanie trudne do utrzymania bez jego udziału.
Nie oznacza to działania przeciwko klientowi. Pokazuje jednak, iż model biznesowy partnera wpływa na jego rekomendacje. Dlatego im precyzyjniej firma definiuje oczekiwany efekt, tym mniejsze ryzyko, iż projekt zakończy się technicznym sukcesem bez wyraźnej wartości biznesowej.
Dobry partner zaczyna od diagnozy
Jakość partnera można ocenić jeszcze przed podpisaniem umowy. Najwięcej mówi sposób, w jaki analizuje on środowisko klienta.
Dojrzały dostawca nie zaczyna od prezentacji własnych usług. Najpierw mapuje zależności między aplikacjami, danymi, infrastrukturą i procesami biznesowymi. Interesuje go, które systemy są krytyczne, ile kosztuje ich przestój, gdzie występują ograniczenia i jakie kompetencje firma chce zachować wewnątrz.
Istotna jest również gotowość do zakwestionowania samej potrzeby migracji. Niektóre aplikacje lepiej pozostawić w dotychczasowym środowisku, inne wymagają przebudowy, a jeszcze inne można zastąpić gotową usługą.
Dlatego podejście „cloud first” traci na znaczeniu. O miejscu działania systemu coraz częściej decydują koszty, bezpieczeństwo, regulacje, opóźnienia i odporność, a nie strategia sprzedażowa dostawcy.
Partner, który zbyt gwałtownie rekomenduje jedną technologię, prawdopodobnie dopasowuje klienta do własnego rozwiązania. Ten, który potrafi podważyć początkowe założenia firmy, może uchronić ją przed kosztowną modernizacją przeprowadzoną w niewłaściwym kierunku.
Liczy się zespół, nie logo
Duża marka zapewnia skalę i dostęp do kompetencji, ale nie gwarantuje, iż do projektu trafią eksperci przedstawieni podczas procesu sprzedażowego. Dlatego większe znaczenie niż logo integratora ma skład konkretnego zespołu.
Przed podpisaniem umowy istotne są nazwiska osób odpowiedzialnych za architekturę, migrację, bezpieczeństwo i utrzymanie. Znaczenie ma także ich dostępność, zasady zastępowania oraz udział podwykonawców.
Referencje stają się użyteczne dopiero wtedy, gdy dotyczą projektów podobnych pod względem skali, krytyczności i złożoności. Migracja systemu pomocniczego nie dowodzi, iż partner poradzi sobie ze środowiskiem, od którego zależy sprzedaż lub produkcja.
Więcej niż lista sukcesów mówi sposób opisywania problemów. Partner, który potrafi wyjaśnić, jak poradził sobie z awarią, opóźnieniem lub błędnym założeniem, daje lepszy obraz swoich kompetencji niż firma pokazująca wyłącznie idealne realizacje.
Odporność trzeba zobaczyć w działaniu
Migracja do nowoczesnego środowiska nie gwarantuje ciągłości działania. Może choćby stworzyć nowe punkty awarii.
Systemy działające w różnych chmurach przez cały czas mogą zależeć od tego samego dostawcy tożsamości, operatora sieci, platformy bezpieczeństwa lub narzędzia do zarządzania. Awaria jednego z tych elementów potrafi zatrzymać całe środowisko mimo formalnego rozproszenia infrastruktury.
Dlatego deklaracje o wysokiej dostępności mają ograniczoną wartość bez scenariuszy awarii, procedur odtworzenia i testów. Dla biznesu najważniejsze jest nie to, czy działa pojedynczy serwer, ale czy firma przez cały czas realizuje zamówienia, obsługuje klientów i prowadzi produkcję.
Najlepszym sprawdzianem pozostaje rzeczywisty test odtworzenia całego procesu biznesowego. Dopiero wtedy widać, czy architektura, procedury i podział odpowiedzialności działają także pod presją czasu.
Najtańsza oferta może być najdroższa
Koszt modernizacji nie kończy się na wynagrodzeniu partnera. Obejmuje również równoległe utrzymywanie starego i nowego środowiska, transfer danych, licencje, bezpieczeństwo, monitoring, szkolenia oraz późniejsze wsparcie.
Nowa architektura może wymagać droższych specjalistów, większej liczby narzędzi i stałego udziału konsultantów. Początkowo atrakcyjna oferta potrafi więc wygenerować wysoki koszt operacyjny w kolejnych latach.
Lepszym punktem odniesienia niż cena wdrożenia jest całkowity koszt działania środowiska w perspektywie kilku lat. Jeszcze więcej mówi koszt jednostkowy, na przykład obsługi transakcji, klienta lub produktu. Wzrost rachunku nie stanowi problemu, jeżeli równocześnie rośnie skala biznesu. Problem pojawia się wtedy, gdy koszty zwiększają się szybciej niż dostarczana wartość.
Znaczenie ma także model wynagrodzenia partnera. o ile jego przychody rosną wraz ze zużyciem infrastruktury, motywacja do upraszczania środowiska może być ograniczona. jeżeli rozlicza się za czas konsultantów, automatyzacja może działać przeciwko jego interesowi ekonomicznemu. Te zależności warto uwzględnić w umowie i miernikach projektu.
Strategia wyjścia zaczyna się przed podpisaniem umowy
Firmy zwykle myślą o zmianie dostawcy dopiero wtedy, gdy kooperacja przestaje działać. W przypadku infrastruktury taka refleksja często pojawia się za późno.
Już na początku współpracy znaczenie mają zasady dotyczące własności kodu automatyzacji, konfiguracji, dokumentacji i danych operacyjnych. Im większy dostęp klienta do tych zasobów, tym większa swoboda dalszego rozwoju środowiska i ewentualnej zmiany wykonawcy.
Równie ważne są format eksportu danych, koszt pomocy przy migracji oraz czas potrzebny do zakończenia usług. Bez takich ustaleń partner może uzyskać przewagę techniczną i organizacyjną, która utrudni klientowi odejście choćby przy spadającej jakości współpracy.
Strategia wyjścia nie jest wyrazem braku zaufania. To narzędzie utrzymania równowagi w relacji i pozycji negocjacyjnej przez cały okres kontraktu.
Transfer wiedzy jest częścią rezultatu
Firma, która po projekcie nie potrafi samodzielnie wykonywać podstawowych operacji, zamieniła stary dług technologiczny na nową zależność.
Transfer wiedzy ma większą wartość, gdy odbywa się w trakcie projektu, a nie podczas kilku szkoleń na jego końcu. Wspólne projektowanie, migracja, rozwiązywanie problemów i dokumentowanie decyzji pozwalają zespołowi klienta stopniowo przejmować odpowiedzialność.
Dobrym miernikiem sukcesu nie jest więc wyłącznie dostępność czy wydajność. Równie istotne stają się poziom automatyzacji, jakość dokumentacji i liczba procesów, które wewnętrzny zespół potrafi obsłużyć bez pomocy z zewnątrz.
Im większa samodzielność organizacji po wdrożeniu, tym większa wartość całej modernizacji.
Najbezpieczniej zacząć od pilotażu
Wybór partnera na podstawie prezentacji i odpowiedzi na zapytanie ofertowe zawsze zawiera element ryzyka. Ogranicza je płatna diagnoza i dobrze zaprojektowany pilotaż.
Pierwszy etap pozwala ocenić sposób myślenia partnera i jakość analizy. Dokumentacja z diagnozy daje firmie wartość niezależnie od tego, czy kooperacja będzie kontynuowana.
Pilotaż pokazuje natomiast, jak partner działa w praktyce: jak reaguje na problemy, kontroluje koszty, dokumentuje środowisko i współpracuje z zespołem klienta. Dopiero realna praca ujawnia, czy potrafi zarządzać złożonością, czy jedynie dobrze prezentuje swoje kompetencje.
Pozytywny wynik pilotażu daje podstawę do rozszerzenia kontraktu. Negatywny pozwala zakończyć współpracę, zanim firma powierzy partnerowi systemy krytyczne i wieloletni budżet.
Dobry partner oddaje kontrolę
CIO pozostaje właścicielem architektury, danych i decyzji dotyczących ryzyka. Partner może doradzać i wdrażać, ale nie powinien być jedynym podmiotem rozumiejącym środowisko ani jedynym źródłem informacji o jego kosztach i jakości.
Z perspektywy zarządu najważniejsze są oczekiwany wynik biznesowy, dopuszczalne ryzyko, całkowity koszt i możliwość zmiany dostawcy. Wybór konkretnej technologii ma znaczenie drugorzędne wobec pytania, czy organizacja zachowa kontrolę nad swoim środowiskiem.
Najlepszy partner nie oferuje najwięcej technologii. Upraszcza środowisko, ogranicza ryzyko i przygotowuje klienta do samodzielnego działania.
Modernizacja jest naprawdę udana wtedy, gdy po jej zakończeniu firma ma większą kontrolę nad technologią, kosztami i ciągłością działania niż wcześniej.
