Jak powinno przebiegać wdrożenie systemu IT w firmie produkcyjnej i co ma do tego Toyota

jak-poprawnie-wdrozyc-system-it

Rozmawiałeś pewnie z innymi zaprzyjaźnionymi firmami, z kolegami po fachu albo po prostu przeczytałeś jak wyglądają wdrożenia systemów IT. Najczęściej te opowieści nie są optymistyczne.

Na prezentacji i początkowych rozmowach wszyscy zapewniają, że wszystko da się zrobić, ze każde wymaganie jest lub będzie zaimplementowane. Wdrożenie nie będzie kosztować fortuny i zajmie kilka tygodni. Słowem „Będziesz Pan zadowolony” 🙂

Zaczynacie analizę – czyli dostawca przyjeżdża, siada z Twoimi ludźmi i rozmawia o tym jak wygląda sytuacja obecnie. Przegląda procesy, dokumenty i wykorzystywane systemy. Później daje popuścić Wam wodze fantazji i słucha czego oczekujecie. Na tej podstawie przygotowuje dokument Analizy który często liczy ponad 100 stron. Czytacie, zgłaszacie uwagi. Dostawca przedstawia Wam wycenę i harmonogram. Podpisujecie umowę i zaczynacie wdrożenie.

Co się dzieje dalej? Jeżeli wszystko idzie zgodnie z planem to kończycie projekt w zakładanej funkcjonalności, w zakładanym czasie i przy założonym budżecie.

Najczęściej jednak któreś z tych trzech rzeczy – budżet, czas, funkcjonalność – jest poważnie naruszona.

Ludzie nie są dobrzy w przewidywaniu przyszłości i szacowaniu czasu trwania poszczególnych zadań. Pomyślcie jak często zadanie które macie wykonać wymyka się Wam spod kontroli. Myślicie że wykonacie je w godzinę, a tymczasem po 3 godzinach jesteście dopiero w połowie.

Podejście tradycyjne (kaskadowe) – Analiza, Wycena, Wdrożenie

To jest nadal najczęściej wykorzystywany sposób wdrażania systemów IT. Polega na tym że całość wdrożenia dzielimy na fazy i do kolejnej możemy przejść dopiero jak zakończyliśmy poprzednią. Fachowo nazywa się to podejściem kaskadowym.

model-kaskadowy-wdrazania-systemow-IT

Jak wygląda model kaskadowy

Co to oznacza w normalnym życiu? To że nie możemy rozpocząć wdrażania jeżeli wcześniej nie została wykonana Analiza, Projekt, Programowanie czy Testowanie. Każdy z tych etapów musi być skończony w całości i zatwierdzony. Jakiekolwiek zmiany na którymkolwiek etapie powodują że trzeba przejść cały cykl od nowa.

Można to porównać do typowej linii produkcyjnej która nie stosuje żadnej zasady Lean. Linia produkuje sprawnie i teoretycznie najbardziej efektywnie. Gotowy produkt jest jednak znany na końcu całego procesu. Wtedy też kontrolowana jest jego jakość, gdzie koszty ewentualnej poprawy są największe.

