To, że UML jest obcy więk­szo­ści ana­li­ty­ków biz­ne­so­wych to przy­kra praw­da, dzi­siaj raczej źle świad­czą­ca o tej więk­szo­ści (patrz model kom­pe­ten­cji ana­li­ty­ka biz­ne­so­we­go IIBA). Używanie UML do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych jest ogra­ni­cza­niem moż­li­wo­ści tych mode­li gdyż UML repre­zen­tu­je para­dyg­mat obiek­to­wy a BPMN pro­ce­so­wy a to dwa odręb­ne świa­ty (to, że powsta­ły i są wyko­rzy­sty­wa­ne rów­no­le­gle te dwie, róż­nią­ce się od sie­bie, nota­cje nota­cje tak­że o tym świad­czy). Trudno tak­że mówić o ​„podej­ściu” do mode­lo­wa­nia pro­ce­sów w UML bo to tak, jak by mówić że ​„łodzie repre­zen­tu­ją zupeł­nie odmien­ne podej­ście do poru­sza­nia się po dro­gach publicz­nych”. Niestety są żegla­rze, któ­rzy nie uzna­ją innej praw­dy niż ta, że łodzią moż­na wszę­dzie, trze­ba się tyl­ko posta­rać. Faktem jest, trze­ba się dobrze posta­rać. […] Co do wyma­gań samych narzę­dzi UML nie podej­mu­ję się dys­ku­sji bo narzę­dzia są roż­ne i każ­dy sam sobie je dobie­ra. Co do samej ścież­ki ana­li­zy to raczej w pierw­szej kolej­no­ści mode­lu­je­my biz­nes (mode­le BPMN) a potem dopie­ro zasta­na­wia­my się i pro­jek­tu­je­my narzę­dzie, opro­gra­mo­wa­nie dla tego biz­ne­su czy­li pora na UML. Odwrotną kolej­ność suge­ru­ją dostaw­cy goto­we­go opro­gra­mo­wa­nia ale ten wątek był na tym blo­gu już nie raz poruszany.