Wymiana systemu IT. Poradnik dla placówek zdrowia

System IT jest sercem placówki medycznej. Gdy nie działa jak trzeba lub kiedy nie nadąża za rozwojem organizacji, zaczyna frustrować zamiast pomagać. Mimo to, wiele podmiotów woli męczyć się ze starym programem. Niesłusznie, bo przejście na nowy może okazać się jedną z najlepszych inwestycji.

Wspomaga rozliczanie świadczeń, umawianie wizyt, gromadzenie i przechowywanie danych medycznych – nie ma placówki medycznej, która nie posiadałaby jakiegoś oprogramowania do tzw. części szarej i białej.

Z jednej strony – niezbędny, z drugiej – często nielubiany. Bo nie działa tak, jak powinien, ma błędy, jest trudny w obsłudze, nieprzyjazny użytkownikowi, brakuje mu niektórych funkcji, jakich życzyliby sobie lekarze, pielęgniarki, rejestratorki lub zarząd. Gdy prośby o modyfikacje, upgrade albo poprawki odbijają się jak groch o ścianę, system IT staje się kamieniem u nogi zamiast obiecanym pomocnikiem wpierającym realizację procesów administracyjno-klinicznych. Co wtedy zrobić?

Zacznij od szczerego i obiektywnego audytu wewnętrznego

Pierwszym sygnałem do wymiany systemu są częste błędy. Z naciskiem na „częste”, bo programy IT dla placówek ochrony zdrowia to żywe twory, które cały czas muszą być rozwijane, aby spełnić wymagania prawne i generować dokumenty zgodnie z nowymi standardami. A każdy upgrade to ryzyko, że gdzieś coś się posypie. Jednak duże firmy IT z reguły szybko reagują, przygotowując łatki pozwalające sprawnie się ich pozbyć. To na pewno nie jest powód do zmiany systemu, a raczej wspólne wyzwanie dla każdego dostawcy.

Jednak są takie sytuacje, które frustrują i przeciągają się w nieskończoność: dostawca IT mówi, że wszystko działa, pracownicy są innego zdania; nowe wymagania administracyjne są wprowadzane z dużym, nieuzasadnionym opóźnieniem; nie można uzyskać pomocy technicznej lub serwisowej. Albo po prostu placówka doszła do muru możliwości programu, który nie nadąża za nowościami technologicznymi i rozwojem organizacji.

W takim przypadku trzeba zdecydować, co dalej: łatać czy wymienić. Na pewno nie zostawić bez ruszania, bo to prosty przepis na niezadowolony zespół, niebezpieczne błędy i atmosferę rezygnacji, która rozleje się na całą kulturę organizacyjną podmiotu. Decyzja może być czasami całkiem prosta, przykładowo, gdy system stworzył nam informatyk i teraz okazuje się, że nie jest w stanie go dalej serwisować. Albo gdy placówka rozrosła się na tyle, że firma oferująca mały system gabinetowy nie ma w ofercie zintegrowanych systemów dla dużych podmiotów.

Jednak gdy powód nie jest tak jednoznaczny, liczy się ustalenie faktów. Oto przykładowa lista pytań, która pomoże na zimno ocenić stanu rzeczy:

• Co dokładnie jest problemem, unikając uogólnień (np. brakuje potrzebnych funkcji, system nie jest aktualny, system działa zbyt wolno)?
• Czy pracownicy zostali wystarczająco dobrze przeszkoleni?
• Czy problemy zgłasza cały zespół czy pojedyncze osoby?
• Czy system został dobrze skonfigurowany?
• Czy aktualizacje ukazują się na czas?
• Jak wygląda obsługa zapytań dotyczących krytycznych funkcjonalności?
• Czy to procedury pracy nie są wąskim gardłem?
• Czy zespół IT w placówce i serwis dostawcy wystarczająco wspierają użytkowników?
• Czy dostawca IT oferuje webinary oraz instrukcje w przypadku nowych funkcji?
• Czy funkcjonalność systemu pokrywa się z rozwiązaniami konkurencyjnymi?

Taki szczery przegląd należy przeprowadzić z przedstawicielem dostawcy IT. W razie potrzeby warto sięgnąć do bezpośredniej konfrontacji użytkowników z informatykami i pracownikami wydziału wdrożeń.

Czasami błąd będzie po stronie dostawcy IT, czasami po stronie placówki. Przykładowo, system może mieć przestarzały interfejs użytkownika (dostawca) lub w procesie wyboru systemu IT zapomniano uwzględnić zapotrzebowania na funkcje wynikające z planów rozwojowych (placówka).

Niezależnie od przyczyn, decyzja o zmianie IT musi być przemyślana i racjonalna. Tutaj kluczowe są zimne kalkulacje finansowe, a nie emocje. Jednak gdy tkwienie przy obecnym systemie oznacza dalsze narażanie się na koszty i utrudnienia, nie można zwlekać. Nie bez powodu często porównuje się wdrożenie IT do małżeństwa – kontynuacja nieszczęśliwego związku nie wychodzi nikomu na zdrowie.

Przeprowadź inwentaryzację, aby odtworzyć wszystkie procesy w nowym systemie