wady-podejscia-kaskadowegoWady podejścia tradycyjnego

  • Dokument analizy to głównie tekst i skomplikowane diagramy – gdy próbujemy spisać jak dokładnie ma wyglądać nasz wymarzony system to trzeba go dokładnie opisać. Jako że najczęściej taki dokument stanowi załącznik do umowy z wykonawcą, to będzie on zawierał jak najwięcej tekstu który co tu dużo mówić – chroni w dużej mierze wykonawcę. Bardzo rzadko firmy zamieszczają projekty ekranów które są dużo prostsze do wyobrażenia.
  • Wiele wersji dokumentu – jako że analiza powstaje na przestrzeni pewnego czasu, to kolejne doprecyzowania wiążą się z kolejnymi wersjami dokumentu. Najczęściej dostawcy spisują to w formacie Word i przesyłają do Was e-mailowo. Spróbujcie później odnaleźć ostatnią wersję lub łatwo zobaczyć co się zmieniło w 100 stronicowym dokumencie.
  • Ogromny zakres dokumentu – nie dość że konieczne jest przeczytanie setek stron analizy (przy wdrożeniach większych systemów dokument analizy liczy grubo powyżej 100 stron), to jeszcze trzeba wyłapać wszystkie zależności które występują pomiędzy poszczególnymi funkcjonalnościami. Pamiętajcie też że swoim podpisem przy Umowie oświadczacie że to co jest w Analizie jest tym co zamawiacie.
  • Brak możliwości przewidzenia wszystkiego – przystępując do wdrożenia ciężko jest przewidzieć czy ujęliśmy wszystko na czym nam zależy. Z jednej strony nie chcemy specyfikować wszystkiego co nam przyjdzie do głowy, bo to znacznie zwiększa koszt całego wdrożenia. Z drugiej strony nie możemy zapomnieć o drobnych szczegółach które mogą być ważne.
  • Zmiany w Waszej firmie i jej otoczeniu – Analiza jest pisana w danym momencie. Można w niej przewidzieć wiele sytuacji których powinien obsługiwać zamawiany system. Ale nikt nie jest w stanie przewidzieć wszystkiego. Twoja firma się cały czas rozwija, każdy dzień może przynieść nowy pomysł na jej organizację, na zmiany w procesach. Nowy klient może przynieść potrzebę wdrożenia nowego sposobu produkcji którego nie ująłeś w analizie. Wyobraź sobie że wdrożenie trwa już 3 miesiące, Twój dostawca IT zaczyna pracować nad kolejnym etapem z Analizy, a Ty widzisz że on nie będzie Ci potrzebny bo zmienił się Twój proces produkcyjny. Zgodnie z umową musisz zapłacić zarówno za rzecz która Ci już nie jest potrzebna (z pierwotnej Analizy) jak i zamówić nowy proces do zamodelowania we wdrażanym Systemie
  • Twoi ludzie nie są programistami – najlepszy specjalista w Twojej firmie może nie mieć wiedzy i wyobraźni aby zrozumieć wszelkie zależności opisane w Analizie. Najczęściej przy pierwszej oddanej wersji systemu IT okazuje się że to nie jest to co on chciał. Dostawca IT odpowiada na to „Ale proszę Pana, rozmawialiśmy z Panem i spisaliśmy to w Analizie którą Pan podpisał”
  • Każda zmiana zakresu wymaga aneksu umowy – jako że zakres jest wpisany do umowy to jego zmiana wymaga jej aneksowania. To z kolei oznacza wymianę maili, włączanie prawnika po obu stronach i czas.
  • Najczęściej koszt jest przeszacowany – dostawca chce się zabezpieczyć przed wszystkimi niespodziankami, a Ty chcesz wpisać do umowy i zakresu wszystkie możliwe potrzeby które przyjdą Ci do głowy.
fiasko-podcza-wdrozenia-systemow-IT

Tak często wyglądają wdrożenia systemów IT

watpliwe-dobre-strony-podejscia-kaskadowegoCzy są jakieś dobre strony?

Najczęściej słyszę takie argumenty za obroną takiego podejścia:

  • W podejściu standardowym można uznać że każdy rozumie co trzeba zrobić, ile za to trzeba zapłacić i na kiedy to będzie wykonane. Jest na to wszystko umowa, którą wszystkie zainteresowane strony podpisały.
  • Ty jako właściciel/zamawiający możesz czuć się komfortowo – ponieważ zawsze możesz wyegzekwować od dostawcy to do czego zobowiązał się w umowie.
  • Z kolei dostawca będzie zabezpieczony przed Twoim zmieniającymi się potrzebami. Zakres jest jasno wpisany w Analizę będącą załącznikiem do umowy.
  • Mamy cały projekt rozpisany na pięknym wykresie Gantt-a – wiemy więc kiedy dokładnie skończymy.

Doświadczenia setek tysięcy projektów IT pokazują jednak coś innego – że to są tylko najczęściej założenia które zostają brutalnie zweryfikowane w trakcie trwania projektu. Model kaskadowy nie jest najlepszym modelem do zarządzania wytwarzaniem i wdrażaniem skomplikowanych systemów IT. Zbyt duża niepewność i zmienność otoczenia nie jest w żaden sposób wspierana w tym podejściu.

