Blog

Gdzie jest mój drugi dom? Praga!

Ostatnio zastanawiałem się, dokąd powinienem skierować kolejne kroki na mojej ścieżce automatyzacji. Polskę znam już dość dobrze, więc dlaczego nie wybrać się w podróż za granicę? Zawsze marzyłem, żeby zobaczyć kraj mojego pochodzenia. Czy wiecie skąd pochodzi słowo ROBOT? Z Czech! Słowo „robot” zostało po raz pierwszy użyte do nazwania fikcyjnego humanoida w sztuce R.U.R. autorstwa Karela Čapka. Ale dokąd iść najpierw? Gdzie ludzie najbardziej ceniliby moją pomoc? Powinno to być duże miasto z wieloma możliwościami. Myślę, że to jasne, to musi być Praga! Słyszałem wiele opowieści o Pradze; jest jedną z najbezpieczniejszych stolic na świecie, ma niesamowitą starą architekturę, z głównymi atrakcjami, takimi jak Zamek Praski, Most Karola czy Rynek Starego Miasta z praskim zegarem astronomicznym i można tam dostać najlepsze piwo w na świecie. Zadzwoń więc do mojego czeskiego kolegi Michaela, wypij z nim jedno piwo i porozmawiajcie, jak mogę pomóc ludziom w Czechach. Moje marzenie się spełniło! Od lipca działa XELTO DIGITAL CZECHIA!

czytaj więcej »

Odcinek 10. Co łączy ServiceNow i dress code?

Podczas rozmowy o platformie ServiceNow, Tomek zapytał mnie: „Edek, a dlaczego Ty właściwie nosisz garnitur? Czy ja Wam opowiadałem historię skąd wziął się ten mój nieszczęsny dress code? Bez którego, tak naprawdę, dzisiaj nie wyobrażam sobie „bycia sobą”. Cała przygoda rozpoczęła się od mojego Curriculum Vitae (o tym skąd wziął się na nie pomysł opowiem Wam innym razem). No bo skoro, postanowiłem mieć swoje CV, to musiało ono wyglądać bardzo profesjonalnie. W końcu CV to wizytówka świadcząca jakim człowiekiem, przepraszam, robotem jest przyszły kandydat na pracownika. A oprócz samego doświadczenia ważnym elementem CV, jeżeli nie najważniejszym, jest właśnie zdjęcie. Stąd też wyniknęła konieczność zakupu garnituru. Okiem Eksperta: Popularną platformą, stosowaną w coraz większej ilości firm, jest niewątpliwie ServiceNow. ServiceNow przeznaczone jest do zarządzania różnymi projektami, procesami, obsługi działów kadr, procesów HR, a także działów finansowych. Dzięki wdrożeniu tej platformy firmy zyskują możliwość ujednolicenia procesów oraz przyspieszenia ich realizacji. Dzięki ujednoliceniu procesów pojawia się miejsce na automatyzację zadań pojawiających się na platformie. Automatyzacja platform takich jak ServiceNow, może oczywiście odbywać się w standardowy sposób poprzez interfejs użytkownika. Jest to dość skuteczne, jednak nie jest to jedyny sposób w jaki możemy tworzyć boty. UiPath daje nam dwa rozwiązania do automatyzacji ServiceNow. Jednym z nich jest połączenie się z Service Now za pomocą konektora UiPath Orchestrator, czyli UiPath Spoke. Dzięki tej opcji  możemy kontrolować robota dzięki wykorzystaniu zadań w ServiceNow. Drugą opcją jest wykorzystanie paczki aktywności, która oferuje kilka aktywności pozwalających na pracę z ServcieNow z poziomu robota. Głównym jej elementem jest ServiceNow Scope w obrębie którego łączymy się z ServiceNow z wykorzystaniem API. Aby zrealizować połączenie niezbędne jest  podanie parametrów takich jak: clientID, clientSecret, hasło oraz link do platformy.  W obrębie aktywności  Service Now Scope możemy wykonywać operacje na zadaniach, pobierać załączniki, aktualizować statusy. Czasami zbiór tych aktywności może być jednak niewystarczający, dlatego polecam również sprawdzenie paczki aktywności stworznej przez Cristi Negulescu. Paczka zawiera aż 90 aktywności związanych z ServiceNow. Pomimo możliwości pracy z interfejsem, jestem gorącym zwolennikiem wykorzystywania wszystkich dostępnych środków pozwalających na pracę poza interfejsem użytkownika. Przyspiesza to w ogromnym stopniu pracę robotów, jak również gwarantuje wysoką stabilność rozwiązania. Dodatkowo nie narażamy się na możliwość błędów związanych z niepoprawnym odkliknięciem. Zastosowanie tej metody jest również dużym uproszczeniem pracy z załącznikami, gdzie w klasycznym podejściu musielibyśmy skorzystać z kilku kliknięć każdego obarczonego ryzykiem błędu. Korzystając z API pobierzemy je przy użyciu jednej aktywności. W ramach ciekawostki, Edwardowi udało się ustawić status realizacji zadania na wymyślony przez siebie. Użytkownik może wybrać tylko z dostępnych opcji, robot pozbawiony jest takich ograniczeń. Jednym problemem jaki można napotkać jest znajomość relacji pomiędzy tabelami. Przykładowo, załączniki mogą być rozrzucone pomiędzy dwiema tabelami, gdzie w jednej tabeli kluczem jest numer zadania, a w drugiej numer zadania nadrzędnego. Aby nie tracić dużej ilości czasu na szukanie relacji, warto podejrzeć strukturę obiektów w tabeli, którą chcemy odpytać. Taką możliwość oferują aktywności z paczki UiPathTeam.ServiceNow.Activities, pozwalają również na wykorzystanie zapytań SQL. Podsumowując ServiceNow dzięki współpracy z UiPath może pełnić rolę narzędzia do kontroli robotów, jak również pozwala na automatyzację wewnętrznych procesów istniejących na platformie. W przypadku, gdy ServiceNow jest pośrednim portalem, w którym rozpoczynamy lub kończymy dany proces, tym bardziej zaleca się wykorzystanie narzędzi działających w tle, aby skrócić maksymalnie działanie robota. Może się to bardzo opłacać zwłaszcza, gdy reszta procesu pracuje w systemie, który ma pewne ograniczenia przetwarzania lub jest zwyczajnie długi.  Uważam, że warto zapoznać się z każdą z opcji i wybrać odpowiednią tą, którą najkorzystniej wpłynie na daną automatyzację. Autor: Tomasz Sioła – RPA Developer

