Having variations of same business process, How to model?

[kimmo_sirpoma]

Customer has variations of the same business process. What is the best practise to model such situations? To define just one business process or many?

Example1:

The main business process would be Sales order management.

Sales orders could be processed differently if created manually (variation1) or by incoming interface (variation2).

Example2:

The main business process would be Sales Distribution.

Distribution process could be different if done by train or by truck.

Maybe above example makes no sence to you, but you got my point I suppose.

Actually my question derives from Solution manager's Project implementation tools and how to define business processes there. Should I define different variations as their own business processes having their own process steps or just one business process and multiple process steps ( like entering process step 'Create Sales Order manually' and 'Create Sales Order from Interface' )?

What I had in mind, was that by choosing the way of describing the variations of same business process, will I have later some impacts on BPEL processing or ARIS or elsewhere? I mean, in business process rules I anyway need to branch "if order created by Interface, do this...else do this....".

I will create a reference of this thread also in Solution manager forum, to have more readers...

Best regards,

Kimmo

[Former Member · Accepted solution]

What you use is a business rule. Your decision to use truck or train triggers a business rule that goes a different path. E.g. the truck might require more screens to fill out than the train.

That means you have to model those two branches from the place where the business rule kicks in. if Train, then go Variant 1, if Truck then go Variant 2.

Your model has to reflect that.

If the differences are minimal (only different values, but in the same fields), the business rule influences the available data of the screen; but if the data is significantly different, then it needs to be treated like a separate sub-process.

[kimmo_sirpoma · Accepted solution]

Thanks Mario,

Unfortunately Solution manager does not support SubProcesses. As you know SolMan SOLAR01 only supports hierarchy 'business scenario'->'business processes'->'business process steps'. What is missing is 'sub business processes' node under 'business processes'. In current SolMan version your term 'subprocess' would mean another business process like:

business process #1 = sales order handling; via interfaces

business process #2 = sales order handling; manual entry

More opinions are still welcome, especially how having separate business processes or not to have, would effect later if business processes are to be converted to real BPEL driven processes.

br: Kimmo

[former_member190969]

Hi Kimmo,

I wouldn't use process steps to refine processes. This is incompatible to SAP implementation content coming from BPR (Business Process Repository). But a good idea would be to copy the main business process e.g. "Sales order processing" into two new processes on the same level, e.g. "Sales order processing by manual input" (variation1) or "Sales order processing by incoming interface" (variation2). Then you can use the Compare Button on the variations to see if any changes have been on the main business process and copy them to the variations. This minimizes the effort to keep track of changes after creating the variations. When you run transaction SA_PROJECT_UPGRADE on that project these changes even get flagged. Mostly this function is used to upgrade against BPR or a template project but it works also for copies inside a project e.g. to model variations.

Regards

Andreas