O zbieraniu wymagań – czyli jak zepsuć system ERP jeszcze przed jego wdrożeniem

Artykuł pierwotnie ukazał się na portalu www.4pm.pl pod adresem http://4pm.pl/artykuly/o-zbieraniu-wymagan-czyli-jak-zepsuc-system-erp-jeszcze-przed-jego-wdrozeniem#2

„Jeśli nie ustalisz dobrze wymagań, nie ma znaczenia jak dobrze zrobisz cokolwiek innego¹” (Wiegers 2004) i choć etap zbierania wymagań opisują wszystkie najważniejsze metodyki projektowe sprawia on wciąż wiele problemów. Frederick Brooks w szeroko komentowanej książce „Mythical Man-Month” pisze „Najtrudniejszą częścią tworzenia oprogramowania jest szczegółowe określnie, co chcemy zbudować, żadna inna część pracy koncepcyjnej nie jest tak trudna jak ustalanie szczegółowej listy wymagań.[…] Niepowodzenie na żadnym innym etapie pracy nie spowoduje tak daleko idących negatywnych skutków. Żaden inny etap nie jest tak trudny do późniejszego sprostowania².” (Brooks 1987). Pomimo iż opinia Brooksa może wydawać się nieco radykalna, badania pokazują, że czym później błąd zostaje wykryty tym większy jest koszt jego naprawy - w skrajnym przypadku różnica ta może być nawet ponad stukrotna (Westfall 2005). 

W przypadku wdrożeń dużych systemów informatycznych z reguły do czynienia mamy z predefiniowanymi funkcjonalnościami systemu (SAP ERP, Oracle EBS, MS Dynamics), gdzie firma wdrożeniowa dokonuje konfiguracji, aby spełnić „wymagania biznesowe”. W tym artykule nacisk zatem położony został na zbieranie wymagań biznesowych w odróżnieniu od innych typów wymagań – np. wymagań technicznych.

Wymagania co do jakości wdrażanych rozwiązań klasy ERP, jak i kryteria akceptacji systemu, z reguły określa się i zapisuje w kontekście spełnienia wymagań biznesowych, to znaczy stworzenia w systemie możliwości obsługi wymaganych przez interesariuszy funkcjonalności. Innymi słowy osoby, które w przyszłości będą korzystać z systemu w przyszłości powinny również określić, na co system powinien pozwalać. Podejście takie chętnie akceptowane jest zarówno przez firmę wdrożeniową, jak i jej klienta, ponieważ z jednej strony umożliwia relatywnie łatwe określenie zakresu prac, które mają być wykonane, z drugiej zaś gwarantuje klientowi, iż jego wymagania zostaną spełnione. Etap zbierania wymagań ma kluczowe znaczenie dla projektu, ponieważ tu właśnie definiowane zostają założenia co do przyszłej jakości użytkowej systemu. W praktyce jednak brak świadomości znaczenia tego etapu oraz brak przyjęcia spójnej metodyki zbierania wymagań skutkuje powstaniem mechanizmów i zachowań wręcz szkodliwych dla finalnej jakości wdrażanego rozwiązania. Co więcej - klasycznie zdefiniowane procedury kontroli jakości mogą przyczyniać się do pogłębienia negatywnych efektów tych mechanizmów, co paradoksalnie prowadzi do tego, że firma, w której wdrażane jest rozwiązanie, sama, w dobrej wierze, wpływa na znaczne obniżenie jego jakości, nie wspominając o zwiększeniu kosztów i ryzyku opóźnień. Mowa tu o charakterystycznych dla projektów wdrożeniowych zachowaniach z trzech poniższych grup:

• „więcej znaczy lepiej” – określanie wymagań nadmiarowych;
• „rozumie się samo przez się” – określanie wymagań niesprecyzowanych;
• „dokładnie tak jak chcemy/dokładnie tak jak jest” – określenie wymagań w kontekście możliwości systemu i możliwości adaptacyjnych organizacji.