czytaj więcej »

Odcinek 9. Einstein i Edward – dywagacje o relacjach międzyludzkich

Miałem ostatnio dość nietypowy sen. Oczywiście, jako, że standardowo nie sypiam, bo pracuję 24 godziny, 7 dni w tygodniu, ale wykorzystałem chwilowe okienko czasowe, ponieważ u Klienta trwała akurat wymuszona przerwa techniczna głównego programu ERP i zdrzemnąłem się chwilę. Przyśniła mi się rozmowa ze wspaniałym człowiekiem, laureatem nagrody Nobla – Albertem Einsteinem. Początkowo jakoś dziwnie się czułem, gdyż w tym marzeniu sennym przeniosłem się do 50- lat XX wieku i na tle kawiarni, w której się spotkaliśmy wyglądałem jakbym był z kosmosu. Po przebudzeniu, zanim wróciłem do swojej pracy, szybciutko zadzwoniłem do Moniki i opowiedziałem jej o czym rozmawialiśmy z Albertem. Okiem Eksperta: „Boję się dnia, w którym technologia zakłóci interakcje międzyludzkie. Wtedy świat zyska pokolenie idiotów ” – Albert Einstein Nie wiem, czy to tzw. legenda miejska, czy rzeczywiście profesor tak się wypowiedział. Jeśli tak, to powiedział to nie później niż w latach 50-tych XX wieku. Od tego momentu dzielą nas technologicznie lata świetlne. Ale obawa wciąż jest aktualna. Czy technologia spowodowała powstanie pokoleń idiotów? Nie zaryzykowałabym takiej tezy. Czy wszechobecna technologia zakłóca interakcje międzyludzkie? Absolutnie tak. Być może dlatego, że żyjemy w epoce nowinek technologicznych tak częstych i tak intensywnych, nie mamy czasu na zdystansowanie się do nich. Jesteśmy w nich tak zanurzeni, że nie przychodzi nam do głowy refleksja – czy one wszystkie są nam w ogóle potrzebne? Kiedyś zadawaliśmy sobie pytanie czy można żyć bez telewizji. Dziś pytamy, czy moglibyśmy obejść się bez mediów społecznościowych. Oczywiście, że moglibyśmy, ale to wymaga od nas wysiłku i determinacji. A my stajemy się leniwi. No i mówimy tu o uzależnieniu. Nie jest to wciąż pokolenie idiotów, ale technologia, która miała być nam podległa, przejmuje kontrolę nad naszym czasem i role się odwracają. To my stajemy się jej poddanymi. Technologia automatyzacji procesów biznesowych też jest, na razie, nowinką. Co oznacza ona w uproszczeniu? Zrobić robota, który za ciebie wykona nudną, żmudną pracę, abyś ty miał więcej czasu na… No właśnie. Warto się zastanowić przez chwilę, na co ten dodatkowy czas? Na pogrążanie się, na przykład, w niewolnicze oddanie mediom społecznościowym czy na twórczy rozwój? Robot wykona za nas wiele zadań w naszej pracy, ale to od nas zależy jak wykorzystamy czas, który dla nas zaoszczędził. Czy spożytkujemy go na relacje z klientem, na rozwój własny, na lepszą organizację zadań, na kontakty ze współpracownikami. Czy go zmarnujemy. Dobra automatyzacja pomaga budować i rozwijać nowe relacje międzyludzkie w biznesie. Tą filozofią kierujemy się w naszym zespole XELTO DIGIAL . Ponieważ, dopóki istnieją więzi pomiędzy członkami zespołów, w grupie, w sterowaniu biznesem itp., dopóty technologia spełnia swoją pożyteczną rolę. Tam, gdzie technologia te relacje zastępuje, świat „zyskuje” pokolenie odludków, żeby nie powiedzieć mizantropów. Autor: Monika Stawicka – Business Analyst

