The Most Important and Most Neglected - Business Rules

Over the years the most important issue I have seen neglected on a transofrmation project is an honest thoughtful discussion on Business Rules. What should the process look like under the different conditions. Business rules come in all forms and levels of complexity. I share a few examples below for the purpose of clarity.

 

A healthcare provider member who wishes to renew her policy for her 7 year old child and 19 year old college student. The business requirement can have different rules, here are some:

• Rule A: Income Level: Family is low income and hence have an extra 10 day grace period
• Rule B: Residence: Family lives in rural counties of the state and hence is eligible for a 45 renewal window, versus same family living in the major cities of the state which has only a 30 day window for renewal.
• Rule C: Age: 19 year old child reached his 19th birthday less than 90 days prior to his policy expiration is treated differently than more than 90 days prior to expeiration date.

 

An example from the supply chain vertical related to demand forecasting and planning could be dependent on order cancellation business rules, for example:

• Rule A: Orders returned due to defective items that are reordered on the same order, should not be removed from demand
• Rule B: Orders returned due to defective items and are reordered on a new order, should be removed from the demand of the month of order, and reapplied to the month of the new order.

 

Projects of all sizes usually neglect business rules when designing and delivering a system. Business rules are the most important part of the process, for indeed that is where decisions are made. Decisions are where the bug are found in the system. Poorly thought through business rules automatically equates to bugs, miscalculations, data quality issues, rework, frustration and utlimately redsign and worse sometime a compelte overhaul of the architecture

 

 

The Cookie Cutter Project

We all come across these straight forward projects, right? The project that was done half a dozen times before, that it almost feels like an operation to the project team. Deploying a new infrastructure at the fifth location of the company, or extending an automated software application service to a new region after three successful deployments elsewhere. Sounds familiar?

Many project teams come across these cookie cutter projects each year, and also many of them end up having a hiccup. NASA shuttle program is one well publicized example. It was not the first few times a mission was launched when it blew up into flames. The program has been very successful for years with dozens of missions. Smaller projects experience the same. Several things project teams need to keep in mind with cookie cutter projects are:

Projects are Projects
A project is still a project, even if done before in a similar context. the fact that a scope of work has been identified by someone as a project means it inherently has some risk, and is deemed by the some in the organization to require closer baby-sitting than a typical operation. On a recent project I was leading for a high tech materials company supply chain, the team viewed the project as a cookie cutter and saw no need for tight toll gates, reviews and checks and balances. After all it was their fifth time to deploy this service for ordering the end product by their business customers. It took extensive coaching and education to explain to the team that if the project came to us, it means that the supply chain service line, as well as the IT PMO have determined it unique enough to be staffed as a project, rather than an operation.

Identical is not Similar
Studying geometry in eight grade was not a total waste for those who did not end up studying engineering. Similar and identical triangles are not the same. Unless a project is identical, to a previous project it should be considered unique and requires progressive analysis. Similar projects will have one-off requirements, or some special handling, or a change that occurred since the latest iteration of the similar project. This is exactly what happened with my project, during the time between the latest deployment at location A and the deployment at location B was five months. A couple of key processes changed across the the supply chain on the other side of the ocean. This change added risk and requirements that location A did not need to deal with. the project team for location B was not aware of this enterprise level change. Similar is not identical.

Humility Pays Back
We all are well aware of Titanic, the vessel that supposedly would survive a crisis in the middle of the water. Watching reconstruction videos of airplane mishaps occurring 40,000 feet high over a vast ocean, and how these failures were resolved has been not only intriguing for me as an engineer and project manager, but also an eye opener. No matter how advanced we human beings become, no matter how many sensors we have on an aircraft, or an Internet of Things (IoT), we will never beat the power of unknowns and unseen, nature and the Creator's will. Humility in dealing with projects' technical scope, technology, science, external factors, human behavior and automated electronic processes that usually run in the background undocumented properly is just good business sense at minimum.

So a cookie cutter project is more than a cookie, its a cake with some custom toppings that could mess up the whole cake if not properly placed.

Enjoy the cake !

Risk Management and Normalization of Risk

Once in a while we come across a failed project, poor decision or worse a catastrophe. The individual or team behind the decision might be very well experienced. When teams take on risks and plan well ahead for the impacts of these potential scenarios, they build competence and are well equipped to handle these risks. However is many situations the risks are mitigated and no negative impact is ever realized, causing teams to be more aggressive in risk taking, and hence the normalization.


In other words, successes and error-free delivery could lead us to gradually accepting higher levels of risks simply because the subsequent effect from a previous risk never occurred. When this normalization occurs we start to operate outside of acceptable parameters without realizing, potentially falling into trouble.

SAP Planning Areas Considerations

Without fine tuning your cloud implementation you might realize less than optimum performance without even noticing. This post shares some recommendations that could fine tune an SAP planning view performance.


Sizing
Verify sizing post implementation is accurate after data is loaded as part of go-live activities. Sizing includes data storage, processing memory, data density (number of relevant data output per time period), ex: 1 sale per month, will not be caught in the weekly runs), and safety factors. Processing data on a more frequent basis and keeping the results on the planning view affects the remaining free resources (memory and storage). Sizing should be done during the cloud service acquisition, at end of blueprint, as part of performance testing and after go-live.


Configuration Complexity
Master data types and overall attributes should be kept as minimally as required. Usually clients use 20%-40% of the attributes they have defined in their implementations impacting performance with no true business value realization. Using non-key figure attributes of master data types as root attribute in a planning level is another approach to improve performance. Minimizing the number of calculations that include input levels is another way to improve performance, however care should be taken to avoid the need to increase the number of key figure values needed to store data. On the fly transformations should also be avoided to avoid performance bottlenecks.


Calculations
The approach used to perform calculations can significantly impact performance. Examples are the selection of key figures for a calculation, the calculation chain, stored key figures inputs, key figures base planning levels, placement and configuration of filters among other factors.


Planning Views
Keeping planning views to a reasonable number of rows is a generally recommended practice. Usually setting the rows to 2000 - 5000 does not impact performance negatively. Utilizing VBA-based templates instead of formula-based templates is another approach to improve performance as recommended by SAP. Using filters in templates when saving and opening templates is highly recommended to ensure reasonable load times. In SAP 1708 users will receive a warning message if no filters are defined in a planning view.


Running Operators as User-Defined Scenarios
Algorithms such as multi-stage inventory optimization affect the whole supply chain network. This large run-time can cause time-outs when run in simulation mode. A recommendation is to run these simulations as user-defined scenarios for improved performance.