Trimlogic ma zaszczyt poinformować, że w dniach 10-11 maja w Poznaniu, jako partner IBM, weźmie udział w tegorocznej konferencji IMPACT 2023.

Impact2023 to prestiżowe wydarzenie gospodarczo-technologiczne skierowane do przedsiębiorców, które daje okazję do prezentacji swoich projektów oraz zaprezentowania rozwiązań z wykorzystaniem technologii i innowacji w odpowiedzi na współczesne wyzwania cywilizacji i społeczeństwa. To także doskonała szansa na nawiązanie nowych kontaktów biznesowych oraz wymianę spostrzeżeń na temat trendów technologicznych. Projekt ten zakłada, że poprzez zastosowanie właściwych narzędzi i strategii, można przyczynić się do stworzenia lepszej przyszłości dla wszystkich.

W ramach Impact2023, zaangażowani są liderzy w dziedzinie technologii, biznesu, polityki i społeczności. Firma Trimlogic została partnerem strefy IBM, gdzie przy naszym stanowisku w przestrzeni Automation będziemy gotowi do dyskusji pod przewodnim tytułem „Ask me anything about Automation!”. Zapraszamy zainteresowanych tematyką automatyzacji, decydentów sektora komercyjnego jak i spółek z udziałem Skarbu Państwa do spotkania, dyskusji i wymiany doświadczeń.

Dla firmy Trimlogic zaproszenie do partnerstwa w projekcie Impact2023 to ogromne wyróżnienie. IMPACT 2023 to ważne wydarzenie, które pokazuje, jak ważne jest stosowanie innowacyjnych technologii dla rozwoju biznesu i przyszłości społeczeństwa. Zapraszamy do Poznania 10-11 maja, abyśmy mogli razem uczestniczyć w tym wyjątkowym wydarzeniu.

Beata Karczewska

Źródła: https://impactcee.com/ ,https://www.linkedin.com/company/impact_cee/

Najwyższa pora dodać od siebie parę słów o serwisie i jego zagadnieniach. Niewątpliwie wielkim osiągnieciem jakiego dopracowała się branża (nie tylko zresztą informatyczna) jest koncepcja SLA (Service Level Agreement). Oczywiście –umowy SLA to coś znacznie więcej niż serwis, to katalog usług a także wiedza o związanych z nimi procesach.

Tu jednak ograniczę się do bardzo wąskiego (ale jakże w praktyce ważnego) wycinka – czyli serwisu nastawionego na reagowanie na zgłoszenia błędów. Z reguły ustanawia się kilka kategorii błędów. Zależnie od fantazji twórców umowy mogą to być np.:

• Blokujący
• Krytyczny
• Istotny
• Zwykły
• Niski
• Propozycja rozwoju

Od klasyfikacji zależy czas podjęcia i czas rozwiązania zgłoszenia. Jakie są najczęściej występujące problemy?

Problem zbyt wielu kategorii zgłoszeń

Problem ten występuje wówczas, gdy kategorii zgłoszeń jest zbyt wiele. Powyżej przedstawiłem sześć przykładowych kategorii –to co najmniej o 1/3 za wiele.
System zgłaszania staje się skomplikowany i trudny do ogarnięcia przez okazjonalnego użytkownika.

Problem zbyt małej liczby kategorii zgłoszeń

