Cykl życia systemu ERP

Systemy Klasy ERP Rok Akademicki 2005/2006Ryzyko• Współczynnik o znaczącym wpływie napowodzenie całego wdrożenia• Sukces wdrożenia mierzony jest takimiwspółczynnikami jak:–całkowita akceptacja ze strony użytkowników– zwrot z inwestycji–czas wdrożenia– inneZłożoność• oznacza stopień trudnościwdrożenia i pielęgnacjioprogramowania• różnice pod względemzłożoności systemu pomiędzyfirmami o różnychrozmiarach i różnychprofilach działalnościPolitechnika Poznańska - Instytut Informatyki 4/39

Systemy Klasy ERP Rok Akademicki 2005/2006Korzyści• określają stopień w jakim korzystanie przezpracowników firmy z funkcjonalności systemumoże poprawić sytuację firmy i przynieść jejwymierny zysk• jeśli firma używa systemu ERP wyłącznie jakobazy danych to korzyści są na ogół znikome• jeśli firma korzysta z wielu funkcjonalnościsystemu (np. do obliczania długości cyklu dlazapasów) na ogół osiąga większe korzyści(poprawa obsługi klienta, większe zyski)Wzajemne zależności między celamiKorzyściZasobyRyzykoZłożonośćSzybkośćZakresKorzyści+ººº+Zasobyº+º+Ryzyko+++Złożoność–+Szybkość–Zakres+ dodatnia korelacja – ujemna korelacja º neutralna korelacjaPolitechnika Poznańska - Instytut Informatyki 5/39

Systemy Klasy ERP Rok Akademicki 2005/2006Reprezentacja zależności nawykresie radarowymryzykokorzyścizłożonośćwysokiniskizasobyzakresszybkośćStrategie wdrażania systemów ERP• „na złamanie karku” (breakneck)• gwiazda (star)• pod klucz (turnkey)• własne (in-house)• budżetowe (budget)• partnerskie (partner)• niskiego ryzyka (low risk)Politechnika Poznańska - Instytut Informatyki 6/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategie wdrożeń systemów ERPszybkośćzasobykorzyściryzykozłożonośćzakresna złamaniekarkuPR1032882282755gwiazdaPR68101068645557pod kluczPR6271082295547własnePR573883265666budżetowePR4112622103333partnerskiePR746887467768niskiegoryzykaPR3291088122323P –postrzegana R – rzeczywista 10 – najwyższa 0 - najniższaWykres radarowy dla strategii„na złamanie karku”ryzykokorzyścizłożonośćPwysokiniskiRzasobyzakresszybkośćPolitechnika Poznańska - Instytut Informatyki 7/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia „pod klucz”• firma kupująca system zupełnie nie angażuje się we wdrożenie• wszystkie czynności związane z systemem są wykonywaneprzez dostawców i integratorów systemów• model o najbardziej ograniczonej komunikacji między firmą adostawcą usług ERP• ograniczona komunikacja między firmą a wdrożeniowcamiprowadzi do powstania produktu skonfigurowanego, leczniezgodnego z wymaganiami biznesowymi firmy• wiele firm myśli o tej metodologii jako o podejściu niskiegoryzyka, czując, że powierzają projekt profesjonalistom, którzywiedzą co robić• brak jakiegokolwiek poczucia własności, sprawia, że projektstaje się projektem wysokiego ryzyka, o niskimprawdopodobieństwie sukcesu• skutki:– liczne konflikty między firmą a dostawcą usług ERP ze względu naniezgodność systemu z wymaganiami– osiągnięte korzyści dużo niższe od spodziewanychStrategia wdrożenia własnego• metodologia polegająca na użyciu własnych zasobów, dowypełnienia wymogów sytemu ERP w takim stopniu w jakimjest to możliwe• wynika z potrzeby oszczędności finansów i zbudowaniawewnętrznej własności systemu• może być kłopotliwe w początkowej fazie wdrożenia• nieznajomość oprogramowania oraz konieczność poznaniadodatkowej wiedzy zwiększa czasochłonności i kosztywdrożenia• całkowita rezygnacja z oszczędności czasu jaka może wynikać zzewnętrznej ekspertyzy (firmy konsultingowe, dostawcy usług)• firma może mieć wyraźne problemy z osiągnięciem wszystkichkorzyści z systemu• ryzyko jest na ogół znacznie wyższe niż spodziewane zewzględu na trudności we wdrażaniu bez zewnętrznejekspertyzyPolitechnika Poznańska - Instytut Informatyki 9/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia wdrożenia budżetowego• podejście całkowicie skupione na zarządzaniu kosztami• cel wyeliminować z wdrożenia tak dużo kosztów jak tylko możliwe• cel osiągany przez rezygnację z pomocy konsultantów i zawężeniezakresu wdrożenia a w konsekwencji zmniejszenie korzyści• może się ciągnąć w nieskończoność (kadra kierownicza może nie wyrażaćchęci do finansowania dalszych wydatków na kontynuację projektu)• brak wsparcia ze strony kierownictwa negatywnie odbija się na reszcieorganizacji• kierownictwo postrzegane przez pracowników, jako osoby nie mająceinteresu w zakończeniu projektu• bez zaangażowania ze strony kierownictwa niższego szczeblaużytkownicy przestają wierzyć w powodzenie wdrożenia i z czasem corazmniej się w nie angażują• ostateczne koszty zbliżone do planowanych (głównie z niechęciwydawania pieniędzy na ten cel)• projekt bardzo wysokiego ryzyka z reguły kończący się niepowodzeniem• prawdopodobieństwo sukcesu niewielkie ze względu na brak wsparcia zestrony kierownictwa i brak wystarczających zasobów finansowychStrategia wdrożenia partnerskiego• wdrożenie przy użyciu zarówno zasobów własnych jak i obcych• podejście dość popularne (wiele firm zwraca się do firmkonsultingowych lub dostawców usług ERP o wsparcie wdrożenia)• na ogół czas i finanse poświęcone na wdrożenie znacznieprzewyższają pierwotnie planowane• odpowiedzialność za powodzenie wdrożenia i użytkowania systemupodzielona pomiędzy firmę i źródła zewnętrzne• w odróżnieniu od strategii gwiazdy, w której ilość zaangażowanychzasobów zewnętrznych jest podobna, odpowiedzialność zawdrożenie leży po obu stronach (również po stronie partnera)• rozproszona odpowiedzialność , może być przyczyną konfliktówpomiędzy firmą a dostawcą usług, szczególnie w momencieprojektowania ważniejszych cech systemu; konflikt taki możenegatywnie odbić się na energii pracowników zaangażowanej wewdrożenie zwiększając w efekcie ryzyko i prawdopodobieństwoniepowodzeniaPolitechnika Poznańska - Instytut Informatyki 10/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia niskiego ryzyka (1)• podejście łączące wysoki poziom użytych zasobów, z małązłożonością i niewielkim zakresem wdrożenia, z rozsądnierozłożonymi „kamieniami milowymi”, aby otrzymaćprojekt o wysokim prawdopodobieństwie powodzenia• strategia o największej liczbie zdarzeń zarównosekwencyjnych jak i równoległych połączonych wzajemnielogiką warunkową „if ... then”• logika if...then używana do weryfikacji osiągnięciaposzczególnych kamieni milowych, jeżeli któryś zkrytycznych kamieni milowych nie zostanie osiągniętyprojekt jest albo wstrzymywany albo powtarzane są jegoostatnie kroki sprzed osiągnięcia ostatniego kamieniamilowegoStrategia niskiego ryzyka (2)• projekt może być wstrzymany jeśli dostawca systemu ERPnie przedstawi odpowiednich referencji dotyczącychwdrożenia i wykorzystania oferowanego oprogramowania(w innych strategiach projekt jest kontynuowany bezweryfikacji referencji)• podejście pod wieloma względami podobne do strategiigwiazdy, przy czym podstawowa różnica dotyczy szybkościwdrożenia• przy bardzo małym zakresie i bardzo niskiej złożonościprzy jednoczesnym dużym zaangażowaniu dedykowanychzasobów, ryzyko jest eliminowane przez dokładną analizę istaranne badania prowadzone przez firmę• każdy bez wyjątku krok wdrożenia przeprowadzany jest wstaranny i metodyczny sposób• jest to najbardziej skomplikowany sposób wdrażaniasystemu ERP ze względu na największą liczbę zdarzeńPolitechnika Poznańska - Instytut Informatyki 11/39

