Automatyzacja to Projekt

We wrześniu tego roku byliśmy częścią bardzo ciekawego wydarzenia, jakim była konferencja Common, jej tematem przewodnim były rozwiązania powerowe firmy IBM. Jako jeden ze sponsorów mieliśmy przyjemność poprowadzić panel tematyczny „Dodaj Powera swojemu biznesowi”.

IBPM S.A. kojarzy się przede wszystkim z rozwiązaniami integracyjnymi i szeroko rozumianą automatyzacją. Jak odnaleźliśmy się w środowisku hardwarowym? Jaki widzimy związek pomiędzy robotyzacją, integracją i automatyzacją a serwerami Power?  Czy istnieją wspólne płaszczyzny dla tych rozwiązań?

W ramach naszego panelu zrezygnowaliśmy z prezentacji i slajdów. Postanowiliśmy porozmawiać o tym, jak holistyczne podejście do integracji i automatyzacji może dodać „powera” do budowanych rozwiązań, ale też o tym jak dobrze zacząć i na co zwrócić uwagę. Rozmowę poprowadziła Paula Rutkowska, Business Development Manager, na pytania której odpowiadali Waldemar Pietrzak, ESB Center Manager, SOA Architekt oraz Krzysztof Marciniak, Business Development Director.

Podczas rozmowy postawiliśmy tezę, że automatyzacja to projekt, a wpisują się w nią stwierdzenia:

Software i hardware nie są rozłączne, musi być pomiędzy nimi synergia IT i Biznes muszą ze sobą rozmawiać i współpracować
Potrzebny jest „punkt bólu” i mobilizacja w organizacji Pracownicy biznesu potrzebują spojrzenia z zewnątrz swojego biurka

Paula Rutkowska: Dla wielu osób związek pomiędzy rozwiązaniami infrastrukturalnymi a tematem automatyzacji nie jest oczywisty. Zacznijmy zatem od pytania, jak ma się infrastruktura do automatyzacji? Czy te tematy da się łączyć?

Waldemar Pietrzak:

Jedną z tez, którą postawiliśmy na wstępie jest koncept, że automatyzacja to projekt. Przy takim spojrzeniu należy pamiętać, że samo oprogramowanie realizujące pewną logikę automatyzacji jest tylko jednym z elementów przedsięwzięcia. Oprócz oprogramowania mamy także hardware w sensie jednostki obliczeniowej: serwera, procesora czy kontrolera oraz innych wyspecjalizowanych układów. A także innych komponentów, które są często bardzo indywidualne dla danego projektu: elementów mechanicznych, urządzeń, dronów – w zależności od tego o jakim projekcie automatyzacji mówimy.

W naszej dyskusji chcę się skupić głównie na projekcie automatyzacji w rozumieniu projektu IT w przedsiębiorstwie, gdzie dwa główne komponenty to hardware i software i na styku tych dwóch obszarów się poruszamy. W tego typu projektach w większości przypadków software i hardware są ze sobą nierozerwalnie związane. Nawet w specyficznych projektach, które są realizowane z wykorzystaniem chmury publicznej, istnieje warstwa uruchomieniowa w postaci wirtualnej. Jednakże wynosimy ją na zewnątrz organizacji, bazując na gwarancjach i zaufaniu – ale mimo wszystko, cały czas musimy ją zdefiniować i skonfigurować. Natomiast w projektach typu private cloud wirtualizujemy pewne warstwy systemu, ale cały czas musimy zapewnić fizyczne urządzenia, na których chmura prywatna będzie uruchomiona.

Obie części projektu hardware i software są bardzo ważne dla sukcesu całego przedsięwzięcia, którego odbiorcą jest przede wszystkim organizacja i biznes. Stąd wynika moje przekonanie, że software i hardware powinny współpracować w synergii w służbie biznesu.

Paula Rutkowska: Jednym z filarów naszej codziennej pracy jest automatyzacja. Dziś też o niej mówimy. Z doświadczenia jednak wiem, że definicji automatyzacji może być wiele. Czym dla Was jest automatyzacja? Jak możemy ją zdefiniować?

Krzysztof Marciniak:

