Release strategy Vs Workflow release of purchasing documents

[ronen_weisz]

Release strategy only (standard workflow) – the workflow plays a secondary rule in this case simply informing users of the document waiting for approval and linking them to the relevant approval transaction (ME54N,ME29N etc.)

The good

• Very simple, easy to implement standard workflows.
• No development needed

The bad

• Approver changes require customizing and transports.
• Can lead to a very large and hard to maintain number of release strategies.
• No data transfer (comments) from one approver to the other.
• Difficult to read approval logs (change documents).
• No parallel approval can cause a line based release strategy (purchase requisition) which is relevant must of the time to a single release level. For example the first approver is a professional approver based on the material group; the other approvers however are usually the same managers and now get a large number of approvals for every requisition. 
• Rejection can be difficult:
  • In some documents there is a reject button (purchase order & requisition) but not in all of them (Contract & service entry sheet).
  • Can cause the addition of the document creator to the release strategy in order to be able to reject to the creator
  • Authorization problems – since the approvers might want to reject one level back by canceling the previous release they will need double authorizations.
• Number of approvers limited to 8.
•  

Decision task workflow release based on a simple release strategy – in this case the release strategy determines only the basic number of approvers usually based on document value.

The good

• Approvers can be changed easily via workflow rules
• Only a few release strategies
• Comments can be transferred from one approver to another (via a bit of development)
• Approval (workflow) logs are easy to read.
• Rejection is easy to do.
• Parallel approval can be done.
• Additional people involved in the process can be added: an assets manger which doesn't approve but is required to check the correct assets are maintained in the document, an option to request the legal department review can be added to the user's options etc.

The bad

• Requires development

Workflow release only – in this case the release strategy is reduced to a single general release step. All the approvers are determined by the workflow. Approvers use a decision task to approve the document.

The good

• Approvers can be changed easily via workflow rules
• No release strategy maintenance 
• Comments are transferred from one approver to another.
• Approval (workflow) logs are easy to read.
• Rejection is easy to do.
• Parallel approval can be done.
• Additional people involved in the process can be added (same as previous option)
• Approvers can be easily skipped, for example if the economics department approved the purchase requisition and no changes have been made in the transfer to the purchase order, no need for them to approve again.

The bad

• Requires development
• The users can't see the expected number of approvers from the purchasing transactions.
• QA checks might be harder to do.
• Changes need to be tracked during the approval process; since there is only one step in the release strategy changes that usually reset it (an increase in value for example) have no effect. 

Dear moderators/space editors, I wanted to ask you to make this (and thisWhether or not to use HR organizational module in workflow rules? ) into polls, I think that these are dilemmas faced many times and that it will be nice to see which of the options people use in their organizations.