Systemy Klasy ERP Rok Akademicki 2005/2006Cele, strategie i zdarzenia• różne cele–różne strategie–różne kombinacje zdarzeń• zamieszanie i nieporozumienia• jakie powinna być zawartość i struktura zdarzeńdla poszczególnych kombinacji celów?• jakie są zależności między celami?„ Zrozumienie wzajemnych relacji i zależności pomiędzyposzczególnymi celami i zdarzeniami jest kluczem doudanego zrozumienia cyklu życia systemu ERP.”Zdarzenia• Zdarzenia– wszystkie charakterystyczne elementy wchodzące wskład projektu• Projekt– wszystkie zdarzenia zachodzące pomiędzy faząkoncepcji a fazą zamknięcia projektu• Prawie wszystkie zdarzenia we wdrożeniu ERPwymagają zaangażowania ludziPolitechnika Poznańska - Instytut Informatyki 12/39

Systemy Klasy ERP Rok Akademicki 2005/2006Przykłady zdarzeń• szkolenia wprowadzające• formowanie zespołów projektowych• analiza wymagań• sesja planowania integracji biznesowej• określenie wizji i misji• szkolenia dla zespołu projektowego• zapytania informacyjne• analiza zwrotu z inwestycji• zapytania ofertowe• przegląd referencji• wymiarowanie sprzętu• przegląd dostawców ERP• przykładowe scenariusze• prezentacje oprogramowania• sesje wczesnego planowania• proces wyboru ostatecznego dostawcy• negocjowanie kontraktu• instalacja oprogramowania• sesja planowania projektu• szczegółowy plan projektu• wyznaczenie sztabu wdrożeniowego• szkolenia ERP• pytania konfiguracyjne• opracowanie polityki wdrożenia• dopasowanie raportów• odwzorowanie funkcjonalne• testowanie i opracowanie prototypu• modyfikacje oprogramowania• konwersja bazy danych• planowanie reakcji na nieprzewidzianeproblemy• dokumentacja• szkolenia dla użytkownikówkońcowych• audyty• pomiary wydajności• start produktywny• wsparcie powdrożeniowe• bieżące szkolenia i pielęgnacjasystemuSzkolenia wprowadzające (1)• proces szkoleniowy poprzedzający pozostałeczynności i zdarzenia projektu ERP• dotyczy kadry kierowniczej wyższego szczebla,ale powinno dotyczyć również innychkrytycznych stanowisk• cel: przekazanie wiedzy na dwa tematy:– podstawowa wiedza na temat ERP– wiedza na temat czynnikówtechnologicznychPolitechnika Poznańska - Instytut Informatyki 13/39

Systemy Klasy ERP Rok Akademicki 2005/2006Szkolenia wprowadzające (2)• Podstawowa wiedza na temat ERP– wspólna dla wszystkich systemów ERP i niezależna odoprogramowania– wiedza ta ułatwia zrozumienie: zasad działania systemów ERP,sposobów wdrażania, podejmowanego ryzyka oraz poznanieelementów niezbędnych do tego, aby z powodzeniem wdrożyć iużytkować system ERP• Czynniki technologiczne– wszystkie charakterystyki i elementy, które mogą mieć wpływ nasystem ERP w środowisku biznesowym, w którym jest onwdrażany– ze względu na dużą zmienność technologii komputerowychwszyscy animatorzy projektu ERP muszą być świadomimożliwości i ograniczeń współczesnych systemów ERP– świadomość tego czego można się spodziewać po systemachklasy ERP pomaga formułować odpowiednie pytania na dalszychetapach wdrożeniaFormowanie zespołów projektowych• powinno odbywać się jak najwcześniej po szkoleniachwprowadzających• skład i struktura zespołu powinny być ustalone na podstawie potrzeborganizacyjnych i tego czego przedstawiciele firmy nauczyli się naszkoleniach wprowadzających• ważne jest, aby sformować zespół projektowy niemal na samympoczątku wdrożenia, aby jego członkowie brali udział wopracowywaniu strategii wdrożenia• zespół projektowy nie musi być tym samym zespołem co zespółwdrożeniowy• zespół projektowy powinien składać się z tych osób, które będą miałyistotny wpływ na ostateczny kształt systemu ERP• liczba członków zespołu projektowego zależy od firmy oraz od sytuacji• zespół projektowy powinien być na tyle liczny aby zapewnićpowodzenie projektuPolitechnika Poznańska - Instytut Informatyki 14/39

