Na początek historyjka: “Konsultant umawia się z Prezesem firmy na spotkanie. Sprawa ważna bo Prezes zlecił mu wdrożenie nowego systemu wynagrodzeń i premiowania. Na spotkaniu konsultant po krótce opowiedział, że to wyjątkowo ważna sprawa dla firmy. Poprosił potem o wyznaczenie kilku osób ze ścisłego kierownictwa, które wraz z nim opracują wymagania na nowy system płac, który to potem konsultant opracuje i wdroży w firmie.  Prezes odrzekł: to są płace dla moich pracowników, ja nie mam czasu, proszę się umówić z nimi, przeprowadzić ankiety i niech oni Panu określą jak chcą być wynagradzani i ile chcą zarabiać. To w końcu to dla nich te pieniądze.”

Już widzę uśmiechy na Waszych twarzach. I…

Sytuacja nie do wyobrażenia, chyba żaden Prezes by tak nie postąpił. Tylko Zarząd firmy ma wiedzę na temat celów firmy i jej strategii oraz wiedze o kosztach, wiec tylko Zarząd ma podstawy by określać jak się ma  koszt pracy do potrzeb firmy w kwestii wykonywania tej pracy. Że nie wspomnę jak by wyglądały płace ustanawiane przez płacobiorców.

Jednak niestety takie sytuacje są nagminne! Bo czym od poprzedniej różni się ta historyjka: “Konsultant umawia się z Prezesem firmy na spotkanie. Sprawa ważna bo Prezes zlecił mu wdrożenie nowego systemu wspierającego zarządzanie firmą. Na spotkaniu konsultant po krótce opowiedział, że to wyjątkowo ważna sprawa dla firmy, należy ustalić cele biznesowe a potem wymagania na system IT itp.. Poprosił o wyznaczenie kilku osób ze ścisłego kierownictwa, które wraz z nim opracują wymagania na nowy, tak ważny system, który to potem konsultant przygotuje lub wybierze na rynku i wdroży.  Prezes odrzekł: to jest system dla moich pracowników, ja nie mam czasu, proszę się umówić z nimi, przeprowadzić ankiety i niech oni Panu określą jak chcą żeby on wyglądał i co robił. To w końcu dla nich to nowe narzędzie pracy.”

I jak teraz wyglądają Wasze miny? Dla mnie obie historyjki są takie same w kwestii skuteczności obu projektów dla firmy.

Więc jak to jest z tymi wymaganiami?  Jak je wyspecyfikować?

Po pierwsze każdy nowy zasób czy reorganizacja firmy, powinny być efektem jakiegoś celu biznesowego. System IT to nic innego jak kolejny nowy zasób w firmie, nowe narzędzie pracy. Więc właściwa kolejność sama się nasuwa:

  1. Opracowanie celów biznesowych i planów
  2. Opracowanie strategii realizacji planów i listy wymaganych zasobów
  3. Określenie wymagań na te zasoby (tu system IT)
  4. Znalezienie produktu lub usługi oraz ich dostawcy spełniających tak określone wymagania (wskazanie wymaganych w nowym systemie funkcjonalności),
  5. Wdrożenie, w tym nanoszenie zmian na projekt, jeżeli tylko okaże się, że w trakcie wdrożenia zaszły zmiany na rynku, uzasadniające zmiany w projekcie.

Jak zebrać wymagania, skoro nie ankietami?

Ankiety to, ich treść, jak wielokrotnie słyszałem, to tak zwane “pobożne życzenia”. Sam ten epitet o czymś już świadczy. Tak wiec ja uważam, że należy ich unikać. Moim zdaniem skuteczniejszą drogą, zapewniającą dużo mniejsze ryzyko pominięcia istotnych cech i chroniące właśnie przed “pobożnymi życzeniami” jest wykonanie modelu firmy.

Model taki budujemy metodą “od ogółu do szczegółu”. Modelem organizacji najlepiej wspierającym kolekcjonowanie wymagań na system IT jest mapa procesów biznesowych. Model taki przy okazji może posłużyć do pewnej reorganizacji firmy. Nie zapominajmy, że wdrażany system to nowe narzędzie pracy więc zawsze wdrożenie wiąże się z reorganizacją w firmie. Modelowanie zaś, prowadzone w pewien specyficzny sposób bardzo ułatwia wychwytywanie w organizacji wszelkich nielogiczności, zbyt kosztownych procesów, zbędnych czynności. Jak?

