Audyt wewnętrzny – od audytu tradycyjnego do nowoczesnego na przykładzie organizacji i wdrożenia audytów zwinnych (cz. III)

Założenia Agile

Druga grupa metodyk – tzw. metodyki zwinne, adaptacyjne, elastyczne (Agile Project Management, APM) – jest oparta na działaniach tworzących wartość, eliminowaniu działań niepotrzebnych, np. administracyjnych. W ramach metodyk zwinnych można wskazać metodykę Scrum[3]. Niekiedy zalicza się do nich także Lean i Kanban[4]. Na potrzeby artykułu przyjęto w uproszczeniu taką właśnie klasyfikację.

Ogólne założenia Agile powstały w 2001 r. i zostały spisane w postaci tzw. Manifestu Agile (Manifestu Zwinnego Wytwarzania Oprogramowania[5], dalej Manifest). Powstał on w USA jako efekt prac 17 reprezentantów[6] nowych metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym. Manifest stanowi punkt wyjścia wszystkich metod zwinnych, początkowo był stosowany na potrzeby rozwoju metod wytwarzania oprogramowania, później coraz powszechniej w innych sferach działalności przedsiębiorstwa. W myśl jego założeń[7] nowe metody programowania mają kłaść większy nacisk na poniższe obszary:

• ludzi i interakcje – zamiast na procesy i narzędzia,
• działające oprogramowanie – zamiast na szczegółową dokumentację,
• współpracę z klientem – zamiast na negocjacje umów,
• reagowanie na zmiany – zamiast na realizację założonego planu.

Elementy wypisane po prawej stronie (niepogrubione) są wartościowe, ale większą wartość mają te, które wypisano po stronie lewej (pogrubione).

Mając na względzie wskazane obszary, w Manifeście sformułowano 12 zasad, którymi miano się kierować w trakcie wytwarzania oprogramowania (patrz ramka poniżej).

Sformułowane zasady pracy podkreśliły aspekt bieżącej współpracy ze zleceniodawcą oraz poddawania ciągłemu procesowi oceny – zarówno przez wykonawcę, jak i zleceniodawcę – tego, czy cele są osiągane i czy odzwierciedlają bieżący stan wiedzy zespołu pracującego nad rozwiązaniem. Stanowiło to przeciwwagę dla podejścia klasycznego, opartego na modelu kaskadowym realizacji prac (Waterfall Model). W procesie wytwarzania oprogramowania model kaskadowy zakładał pewne iteracyjne podejście[8] do wykonywania prac. Kolejna faza projektu mogła być rozpoczęta dopiero po zakończeniu poprzedniej. W założeniu model ten był właściwy w sytuacji, gdy cel, wymagania i zakres prac zostały jasno i bezsprzecznie dookreślone przez strony umowy.

Istotnymi ograniczeniami modelu kaskadowego były jego wrażliwość na zmiany, które mogły wystąpić w trakcie trwania projektu, oraz konieczność czekania na końcową wersję produktu. Niejednokrotnie, wskutek długotrwałego procesu realizacji, produkt końcowy rozmijał się z oczekiwaniami zleceniodawcy, z uwagi na jego niedopasowanie do obecnych, nowych realiów. Metodyki Agile wychodziły naprzeciw tym ograniczeniom i znalazły odzwierciedlenie m.in. w podejściach Scrum, Kanban, Lean. W dalszej części artykułu przedstawiono w zarysie podejście Scrum jako przedstawiciela metodyk Agile.

Metodyka Scrum

Scrum to ramy postępowania przydatne w procesach wytwarzania, dostarczania i utrzymywania złożonych produktów[9]. Metodyka jest oparta na empirycznym podejściu do podejmowania decyzji, czyli bazuje na doświadczeniu. Według jej twórców[10] Scrum jest łatwa do zrozumienia, ale trudna do opanowania.

Teoria Scrum opiera się na trzech zasadach:

