Diagram advice?

[Bill Egge]

Do you have any adice to offer for this diagram?

[thomaskilian]

Looks like a mixture of EP Business Model with technical architecture. If this is kind of analysis you could probably leave it as it is but I'd recommend to focus on the business process when using EP. Maybe you could elaborate a bit more on what you're trying to say.

[Bill Egge]

Thanks for your post Thomas,

I was trying to get a grasp of the processes involved in employee terminations.  Since I can work out the details of how each Business process is done, I only included what was needed by that process.

Your over my head though on EP Business Model and Technical architecture.  If I focus on the business process, and I suppose exclude technical architecture (which I am not really sure what your refering to, but it means removing something) then I cannot see how the model would be usefull - removing anything would just leave question marks.

Like suppose I removed the names of the physical documents involved - if I did that then I would be in the dark about what file is used.

[thomaskilian]

I just didn't understand whether this is analysis or design. Obviously you try to analyze the current state. What you're doing is taking bits and pieces instead of a plane to fly over it. Just take the 30.000 ft view and try to document what the purpose of the business process is - by leaving out any xls or so. If later you're documenting artifacts, use a component diagram to show what's used in the process. The way you approach it will nail you down in an early stage (maybe you'll find out that xls/doc won't be the best solution). If, as I understand, this diagram is just for documentation purpose, then leave it as it is, clearly marking that in some note or text field. Anyway I'd recommend to document the business process behind in a similar diagram. Include the actors as well and, instead of the three blue squares, use a single one TermNoWages (I use Entities from MVC notation as my own flavor).