Dobre pytanie. Automatyzacja to dość pojemne słowo i na pewno wielu z nas różnie ją interpretuje. Przygotowując się do tego spotkania, w pierwszej kolejności naturalnie chciałem wyszukać w Internecie prostą definicję posiadającą wspólny mianownik pasujący do każdego oblicza automatyzacji. Takim, który połączy dwa światy, o których tutaj rozmawiamy, świat aplikacji i świat infrastruktury. Ostatecznie jednak chciałbym odpowiedzieć na Twoje pytanie z perspektywy czasu i tego jak my na przestrzeni lat postrzegaliśmy automatyzację. Kiedyś automatyczne wysłanie maila z załącznikiem było automatyzacją. Inny przykład, to w większych firmach działy procesów i procedur, które jako pierwsze modelowały procesy biznesowe i szukały optymalizacji. Najpierw na papierze, potem w narzędziach klasy BPMS. Potem pojawiły się pierwsze roboty, mam na myśli zarówno Voiceboty, Chatboty czy po prostu RPA i możliwości na kolejnej warstwie automatyzowania czynności manualnych. Co dalej? Ostatnio miałem okazję przeczytać o tym, że Skoda testuje odbiór paczek z bagażników swoich samochodów. Ciekawe wyzwanie i pomysł. Ja osobiście z racji mojego doświadczenia czekam na wykorzystanie możliwości dronów w branży telekomunikacyjnej. Marzy mi się w pełni samodzielny proces samoinstalacji u nowego operatora telekomunikacyjnego, a potrzebny sprzęt niech dostarczy mi dron przez okno. Tutaj chyba już odpłynąłem, więc na koniec coś ze wspomnianego Internetu. Automatyzacja to po pierwsze minimalizowanie aktywności użytkowników. Automatyzacja to po drugie poprawa jakości danych i minimalizowanie błędów. Automatyzacja wreszcie to po trzecie redukcja kosztów operacyjnych.

Waldemar Pietrzak:

Z mojego punktu widzenia, architekta i dostawcy – projekty automatyzacji są bardzo różnorodne, mamy przekrój bardzo różnych rozwiązań w zależności od sektora, domeny rozwiązania, różnych potrzeb i dojrzałości organizacji.

Spektrum jest duże – od bardzo prostych usprawnień automatyzujących kroki dotychczas realizowane przez człowieka, integracje danych i usług, poprzez Roboty (RPA) na warstwie aplikacyjnej, rozwiązania hybrydowe ze skomplikowanymi procesami biznesowymi integrującymi wiele systemów dziedzinowych, aż po uczenie maszynowe i rozwiązania bazujące na sztucznej inteligencji. W wielu sytuacjach często możemy wesprzeć się technologią, która dostarcza nowe rozwiązania dla realizacji wymagań stawianych przed automatyzacją. Mam tu na myśli choćby przyspieszenie i optymalizację procesów, czy eliminację błędów ludzkich.

Natomiast wybór technologii dla realizacji automatyzacji jest mocno zależny od dziedziny rozwiązania i stawianych celów. Przykładowo są rozwiązania, gdzie akceptuje się możliwość uczenia się i doskonalenia mechanizmu automatyzacji, gdzie można zastosować uczenie maszynowe. I są rozwiązania, gdzie błąd jest nieakceptowalny, a tym samym pewne metody i technologie są trudne do zastosowania. Na pewno w najbliższej przyszłości będą pojawiać się nowe możliwości automatyzacji wynikające z nowych rozwiązań i technologii.

Paula Rutkowska: O technologię też chcę Was zapytać, ale zanim o tym, powiedzcie proszę, po co automatyzować?

Krzysztof Marciniak:

Chyba zacznę od końca mojej poprzedniej wypowiedzi i na pewno, co oczywiste zwrócę uwagę, że automatyzujemy ze względów na koszty, a dokładnie ze względu na ich redukcję. Ważne, żeby w tym miejscu zaznaczyć, że za przekazem automatyzacji w organizacji powinien iść transparentny przekaz do pracowników, że celem automatyzacji nie są redukcje kadrowe, a bardziej efektywne wykorzystanie merytorycznych umiejętności. Automatyzacja może być narzędziem motywacyjnym. Inną korzyścią automatyzacji jest dążenie do zwinności samej organizacji, elastyczności zarządzania. Automatyzacja to także odpowiedź na konieczność przystosowania się do nowej, covidowej rzeczywistości. Myślę, że nie ma przesady w stwierdzeniu, że organizacje na wyższym poziomie automatyzacji czy digitalizacji łatwiej przystosowały się do pracy zdalnej.