Systemy Klasy ERP Rok Akademicki 2005/2006Analiza wymagań• proces, który ma określić wymagania firmy w stosunku dosystemu ERP• ogólny szkic odzwierciedlający wszystkie głównecharakterystyki funkcjonalne potrzebne do wsparciadługoterminowych potrzeb biznesowych przedsiębiorstwa• nie powinna być przeprowadzana bez starannegoprzebadania przyszłych kierunków biznesowych ipotencjału rozwojowego firmy• ważne aby analizę wymagań przeprowadzić poodpowiednim szkoleniu wprowadzającym• projekt ERP niczym misja sondy VoyagerSesja planowania integracji biznesowej• łączenie informacji wynikających z analizywymagań z obecnymi i przyszłymiwłaściwościami operacyjnymi potrzebnymido wspomagania strategii biznesowychfirmy• zespół projektowy ERP decyduje co i jak(w sensie ogólnym) powinien robić systemERPPolitechnika Poznańska - Instytut Informatyki 15/39

Systemy Klasy ERP Rok Akademicki 2005/2006Określenie wizji i misji• stanowi podstawę i źródło do zmian zarządzania i organizacjiwynikających z wdrożenia systemu ERP• określenie wizji jest procesem określającym przewidywania firmyodnośnie współpracy systemu ERP z funkcjami biznesowymi firmy• przykład wizji:„Zaoferować najlepszą na rynku obsługę klienta przez efektywnewdrożenie i używanie systemu ERP w połączeniu z efektywnymzarządzaniem operacyjnym”• misje określane są precyzyjniej niż wizje i są powiązane z datamiważności, które określają nieprzekraczalne terminy zakończeniarealizacji poszczególnych misji• określenie misji bezpośrednio pomaga określić wizje• przykład misji:„Wdrożyć w pełni zintegrowany system ERP pokrywający wszystkieaspekty funkcjonalne biznesu do końca przyszłego roku”• określenie wizji i misji odbywa się na podstawie danychotrzymanych z analizy wymagań i sesji planowania integracjibiznesowejSzkolenia dla zespołu projektowego• szkolenia dla członków zespołu projektowego ERP w zakresiepodstawowych pojęć ERP• podobne do szkoleń wprowadzających, ale bardziejrozwinięte• szczegółowe omówienie krytycznych czynników mającychwpływ na powodzenie wdrożenia ERP• przedstawienie całego cyklu życia systemu ERP• tematy takie, jak:– współpraca z dostawcami ERP podczas przeglądu ofert– cel przeglądu referencji– rola dokumentacji– konwersje danych– tworzenie szczegółowego planu projektu– innePolitechnika Poznańska - Instytut Informatyki 16/39

Systemy Klasy ERP Rok Akademicki 2005/2006Zapytania informacyjne• dokument wysokiego poziomu w formie kwestionariusza zawierającyogólne pytania dotyczące dostawcy ERP, dostawcy usług, produktów iogólnych możliwości systemu kierowany do dostawców systemówERP• przykłady pytań:– jakie moduły funkcjonalne są oferowane?– ile kosztuje produkt podstawowy?– czy występują dodatkowe licencje użytkownika?– jaki jest udział dostawcy w rynku?• zapytania informacyjne połączone z ogólnymi badaniami rynkowymipozwalają:– określić początkowy zakres kosztów jakie będzie musiała ponieść firma– stworzyć początkową tzw. „długą listę” dostawców ERP, spośród którychzostanie wybrany ostateczny dostawca• zapytanie informacyjne można przesłać do dostawcy ERP w formieelektronicznej lub papierowej albo wypełniać na bieżąco podczaskontaktu osobistego lub telefonicznegoZwrot z inwestycji• technika używana do obliczenia zwrotu z inwestycjiobliczanego, jako zyski otrzymane z pewnych środków wstosunku do pieniędzy w nie zainwestowanych• używane jako uzasadnienie dla nowego systemu ERP, a takżejako miara tego, jak dobrze został wdrożony system ERP, lubprzy wdrożeniu nowej lub dodatkowej funkcjonalności• może stanowić finansowe uzasadnienie do przeprowadzeniatak kosztownej inwestycji jak wdrożenie ERP• uzasadnienie jakościowe pochodzące z sesji planowaniaintegracji biznesowej i zapytań informacyjnych jestprzekładane na informację ilościową spełniającą wymaganiaplanistów finansowych• istnieje jednak sporo sytuacji, w których mimo niekorzystnychanaliz zwrotu z inwestycji konieczna jest inwestycja w systemERP (np. problem roku 2000)Politechnika Poznańska - Instytut Informatyki 17/39

Systemy Klasy ERP Rok Akademicki 2005/2006Zapytanie ofertowe• seria pytań zadanych dostawcom ERP• pytania powinny być tak sformułowane, aby sprawdzić,czy system ERP rzeczywiście zawiera wszystkie niezbędnedla przedsiębiorstwa funkcjonalności biznesowe• po otrzymaniu odpowiedzi można zawęzić listępotencjalnych dostawców ERP i przejść do indywidualnychkontaktów z nimi• zapytania powinny być sformułowane w oparciu owymagania biznesowe i powinny w szczegółowy sposóbodpowiedzieć na pytania powstałe w wyniku analizywymagań• dystrybucja zapytań ofertowych poprzez witrynę WWWPrzegląd referencji• pomaga jeszcze bardziej zawęzić listępotencjalnych dostawców oprogramowania iusług poprzez sprawdzenie ich możliwości wwarunkach rzeczywistych• referencji mogą dostarczyć zarówno dostawcyERP jak i inne podmioty• referencje dostarczone przez dostawców ERP niezawsze są uczciwe i obiektywne• referencje otrzymane od niezależnego podmiotudają najlepsze możliwe do uzyskania naprawdębezstronne informacjePolitechnika Poznańska - Instytut Informatyki 18/39

