 |
|
|
|
Hello people,
I'm currently working on some process templates for the different decompostions: business process, sub-process, processtep, task. What i'm trying to do is to describe what elements are important on the different levels of detail. This way i want people to understand not to get into much detail when start modelling, and when it is the right time to discuss other matters. For example: processteps and tasks is where people deal with information, so let's talk about information. On the task level you will find (some) business rules, so let's get down discussng business rules etc.
So i have two questions:
So far i have very basic things like roles, documents, applications etc. but are focused on the last two levels of detail. What should a template for the bussines process, and sub-process hold? Do you people have any suggestions what is important to describe on the different levels of detail
And on what levels is the best starting point to discuss other matters?
I'm not asking for any tools or notations, hope you can give me some ideas, thanks! |
|
|
|
 | |
|
|
|
| John_P wrote
Hello people,
I'm currently working on some process templates for the different decompostions: business process, sub-process, processtep, task. What i'm trying to do is to describe what elements are important on the different levels of detail. This way i want people to understand not to get into much detail when start modelling, and when it is the right time to discuss other matters. For example: processteps and tasks is where people deal with information, so let's talk about information. On the task level you will find (some) business rules, so let's get down discussng business rules etc.
So i have two questions:
So far i have very basic things like roles, documents, applications etc. but are focused on the last two levels of detail. What should a template for the bussines process, and sub-process hold? Do you people have any suggestions what is important to describe on the different levels of detail
And on what levels is the best starting point to discuss other matters?
I'm not asking for any tools or notations, hope you can give me some ideas, thanks!
|
Hi John,
I am not sure I follow or agree with some of you rbasic assumptions, like there are only so many levels of process decomposition, and that different things are dealt with at each level of decomposition. Why are you making the these assumptions? Are they based on some previous reading or research? If so, you may want to re-visit them for clarity, or move on to another view point. There are plenty of good books on process modeling, and on information modeling, for example.
All I can say is that I find that processes decompose to as many levels as needed; you usually stop when the level reached is the lowest for a complete activity and decomposing it further would produce incomplete activities.Information Requirements or Business Rules could be defined at any level, but most commonly at the lowest level.
David Wright |
|
|
|
| |
|
|
|
Hi,
I agree with David's comments and want to take them a stage further: as a trainer I get asked these questions on every course and I have some rules for when to split or merge processes at top level and guidance on lower levels. I also have guidance on what to document at each level. However, the thorny issue of templates always comes up...as a BA I have asked myself the question why have I developed a set of templates for documenting objectives, high level requirements, process models, data models and non-functional requirements? What was my motivation? My motivation was so that I didn't have to rethink what I need to do my analysis. And you know what? Every real project I apply them to I end up refining these templates to an extent. Why?
To cut to the chase: I think templates are a short cut - an aide memoire - a checklist so I don't have to re-invent the wheel. That is the nice way of putting it! Another way of putting it is that I am trying to cut down on the amount of thinking I have to do for each project - and it never completely works as I have to refine them! In other words, I have to think and cannot just follow my templates.
Worse still, my templates work for an extent for me - doesn't follow they will work for other people without refinement. So, templates, forms (remember SSADM???) and other frameworks should be used (are useful as) a starting point for analysis documentation and not an end point. They will never be complete and are unlikely to work for any project at all without some modifications (even just "n/a" is a modification!).
It gets worse than that in my practical experience: I have to agree with all the suppliers of information to the analysis process and the customers of that information that the way I am documenting the different components of analysis (the components needed don't change in my experience) is fit for their purposes - they can use them: suppliers for review and sign-off, customers for development and implementation. And guess what? Each project, organsiation, department (sometimes individuals!) have their own requirements on what I need to include/exclude on my 'templates'!
Bottom line: do what you need to do to do the analysis, not (necessarily!) what the template says.
If that analysis of templates is true, then simply put in the bare bones (title, description, author, date created is about it) and the rest of the templates is what the analyst needs to analyse.
Thems my thoughts - hope they're useful!
Guy |
|
|
|
| |
|
|
|
I completely understand Guy's point about keeping only the bare bones in a template. Much of what he said rings true. But in his excitement I think our friend took it too far ;-) It would be great if we all had every minute of the time we needed to do proper analysis on every project. However, I think we all would agree that it just isn't so.
Templates have several benefits:
- They save the experienced analyst a lot of time (which also means it can save money)
- They avoid missing certain types of information (if you created a new template every time do you think you would always remember to include the same things, or would you miss something)
- Templates help us lead projects that inevitably have less experienced analysts working on them (the template is a guide for inexperienced analyst)
To reiterate, I agree with much of what guy said in principle. Consider the following compromise:
- Start with a template for the analysis process. What artifacts should be created in different phases to create a successful and complete end product.
- Analyse the needs of the project and modify the analysis process to include artifacts that are relevant to your situation. Add new artifacts, and remove others.
- Find a template for each artifact.
- Evaluate each artifact template. Does it have what you need? If not add it. Does it have too much? If so, remove it.
In my experience the best way to use templates is to have a template that is adequate for most situations, but also have notes on template modification that accompany it. The notes convey that if the project has need "X" or need "Y" then certain sections or attributes of the template should be added or removed. Modify these notes based on the outcome of each project. Inevitably, you learn something in each project that modifies the template in a way you had never considerd.
Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile |
|
|
|
| |
|
|
|
Chris,
Basically I agree with (almost!) everything you said. The idea of having "notes on template modification that accompany it [the template]" is excellent as it allows the analyst using the template to mod it when they need to because of what they need to analyse.
The only point I would not subscribe to is " It would be great if we all had every minute of the time we needed to do proper analysis on every project." If we don't do proper analysis (or analyse, document and escalate the risks and issues of not doing so) then who on a project will do the analytical thinking that needs to be done?
As a trainer I have debates every course with analysts who say they are not given enough resource (time, money, analysts) to do a proper job but then go on and do an incomplete job anyway. As an analyst I also have this debate with the Project Manager(s) of every project I have worked on. In either case the correct response is a full documented analysis of the issue of not being able to do the necessary work and a full documented analysis of the risks (normally of project failure) of not doing so.
These belong on the project risks and issues log and should be reviewed every project meeting until resolved (perhaps by doing the project analysis ??? :-) )
Anyway, as you rightly observe I get carried away and I hope I am not over-labouring this point as I also said I basically agree with everything you said.
Guy
|
|
|
|
| |