Kierownicy działów IT dużych firm zwykle nie narzekają na nadmiar wolnego czasu. Poza zagadnieniami typowo infrastrukturalnymi zwykle zajmują się również szeregiem systemów biznesowych. Niektóre z nich są niezwykle rozbudowane i wymagają sporego zaangażowania. Jednocześnie użytkownicy bardzo często domagają się wprowadzania kolejnych, często niewielkich, rozwiązań.
Pracownicy IT świetnie wiedzą, że koszty związane z wprowadzaniem nowych systemów pojawiają się jeszcze zanim rozpocznie się wdrożenie. Samo przygotowanie do projektu wymaga sporo pracy, bez względu na to, czy myślimy o wdrożeniu własnym zespołem czy też o zaangażowaniu zewnętrznego wykonawcy. Zakres wdrożenia trzeba wstępnie rozpoznać, zrozumieć jego dziedzinę oraz przynajmniej wstępnie opracować koncepcję rozwiązania od strony nie tylko technicznej, lecz również organizacyjnej, podejmując przy tym szereg decyzji.
Uruchomienie nowego projektu może oznaczać konieczność doszkolenia kadry. System, nawet jeśli jego wdrożenie będzie szybkie i stosunkowo tanie, wymaga zazwyczaj serwerów i długoletniego wsparcia, co znów wiąże się z kosztami organizacyjnymi i finansowymi. Co istotne, koszty często tylko nieznacznie zależą od skali projektu.
Porównajmy dwa przypadki: mały system dla pięciu użytkowników jednego biura i duży system dla tysiąca użytkowników całej korporacji. Jeśli przeliczyć zaangażowanie własne działu IT na liczbę użytkowników, którzy odniosą korzyść w obu tych przypadkach, okaże się, że mały system jest znacznie droższy!
Mały system oznacza duży nakład pracy również po wdrożeniu. Tak jak duży system, również wymaga poprawek, reakcji na nieprzewidziane zachowania użytkowników, zarządzania backupami itd. A wszelkie koszty z tym związane spadają na dział informatyczny.
Skoro wdrożenie małych systemów przynosi niewiele korzyści, nasuwa się konkluzja, że należy unikać ich wdrożenia. Oczywiście nie zawsze jest to możliwe.
Jednym z istotnych, choć być może nieoczywistych, zadań struktur IT w dużej firmie jest oddzielenie tematów, które należy doprowadzić do wdrożenia, od tych, które powinny być przy wdrożeniu pominięte.
Rzecz jasna pojawiają się projekty, których realizacji odmówić nie można. Ale czasem odmowa jest wręcz oczekiwana. Często osoby "na górze" nie wykazują się asertywnością i spychają problem na dział IT: "Porozmawiajcie z informatykami, jeśli okaże się, że problem da się łatwo rozwiązać, może IT wam to zrobi.". W takiej sytuacji działowi IT przypada niewdzięczna rola "ucięcia" tematu.
Częste są również sytuacje, gdy dostatecznie zmotywowani użytkownicy nie konsultują się z "górą", lecz od razu idą ze swym pomysłem do działu informatycznego. Udzielenie odpowiedzi odmownej jest wówczas łatwiejsze, lecz stałe odmawianie powoduje, że dział IT zdobywa sobie złą opinię.
Należy zaznaczyć, iż problemy i oczekiwania użytkowników nie zawsze są zwykłym "chciejstwem" i że czasem stoją za nimi bardzo ważne problemy, ignorowane przez kadrę zarządzającą. Niektóre z takich rozwiązań wręcz należałoby wdrożyć, aczkolwiek z pewnym zastrzeżeniem.
Otóż użytkownicy mają skłonność do przedstawiania swoich oczekiwań w postaci opisu gotowego rozwiązania. Jest to częsty błąd, który osobom nietechnicznym można wybaczyć. Gorzej, gdy pracownicy działu IT podchwycą temat w sposób podany przez użytkownika, nie starając się dotrzeć do istoty problemu. W skrajnym przypadku może się to skończyć wdrożeniem rozwiązania zgodnego z opisem, ale nie realizującego kluczowej potrzeby. Istotą działania IT w tym obszarze powinno być wyjście z domeny rozwiązań użytkownika i dotarcie do domeny problemu, co pozwoli ocenić jego rzeczywistą naturę.
Bez względu na istotę problemu czasem należy odmówić realizacji projektu. Nie oznacza to jednak, że zawsze trzeba zostawić użytkownika z niczym. Od działu IT należy oczekiwać kompetencji, pozwalających na udzielenie użytkownikowi pomocy przy minimalnych nakładach.
Czasem więc zamiast prostego "nie" można nakierować użytkownika na rozwiązanie pozasystemowe lub zaproponować proste narzędzia ułatwiające pracę.
Jednym z najpowszechniej stosowanych narzędzi tego rodzaju nadal są arkusze kalkulacyjne, z MS Excelem na czele. Mimo iż rozwiązania oparte na arkuszach mają słabe strony, to są czasem wystarczające. Zwykle największą trudnością jest tu jest brak kompetencji użytkownika, który nawet nie wie, że arkusz lub jego odpowiednie użycie może być rozwiązaniem.
Kiedyś powszechnie stosowano również aplikacje tworzone w MS Access. Co ciekawe, MS Access pozwalał osobom nietechnicznym na tworzenie całkiem zaawansowanych baz danych. Dziś ta technologia jest już raczej archaiczna, choć nadal spotyka zaimplementowane w niej dobrze działające aplikacje.
Nierzadko użytkownicy uparcie nie przyjmują odmowy. W takiej sytuacji najlepszym wyjściem jest uświadomienie kosztów, jakie są związane z danym tematem. Można wręcz spróbować przenieść część kosztów projektu na użytkownika. Wystarczy poprosić o przygotowanie specyfikacji, rozpoznanie rynku gotowych produktów tego rodzaju, poszukanie potencjalnych dostawców itd.
W ten sposób możemy również determinację użytkownika i odróżnić zachciankę od rzeczywistej potrzeby. Co więcej, przyczyniamy się do pełniejszego zrozumienia przez osoby nietechniczne specyfiki pracy działów IT, co może procentować w przyszłości.
Czasem wdrożenie jednego (bądź wielu) małych systemów jest, mimo relatywnie wysokich kosztów, nieuniknione. W takiej sytuacji wysiłki IT powinny zmierzać w stronę minimalizowania nakładów. Można to osiągnąć na kilka różnych sposobów.
Najczęstszym, choć nie zawsze możliwym (nie zawsze również najtańszym) jest dodanie nowego modułu do już istniejącego systemu. Największą zaletą takiego podejścia jest minimalny wzrost kosztów związanych z utrzymaniem, ponieważ nowe funkcjonalności zwykle nieznacznie wpływają na złożoność całości.
Innym podejściem jest wdrażanie systemów jedynie w technologiach już szeroko stosowanych w firmie. Eliminuje to problem z dostępem do specjalistów, jednak wpływ na sumaryczny koszt wdrożenia i utrzymania jest na ogól niewielki.
Jeśli w firmie stale powstają coraz to nowe małe systemy "poboczne", warto pomyśleć o rozwiązaniach technologicznych z grupy low-code development, takich jak InstaDB. Są to narzędzia, które pozwalają na wytwarzanie aplikacji bez (lub przy minimum) pisania kodu.
Platformy low-code development sprawiają, że tworzenie różnorodnych aplikacji jest bardzo szybkie. Brak konieczności pisania kodu, jego debugowania i pielęgnacji znacząco skraca czas pracy i obniża koszty. Dodatkowo development często jest na tyle prosty, że podobnie jak w przypadku MS Access użytkownicy mogą samodzielnie tworzyć w nich własne rozwiązania.
Platformy low-code development zapewniają zwykle spójne i stabilne środowisko aplikacji, co zmniejsza koszty utrzymywania pojedynczych aplikacji. Dzięki narzędziom związanym z kopiami zapasowymi, tworzeniem kopii roboczych, zarządzaniem dostępami czy przywracaniem wersji historycznych utrzymanie gotowych aplikacji jest bezproblemowe, a dodawanie kolejnych aplikacji praktycznie nie wiąże się z większym obciążeniem.
Być może najważniejszym wnioskiem jest, iż w przypadku małych systemów nie zawsze należy pozytywnie odpowiadać na potrzeby użytkowników. Nierzadko jest to nie tylko niekonieczne, ale wręcz niepożądane.
Jeśli jednak wdrożenie niewielkiego systemu jest z jakiegoś powodu nieuniknione, należy się do niego zabrać bardzo uważnie, ponieważ koszty z&pewnością będą niewspółmiernie duże do korzyści. Koszty należy w miarę możliwości obniżać, stosując obecne już w organizacji rozwiązania i technologie.
Jeśli spodziewamy się wielu drobnych wdrożeń w przyszłości, warto rozważyć skorzystanie z jednej z platform z grupy low-code development.