Systemy Klasy ERP Rok Akademicki 2005/2006Wymiarowanie sprzętu• jeden z trudniejszych i zarazem jeden z najważniejszychprocesów• służy do określenia wielkości obecnego i przyszłegozapotrzebowania na sprzęt komputerowy, który będzieużywany do zaspokojenia potrzeb biznesowych firmy• czasami wymiarowanie sprzętu odbywa się na podstawiekwestionariusza (kilkadziesiąt do kilku tysięcy pytań)związanych z transakcjami, gromadzeniem danych,wymaganiami dotyczącymi przetwarzania danych itp.• wiele firm kupuje niedowymiarowaną ilość sprzętu• rzadkością jest opinia użytkowników ERP lub menadżerówIT mówiąca, że ich sprzęt komputerowy jest za duży wstosunku do ich potrzebPrzegląd dostawców ERP• dla potencjalnych dostawców ERP jest okazją na wizytę w firmie izapoznanie się z profilem jej działalności• dostawcy ERP traktują ten etap jako etap gromadzeniainformacji, na podstawie których przygotują specyficznerozwiązania w demonstracyjnej wersji• różny stopień przygotowania ze strony dostawców ERP:– od starannie przygotowanych kwestionariuszy– do pytań zadawanych ad hoc• firma powinna być przygotowana na dostarczenie dostawcomERP pakietu dokumentów zawierających: raporty, zrzutyekranowe, przykładowe dane, dokumentację elektroniczną i inneelementy zgodne z ustalonymi wymaganiami określonymi naetapie analizy wymagań• dokumenty te posłużą dostawcom ERP do przygotowaniaprezentacji pokazującej w jakim stopniu system może byćdostosowany do wymagań biznesowych firmyPolitechnika Poznańska - Instytut Informatyki 19/39

Systemy Klasy ERP Rok Akademicki 2005/2006Przykładowe scenariusze• formalna metoda wg której postępują dostawcy ERP wcelach demonstracyjnych• różny stopień szczegółowości– od prostych harmonogramów– do bardzo szczegółowych• najlepsze scenariusze skupiają się na tych wymaganiachbiznesowych organizacji, które zostały określone na etapieanalizy wymagań• czasami dostawcy oferują własne scenariusze i prosteprojekty• bardziej dopracowane projekty często wymagają, bywszyscy dostawcy w celach sprawiedliwego porównaniadostarczyli tego samego demo-scenariuszaPrezentacja oprogramowania• jest okazją dla animatorów projektu na obejrzeniesystemu, zadawanie pytań i interakcję z przedstawicielamidostawcy ERP• często stanowi podstawową daną wejściową w procesiewyboru oprogramowania• najczęściej w firmie, rzadziej u dostawcy lub przez Internet• czas prezentacji– od kilku godzin dla firm o prostej strukturze– do kilku tygodni dla dużych i złożonych organizacji• prezentacje oprogramowania mogą być złudne• niektórzy dostawcy oferują standardowe ogólneprezentacje – inni przeprowadzają wstępną konfiguracjęswojego oprogramowania pod kontem wymagańbiznesowych odbiorcy• często prezentacja oprogramowania jest traktowana jakoetap skracania listy potencjalnych dostawcówPolitechnika Poznańska - Instytut Informatyki 20/39

Systemy Klasy ERP Rok Akademicki 2005/2006Sesja wczesnego planowania• umożliwiają zgromadzenie bardziej szczegółowychinformacji dotyczących zakresu, czasu i zasobówpotrzebnych do wdrożenia konkretnego rozwiązania• idealnym rozwiązaniem jest sesja planowania, w którejuczestniczą firma, dostawca ERP i trzecia strona z zewnątrz• określane są:– moduły funkcjonalne, które zostaną wdrożone– czas przeznaczony na wdrożenie tych modułów– własne i obce zasoby niezbędne do wdrożenia– oszacowanie kosztów zaproponowanego rozwiązania• oszacowanie kosztów dużo bardziej precyzyjne niż toobliczone na etapie zwrotu z inwestycji• jeśli oszacowanie kosztów zostało przeprowadzone dlawszystkich dostawców z „krótkiej listy”, to mamy kolejneprecyzyjne porównanie pomiędzy dostawcamiProces wyboru ostatecznego dostawcy (1)• proces decyzyjny, w którym biorą udział wszyscyanimatorzy projektu i wszystkie nagromadzone do tej poryinformacje• w wielu przypadkach decyzja jest oczywista i istnieje jużwzględny konsensus dla wybranego rozwiązania w innychzespół projektowy jest podzielony pomiędzy dwoma lubwięcej rozwiązaniami• ocena powinna być przeprowadzona na podstawiemożliwości systemu dotyczących spełnienia wszystkichwymagań przedsiębiorstwa, a nie na podstawie prezentacjioprogramowania• wynik procesu decyzyjnego nie będzie osiągnięty dopókinie będzie konsensusu pomiędzy wszystkimi animatoramiprojektu• w przypadku jednogłośnego wyboru należy zachowaćszczególną ostrożnośćPolitechnika Poznańska - Instytut Informatyki 21/39

Systemy Klasy ERP Rok Akademicki 2005/2006Proces wyboru ostatecznego dostawcy (2)• dziwne sytuacje, różne naciski, chęć jak najszybszegozainstalowania oprogramowania mogą doprowadzić donieodwracalnej katastrofalnej sytuacji podobnej dokatastrofy Challengera w styczniu 1986• dla wielu firm godną rozpatrzenia jest decyzja ozaniechaniu zakupu nowego systemu i pozostanie przydotychczasowych rozwiązaniach• niektóre firmy zatrzymują wdrożenie na tym etapieoczekując na dodatkowe informacje, czas tej przerwy możetrwać od kilku dni do kilku lat• jest to krytyczny punkt cyklu życia systemu ERP, poakceptacji wyboru, zatrzymanie procesu wdrożenia iodwrócenie cyklu jest czynnością niezwykle kłopotliwą,dlatego zaleca się szczególną ostrożność przy jejpodejmowaniuNegocjacje kontraktu• udokumentowana formalna umowa pomiędzy firmą a dostawcą ERPi/lub dostawcą usług• czasami podpisuje się osobne kontrakty na sprzęt, oprogramowanie iusługi, w innych przypadkach łączy się je• większość dostawców ERP rozpoczyna negocjacje od standardowegokontraktu, którego treść i warunki ulegają zmianie jeszcze przedpodpisaniem ostatecznego kontraktu• dostawca czasami musi zrezygnować z niektórych punktówkontraktu, aby dokonać transakcji• różne podejścia firm do podpisywania kontraktów:– od przejrzenia kontraktu i podpisania go tego samego dnia– do kilkutygodniowych analiz z udziałem różnych osób• proces negocjowania kontraktu może być czasochłonny,bezproduktywny i frustrujący• podpisanie kontraktu przez obydwie strony jest początkiemformalnej zgody na wdrożenie systemu ERPPolitechnika Poznańska - Instytut Informatyki 22/39