• zasada przejrzystości jest pojmowana przez pryzmat transparentności całego procesu wytwórczego, począwszy od jednakowego zrozumienia przez wszystkich celu procesu, jego poszczególnych etapów, a skończywszy na poczynionych założeniach co do uznania danego etapu czy też całego procesu za zakończony; wszyscy uczestnicy powinni się zatem porozumiewać przy zastosowaniu tej samej terminologii, uzgodnionych definicji kluczowych kwestii organizacji i przebiegu procesu/dostarczanych produktów itp.,
• zasada inspekcji umożliwia częsty przegląd stopnia realizacji prac i wykrycie nieprawidłowości; częstotliwość przeglądów nie może być zbyt duża, aby nie wpływała negatywnie na postęp prac; inspekcji poddaje się tzw. artefakty scrumowe, zwykle w odniesieniu do tzw. wydarzeń scrumowych (Scrum Events): planowanie Sprintu, codzienny Scrum, przegląd Sprintu i retrospektywa Sprintu (będzie o tym mowa dalej),
• zasada adaptacji jest powiązana z zasadą inspekcji – jeśli w trakcie inspekcji zostaną stwierdzone pewne niedopuszczalne odstępstwa od przyjętych założeń, należy niezwłocznie podjąć czynności korygujące, aby uniknąć negatywnego wpływu na dalsze etapy prac.

Filozofia metodyki Scrum jest oparta na pięciu podstawowych wartościach, którymi powinni się kierować wszyscy współpracownicy (zob. rysunek).

W założeniu dany projekt scrumowy jest realizowany przez Zespół Scrumowy (Scrum Team), w którego skład wchodzą: Właściciel Produktu, Zespół Deweloperski oraz tzw. Scrum Master.

Właściciel Produktu (Product Owner) to osoba, która jest odpowiedzialna za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego. Zarządza tzw. Backlogiem Produktu[11]. Cały Zespół Scrumowy musi respektować jego decyzje. Może on zlecać wykonanie zadań Zespołowi Deweloperskiemu, ale pozostaje za nie odpowiedzialny.

Zespół Deweloperski (Developers) jest interdyscyplinarny, krosfunkcjonalny, tj. złożony ze specjalistów różnych dziedzin, niezbędnych do wykonania prac. W założeniu zespół ten jest samoorganizujący się i wystarczający do zrealizowania zadań. Nie powinien być duży, aby zapewnić zwinność działania (charakter Agile).

Scrum Master to osoba odpowiedzialna za promowanie i wdrażanie założeń metodyki Scrum do prac zespołu, by zmaksymalizować wytwarzaną wartość (produkt).

Aby w pełni zrozumieć metodykę Scrum, należy poznać jej podstawowe pojęcia, takie jak artefakty scrumowe (Scrum Artifacts). Są to kluczowe elementy zwiększające przejrzystość i zrozumienie procesu. Można do nich zaliczyć wspomniany wcześniej Backlog Produktu, Backlog Sprintu czy tzw. przyrost.

Backlog Produktu (Product Backlog) jest listą wszystkich cech, funkcji, wymagań, ulepszeń i korekt, które reprezentują zmiany wprowadzone w przyszłych wydaniach produktu[12]. Nie stanowi zamkniętego katalogu i zmienia się (rozbudowuje) w trakcie trwania projektu, np. na skutek informacji zwrotnych dostarczanych przez użytkowników, zmian w wymaganiach biznesowych, technologii. Odpowiada za niego Właściciel Produktu, który uzgadnia zmiany z Zespołem Deweloperskim.

Backlog Sprintu (Sprint Backlog) to zbiór elementów Backlogu Produktu składających się na etap procesu realizacji, tzw. Sprint. Obrazuje zespół czynności niezbędnych do wykonania przez Zespół Deweloperski, aby zrealizować cel danego etapu projektu (czas realizacji Sprintu jest zwykle ograniczona do 1 mies.). Mając na względzie ciągły proces doskonalenia, Backlog Sprintu powinien zawierać przynajmniej jedno istotne usprawnienie zidentyfikowane podczas poprzedniego przeglądu prac, czyli tzw. retrospektywy Sprintu (Sprint Retrospective). Zarządza nim Zespół Deweloperski, który może dokonywać jego aktualizacji oraz usuwać niepotrzebne, wcześniej zaplanowane działania, aby jak najlepiej dopasować się do rzeczywistości. Zespół monitoruje na bieżąco (codziennie) postęp prac i szacuje prawdopodobieństwo osiągnięcia celu Sprintu. Odbywa codzienne spotkania (zwykle krótkie, 15-minutowe), które pozwalają zaplanować dzień pracy i wykonać szybką inspekcję prac wykonanych poprzedniego dnia (tzw. codzienny Scrum, Daily Scrum).

Przyrost (Increment) jest sumą wszystkich elementów zakończonych podczas Sprintu i poprzednich przyrostów. Istotne jest, aby stanowił namacalny efekt prac, np. produkt gotowy do użycia na danym etapie. Musi być zatem ukończony według przyjętej na wstępie procesu definicji ukończenia, jednakowo rozumianej przez Zespół Scrumowy.