1.1 „więcej znaczy lepiej” – określanie wymagań nadmiarowych;

Trudności typu „więcej znaczy lepiej” związane z definicją wymagań biznesowych mają swoje korzenie w przekonaniu, że każda dodatkowa funkcjonalność zwiększa jakość użytkową systemu; w imię zasady, że jeżeli użytkownicy mogą wydobyć z systemu więcej, powinni być bardziej zadowoleni. Takie podejście znacząco rzutuje na sposób zbierania wymagań, które następnie stanowią podstawę do podpisania umowy z firmą wdrożeniową.

Klasycznym przykładem takiego podejścia było zapytanie ofertowe firmy, która ze względu na klauzulę poufności zostanie nazwana PFPR (przykładowa firma produkcyjna). Owo zapytanie przesłane zostało w formie arkusza kalkulacyjnego, w którym dla każdego z działów, po otwierającym stwierdzeniu „system powinien pozwalać na:”, następowały chaotycznie wylistowane kolejne wymagania. Co więcej, wytyczne te w żaden sposób nie odnosiły się do procesów wykonywanych w firmie, często były to zdania wyrwane z kontekstu, stwierdzenia nieprecyzyjne i ogólniki odnoszące się bardziej do nowinek technologicznych z prasy specjalistycznej niż realnej praktyki biznesowej firmy.

Tak przygotowany dokument wymagań jest rażącym przykładem braku kompetencji pracowników firmy PFPR odpowiedzialnych za ich zdefiniowanie. Powstaje on wtedy, gdy z jednej strony na każdym z etapów kolejne osoby współtworzące dokument (pracownicy, kierownicy działów, kierownicy departamentów) wychodzą z założenia, że na „wszelkim wypadek” wymagania powinny zostać określone jak najszerzej, z drugiej zaś brakuje w procesie zbierania wymagań osoby, która posiadłaby na tyle dużą znajomość procesów oraz moc decyzyjną, aby uczynić z nich spójną całość zgodną z planami rozwojowymi i strategią przedsiębiorstwa³.

Takie „beztroskie” podejście do kwestii zbierania wymagań prowadzi do ujęcia w kontrakcie dużej ilości wymagań określanych w tekście umownie jako „nadmiarowe”. Wymagania nadmiarowe, czyli takie, których koszt realizacji przewyższa wartość dodaną dla biznesu w długim okresie. Identyfikacja wymagań nadmiarowych nie jest zadaniem łatwym i pozostaje kwestią indywidualną dla każdego przedsiębiorstwa. Decyzje o uznaniu wymagania za nadmiarowe interesariusze powinni podjąć wspólnie na podstawie odpowiedzi na, między innymi, następujące pytania:

• jak często w praktyce biznesowej występuje dane wymaganie (wolumen transakcji, częstotliwość użycia)?
• czy dla wymaganej funkcjonalności dostępne jest rozwiązanie alternatywne (workaround)?
• jakie koszty poniosłaby organizacja gdyby dane wymaganie nie zostało spełnione?
• czy dane wymaganie zgodne jest z najlepszymi praktykami biznesowymi i kierunkiem rozwoju firmy?

Zgodnie z procedurą (IEEE) „IEEE standard for a software quality metrics methodology” (1998) do każdego z wymagań powinna zostać przypisana waga określająca jego znaczenie dla przedsiębiorstwa. Pełny obraz wymagań wyłania się, gdy z jednej strony zespół dysponuje zatwierdzoną przez wszystkich interesariuszy listą wymagań wraz z przypisanymi wagami, z drugiej zaś zestawieniem kosztowym ich realizacji sporządzonym przez wykonawcę/dostawcę.