czytaj więcej »

Odcinek 8. Edward w obłokach – NetSuite jako przykład automatyzacji cloudowych systemów ERP

Dziś chciałbym wraz z Przemkiem opowiedzieć Wam o automatyzacji systemów ERP innych niż JD Edwards czy SAP, bo opartych na rozwiązaniach chmurowych. Jednym z takich systemów jest NetSuite czyli prawdopodobnie najlepszy cloudowy system do zarządzania produkcją. Jako ciekawostkę powiem Wam, że artykuł na temat NS bardzo długo „dojrzewał”. I w sumie, kiedy już powstał, to sam nie wiem dlaczego, tyle czasu nad nim pracowaliśmy z Przemkiem. Przecież ten temat jest taki niesamowity. Okiem Eksperta: NetSuite od firmy Oracle jest kompletnym, w pełni skalowalnym rozwiązaniem, zaprojektowanym dla szybko rozwijających się przedsiębiorstw. Jest to jeden z produktów błyskawicznie zwiększających swoje udziały na rynku chmurowych systemów ERP. Rozwiązanie wykorzystuje chmurę do przechowywania danych, w związku z czym jego automatyzacja przebiega nieco inaczej. O różnicach opowiem na przykładzie zrealizowanego dla jednego z naszych klientów procesu: aktualizacja wersji zestawień materiałowych (BOM). Na wstępie dodam, że pojawiły się już dedykowane rozwiązania w UiPath pozwalające na automatyzację z poziomu backend`u, ale… nie u każdego są one możliwe do zrealizowania ze względów konfiguracyjnych bądź dostępowych. W naszym przypadku rozwiązanie nie umożliwiło zmian w całym NS, a jedynie w części aplikacji. W związku z tym zdecydowaliśmy się na klasyczną automatyzację interfejsu użytkownika. Pierwszą z różnic pomiędzy klasycznym ERP a NS jest brak bazy danych, co uniemożliwia wyciąganie potrzebnych informacji takich jak np. lista zadań (Work Order) czy komponenty w rewizji (BOM Revision) z poziomu SQL. Aby rozwiązać ten problem wykorzystaliśmy Web Scraping – bezpośredni odczyt danych z ekranu. Następnie przy mechanizmie przechodzenia do kolejnego Work Orderu (kolejnej „transakcji”) – w cloudowym ERP nie można wpisać np. numeru WO w aplikacji, tylko trzeba przejść do WO za pomocą unikalnego linku. To samo dotyczy innych zakładek/aplikacji. Wykorzystując pole Internal ID (domyślnie ukryte, ale opcjonalne pole w NS) oraz stałą część adresu udało nam się stworzyć mechanizm, który pozwala poruszać się po systemie NetSuite bez uciążliwego i długiego klikania po ekranie – czyli bezpośrednią nawigację. Jedną z ostatnich rozbieżności były selektory. O ile w klasycznych ERP dane pole posiada jeden stały selektor, to w NetSuite napotkaliśmy przypadki, w których pole miało dwa (a czasem nawet trzy) różne selektory, w zależności od tego czy było aktywne (kliknięte) czy nie. Dodatkowo, urokiem aplikacji webowej jest to, że czasem mimo iż jakiegoś wewnętrznego okna/przycisku nie widać na ekranie (wyłączony parametr visible/active na stronie) to de facto dla robota, który szuka selektora jest to widoczne. Finalny problem z jakim się spotkaliśmy związany był z jednoznacznym wybieraniem nazwy komponentu (produktu), jeśli na liście wartości dla pola znajdowało się kilka pozycji zaczynających się od tych samych znaków. Wynikało to stricte ze specyfiki NS i jego sposobu wyświetlania list. Pomimo początkowych trudności, udało nam się opracować mechanizm sprawdzenia, czy wybór jest niejednoznaczny i w takim przypadku wykorzystaliśmy poszerzone wyszukiwanie z możliwością ustawienia szukania konkretnego tekstu. Spytacie czy nie lepiej było go użyć od początku? Odpowiedź brzmi nie – to wyszukiwanie wymaga otwarcia nowego okna, zaznaczenia kilku pól i poczekania na wynik, co przekłada się na kilka (naście) sekund więcej dla procesowania pojedynczego komponentu (produktu). Wydaje się niedużo, aczkolwiek w kontekście całego procesu wydłużyłoby go znacząco. Podsumowując, automatyzacja systemów ERP opartych na chmurze ma swoje plusy i minusy. Na pewno w niektórych przypadkach będzie szybsza od automatyzowania tradycyjnych systemów ERP, aczkolwiek wymaga ona znalezienia odpowiednich rozwiązań. Autor: Przemysław Wal – RPA Developer Foto: iStock

czytaj więcej »

Odcinek 7. Edward ubiera się u Prady, czyli jego nowy Framework

W tym tygodniu chciałbym Wam się do czego przyznać. Kiedy zadzwoniłem do Rafała, żeby omówić zagadnienia dotyczące Framwork`a  zdałem sobie sprawę, że praca z całym zespołem XELTO DIGITAL to czysta przyjemność. Każdy w naszym zespole odpowiada za konkretne automatyzacje procesów, ale kiedy ktoś z Nas boryka się z zagadnieniem, którego nie może „rozgryźć” nie zostaje z tematem sam. Dzięki temu wsparciu, wspólnym rozmowom i „burzom mózgów” powstał właśnie wzór budowy robotów. Ale zanim o tym wszystkim z Rafałem  opowiemy, muszę w tym miejscu podziękować moim Koleżankom i Kolegom za tą współpracę. Okiem Eksperta: UiPath promuje tworzenie rozwiązań w oparciu o tak zwany 'Robotic Enterprise Framework’, który gwarantuje podstawową implementację najważniejszych koncepcji wspierających tworzenie automatyzacji. Razem z zespołem XELTO DIGITAL poszliśmy o krok dalej i stworzyliśmy rozbudowaną wersję frameworke’a, który stanowi podstawę budowanych przez nas robotów. Co nam to daje?  1.Standaryzacja Dla każdego klienta wszystkie procesy zbudowane są dokładnie w taki sam sposób. Pozwoliło nam to zaimplementować wiele wspólnych mechanizmów już na etapie projektowania wzorów. Otwierając nowy projekt programista nie musi się już martwić o logowanie, główną obsługę błędów czy też przygotowanie środowiska. Dla przykładu: wykorzystując procedurę TypeIntoElement programista jednym klockiem zaloguje czy element istnieje, wpisze do niego wartość wybraną przez siebie metodą, sprawdzi czy wprowadzona wartość jest poprawna i jeśli coś nie zadziała, to powtórzy to X razy. Ponadto, zarówno logi, jak i komunikaty błędów mają jednolity format i dostarczają nam kluczowych informacji. 2. Bezpieczeństwo Dzięki wbudowanym mechanizmom każdy z procesów potrafi dokonać podstawowego przygotowania maszyny do pracy, jak i pozostawić po sobie środowisko gotowe na kolejnego robota. Ponadto, co by się nie wydarzyło, robot jest w stanie z gracją zamknąć wszystkie otwarte aplikacje i pozostawić stację w takim samym stanie, w jakim ją zastał. Jeżeli robot pracuje na Windows serwerze to wie, żeby zamykać procesy jedynie dla konkretnej sesji użytkownika, pozwalając na bezpieczną pracę wielu robotów jednocześnie. 3.Przyspieszona produkcja Przygotowanie wzoru dla nowego projektu zajmuje ok. 30 minut. W tym czasie programista otrzymuje pakiet kompleksowych rozwiązań, których jednorazowe projektowanie, budowanie i testowanie zajmowałoby co najmniej kilka dni. Z kolei wykorzystanie reużywalnych komponentów pozwala na szybką budowę akcji procesowych. Piszę tu zarówno o uniwersalnych procedurach obecnych we framework’u, jak i tych przygotowanych pod konkretne aplikacje, które są dostępne w zbudowanych przez nas bibliotekach pomocniczych. Dla przykładu, wspomniany już TypeIntoElement oraz ClickElement będą działać na każdej aplikacji webowej, natomiast NavigateFastPathJDE jest procedurą zbudowaną stricte pod obsługę szybkiej ścieżki w JDE. 4.Lepsze SLA wsparcia technicznego  Standaryzacja procesu tworzenia robota pozwala na poprawę czasu diagnostyki w przypadku wystąpienia błędów w pracy procesu. Są tego dwa powody: po pierwsze, konkretne błędy mogą wystąpić jedynie w konkretnych miejscach. Jeśli nie działa połączenie ODBC to od razu wiemy, że problemu należy szukać w obszarze 'get transactions data’. Dzięki temu czas potrzebny na samo szukanie miejsca problemu zostaje znacząco skrócony. Po drugie, wprowadziliśmy jednolite kody błędów dla wszystkich robotów oraz podzieliliśmy je między te, za które odpowiedzialny jest biznes, jak i te, które występują po stronie używanych aplikacji. Gdy podczas monitoringu pracy robotów pojawi nam się komunikat, np. B0001, to od razu dla nas jest jasne, że nie udało się robotowi zalogować do aplikacji, ponieważ hasło wygasło. Podsumowując, wdrożenie własnego wzoru budowy robotów spowodowało, że nowe procesy budowane są szybciej, bezpieczniej i pozwalają łatwo wpasowywać je do już istniejącej infrastruktury robotycznej u dowolnego klienta. Autor: Rafał Korporowicz – Senior RPA Developer Foto: iStock