Przeglądu Sprintu (Sprint Rewiev) dokonują Zespół Scrumowy i interesariusze produktu końcowego. Wspólnie ustalają, co można wykonać w następnej kolejności, aby zoptymalizować wartość docelowego produktu.

Postęp prac monitoruje Właściciel Produktu. Monitoring jest przeprowadzany cyklicznie, zwykle podczas przeglądu Sprintu; porównując plan z wykonaniem (efektami poprzednich Sprintów), Właściciel Produktu jest w stanie oszacować postęp pracy i możliwość jej ukończenia zgodnie z celem i w założonym czasie. Przebieg procesu według metodyki Scrum przedstawiono na rysunku.

Mankamenty tradycyjnego audytu wewnętrznego

W przeważającej mierze koncentruje się on na dostarczaniu informacji ex-post. Oznacza to, że większość prac jest wykonywana w mniej lub bardziej odległej perspektywie czasowej od zaistniałych zdarzeń będących przedmiotem analiz. Na podstawie zdarzeń historycznych są wyciągane wnioski i formułowane ew. zalecenia na przyszłość. Skomplikowanie analizowanych kwestii oraz ich wnikliwość pociągają za sobą nieodłącznie wydłużenie czasu realizacji, przy zwykle ograniczonych zasobach. Czas realizacji niejednokrotnie wydłuża się w wyniku oczekiwania na dostarczenie przez audytowanych dokumentów czy wyjaśnień.

Tradycyjny audyt wewnętrzny działa w usystematyzowany sposób, któremu sprzyja wspominany wcześniej model kaskadowy. Można wyróżnić następujące po sobie fazy prowadzenia zadania: planowanie, gromadzenie dokumentacji, analiza dokumentacji, pozyskiwanie dodatkowych wyjaśnień, raportowanie. Istotnie determinują one czas realizacji zadania. Niezwykle istotna dla przebiegu prac i wyciągania prawidłowych wniosków, ale i czasochłonna jest faza planowania zadania. Ponieważ wachlarz zlecanych prac cechuje duża rozpiętość tematyczna i trudno oczekiwać od audytorów znajomości wszystkich zagadnień biznesowych, czas wdrożenia się przez zespół audytowy w obszar analizowanych zagadnień może być długi.

Kolejnym czynnikiem istotnie wydłużającym czas realizacji zadania jest oczekiwanie na niezbędną do analiz dokumentację czy wyjaśnienia audytowanych. Jest to czynnik w zasadzie niezależny od audytorów – nacisk audytu na przyśpieszenie tej fazy zadania jest zwykle mocno ograniczony, gdyż strona audytowana oprócz obsługi audytu, co jest zazwyczaj dla niej kwestią drugorzędną, musi się skupić w pierwszej kolejności na wypełnianiu bieżących zadań biznesowych.

Istotnym czynnikiem, wynikającym z charakteru prowadzenia audytu w modelu tradycyjnym, jest także konieczność dokumentowania każdego etapu prac. Zwykle powinno to nastąpić przed kolejną fazą – raportowania. Praktyka wskazuje jednak, że niektóre z elementów dokumentacji zadania są kompletowane w fazie raportowania, a niektóre po niej (na ogół dotyczy to jednak kwestii pozaraportowych).

W podejściu tradycyjnym audyt wewnętrzny jest postrzegany bardziej jako kontroler niż doradca – wynika to z atrybutu niezależności oraz wskazywania nieprawidłowości w działaniu.

Audyt zwinny – czy to może się udać

Konieczność przeprowadzenia zmian w audycie wewnętrznym jest w głównej mierze determinowana zmianami w otoczeniu, ich rosnącą częstotliwością, szybkim rozwojem technologii oraz oczekiwań zleceniodawców zadań audytowych w kwestii dostarczania coraz szybszej informacji zwrotnej, częściej również nie tej historycznej (ex-post), ale wyprzedzającej (ex-ante). Organizacje kładą coraz większy nacisk na ograniczanie kosztów działalności.

Powierzone audytowi wewnętrznemu zadania realizują zwykle zorganizowane zespoły audytowe. Takie podejście ma zapewnić lepsze, pełniejsze spojrzenie na audytowany obszar i formułowanie ocen końcowych na podstawie wewnątrzzespołowych konsultacji. Zadania realizowane przez zespoły audytowe, choć dotykają różnych sfer działalności, przebiegają według wskazanych uprzednio faz[13]. Noszą znamiona zadań projektowych, jakie są prowadzone w ramach działalności biznesowej.