Bardzo dobrym przykładem jest tutaj projekt Sentinel wykonywany przez FBI. Miał on za zadanie zniesienie papierowych archiwów w FBI i wdrożenie w pełni cyfrowego systemu zarządzania codzienną pracą agencji.
Pierwsze próby podjęto po atakach na 9/11, kiedy FBI nie było w stanie nawet wysłać elektronicznie zdjęć zamachowców i musiało korzystać z fax-ów czy CD-ROM-ów przesyłanych przez noc. Wtedy Kongres zatwierdził 170 mln USD na projekt Virtual Case File. W 2004 projekt jednak zaczął umierać z powodu nietrafionych wymagań funkcjonalnych, opóźnień w projekcie i złego zarządzania. Do 2006 roku koszty wzrosły już do 600 mln USD !
Następnie firma Lockheed Martin otrzymała zlecenie na nowy projekt – Sentinel. Budżet na dwie pierwsze fazy wynosił 306 mln USD. Do 2010 roku projekt był wykonany tylko w połowie i koszt wzrósł o kolejne 100 mln USD.
W 2010 nowy dyrektor IT w FBI postanowił że całe oprogramowanie powstanie wewnątrz FBI z pominięciem zewnętrznych dostawców. Zredukował zespół z 400 do 45 osób , budżet ustalił na kwotę tylko 30 mln USD i zobowiązał się do dostarczenia całego projektu w 12 miesięcy. Udało się to dzięki zastosowaniu zarządzania projektem w modelu SCRUM – czyli odrzuceniu wszystkich poprzednich, tradycyjnych sposobów. Tych, które wcześniej kosztowały USA prawie 1 mld USD.

Co Toyota ma wspólnego z wytwarzaniem i wdrażaniem oprogramowania?

Wielu z Was na pewno zna historię Toyoty i to jak bardzo zmieniła rzeczywistość produkcyjną. Jej podejście do systemu zarządzania produkcją i wprowadzenie TPS (Toyota Production System) zakładało ciągłe doskonalenie i eliminację marnotrawstwa. Liczy się doskonalenie ludzi i procesów a nie tylko praca nad zwiększeniem wydajności.

toyota-model-factory-line

Przykład Kanbanu w zakładach Toyoty

W systemie tradycyjnym pracownicy wykonywali wymagające małego myślenia powtarzalne czynności produkcyjne. Nie przejmowali się kontrolą jakości – wady wykryte w samochodach były poprawiane dopiero na końcu linii produkcyjnej. Teoretycznie wydajność pracowników była bardzo wysoka – czasy jednostkowe mierzone na każdym stanowisku można było optymalizować, linia nie miała przestojów (które są przecież bardzo kosztowne).

W Toyocie pomyślano jednak że przecież to pracownicy wiedzą najlepiej co należy poprawić w samochodzie nad którym pracują na danym odcinku linii. Dlaczego nie skorzystać z tej wiedzy? Dlaczego nie naprawiać problemu od razu w momencie jego wystąpienia? Przecież usunięcie go od razu będzie wielokrotnie tańsze niż czekanie do końca procesu.

Na tej podstawie powstały tzw. „Zwinne metodyki wytwarzania oprogramowania” (tak, wiem – trudne wyrażenie ;). W skrócie jest to zestaw zasad jak należy prowadzić projekty IT, także dotyczące wdrażania systemów w firmach (np. ERP czy MES).

Scrum jako metodyka zarządzania projektami informatycznymi powstał w 1995 roku, jednak dopiero w ostatnich latach widać prawdziwą eksplozję jej stosowania. Nie tylko zresztą w przemyśle informatycznym ale np. w szkolnictwie czy wojsku.