Systemy Klasy ERP Rok Akademicki 2005/2006Instalacja oprogramowania• często od razu po podpisaniu kontraktu następuje szybka instalacjaoprogramowania• ten drobny krok ma spektakularne znaczenie, gdyż daje namacalnydowód tego w co zainwestowano spore pieniądze• różnice pomiędzy instalacjami w zależności od:– rozmiaru firmy– używanego oprogramowania (systemy operacyjne, bazy danych itp.)– wybranego systemu i zakresu wdrożenia• instalacja scentralizowanych systemów przebiega na ogół szybko isprawnie• instalacja systemów zdecentralizowanych i heterogenicznych wymagaczasami kilku tygodni a nawet miesięcy• istnieją sytuacje, które nie wymagają instalacji oprogramowania• w przypadku dużych firm o różnych środowiskach biznesowych możedojść do sprzeczności technicznych i bazodanowych nawet wtedy, gdystosowany jest ten sam system ERP, baza danych i system operacyjny,wówczas jedynym rozwiązaniem jest wybór kilku różnych rozwiązań(ERP, DB, OS)Sesja planowania projektu• jest to narada podczas, której planowane jest wdrożenienowego systemu• w naradzie biorą udział wszyscy animatorzy projektu wcelu zjednoczenia we wspólnych wizjach i misjach orazopracowania strategii przeprowadzenia wdrożenia• jest to rozwinięcie sesji planowania wstępnego• stanowi również metodę oceny danych wyjściowych z sesjiplanowania wstępnego• ostatnia okazja do uzyskania informacji na tematdostępności zasobów• czas trwania od 1 dnia do 1 tygodnia• wszystkie zgromadzone w tej fazie dane wyjściowe posłużąjako dane wejściowe do opracowania szczegółowego planuprojektuPolitechnika Poznańska - Instytut Informatyki 23/39

Systemy Klasy ERP Rok Akademicki 2005/2006Szczegółowy plan projektu• formalnie udokumentowany plan przedstawiający strategię wdrożeniawraz z krytycznymi terminami zakończenia poszczególnych etapów• plan dotyczy wdrażanych modułów funkcjonalnych oraz kolejnościwdrażania, przy uwzględnieniu sekwencyjności, równoległości i innychaspektów dotyczących czynności wdrożeniowych• po osiągnięciu na wyższym poziomie planu konsensusu odnośniewyboru modułów do wdrożenia i sekwencji wdrażania tych modułów,na obecnym etapie poszczególnym członkom podstawowego zespołumogą być przydzielone konkretne zadania takie, jak:– szkolenia, testy, konwersje danych, opracowanie prototypów,implementację, dokumentację, rozwiązywanie kwestii spornych itp.• po skompletowaniu wszystkich elementów szczegółowego planuprojektu można go udokumentować w sposób elektroniczny przyużyciu jednego z wielu pakietów oprogramowania do planowaniaprojektów• plan ten często jest przedstawiany w postaci wykresów Gantta• gotowy plan powinien być puszczony w obieg pomiędzy wszystkichanimatorów projektuSztab wdrożeniowy• pomieszczenie przeznaczone wyłącznie na potrzebywdrożenia• jest to centralne miejsce, w którym mogą:– odbywać się narady zespołu wdrożeniowego– znajdować się terminale komputerowe– znajdować się urządzenia multimedialne służące do prezentacji– mieścić się małe sale szkoleniowe• dwa podejścia:– wewnątrz firmy– poza obrębem firmy• dobrze zorganizowany sztab wdrożeniowy jest areną wieluczynności związanych z wdrożeniem• dla niektórych członków zespołu wdrożeniowego staje siędrugim domemPolitechnika Poznańska - Instytut Informatyki 24/39

Systemy Klasy ERP Rok Akademicki 2005/2006Szkolenia ERP• skupiają się na funkcjonalności systemu ERP• powinny być skierowane do głównych animatorów projektu, alemogą w nich uczestniczyć także inne osoby zaangażowane wewdrożenie• wstępne szkolenia ERP nie powinny być kierowane doużytkowników końcowych• celem jest przekazanie specjalistycznej wiedzy tzw. „know-how”na temat systemów ERP• kurs pomaga członkom podstawowego zespołu w pełni zrozumiećwszystkie funkcjonalne możliwości i ograniczenia systemu ERP• kurs powinien być raczej ogólny a nie dostosowany do danejfirmy, gdyż w ten sposób pracownicy mogą poznać pełnąfunkcjonalność systemu ERP w sposób obiektywny i bezstronny• ta wiedza pozwoli członkom podstawowego zespołu ERP określićszczegółowo jak będzie wyglądała konkretna interakcja systemuERP z poszczególnymi funkcjami biznesowymi firmyPytania konfiguracyjne (1)• pytania zadawane przez dostawcę ERP w celu lepszegozrozumienia firmy i określenia, jak najlepiej skonfigurowaćoprogramowanie• 3 sposoby zarządzania:– podejście ręczne• przedstawiciel dostawcy ERP podczas osobistego kontaktu zklientem zadaje różne pytania związane z funkcjonalnością systemu– podejście pół-automatyczne• proces taki jak w podejściu ręcznym z tą jednak różnicą, żeprzedstawiciel dostawcy wprowadza dane do systemukomputerowego w celu elektronicznej konfiguracji oprogramowania• jeśli wykonywane jeszcze przed dostawą oprogramowania, to naogół w momencie dostawy klient otrzymuje całkowicieskonfigurowane oprogramowanie– podejście automatyczne• system ERP wyświetla serię pytań, a klient samodzielnie lub przypomocy konsultanta odpowiada na wszystkie pytania• po zakończeniu system ERP automatycznie aktualizuje swojeustawienia konfiguracyjne w oparciu o otrzymane odpowiedziPolitechnika Poznańska - Instytut Informatyki 25/39

