Skip to Content

ID-100137855.jpg“We want to change the business rules.”  I hear that a lot as a senior manager in Accenture’s Technology Consulting practice – when delivering 9-month+ projects, often customer preferences or market conditions have changed by the time a project goes from design through to deployment. Another symptom is the reluctance to sign off designs – “how can we (a business unit) sign off designs now when we don’t yet have our [insert relevant campaign here] worked out?”

I recently worked with a large utility company to implement SAP dunning by Collections Strategy, utilising BRF+ and Decision Service Management (DSM) as the repository of business rules. Flexibility in changing business rules in Credit and Collections is a must for companies with large debt books, as it enables their credit department to:

  1. make their collections rules progressively more targeted, as they become more and more sophisticated with their analytics and customer segmentation
  2. add more sophisticated customer characteristics (e.g. components of credit risk scores) as the data becomes more readily available
  3. adapt their rules to changing macro-economic conditions (e.g. recessions, political climates, etc) or changing customer behaviours (e.g. greater mobile use, email use)
  4. respond rapidly to unforeseen events such as bushfires

Building flexibility into the platform is essentially an acknowledgement that no company can predict at the present time the products and collections paths that their future customer base will respond best to at some later time. (Sales and Marketing is probably the other obvious candidate for BRF+/DSM). Accenture’s New Energy Consumer research[1] consistently finds that energy consumer preferences are changing rapidly and that the preferred mode of communication is not consistent across different demographics and consumer segments. In addition, with digital disruption gathering pace and uncertain economic times, locking in business rules 9 months ahead of deployment robs a company of the agility they require for success.

We achieved this agility on my most recent project with SAP’s BRF+ framework stored in a central DSM repository. The BRF+ framework enabled us to explicitly call out and encode business logic in a rules repository which could be changed in the production system via a hot deployment (no transports required). We therefore gave business users visibility of the business rules (a benefit in and of itself) and furthermore the power to change them.

So the answer to the statement: “We want to change the business rules”, now becomes – go for it, not via submitting a change request into IT to change some code, nor even via a service request to change a configuration value in a custom table, but by taking direct ownership of the logic and making the change (with all the possible consequences) yourself.

It’s important to realise that this is not the (in my view, unrealistic and unnecessary) utopian dream of business users “writing” code through Business Process Management software, where no technical skills are required to get the software to do what the business wants. Quite the contrary – it is a highly designed system where business rules are deliberately abstracted out and encoded in BRF+, with the rest of the logic remaining written in ABAP. Architecting this becomes the core challenge for the solution team.

The use of DSM / BRF+ is, though, still a step change away from the traditional Software Development Life Cycle, requiring a paradigm shift in IT operations and business units:

  1. Governance – The SLDC has well-understood stage gates and approval processes before code is released into production (e.g. System testing, User Acceptance Testing, Dress Rehearsals, etc). Similar stage gates and approvals need to be developed for business units with the new power to deploy into production. With great power comes great responsibility.
  2. Testing – Again, IT delivery organisations often understand concepts of testing scope and coming up with test conditions (edge cases, etc) better than business units. We used the automated test case tool in of DSM as part of the project to build a regression test suite (more than 3000 test cases) for the business unit to use and keep up to date. This skill-set needs to be taken on by the business.
  3. Who “owns” production stability? – Prior to this, it was very clear who owned the stability of the system – IT operations. If anything went wrong (between requirements and delivery), the accountability would fall on IT. With the business having the power to make changes directly, with the potential positive and negative consequences that could ensue from the change, a more shared responsibility is appropriate and a process for working together to resolve issues is required.
  4. Business vs Technical knowledge – It is true that to change a BRF+ rule takes minimal time and seems very simple for any of us with technical backgrounds. It is therefore tempting to expect business users (without technical backgrounds) to be able to pick this up and do it correctly. In my view this is unrealistic, and attempting to resolve this by simplifying the UI to make it more business friendly simply reduces the potency of the framework. Business units will need at least a couple of “super-users” with some technical background – if you like, the sort of people who can read pseudo-code but couldn’t write code themselves.

In summary, BRF+ with DSM is a toolset that enables organisations to respond flexibly to rapidly changing market conditions and customer preferences. It is not a silver bullet and most certainly does not do away with IT altogether – but properly designed, it can abstract business rules such that business users can have direct visibility and control over the logic that runs their business. This direct control is not something to be entered into lightly and requires an operating model change in both IT Operations and the business units using it. The rewards are worth it though – an agile business that can progressively improve its performance through tweaking the business rules that govern its software.


[1] An annual global survey which has to date surveyed more than 60,000 energy consumers and more than 2000 small to medium enterprises across 26 countries. See https://www.accenture.com/us-en/insight-unleashing-business-value-main.aspx

[2] Image taken from www.freedigitalphotos.net

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Jocelyn Dart

    Thanks for sharing Dom. 

    As someone involved in the project – if only from the sidelines – it was a real showcase of the kind of innovation that can be achieved with Business Rules in the mix.

    A real credit to you and your team!

    (0) 
  2. Carsten Ziegler

    Thanks a lot for shraring and kudos to all the folks involved.

    You describe a situation and solution approach typical for many customer projects I was involved.

    (0) 
  3. Mohammed Muzammil

    Dear Dom,

    Your article is very interesting and you have written it in a very engaging manner.

    We have implemented BRF+ in the present utility project that I am working in, however the entire work was done from the IT team at client location. You have in a nutshell explained the benefits of BRF+. I wonder what approach should one take as a technical person for learning it 😕

    Any thought on this? Am curious.

    Thanks

    Regards,

    Mohammed Muzammil.

    (0) 
    1. Dom Mendonca Post author

      Hey Mohammed,

      Thanks! Re learning BRF+ from a technical perspective, on my project we bought this book which Carsten wrote – BRFplus—Business Rule Management for ABAP Applications. This was a good head start for the team.


      Regarding solutioning which rules to abstract out and how, that really requires a strong understanding of client needs and hence very close engagement with the client. We ended up building it offshore but doing the bulk of the design work at the client location.


      Regards,

      Dom

      (0) 

Leave a Reply