masaiculin wrote
Hi, I have recently started work with an Insurance company in Sydney and have suggested that we map out the business processes. Does anyone out there have processes/best practices that they would be willing to share.
Rebecca
|
|
Hi Rebecca, welcome to the forum. Business processes are pretty straightforward, the question is what other things might you also need to map out. RML (requirements modeling language) divides visual models into 4 categories of models:
Objectives, People, Systems and Data. Within each category are what are called bounding models. They are models that help to bound the scope of the problem.
Here is a link to a summary of all the RML models
http://www.seilevel.com/wp-content/uploads/RML-Language-for-Modeling-Software-Requirements.pdf
here is a link to our book on RML
http://www.amazon.com/Visual-Software-Requirements-Practices-Microsoft/dp/0735667721/ref=sr_1_1?ie=UTF8&qid=1344871900&sr=8-1&keywords=visual+models+software+requirements
Objectives models help you to visually model the business value of the system
People models help you to model the people who are using the system as well as what they do
System models help you to model the ecosystem and the individual systems within the ecosystem
Data models help you to model the relationships between data objects down to individual fields
Process flows are one type of visual people model and they are very useful, but are not sufficient to model a solution.
You can find a ton of information about process flows on the internet. Here are some tips that you might not find elsewhere:
1) dont include branching in your L1 (highest level) process flows
2) try to keep out system specific interactions until you get to the lowest level (or not at all)
3) try to keep process flows to less than 20 or so steps. Too many steps will make the flow unreadable
4) Try to keep process flows to no more than 3 (or 4) levels
5) Start from L1 process flows and then work your way down to detailed L3 process flows