Systemy Klasy ERP Rok Akademicki 2005/2006Pytania konfiguracyjne (2)• elektroniczne narzędzia konfiguracyjne mogą wyglądaćatrakcyjnie, gdyż pozwalają osiągnąć szybkie i niedrogiewdrożenie, jednak taka sytuacja jest rzadka• częściej spotyka się sytuację, w której ustawienia standardowe sąrównie dobre• przyczyny:– na wczesnych etapach wdrożenia użytkownicy nie znają jeszcze pełnejfunkcjonalności systemu ERP, zatem i odpowiedzi nie zawsze sąprecyzyjne• skutki:– duża liczba zmian konfiguracyjnych przed startem produktywnym• narzędzia konfiguracyjne oraz rozmowy informacyjne zkonsultantami pomagają lepiej poznać organizację, ale nie są wstanie zagwarantować sukcesu wdrożeniaOpracowanie polityki wdrożenia• służy ustaleniu podstawowych reguł wdrożenia i dokonywaniazmian w systemie ERP• polityka rozwiązywania kwestii spornych jest formalnąprocedurą ich obsługi w ramach podstawowego zespołu• tylko nierozwiązywalne problemy oraz kwestie sporne sąprzekazywane na wyższe szczeble zarządzania aż do miejsca,w którym zostanie podjęta decyzja• tylko krytyczne kwestie sporne nierozstrzygalne na niższychpoziomach są przekazywane kierownictwu wyższego szczebla• polityka modyfikacji oprogramowania jest formalnieudokumentowanym procesem wyjaśniającym procedury dlarealizacji zmian w oprogramowaniu• proces zmian oprogramowania może wymagać od kilkukluczowych animatorów wyłączenia się i przyjrzenia sięuzasadnieniom kosztów/zysków spowodowanych modyfikacjąoprogramowaniaPolitechnika Poznańska - Instytut Informatyki 26/39

Systemy Klasy ERP Rok Akademicki 2005/2006Dopasowanie raportów• faza reprezentująca połączenie raportów starego systemu zraportami w nowym systemie• większość starych systemów zawiera całe serie różnych raportówdla każdego modułu• raporty na ogół są tworzone w drodze:– wyboru danych– sortowania danych– prezentowania danych• jeżeli w firmie nie przeprowadzano reorganizacji procesówbiznesowych to te same raporty powinny wystąpić w nowymsystemie• część starych raportów w formie papierowej może być zastąpionaraportami w formie elektronicznej korzystając z technicznychmożliwości nowego systemu (np. prezentacje wideo, wykresy,arkusze kalkulacyjne)• jeżeli wystąpiła faza reorganizacji procesów biznesowychwówczas mogą być potrzebne inne typy raportów niż teoferowane przez stary systemOdwzorowanie funkcjonalne• proces współpracy wielu osób w celu zrozumienia iudokumentowania przepływu procesów biznesowych i sposobu ichinterakcji z oprogramowaniem• zespół ERP zaczyna od danych z analizy wymagań i sesji planowaniaintegracji biznesowej i dostraja je do możliwości i ograniczeńoprogramowania ERP• odwzorowanie funkcjonalne jest najbardziej efektywne gdydostępne są wszystkie informacje na temat:– funkcjonalnych możliwości i ograniczeń systemu– specyficznej wiedzy organizacyjnej– specyficznej wiedzy z zakresu działalności gospodarczej firmy– umiejętności pracowników organizacji• wymaga zaangażowania wszystkich członków podstawowegozespołu wdrożeniowego oraz zewnętrznych konsultantów znającychmożliwości oprogramowania• tablica niezbędnym narzędziem pracy• odwzorowanie funkcjonalne może odbyć się w trakcie jednejogromnej sesji lub kilku mniejszych sesji indywidualnychPolitechnika Poznańska - Instytut Informatyki 27/39

Systemy Klasy ERP Rok Akademicki 2005/2006Testowanie i opracowanie prototypu (1)• na podstawie wyników odwzorowania funkcjonalnego udowadniamożliwość (lub jej brak) skonfigurowania oprogramowania tak abyspełnione były wymagania funkcjonalne• na tym etapie członkowie zespołu ERP ściśle współpracują zkonsultantami przy:– konfigurowaniu oprogramowania– wprowadzaniu przykładowych danych– wykonywaniu transakcji– przeglądaniu danych wyjściowych– określaniu poprawności przebiegu procesów• proces ten może być powtórzony dla jednego procesu biznesowego:– od 1 razu– do kilkuset razy• każde powtórzenie procesu może wiązać się z poprawką w systemie iponowną oceną wyników• gdy proces jest zgodny z oczekiwaniami, ustawienia konfiguracyjnesą zapisywane i dokumentowaneTestowanie i opracowanie prototypu (2)• na początku jest stosunkowo małe i stopniowo się rozrasta• pojedyncze komponenty przepływu procesów biznesowychsą projektowane, testowane i weryfikowane, a następniełączone w większe przepływy procesów biznesowych• większe przepływy procesów biznesowych są testowane ipoprawiane w oparciu o sprawdzone komponenty składowe• na zakończenie przeprowadza się test procesów dla całegoprzedsiębiorstwa• potrzeby testowania i prototypów różne w różnych firmach:– mniejsze w przypadku standardowych procesów biznesowych– większe w przypadku skomplikowanych przepływów• w wielu przypadkach firmy nie są w stanie określić w jakimstopniu nietypowe są ich procesy biznesowe, wówczasdobrym pomysłem jest testowanie oprogramowaniazawczasuPolitechnika Poznańska - Instytut Informatyki 28/39