Definicja ta jest celowo nieostra, ponieważ każde wymaganie  powinno zostać ocenione indywidulanie, w kontekście znaczenia dla procesów biznesowych i planów rozwojowych firmy, ale również krótko- (koszt wdrożenia) i długofalowych (koszt utrzymania) kosztów jego realizacji. W procesie załączania wymagań do kontraktu  uwzględnione powinny zostać również możliwości, jakie stwarza wdrażany system (tak na przykład niekiedy taniej i wydajniej jest połączyć centralny system ERP z wyspecjalizowanym system branżowym niż rozwijać nowe funkcjonalności w systemie ERP).

Realizacja wymagań nadmiarowych w dwojaki sposób utrudnia zachowanie wysokiego poziomu jakości finalnej systemu:

• Po pierwsze nie uwzględnia wpływu realizacji wymagań na jakość użytkową rozwiązania, czyli charakterystyk takich jak: wydajność, elastyczność, satysfakcja, bezpieczeństwo; prowadzi za to do budowy rozwiązań nadmiernie skomplikowanych, trudnych w obsłudze i kosztownych w utrzymaniu.
   
• W znacznej mierze wymagania nadmiarowe rozmijają się z predefiniowanymi możliwościami systemu, często określanymi jako „najlepsze praktyki”, co automatycznie wymusza stworzenie odpowiednich rozszerzeń kodu źródłowego. Rozszerzenia ze względu na mniejszą dojrzałość są znacznie bardziej narażone na generowanie błędów -  błędów za które, nie ponosi odpowiedzialności dostawca oprogramowania (są poza gwarancją), a po krótkim okresie wsparcia również i firma wdrożeniowa. Co więcej, rozszerzenia w znaczący sposób utrudniają również aktualizację systemu do nowszej wersji oraz wdrażanie nowych procesów. Wszystko to skutkuje zwiększonymi kosztami utrzymania⁴ i zmniejszeniem zadowolenia użytkowników.  

W skrajnym przypadku możemy mieć zatem doczynienia ze zwiększeniem kosztów przy jednoczesnym spadku jakości użytkowej. Zjawisko to opisuje Hugh Jack w książce „Engineer on a disk” (2001: 6). Przyjmuje on założenie, że wraz ze stopniem realizacji wymagań ponad pewien poziom określanym jako „optymalna jakość rozwiązania”, koszt rośnie nieproporcjonalnie do wartości dodanej dla klienta. W projektach wdrożeniowych tendencja ta jest znacznie pogłębiona i realizacja wymagań nadmiarowych może doprowadzić do spadku jakości przy jednoczesnym wzroście kosztów.

Rysunek 1. Relacja między kosztem i jakością
Źródło: Opracowanie własne na podstawie: Jack (2001: 6)

1.2 „rozumie się samo przez się” – określanie wymagań niesprecyzowanych.

Kolejną kategorię wymagań szkodliwych dla jakości systemu są wymagania niesprecyzowane, czyli takie, które nie zostały w precyzyjny sposób określone w żadnym z dokumentów, stanowią jednak istotny element wpływający na wykonanie procesu i powinny zostać w systemie odzwierciedlone. Klasycznym, przykładem takiego wymagania na podstawie realnego kontraktu wdrożeniowego jest np.: „system powinien spełniać wymagania polskiej księgowości”. Nie chodzi tu absolutnie o to, że jest to błędne wymaganie – bo w istocie system jak najbardziej powinien spełniać wymagania polskiej księgowości, problemem jest otwartość i nieprecyzyjność tego stwierdzenia, a co za tym idzie: brak możliwości oszacowania kosztów jego realizacji.

Przyjąwszy założenie o pełnej informacji zarówno zakres prac, ilość potrzebnych zasobów, jak również harmonogramu od początku do końca wdrożenia powinien być niezmienne. Tymczasem, w miarę postępu prac nad systemem, zawsze pojawiają się dodatkowe niesprecyzowane lub niewymienione uprzednio wymagania, co wpływa na zwiększenie kosztów, a przez to często również na i harmonogram.