Z tego też względu również w odniesieniu do audytu można próbować stosować metodyki Agile. Przykładowo filozofia działania metodyki Lean skupia się na: dostarczaniu tej wartości, ograniczaniu strat procesowych niedostarczających tej wartości, ciągłym procesie ulepszeń. Gdyby więc spojrzeć na funkcjonowanie audytu wewnętrznego przez pryzmat postawionych przez metodykę Lean celów, można dostrzec potencjał zmian w tym obszarze.

W przypadku działań audytowych możliwe obszary usprawnień dotyczyłyby powstających strat związanych z: czasem zapoznawania się z badanym obszarem; czasem oczekiwania na dokumenty, informację zwrotną, wyjaśnienia; wykonywaniem zbędnych czynności dokumentacyjnych czy też dostarczaniem produktu końcowego nieprzysparzającego wartości lub przysparzającego jej zbyt późno. Obszary strat można pogrupować na 7 typów (patrz tabela).

Zastosowanie metodyki Lean do wskazanych obszarów powstających strat audytowych, w szczególności dążenie do ich ograniczenia lub wyeliminowania, umożliwiłoby osiągnięcie statusu Agile Audit. Istotną kwestią jest, jak tego dokonać. Pomocne mogą się okazać metodyka Scrum i Kanban oraz iteracyjne podejście w prowadzeniu zadań.

Podejmowane działania mogłyby obejmować[14]:

1. Organizację codziennych krótkich (np. 15-minutowych) spotkań scrumowych, tj. spotkań zespołu zmierzających do ustalenia: co zostało zrobione od wczorajszego spotkania scrumowego, co planuje się zrobić dziś, do następnego spotkania, jakie są przeszkody w wykonaniu tych czynności. Funkcję Scrum Mastera pełniłaby osoba odpowiedzialna za prowadzenie zadania – kierownik zadania audytowego; Scrum Master podejmowałby czynności zmierzające do niwelacji wskazanych przeszkód, tak aby ułatwić pracę całego Zespołu Scrumowego (audytowego).

2. Stworzenie kart Kanban do zobrazowania postępów prac audytowych. Przykładową kartę Kanban pokazano na następnej stronie.

3. Stworzenie wykorzystywanych w programowaniu zwinnym tzw. wykresów burndown – jest to graficzne przedstawienie pozostałych do wykonania w projekcie prac względem upływu czasu (np. w ramach danego etapu prac – Sprintu) oraz szacowany czas pracy do zakończenia projektu (tu zadania audytowego) – przykład przedstawiono na rysunku poniżej.

4. Organizację wewnętrznych spotkań podsumowujących audyt z naciskiem na identyfikację wąskich gardeł i sposobów usprawnień w przyszłości.

Ramowy przebieg całego zadania audytowego, przy adaptacji metodyki Scrum, mógłby wyglądać następująco. Byłoby ono realizowane przez Zespół Scrumowy (tu audytowy). Cel zadania audytowego oraz główne czynności audytowe umożliwiające jego osiągnięcie byłyby wstępnie zdefiniowane przy udziale zleceniodawcy zadania i tworzyłyby swoisty Backlog Produktu (tu program zadania).

Całe zadanie audytowe zostałoby podzielone na etapy (Sprinty) obejmujące czynności cząstkowe do wykonania w ramach danego etapu. Sprinty te byłyby w sposób częstotliwy (wielokrotny) weryfikowane i w razie potrzeby modyfikowane, z uwzględnieniem osiągnięcia celu sprintu. Ew. modyfikacja programu zadania, na skutek nowych, pojawiających się w trakcie Sprintu i nieznanych uprzednio okoliczności, wymagałaby aprobaty zleceniodawcy zadania – Właściciela Produktu.

Uwzględniając iteracyjne podejście, po zakończeniu danego Sprintu, Właściciel Produktu otrzymywałby informację o postępie prac, w postaci raportów/informacji cząstkowych zadania. Wnioski byłyby formułowane na podstawie zakończonych czynności, a audytowana strona mogłaby na bieżąco, w miarę możliwości, wdrażać (przyjmować do realizacji) rekomendacje.

Po zakończeniu wszystkich Sprintów zadania powstałby raport końcowy będący ramowym podsumowaniem programu zadania. W przypadku zadań typowo doradczych Zespół Scrumowy mógłby się składać nie tylko z audytorów, lecz także z delegowanych do zadania pracowników operacyjnych z obszaru biznesu.