Jak się to ma zatem do wdrażania systemów IT? Oto podstawowe zasady:

  • Polegamy na ludziach – konieczne jest zaufanie – zarówno do Twoich ludzi jak i do dostawcy. Ludzie chcą pracować dobrze, chcą się rozwijać, chcą mieć dobre narzędzia do pracy. Dostawca chce zrealizować wdrożenie jak najlepiej, bo chce mieć zadowolonego klienta do którego będzie mógł zaprosić kolejnych na wizytę referencyjną. Proste tłumaczenie ale w wielu firmach o tym się zapomina.
  • Zmiana jest ciągle wpisana w proces – to jest chyba największa różnica w stosunku do standardowego procesu wdrażania oprogramowania. Od początku zakładamy że rzeczy mogą i będą się zmieniać. Zakres wdrożenia, priorytety, potrzeby, otoczenie, współpracujące systemy. Wszystko może ulec zmianie i trzeba być na to przygotowanym. Zaakceptuj to ale miej narzędzie do sprawowania nad tym kontroli.
  • Lepiej zmieniać coś od razu niż czekać – skoro widzimy że coś nie działa lub jest zbędne to nie ma sensu tego kontynuować aby zaspokoić zapisy umowy. Jeżeli funkcjonalność którą wyspecyfikowałeś i zamówiłeś nie sprawdza się w rzeczywistości – zmień to od razu. Nie czekaj na koniec wdrożenia.
  • Działające oprogramowanie ponad specyfikacja – na koniec każdego etapu uzgodnionego z dostawcą, użytkownicy mają dostać działające oprogramowanie. Czy to będzie drobna funkcjonalność czy większy element – najważniejsze żeby dało się z tym pracować i zobaczyć to w codziennym użytkowaniu. Dopiero wtedy widać co należy poprawić – specyfikacja na papierze nigdy tego nie odda w pełni.
  • Wizualizacja procesów – w tym podejściu zarówno klient jak i dostawca mają narzędzia pokazujące na bieżąco gdzie znajduje się wdrożenie. Wszystko po to aby była pełna przejrzystość dla wszystkich uczestników i aby jak najszybciej odkrywać problemy. Dostawca nie jest już czarną skrzynką która po podpisaniu umowy wraca za pół roku z finalną wersją rozwiązania.
  • tablica-kanban-przyklad

    Wizualizacja postępu przy pomocy tablicy kanban

  • Eliminacja marnotrawstwa – spędzanie czasu nad pięknymi dokumentami analizy, dopieszczanie wykresu Gantt z harmonogramem projektu który już po tygodniu jest nieaktualny czy czekanie z poprawianiem błędów na koniec projektu – to wszystko marnowanie czasu i pieniędzy z punktu widzenia wdrożenia. Najważniejsze jest działające oprogramowanie realizujące realne potrzeby Twojej firmy i Twoich ludzi. Idealnie wyglądający harmonogram załączony do umowy tego nie gwarantuje.
  • Współpraca pomiędzy wszystkimi zainteresowanymi – Ty i Twój dostawca od teraz to jeden zespół. Jesteście zarówno zainteresowani tym aby wdrożyć oprogramowanie, ale też jesteście za to odpowiedzialni. Podejście typu „Płacę to wymagam” nie ma tutaj zastosowania. Sam system nie zmieni Twojej firmy jeżeli Twoi ludzie nie będą zaangażowani w jego wdrażanie i zmiany w firmie z nim związane.

Jak można lepiej wdrażać oprogramowanie? Podejście zwinne (Lean, Agile lub Scrum – różnie jest nazywane)

Poniżej znajdziesz po kolei jak może wyglądać wdrożenie dowolnego systemu informatycznego (np. Zarządzania produkcja) przy zastosowaniu lekkiej metodyki Scrum. Na temat samego SCRUM-a można znaleźć wiele informacji w sieci, np. SCRUM w 59 minut)

Etap przygotowania

