Hello All,

I am experiencing some paralysis here, and I'm hoping this community might offer some tips for breaking out.

After two years out of the game, (though I had done BA work for many years) I am several weeks into a project that is requiring me to document a company's notification processes within its own ranks as well as to the customer. Next, we'll be trying to revise and streamline those processes. So far, it's been not too terribly difficult, but as I get into the really detailed areas (who calls who when this happens in this particular scenario...), I'm starting to find myself paralyzed. I'm looking at the inconsistencies in the current processes and having trouble figuring out the best way to depict those inconsistencies graphically, and I'm a bit overwhelmed overall.

Could someone suggest something I might read, a quick overview perhaps of a course, anything that might break me out of this stuck place? I just need to gain some clarity!

Thanks very much.

Marie

 Hi Marie,

Welcome to ModernAnalyst.

Don't know if this will help but you could try...

1. stay focussed on what you are doing (which seems to be modelling the as-is physical process model)

2. list the starting events for each one of these convoluted processes. E.g. "customer advisor receives notification of xyz". Be ruthless about the event. Was it in this example true that the starting event in the current physical world is that an advisor receives a notification or do they choose to open some application to see if they have a notification?

3. record the process flow that results from the event using BPMN or similar (example "how to" document here). Again, be brutal about how much the person/role running the process HAS to do before they can go off and do something else (i.e. the process in effect ends). Don't get sucked in to long models where there are really process breaks while in effect the wait is caused by waiting for another event to occur. E.g. Process step "advisor notifies customer of xyz" could be the end of the process. The next event may be "customer queries xyz notification" but that is another event modelled on another process model. Don't link it to the process step "advisor notifies customer of xyz" unless it really adds value and even then do it via an intermediate event. Otherwise your process models will never end and neither will they reflect reality (lots of people doing lots of things not always in a logical order).

4. Apply the rules and guidelines about when to combine or split processes as rigorously as you can. Those rules can be found in the article mentioned earlier.

5. Use swimlanes to show who is doing what but not show systems.

5. Don't start trying to logicalise and/or model requirements in your current as is physical model - as you say the next steps are streamlining the process. First step is to see just how good (or bad) it really is.

Hope that helps...

Guy

Guy, the article was a big help. Good refresher for getting my thoughts in order. Thanks for the thoughtful response.