1 of 1 people found this helpful
We've stopped short of modelling things to this level of granularity mainly due to the maintenance overheads and other priorities (more the latter than the former).
However, to answer some of your questions....
BMC_Activity is the parent class of BMC_BusinessProcess. The other child of BMC_Activity is BMC_Transaction. So you kind of have the option of recording activities (which are generally thought of as being the things you have to do to deliver a Business Service), as a combination of business processes and transactions (either human or system).
You can relate multiple business processes via a component relationship if you like, to represent a decomposed overall process (kind of your main process plus L1, L2, L3, .. scenario if I understand this correctly).
In terms of making it easier for end-user (say Incident Management) selection, do you want to track at the granularity of the main BP or do you need to identify the sub-processes?? Sounds like the latter? If you maybe use BMC_BusinessProcess for the main process and then relate BMC_Activity CIs for the sub-processes, you can then at least tell your users to search for BMC_Activity CIs not BMC_BusinessProcess CIs. Naming conventions can help then (e.g. BusinessProcess BP1 has sub processes BMC_Activity AC1:1, AC1:2, AC1:3,..).
So pretty much what you have done, but using two classes?? (or is that what you are already suggesting?)
Thanks for the reply - I was thinking about using the 2 classes but then reporting becomes a little more difficult but I'll let them decide that. I think you and I are on the same page with naming conventions. I have stated to go down the path of component relationships for now but once we try a few that might change to the Activity path. Either way is better than the Operational Categories that they wanted to store them in!
Thanks for the input