Zanim przystąpicie do pracy z Twoim dostawcą konieczne jest wykonanie wszelkich prac przygotowawczych. Na pierwszy rzut oka możesz stwierdzić że nie różnią się one od klasycznego sposobu wdrażania, ale … przeczytaj uważnie:

  • Warsztaty z wymagań – to spotkania podobne do analizy przedwdrożeniowej. Wykonawca słucha Twoich potrzeb, analizuje obecnie wykorzystywane przez Ciebie procesy i systemy. Patrzy co przechowujesz w arkuszach Excel, co na kartkach. Co robisz manualnie a co masz już zautomatyzowane. Nie stara się jednak bardzo szczegółowo określić każdego Twojego wymagania – zaprojektować każdego ekranu czy określić każdego możliwego pola na wydruku. Ma być to na tyle dokładne aby obydwie strony umowy rozumiały co jest do zrobienia. Dodatkowo – nie ma sensu przewidywać teraz wszystkiego co może być potrzebne za kilka lat. Często bowiem się okazuje że płacisz za rzeczy których nigdy nie wykorzystasz a z drugiej strony za takie które mocno komplikują system.
  • Lista potrzeb – (niektórzy dostawcy używają słowa Backlog na taką listę) to jest wynik Warsztatów z wymagań. Powstaje z pewnością długa lista potrzeb, które powinien/musi spełniać system IT który chcesz wdrożyć. Ta lista musi być dostępna dla wszystkich osób zainteresowanych wdrożeniem – zarówno dla wykonawcy jak i wszystkich Twoich ludzi którzy będą brać udział we wdrożeniu. Najlepiej jeżeli będzie przechowywana w udostępnionym wszystkich miejscu, stale aktualnym – jak np. Arkusz Google Docs czy oprogramowanie typu JIRA. Nie ma sensu żeby to był np. plik Word który przesyłacie sobie e-mailem bo zdezaktualizuje się przy pierwszej próbie zmiany. Ktoś nie dostanie maila, ktoś skasuje a ktoś inny wprowadzi zmiany i zapomni wysłać do innych.
  • Wycenienie każdej potrzeby/funkcjonalności – na tym etapie Wykonawca dokonuje estymaty pod kątem skomplikowania. Nie podaje się jej w godzinach, ponieważ ludzie są bardzo kiepskimi prognostykami co do tego ile będzie coś trwało. Przypomnij sobie ile razy szacowałeś jakieś proste zadanie na godzinę, a później okazywało się że zajmowało Ci cały dzień. Znacznie prościej powiedzieć że np. dane zadanie będzie łatwe, średnie czy trudne. Ludziom dużo łatwiej wychodzą porównania. Tutaj najczęściej posługujemy się tzw. Story Points, które określają poziom skomplikowania danego wymagania – 1,2,3,5,8,13 itd (jest to tzw. Ciąg Fibonacciego – każda kolejna liczba jest sumą dwóch poprzednich). Zadanie które jest wyestymowane na 8 jest dużo bardziej skomplikowane od tego wycenionego na 3, podobnie zadanie wycenione na 2 jest dwa razy bardziej skomplikowane od tego wycenionego na 1.
  • Ułożenie wg priorytetów – tutaj musisz wspólnie z Twoim dostawcą określić priorytety dla poszczególnych wymagań. To nic innego jak ułożenie wszystkich wymaganych funkcjonalności od najważniejszej do najmniej ważnej. Jako ważne zadania należy rozumieć te które przyniosą Ci największą wartość biznesową – pozwolą np. zaoszczędzić czas na obecnie wykonywanych zadaniach czy pozwolą obsłużyć wzrost firmy który planujesz w ciągu najbliższego okresu. Weź pod uwagę że ta lista priorytetów jest układana przez Ciebie na ten moment – za 3 miesiące może się okazać że jest kompletnie inna bo zmieniło się Twoje otoczenie biznesowe. Wdrażając oprogramowanie zgodnie z taką „lekką” metodyką wręcz dajesz sobie przyzwolenie na zmianę priorytetów i możesz to zrobić po każdym etapie. To jest właśnie miejsce w którym taki sposób wprowadzania systemu IT różni się od tradycyjnego, gdzie zmiana po podpisanej umowie jest praktycznie niemożliwa lub bardzo kosztowna.
  • Określenie budżetu – suma wszystkich funkcjonalności w liście wymagań daje określoną liczbę Story Points. Mnożąc to przez koszt realizacji jednego Story Point-a przez Twojego wykonawcę dostajesz zarys budżetu jaki jest potrzebny na realizację.
  • Ustalenie Właściciela Produktu – to jest wbrew pozorom jeden z ważniejszych elementów całego planu. Po Twojej stronie musi być jedna osoba która odpowiada za wdrożenie. Taka osoba ma za zadanie z jednej strony odbierać poszczególne funkcjonalności od wykonawcy ale też ma być łącznikiem pomiędzy wykonawcą a Twoją firmą. Nie może dopuścić do zatorów w komunikacji, ma dbać o to aby ustalać priorytety poszczególnych funkcjonalności i wziąć odpowiedzialność za całą wizję projektu.Tutaj konieczne jest podjęcie decyzji czy będzie realizowane wszystko czy też koszt przekracza Twój wstępnie założony budżet i konieczne jest zmniejszenie zakresu realizowanych funkcjonalności. Jeżeli musisz zmniejszyć koszt to przy takim ułożeniu listy funkcjonalności jest to bardzo proste – po prostu eliminujesz te na samym końcu listy, czyli najmniej ważne. Czynisz to do momentu aż suma kosztów funkcjonalności będzie mieściła się w Twoim zakładanym budżecie.

