Systemy informatyczne s\u0105 zwykle drogie. Ich wdro\u017cenie to nierzadko koszt kilkuset tysi\u0119cy lub nawet wielu milion\u00f3w z\u0142otych. Planuj\u0105c tak istotn\u0105 inwestycj\u0119, warto starannie j\u0105 przemy\u015ble\u0107 i przygotowa\u0107, tak aby przynios\u0142a maksymalny zwrot oraz dostarczy\u0142a organizacji mo\u017cliwie najwi\u0119kszej warto\u015bci.<\/p>\n\n\n\n
Warto\u015b\u0107 ta mo\u017ce by\u0107 zdefiniowana bardzo wymiernie, np.: jako wzrost przychod\u00f3w, spadek koszt\u00f3w lub jako co\u015b trudniej mierzalnego np.: zmniejszenie okre\u015blonego ryzyka, poprawa ergonomii \u015brodowiska pracy lub czy zwi\u0119kszenie efektywno\u015bci wybranych proces\u00f3w.<\/p>\n\n\n\n
Powy\u017csze stwierdzenie wydaje si\u0119 oczywisto\u015bci\u0105, a jednak cz\u0119sto w swojej praktyce widuj\u0119 projekty z niew\u0142a\u015bciwie okre\u015blonym celem biznesowym<\/strong>, wyra\u017conym jako wdro\u017cenie okre\u015blonego systemu. Projekty takie od samego pocz\u0105tku s\u0105 realizowane z za\u0142o\u017ceniem, \u017ce miar\u0105 ich sukcesu jest fakt wdro\u017cenia z g\u00f3ry wybranego systemu, niezale\u017cnie jakie finalnie przyniesie to skutki dla organizacji.<\/p>\n\n\n\n W konsekwencji skupiaj\u0105 si\u0119 jedynie na pozyskaniu szczeg\u00f3\u0142owych wymaga\u0144, kt\u00f3re najcz\u0119\u015bciej s\u0105 nast\u0119pnie realizowane jedynie w takim zakresie, na jaki pozwala konfiguracja systemu.<\/p>\n\n\n\n W artykule przedstawi\u0119 na konkretnych przyk\u0142adach, co zrobi\u0107, by zadzia\u0142a\u0107 bardziej efektywnie.<\/p>\n\n\n\n Ze wskazaniem finalnego rozwi\u0105zania nie warto si\u0119 \u015bpieszy\u0107<\/strong>. Nie chodzi tutaj oczywi\u015bcie o zb\u0119dn\u0105 zw\u0142ok\u0119 i przeci\u0105ganie podejmowana decyzji, ale o poprzedzenie wyboru rozwi\u0105zania rzetelnym i poprawnym zdefiniowaniem potrzeby<\/strong>, wymaga\u0144 oraz rozpoznaniem dost\u0119pnych opcji. Na tym w\u0142a\u015bnie polega prawid\u0142owo przeprowadzana analiza biznesowa, definiowana w BABOK (A Guide to the Business Analysis Body of Knowledge\u00ae<\/a>), jako:<\/p>\n\n\n\n Praktyka umo\u017cliwiania zmian w kontek\u015bcie przedsi\u0119biorstwa poprzez definiowanie potrzeb i rekomendowanie rozwi\u0105za\u0144, kt\u00f3re dostarczaj\u0105 warto\u015b\u0107 interesariuszom.<\/em><\/p>\n<\/blockquote>\n\n\n\n Warto przytoczy\u0107 r\u00f3wnie\u017c znajduj\u0105c\u0105 si\u0119 w BABOK<\/a> definicj\u0119 potrzeby:<\/p>\n\n\n\n Problem lub szansa, kt\u00f3rymi nale\u017cy si\u0119 zaj\u0105\u0107.<\/em><\/p>\n<\/blockquote>\n\n\n\n oraz definicj\u0119 wymagania:<\/p>\n\n\n\n U\u017cyteczna reprezentacja potrzeby.<\/em><\/p>\n<\/blockquote>\n\n\n\n Nale\u017cy zatem najpierw zdefiniowa\u0107 potrzeb\u0119 i wyra\u017caj\u0105ce je wymagania, a dopiero w kolejnym kroku przej\u015b\u0107 do analizy dost\u0119pnych opcji oraz rekomendowania rozwi\u0105za\u0144. Wynika z tego, \u017ce cel danej inicjatywy nie powinien by\u0107 wyra\u017cony jako wdro\u017cenie systemu XYZ, ale jako problem, kt\u00f3ry nale\u017cy rozwi\u0105za\u0107 lub szansa, kt\u00f3r\u0105 nale\u017cy wykorzysta\u0107<\/strong>.<\/p>\n\n\n\n Gdy nie koncentrujemy si\u0119 najpierw na potrzebie i wymaganiach, ale od razu przechodzimy do konkretnych rozwi\u0105za\u0144, cz\u0119sto tracimy z oczu rozwi\u0105zania potencjalnie lepsze, zaspokajaj\u0105ce rzeczywist\u0105 potrzeb\u0119 w wi\u0119kszym stopniu i dostarczaj\u0105ce wi\u0119kszej warto\u015bci.<\/p>\n\n\n\n Banalnym przyk\u0142adem b\u0119d\u0105cym ilustracj\u0105 tego zjawiska jest sytuacja, z kt\u00f3r\u0105 spotka\u0142em si\u0119, pracuj\u0105c jako analityk IT w jednym z bank\u00f3w inwestycyjnych. Zesp\u00f3\u0142, kt\u00f3rego by\u0142em cz\u0119\u015bci\u0105, odpowiada\u0142 za utrzymanie i rozw\u00f3j kilku system\u00f3w informatycznych. Pewnego dnia u\u017cytkownicy jednego z system\u00f3w skontaktowali si\u0119 z nami i przekazali nam \u201ewymagania\u201d m\u00f3wi\u0105ce o konieczno\u015bci dodania do systemu formularza zawieraj\u0105cego konkretne pola. Opisali r\u00f3wnie\u017c, w szczeg\u00f3\u0142owy spos\u00f3b, miejsce w systemie, do kt\u00f3rego maj\u0105 trafia\u0107 wprowadzone r\u0119cznie dane.<\/p>\n\n\n\n S\u0142owo wymagania<\/em> w poprzednim zdaniu celowo uj\u0105\u0142em z cudzys\u0142\u00f3w, gdy\u017c nie by\u0142y to wymagania, a konkretna propozycja rozwi\u0105zania<\/strong>. Id\u0105c utartym i znanym schematem rozumowania (brak danych -> wprowadzanie ich przez formularz), u\u017cytkownicy systemu stracili z pola widzenia potencjalnie inne, lepsze rozwi\u0105zania. Oczywi\u015bcie po kr\u00f3tkiej rozmowie okaza\u0142o si\u0119, \u017ce ich rzeczywist\u0105 potrzeb\u0105 nie jest posiadania formularza w systemie, ale mo\u017cliwo\u015b\u0107 obs\u0142ugi nowych produkt\u00f3w inwestycyjnych. Aby m\u00f3c to robi\u0107, potrzebuj\u0105 konkretnych danych. Wiedz\u0105c to, po kr\u00f3tkiej analizie mogli\u015bmy zaproponowa\u0107 inne, lepsze rozwi\u0105zanie<\/strong> polegaj\u0105ce na automatycznym imporcie potrzebnych danych.<\/p>\n\n\n\n Powy\u017cszy przyk\u0142ad jest banalny, ale dobrze ilustruje on problem, kt\u00f3ry mo\u017ce wynika\u0107 ze zbyt wczesnego definiowania rozwi\u0105za\u0144<\/strong>, bez poprzedzaj\u0105cej to rzetelnej analizy. Problemem tym jest wyb\u00f3r i wdro\u017cenie rozwi\u0105zania, kt\u00f3re by\u0107 mo\u017ce w jakim\u015b stopniu zaspokaja rzeczywist\u0105 potrzeb\u0119 biznesow\u0105, ale nie jest optymalne.<\/p>\n\n\n\n Przytoczony przyk\u0142ad dotyczy niewielkiej funkcjonalno\u015bci w istniej\u0105cym ju\u017c systemie informatycznym, a nie ca\u0142o\u015bciowego wdra\u017cania nowego systemu. Jednak podczas realizowania du\u017cych i skomplikowanych projekt\u00f3w wpadamy cz\u0119sto w identyczna pu\u0142apk\u0119. Dodatkowo, im wi\u0119ksza jest inwestycja<\/strong>, tym istotniejsze staje si\u0119 to to, aby zrealizowa\u0107 w jej ramach najlepsze z mo\u017cliwych, a nie zaledwie \u201ejakie\u015b\u201d rozwi\u0105zanie.<\/p>\n\n\n\n Jak ju\u017c wcze\u015bniej wspomnia\u0142em, punktem wyj\u015bcia do rozpocz\u0119cia okre\u015blonej inicjatywy powinno by\u0107 zdefiniowanie potrzeby. To w\u0142a\u015bnie ona informuje o tym co, chcemy uzyska\u0107 jako organizacja i to ona powinna stanowi\u0107 podstaw\u0119 do zdefiniowania<\/strong> wymaga\u0144 biznesowych<\/strong>.<\/p>\n\n\n\n Nast\u0119pnym krokiem powinna by\u0107 analiza stanu obecnego (AS-IS), czyli stanu, w kt\u00f3rym obecnie znajduje si\u0119 organizacja i w kt\u00f3rym istnieje zdefiniowana potrzeba biznesowa. Nast\u0119pnie przej\u015b\u0107 nale\u017cy do zdefiniowania stanu docelowego (TO-BE), czyli stanu organizacji, w kt\u00f3rym potrzeba biznesowa zostanie zaspokojona.<\/p>\n\n\n\n Zwykle istnieje sporo mo\u017cliwych przej\u015b\u0107 pomi\u0119dzy stanem obecnym (AS-IS) oraz docelowym (TO-BE). Mog\u0105 one \u0142\u0105czy\u0107 wiele element\u00f3w i wymaga\u0107 zmian proces\u00f3w biznesowych, inwestycji w kompetencje pracownik\u00f3w, czy te\u017c wdro\u017cenia odpowiednich system\u00f3w IT. Ka\u017cde z mo\u017cliwych przej\u015b\u0107 jest potencjaln\u0105 opcj\u0105 rozwi\u0105zania<\/strong>. Nale\u017cy je oceni\u0107, por\u00f3wna\u0107 i wybra\u0107 najlepsze z nich.<\/p>\n\n\n\n Dokumentem, kt\u00f3ry zdecydowanie wspiera opisane powy\u017cej podej\u015bcie, jest Business Case. Jego opracowywanie stanowi jedn\u0105 z technik opisanych w BABOK.<\/p>\n\n\n\n Dokument ten przedstawia:<\/p>\n\n\n\n Opcje rozwi\u0105zana s\u0105 ocenione za pomoc\u0105 wybranych kryteri\u00f3w. <\/strong>Zwykle s\u0105 to:<\/p>\n\n\n\n Business Case ko\u0144czy si\u0119 zazwyczaj rekomendacj\u0105 jednego z rozwi\u0105za\u0144, popart\u0105 jasnymi i rzeczowymi argumentami. Przedstawienie i por\u00f3wnanie opcji w tej formie oraz rekomendowanie jednej z nich pozwala interesariuszom, w tym szczeg\u00f3lnie sponsorowi projektu, na podj\u0119cie trafnej, poprzedzonej analiz\u0105 decyzji o wyborze konkretnego rozwi\u0105zania<\/strong>. <\/p>\n\n\n\n Przeprowadzaj\u0105c analiz\u0119 w opisany spos\u00f3b, definiuj\u0105c r\u00f3\u017cne mo\u017cliwo\u015bci dotycz\u0105ce rozwi\u0105zania i rzetelnie por\u00f3wnuj\u0105c je pomi\u0119dzy sob\u0105, stanowczo zwi\u0119kszamy prawdopodobie\u0144stwo wyboru optymalnego rozwi\u0105zania, d\u0142ugofalowo dostarczaj\u0105cego organizacji maksymaln\u0105 warto\u015b\u0107. W konsekwencji dbamy o to, aby nasz projekt okaza\u0142 si\u0119 sukcesem, a nie kosztown\u0105 i nikomu niepotrzebn\u0105 lub niechcian\u0105 inwestycj\u0105, nieprzynosz\u0105c\u0105 oczekiwanego zwrotu<\/strong>.<\/p>\n\n\n\n Argumentem potwierdzaj\u0105cym tez\u0119 o poprawno\u015bci opisanego podej\u015bcia mo\u017ce by\u0107 przyk\u0142ad projektu realizowanego dla jednego z klient\u00f3w. Projekt mia\u0142 dotyczy\u0107 analizy przedwdro\u017ceniowej systemu ERP. Wydawa\u0142 si\u0119 trudny ze wzgl\u0119du na wcze\u015bniejsze, negatywne do\u015bwiadczenia klienta, kt\u00f3ry twierdzi\u0142, \u017ce wcze\u015bniej \u201e [\u2026] mia\u0142 problem, wdra\u017ca\u0142 system, wydawa\u0142 pieni\u0105dze i nadal mia\u0142 problem\u201d.<\/p>\n\n\n\n Po namowach klient zgodzi\u0142 si\u0119, aby tym razem projekt nie dotyczy\u0142 stricte analizy wymaga\u0144 dotycz\u0105cych wdro\u017cenia konkretnego systemu IT, lecz aby potraktowa\u0107 go jako okazj\u0119 do analizy i optymalizacji jego organizacji. W efekcie zdefiniowana zosta\u0142a potrzeba i wynikaj\u0105ce z niej wysokopoziomowe wymagania biznesowe<\/strong>. Nast\u0119pnie przeprowadzona zosta\u0142a analiza AS-IS oraz TO-BE wybranych proces\u00f3w. Obejmowa\u0142a ona opracowanie modeli w notacji BPMN.<\/p>\n\n\n\n Finalnym rezultatem by\u0142a lista proponowanych zmian i optymalizacji dotycz\u0105cych analizowanych proces\u00f3w oraz zbi\u00f3r wymaga\u0144 dotycz\u0105cych system\u00f3w informatycznych mog\u0105cych je wesprze\u0107. Ca\u0142a analiza przeprowadzona zosta\u0142a wed\u0142ug zasady \u201esolution agnostic\u201d,<\/em> czyli bez zak\u0142adania z g\u00f3ry wdro\u017cenia konkretnego systemu, a skupiaj\u0105c si\u0119 na wymaganiach organizacji i oczekiwanych rezultatach.<\/p>\n\n\n\n Na podstawie udokumentowanych wymaga\u0144 powsta\u0142 dokument RFP (ang. Request for proposal), kt\u00f3ry wys\u0142ano do dostawc\u00f3w oprogramowania w celu uzyskania ofert. Oczywi\u015bcie klient otrzyma\u0142 pe\u0142ne wsparcie w zakresie analizy ofert i wyboru wykonawcy, a nast\u0119pnie wdro\u017cenia systemu.<\/p>\n\n\n\n Ostatnim etapem projektu by\u0142o sprawdzenie, czy zaproponowane zmiany, w tym zmiany w procesach oraz wdro\u017cenie wybranych system\u00f3w IT, przynios\u0142y oczekiwany skutek. W tym celu opracowano mierniki wynikaj\u0105ce wprost ze zdefiniowanych na pocz\u0105tku projektu wymaga\u0144 biznesowych. <\/p>\n\n\n\n Na podstawie zebranych danych okaza\u0142o si\u0119, \u017ce rzeczywi\u015bcie wymagania biznesowe zosta\u0142y spe\u0142nione, a co za tym idzie, zdefiniowana potrzeba organizacji zosta\u0142a zaspokojona<\/strong>. Dzi\u0119ki por\u00f3wnaniu r\u00f3\u017cnych opcji rozwi\u0105zania, bez pocz\u0105tkowego za\u0142o\u017cenia co do wyboru konkretnego systemu, zosta\u0142a ona zaspokojona w spos\u00f3b optymalny<\/strong>.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli interesuje Ci\u0119 temat Analizy Biznesowej, sprawd\u017a koniecznie inne artyku\u0142y naszych specjalist\u00f3w<\/a>. <\/p>\n\n\nNajpierw wymagania, potem rozwi\u0105zanie<\/strong><\/h2>\n\n\n\n
\n
\n
\n
Dlaczego tak?<\/strong><\/h2>\n\n\n\n
AS-IS i TO-BE<\/strong><\/h2>\n\n\n\n
Business Case \u2013 do czego s\u0142u\u017cy?<\/strong><\/h2>\n\n\n\n
\n
\n
Czy to dzia\u0142a?<\/strong><\/h2>\n\n\n\n