BI and ESA driven approach to SAP project implementations - Part 3

Where are we now?



We walked down the memory lane, and relived the experience of information inefficiencies in our SAP projects.

We analyzed some reasons why the traditional implementation methods leave a lot to be desired.
I guess it is about time we got around to solving this mess.



Let us try to set the context.



Consider the process of building a house. You start by sitting down with an architect who will convert your ideas into a tangible thing – a blue print. What happens then? A structural engineer takes this blueprint as input, and converts this into a series of technical drawings and specifications. These are then expanded upon by the electricians, masons and plumbers etc as they build different parts of the house.



We can take a similar approach in our SAP projects too. In fact, we do have (or claim to have) a blueprinting phase in most of our projects.



What is the significant difference between an SAP blueprinting activity and that of building a house?



In the case of a house – we follow a tops-down approach. We give our ideas to the architect, who will put it all together, along with things he has learned over the years from other clients – and set down tangible things for the structural engineer to look at. Engineer does the same for the electrician, mason etc.



In SAP blueprinting, we assume that the SAP software is inherently tightly integrated, and hence a bottoms up approach is just fine. We start by concentrating on the order to cash process, procure to pay process etc and assume that it will all somehow build up to a nice whole solution at the end, due to the inbuilt integration aspects of SAP.



Seldom does everything go according to plan – whether we are building a house or implementing SAP. The plumber might find that he is unable to find the same size piping that the engineer specified. What happens now? Either the plumber goes ahead with whatever is available in the market, or he goes back to the engineer with this information. If he goes ahead with his own ideas without checking back with the engineer, it can become a sizeable issue later on. If he checks with the engineer, the latter will be able to take a decision with the least impact to the design, time and budget. It is also expected that the engineer checks back with the architect if this affects the usability of any aspect of the house. Finally, if the original vision needs to be changed, the architect is expected to check with you, the guy paying the bills – who has to live in the house after every one else involved in the building process goes off in their separate ways.



In SAP, especially with the advent of specialized suites like CRM and SRM, it is not longer safe to assume that SAP will inherently take care of the integration aspects. A good example is business partner master data. You might have a channel partner in your CRM system, who is also a sold to party in your ECC system, and a vendor in your SRM system. SAP doesn’t care if you treat them the same or as disparate entities, since all the business rules you configure are within a given system (say CRM) and not within your solution (which has CRM, ECC, SRM and maybe legacy systems).



Unless you make a conscious effort to design it well (say with MDM and/or BI ), the chances are that you will never know that these business partners are all the same. What is the big deal if you don’t know they are the same? Well, you lose out on the big picture. Example : Say you have two types of relationships with another company – you buy some things from them, and you sell some things to them. At any point of time, you typically have money coming in from them, and money going out to them. If you cannot establish the fact that the vendor and customer are the same company, you won’t be able to optimize your cash flow, credit management etc.



How do we ensure that all of these different data points play well with each other?



To begin with, we need to find the one place where they all come together.



Who needs all of the data well integrated?



Is it the sales and distribution guy? Is it the lady who manages the inventory? Is it the finance clerk who pays invoices? The answer – and no points for guessing – is none of the above. It is the folks who look over multiple domains that need all the dots connected. Example : the VP who runs both sales and marketing finds it invaluable to know if he can compare marketing spend with sales revenue. The COO, CFO and CEO are typically interested in comparing data across all the domains to make sure the company is healthy and growing.



The first step then, is to find out how these people manage their company – in quantitative terms.



This is not as hard or insurmountable as it seems. People at this level usually manage information at an aggregated level. I like to start with analyzing how the business is planned and budgeted. The logic is simple – they expect to compare actual data with this planned/budgeted data to make their decisions. If you got the plan/budget covered – you have the actual data (at the aggregated level) covered too. Looking at the budget at the topmost level – you can identify the minimum dimensions that you need in your data model. This is where account modeling becomes your best friend. Represent each KPI as a measure, and list the characteristics by which they are measured. After you are done representing all your KPIs – you would arrive at something like this for example. Here I am considering just 2 domains – sales and marketing. In real life, you have to consider all applicable domains.





Business Partner Group Product Type Quarter Measure Amount
Revenue
Marketing Spend
..
..



The one thing you have to watch out is – only list those dimensions that are common across KPIs at this level. For example – You typically sell at a material number level, but market at a product type level. So – you cannot compare sales and marketing spend at a material number level. If you try to do it, you will need some sort of an allocation rule that splits your product type to all products– and from that point you start reducing the purity of the data. In budgeting, it is a valid process to allocate like this – but the moment you start splitting your actual data (the real dollars), you are spoiling the quality of the data. You can do this for “what if analysis” etc, but do not treat this as the “truth”.



You can now start going down the org hierarchy and filling in the next level of KPIs, thereby expanding your data model. This is an important aspect of the exercise – after all the VP cannot run the company all by himself. The guys reporting to him will need a more granular view of the data to manage their responsibilities. Again, budgeting is a great place to start from. Budgeting is typically a top down operation in most companies. Example : If the VP budgets by Business partner groups, probably the guy next down in the hierarchy will split it by geographies.



Keep going in this fashion, till you reach the operational reports. At this level – you may or may not find budgeting information to help you. But do not despair – this is where the existing legacy reports come into play. They will help you get started to find the lowest level information that needs to be reported on.



Needless to say – do not just trust documented information made available to you. You should talk to the users and make necessary adjustments. It is very common for users to take a canned report, and manipulate it on their desktops. So make sure you verify the validity of existing reports etc.



What do we do with all the information we compiled so far?



It is time to talk to the folks implementing the order to cash process etc. Each “measure” you figured out typically has at least one transaction that creates this data in the system. Example: Revenue might be from SAP sales orders. You know all the characteristics that the business is interested in to measure that KPI. So, armed with this information – start a discussion (which is nothing but a gap analysis) . The idea is that there should be a way to attach all the business-relevant characteristics to the transaction.



Let us consider one of the pain points we discussed in the previous blog. The case in point is that of identifying a customer segment in marketing spend transactions. If the customer belongs to only one segment, you do not need to hold the segment explicitly in the transaction, since it can be uniquely determined from the master data. However, what if the customer belongs to multiple segments? You cannot determine the segment automatically in this case. So you are better off asking a user to choose the segment from a list of possible values in this case.



This also provides an opportunity to take a look at the possibility of changing a business process. Example: Say the business user budgets marketing spend by customer segment. However, the transactions never capture segment. You should go back to the business and ask them if they see sufficient value in capturing the segment information in transactions. Explain to them the details of what it takes to capture segment – maybe an SAP enhancement, retraining hundreds of users, maintaining more master data etc. The business might just realize that it is not of great value to measure KPIs by segment any more. After you go through all the measures in this fashion, you should have the transactions designed in such a fashion that they will contain the characteristics that your business users are interested in (or have a well defined look-up rule to find a characteristic from some other field) . This is not to say that transactions will not have any additional fields – they might need all kinds of extra fields to hold things together.



This information – which serves as a common base for the business intelligence guys, transaction system guys and the business users, is invaluable to an organization. In the next blog, we will explore the physical implementation options in the system – and what a business process expert needs to know in terms of the options available to him/her.