Przykładowy ramowy przebieg zadania audytowego (z adaptacją metodyki Scrum) przedstawiono na rysunku poniżej. Dla porównania na kolejnym rysunku pokazano ramowy przebieg realizacji tradycyjnego zadania audytowego według modelu kaskadowego.

Istotną różnicą w porównaniu z Agile (modelem Scrum) jest brak iteracyjnego podejścia do wykonywania zadania i angażowania/cyklicznego informowania audytowanych o postępie prac. W rezultacie w modelu tradycyjnym rośnie ryzyko braku spełnienia oczekiwań zleceniodawcy (strata czasu i poniesienie zbędnych kosztów).

Zalety i wady rozwiązania opartego na Agile

Można wskazać następujące zalety stosowania rozwiązań opartych na metodykach Agile:

• zmniejszenie ryzyka niespełnienia oczekiwań zleceniodawcy; większe i częstsze angażowanie audytowanej strony biznesowej/zleceniodawcy zwiększa jego satysfakcję z finalnego produktu,
• większe zaangażowanie audytowanej strony biznesowej/zleceniodawcy wpływa korzystnie na skrócenie czasu pozyskiwania wiedzy, interpretacji faktów, formułowania prawidłowych rekomendacji, przez co zmniejsza koszty procesu,
• zwiększona (bieżąca) współpraca z audytowaną stroną biznesową/zleceniodawcą zadania wpływa pozytywnie na wzajemny przepływ wiedzy,
• szybsze odnotowanie korzyści z przeprowadzonego zadania (na bieżąco wdrażane rekomendacje),
• wzrost produktywności zespołu audytowego,
• zwiększona motywacja zespołu audytowego.

Jak każde modelowe rozwiązanie, podejście Agile w audycie ma również wady:

• brak możliwości zastosowania do wszystkich realizowanych przez komórkę audytu zadań – w szczególności dotyczy to zadań o charakterze śledczym, typowo kontrolnych, gdy interakcja i współpraca z audytowanym mają drugorzędne znaczenie lub nawet nie są wskazane,
• brak celowości zastosowania w przypadku zadań szybkich, krótkich,
• brak zrozumienia i/lub możliwości wystarczającego zaangażowania się strony audytowanej w bieżące prace audytowe,
• brak możliwości bieżącej realizacji formułowanych zaleceń/rekomendowanych działań,
• ograniczone możliwości rozwiązywania problemów przez Auditor-in-charge (Scrum Mastera),
• brak wystarczającego zrozumienia podejścia Agile w organizacji.

Podejmując decyzję o zastosowaniu metodyk Agile i ich zakresie, należy więc każdorazowo rozważyć plusy i minusy takiego rozwiązania.

Podsumowanie

Audyt wewnętrzny na przestrzeni lat podlegał zmianom dostosowującym do wymagań otoczenia. Obserwowana dzisiaj rewolucja w przemyśle kolejny raz wymusza takie zmiany. Nieuniknione jest ukierunkowanie rozwoju audytu w stronę obszaru IT i nowych technologii. Coraz częściej bowiem mówi się o rozwoju sztucznej inteligencji (AI) i internecie rzeczy (Internet of Things, IoT). Są to zjawiska, które w niedalekiej przyszłości istotnie wpłyną na funkcjonowanie przedsiębiorstw. W szczególności będą wymuszać wypracowanie zdolności do szybkiej zmiany i dostosowania do nowych wymogów runku, dostawców, klientów itp.

W konsekwencji jeszcze bardziej pożądane będzie dostarczanie szybkiej i bieżącej informacji w wielu dziedzinach, a co za tym idzie – wzrosną oczekiwania co do zwinności przedsiębiorstw. Znacznie bardziej istotna będzie informacja ex-ante niż ex-post. Z pewnością będą to również determinanty wymuszające strategiczną zmianę w podejściu i organizacji audytu wewnętrznego.

Agile – w przeciwieństwie do dotychczasowego podejścia opartego na konieczności realizacji „sztywnego”, założonego planu – w swoich założeniach (Manifeście) jest nastawiona m.in. na szybkie (zwinne) reagowanie na zmiany i współpracę z klientem. Kładzie również większy nacisk na efekt niż na proces dochodzenia do niego i jego udokumentowanie. Cechy te oraz źródło powstania Agile (środowisko IT) skłaniają do stwierdzenia o słuszności jej zastosowania jako elementu strategicznego rozwoju audytu wewnętrznego. Przez „strategiczny rozwój” rozumie się podjęcie już dziś działań w kierunku dostosowania do rysujących się tendencji zmian w otoczeniu w perspektywie kilku lat (antycypowanie trendów przyszłości).