Waldemar Pietrzak:

Automatyzacja, w niektórych obszarach, stała się bardzo łatwa wraz z rozwojem technologii i rozpowszechnienia się nowych rozwiązań. Kiedyś instalacja środowisk, systemów operacyjnych, oprogramowania, instalowanie poprawek bezpieczeństwa często wymagały wiele pracy administratorów lub osobistej wizyty w serwerowni. Wraz z rozpowszechnieniem się rozwiązań bazujących na maszynach wirtualnych, konteneryzacji oraz podejściu Infrastructure as a Code automatyzacja tych czynności jest bardzo łatwa. Dzięki temu na naszych oczach tworzy się elastyczna infrastruktura, w której na żądanie można powoływać nowe środowiska, skalować rozwiązania, serwery czy aktualizować poszczególne środowiska. Oczywiście dużo zależy od dojrzałości firmy, jej otwarcia na nowe technologie i ich wdrażania w ramach organizacji.

Paula Rutkowska: Omówiliśmy podstawy, czym jest automatyzacja i po co nam ona. Załóżmy, że jesteśmy przekonani. Od czego zacząć? Od czego zacząć praktyczne planowanie automatyzacji?

Waldemar Pietrzak:

Jednym z ważniejszych momentów jest zdefiniowanie potrzeby biznesowej. Jawne nazwanie tego po co chcemy realizować automatyzację, jaki jest zakres dla jej poszczególnych elementów oraz jakie cele chcemy osiągnąć. Ważne, żeby mieć na uwadze korzyści jakie przyniesie taki projekt dla biznesu i innych obszarów organizacji. Oczywiście chodzi o korzyści zarówno wymierne jak i niewymierne. Dla biznesu: może być to time to market czy czas realizacji zlecenia. Dla IT może być to łatwość aktualizacji systemów, wyeliminowanie lub zminimalizowanie liczby błędów i sytuacji wyjątkowych, czy łatwość utrzymania poszczególnych środowisk.

Automatyzacja, jej zakres – dobrany sprzęt hardware jak i zakres tworzonego oprogramowania musi być dopasowany do tej potrzeby. Na pewno warto podejść rozsądnie – nie automatyzujemy wszystkiego za wszelką cenę i dobieramy środki adekwatne do potrzeb.

Paula Rutkowska: I to jest ten zapowiadany wcześniej moment. Jak wybrać technologię? Na czym się skupić? Na co zwrócić uwagę, a co zignorować?

Krzysztof Marciniak:

Powiem przewrotnie i prowokacyjnie – najlepiej i zdecydowanie najłatwiej jest mieć architekta, jak Waldek. Odpowiednie KPI pozwolą zweryfikować skuteczność jego decyzji. Bardziej przyziemnie – na bazie moich doświadczeń myślę, że warto zwrócić uwagę na kilka dostępnych i znanych narzędzi. Pierwszym z nich jest POC (Proof of Concept). Jeśli tylko mamy taką możliwość, pomyślmy też o umówieniu się z dostawcą na succes fee. Z własnego doświadczenia wiem, że warto powiązać dostawcę hardware’u z dostawcą software’u, stąd najlepiej myśleć o rozwiązaniach cloudowych. Ułatwi to zarządzanie usługą w przyszłości i jej utrzymanie. Ważne jest też, aby zwrot z inwestycji był w miarę szybki. Obecnie od technologii oczekuje się szybkich efektów, a co za tym idzie długie projekty i inwestycje z długim czasem zwrotu są nieopłacalne z perspektywy uwarunkowań biznesowych. Ciekawym aspektem jest również podejście do unifikacji technologii. Z jednej strony z perspektywy zakupowej i negocjacyjnej mnogość technologii ułatwia obniżenie ceny i negocjacje, z drugiej każda kolejna technologia utrudnia utrzymanie, czy zmusza nas do utrzymywania kolejnych kompetencji w zespołach. Na koniec chcę zwrócić uwagę na istotną rolę partnera po stronie biznesu. Bardzo ważne jest doprecyzowanie szerzej roli właściciela biznesowego i wzmocnienie jej do etykiety ambasadora technologii.