Możliwie najbardziej dokładna i kompletna specyfikacja wymagań pozwala na zmniejszenie liczby funkcjonalności nieplanowanych, a w związku z tym na ograniczenie ryzyka powstania rozbieżności między planowanym i realnym budżetem oraz planowanym i realnym czasem realizacji projektu. Przy czym zarówno praktycy jak i opracowania naukowe zgodnie potwierdzają, iż precyzyjne określenie wszystkich wymagań wobec wdrażanego systemu jeszcze przed rozpoczęciem wdrożenia jest bardzo trudne -  o ile nie niemożliwe - stąd  „Na etapie podejmowania decyzji o wdrożeniu systemu ERP należy założyć, że prawdopodobnie nastąpi przekroczenie budżetu określonego w umowie. Klient decydujący się na tego typu wdrożenie powinien przyjąć dodatkową rezerwę na poziomie ok. 15 proc. budżetu całego projektu, na obsługę nieprzewidzianych zdarzeń (na przykład dostosowanie ergonomii systemu lub premie dla członków projektu za dobre wdrożenia). O istnieniu dodatkowej rezerwy budżetowej dostawca nie powinien wiedzieć” (Partyka i in. 2009: 8).

Kwestia wymagań niesprecyzowanych może stać się ogniskiem zapalnym konfliktów na wszystkich szczeblach hierarchii projektowej, gdyż ich realizacja niesie za sobą duże koszty, a równocześnie dokument specyfikacji wymagań nie określa jasno, po czyjej stronie leży ich pokrycie. Nieporozumienie zaostrza się w sytuacji, gdy zarówno firma wdrożeniowa, jak i klient nie posiadają budżetu rezerwowego na tego typu okoliczności, a rentowność projektu staje się zagrożona.

Rysunek 2. Relacja - specyfikacja wymagań a czynniki kluczowe
Źródło: opracowanie własne

Sytuację taką przedstawia rysunek 3. Zwiększone ryzyko utraty jakości pojawia się, gdy koszty realizacji wymagań projektowych przekraczają rezerwy finansowe projektu lub wychodzą poza harmonogram. W takiej sytuacji dla ratowania rentowności projektu, najłatwiej jest poświęcić elementy trudnomierzalne, nie widoczne na pierwszy rzut oka – jak na przykład obciąć budżet fazy testów lub realizować rozszerzenia najmniejszym możliwym kosztem nie uwzględniając ich późniejszego utrzymania lub dostosowania do zmieniających się procesów. Cytując Gary’ego Anthesa (1997: 76) „Kierownicy SI często poświęcają jakość zupełnie bez potrzeby w imię narzuconych samym sobie zbyt trudnych harmonogramów. Dzieje się tak, ponieważ łatwiej niż jakość jest zarządzać i mierzyć rzeczy namacalne jak terminy lub zamknięte fazy”.
 

1.3 Gotowość na zmianę

Zachowania z grupy „dokładnie tak jak chcemy/dokładnie tak jak jest” mają swoje źródło w fakcie, iż dokument specyfikacji wymagań to opis, czyli jedynie zarys kształtu procesów przed wdrożeniem nowego systemu ERP z ewentualnym uwzględnieniem planów rozwojowych firmy. Tymczasem każdy system ERP przygotowany jest do obsługi pewnych predefiniowanych procesów, określanych również jako najlepsze praktyki. Konsekwentne dążenie kierownictwa projektu do realizacji procesu w nowym systemie w dokładnie taki sam sposób, w jaki realizowane były one w starym, prowadzi po pierwsze do efektów opisanych w rozdziale poprzednim rozdziale, czyli utraty jakości użytkowej, po drugie do niewykorzystania potencjału, jaki stwarza dany system ERP. Cytując Marka Kuszneruka (2010) „Jeżeli chcemy wdrażać istniejące procesy w nowym systemie, to lepiej idźmy na browar. Wdrożenie SAP ma sens wtedy, kiedy robimy zmiany radykalne⁵”

