Wyślij zapytanie Dołącz do Sii

W niniejszym artykule omówię zagadnienie wykorzystania podejścia Agile w tzw. procesach regulowanych na przykładzie branży farmaceutycznej i tzw. środowiska GxP (co to jest – o tym za chwilę).

Dlaczego w ogóle warto o tym pisać? Ponieważ jest to przykład bardzo udanego mariażu podejścia zwinnego, które, co do założeń (i praktyki!), „przedkłada działające oprogramowanie ponad dokumentację”, z wymogami narzuconymi przez Regulatora (w tym przypadku dla branży farmaceutycznej) na oprogramowanie wspierające procesy walidowane – ogólnie określane jako GxP.

Kilka słów o GxP

Cóż to zatem jest to GxP? To akronim od angielskiego Good „x” Practices, gdzie za „x” można podstawić: Clinical, Manufacturing, Distribution, Procurement, Laboratory etc.

Niech nas tylko nie zwiedzie fraza dobre praktyki, która mogłaby sugerować pewną dowolność stosowania się do tych wytycznych. Nic bardziej mylnego! Dla organizacji chcących funkcjonować w branży farmaceutycznej to bezwzględny wymóg.  Bardziej trafnym określeniem byłyby zatem wymogi regulacyjne niż dobre praktyki.

Typy systemów w środowisku GxP

W ramach środowiska GxP funkcjonować mogą różnorodne systemy. Żeby uzmysłowić Czytelnikowi, o jakich typach systemów mówimy, pozwolę sobie przywołać – wg informacji z Głównego Inspektoratu Farmaceutycznego – przykład odnoszący się tylko do systemów wykorzystywanych w dystrybucji produktów leczniczych:

  • Systemy magazynowo – księgowe wspierające procesy przebiegające w hurtowni (m.in. zamówienia, zakup, sprzedaż, reklamacje, wstrzymania, wycofania, zwroty, utylizacja).
  • Urządzenia skanujące dane z opakowań do systemu.
  • Systemy wspomagające zarządzanie transportem.
  • Systemy zarządzające kontrolą warunków otoczenia podczas przechowywania i transportu:
    • zapewnienie warunków przechowywania w całym łańcuchu dystrybucji,
    • zbieranie danych,
    • przechowywanie i archiwizacja danych.
  • Systemy elektronicznego zarządzania dokumentacją: tworzenie, dystrybucja, archiwizacja dokumentacji.

Jak łatwo wywnioskować, w przedsiębiorstwie farmaceutycznym jest wiele systemów, które zgodnie z regulacjami podlegają wymogowi walidacji. A to oznacza, że zastosowanie opisywanego tu modelu ma duży potencjał. Oczywiście – o ile chcemy podążać ścieżką Agile… ?

Jak zatem stosować Agile w procesach regulowanych?

W całym Modelu można wyróżnić trzy „fazy” (purystów językowych z góry przepraszam za pozostawienie nazewnictwa w oryginalnej angielskiej wersji):

Validation Planning

Faza obejmująca:

  1. Ocenę ryzyka (System GxP and risk assessment), w ramach której szczególny nacisk jest kładziony na identyfikację zagrożeń z perspektywy ich wpływu na końcowego użytkownika, przedsiębiorstwo oraz zgodność z obowiązującymi regulacjami (w tym: GxP).
  2. Ocenę danych przetwarzanych przez dany system (Data classification assessment) m.in. pod kątem ich zgodności z obowiązującymi regulacjami.
  3. Ocenę dostawcy oprogramowania (Supplier assessment) – jeżeli kupowane jest oprogramowanie, które następnie będzie użyte przy budowie naszego systemu.
  4. Plan walidacji (Validation plan), który określa podejście do walidacji i jej zakres.

Zakończenie powyższych prac nad fazą Validation Planning znajduje potwierdzenie w przejściu Bramki akceptacyjnej (Approval gate validation planning).

Design, Build and Test