Paula Rutkowska: W Waszych odpowiedziach pojawił się nieco szerszy kontekst niż tylko automatyzacja. Wspominaliście o hardwerze, usługach cloudowych. Mówiliście o automatyzacji w ujęciu biznesowym, ale także zwróciliście uwagę na aspekt IT. Jak do tematu automatyzacji ma się architektura korporacyjna? Warto zaplanować otoczenie, czy może działania ad-hocowe w dzisiejszych czasach lepiej się sprawdzają?

Waldemar Pietrzak:

Z racji mojego doświadczenia oraz roli jaką pełnię dosyć oczywiste może się wydawać, że jestem orędownikiem tworzenia, utrzymania i planowania architektury korporacyjnej w skali odpowiedniej do rozmiaru i dojrzałości organizacji.

Na pierwszy rzut oka być może nie widać oczywistego, ścisłego i bezpośredniego powiązania pomiędzy architekturą korporacyjną a hardwarem, urządzeniami. Jest to jednak bardzo złudne. Architektura korporacyjna przede wszystkim prezentuje „obraz z lotu ptaka”, ale analizując poszczególne perspektywy lub komponenty, bardzo szybko przechodzimy od ogółu do szczegółu. Często nie zauważalnym jest moment, kiedy realizujemy analizę oraz definiujemy architekturę i samą infrastrukturę już na poziomie sprzętu. Jest to najłatwiej uchwytne, gdy analizujemy kwestie bezpieczeństwa lub komunikacji pomiędzy systemami – a komunikacja bezpośrednio wynika z automatyzacji procesów.

Paula Rutkowska: Waldek, integracja to ogromna część Twojej codziennej pracy. Czy można podejść do automatyzacji bez integracji?

Waldemar Pietrzak:

Niezależnie od rodzaju i zakresu automatyzacji – automatyzacja i integracja są bardzo powiązane. Ma to szczególne znaczenie dla większych organizacji, gdzie każda automatyzacja wiąże się z komunikacją i wymianą informacji pomiędzy systemami.

Integracja i sposób jej realizacji ewoluuje. Kiedyś integracja była prostą formą przenoszenia plików, danych. Królowało podejście SOA (Service Oriented Architecture) – wszystko jest usługą. Obecnie to się zmienia i preferowane jest bardziej elastyczne podejście – reprezentowane przez API Management, mikrousługi. Niezależnie od rodzaju integracji i jej dojrzałości w organizacji, wydaje mi się, że są to pojęcia nierozerwalnie związane – szczególnie w dużych organizacjach, gdzie mamy wielość rozwiązań i systemów.

Paula Rutkowska: Kiedy mówimy o automatyzacji często myślimy o procesach biznesowych, celach i korzyściach dla Biznesu. Jaka jest rola IT w procesie automatyzacji i kiedy warto pomyśleć o dostawcy?

Krzysztof Marciniak:

Nie jestem pewny, czy jest jedna, krótka i dobra odpowiedź na to pytanie. Na pewno wiele zależy to od wielkości organizacji, samej struktury organizacyjnej czy nawet właścicielstwa wewnętrznych budżetów. Przez ostatni rok miałem okazję uczestniczyć w kilku projektach i zobaczyć skrajnie różne organizacje z zespołami IT o różnych kompetencjach. Podskórnie czuję, że na końcu o efektywności IT decydują sami ludzie i ich umiejętności. Nie mniej warto zwrócić uwagę na kilka rzeczy. Różnice, o których wspomniałem, wiążą się np. z odpowiedzialnością za automatyzację czy digitalizację w organizacji i co za tym idzie za odpowiedzialność samego zespołu IT. Czy biznes wykonujący tą samą pracę od dłuższego czasu, jest sam w stanie zidentyfikować efektywną zmianę? A może lepiej zrobi to ktoś z zewnątrz? Kto ma dostęp i wiedzę o najnowszej technologii? Biznes czy IT? Te pytania można też przełożyć na współpracę z zewnętrznymi dostawcami. Tutaj też dochodzimy do pewnego stopnia dojrzałości technologicznej, gdzie albo z perspektyw merytorycznych albo finansowych zaczynamy korzystać ze wsparcia zewnętrznego. Świetnie, jeśli uda nam się znaleźć, jak wspomniałem wcześniej, jednego dostawcę software’u i hardware’u. Idealnie, jeśli ten dostawca będzie chciał i umiał dzielić się swoimi kompetencjami. Chcę także zwrócić uwagę na wzorce znane z ITIL-a czy COBIT-a. Jeśli uda się na bazie tych wzorców zorganizować pracę naszego zespołu IT, to współpraca z wewnętrznym klientem czy zewnętrznym dostawcą będzie ustrukturyzowana, a co za tym idzie łatwiejsza w zarządzaniu zmianą.

