Zrozum, zanim zaproponujesz rozwiązanie

Analiza biznesowa, przeprowadzana przez wykonawcę rozwiązań IT dla biznesu, nie polega na zwykłym spisaniu problemów zgłaszanych przez klienta. Zapis przebiegu spotkań, wypunktowanie najważniejszych wymagań stawianych przed oprogramowaniem i prezentacja ich klientowi w formie tabeli to jeszcze nie analiza biznesowa! Wykonawca oprogramowania otrzymuje w ten sposób jedynie wnioski dotyczące efektów wadliwego działania aktualnego systemu zarządzania, ale dalej nie ma pojęcia o przyczynach tego stanu rzeczy. Jak zatem może zaproponować zleceniodawcy lepsze rozwiązanie?

Prawidłowo przeprowadzona analiza i modelowanie biznesowe opierają się na pewnych ściśle określonych zasadach i korzystają z przeznaczonych do tego celu notacji (języków). Na naszym rynku istnieje wiele podręczników szczegółowo opisujących teorię poszczególnych notacji: UML, BPMN, BMM, SysML itd. Ich autorzy skupiają się na definicji pojęć, słownictwie i powiązaniach występujących w poszczególnych metodach zapisu, a teorie uzupełniają prostymi przykładami. Autor tej książki postanowił podejść do tematu z całkiem innej strony wychodzi od faktycznych problemów, z jakimi spotkał się w swojej wieloletniej praktyce, i podaje przykłady ich poprawnego, analitycznego opisu z użyciem takiej notacji, która jest najwłaściwsza w danej sytuacji biznesowej. Dzięki temu masz szansę poznać i zrozumieć, kiedy, po co i jak stosować dany język analityczny.

Rozdziały:

Wstęp (5)

1. Po co nam pan analityk? (7)

2. Jak opracować wymagania dla systemu informatycznego (13)

• Jaki to ma związek z systemem informatycznym? (14)

3. System zarządzania informacją (17)

• Dwie definicje (18)
• Łańcuchy (21)

4. Czym jest system CRM (25)

• Opis problemu (25)
• Czy dysk sieciowy rozwiązuje problem? (29)
• Pora na system CRM (30)

5. Zasoby IT a procesy przetwarzania informacji (35)

6. A na grzyba mi to modelowanie (39)

• Więc jak to jest z tymi wymaganiami? Jak je wyspecyfikować? (40)

7. O błędach w modelowaniu (43)

• Jak, co i po co modelować (43)
• O analizie wymagań dla systemu IT (45)

8. Potrzeby informacyjne a zarządzanie wiedzą (47)

• Potrzeby informacyjne firmy (47)
• Definicje (48)
• Model pojęciowy jako model rzeczywistości (51)
• Zarządzanie wiedzą (56)

9. Historyjka użytkownika - kłopoty (57)

10. Reguły biznesowe - czym są (61)

11. Komunikacja, czyli analiza i projektowanie, oraz jak to zostanie odebrane (63)

• Model komunikacji (63)
• Jak to się ma do inżynierii oprogramowania (66)
• Na zakończenie (68)

12. Przypadki użycia i granice systemu (71)

13. Diagram klas: model dziedziny (77)

• Dygresja budowlana - pouczająca przygoda (77)
• Diagram klas czy model dziedziny - co ma powstać? (78)
• Model dziedziny systemu zamówienia (79)
• Diagram klas a model dziedziny systemu (81)
• Czy takie analizy mają sens w przypadku gotowych ERP? (85)
• A gdzie się podziały wymagania pozafunkcjonalne? (85)

14. Klient nasz pan (87)

15. Wymagania dla oprogramowania ERP a analiza przedwdrożeniowa - gdzie jest różnica? (91)

• Kupujemy buciki (91)
• Jak wykonać patyczek? (92)
• Co zawiera taki model? (93)

16. Udziałowcy projektu, czyli diagramy UML (95)

• Modelowanie zależności pomiędzy udziałowcami (96)
• UML i diagramy przypadków użycia jako model udziałowców (96)
• Analiza RACI (100)

17. Analityk biznesowy, czyli wyplenić dwuznaczność z dokumentów (101)

18. Plansza do gry w szachy, czyli analiza i projektowanie (103)

• Cel zamawiającego (103)
• Model pojęciowy - zrozumieć problem i cel projektu (105)
• Model procesu biznesowego - zrozumieć, co i po co jest robione (107)
• Zarządzanie wymaganiami (117)
• Na zakończenie (119)