Ta faza stanowi clue prac rozwojowych. Tutaj również podejście zwinne dochodzi mocno do głosu. Kluczowe jej komponenty to:

  1. Przygotowanie Product Backlog, zawierającego nawiązania do wymogów regulacyjnych (znowu GxP). Tutaj następuje priorytetyzacja user stories, również pod kątem wymogów regulacyjnych.
    • Co ciekawe, product backlog nie musi mieć postaci dedykowanego dokumentu. Może być ujęty w formie zapisów elektronicznych w narzędziu wspierającym niniejszy proces, zwalidowanym do zastosowania w środowisku regulowanym (o tym narzędziu napiszę na końcu tego postu).
  2. Wykonanie Sprintów (Sprint execution), zgodnie z przyjętą metodyką agile.
    • Warto nadmienić, że w każdym sprincie – zgodnie z omawianym modelem – musi uczestniczyć przedstawiciel quality lub compliance lub zespołu walidacyjnego, co ma na celu zapewnienie bieżącego nadzoru nad działaniami o charakterze walidacyjnym.
    • W wyniku każdego sprintu powstają zapisy walidacyjne, które muszą być odpowiednio przechowywane, zabezpieczone i dostępne (vide dedykowane narzędzie wspierające). Będą one stanowiły podstawę do przyszłego zezwolenia do produkcyjnego wdrożenia.
  3. Sformułowanie Sprint Backlog.
  4. Opracowanie Architektury Systemu (System architecture or system description) – która wynika z technicznych uwarunkowań. Tutaj zostanie określone miejsce wdrażanego systemu w istniejącym w firmie krajobrazie IT (IT landscape), zaadresowane zostaną kwestie infrastruktury, połączeń sieciowych, baz danych, systemów operacyjnych etc.
  5. Opracowanie szczegółowych User Stories, czyli doprowadzenie historyjek do stopnia szczegółowości umożliwiającego rozpoczęcie prac przez zespół deweloperski.
    • Również tutaj wystarczy, gdy user stories przyjmą formę zapisów elektronicznych w narzędziu wspierającym niniejszy proces (nie ma konieczności przygotowywania dedykowanych dokumentów).
  6. Jeżeli Plan Walidacji to przewiduje (vide ustalenia z fazy Planowania walidacji) – konieczna jest Ocena ryzyka dla User Stories (User story risk assessment). Głównym obszarem troski jest tutaj bezpieczeństwo pacjentów (przecież docelowo mówimy o produkcji leków), jakość produktów i integralność danych. Wyniki tych działań mogą mieć przełożenie na kształt i formę testów, na wdrożenie punktów kontrolnych o charakterze technicznym, proceduralnym lub związanych z bezpieczeństwem, a także wskazywać na ewentualne szczególne potrzeby szkoleniowe.
  7. W pewnych przypadkach (np. konieczność przygotowania interfejsu) może zaistnieć potrzeba opracowania Specyfikacji technicznej (Design specification).
    • Podobnie jak wcześniej, to opracowanie może przyjąć formę zapisów w narzędziu wspierającym.
  8. Przygotowanie kodu i przegląd kodu / Testy systemowe (Code review/unit testing) – działania koncentrujące się na weryfikacji i zapewnieniu poprawności kodu od strony czysto technicznej.
  9. Weryfikacja przygotowanego kodu następuje iteracyjnie w trakcie dedykowanych wydarzeń wynikających z przyjętej metodyki zwinnej: Iterations/Sprint reviews/Daily Standups
  10. Na etapie Planowania testów (Test planning) wybierane są user stories do najbliższej iteracji testów. Na tym etapie precyzowane jest podejście do testów (odpowiedzialności, obsługa błędów, kryteria akceptacji etc.) – o ile nie jest to zdefiniowane generycznie na wcześniejszym etapie. Tu również może zapaść decyzja o ewentualnych testach regresyjnych.
    • Podobnie jak kilkukrotnie wcześniej, również tutaj plan testów – zamiast dedykowanej dokumentacji – może przyjąć formę scenariuszy testowych (referujących do testowanych user stories) umieszczonych w zwalidowanym narzędziu wspomagającym.
  11. Jeżeli zakres sprintu wymusza zmiany w infrastrukturze, wykonywana jest Ocena infrastruktury (Infrastructure qualification/installation verification).
  12. Po realizacji wszystkich powyższych (wymaganych) punktów następuje Bramka gotowości do testów dla bieżącego sprintu (Approval gate sprint).
  13. Po pomyślnym przejściu powyższej bramki wchodzimy w etap Testów, zgodnie z Planem testów (Verification of user stories/regression testing).
    • Zwalidowane narzędzie pomocnicze może stanowić tu dużą pomoc przy procesie testowania, w szczególności, przy rejestracji wyników tych testów.
  14. Po zakończeniu testów mamy już zweryfikowany Pakiet oprogramowania (Shippable software), który – po złożeniu z pozostałymi pakietami – będzie składał się na pierwsze wdrożenie. Ma ono miejsce w trzeciej, ostatniej fazie Modelu:

Validation Reporting

  1. Zanim nastąpi wdrożenie rozwiązania, konieczny jest przegląd istniejących Procedur operacyjnych i szkolenia (SOPs adaption and training). Aktualizacji mogą wymagać zarówno procedury biznesowe jak i techniczne.
  2. Przed wdrożeniem wymagany jest również Raport z testów i informacje nt. wdrożenia (Test summary report/release note).
    • Tradycyjnie już, takie informacje możemy szybko uzyskać z dedykowanego narzędzia wspierającego.
  3. Kolejnym krokiem jest właściwe Wdrożenie oprogramowania na środowisko produkcyjne (Deployment) i przekazanie biznesowi do wykorzystania i zespołowi technicznemu do utrzymania.
  4. Kluczowym z punktu widzenia wymogów regulacyjnych jest Raport z walidacji (Validation report), który prezentuje wynik wykonanych działań walidacyjnych i adresuje ewentualne odchylenia.
  5. Krokiem zamykającym cały proces jest przejście Bramki decyzyjnej (Approval gate validation reporting) potwierdzającej skuteczność przedmiotowego wdrożenia i jego zgodność z obowiązującymi regulacjami.

Cały Model jest poniżej przedstawiony w formie poniższego schematu:

Model zastosowania Agile w procesach regulowanych
Ryc. 1 Model zastosowania Agile w procesach regulowanych

Dedykowane oprogramowanie

Warto na koniec zauważyć, że powyższy model może, a nawet powinien być wspierany przez Dedykowane oprogramowanie, które umożliwia zastosowanie podejścia zwinnego przy jednoczesnym rygorystycznym spełnieniu wymogów walidacyjnych. Zostało to zresztą kilkukrotnie wskazane w powyższym tekście (wyróżnione turkusową czcionką).

Aby to narzędzie spełniało stawiane przed nim zadania, samo musi zostać poddane walidacji. Co ważne, proces walidacji narzędzia musi być przeprowadzony w organizacji, w której narzędzie ma funkcjonować. Jest to stan specyficzny dla tej organizacji (inna organizacja musi przeprowadzić sobie „swoją” walidację).

Walidacja narzędzia oznacza – jako minimum – możliwość rejestracji danych o zmianach w wybranych zapisach, w tym: rejestrację daty, czasu i autora tychże zmian (tzw. audit trail). I oczywiście przechowywanie ich przez okres wymagany prawem.

Dobrym przykładem takiego narzędzia są produkty firmy Atlassian: Jira & Confluence.

Kilka słów podsumowania

Podsumowując, doświadczenie wielu firm stosujących ten model (lub zbliżony) wskazuje jasno, że dostarczanie zmian w oprogramowaniu w sposób efektywny kosztowo i czasowo nie koliduje z zastosowaniem się do wymogów Regulatora w zakresie walidacji systemów informatycznych. Zastosowanie dedykowanych narzędzi wspierających usprawnia ten proces i czyni go łatwiejszym do zarządzania.

Uwagi końcowe

  1. Opisany Model może być zastosowane do dowolnego podejścia Agile.
  2. Proces wdrażania zmian przebiega wg zbliżonych reguł, co implementacja inicjalna systemu opisana powyżej, ale jest nieco prostszy (nie wszystkie elementy mają tu zastosowanie).
  3. To opracowanie jest jedynie próbą zwięzłego przedstawienia modelu pracy w trybie zwinnym w środowisku regulowanym. Potencjalny Zainteresowany jego wdrożeniem musi oczywiście sięgnąć do źródła.

Źródło

Guidance on the use of Agile in a GxP environment. BioPhorum Operations Group Ltd.

***

A jeśli chcesz poznać inne artykuły naszych Agilowych ekspertów, zachęcamy do lektury: Co nas motywuje i jak motywować innych?, Model fazowy – jak usystematyzować Retrospektywę? oraz Retrospektywa – mój sposób na nudę.

Ocena:
Autor
Avatar
Tomasz Michalski

PM z wieloletnim doświadczeniem w kilku branżach i metodykach projektowych. Obecnie z przyjemnością odkrywa uniwersum metodyk zwinnych ? Prywatnie opiekun psa i dwóch kotów, ogrodnik. Lubi biegać, pływać i jeździć na rowerze (prawie triathlon ?). I czytać (!). Od dekady jest początkującym adeptem jogi.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany.

Może Cię również zainteresować

Pokaż więcej postów

Bądź na bieżąco

Zapisz się do naszego newslettera i otrzymuj najświeższe informacje ze świata Sii.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Get an offer

Natalia Competency Center Director

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

APLIKUJ APLIKUJ

Join Sii

Paweł Process Owner

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?