Waldemar Pietrzak:

Tutaj chciałbym zwrócić uwagę na dwa ważne aspekty: doświadczenie i świeże spojrzenie na problem automatyzacji. Świeże spojrzenie na dany problem lub wymagania stawiane przed automatyzacją oraz doświadczenie w realizacji takich projektów w wielu wypadkach pozwalają zaproponować optymalne rozwiązanie, uniknąć pułapek czy zwrócić uwagę na kluczowe aspekty i etapy w projekcie.

Paula Rutkowska: Konferencja, na której jesteśmy, dedykowana jest tematowi rozwiązań powerowych. Co właściwie ma power do automatyzacji?

Waldemar Pietrzak:

Współpraca hardware’u i software’u jest kluczowa. Tu ważna jest synergia. Dobrym przykładem wykorzystującym efekt synergii, jest firma Apple, która swoje produkty tworzy tak, aby oprogramowanie optymalnie współpracowało z platformą sprzętową (lub odwrotnie). W przypadku innych producentów, gdzie oprogramowanie musi działać na wielu platformach sprzętowych, osiągnięcie takiego efektu synergii jest mocno utrudnione. Innym przykładem takich urządzeń optymalizujących współpracę sprzętu i oprogramowania są np. urządzenia IBM Datapower Gateway Appliance i MQ Appliance oferowane przez IBM.

W przypadku naszych rozwiązań automatyzacji bazujących na rozwiązaniach firmy IBM, także staramy się wykorzystać efekt synergii na poziomie aplikacyjnym – tak, aby oprogramowanie optymalnie wykorzystywało możliwości udostępniane przez sprzęt. W naszych rozwiązaniach często proponujemy właśnie zastosowanie Power’a – dzięki mechanizmom wysokiej dostępności, wsparcia dla RedHat OpenShift i IBM Cloud Pak, możemy łatwiej dostarczyć rozwiązanie dla klienta i co więcej zastosowanie Powera pozwala nam osiągnąć wydajność większą o 20%-30% względem innych rozwiązań o podobnej skali na innej platformie.

Paula Rutkowska: Na koniec chyba najtrudniejsze pytanie – dlaczego IBM?

Krzysztof Marciniak:

Wypadałoby w tym miejscu mieć najdłuższą wypowiedź wypełnioną zdaniami na którymi pracowało wiele marketingowych głów. Spróbuję jednak konkretnie i przede wszystkim krótko. Gartner, Forester, marka premium, to ma znaczenie. Prowokacyjnie i chyba wbrew różnego typu tendencjom, powiem jeszcze tak: dlatego IBM, bo nie opensource. A co za tym idzie?  Gwarancja ścieżki rozwoju produktów, wsparcia rozwiązania, suportu itd. Dlaczego IBM? Bo to pewność i stabilność. Dodatkowo próg poznania technologii jest taki, że wykształcenie własnych kompetencji w zespole IT nie jest wyzwaniem. Z perspektywy operacyjnej – gotowość i otwartość na POC-a. No i oczywiście dobór i wskazanie merytorycznego partnera. Mogę tak wymieniać jeszcze długo.

Paula Rutkowska: Bardzo Wam dziękuję za dzisiejszą rozmowę. Tematy dziś poruszone to zaledwie wstęp do tego, ile można powiedzieć o automatyzacji, integracji i synergii pomiędzy softwarem i hardwerem. Mam nadzieję, że podczas kolejnych spotkań będziemy mogli ponownie wymienić nasze spostrzeżenia i podzielić się doświadczeniami.