Temat: Analiza z użyciem wywiadów

Krzysztof Połojański:
Panie Jarku,
zastanawiam się nad tym, co Pan napisał o zbawiennych skutkach analizy dokumentów i szczerze przyznam, że nie wyobrażam sobie takiej formy analizy biznesowej (szczególnie, że pozostawia Pan tylko 10% treści do uszczegółowienia podczas wywiadów :)

W związku z tym mam do Pana kilka pytań (jeśli można...):

Jakich analiz to dotyczy? (jakich sektorów, jak rozległych obszarów biznesowych)

generalnie dotyczy to każdej działalności, która wymaga komunikowania się zostawia, po sobie ślady "na papierze" (a nawet komunikatory, maile)

Czy zaczyna Pan analizę od zebrania tych dokumentów i ich samodzielnej analizy? Czy mimo wszystko stara się Pan przy pomocy klienta umiejscowić te dokumenty w którymś z omawianych procesów biznesowych?

zaczynam od spotkania, na którym identyfikuję kluczowe procesy, z reguły jest ich kilka (tak zwane procesy end-to-end), spotkanie ma na celu ich identyfikację oraz ogólne określenie aktualnej "kultury organizacyjnej"

O jakiej liczbie dokumentów jest tutaj mowa? (10? 100? 500?)

różnie, raz 100 raz 500 (częściej jednak bliżej 100)

No i co dla Pana jest dokumentem (które z nich powinny być przedmiotem takiej analizy, a które nie)?

ogólnie jest także założenie: jeżeli coś ma znaczenie jest utrwalane, więc interesują mnie formalne dokumenty ale także nie formalne (jeden z moich klientów bardzo sprawnie zarządzał kilkoma magazynami w Polsce przez GG)

Nie ja jeden stosuje tę metodę (i nie w 100% przypadków):
http://itcrewblog.pl/2012/02/27/identyfikacja-wymagan-...

Temat: Analiza z użyciem wywiadów

Dziękuję za odpowiedź.

Link bardzo ciekawy. Są tutaj wymienione źródła wiedzy dla takiej metody analizy:

Modele i mapy procesów
Opisy procesów
Diagramy organizacyjne
Specyfikacje produktów
Procedury
Standardy oraz instrukcje
Raport o problemach
Literatura związana z konkurencyjnymi produktami

(swoją drogą, rzadko moim zdaniem spotyka się organizacje, które trzymają aktualne=pożyteczne wersje takich dokumentów)

W tym kontekście wszystko jest jasne. Wydobycie wiedzy o stanie ASIS na podstawie takiej dokumentacji jest już dużo łatwiejszym zadaniem niż wydobycie jej z dokumentów typu faktura, zlecenie, dokumenty magazynowe, raporty itp. (a o takich myślałem pisząc poprzedniego maila).

Pojawia się jednak kolejne pytanie. Jak często spotyka się Pan z projektami, gdzie musi Pan odwzorować jedynie stan ASIS ? (gdzie klient chce np. przepisania istniejącego systemu na nową platformę; nie wykorzystując w ten sposób szansy na polepszenie jego funkcjonalności).

Przy pomocy tej metody opisze Pan obecnie istniejący biznes (być może lepiej niż zna go nie jeden uczestnik tego biznesu), ale gdzie przepraszam jest miejsce na wymagania klienta? Gdzie jest miejsce na usprawnienia, nowe wymagania do systemu? Przypominam, iż mowa tu cały czas o IDENTYFIKACJI WYMAGAŃ na podstawie dokumentów. Gdzie w takim razie one powstają?

Z poważaniem
Krzysztof Połojański

Temat: Analiza z użyciem wywiadów

Krzysztof Połojański:
Dziękuję za odpowiedź.

Link bardzo ciekawy. Są tutaj wymienione źródła wiedzy dla takiej metody analizy:

Modele i mapy procesów
Opisy procesów
Diagramy organizacyjne
Specyfikacje produktów
Procedury
Standardy oraz instrukcje
Raport o problemach
Literatura związana z konkurencyjnymi produktami

(swoją drogą, rzadko moim zdaniem spotyka się organizacje, które trzymają aktualne=pożyteczne wersje takich dokumentów)

W firmach z reguły są:
- dokumenty operacyjne (faktury itp.)
- schemat organizacyjny
- zarządzanie wewnętrzne
- wiemy jakie prawo ogranicza daną firmą
- różne nieformalne dokumenty (np.maile dot. załatwiania tych samych spraw)