Systemy Klasy ERP Rok Akademicki 2005/2006Modyfikacje oprogramowania• umożliwiają rozszerzenie właściwości funkcjonalnychoprogramowania ERP• stanowią jedną z najbardziej skomplikowanych części etapuprototypowania i testowania• powinny być wykonywane tylko wtedy, gdy fazy odwzorowaniafunkcjonalnego oraz opracowania prototypu jednoznaczniewykażą, że oprogramowanie nie jest w stanie zrealizowaćwymaganych funkcji• dodatkowa analiza zysków i strat powinna być przeprowadzona,aby znaleźć ekonomiczne uzasadnienie dla procesu modyfikacjioprogramowania• w firmach przechodzących od własnych systemów do systemuERP modyfikacje oprogramowania są realizowane bezwiększego namysłu, chociaż właściwa funkcjonalność może byćosiągnięta przez opracowanie prototypu i testowanie• modyfikacje oprogramowania, o ile nie są niezbędne, są raczejniepożądane ze względu na ukryte koszty i problemy wpielęgnacji takich zmianKonwersja bazy danych• proces przeniesienia danych ze starego systemu do nowego• można być wykonana ręcznie lub przy użyciu jednej z wieluróżnych metod elektronicznych• zalety ręcznej konwersji danych:– możliwość gruntownego przetestowania oprogramowania– zdobycie dodatkowej wiedzy podczas rozwiązywania problemówze spójnością danych– oprogramowanie będzie często wykonywać test spójności danych,zazwyczaj pomijany przy konwersji elektronicznej• programy służące do elektronicznej konwersji danych używanegłównie do przenoszenia szybko zmieniających się informacjioraz tabel zawierających duże ilości danych• oprogramowanie do konwersji danych powinno być gruntownieprzetestowane pod względem jakości i niezawodności• błąd w oprogramowaniu do konwersji nie zauważony do chwilistartu produktywnego może wywołać spustoszenie w bazie nacałe miesiące a nawet i lataPolitechnika Poznańska - Instytut Informatyki 29/39

Systemy Klasy ERP Rok Akademicki 2005/2006Planowanie reakcji na problemy• proces planowania reakcji na przypadek, gdy cośpójdzie nie tak jak powinno• opracowane na zasadzie „co...jeśli...”• istnieje wiele obszarów projektu ERP, w którychplanowanie reakcji na problemy może byćstosowane i przynieść korzyści• najważniejszym etapem jest start produktywny• dobrą praktyką jest pozyskanie od konsultantówwiedzy na temat wszystkich problemów jakie sąim znane z doświadczenia lub z opowiadań• wiedza ta posłuży do opracowania dobrego planureakcji na problemy, ale również da szerokiespojrzenie na słabe punkty oprogramowaniaDokumentacja• jest bardzo istotnym narzędziem komunikacyjnym przywdrażaniu ERP• przydatna przy:– modyfikacji oprogramowania– przepływach procesów biznesowych– rozwiązywaniu problemów– ustawieniach konfiguracyjnych ERP– szkoleniach– audytach– analizie zysków i strat– ogólnej komunikacji• pomaga spowolnić tempo wdrożenia zmuszającużytkowników do przemyślenia tworzonej dokumentacji• niektóre systemy ERP dostarczają narzędzi do zarządzaniadokumentamiPolitechnika Poznańska - Instytut Informatyki 30/39

Systemy Klasy ERP Rok Akademicki 2005/2006Szkolenia dla użytkowników końcowych• szkolenia zarówno dla użytkowników końcowych jak iczłonków zespołu ERP• opracowane specjalnie dla danej firmy• informacje na temat co i kiedy należy zrobić, którego menuużyć, by skorzystać z odpowiednich funkcjonalnościsystemu• uczestnicy szkolenia powinni otrzymać materiałyszkoleniowe wcześniej opracowane w formie dokumentacji• instruktorzy mogą być zarówno pracownikami firmy, jak ikonsultantami zewnętrznymi• czasami pracownicy firmy, którzy mają przeprowadzićszkolenie, sami muszą przejść kurs dotyczący sztukiprezentacjiAudyty• mogą być stosowane do prawie wszystkich etapów projektu• mogą być pomocne w zapewnieniu, że projekt jest zgodny zoczekiwaniami, realizowany terminowo i w ramachprzewidzianego budżetu• dostawcy ERP i zewnętrzni konsultanci mogą być bardzopomocni w audytach• z reguły dostawcy ERP mogą dostarczyć listy kontrolne dlawszystkich ważnych ustawień konfiguracyjnych systemu ERP• odpowiedzialność za terminowe przeprowadzenie wszystkichniezbędnych audytów leży po stronie firmy i zespołu ERP• dostawcy ERP i zewnętrzni konsultanci rzadko oferująjakąkolwiek gwarancję, że efektywnie przeprowadzą audyty• krytycznymi punktami do przeprowadzenia audytów są fazy:przedwdrożeniowa, wdrożeniowa i powdrożeniowa• najbardziej krytyczny punkt w fazie wdrożenia występuje tużprzed startem produktywnym• istnieją elektroniczne narzędzia audytorskiePolitechnika Poznańska - Instytut Informatyki 31/39

Systemy Klasy ERP Rok Akademicki 2005/2006Pomiary wydajności• dotyczą krytycznych informacji powiązanych z modułamifunkcjonalnymi i odpowiadającymi im czynnościamifunkcjonalnymi• wiele firm nie dostrzega potencjału narzędzi pomiarowychukrytych w systemie ERP, jak np. narzędzia raportowania i plikidanych• wśród wielu pomijanych a istotnych miar wydajności możnadostrzec między innymi:– ujemne stany magazynowe– terminowe dostawy– terminową realizację zleceń produkcyjnych– terminową realizację dostaw od firmy partnerskiej– wiadomości związane z działaniami MPS/DRP/MRP– zwroty od klienta– zwroty do dostawcy• inne istotne miary, czasami wymagające więcej pracy to:– odpowiedniość stanów magazynowych– precyzja specyfikacji materiałowych– precyzja marszrut technologicznych– całkowicie zrealizowane zlecenia sprzedaży itp.Start produktywny• najważniejsza faza projektuPolitechnika Poznańska - Instytut Informatyki 32/39