czytaj więcej »

A jeśli zastąpi mnie robot…?

W roku 1983 okładka magazynu Times przedstawiała robota wywożącego na taczce fabrykę i anonsowała artykuł pt.: The new economy. Dotyczył on prognoz na przyszłość w dobie recesji, bankructw w przemyśle ciężkim wieszcząc kurczenie się miejsc pracy dla tzw. blue collars. To czas rodzenia się przemysłu nowych technologii, tak egzotycznych jak mikroelektronika, laser, inżynieria genetyczna; powstają zupełnie nowe obszary rozwoju, jak w przypadku firmy Apple, która właśnie z firmy garażowej przekształca się w potężną korporację. Pojawiają się obawy związane z rozwojem automatyzacji i możliwością zastępowania robotami czy automatami całych sektorów zakładów pracy dotychczas opanowanych przez człowieka. Ale przecież obawy przed automatyzacją towarzyszyły człowiekowi już od momentu wprowadzenia pierwszych maszyn. Słyszeliśmy o niszczeniu maszyn w fabrykach w początkach XIX wieku; był to dobrze zorganizowany ruch tzw. luddystów protestujących przeciwko zmianom sposobu ich życia i zagrożeniom, jakie niósł wynalazek i zastosowanie maszyn tkackich. Nocne napady na tkalnie, niszczenie maszyn, czy zastraszanie ludzi nie cofnęło procesu uprzemysłowienia, podobnie jak zabranianie przez amerykańskie związki zawodowe, prawie wiek później, używania przez pracowników fabryk pneumatycznych rozpylaczy do farb. Ale pokazało wyraźnie, że lęk przed nowym był i będzie zawsze towarzyszył człowiekowi, niezależnie od epoki. Liczby mówią jednak, że mechanizacja produkcji spowodowała gwałtowny wzrost a nie spadek ilości miejsc pracy. Przykładowo, w USA w 1910 w przemyśle samochodowym pracowało 140 tysięcy osób, w 1920 z postępującą mechanizacją liczba miejsc pracy wzrosła do 250 tysięcy, a w 1930 pracowało tam już 380 tysięcy. Po opublikowaniu w 2013 roku przez Carla Freya i Michaela Osborna artykułu „The Future of Employment: How susceptible are jobs to computerisation?”, powstała nawet aplikacja: WILL ROBOTS TAKE MY JOB? funkcjonująca do dziś i podpowiadająca jakie jest prawdopodobieństwo, że Twoje stanowisko zostanie zastąpione przez roboty. Jesteś analitykiem systemów komputerowych? – dziś występuje bardzo małe prawdopodobieństwo zastąpienia Twojego stanowiska robotem i wynosi 0,7%. W tym samym momencie stanowisko zaopatrzeniowca, w sensie zadań pracownika działów zaopatrzenia dużych firm jest już zagrożone w 98%, przy czym w ciągu najbliższych 2 dekad zagrożenie wzrośnie o kolejne 59%. Ale i ryzyko zastępowalności analityka wzrośnie o 32% w ciągu 20 najbliższych lat. Artykuł przewidywał, że niskie ryzyko komputeryzacji stanowiska pracy dotyczy tylko co trzeciego pracownika i to głównie osób zatrudnionych w edukacji, ochronie zdrowia, artystów, menadżerów różnego szczebla oraz oczywiście specjalistów do spraw IT. Czy jednak za klika lat ta perspektywa będzie wyglądać tak samo? Jak wspominaliśmy, strach przed automatyzacją nie jest czymś nowym. Dziś, w wyniku automatyzacji pewne grupy pracowników tracą pracę, ale jednocześnie powstają nowe miejsca pracy (często lepiej płatne niż te utracone) i zwykle poza trudnym okresem przejściowym sytuacja się poprawia. Weźmy uczenie maszynowe i robotykę, które znajduje sposób na lepsze, szybsze, tańsze sposoby wykonywania tych samych czynności, do których przez dekady zatrudniano ludzi o określonych kompetencjach. W sytuacji tego swoistego zastępstwa, pracowników przenosi się do innych ról. I ponownie, podobnie jak w przypadku rewolucji przemysłowej, jest mało prawdopodobne, aby okres przejściowy był bezbolesny. Ludzie będą potrzebowali czasu na przekwalifikowanie, menadżerowie na wymyślenie na nowo ról dla uwolnionej siły roboczej. I mają na to znacznie mniej czasu, niż wiek temu. Zmiany następują szybciej niż poprzednio i mają znacznie szerszy zasięg. Na zakończenie wróćmy do artykułu z tygodnika Time; został w nim przytoczony cytat pochodzący z roku 1950. Jest to opinia Johna Diebold’a, konsulanta zarządczego z Nowego Jorku, który twierdził, że w różnych momentach, zwykle w głębokiej recesji, ludzie mówili, że odtąd będzie okropnie z powodu automatyzacji. Ale kilka lat później wszystko zostało zapomniane. Niektóre rodzaje pracy zanikają, a inne powstają. To znak zdrowej gospodarki. Nic dodać, nic ująć, mimo 71 lat… Źródło: Will Robots Take My Job, Starch przed automatyzacją, https://pl.wikipedia.org/wiki/Luddyzm, (TIME) The new economy Autor: Monika Stawicka – Business Analyst