W tym kontekście wszystko jest jasne. Wydobycie wiedzy o stanie ASIS na podstawie takiej dokumentacji jest już dużo łatwiejszym zadaniem

nie robię typowego opisu AS-IS

niż wydobycie jej z dokumentów typu faktura, zlecenie, dokumenty magazynowe, raporty itp. (a o takich myślałem pisząc poprzedniego maila).

właśnie z tego to wydobywam ale:





analiza wymaga zamodelowania warstwy środkowej a nie najniższej, nie interesują mnie szczególiki (jak np. w sixsigma czy lean), interesuje mnie wewnętrzny łańcuch wartości.

Pojawia się jednak kolejne pytanie. Jak często spotyka się Pan z projektami, gdzie musi Pan odwzorować jedynie stan ASIS ?

nie robię tego z zasady bo to strata czasu, modele as-is i to-be to modele trzeciej najniższej warstwy, na etapie definiowania wymagań istotne CO ma być zrobione a nie JAK.

(gdzie klient chce np. przepisania istniejącego systemu na nową platformę; nie wykorzystując w ten sposób szansy na polepszenie jego funkcjonalności).

jak tak chce mimo, że mówię że to nie ma sensu to nie podejmuje się projektu

Przy pomocy tej metody opisze Pan obecnie istniejący biznes (być może lepiej niż zna go nie jeden uczestnik tego biznesu), ale gdzie przepraszam jest miejsce na wymagania klienta? Gdzie jest miejsce na usprawnienia, nowe wymagania do systemu? Przypominam, iż mowa tu cały czas o IDENTYFIKACJI WYMAGAŃ na podstawie dokumentów. Gdzie w takim razie one powstają?