Systemy Klasy ERP Rok Akademicki 2005/2006Wsparcie powdrożeniowe• wszystkie pomocnicze czynności niezbędne po terminie startuproduktywnego• potrzeby dotyczące takiego wsparcia, na ogół duże na samympoczątku, maleją wraz ze stopniem zaznajomieniaużytkowników z systemem• wsparcie powdrożeniowe może być uciążliwe, jeśli wieleprocedur działa wadliwie• w wielu przypadkach błędy są wyłapywane kilka dni lubtygodni po starcie produktywnym• im późniejsze wykrycie usterek, tym większy koszt ichusunięcia• najlepszą drogą uniknięcia tych problemów jest staranne igruntowne przeprowadzenie fazy opracowania prototypu itestowania• umożliwia ono zminimalizowanie niespodzianek, ale nadalfirma powinna być przygotowana na znaczne wsparciepowdrożenioweBieżące szkolenia i pielęgnacja systemu• wewnętrzne szkolenia – dla nowych pracowników, przy rotacjistanowisk, pomiędzy różnymi funkcjami• zewnętrzne szkolenia – wgląd na nowości z zakresu oprogramowania,zarządzania i technologii komputerowych• wymiana informacji w ramach grup użytkowników danego systemuERP• lokalne oddziały głównych producentów• fachowe czasopisma, stowarzyszenia badawczo-rozwojowe, Internet– dodatkowymi sposobami umożliwiającymi kontakt z nowościami wzakresie ERP• bieżąca pielęgnacja systemu – ciągłe powdrożeniowe wsparciesystemu• help desk– formą bieżącej pielęgnacji systemu– pomoc dla użytkowników w wielu potrzebach związanych z ERP– help desk wewnętrzny – wyłącznie dla danej firmy– help desk zewnętrzny – na ogół u dostawcy ERP lub dostawcy usługPolitechnika Poznańska - Instytut Informatyki 33/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia „na złamanie karku” –zdarzenia i sekwencje• W celu obniżenia kosztów i skrócenia czasu z wdrożenia wyeliminowanowiele istotnych kroków• Bardzo mało czasu poświęca się wyszukiwaniu dostawców ERP izadawaniu pytań• Decyzja o wyborze dostawcy podejmowana jest zazwyczaj przez jednegolub kilku przedstawicieli kadry zarządzającej wyższego szczebla• Pośpieszne negocjowanie kontraktu bez zbytnich rozmów• Duży pęd do zainstalowania oprogramowania tak szybko jak to możliwe• Konwersja bazy danych ręczna, przeprowadzana przez pracownikówfirmy, nie ma czasu na opracowanie elektronicznych narzędziStrategia „na złamanie karku” –wady i zalety• Zalety–prostota– szybkość– nie wymaga wiele planowania– brak polityki– niskie koszty początkowe• Wady–wysokie ryzyko– ogromna ilość poprawek– braki organizacyjne– problemy z wydajnością– niskie korzyściPolitechnika Poznańska - Instytut Informatyki 34/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia niskiego ryzyka –zdarzenia i sekwencjeStrategia niskiego ryzyka –wady i zalety• Zalety– bardziej przewidywalne wyniki– mały zakres– lepsza zgodność z założonym budżetem– mniejszy wpływ na bieżącą działalność biznesową– osiągnięcie maksymalnych korzyści– niewielka ilość dużych niespodzianek• Wady– długie wdrożenie– konceptualnie trudne do opanowania– wymaga wsparcia ze strony kierownictwa wyższego szczebla– wymaga dedykowanych zasobów– kosztownePolitechnika Poznańska - Instytut Informatyki 35/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia wdrożenia budżetowego –zdarzenia i sekwencjeStrategia wdrożenia budżetowego –wady i zalety• Zalety–prostota– nie wymaga wiele planowania– brak polityki– niskie koszty początkowe• Wady–wysokie ryzyko– bardzo długa implementacja– ogromna liczba poprawek– braki organizacyjne– problemy z wydajnością–problemy funkcjonalne– niskie korzyściPolitechnika Poznańska - Instytut Informatyki 36/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia wdrożenia własnego –zdarzenia i sekwencjeStrategia wdrożenia własnego –wady i zalety• Zalety– wymaga użycia podstawowych elementów wdrożenia ERP– buduje solidne zasoby techniczne– dokładne odwzorowanie przepływu procesów biznesowych– kod źródłowy zazwyczaj bardzo zwarty dzięki czemu nie wymagadużej ilości zasobów komputerowych– wymusza komunikację między przedstawicielami różnychobszarów• Wady– wysokie ryzyko– intensywne wsparcie powdrożeniowe– podatne na zmiany pracowników– brak elastyczności– powolna adaptacja zmian technologicznych– brak zewnętrznego wsparcia wiedzą– braki integracjiPolitechnika Poznańska - Instytut Informatyki 37/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia gwiazdy – zdarzeniai sekwencje oraz wady i zalety• Zdarzenia i sekwencje podobne do strategiiniskiego ryzyka z większym naciskiem na cele• Zalety– niskie ryzyko– wysokie korzyści– przewidywalne wyniki– w trakcie powstaje solidna baza wiedzy– wysokie poczucie własności ze strony użytkowników– silna integracja• Wady–koszty–może znacznie pomniejszyć zasoby organizacyjne– psychologicznie stresogenneStrategia wdrożenia pod klucz –zdarzenia i sekwencje oraz wady i zalety• Struktura i sekwencje zbliżone do strategiiniskiego ryzyka, ale większość zdarzeń i planówzrealizowanych przez zasoby zewnętrzne• Zalety– zaangażowanie nielicznych lub żadnych zasobówwłasnych• Wady–wysokie ryzyko– kosztowne– brak poczucia własności– przeróbki / pominięte funkcjonalności– negatywne relacje między firmą a wdrożeniowcami– podatne na zmiany związane z dostawcąPolitechnika Poznańska - Instytut Informatyki 38/39

Systemy Klasy ERP Rok Akademicki 2005/2006Strategia wdrożenia partnerskiego –zdarzenia i sekwencje oraz wady i zalety• Struktura i sekwencje podobne jak w strategii niskiegoryzyka, ale odpowiedzialność rozłożona pomiędzy zasobywewnętrzne i zewnętrzne• Zalety:– dobry dostęp do wiedzy funkcjonalnej i technicznej– niższe wymagania w stosunku do zasobów organizacyjnych• Wady:– średnie ryzyko– kosztowne– problemy własnościowe– negatywne relacje pomiędzy firmą a zasobami zewnętrznymi– podatne na zmiany związane z dostawcąStrategie wdrożeń -podsumowanie• Ze względu na skomplikowaną naturęwdrożenia, niewiele jest identycznychwdrożeń• Wiele wdrożeń ma strukturę i sekwencjezbliżone do prezentowanych strategii• Niektóre wdrożenia różnią się nieznacznieod prezentowanych podejść, a inne takznacznie, że trudno je zakwalifikować dojakiejkolwiek z prezentowanych tu strategiiPolitechnika Poznańska - Instytut Informatyki 39/39