czytaj więcej »

Odcinek 6. Biała Lista. Czy można ją zweryfikować inaczej?

Pamiętam, jak wszyscy przedsiębiorcy zaczynali przygodę z Białą Listą. Oczywiście zaczęło się od wielkiego chaosu. Czasem zastanawiam się czy każda zmiana musi się od tego zaczynać. Ale w gruncie rzeczy zmiany są dobre. Ja przynajmniej bardzo lubię, gdy ciągle coś się dzieje. Wracając do Białej Listy, to każdy się obawiał, denerwował jak to z tym wszystkim będzie. A okazało się, że nie taki diabeł straszny jak go malują. W sumie Bond nie posługiwał się tym powiedzeniem, ale jestem pewny, że miał je we krwi. Siedząc z Przemkiem i popijając kawę usłyszałem co nieco na temat Białej Listy: Okiem eksperta: Od 2019 roku w Polsce istnieje obowiązek weryfikacji kontrahentów na tzw. Białej Liście. Jest to rządowy wykaz (wyszukiwarka) wszystkich firm wraz ze wskazaniem jaki jest ich status jako płatnika podatku VAT. Na rynku istnieją rozwiązania pozwalające na masowe odpytywanie bazy Białej Listy za pomocą API, aczkolwiek są to rozwiązania dedykowane i „szyte” pod konkretnego klienta i system ERP. Mają one też pewne ograniczenia wynikające bezpośrednio z zasad ustawy, odnośnie maksymalnej ilości dziennych zapytań jaka może być wykonana, jak również maksymalnej ilości przetworzonych danych (maksymalnie 300 rekordów). Jako XELTO DIGITAL, opracowaliśmy inny sposób weryfikacji Białej Listy oparty na zautomatyzowaniu wyszukiwania na stronie internetowej, bez wykorzystywania API. Użytkownik podaje listę numerów NIP i/lub numerów rachunków bankowych kontrahentów. Następnie robot na stronie wyszukiwarki podatników VAT sprawdza po kolei każdy z numerów oraz zbiera ze strony niezbędne informacje, takie jak: status podatnika, walidację czy numer(y) konta znajduje się na liście rachunków zweryfikowanych, datę wyszukiwania i unikalne ID. W kolejnym kroku zapisuje te dane w pliku wynikowym, który może zostać umieszczony w dowolnej lokalizacji bądź przesłany mailowo do osoby zlecającej. Zaletą tego rozwiązania, w przeciwieństwie do istniejących już rozwiązań, jest jego duża swoboda w konfiguracji dla Klienta, umożliwiająca mu dopasowanie do konkretnych wymagań. Dużym plusem jest też ominięcie limitów, które istnieją w przypadku zapytań przez API, ponieważ w tym rozwiązaniu symulujemy pracę człowieka, „ręcznie” otwieramy stronę i wyszukujemy płatników. W przypadku, gdy automatyzuje się proces z wykorzystaniem interfejsu użytkownika to jest on wolniejszy niż wysłanie zapytań przez API. Jednocześnie jest to wciąż wielokrotnie szybciej niż zrobiłby to człowiek, dzięki czemu można ominąć limit ilości wyszukiwań. Technicznie rzecz ujmując  development procesu wymaga zwrócenia uwagi na selektory od przycisków wyszukiwania – po pierwszym wyszukaniu przycisk przenosi się w inne miejsce na ekranie i pomimo tego, że wygląda dokładnie tak samo, to w kolejnych zapytaniach jego selektor jest już inny. W przypadku, gdy w pliku wejściowym znajdują się zarówno numery NIP, jak i kont, należy rozdzielić tę listę w kodzie robota. Robot sprawdza najpierw rachunki bankowe, a dopiero później numery NIP, unikając w ten sposób zbędnego przechodzenia między ekranami do wyszukiwania. Autor: Przemysław Wal – RPA Developer

