Skip to Content
Author's profile photo Former Member

From #SAPTechEd – Coolest BPM Implementations – Using Business Rules to Automate Process Steps in BPM Processes at Ericsson

In my SAP TechEd Presentation PMC 114, I presented 5 “coolest” BPM customer implementations that customers have shared over the last 18 months. 

One of the coolest implementations I profiled was Ericsson’s global supplier master data create and update processes.  This implementation leveraged SAP NetWeaver Master Data Management (MDM), SAP NetWeaver Business Process Management (BPM), and SAP NetWeaver Business Rules Management (BRM) to streamline and automate a global business process that allowed business users to directly enter new supplier master data into Ericsson’s systems without having to work through a master data governance team.

Streamlining of data governance processes for master data is among one of the most common applications of SAP’s BPM tooling.  What makes Ericsson’s implementation stand out is their clever use of business rules to add intelligence to the user experience.   By making the UI smarter and able to guide business users, Ericsson is able to eliminate an extra manual step by a master data administrator that most other MDM implementations require.

One of the complexities of trying to manage business partner data of customers or partners globally is dealing with country or region specific fields such as tax numbers or payment methods.  In a data governance process, this typically results in needing a master data specialist for a specific country to be in charge of entering and checking locally-required fields for a new business partner master data record.  And, a few run of the mill BPM processes I’ve seen implemented by some SAP partners directly orchestrates this process step into the BPMN flow.

In the case of Ericsson, business rules were added to the BPM process and managed in SAP NetWeaver BRM to help guide business users in knowing what required fields for suppliers were according to the countries they are based in, and serve for Ericsson.  These rules covered data such as payment method, banking details, tax numbers and withholding requirements, business partner roles in SAP, DUNS numbers, and vendor returns.   By adding business rules in BRM, country-specific specialists no longer need to be involved in every new supplier create request.  Instead they can focus on refining business rules whenever country requirements change, and resolving exceptions.


See the screencam video of Ericssons user experience below to see how these business rules provide immediate feedback to business users, thus making the user experience more friendly for business users.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Hello Chase:
      Yes it is a nice case study of using BRM with BPM, on the UI side. Usually BRM will be used as decision tables, functions etc. as part of the BPM process.

      At the Client(A major softdrink maker, in TX, USA)I worked lately, we used this same principle in a Product/Material master data project, more elaborately. Like ...
      (1) There are more than 250 attributes to the master data record.
      (2) These attributes have intricate relationships like mutually exclusive, mutually associative, arithematically proportional etc. (3) These relationships were formulated in to business rules, embedded in to each cell of a spreadsheet, in N x N grid, where N is the total number of attributes in the master record.
      (4) More complex requirement is that these 250 attributes were divided between different department, so each department master data attributes were separated in to a page-tab each on the web dynpro UI. So any department can only edit their own attributes, not any other attributes etc.
      (5) The functional requirements mentioned above 2, 3, and 4 were all managed by separate calls to BRM engine and UI was rendered based on the results given by BRM rules.

      At the end, every one was happy 🙂

      PS: There were some short comings in both BPM and BRM features as of now, and hopefully they will be rectified/fulfilled soon.

      - Prasad Nutalapati

      Author's profile photo Former Member
      Former Member
      Nice blog.Myself and Prasad were at the same client.We followed the same way as you mentioned in the blog.

      Main idea behind going for BRM is to give more flexibility for the business to change the rules at runtime without any development effort.correct ?

      So, Modeling the BRM properly is very important .
      1.What happens if business wants to add additional attribute in "purchasing org" scenario.
      2. Removing few fields from decision table
      3. Rules may be bit more complex, like one field may dependent on combination of two/more other fields on the UI.

      There should not any tight coupling/dependency between the UI layer (webDynpro) and BRM.

      Designing the webDynpro and BRM should be in such a way that whenever rule/decision table changes it should be reflected in webdynpro with out any development effort.

      It would be nice if you can share on how they modeled the webdynpro in above scenario.

      Appreciate your comments on this

      Thanks, Anil