Wdrożenie niskokodowej platformy jest istotną zmianą w szerszym spektrum transformacji firm. Ustanawia nowe połączenia pomiędzy biznesem a IT, wprowadza rzeczywiste zaangażowanie biznesu w cyfryzację, zapewnia elastyczność. W drodze do tych celów napotkać można jednak mniej i bardziej oczywiste pułapki. Podsumowujemy spotkanie społeczności CXO HUB poświęcone rozwiązaniom Low Code, które odbyło się 19 czerwca br. przy współpracy z firmami Pretius Low-Code oraz VSoft.
Podczas spotkania CXO HUB jedną z sesji poświęciliśmy wymianie doświadczeń związanych z wdrażaniem i wykorzystaniem Low Code. Dyskusję prowadzili Adam Kasperowicz, CIO w Grupie VAN, Rafał Wyszewski, CIO w Gourmet Foods oraz Tomasz Rychter, Dyrektor Pionu Innowacji i Jakości Centralnego Ośrodka Informatyki. Do dyskusji włączali się wszyscy uczestnicy spotkania – poniżej publikujemy zapis najciekawszych wątków tej dyskusji.
Przesłanki do zastosowania Low Code
Szymon Augustyniak, CXO HUB (SA): Jakie przesłanki zastosowania Low Code zadecydowały o wdrożeniu?
Adam Kasperowicz, Grupa VAN (AK): Przesłanką podstawową była strategiczna konieczność wymiany najważniejszego systemu biznesowego szybko, nadając mu nowoczesny charakter i otwierając możliwości stałego doskonalenia. Budowaliśmy system od zera, natomiast traktowaliśmy projekt od początku jako rozwojowy, mający przynieść korzyści strategiczne biznesowe i kosztowe w dłuższej perspektywie. Tak zdecydował zarząd. Szybko przy tym udało się zbudować bufor z oszczędności uzyskiwanych na bieżąco, jak kilkuset tys. złotych z rezygnacji z aktualizacji wersji serwerów aplikacyjnych, które docelowo miałby być wycofane z użycia.
Rafał Wyszewski, Gourmet Foods (RW): Pierwszą przesłanką do wprowadzania Low Code było spotkanie z dyrektorem handlowym, który opisał następująco swój „problem z informatykami”: oni dostarczą, to o co proszę, natomiast nie wiem do końca, czego potrzebuję, jakie jest moje zapotrzebowanie”.
Od tego momentu doświadczenie z Low Code, które w firmie zaczęło się nieco wcześniej, nabrało rumieńców. Zaczęliśmy dążyć do tego, aby biznesowi udostępniać środowisko, w którym będzie miał możliwość działania. Dobre zrozumienie celu, pomogło zdefiniować sposób zastosowania Low Code. Biznes zaczął bowiem automatyzować procesy, co było wcześniej zblokowane koniecznością angażowania w każdą zmianę IT. Low Code w pierwszej kolejności uwolnił szereg tego typu inicjatyw, według pomysłów, które przedstawiciele biznesu sami sformułowali a następnie wdrażali.
Testowaliśmy kilka platform Low Code na przestrzeni kilku lat. Część okazała się zdecydowanie zbyt ambitna. Inne, także dostarczane przez wielkich graczy, nie spełniły oczekiwań i efekty przyniosło dopiero zorientowanie się na platformy prostsze, łatwiejsze do wdrożenia i obsługi, zawierające wiele gotowych elementów.
Odnaleźliśmy próg adaptacji dla biznesu – biorąc pod uwagę podstawowe parametry łatwości wdrożenia, obsługi, efektywności rozwiązania. Wcześniej, pomimo że IT było bardzo nastawione na wspieranie biznesu, platformy wymagały jego istotnego zaangażowania, a to szybko hamowało postępy i rezultaty.
Tomasz Rychter, Centralny Ośrodek Informatyki (TR): Przychodząc do COI, trafiłem na projekt wdrożenia platformy Low Code, który mieliśmy reaktywować. Mieliśmy okazję przeanalizować, co było przyczyną niepowodzenia pierwszego wdrożenia. Oczywiście nie Low Code sam w sobie, ale nietrafna analiza biznesowa na początku. Nie uwzględniała ona realiów i potrzeb tego projektu, a dodatkowo podczas realizacji partner zaproponował nierealne elementy do wdrożenia.
Na podstawie analizy tego niepowodzenia sformułowaliśmy nowy tryb wdrożenia Low Code, który planujemy zastosować. W pierwszej kolejności określiliśmy, kto dokonuje analizy, komu powinniśmy zaufać przy podejmowaniu decyzji o wdrożeniu Low Code i wyborze platformy o określonych cechach. Przekazanie tego zadania partnerowi oznacza ryzyko szablonowego podejścia do naszych bardzo indywidualnych wyzwań. Sprowadzałoby się to wręcz do znanej zasady – jeśli ktoś ma w ręku młotek, to wszystko w zasięgu wydaje mi się gwoździem. Tymczasem po chybionej analizie biznesowej uruchamia się propagacja błędów – w związku z tym żaden kolejny etap nie jest w stanie przynosić pozytywnych rezultatów.
Przesłanki wykorzystania Low Code w administracji postrzegamy dzisiaj przede wszystkim z perspektywy potrzeby dostarczenia rozwiązań do tych miejsc w łańcuchu cyfryzacji administracji, które są zbyt małe, aby można było tam angażować wielkie nakłady IT i realizować projekty. Nawet jeśli przyznano by im poważne budżety, to nie dysponują one zasobami własnymi, aby prowadzić cyfryzację. Dotyczy to miejskich i gminnych ośrodków administracji centralnej i samorządowej.
Ich cyfryzacja jest zarazem ważna, niezbędna. Natomiast te zadania są podwójne, ponieważ dotyczą rozwiązań wspólnych, które możemy obsłużyć centralnie, jak też specyficznych, „lokalnych” i to właśnie je przede wszystkim obsłuży Low Code. Cały szczegółowy schemat będzie wynikał z analizy indywidualnych przypadków, z pewnością bowiem nie chcemy odsyłać po wsparcie do dostawców, ale do własnego, wewnętrznego zespołu, który nad platformą Low Code będzie czuwał.
Kto przyswoi Low Code?
SA: Bardzo ciekawa wydaje się kwestia zbudowania lub zapewnienia kompetencji do zarządzania platformą i jej wsparcia oraz kompetencji użytkowników, ich zdolności przyswojenia sobie działania w Low Code.
RW: Zaobserwowaliśmy, że bardzo szybko oswajają się z Low Code ci biznesowi użytkownicy, którzy mają choćby podstawowe wyobrażenie o informatyce, programowaniu oraz zdolności matematyczne, logiczne. Low Code stał się dla nich narzędziem usprawnienia pracy, realizacji zadań. Szybka adaptacja przez nich, szybkie uzyskanie pierwszych rezultatów, stało się też kołem zamachowym szerszej zmiany. Natomiast ludziom bez przygotowania jest zdecydowanie trudniej. Bywało, że nawet roczne szkolenia nie dawały rezultatów, nie byli w stanie integrować danych przy pomocy Low Code tylko „po staremu” robili to w Excelu.
AK: Są też przykłady programistów, którzy mieli trudności z tą zmianą. W pewnym momencie niektórzy nawet się poddali, wycofali się z nauki. Nie ma zatem prostej odpowiedzi, bo z pewnością nie można też powiedzieć, że Low Code jest dla mniej zdolnych, mniej błyskotliwych programistów. Wręcz przeciwnie – ci najlepsi, jak zauważyłem, chętnie wchodzą w Low Code i doskonale się w nim odnajdują. To dla nich świadomy wybór, bo oceniają, że mogą osiągnąć więcej, niż kodując tradycyjnie. Więcej czasu poświęcają też na rozmowę z biznesem, mogą w większym stopniu sterować pracą innych. Low Code narzuca standardy – warto wykorzystać to do organizacji ściślejsze współpracy z biznesem, pod przewodnictwem IT.
TR: Sytuacja się komplikuje, kiedy myślimy o rozwiązaniu, które ma żyć dłużej i będzie wymagało dalszego rozwoju, optymalizacji. Często na przykład w Scrumie, jeśli osiągniemy pierwszy sukces, pojawia się oczekiwanie, że będziemy szli dalej tą ścieżką, aby zebrać kolejne korzyści. To okazuje się wyzwaniem, bo o ile w Low Code sama wiedza jak wyklikać rozwiązanie z dostępnych elementów jest przystępna, zależnie od platformy, to myśląc w dłuższej perspektywie należy gromadzić jej więcej. Aby długofalowo osiągnąć sukces, aby go skalować, umacniać, potrzeba wiadomości analitycznych, czy np. w ciągu roku ścieżka rozwoju w Low Code nie osiągnie kresu i czy nie będę potrzebował migracji do innego rozwiązania. Jest to więc kwestia wiedzy – własnej albo partnera, żeby strategicznie planować.
Rozmawiając o kompetencjach nie wolno zapominać o ich późniejszym wykorzystaniu. A wszyscy owi potencjalni użytkownicy Low Code, czy to z biznesu, czy ze styku IT z biznesem, ci ze zdolnościami, predyspozycjami – są z reguły także mocno obciążeni pracą. Rodzi się więc pytanie: czy jesteśmy w organizacji w stanie przestawić tak zwrotnicę, żeby do ich obowiązków dołożyć jeszcze programowanie w Low Code? Jeśli tak, to kosztem jakiej części ich dotychczasowych zajęć? Uważam, że wdrożenie Low Code nie powinno być traktowane jako sposób na szybkie uzupełnienie wakatów w IT.
Przyśpieszenie dzięki Low Code pracy programiście przy realizacji PoC jest bardziej realnym scenariuszem. Ale także z pewnością nie na zasadzie, że Low Code zastąpi nam programistów.
Adam Wojtaszek, Experis: Odnoszę czasem wrażenie, że programista Low Code miałby być programistą innego gatunku. Typową cechą programistów jest operowanie pewnym ruchomym kapitałem doświadczenia: repozytorium sprawdzonych kodów, bibliotek, mikroserwisów. Trudno mi sobie wyobrazić, aby dało się to wykorzystywać w Low Code. W Low Code programista w zasadzie nie ma możliwości przenoszenia, powtarzania sprawdzonych przez lata schematów. Nadal musi dysponować głębszą refleksją, ale innego typu – jak połączyć gotowe elementy. Dlatego wydaje mi się, że Low Code niejako powołuje do życia nowy gatunek programistów. A dalej – także nowy schemat i nowy zestaw ról.
W pewnej części developer będzie odpowiadał za integracje albo dopisze w razie czego brakujący fragment kodu, natomiast za architekturę biznesową będzie odpowiadał użytkownik wywodzący się z biznesu, który teraz dodatkowo będzie miał narzędzia do stworzenia sobie rozwiązań potrzebnych do ulepszenia procesu.
AK: Low Code z pewnością nie tworzy w organizacji ścian, ale właśnie sprzyja integracji. Nie dostrzegam też ścian, ograniczeń, do których moglibyśmy dochodzić, pomimo, że rozwiązanie żyje. Każdy kto wytwarza w Low Code systemy dąży do tego, żeby były coraz lepsze. Taka zresztą jest obietnica – szybciej możemy poprawić to, co wymaga zmiany. Poprawki, zmiany, rozwój, dodawanie funkcji, są częścią niepisanej umowy pomiędzy IT, które dostarczyło taką platformę, razem z prawami i obowiązkami, oraz biznesem, który musi zaakceptować to środowisko, aby wesprzeć w większym stopniu cyfryzowanie firmy.
Zmieniają się też nieustannie same platformy. Producenci także zdają sobie sprawę z konieczności doskonalenia środowisk. Nie dziwię się im, skoro mają doskonały poligon zbierania doświadczeń i podpowiedzi od rosnącej rzeszy zaangażowanych w nie użytkowników.
RW: Można zaobserwować duże różnice pomiędzy platformami. Są platformy bardzo trudne, wymagające niekiedy w zasadzie tyle pracy, co programowanie, a inne są łatwe i intuicyjne. Naturalnie nie dzieje się to przypadkiem – ukierunkowane są bowiem na różne zastosowania, na różny kontekst.
Low Code „obok” innych technologii, a nie „zamiast”
Adam Wojtaszek: A czy to nie jest następny krok w całej historii programowania? Biorąc zwłaszcza pod uwagę wsparcie tzw. generatywnego AI w kodowaniu, składaniu gotowych elementów kodu…
TR: Nie do końca bym się zgodził, że to kolejny krok. To bardziej nowa gałąź, dyscyplina. Porównałbym to do rozwoju narzędzi do pisania stron internetowych, który obserwowałem przez dużą część mojego zawodowego życia z bliska, jako front-end developer. Najpierw pisaliśmy strony statyczne, a potem dynamiczne, do których niektórzy korzystali z gotowych CMS’ów, inni pisali własne. Z tych gotowych systemów bardzo prosta była np. Joomla, a z kolei Drupal był bardzo skomplikowany. Po latach nadal mamy webdeveloperów, którzy na tych dawnych CMS-ach się opierają, bo one wciąż żyją, obok nowych rozwiązań do budowy witryn. Powiedziałbym więc, że Low Code to raczej kolejna grupa – klasa narzędzi do kolejnych zadań.
RW: Tym bardziej, że dziś dobrze jest łączyć umiejętności, aby programiści nie stawali się monograficzni, stosując jedno podejście do wszystkiego. Przeciwnie, to używając połączeń między Low Code a programowaniem wysokopoziomowym, stosując te narzędzia i platformy naprzemiennie, odpowiednio do wyzwań, szybciej uzyskuje się efekty. Współpraca narzędzi ma służyć lepszym efektom, uzyskiwanych dużo szybciej. Przykłady rozmiarów tego przyśpieszenia możnaby mnożyć, przy czym skrócenie czasu wykonania o kilka rzędów, np. z 6 miesięcy do miesiąca to typowe uzyski w takim zróżnicowanym podejściu.
Michał Jurkowski, VSoft: W tym momencie wracamy do kwestii możliwości rozwiązania problemu deficytu pracowników IT przez adaptację Low Code. Mnie się wydaje, że Low Code nie tyle wprost pomaga w tym, co zwiększa elastyczność. Działa pośrednio. Do pracy w środowisku Low Code możemy pozyskać pracowników nie przeszukując wyłącznie ofert informatyków, ale także osób z inną podstawową specjalizacją, które rokują, że wejdą w tryb pracy jaki oferuje środowisko Low Code. Wówczas to zaczyna wpływać na uzdrowienie sytuacji – poszerzamy sobie spektrum osób, które mogą realizować zadania.
TR: Taka jest też nasza wizja obsłużenia procesu cyfryzacji w mniejszych ośrodkach, gdzie o wysokiej klasy specjalistów jest trudniej. Nawet jeśli użytkownicy Low Code nie zbudują samodzielnie całego rozwiązania, to będą mieli zdolność opanowania pracy w tym trybie i przyspieszą jego powstanie.
AK: Mnie na przykład udało się pozyskać dzięki Low Code ludzi, którzy wcześniej, pomimo że wywodzą się z biznesu, byli zainteresowani pracą choćby częściowo w IT. Dopóki nie pojawił się Low Code nie mieli jednak takiej możliwości.
Dominik Sawicki, BEC: W jakim stopniu platformy Low Code potrafią demokratyzować firmę pod względem IT? Czy nie rodzi to wyzwań cyberbezpieczeństwa albo związanych z trudnością dokumentacji wytwarzanych w takim trybie rozwiązań?
RW: Aby uniknąć wyeksponowania w ten sposób na zagrożenia, przede wszystkim nie pozwalaliśmy biznesowi robić aplikacji komunikujących się ze światem zewnętrznym. Po drugie – stawialiśmy na współpracę IT z biznesem. Udostępnialiśmy i uczyliśmy narzędzi w momencie, kiedy potrzeba, jaką zgłaszał biznes mogła być obsłużona przez niego samodzielnie w Low Code.
Taka stabilność, pewność jest faktem, więc stopniowo Low Code stało się elementem kultury firmowej. Dlatego dziś np. w procesach HR zwraca się u nas uwagę na umiejętność wykorzystania środowiska cyfrowego – jest to jednym z kryteriów przyjmowania do pracy, a także jest przedmiotem doskonalenia, ponieważ w takim środowisku na co dzień wszyscy w dużej mierze pracujemy.
Pułapki i niespodzianki podejścia niskokodowego
W dyskusji pojawiały się już wzmianki o pułapkach i niespodziankach. Spróbujmy ująć to jeszcze raz: przed czym należy przestrzec przy wdrażaniu Low Code?
AK: Z pewnością nie można puścić Low Code na żywioł, bez kontroli. Trzeba w zarodku likwidować wszelkie przejawy Shadow IT. W IT powinna stale palić się ostrzegawcza lampka – jakie dane chcą w swoich rozwiązaniach udostępniać ich twórcy, czy nie powołują nagle redundantnych baz danych, czy zachowują zasady określone wewnętrznym governance i zgodności z prawem dotyczącym np. danych osobowych?
Musimy kontrolować do jakich danych jest dostęp, a Low Code jako transparentna przestrzeń w tym pomaga, ponieważ wiemy jakie narzędzia i jakie dane udostępniamy.
RW: Jest też pewne interesujące zjawisko, które, jeśli wymknie się spod kontroli, może pójść w niedobrą stronę. Low Code po prostu angażuje, wciąga. Miałem przypadki, kiedy przełożony biznesowych użytkowników Low Code przychodził do mnie z prośbą o odebranie uprawnień do platformy tłumacząc, że pochłania go chęć robienia w niej ciekawych rzeczy kosztem podstawowych obowiązków.
Marek Godala, Globema: Czy punktem szczególnie trudnym i ryzykownym nie jest moment przestawienia się programistów na środowisko Low Code?
AK: Taki problem faktycznie występuje. Niekiedy pokrywa się to z różnicami pokoleniowymi, niekiedy po prostu ze ścisłą specjalizacją, wzmocnioną dodatkowo przyzwyczajeniem. Są programiści, którzy nie będą chcieli zmiany. I jest to ryzyko, które trzeba uwzględnić, ale nie dotyczy ono wyłącznie Low Code.
TR: W tym wypadku można jednak rzeczywiście mówić o podwyższonym ryzyku. Zastanówmy się, jak kalkulują programiści: na ile Low Code to przyszłościowa kategoria? Jego nauka przecież zajmie czas, w którym zdezaktualizują się przynajmniej częściowo podstawowe, dotychczasowe kompetencje i umiejętności. Jeśli zaś są one na rynku cenniejsze – to programista nie będzie zainteresowany taką zmianą na gorsze i z dużym prawdopodobieństwem poszuka innego miejsca. Inaczej sam ryzykuje, że wypadnie z obiegu.
Jakub Głąb, VSoft: Rozmawialiśmy tu o roli partnerów, a potem zgodziliśmy się, że efektywność Low Code warunkuje wpięcie go w istniejący governance. Chciałbym więc zapytać: czy governance w obszarze Low Code powierzyć można zewnętrznemu partnerowi czy lepiej wewnętrznemu zespołowi?
AK: W wyniku poszerzającego swój zakres wdrożenia Low Code, IT podzieliło się na domenowe zespoły w ramach platformy. A zarazem nie mogąc nakładać kolejnych obowiązków na barki tych osób – poprosiłem o częściowe wsparcie w tym zakresie osoby z zewnątrz, która reprezentuje partnera.
RW: Potwierdzam – zdecydowanie to IT obejmuje governance Low Code, natomiast wymaga to niekiedy zatrudnienia dodatkowo osób.
TR: My będziemy budować całkowicie nowy, wyznaczony od początku do tego zadania zespół. Będzie on musiał ściśle współpracować z analitykami, z działem governance. Spodziewamy się też, że zacznie działać grawitacja organizacyjna, kiedy zespół okrzepnie kompetencyjnie, zaczną przychodzić do niego ludzie z organizacji i dokonywać zleceń podporządkowanych wybranym regułom i standardom, przede wszystkim ważne to będzie w przypadku zleceń automatyzowania procesów wewnętrznych w różnych działach.
Dominik Sawicki: Czy z kolei utrzymanie platformy Low Code nie obciąża IT? Jak odbywa się aktualizacja lub zmiana platformy?
RW: Wytwarzane są niewielkie automatyzacje i rozwiązania, które nawet zsumowane nie stanowią istotnego narzutu pracy w zakresie utrzymania. Często też, przy zmianie pracownika, te rozwiązania budowane są od nowa, wytwarza je od nowa użytkownik, który został nowym właścicielem procesu i zarazem twórcą odpowiadających mu narzędzi.
Ryzyko związane z aktualizacją platformy to w pewnym sensie już historia. Rzeczywiście, kilka lat temu obawialiśmy się takich zmian, obecnie aktualizacje są płynne, niewidoczne dla nas – nie przysparzają nam ani dodatkowej pracy, ani kłopotów.
Jakub Głąb: Jakim wyzwaniem jest z kolei pozyskiwanie kompetentnych osób do pracy z platformą – trudno znaleźć w ogłoszeniach o pracę ofert dla pozycji np. „citizen developer”. Skoro nie ma ich na rynku, to gdzie w razie potrzeby ich szukać? Interesuje mnie szczególnie na ile jest to ryzykowne dla całego przedsięwzięcia Low Code w firmie?
TR: To jest wyzwaniem w IT dla każdego obszaru, ale dużo pomagają działania w zakresie budowy marki. Próbujemy też rekrutacji wewnętrznej, a ponieważ zgłasza się u nas do pracy wielu chętnych, niektórym z nich możemy proponować udział w nowym zespole Low Code. Dla wielu to tym atrakcyjniejsze, że projekt jest u zarania – nie wybraliśmy dotąd jeszcze platform, można powiedzieć, że zyskują premię za bycie wśród pionierów.
Poszukujemy zdolnych i zarazem elastycznych osób, które przyswoją każdą platformę, a nie konkretną i zechcą raczej obejmować wiedzą i doświadczeniem całość Low Code. A dodatkowo integracje z systemami powstającymi w innych technologiach.
Bezszwowe organizacje
SA: Spróbujmy podsumować korzyści i znaczenie tej zmiany, jej głębokość. Czy to rewolucja dla firmy, kamień milowy budowy „bezszwowych” organizacji?
RW: To z pewnością nowa jakość dla biznesu – nowego typu oferta współpracy, zaangażowania dla ludzi, którzy chcą mieć wpływ, ułatwiać sobie pracę, wprowadzać automatyzacje, uzyskiwać skokowe przyrosty efektywności. To pociąga i zarazem stanowi istotę tej zmiany.
AK: Widzę tę zmianę wielowymiarowo, w pewnej sekwencji. Obok pojawienia się Agile, to kolejna ważna zmiana, dzięki której biznes rozumie technologię, myślę tu o jej logice. I chce się w nią angażować, stosować do zmian procesów.
TR: Low Code to kolejne narzędzie ułatwiające demokratyzację. Kolejne obniżenie poziomu wejścia w świat technologii, które pozwala łatwiej zrozumieć procesy. A dzięki przyjęciu wspomnianej logiki – użytkownicy ze świata biznesu będą mogli poprzez Low Code sami kształtować rozwiązania. Scrum się długo adaptował – i często ponosił porażki. Mając to w pamięci, starałbym się niwelować wszelkie indywidualne, charakterystyczne dla danej firmy przeszkody, przyczyny błędów i problemów w adaptacji. Po to, aby nie płacić podwójnie „frycowego”, nie odrabiać ponownie lekcji bardzo podobnej do tej z wdrażania Agile. To można wpisać zarówno do kategorii wyzwania, jak i korzyści.