Brak gotowości na zmianę prowadzi z jednej strony do obustronnego wzrostu kosztów wdrożenia, z drugiej niewykorzystania narzędzi i funkcjonalności dostępnych w systemie i w każdej chwili gotowych do użycia. Skalę tego zjawiska pomagają zobrazować badania analityczne przeprowadzone przez firmę Accenture: „Według Accenture przedsiębiorstwa nigdy nie wykorzystują aż 33 procent funkcjonalności posiadanego systemu ERP” (Partyka i in. 2009: 3).

Podsumowując – organizacja przystępująca do wdrożenia systemu ERP powinna być gotowa na zmiany, które mogą być zmianami radyklanymi, a których przeprowadzenie wymagać będzie od całej organizacji zwiększonych nakładów pracy. Dodatkowy wysiłek jaki musi ponieeść organizacja związany jest nie tylko z zaprojektowaniem i testami rozwiązania, ale również, a może przede wszystkim z wprowadzeniem zmiany w życie. Jak bardzo istotny jest to element wdrożenia obrazuje badanie przeprowadzone przez firmę SAP zgodnie z którym „62% największych trudności w projektach wdrożeniowych systemów ERP związane jest z ludźmi, przy czym największe znaczenie ma kwestia zarządzania zmianą” (SAP 2011: 90).

W samej organizacji potrzebna jest  zatem nie tylko duża świadomość swoich możliwości transformacyjnych, ale i świadomość ograniczeń, ponieważ, jeśli zmiany będą zbyt radykalne, wdrożenie może zupełnie się nie udać. Ciekawą próbę stworzenia metody pozwalającej na ocenę możliwości wdrożenia zmian opracowała firma BCG tworząc metodyką DICE⁶. DICE to akronim od mierzonych czynników, na podstawie oceny których szacuje się szansę powodzenia wdrożenia zmiany; są to kolejno: (D)uration  - czas trwania projektu, (I)ntegrity – zgranie i wydajność pracy zespołu; (C)ommitment – zaangażowanie w przeprowadzanie zmiany (na poziomie lokalnym i na poziomie wyższego kierownictwa); (E)ffort – dodatkowy wysiłek wymagany od pracowników firmy celem wdrażania zmiany.

Podsumowanie

Podsumowując, zbieranie wymagań to kluczowy etap przygotowań do wdrożenia, rzutujący następnie na cały proces implementacji systemu. Definicja wymagań rzutuje zarówno na jakość systemu jak i koszt oraz harmonogram projektu. Cytując Lindę Westfall (2005) „Bez jasnego obrazu, co do zakresu projektu, szacunki odnośnie harmonogramu i kosztu nie mogą być adekwatne⁷.”

Kluczowe dla sukcesu etapu zbierania wymagań okazują się kompetencje zespołu odpowiedzialnego za to zadanie. „Osoba, której zadaniem jest za zdefiniowanie wymagań bez względu na to czy to analityk biznesowy, analityk wymagań czy analityk systemowy odpowiedzialna jest za wydobycie wymagań od klientów, użytkowników i innych interesariuszy, ich analizę, transkrypcję w formie specyfikacji oraz komunikacje⁸.” (Westfall 2005) W tym celu w zespole zbierającym wymagania konieczne są następujące kompetencje:

• znajomości procesów biznesowych w firmie pozwalająca na ocenę i kompletację wymagań niesprecyzowanych;
• moc decyzyjna pozwalająca na weryfikacje i odrzucanie wymagań nadmiarowych;
• znajomość plantów rozwoju oraz świadomość możliwości transformacyjnych organizacji.  

