Czy na pokładzie jest tester? O roli testera oprogramowania w projekcie
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Kiedy wyślesz zapytanie ofertowe do dostawcy ERP lub CRM, w odpowiedzi dostaniesz pytanie o wymagania, jakie ma spełniać system. Teoretycznie każdy mniej więcej wie, jak działa firma, w której pracuje. Jednak w tym przypadku teoretycznie i mniej więcej to słowa klucze – często wywołujące więcej szkody niż pożytku. W końcu to, co nam się wydaje, nie zawsze jest odzwierciedleniem rzeczywistości.
W tym artykule:
Celem mapowania procesów może być przygotowanie firmy do wdrożenia systemu typu ERP lub CRM. Przy tak jasno sprecyzowanym celu, cały projekt mapowania będzie skupiał się na wyszukaniu i uwzględnieniu kluczowych informacji - określeniu przebiegu procesów oraz występujących w ich ramach zależności między: ludźmi w danym dziale, z innymi działami lub z zewnętrznymi podmiotami.
Co więcej, mapowanie procesów obnaży problemy występujące w procesie np. wąskie gardła, zdublowane kroki, brak jasno określonej osoby odpowiedzialnej za proces itd. Dzięki temu będziemy mieć klarowny obraz, jak proces wygląda teraz i jak (lepiej, bez powielania ww. problemów) powinien wyglądać w przyszłości – w nowym systemie.
W wyniku mapowania procesu powstaje rzetelna dokumentacja zawierająca diagramy (mapy), metryki i opis poszczególnych procesów, co de facto jest dokładnie opracowanymi wymaganiami systemowymi, o które pyta dostawca ERP-a lub CRM-u. Tak przygotowana dokumentacja ułatwia wszystkim (zarówno ludziom w samej organizacji oraz dostawcom systemów) zrozumienie jak działa organizacja i jakie są jej rzeczywiste potrzeby tych procesów.
Dobrze opracowana dokumentacja pozwala na łatwiejsze określenie, które funkcje nowego systemu są najistotniejsze - must have, będą tylko miłym dodatkiem - nice to have lub są całkowicie niepotrzebne dla naszej organizacji – won’t.
Dzięki takiej gradacji możemy też precyzyjnie zdefiniować stopień personalizacji systemu, a tym samym możliwe, że zmniejszyć koszty pisania kodu pod nowe funkcje. Równocześnie mamy pewność, że to co istotne, z punktu widzenia naszej organizacji, na pewno znajdzie się w systemie.
Organizacja, z różnych powodów, może chcieć wdrożyć system ERP lub CRM, dzieląc wdrożenie na etapy. Pierwszy powód to oczywiście finansowy. Usługa samego dobrania odpowiedniego ERP-a do potrzeb danego przedsiębiorstwa, w specjalistycznych firmach kosztuje nawet kilkanaście tysięcy złotych. Skoro sama decyzja o wyborze systemu jest trudna i dodatkowo niesie za sobą olbrzymie konsekwencje, to co dopiero zakup i jego wdrożenie.
Drugi to zmiana zachowania pracowników, czyli ich adaptacja do używania nowego systemu. Wdrożenie systemu na początku w jednym, dwóch działach jest łatwiejsze niż jego implementacja od razu w całej firmie.
Wybór procesów do zmapowania lub zautomatyzowania może być trudny. Dlatego przygotowaliśmy listę pytań, które mogą ułatwić podjęcie decyzji - lista kontrolna.
Wybierz jeden z procesów występujący w firmie. Następnie odpowiadając na poniższe pytania, oceń go w skali od 1 do 5 punktów. Zsumuj punkty. Proces o największej liczbie punktów prawdopodobnie powinien być zmapowany / zautomatyzowany w pierwszej kolejności.
Mapowanie procesów powinno być nieodłącznym elementem wdrożenia każdego systemu ERP lub CRM. Zupełnie tak jak kiedyś kompas i mapa były nieodłącznym elementem podróży. W końcu to system informatyczny ma być dla ludzi i ułatwiać ich codzienną pracę.
Nie wiesz, którego ERP-a wybrać? Skorzystaj z naszej wyszukiwarki ERP-ów.
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Pierwsza zasada brzmi: testowanie ujawnia usterki, ale nie może dowieść ich braku, czyli o roli testera
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Decyzja jest trudna, ale możliwa do podjęcia. Wszystko zależy od przeznaczenia danego rozwiązania i budżetu. Sprawdź >
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.
Model wspólnej odpowiedzialności zakłada, że Microsoft zabezpiecza swoją infrastrukturę IT. Ty zabezpieczasz swoje dane.