Decyzja zapadła, budżet został zarezerwowany i co teraz? Po pierwsze, należy opracować harmonogram projektu. W zależności od wielkości placówki, nowe wdrożenie może trwać miesiącami. Po drugie, sporządzić listę posiadanych zasobów IT i sprzętu oraz dokładnie udokumentować sposób działania starego systemu. Przyda się do odtworzenia procesów i poprawy tych kulejących. Po trzecie, zweryfikować listę zapotrzebowania na funkcje z naciskiem na elementy, których brakowało w starym systemie. I po czwarte, rozpocząć proces wyboru nowego systemu, włącznie z wizytami w podobnych do naszej placówkach, które są zadowolone z digitalizacji.

Podmioty, które mają ten proces za sobą, polecają powołanie specjalnego zespołu złożonego z informatyków, pracowników szpitala oraz konsultantów wdrożeniowych nowej firmy IT. Aby nie popełnić tych samych błędów, warto poświęcić więcej czasu na testy systemu na danych rzeczywistych. W centrum wszystkich procesów powinno być płynne przeniesienie bazy danych.

Rzeczywistość weryfikuje najlepsze plany. Przygotuj plan B

Tyle w teorii. W praktyce, wszystko może się zdarzyć. Cyfryzacja opiera się w mniejszej części na samym systemie, a w większej – na prawidłowym zarządzaniu projektem IT.

Dlatego od początku należy zwrócić uwagę na kilka nieinformatycznych elementów digitalizacji. Wśród najważniejszych są:

? Zaplanuj szkolenia tak, aby nie było żadnych słabych ogniw w obsłudze systemu. Na tym etapie trzeba mocno stąpać po ziemi. Harmonogram szkoleń powinien być dopasowany do realiów, aby nie kolidował z obowiązkami pracowników i aby nie musieli się oni doszkalać po godzinach pracy.

? Jeśli to konieczne, trzeba pomyśleć o zatrudnieniu dodatkowych osób do pomocy na okres przejściowy wdrożenia. Pomiędzy szkoleniami nie może być zbyt dużej przerwy, bo pracownicy zapomną, czego nauczyli się wcześniej. Choć harmonogram szkoleń trzeba planować z wyprzedzeniem tygodni, należy pamiętać o zachowaniu marginesu elastyczności tuż przed uruchomieniem systemu – dopiero wtedy wiadomo, które osoby mają nadal problem z obsługą systemu i trzeba zorganizować indywidualne kursy. Prowadź szkolenia tak długo, aż wszyscy użytkownicy systemu poczują się pewnie w jego obsłudze. Wymagaj od konsultanta dostawcy informacji o poziomie umiejętności zespołu.

? Przygotuj plan awaryjny i ogłoś potencjalne problemy na starcie. Można być niemal pewnym, że w pierwszych dniach po uruchomieniu nowego systemu nieraz usłyszymy „i po co było nam ruszać nasz stary system” albo „teraz jest jeszcze gorzej”.

? Kierownictwo powinno jak mantrę powtarzać, że na początku będzie trudniej, ale potem lepiej. Tak, by uniknąć dodatkowej frustracji, stresu i chaosu. Ale do zakłóceń można i trzeba się przygotować, bo powolna obsługa nowego programu nie jest żadną wymówką przed pacjentami. Taki plan B powinien obejmować m.in. procedury na wypadek przestojów czy opóźnień.

? Utwórz centrum dowodzenia zmianą. Nie zostawiaj pracowników samych sobie, gdy pojawia się problem. Stwórz zespół zarządzania wdrożeniem nowego programu, w skład którego wejdą konsultanci dostawcy IT (na miejscu i online), przedstawiciele zarządu, liderzy wdrożenia wyłonieni w placówce, informatycy. Każda z osób powinna być dostępna w czasie pracy placówki medycznej – najlepiej sporządzić listę z przyporządkowaniem zakresu odpowiedzialności do osoby oraz numerem kontaktowym. Zarezerwuj w budżecie poduszkę finansową na wypadek, gdy trzeba będzie przedłużyć szkolenia – to pozwoli uniknąć niepotrzebnych przepychanek z dostawcą IT.

? Monitoruj stan rozruchu nowego systemu. Określ z góry listę wskaźników, na podstawie których będziesz oceniał postępy wdrożenia. To może być ankieta wśród pracowników, ocena lidera wdrożenia, opóźnienia we wprowadzaniu danych, jakość danych itd. Stwórz arkusz Excel, waliduj postępy nawet co tydzień w pierwszych trzech miesiącach, a potem już tylko co np. miesiąc (w zależności od postępów). W anonimowej ankiecie pytaj wprost pracowników, w jakim procencie czują się pewni w obsłudze nowego systemu, a które funkcjonalności nadal sprawiają im problemy. Organizuj spotkania podsumowujące, podczas których omawiane będą postępy w tych obszarach, które były pierwotną przyczyną zmiany systemu. Niczego nie zamiataj pod dywan – jeśli zespół ma zaufanie do zarządu, szczery dialog będzie tylko wspierał zarządzanie zmianą.

To tylko kilka elementów zarządzania zmianą systemu IT w organizacji. Przejście na nowy system nie jest łatwe, bo zespół potrafi przyzwyczaić się nawet do źle działającego oprogramowania. Taka „apatia cyfrowa” może powoli psuć kulturę organizacyjną i osłabiać potencjał placówki w poprawie jakości usług i wzmacnianiu zadowolenia pracowników. A od tego zaczynają się kolejne problemy.

Czytaj także: Co czyni najlepsze na świecie szpitale najlepszymi?