Ta trudność jest w pewnym sensie odwrotna do poprzedniej; jest też znacznie bardziej brzemienna w skutki. Załóżmy, że mamy tylko 3 kategorie: błąd blokujący (uniemożliwia pracę z systemem, więc ma bardzo krótki czas rozwiązania), błąd średni (pozwala na rozwiązanie mniej-więcej w ciągu 2 dni roboczych) oraz „propozycja rozwoju”. Załóżmy teraz, że pojawia się problem o charakterze biznesowym, który jest dość ważny i wymaga sporych prac programistycznych, a do tego przed implementacją wymaga uwzględnienia wielu oddziaływań, wypowiedzenia się wielu osób i wypracowania rozwiązania, a przy tym wpływa na inne elementy systemu. W jakiej kategorii powinien być zgłoszony? Kategorie błędów objętych rygorystycznym czasem rozwiązania nie są najlepszym wyborem (ani dla dostawcy usług, ani dla Klienta). Dostawca pracuje pod „mieczem Damoklesa” w postaci terminu, więc będzie dążył do jak najszybszego (być może powierzchownego) rozwiązania zgłoszenia. W ten sposób dostawca usług będzie miał palący problem, a Klient otrzyma gorsze (za to szybkie) rozwiązanie. Pewnym rozwiązaniem byłoby zgłoszenie typu „propozycja rozwoju”–ale wielu użytkowników postrzega ten status jako związany z dodatkowymi kosztami „za rozwój”. Usługodawcy i usługobiorcy–we wspólnym interesie–zazwyczaj jakoś obchodzą ten problem, zakładając zgłoszenia o średnim priorytecie i „obezwładniając” mechanizm JIRY (czy innego rozwiązania śledzenia zleceń) przy pomocy funkcji „zawieszania”. Jest to jednak nie tylko sprzeczne z ideą SLA, ale wręcz idzie po jej prąd; obchodzimy mechanizmy które są jej bogactwem. Właściwym rozwiązaniem byłoby chyba zróżnicowanie statusów zgłoszeń nie objętych ścisłym terminem realizacji –na takie, które są swobodną propozycją do rozważenia przy kolejnej wersji systemu i na takie, w których toczy się praca nad wypracowaniem bieżących rozwiązań.

Problemy wynikające z korzystania z mechanizmu zgłoszeń

Łańcuchowanie zgłoszeń, Istotnym problemem jest –skądinąd naturalna –skłonność użytkowników do „łańcuchowania” zgłoszeń. Zjawisko polega na tym, iż po rozwiązaniu jednego –zgłoszonego pod rygorem czasowym –problemu, użytkownik zauważa inny, mniej lub bardziej związany z poprzednim i dopisuje go w komentarzach poprzedniego zgłoszenia (zamiast dokonać nowego zgłoszenia). Różnica jest fundamentalna –bowiem nowe zgłoszenie oznacza nową pulę czasu na rozwiązanie, zaś dopisanie nowego problemu do starego zgłoszenia powoduje, iż rozwiązanie może nastąpić tylko w czasie, jaki pozostał z całkowitego limitu po rozwiązaniu poprzedniego zgłoszenia. Jest to sprzeczne z ideą SLA, jednak tendencja jest zrozumiała (nawet bez złych intencji Zgłaszającego). Po prostu objęcie zagadnienia rozrzuconego po różnych zgłoszeniach jest dość trudne, stąd skłonność do komasowania problemów w jednym zgłoszeniu. Z drugiej strony, przy odpowiednio długim łańcuchu w tym samym zgłoszeniu (w cyklu problem – rozwiązanie – nowy problem – rozwiązanie – następny problem itd.) przekroczenie limitu SLA staje się nieuchronne. Rozwiązaniem byłaby możliwość klastrowania zgłoszeń (tak by można je było przechowywać i przeglądać niejako w „folderach tematycznych”), ale niewiele systemów wsparcia SLA zapewnia podobną funkcjonalność. Pozostaje zaapelowanie do dyscypliny zakładania zgłoszeń lub korzystanie ze statusów zgłoszenia nieposiadających limitu czasowego.

Zgłaszanie propozycji rozwoju lub modyfikacji jako błędów podlegających SLA

Ten problem ma charakter pozatechniczny –nie bardzo też wyobrażam sobie techniczne środki jego mitygacji. Rozróżnienie pomiędzy błędem a postulatem modyfikacji jest zagadnieniem „miękkim” i każdorazowo musi być rozwiązane na drodze negocjacji.

Dobra współpraca w zakresie SLA wymaga wysokiej kultury biznesowej –i, mimo pozornego sformalizowania, nie jest możliwa bez determinacji obu stron aby prowadzić ją na zasadzie „win-win”. Pewne kwestie można ulepszyć od strony technicznej (kilka z takich ulepszeń zaprezentowałem powyżej) jednak ciężar leży przede wszystkim po stronie dobrej woli obu zainteresowanych stron.