Podsumowując to co mamy na koniec tego etapu to:

  • określoną funkcjonalność którą wymagamy od nowego systemu IT
  • priorytety dla poszczególnych funkcjonalności
  • budżet całkowity określony przez dostawcę
  • szacowany czas jaki jest potrzebny na realizację wszystkich założonych funkcjonalności
  • wyznaczonego Właściciela Produktu po stronie Twojej firmy

Pora przejść dalej – czyli do realizacji.

Etap pracy/wdrożenia

W metodyce typu Scrum praca jest podzielona na etapy, tzw. Sprinty (to słowo które możesz czasami usłyszeć w rozmowie z Wykonawcą). Sprint może trwać 1,2 czy 3 tygodnie – ważne jednak żeby był o stałej długości. Wykonawca na bazie swojego doświadczenia wie ile jest w stanie zrealizować Story Points w danej długości Sprintu przy zakładanej wielkości swojego zespołu. W miarę jak zespół nabiera doświadczenia przy Twoim projekcie to może szybciej realizować poszczególne funkcjonalności – czyli wykonywać więcej Story Points w jednym etapie.

typowe-dlugosci-sprintow

Przykładowe długości sprintów

Każdy Sprint składa się z kilku standardowych rzeczy:

  • Etap planowania – w tym etapie Ty (a właściwie Twój Właściciel Produktu) razem z Wykonawcą ustalacie listę funkcjonalności jakie mają być zrealizowane. Powiedzmy że wykonawca wie że jest w stanie zrobić 30 Story Point-y w etapie więc wybieracie te funkcjonalności których suma wynosi właśnie 30 SP. Następnie każda z tych wybranych funkcjonalności musi być przejrzana pod kątem precyzyjnego opisu i tzw. Kryteriów odbioru. To ostatnie to nic innego jak spisane w punktach jasne wymagania co do tego, co ma funkcjonalność realizować. To bardzo pomaga przy odbieraniu funkcjonalności od wykonawcy – jeżeli każdy z punktów jest spełniony oznacza to automatycznie że funkcjonalność jest dobrze wykonana. To zabezpiecza zarówno Ciebie jak i wykonawcę przed nieporozumieniami które pojawiają podczas współpracy.
przykladowe-kryteria-odbioru-zadania-scrum

Przykładowe kryteria odbioru w zadaniu

  • Etap pracy – wykonawca wie co ma robić – zobowiązał się zrealizować pewne funkcjonalności – zabiera się więc do pracy. Jego celem jest nie tylko wykonanie funkcjonalności ale i dokładne ich przetestowanie, tak aby na koniec oddać Ci oprogramowanie którego możesz używać. Ważne jest tutaj aby cały czas był dostęp do Twojego Właściciela Produktu – tak aby ewentualne pytania czy wątpliwości mogły być rozwiązywane od ręki. Równie ważna jest zasada że Ty jako Klient nie możesz zmieniać zakresu danego etapu w trakcie jego trwania. W przeciwnym wypadku nie będzie żadnego zakładanego efektu poza chaosem.
  • Etap oddania i odbioru – Na koniec każdego etapu wykonawca ma tzw. Demo day, czyli inaczej mówiąc Dzień Pokazowy ;). Prezentuje co udało mu się zrobić, czego nie. To co prezentuje jest już gotowe do wdrożenia u Ciebie tak abyś mógł tego używać i na bieżąco przekazywać swoje uwagi. To kolejny z punktów który zasadniczo różni się od klasycznego sposobu wdrażania. W tamtym modelu wykonawca coś Ci prezentuje, najczęściej pod koniec swojej pracy ale nie oddaje Ci tego jako skończonego kawałka swojej pracy.
  • Etap podsumowania i spisania wniosków – w tym momencie obydwie strony – zarówno Twoja firma jak i wykonawca – muszą szczerze podsumować dany etap. Konieczne są następujące pytania:
    • Co się udało zrobić?
    • Czego nie udało się zrobić i dlaczego?
    • Co można usprawnić w kolejnym etapie?
    • Jakie były przeszkody, które można usunąć?

Po tym ostatnim etapie następuje powrót do początku – czyli zaczynamy planować kolejny etap i … od nowa rozpoczynamy cały cykl.