Finalny dokument powinien zostać zatwierdzony przez wszystkich interesariuszy, z uwzględnieniem wag dla poszczególnych wymagań, dojrzałości organizacyjnej firmy i perspektywy możliwości technologii/systemu. Decyzja o realizacji wymagań w systemie powinna uwzględniać ich wpływ na jakość użytkową tworzonego rozwiązania. Z pewnym uproszczeniem możemy przyjąć, iż czynnikiem decydującym o wpływie wymagań na jakość systemu nie jest ich ilość, a kompletność, wewnętrzna spójność i zgodność procesami oraz planami rozwojowymi firmy.

Bibliografia:

Wiegers K. E. (2004) In Search of Excellent Requirements, Process Impact website: www.processimpact.com.
Brooks F.P. (1995 ) The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional.
Westfall, L. (2005) The What, Why, Who, When and How of Software Requirements. ASQ World Conference on Quality and Improvement Proceedings 59 s. 97-104.
IEEE (1998) IEEE standard for a software quality metrics methodology. Hoes Lane: The Institute of Electrical and Electronics Engineers, Inc.
Jack, H. (2001) Engineer on a disk. <http://claymore.engineer.gvsu.edu> .
Partyka, A., Nowak, F., Kuszneruk, M., Muszyński, P., Czeczuk, A., Rey, J., Sosulski, T. (2009) Największe ryzyka wdrożeń systemów ERP. Warszawa: K2 Consulting.
Anthes, G.H. (1997) Quality? What’s that? Computerworld, 31 (41), s. 75–76.
Robert B. Grady called "Practical Software Metrics for Project Management and Process Improvement."
SAP (2011a) ASA380 ASAP 7.1 Implementation methodology in details. Waldorf: SAP AG.
 

Przypisy:

¹ "If you don't get the requirements right, it doesn't matter how well you do anything else."

² "The hardest part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all of the interfaces to people, to machines to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later."

³ Kultura organizacji ma tu ogromne znacznie i wymagania nadmiarowe są szczególnie częstym zjawiskiem w firmach, w których powszechne jest wyszukiwane i piętnowania winnych – definiując więcej wymagań pracownicy po prostu zabezpieczają się przed zarzutem nie ujęcia czegoś – co potencjalnie mogłoby okazać się pomocne.

⁴ TCO – Total cost of ownership

⁵  cytat z wywiadu przeprowadzonego w 2010 roku

⁶ Na stronie BCG nieodpłatnie udostępniono kalkulator, który pozwala na wstępne wyliczenie za pomocą metody DICE szansy powodzenia realizowanego przedsięwzięcia http://dice.bcg.com/dice.html

⁷ Without a clear picture of that scope, estimates of the project schedule, cost and quality will be inaccurate.
W książce "Practical Software Metrics for Project Management and Process Improvement." Robert B. Grady (1992) opisuje ciekawą stworzoną przez siebie metrykę, zgodnie z którą długości fazy zbierania wymagań wynosi około 6-8% trwania projektu. Oznacza, że jeśli zbieranie wymagań zajęło między 6 a 8 dni to kierownik projektu może przyjąć, iż projekt potrwa około 100 dni. Z praktyki autora wynika, iż relacja ta może być lekko zaniżona i czas zbierania wymagań może wynosić nawet do 15 procent czasu trwania całości projektu. Proporcja ta dostarcza jednak bardzo ciekawej informacji o spójności wymagań wewnątrz organizacji. Jeśli zbieranie wymagań trwa zbyt długo oznacza to, że albo organizacja jest nieprzygotowana na wdrożenie nowego systemu (brak wiedzy, zła organizacja, wewnętrzna tarcia, sprzeczne interesy) albo w zespole za to odpowiedzialnym brak stosowanych kompetencji i mocy decyzyjnej.

⁸ The requirements analyst, also called the business analyst or system analyst, is responsible for  liciting the requirements from the customers, users and other stakeholders, analyzing the requirements, writing the requirements specification and communicating the requirements to development and other stakeholders.