Pobierz System Kanban w administracji publicznej i więcej Publikacje w PDF z Economia tylko na Docsity!
System Kanban w administracji publicznej 421
toMasz orDysiński
Wydział Ekonomiczny w Szczecinie Wyższa Szkoła Bankowa w Poznaniu
System Kanban w administracji publicznej
1. Wstęp
Współcześnie ekonomia oraz sprawy związane z szeroko rozumianym zarzą‑ dzaniem i organizacją jasno wskazują informację jako kluczowy zasób. Środki produkcji jak ziemia, praca czy kapitał straciły na znaczeniu. Sukces dowolnej organizacji zależy obecnie od bazy informacji lub wiedzy, którą wykorzystują jej pracownicy. Drugim ważnym czynnikiem związanym z otoczeniem organizacji jest totalne zachwianie stabilności – przechodząc na ekonomię ukierunkowaną na klienta, stabilność znika z powodu stale zmieniających się potrzeb czy też gustów. Jest to powodem zmiany sposobu działania firm/organizacji, gdy bycie zwinnym (z ang. agile ) daje możliwość dopasowywania się do aktualnych po‑ trzeb rynku. Czynniki te powodują dość burzliwe dyskusje w gronie osób zarzą‑ dzających na temat tego, co można zrobić, aby organizacja przetrwała w tak niestabilnych czasach. Jednym z potencjalnych rozwiązań jest przekształcenie tradycyjnej orga‑ nizacji w organizację wirtualną. Technologia ICT zaprzęgnięta do procesu pozyskiwania oraz przetwarzania danych i informacji, a następnie do wydo‑ bywania wiedzy i zarządzania nią może poprawić sytuację. Problemem w tej materii stała się opinia użytkowników (uzasadniona), że tego typu narzędzia są bardzo zaawansowane technologicznie, a to przekłada się na wysoki poziom skomplikowania procesu korzystania z nich. Zarządzanie informacją i metody odkrywania wiedzy wymagają z reguły dość dużych umiejętności z zakresu in‑ formatyki. Często także sam etap wprowadzania danych do tego typu systemów (np. w aplikacjach typu CRM) zabiera więcej czasu niż cały proces.
422 Tomasz Ordysiński
Dodatkowym zjawiskiem, które wykształciły sieci społeczne (np. Facebook), jest efektywna, niczym niewymuszona komunikacja. W praktyce biznesu i organizacji pojawił się tzw. wymiar social (tłumaczenie tego słowa jako „społeczny” nie oddaje znaczenia). Tak intensywnie swego czasu badana i piętnowana niechęć do dzielenia się wiedzą nagle w części społeczeństwa w wieku 16–25 lat przestaje istnieć, a prze‑ cież grupa ta to przyszli pracownicy. Naturalnym procesem stało się zamieszczanie informacji, problemów dotyczących spraw organizacji i ich rozwiązań w sieciach (samo zjawisko jest dużym problemem dla pracodawców z uwagi na ujawnianie spraw wewnętrznych), dla pracownika jest to po prostu sposób na radzenie sobie w sytuacji, gdy procedury lub przepisy nie obejmują zaistniałego problemu. Propozycja autora niniejszego artykułu zakłada zmianę podejścia do zarzą‑ dzania w organizacjach. Każda z nich musi stawić czoło niestabilnym czasom, w których inicjatywy (nowa usługa, nowy produkt, każde zapytanie klienta itd.) powinny być postrzegane jako unikatowe i z reguły ograniczone czasowo. Te dwie cechy powodują, że codzienna działalność operacyjna organizacji nabiera bar‑ dziej charakteru projektu niż procesu. Co więcej, takie projekty angażują z reguły wiele osób, więc zarządzanie i postępy w realizacji powinny być transparentne i dostępne dla każdego zainteresowanego pracownika. Istnieje wiele metodyk zarządzania projektami, jednak w tym przypadku swoje zastosowanie znajdują te z grupy „zwinnych” (ang. agile ). Celem tego artykułu jest prezentacja wykorzy‑ stania podejścia Kanban oraz jego implementacji w komunikacji i zarządzaniu inicjatywami projektowymi w organizacji.
2. Kanban w procesie produkcji
System Kanban utożsamia się obecnie z implementacją filozofii produkcji „na czas” (ang. just in time – JiT), którą wdraża się w celu kontroli i minimalizacji zapasów oraz odpadów. Zapoczątkowana w latach 40. ubiegłego stulecia idea JiT rozwinęła się w ramach działalności koncernu Toyota jako filozofia stałych usprawnień w procesie produkcji. Słowo kanban pochodzi z języka japońskiego i w wolnym tłumaczeniu oznacza szyld/wywieszkę – coś, co w bardzo zwięzłej formie przekazuje dużo informacji. W koncernie Toyota pierwotnie stosowano karty Kanban do oznaczenia różnych pojemników zawierających materiały stosowane w procesie produkcji, aby jasno komunikować, które materiały należy na bieżąco uzupełniać. Obecnie stosuje się wiele wariantów kart Kanban, także w postaci elektronicznych tablic.
424 Tomasz Ordysiński
i odbiorcom) bardzo dobry wgląd w obecne i przyszłe stany zamówień oraz w całość łańcucha dostaw^4. Są one integrowane z rozwiązaniami klasy ERP. Daje to możliwość optymalnego zarządzania łańcuchem dostaw w czasie rze‑ czywistym, włącznie z wysyłaniem sygnałów o zapotrzebowaniu (w metodyce Kanban pulling signals ) do dostawców. Sygnały te zawierają zbiór informacji dotyczących punktu dostawy, liczebności partii, numeru cyklu produkcyjnego oraz innych dostarczanych w czasie rzeczywistym. Umożliwia to stałe śledze‑ nie takich miar, jak: rzeczywista długość cyklu w porównaniu z zaplanowaną, wzorce zużycia, efektywność dostawcy w zakresie dostaw na czas, dokładność uzupełnień „pustych pojemników”, zapełnienie magazynów (jeżeli istnieją) czy też starzenie się zapasów. Silne powiązanie docelowego konsumenta z produ‑ centem dzięki zastosowaniu Kanbana skutkuje powstaniem procesu produkcji umożliwiającego sprzedaż opartą na wartości produktu, a nie na cenie^5. Moduły systemów zintegrowanych opartych na metodyce Kanban zostały wdrożone i są dostępne praktycznie u wszystkich dużych producentów tych rozwiązań: JD Edwards firmy Oracle, IFS, Infor ERP LN, SAP ERP czy też Microsoft Dynamics^6.
3. Kanban w produkcji oprogramowania
Zalety podejścia opartego na metodyce Kanban zauważono także w zakresie zarządzania projektami IT. Inżynieria oprogramowania i produkcja aplikacji/ systemów jest jedną z wiodących branż gospodarki w XXI w. Podobnie jednak jak w przypadku produkcji, metodyki zarządzania projektami informatycznymi rozwinięte w XX w. nie są do końca wystarczające w tak zmiennym otoczeniu. Planowanie długoterminowe, stabilność oczekiwań klienta oraz warunków rynkowych można uznać za elementy obecne w przeszłości także w tej branży. Większość obecnych projektów ICT zakłada okres realizacji krótszy niż rok, a presja ze strony klienta na jak najszybsze uzyskanie wymaganych funkcjonal‑ ności jest bardzo wysoka. Uproszczony rozwój metodyk zarządzania projektami
(^4) O. Maříková, E‑kanban and its Practical Use , http://stc.fs.cvut.cz (data odczytu 20.03.2013). (^5) T.R. Cutler, Examining Lean Manufacturing Promise , http://www.softwaremag.com (data odczytu 20.03.2013). (^6) J. Anderson, Lean software development , Microsoft Corporation 2011, www.leankanba‑ nuniversity.com (data odczytu 20.04.2013).
System Kanban w administracji publicznej 425
można opisać jako powstanie i wykorzystanie modelu kaskadowego, następnie spiralnego (np. RUP), extreme programming (np. RAD), a wreszcie obecnej gamy metodyk określanych jako „zwinne”^7.
Rysunek 1. Metodyki zarządzania projektami Źródło: http://www.crisp.se/file‑uploads/Kanban‑vs‑Scrum.pdf.
Niewątpliwie jedną z najbardziej popularnych metod zwinnych jest Scrum. Jest to pewien wzorzec (struktura) stosowany do zarządzania rozwojem dużych produktów IT, który powstał na początku lat 90. ubiegłego stulecia. Scrum nie jest procesem ani techniką budowy produktów – stanowi raczej pewien wzorzec stosowania procesów oraz technik. Reguły Scruma łączą razem zdarzenia, role, artefakty, zarządzając relacjami i interakcjami pomiędzy nimi^8. Ogólne założenia metodyki są dość proste, a jej sedno sprowadza się do trzech głównych ról:
- właścicieli produktu, którzy określają, co powinno zostać wytworzone w ciągu następnych 30 dni projektu (lub okresu krótszego),
- zespołów projektowych, które zajmują się wytworzeniem wyspecyfikowanych funkcjonalności w założonym okresie oraz zeprezentowaniem swoich osią‑ gnięć po tym czasie; na podstawie prezentacji właściciele produktu określają kolejne zadania na następny okres;
- Scrum mastera, który jest odpowiedzialny za efektywne procesy w ramach danych okresów zadaniowych (tzw. sprintów), stałe poprawianie procesu oraz pomoc zespołom projektowym. Sam projekt zarządzany według Scruma jest realizowany iteracyjnie, w ra‑ mach sprintów nie dłuższych niż miesiąc. Na początku danego sprintu zespół projektowy zobowiązuje się do dostarczenia określonej funkcjonalności (ca‑ łość trzymana jest w backlogu projektu). W czasie sprintu zaimplementowane
(^7) K. Schwaber, J. Sutherland, The Scrum Guide Developed and sustained , http://www.scrum. org (data odczytu 25.03.2013). (^8) What is Scrum Methodology? , http://www.mountaingoatsoftware.com (data odczytu 12.05.2013).
System Kanban w administracji publicznej 427
Równolegle do Scruma rozwinęła się idea adaptacji Kanbana do zarządza‑ nia produkcją oprogramowania. Koncepcja mająca swoje korzenie w produkcji fizycznego produktu znalazła swoje miejsce także w projektach IT. Na pierwszy rzut oka różnica między metodyką Scrum a Kanban wydaje się minimalna, ale przy uważnej analizie widać wyraźne różnice w tych podejściach^10. Stanowisko takie zajmuje większość developerów oprogramowania, którzy bardzo precyzyj‑ nie dzielą się na: zwolenników podejścia Scrum (jako jedynej słusznej metodyki zwinnej w projekcie IT), „wizjonerów” podejścia Kanban, którzy jasno widzą zalety wynikające z limitów pracy (ang. Work In Progress – WIP, transparentno‑ ści procesu itp.), oraz osoby „ze środka” (świadome plusów i minusów każdego z podejść i umiejętnie wykorzystujące metody w odpowiednich okolicznościach). Według drugiej i trzeciej grupy, Kanban jest naturalnym krokiem w ewolucji metodyk zarządzania projektem^11. Zdanie autora niniejszej pracy pokrywa się z założeniem konieczności rozumienia różnic w obu podejściach i stosowania tej z technik, która lepiej wspomoże projekt w danych uwarunkowaniach. Obie metody zawierają dość miękkie założenia, co powoduje, że można je łatwo adaptować. Scrum jest nieco mocniej strukturalizowany (jeżeli tego terminu można użyć w przypadku meto‑ dyki zwinnej), ale np. w porównaniu z Kanbanem wymusza stosowanie iteracji w projekcie. Kanban jest metodą znacznie bardziej liberalną^12.
Tabela 1. Porównanie metod Scrum i Kanban
Scrum Kanban Zakłada się iteracje procesu. Iteracja jest opcjonalna – przebieg może być sterowany zdarzeniami. Przyporządkowanie zespołu do konkretnego sprintu.
Przyporządkowanie jest opcjonalne.
Prędkość realizacji jest główną miarą planowania i poprawy procesu.
Podstawową jednostką planowania i poprawy procesów jest czas realizacji. Wskazanie zespołów interfunkcjonalnych. Zespoły interfunkcjonalne są opcjonalne. Zespoły specjalistów są dozwolone. Podział projektu musi być tak wykonany, aby poszczególne części zostały wykonane w ciągu jednego sprintu.
Nie ma narzuconych reguł podziału projektu.
(^10) K. Scotland, Kanban Thinking , http://availagility.co.uk (data odczytu 14.06.2013). (^11) St. Denning, op.cit. (^12) D.J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business , Blue Hole Press, Washington 2010, s. 13.
428 Tomasz Ordysiński
Scrum Kanban WIP jest wyznaczany pośrednio (przez plan sprintu).
WIP wyznaczany bezpośrednio.
Estymacja konieczna. Estymacja opcjonalna Nie można dodać nowego elementu w trakcie sprintu.
Można dodać nowe zadanie w każdym momencie, jeżeli pozwala na to WIP. Backlog sprintu jest w posiadaniu konkretnego zespołu.
Tablica Kanban może być dzielona przez wiele zespołów i członków zespołu. Wyznaczone role: właściciel procesu, menadżer sprintu, zespół.
Brak wskazanych ról.
Priorytety zadań w backlogu. Priorytety są opcjonalne. Tablica Scrum jest czyszczona po każdym sprincie.
Tablica Kanban jest stała i dostępna przez cały czas realizacji projektu. Źródło: opracowanie własne.
Założenia Kanbana w przypadku rozwoju i produkcji oprogramowania można zaprezentować w trzech punktach:
- wizualizacja przepływu pracy:
- podział projektu na zadania, a zadań na czynności; zapisanie każdego elementu w postaci fiszki i umieszczenie na tablicy Kanban;
- zastosowanie nazwanych kolumn w celu opisania etapów przepływu procesu i zamieszczenie fiszek w odpowiedniej z nich, ilustrujących poziom zaawansowania prac;
- określenie limitów pracy w toku ( Work in Progress – WIP) dla każdego z wy‑ różnionych etapów (kolumn), co określa, ile zadań może być realizowanych maksymalnie;
- pomiar czasów realizacji (średni czas całkowitej realizacji zadania), optyma‑ lizacja procesu w celu minimalizacji czasów^13. Work in Progress w podejściu Kanbana jest stosowany do kontrolowania przepływu pracy w procesie/projekcie. Umożliwia on hamowanie lub przyspie‑ szanie działań w procesie przez zwiększanie limitów zadań na danym etapie. Pozwala to na działania proaktywne rozwiązujące problemy zastojów, wąskich gardeł w momencie pojawienia się wstępnych symptomów, a nie po zaistnieniu problemu^14.
(^13) M. Heusser, How the Kanban Method Changes Software Engineering , http://www.cio.com (data odczytu 14.03.2013). (^14) H. Kniberg, Kanban vs Scrum. A practical guide , http://www.crisp.se (data odczytu 26.06.2013).
430 Tomasz Ordysiński
Czy te zadania wchodzą w skład procesu, czy też stają się już projektem? Z uwagi na bardzo szybko zmieniające się otoczenie organizacji linia dzieląca te dwa pojęcia zaczyna się rozmywać, a procesy zaczynają nabierać cech projektów. Przy założeniu zastosowania podejścia procesowego drogą do doskonalenia jest zarządzanie przez jakość (ang. Total Quality Management – TQM). Wspiera to stopniową optymalizację realizowanych działań, ale w praktyce bardzo często kończy się na etapie wprowadzania np. norm ISO oraz bogatej dokumentacji.
PROCES
KANBAN
Przekazanie do produkcji
Przekazanie do produkcji
Informacja do działu produkcji
Przyjęto do realizacji
Odrzucono realizację
Dział obsługi klienta
Informacja do klienta
Zlecenie 4
Weryfikacja zamówienia
Weryfikacja zamówienia
Zlecenie 2
Przyjęcie zamówienia
Przyjęcie zamówienia
Zlecenie 3
Poinformowanie klienta o decyzji
Poinformowanie klienta o decyzji
Zlecenie 1
Rysunek 3. Transformacja podejścia procesowego na Kanban Źródło: opracowanie własne.
Zarówno w przypadku procesów, jak i projektów kluczem, jak to zostało wspomniane we wstępie artykułu, jest dostęp do aktualnej informacji. Dla dzia‑ łań rozciągniętych w czasie oprócz informacji stanowiących „bazę wejściową”
System Kanban w administracji publicznej 431
kluczowe są te, które powstają w trakcie realizacji. Tutaj niektóre z badań wskazują, że do powstania jednej strony oficjalnego dokumentu w projekcie/ procesie (np. specyfikacji zamówienia w procedurze przetargowej) liczba tekstu komunikacji (najczęściej w postaci maili zawierających uzgodnienia lub wersje próbne dokumentu) jest ponad 10‑ krotnie większa. W przypadku strukturali‑ zowanych metodyk zarządzania projektami, jak np. PRINCE 2, przygotowano jasne zalecenia odnośnie do postępowania z dokumentacją projektową oraz jej udostępnianiem zainteresowanym członkom zespołu projektowego. Należy jednakże zauważyć, że dotyczy to już gotowych ustaleń, a nie tez roboczych, dyskusji i innych elementów stanowiących kontekst finalnej decyzji. Zastoso‑ wanie Scruma poprawia nieco sytuację, gdyż wszelkie informacje konieczne do działania znajdują się na danej tablicy. Problemem jest jednak „czyszczenie” tablicy po każdym sprincie, co powoduje brak dostępu do zamieszczonych tam pierwotnie informacji oraz całości projektu. Metodyka Kanban jest odpowiedzią na problemy związane z komunikacją i dostępem do informacji w czasie trwania projektu. Zakłada się tu jedną tablicę reprezentującą wszystkie etapy projektu oraz przypisanie całości informacji (oraz jej utrzymanie przy danej fi szce do końca projektu, a nawet i potem jako zbiór tzw. dobrych lub złych praktyk).
To do On going Done^ Zadanie N Informacja 1 Informacja 2 Informacja 3 Informacja 4 Informacja 5 …
Rysunek 4. Zarządzanie informacją w Kanbanie Źródło: opracowanie własne.
Celem artykułu jest prezentacja założeń implementacji zarządzania informa‑ cją w projekcie administracyjnym za pomocą metodyki Kanban. W przypadku administracji zarządzanie projektem jest de facto zarządzaniem informacją, bo przecież produkt w 99 % przypadków jest skodyfikowaną informacją, np. de‑ cyzją na podanie petenta. Do sprawnego funkcjonowania tego mechanizmu
System Kanban w administracji publicznej 433
- trzymanie całej informacji dotyczącej zadania w jednym miejscu (kar‑ teczka),
- możliwość komunikacji uczestników projektu w ramach zadań, tablicy oraz całej struktury,
- wielopoziomowość układu – tablica tablic/karteczka jest tablicą,
- możliwość definiowania dat końcowych zadania,
- dołączanie dokumentów (centralne repozytorium dokumentów z wersjono‑ waniem),
- możliwość śledzenia zmian w wybranych zadaniach + powiadamianie o zmia‑ nach, wiadomościach itp.,
- definiowanie poziomów dostępu do tablicy/karteczek,
- filtrowanie karteczek na poziomie tablicy i wszystkich tablic,
- możliwość definiowania WIP‑ów. Platformę rozwiązania stanowią produkty firmy Microsoft (MS SQL Server oraz MS Sharepoint), których zaletą jest łatwość instalacji i zrozumienia śro‑ dowiska przez użytkownika końcowego. Interfejs samego Sharepointa został zmodyfikowany dokładnie według zaleceń metodyki Kanban i odzwierciedla tablice, listy (etapy), zadania itd. Produkt zaimplementowano już w kilku fir‑ mach z dużym sukcesem.
6. Podsumowanie i kierunki dalszych badań
Artykuł prezentuje zalety oraz stosowalność metodyki Kanban w wielu dzie‑ dzinach – od początkowej sfery produkcji do zarządzania miękkimi projektami z zakresu administracji. Obecnie dostępne powszechnie narzędzia zarządzania projektami oparte na Kanbanie są głównie przeznaczone do produkcji opro‑ gramowania. Jednak ich adaptacja do sfery administracyjnej lub każdej innej, w której transparentność, prostota oraz przewidywalność pełnią kluczową rolę, będzie powodować wytworzenie nowej jakości. Obecne rozwiązania informa‑ tyczne charakteryzują się dużym skomplikowaniem, nakładem pracy w trakcie wprowadzania danych o procesie oraz brakiem naturalnych interfejsów do sa‑ mego monitorowania oraz zarządzania procesem. Bez przejrzystości procesu jego uczestnicy nie są w stanie zrozumieć swojej roli i znaczenia (np. w przypadku opóźnienia) w całości łańcucha. Te braki eliminuje Kanban. Implementacja utwo‑ rzona w ramach współpracy pomiędzy nauką a biznesem usuwa z organizacji komunikację opartą na mailach. Ten model się już po prostu nie sprawdza – czas
434 Tomasz Ordysiński
na zastąpienie go podejściem opartym na trzymaniu 100 % informacji przy danym zadaniu przez cały okres jego realizacji. Zmniejsza to wewnętrzne koszty firmy dzięki zaoszczędzeniu czasu poświęcanego na poszukiwania pośród 1000 maili tych, które są ważne w przypadku danej sprawy, oraz uniknięciu konieczności wdrożenia nowych osób do projektu (np. z powodu choroby pierwotnie odpo‑ wiedzialnego pracownika). Rozwiązanie to powoduje rewolucję w komunikacji wewnętrznej oraz zewnętrznej (np. w sytuacji kooperowania z innymi firmami przy danym projekcie). Wirtualizacja organizacji w tym przypadku jest w 100 % stosowana w praktyce. Założenia i funkcjonalności produktu są dalej rozwijane, a kierunki dalszych prac nad rozwiązaniem skupiają się w trzech zakresach:
- integracji narzędzia z systemami ERP (z uwagi na przyjęte technologie pierw‑ szym etapem będzie podłączenie pod MS Dynamics oraz Navision),
- module statystyk do badania efektywności realizowanych projektów/proce‑ sów,
- module „odkrywania wiedzy” do badania prawidłowości realizowanych projektów/procesów.
Bibliografia
- Anderson D.J., Kanban: Successful Evolutionary Change for Your Technology Business , Blue Hole Press, Washington 2010.
- Womack J.P., Jones D.T., Roos D., The Machine That Changed the World: The Story of Lean Production , Free Press, US 2007.
Źródła sieciowe
- Anderson J., Lean software development , Microsoft Corporation 2011, www. leankanbanuniversity.com (data odczytu 20.04.2013).
- Cutler T.R., Examining Lean Manufacturing Promise , http://www.softwaremag. com (data odczytu 20.03.2013).
- Denning St., What Exactly is Agile? Is Kanban Agile? , http://www.forbes.com (data odczytu 22.03.2013).
- Edwards G., Weighing the Disadvantages of the Kanban System , http://www. brighthubpm.com (data odczytu 20.03.2013).
- Heusser M., How the Kanban Method Changes Software Engineering , http://www. cio.com (data odczytu 14.03.2013).