Marek Piotrowski

11 września miała miejsce V edycja Letnich Regat Przyjaciół, w których Trimlogic po raz pierwszy brał udział. Regaty Przyjaciół to idea, która ma za zadanie promować żeglarstwo oraz aktywny i zdrowy tryb życia. Coroczna impreza to również dobra okazja do integracji, poznania nowych ludzi ze świata IT i spędzenia czasu w ich towarzystwie. Wydarzenie trwało dwa dni, pierwszego dnia odbiór jachtów i ognisko zapoznawcze, a już następnego ranka regaty. Trasa była podzielona na trzy wyścigi, a zebrane punkty dały nam dziesiąte miejsce w rankingu.
W tym roku organizatorem regaty była firma Vetasi oraz Opsenio.

Dziękujemy za wspólnie spędzony czas i mamy nadzieję… do zobaczenia w przyszłym sezonie na Wielkich Jeziorach Mazurskich 2022!

Zachęcamy do zobaczenia galerii, więcej informacji o regatach na stronie: http://www.regatyprzyjaciol.org/

Beata Karczewska 

 Przez lata na jachcie Sztormana organizowane były rejsy po Morzu Bałtyckim oraz był on wykorzystywany do nauczania żeglarstwa w ośrodkach harcerskich. Po kilku latach postoju w puckich „krzakach”, armatorem Sztormana zostało Bractwo Morza – organizacja non profit zrzeszająca miłośników morza. Przed zakupem jacht spędził kilka sezonów stojąc na lądzie w puckim HOM-ie, w międzyczasie część jego wyposażenia spłonęła w pożarze magazynu (m.in. silnik i materace). Młodzież w ramach stypendium morskiego własnymi siłami wyremontowała jacht i doprowadziła do ponownego postawienia żagli oraz wyruszenia Sztormana w morze. Ponad 2 tysiące roboczogodzin, wyrzeczeń, zmęczenia i wysiłku, aby dać jachtowi nowe życie. Widząc tak duże zaangażowanie i pasję wśród młodych ludzi Trimlogic  nie pozostał obojętny i postanowił wesprzeć Bractwo Morza zostając jednym ze sponsorów projektu Sztorman.

  Sztorman to jacht turystyczno – regatowy zbudowany w 1973 roku w Stoczni Conrada w Gdańsku. Latem 2019 roku jacht został przestawiony z Pucka do Gdańska, gdzie miał się zacząć jego remont. We wrześniu, podczas inauguracji pierwszego naboru Stypendium Morskiego, Sztorman został wyciągnięty z wody i postawiony na nabrzeżu Przystani Cesarskiej. Sztorman wymagał gruntownego remontu zarówno kadłuba, pokładu jak i wnętrza. Zdemontowany został cały osprzęt, mahoniowe listwy odbojowe oraz drewniane elementy wnętrza. Następnie, usunięto starą farbę z części podwodnej kadłuba, pokładu oraz wnętrza. Wymienione zostały również okna. Do wakacji 2020 roku udało się pomalować wszystkie zaplanowane rejony. Tego samego sezonu udało się odwiedzić Gdynię i Jastarnię. Niestety przy planowaniu kolejnych rejsów konieczne było dokończenie remontu oraz zdobycie niezbędnego wyposażenia. Jednym z najważniejszych punktów była wymiana żagli, które ufundował Trimlogic.
W te wakacje Sztorman wraz z Bractwem Morza odwiedził porty: Hel, Kalmar, Oskarshamn, Nynashamn, Karingsund, Gavle, Kobba Klintar, Maarianhamina, Nykoping oraz Visby. Przepłynął łącznie 1315Mm w ciągu 375 godzin. Teraz, gdy jacht jest już sprawdzony, będzie on służył Stypendystom do organizowania pierwszych samodzielnych rejsów morskich. Aktualnie Sztormana spotkamy na przystani POLsail – nabrzeżu barkowym.

źródło: https://www.facebook.com/BractwoMorza/  https://www.youtube.com/channel/UCr89GYWOoL89WoX4HAGaU8A/featured

Beata Karczewska