Część analityków używa modelowania tylko do udokumentowania zastanego oraz planowanego stanu rzeczy jednak modelowanie może przynieść daleko większe korzyści poza projektami informatycznymi. Jak przynieść oszczędności samym tylko wykonaniem modelu? Jak osiągnąć korzyści z modelowania odkładając na zakończenie projektu wykonany model na półkę? Historia zna wiele przypadków, że samo wykonanie modelu firmy, oczyszczenie go z nielogiczności, zbędnych czynności itp. powodowało obniżenie kosztów nawet o 30%! Oczyszczenie firmy tylko z niepotrzebnych, nie wnoszących wartości procesów, może istotnie skrócić czas obsługi klientów a to już nic innego jak podniesienie konkurencyjności w czystej postaci.

Tworząc model procesów można oprzeć się na teorii łańcucha wartości i nałożyć na proces modelowania pewne wymagania. Ogólnie polega to na przyjęciu zasady, że każdy modelowany element (proces) musi powiększać wartość wnoszoną do całego łańcucha procesów (łańcucha wartości), w którym uczestniczy. Jako przykład podam pozornie prosty model organizacyjny firmy, który można analizować podobnie a jest łatwiejszy do pokazania tej zasady.

Jeżeli chcemy takim schematem zaprezentować tylko wolę Zarządu firmy w kwestii organizacji firmy to może on mieć dowolną postać zgodną z życzeniem decydenta. Możemy jednak pokusić się o postawienie sobie innego zadania: usprawnienie organizacji i jej optymalizacja. W takim przypadku narzucamy pewne zasady na tworzenie schematu organizacyjnego. Nazwiemy go teraz modelem organizacji zasobów ludzkich firmy.

Taką zasadą może być np. założenie, że każdy każdy pracownik ma tylko jednego przełożonego, oraz każdy kierownik ma co najmniej dwóch podwładnych. Bo jaką rolę spełnia osoba, która ma jednego szefa i jednego podwładnego? Jedną z ról menedżera (kierownika) jest organizacja pracy podwładnych jednak trudno mówić, że organizujemy coś lub koordynujemy skoro mamy tylko jednego podwładnego? Jaką wiec wartość wnosi w hierarchii osoba mająca tylko jednego podwładnego? Tą metodą skonstruujemy bardzo przydatny schemat organizacyjny, proponuje spróbować samemu.  Taki schemat jest w zasadzie wymagany jako lista zasobów (ról) np. w systemie ERP

Modelując procesy można poczynić kilka tego rodzaju założeń i okazuje się, że samo modelowanie, czyli  zastanowienie się nad logiką każdego elementu firmy, przynosi już korzyści. Mając model procesów uporządkowany, opracowany na nowo, oczyszczony z “błędów organizacyjnych” robimy listę procesów, które chcemy wesprzeć nowym systemem i mamy listę oczekiwanych funkcjonalności. Jest to lista doskonale nadajaca się np. do wykonania diagramu przypadków użycia, tez zaś spokojnie można udokumentować wspomagając się wywiadami ale dopiero teraz.

Metodyka ta jest zgodna z modelem SOA (ang. Service Oriented Application, Aplikacje zorientowane na usługi), którego to modelu popularność rośnie od pewnego czasu (więcej na stronie www.omg.org). Metodyka ta jest zgodna także z [[metodą podnoszenia efektywności organizacji Rummlera-Brache’a]].

Firma jako taka jest procesem w rynkowym łańcuchu wartości w jakim funkcjonuje. Przykład: na jednym końcu łańcucha mamy kopalnię węgla a na drugim np. mój kaloryfer w domu. Po drodze jest np. elektrociepłownia opalana węglem. Mamy więc łańcuch procesów takich jak: wydobycie węgla, transport węgla, wytwarzanie pary, transport pary do mieszkań. To sa procesy, które można dekomponować i będziemy w tedy modelowali poszczególne firmy. Biznesami są: kopalnie, kolej, elektrociepłownie. Możliwe są np. trzy procesy wydobycia, transportu i proces wytwarzania pary mogą stanowić jeden biznes np. Turoszów. Tak więc można spokojnie według mnie przyjąć, że powstanie produktu (gdzie produktem procesu może być także stan nazwany: węgiel dowieziony do celu) jest celem procesu. Co do celu modelu dla mnie jest tylko jeden: udokumentowanie przedmiotu i wyników analizy oraz testowanie hipotez a to prosta droga do obniżenia ryzyka przyjęcia hipotezy we wdrożeniu. I po to głownie modelujemy.

 

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.