podchodząc do analizy wymagań w następujący sposób:
- opisuje biznes (procesy a nie procedury wiem co i po co jest robione
- wybieram w procesach (razem z klientem) miejsca, które można wesprzeć systemem, dostaje listę oczekiwanych usług systemu (przypadki użycia)
- modeluje dziedzinę systemu

mam wymagania, co do zasady wprowadzenie nowego narzędzia zmieni procedury więc nie zajmuje się nimi na poziomie as-is bo to strata czasu skoro i tak maja polecieć do koszta

kluczem jest: co nazywamy wymaganiem? To, że system ma wystawiać faktury VAT czy to że gdzieś tam ma być rozwijana lista różowa i zaokrąglona?

Temat: Analiza z użyciem wywiadów

Jarek Żeliński:

Krzysztof Połojański:
Dziękuję za odpowiedź.

Link bardzo ciekawy. Są tutaj wymienione źródła wiedzy dla takiej metody analizy:

Modele i mapy procesów
Opisy procesów
Diagramy organizacyjne
Specyfikacje produktów
Procedury
Standardy oraz instrukcje
Raport o problemach
Literatura związana z konkurencyjnymi produktami

(swoją drogą, rzadko moim zdaniem spotyka się organizacje, które trzymają aktualne=pożyteczne wersje takich dokumentów)

W firmach z reguły są:
- dokumenty operacyjne (faktury itp.)
- schemat organizacyjny
- zarządzanie wewnętrzne
- wiemy jakie prawo ogranicza daną firmą
- różne nieformalne dokumenty (np.maile dot. załatwiania tych samych spraw)

W tym kontekście wszystko jest jasne. Wydobycie wiedzy o stanie ASIS na podstawie takiej dokumentacji jest już dużo łatwiejszym zadaniem

nie robię typowego opisu AS-IS

niż wydobycie jej z dokumentów typu faktura, zlecenie, dokumenty magazynowe, raporty itp. (a o takich myślałem pisząc poprzedniego maila).

właśnie z tego to wydobywam ale:





analiza wymaga zamodelowania warstwy środkowej a nie najniższej, nie interesują mnie szczególiki (jak np. w sixsigma czy lean), interesuje mnie wewnętrzny łańcuch wartości.

Pojawia się jednak kolejne pytanie. Jak często spotyka się Pan z projektami, gdzie musi Pan odwzorować jedynie stan ASIS ?

nie robię tego z zasady bo to strata czasu, modele as-is i to-be to modele trzeciej najniższej warstwy, na etapie definiowania wymagań istotne CO ma być zrobione a nie JAK.

CO ma być zrobione to chyba raczej zakres analizy. Czy podczas analizy nie powinniśmy szukać odpowiedzi na pytanie JAK ma to COŚ być zrobione? Wydobycie tylko tego, CO ma być zrobione może posłużyć do wsparcia wyceny projektu. Z pewnością nie wystarczy do implementacji systemu (no chyba, że klient nie określa żadnych reguł biznesowych i daje nam wolną rękę...tak chyba nigdy nie jest)

(gdzie klient chce np. przepisania istniejącego systemu na nową platformę; nie wykorzystując w ten sposób szansy na polepszenie jego funkcjonalności).

jak tak chce mimo, że mówię że to nie ma sensu to nie podejmuje się projektu

Rozumiem, że zakłada Pan, że każdy biznes da się ulepszyć...ryzykowne założenie...

Przy pomocy tej metody opisze Pan obecnie istniejący biznes (być może lepiej niż zna go nie jeden uczestnik tego biznesu), ale gdzie przepraszam jest miejsce na wymagania klienta? Gdzie jest miejsce na usprawnienia, nowe wymagania do systemu? Przypominam, iż mowa tu cały czas o IDENTYFIKACJI WYMAGAŃ na podstawie dokumentów. Gdzie w takim razie one powstają?

podchodząc do analizy wymagań w następujący sposób:
- opisuje biznes (procesy a nie procedury wiem co i po co jest robione
- wybieram w procesach (razem z klientem) miejsca, które można wesprzeć systemem, dostaje listę oczekiwanych usług systemu (przypadki użycia)
- modeluje dziedzinę systemu

W jaki sposób Pan to robi?

mam wymagania, co do zasady wprowadzenie nowego narzędzia zmieni procedury więc nie zajmuje się nimi na poziomie as-is bo to strata czasu skoro i tak maja polecieć do koszta

kluczem jest: co nazywamy wymaganiem? To, że system ma wystawiać faktury VAT czy to że gdzieś tam ma być rozwijana lista różowa i zaokrąglona?

Wymaganiem jest i to, że system ma wystawiać faktury i to, że powinna być widoczna różowa i zaokrąglona lista rozwijana. Moim zdaniem ważne jest to, abyśmy razem z klientem potrafili odpowiedzieć na jedno, bardzo ważne pytanie: Po co robimy to, co robimy? Co chcemy osiągnąć?
Świadomość celu powinna pomóc w określeniu jak głęboko powinniśmy zejść z opisem wymagań.

Temat: Analiza z użyciem wywiadów

CO ma być zrobione to chyba raczej zakres analizy. Czy podczas analizy nie powinniśmy szukać odpowiedzi na pytanie JAK ma to COŚ być zrobione?

najprostsza definicja przypadku użycia / wymagania zaleca: bo nie implementować rozwiązana na etapie analizy wymagań, czyli wymagania w rodzaju "podczas tworzenia faktury klienta wybieramy z rozwijanej listy" jest już implementacją", celem jest faktura zgodna z prawem.

Wydobycie tylko tego, CO ma być zrobione może posłużyć do wsparcia wyceny projektu. Z pewnością nie wystarczy do implementacji systemu (no chyba, że klient nie określa żadnych reguł biznesowych i daje nam wolną rękę...tak chyba nigdy nie jest)

bo implementacja to projekt systemu a nie specyfikacja wymagań, reguły biznesowe to nie implementacja a element wymagań.

to dlatego proces ma takie fazy:
- analiza wymagań (system jako czarna skrzynka) - tu celem analizy jest określenie "do czego" system posłuży"

- identyfikacja reguł biznesowych

- opracowanie projektu logiki systemu

- implementacja

z perspektywy OMG/MDA mamy trzy modele: CIM potem PIM a potem PSM i nie jest dobrym pomysłem mieszanie zakresów tych modeli.

(gdzie klient chce np. przepisania istniejącego systemu na nową platformę; nie wykorzystując w ten sposób szansy na polepszenie jego funkcjonalności).

jak tak chce mimo, że mówię że to nie ma sensu to nie podejmuje się projektu

Rozumiem, że zakłada Pan, że każdy biznes da się ulepszyć...ryzykowne założenie...

nie, uznaję zasadę, że nie ma sensu robienie czegoś co go nie ulepszy...

Przy pomocy tej metody opisze Pan obecnie istniejący biznes (być może lepiej niż zna go nie jeden uczestnik tego biznesu), ale gdzie przepraszam jest miejsce na wymagania klienta? Gdzie jest miejsce na usprawnienia, nowe wymagania do systemu? Przypominam, iż mowa tu cały czas o IDENTYFIKACJI WYMAGAŃ na podstawie dokumentów. Gdzie w takim razie one powstają?

z dokumentów np. mam, że firma wystawia faktury poprzedzane zawsze zamówieniem, reguła biznesowa mówi, że dopuszczamy grupowanie zrealizowanych zamówień ale pod warunkiem, ze zawsze całość z jednego miesiąca na jednej fakturze.

Po pierwsze: skąd nowe wymaganie? Albo zmienił się proces, albo reguła biznesowa, albo system jest przestarzały i nieergonomiczny (np. po d DOSem...)

jakiś inny powód by to psuć? Owszem: system jest tak zaprojektowany, że każda zmiana jak wyżej wymaga ingerencji programistów, być może warto znaleźć sposób na rozwiązanie tego problemu i zaprojektować inny system?

podchodząc do analizy wymagań w następujący sposób:
- opisuje biznes (procesy a nie procedury wiem co i po co jest robione
- wybieram w procesach (razem z klientem) miejsca, które można wesprzeć systemem, dostaje listę oczekiwanych usług systemu (przypadki użycia)
- modeluje dziedzinę systemu

W jaki sposób Pan to robi?

no to elaborat :) są dwa wyjścia:
- szkolenie u mnie :)
- literatura OMG
- literatura BABoK
- .............. literatura

a w dużym skrócie tu:
http://it-consulting.pl/autoinstalator/wordpress/2012/...

mam wymagania, co do zasady wprowadzenie nowego narzędzia zmieni procedury więc nie zajmuje się nimi na poziomie as-is bo to strata czasu skoro i tak maja polecieć do koszta

kluczem jest: co nazywamy wymaganiem? To, że system ma wystawiać faktury VAT czy to że gdzieś tam ma być rozwijana lista różowa i zaokrąglona?

Wymaganiem jest i to, że system ma wystawiać faktury i to, że powinna być widoczna różowa i zaokrąglona lista rozwijana.

otóż nie, "różowa i zaokrąglona lista rozwijana" to element projektowania, z perspektywy zamawiającego może on zgłosić ograniczenie: "faktura ma być śliczna bo w FK pracują dziewczynki", tu żądam wskazania jaki cel biznesowy zaspokaja to oczekiwanie, trzeba jednak mieć te cele biznesowe projektu, bez nich wykonawca "płynie w koszty" po każdym takim żądaniu....

podstawowym elementem dobrego projektu są CELE BIZNESOWE i mapowanie ich na wymagania funkcjonalne i poza-funkcjonalne (jakościowe), bez tego zakres projektu jest praktycznie niezarzadzalny i najczęściej puchnie w takt projektu... w projektach "czas i materiał" dostawca ma super klient cierpi (jest naciągany) w projektach fixed-price utrata panowania nad zakresem to kicha totalna

Moim zdaniem ważne jest to, abyśmy razem z klientem potrafili odpowiedzieć na jedno, bardzo ważne pytanie: Po co robimy to, co robimy? Co chcemy osiągnąć?

ano właśnie CELE BIZNESOWE (udokumentowane! to podstawowy element dobrej analizy biznesowej) system fakturowania tworzymy i wdrażamy by sprawnie fakturować, pojęcie "sprawnie" wymaga indywidualnej oceny ale "różowe i rozwijane" to jeden z wielu możliwych pomysłów, pozwolenie na to, by użytkownik takie rzeczy "narzucał" to troszkę jak iść do lekarza i dyktować mu treść recepty, projekty zabijają najczęściej właśnie takie życzenia, ja o czymś takim natychmiast informuje sponsora projektu.

Świadomość celu powinna pomóc w określeniu jak głęboko powinniśmy zejść z opisem wymagań.

definicja wymagań ("głębokość") jest jasna w każdej dobrze opisanej metodyce, problem w tym by oddzielać wymagania od ich implementacji (jak w każdej innej branży, np. celem i wymaganiem jest płynna jazda samochodem niezależnie od prędkości, wybór rodzaju skrzyni biegów albo typu silnika - a niektóre radzą sobie bez skrzyni - to implementacja tego wymagania).

Temat: Analiza z użyciem wywiadów

Dziękuję za odpowiedź :)