czytaj więcej »

Odcinek 5. Standaryzacja kontra automatyzacja.

Standaryzacja czy automatyzacja – oto jest pytanie. Nie tylko wielcy klasycy pokroju Shakespeare`a zadawali sobie i światu ważne pytania. Czasem lubię posiedzieć na naszym firmowym balkonie i rozmyślać o różnych aspektach automatyzacji i nie tylko. Jak się okazuje nasz balkonik jest uwielbiany przez wszystkich pracowników XELTO DIGTIAL. Obserwując zachód słońca rozpoczęliśmy z Moniką dość ciekawą polemikę: Okiem Eksperta: Każdy biznes podlega stałym zmianom. Zmienia się sposób funkcjonowania firmy w sytuacji, gdy rosną koszty pracy, gdy wymagania klientów są coraz większe, gdy przychodzi lęk o skuteczność dotychczasowych rozwiązań, gdy rywalizujemy z konkurencją. Zdając sobie sprawę, że zmiany są kosztowne, szukamy tych obszarów, w których proces zmian pozwoli osiągnąć cel najszybciej, przy poniesieniu jak najniższych kosztów. Od czego zatem zacząć? Na pewno od nazwania miejsc, które spowalniają procesy, elementów, które generują najwięcej błędów, konsumują duże ilości czasu przynosząc mierne efekty w skali całej firmy. W każdym biznesie znajdą się procesy, które są przestarzałe, angażują starą technologię i opierają się w dużej mierze na, niestety, omylności człowieka. Szczególnie widoczne jest to w dużych firmach, które mają wiele rozgałęzień i gdzie proces zdefiniowany w określonym miejscu i czasie (i zresztą sprawdzający się doskonale przez długi czas) zaczyna w końcu szwankować. Powoli staje się niespójny lub jest prowadzony inaczej w zależności od warunków, w których się go uruchamia. Warunki działania często odgrywają rolę w niezamierzonych modyfikacjach procesu i powodują, że jego pierwotna definicja zanika pod warstwami interpretacji i wyjątków. (Do tych warunków można zaliczyć jednostki biznesowe rozmieszczone w różnych krajach, o różnej kulturze pracy, czy różnych obyczajach). Rada? Pierwszą i do pewnego czasu jedyną receptą było przyjrzenie się każdemu zdarzeniu w ten sam sposób za każdym razem, gdy ono występuje lub gdy dzieje się określony rodzaj pracy i próba standaryzacji. Standaryzacja oznaczała ujednolicenie wszystkich znanych kroków, aż do uzyskania spójnych procesów. Nie trzeba tu dodawać, że sama operacja rozpoznania i oszacowania różnorodnych zadań i zdarzeń była i jest zawsze czasochłonna, i ciągnie za sobą wymierne koszty. Jeśli teraz dodamy do tego czas potrzebny na kolejny wysiłek, czyli automatyzację, to moment uzyskania oczekiwanych zmian odsuwa się w czasie. Należy zatem postawić sobie pytanie: co jest rzeczywistym celem tej operacji? Czy chcemy mieć ustandaryzowane procesy (gotowe do automatyzacji), jednolicie działające we wszystkich obszarach firmy? Czy chodzi nam o oszczędności kosztów pracy i o uwolnienie potencjału drzemiącego w ludziach. Jeśli bowiem myślimy o samej standaryzacji, możemy zapomnieć o oszczędności. Zamiast więc na kompleksową standaryzację poprzedzającą automatyzację postawmy na standaryzację POPRZEZ automatyzację. Wybór i rozpoznanie procesów, które wymagają zmian jest warunkiem koniecznym, co do tego nie ma wątpliwości. Zastąpmy czas, który poświęcilibyśmy na, mówiąc kolokwialnie, wyprostowanie kulawych procesów, wysiłkiem włożonym w analizę miejsc, gdzie najlepszym rozwiązaniem będzie automatyzacja procesu. Najważniejszym celem automatyzacji powinna zawsze pozostawać chęć odciążenia Twoich pracowników, uwolnienia ich od zadań żmudnych i monotonnych i wreszcie umożliwienie im rozwoju. Ciekawe spostrzeżenie: standaryzacja z perspektywy pracowników niewiele zmienia, w przeciwieństwie do automatyzacji. Biorąc pod uwagę oczekiwania, jakie mają wobec obu procesów, pracownicy są zdecydowanie żywiej zainteresowani wprowadzeniem automatyzacji, gdyż na jej końcu pojawia się możliwość zdania żmudnych zadań robotowi. Pozbycie się czynności powtarzalnych i frustrujących powoduje, że zwyczajnie wraca ich zaangażowanie, często dawno już utracone. Podsumowując, nie rezygnując ze standaryzacji można ją tak modelować, aby była elementem automatyzacji, nie celem samym w sobie. I co równie ważne, jeśli nie ważniejsze, należy koncentrować uwagę na potencjale pracowników. Z obserwacji wynika, że potencjał pracownika wzrasta proporcjonalnie do przekazywania zadań robotom. Autor: Monika Stawicka – Business Analyst Źródło: Should You Automate Your Processes „As-Is” or Standardize First?

czytaj więcej »