Exercitation ullamco laboris nis aliquip sed conseqrure dolorn repreh deris ptate velit ecepteur duis.
Close
Words from our community
Setting up purchase order approval workflows in S/4HANA
An SAP Functional Consultant tells us about his experience setting up BRF+ to support the workflows.
Q: First of all, what was the background of the workflow implementation?
A: I have been involved in a project to implement SAP S/4HANA in a multi-entity organisation. The project started a few years ago and went live in 2018. This was a greenfield SAP implementation, as the organisation had previously used various legacy systems to carry out their processes.
Most of the business processes were moved into SAP and various workflows had to be built from scratch in SAP, including those for purchase order (PO) approval.
Q: What is your background and how did you get involved in this project?
A: I am an SAP Functional Consultant who formed part of the project team responsible for the SAP implementation. Specifically, I am a Team Lead for Logistics workstream, which was responsible for implementing the PO approval process.
Q: What were the key decisions which had to be made in designing the workflows?
A: The workflows had to be designed by the business and we helped them reflect these in SAP.
SAP has a standard release functionality; however, it was not able to meet client requirements. Additional mechanisms were required on top of this standard functionality. We had two choices: 1) Either build custom programmes and tables, or 2) use BRF+.
Building custom solutions would have been the usual way of solving this problem. However, given that in S/4HANA, output management relied heavily on BRF+, we decided to have a serious look at this solution.
We were attracted to BRF+ as it was an available solution in SAP which could fulfil our requirements without much need for customisation. It took a bit of effort to convince the business; but we were fortunate to have a few consultants on our team who had had positive experiences with BRF+ and were able to apply their knowledge in this implementation. Both factors helped in the decision-making process to go with BRF+.
Q: How was BRF+ used in the project?
A: BRF+ was used to build various business rules across all Logistics processes. In the PO release workflows, the release rules were built in BRF+ tables. These tables determined where POs should be routed (i.e., based on PO value, purchasing group, etc., which users would need to release the PO).
Outside of these workflows, BRF+ was also used in certain validation rules. For example, when a user entered a material number during a transaction, other fields relating to this material were automatically entered. These values were fetched from a table stored in BRF+.
Once BRF+ tables were setup, the relationships captured in the tables would automatically generate function modules that would be called by existing relevant programmes. Without BRF+, the function modules would need to be modified.
It is worth noting that other standard customising activities still had to be performed in SAP. For example, in the PO release process, we still had to configure the release strategies, release codes, and so on as part of IMG Customizing in SAP. BRF+ simply contained the rules which determined where the PO should be routed for release.
Q: Was there an authorisation-element in the PO release implementation?
A: As per any PO release process, a user can only release POs when they have been assigned specific authorisations through roles. We worked very closely with the GRC team in the implementation, led by Marcel, to build a solution which worked for the business.
Hence, the use of BRF+ did not eliminate the need for user authorisation assignments. Various roles had to be created to give access to release PO at different levels for different release criteria. Users who should have access to release PO were assigned the relevant role, based on the authorisation matrix.
The BRF+ tables capture the relationships between release rules and these users. The initial design was to link release rules to user-IDs. However, after go-live it was found that this design could not keep up with dynamic changes in user-IDs. Therefore, a decision was made to link release rules to roles instead. This means the BRF+ tables would not need to be updated when a user change happens.
Q: Other than what was mentioned in the previous point, what were difficulties relating to the authorisation portion of the implementation?
A: SAP authorisation concept is unique and generally can be very difficult to understand by people who have not used it before, especially if they have run their business mainly offline. SAP’s strict authorisation restrictions can also be a challenge to grasp, especially when compared to other systems which generally allow users to have wider access than they need. Once business users understand the basic authorisation concept, communication generally becomes easier.
For the PO release process in particular, some business users found the authorisation matrix difficult to understand. This was further complicated by various SAP terminologies relating to the release process. However, once understood, the design process went more smoothly.
As we go into business-as-usual, a typical complexity would involve segregation of duties (or lack of), which would usually happen when department does not have enough users. As a result, conflicting authorisations are assigned to the same user, resulting in an SOD violation.
Q: It seems BRF+ underpins much of the PO approval process. What is the feedback from the business about the use of BRF+?
A: To be honest, the activities conducted in BRF+ are not transparent to end users. From the business point-of-view, BRF+ is only known to certain business process owners who are involved in maintaining business logics and requirements. The end user sees no difference whether custom SAP programmes or BRF+ is used.
BRF+ has a user-friendly frontend on which users can define business rules; so rather than having to dive into SAP configurations, business users can implement such business decisions themselves. For example, if there is a change in the PO release workflow rules, this can be entered on the frontend by the business and subsequently reflected in the backend BRF+ tables.
However, while BRF+ is relatively user-friendly, users who are not used to SAP may not find it to be so intuitive to use. Therefore, business users involved would need special training to get them familiar with the system.
Q: What advice would you give to someone who is about to implement the PO release workflows in SAP?
A: I would recommend that BRF+ be considered if your workflows are complicated. Some of my advice would be:
- BRF+ implementation requires special expertise. I would recommend having someone experienced in BRF+ on your team, to gain the full benefits of the solution.
- When used in the PO release process, avoid linking release rules to user-IDs. Link rules to roles instead.
- BRF+ configuration must be aligned with the authorization matrix of roles and values therein.
- Finally, remember that the design ultimately has to meet business requirements.
Click here to go back to the main newsletter page.
Get our newsletter delivered to your inbox monthly
Blog posts, webinars, tips and more! Make sure you don’t miss out by signing up for our newsletter.