Dziś porozmawiamy o tym, czym jest „sprawa” i z czego się składa. Omawiając case management  z perspektywy oprogramowania IBM Case Manager, pokażę całą hierarchię poziomów zarządzania dostępnych w tym produkcie.

Najwyższą instancją jest Rozwiązanie (solution). Obejmuje całą dziedzinę. W banku może zawierać wszystko, co związane jest z klientami (np. „Klient”) albo z produktami (np. „Pożyczka długoterminowa”), w przypadku zakładu opieki zdrowotnej – wszystko, co związane z opieką medyczną („Umowa  świadczenia obsługi zdrowotnej”), zaś w firmie turystycznej – dziedzinę świadczonych usług (np. „Organizacja wycieczek”). Wybierzmy ten ostatni przykład do prezentacji dalszych poziomów zarządzania sprawami. „Rozwiązanie” zawiera w sobie typy sprawy (case type). Dla rozwiązania „Organizacja wycieczek” mogą to być na przykład następujące typy: wycieczka szkolna. wycieczka zakładowa krajowa. wycieczka zakładowa zagraniczna oraz wycieczka objazdowa ogólnodostępna. Jak widać, podzieliłem rozwiązanie na typy według produktów oferowanych przez biuro. Każdy z tych rodzajów wycieczek organizuje się trochę inaczej, należy wykonać inne działania. Organizując konkretną wycieczkę, tworzymy sprawę (a „mądrze” mówiąc – instalację sprawy) jednego ze zdefiniowanych typów.

Weźmy w naszym przykładzie do dalszych rozróżnień typ sprawy p.t. „Wycieczka objazdowa ogólnodostępna”. Dla zorganizowania takiej wycieczki może być potrzebne wykonanie pewnej liczby działań, które tu nazywamy zadaniami (tasks). Zadania mogą być różnego typu, na przykład: zaplanowanie trasy. kalkulacja. załatwienie wiz dla pilota i kierowcy, sprzedaż. realizacja. rozliczenie wycieczek. Ponieważ w trakcie organizacji mogą zajść różne zdarzenia, uniemożliwiające przeprowadzenie imprezy (np. wycieczka się nie sprzeda, albo w kraju docelowym wybuchnie wojna) potrzebne jest nam też zadanie: zamknięcie sprawy bez realizacji wycieczki. Proszę zauważyć, że nie wszystkie zadania z tej listy będą wykonywane przy organizacji każdej wycieczki: na przykład jeśli będzie to kolejna wycieczka tą samą trasą, nie będziemy wykonywać zadania „zaplanowanie trasy” a być może także „kalkulacja”. Jeśli wycieczka będzie krajowa, zbędne stanie się załatwianie wiz – i tak dalej. Zadanie „zamknięcie sprawy bez realizacji wycieczki” w ogóle będzie potrzebne rzadko – tylko w wypadku fiaska przedsięwzięcia. Fakt nieobligatoryjności uruchomienia poszczególnych zadań czyni niepożądanym ułożenie ich w formie procesu – zwłaszcza że niektóre z nich będą zapewne przy różnych wycieczkach wykonywane w różnej kolejności (lub nawet równolegle). Jak widać, realizacja „sprawy” nie ma charakteru ani procesowego, ani liniowego. Nie ma jednej, uniwersalnej dla wszystkich spraw danego typu „ścieżki załatwiania”.  Brak jest przewidywalności: każda sprawa, mimo tego samego typu, może obejmować inny zestaw zadań – decyduje o nim kompetentny pracownik.

Najmniejszą jednostką case management jest krok (step). Każde zadanie składa się z (co najmniej jednego, ale najczęściej z kilku) kroków. Mogą to być niekiedy kroki wykonywane w nie zdefiniowanej kolejności, ale najczęściej są połączone w proces. Na przykład zadanie „zaplanowanie trasy” może składać się z następujących kroków

Reasumując: realizując przedsięwzięcie, wybieramy odpowiadające mu rozwiązanie, następnie tworzymy sprawę o określonym typie. Spośród dostępnych wybieramy konieczne do realizacji sprawy zadania  i realizujemy składające się na nie kroki.

Marek Piotrowski