UML - graficzny język modelowania różnych aspektów działania systemu informatycznego - jest standardem bardzo rozbudowanym. W jego skład wchodzi 13 rodzajów diagramów. Każdy tzw. klasyfikator (klasa, relacja, przypadek użycia, czynność, ...) ma w UML-u kilkadziesiąt własności. Dokumentacja języka UML 2.1 liczy ponad 1000 stron. Czy aby tworzyć eleganckie i poprawne diagramy UML trzeba znać pełną notację tego języka?

Powszechna sytuacja: dostawca realizuje dla klienta system "szyty na miarę". Wyniki analizy dostarcza m. in. w postaci dlagramów np. w języku UML. Tymczasem przedstawiciele klienta to specjaliści biznesowi, a nie informatycy. Nie znają więc notacji UML. Jak sprawić, żeby zrozumieli model i zaczęli się z nim identyfikować? Pełniąc rolę głównego analityka w projekcie realizowanym dla instytucji ubezpieczeniowej, zastosowałem w tym celu ciekawą technikę.

Realizacja procesu biznesowego w organizacjach biurowych (w przeciwieństwie np. do fabryk) nieuchronnie wiąże się z przepływem dokumentów. Czy pojawienie się dokumentów wpływa na sposób, w jaki modelujemy procesy? Czy tworząc model procesu powinniśmy się w ogóle przejmować dokumentami? W projekcie prowadzonym dla jednej z instytucji rynku ubezpieczeniowego, w ramach którego kierowałem zespołem analityków tworzących model procesów biznesowych, znaleźliśmy bardzo ciekawą technikę modelowania procesów, w których pojawiają się dokumenty.