dzien-swistaka-scrum

Niektórzy mogą powiedzieć że to prawie jak Dzień Świstaka, ale to jest właśnie siła lekkich metodyk typu Scrum. Dzielimy całość na małe etapy nad którymi jesteśmy w stanie zapanować i po których wiemy więcej co nam jest potrzebne.

Jakie są korzyści z wdrażania przy pomocy metody zwinnej?

Znacie już przebieg pracy zarówno w klasycznej metodyce (tzw. Kaskadowej) wdrażania oprogramowania jak i nowej, zwinnej typu Scrum. Macie już pewnie wyrobione pierwsze swoje zdanie na ten temat.

Mogę sobie wyobrazić że niektórzy z Was od razu podniosą takie argumenty jak:

  • „Przecież ja nie wiem ile to mnie będzie kosztować finalnie”
  • „Mamy do wydania 50 tys zł a ta firma mi mówi że żeby się zmieścić w tym budżecie to musimy zrezygnować z części funkcjonalności”
  • „Skoro płacę jako klient to dlaczego mam jeszcze kogoś delegować od siebie do cyklicznej pracy z wykonawcą”
  • „Co to znaczy że oddajecie mi do pracy niepełne oprogramowanie?”
  • „Moi znajomi zawsze negocjują super ceny na wdrożenie systemu IT i chyba te wdrożenia są udane skoro nadal się rozwijają”

To oznacza że powinniście przeczytać ten artykuł raz jeszcze albo porozmawiać z kimś kto pracuje w takim modelu. Może się również okazać że Wasze podejście jest niezmienne i nie chcecie przyjąć do wiadomości że można lepiej.

Przeczytajcie sobie proszę wtedy w sieci historię Toyoty (tutaj w języku angielskim) i jej konfrontacji z wielkimi wtedy fabrykami samochodów koncernów Amerykańskich. Oni też pukali się w głowę:

  • Jak to pracownik może zatrzymać całą linię produkcyjną? Przecież to są gigantyczne straty.
  • Jak to pracownik ma mówić kierownikowi co ma robić aby naprawić problem podczas awarii? Przecież pracownik jest tylko trybikiem którego możemy wymienić w każdym momencie.
  • Jak to pracownicy chcą pracować i wiedzą co można usprawnić? Przecież to są najczęściej niewykształceni ludzie.

Zakończenie tej historii chyba znacie – Toyota na początku lat 90-tych przejęła fabrykę we Freemont (a właściwie to weszła w spółkę z General Motors) która miała najgorszą reputację wśród wszystkich fabryk GM. Za czasów tego ostatniego strajki były tam na porządku dziennym, nieobecności dochodziły do 20% a jakość samochodów które schodziły z taśm była delikatnie mówiąc wątpliwa.

Toyota nie zmieniła ekipy tam pracującej, ale inwestując w zmianę kultury panującej w zakładzie i wprowadzając swój słynny Toyota Production System potrafiła w ciągu dwóch lat przegonić wydajnością każdy pozostały zakład produkcyjny General Motors. Dodatkowo jakość samochodów była na takim samym poziomie jak siostrzana fabryka w Japonii.

Nie należy stać w miejscu tylko dlatego że tak robią inni. Jeżeli są dostępne i sprawdzone powszechne metody poprawy działania – korzystajcie z nich!

Zachęcam do kontaktu z Qcadoo i przekonania się jak może wyglądać wdrożenie systemu MES w Waszej firmie.

Marcin Perłak

Prezes Qcadoo Limited. Przyjmuje różne role w Qcadoo (poza byciem programistą). Lubi proste formy, jasne zasady. Fanatyk idealnej obsługi klienta. Po pracy zaraża swoje córki nowymi technologiami i jeździ na rowerze po małopolskich wsiach.

2 komentarze

Radek

about 1 rok ago

Gratukuje! Bardzo dobrze,fachowo opisany caly proces.

Odpowiedz

Maria Pruszyńska

about 8 miesięcy ago

Pracuję w firmie zajmującej się tworzeniem systemów oraz wdrożeniami. Błędem wielu firm jest brak konsultacji z pracownikami przy wyborze odpowiedniego systemu. Często wdrożenie nie udaje się właśnie dlatego. Bardzo ciekawy tekst.

Odpowiedz

Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked