Introduction
In this blog, I want to discuss the process methodology for designing a business process. Within the first blog, I gave an example of a business scenario and the role of the BPX in that scenario. I've had lots of people ask how I came up with the scenario, so this blog will explain the thought process for process oriented thinking. This is key for the BPX.Designing with Process Oriented Thinking for ERP
Traditionally, ERP solutions have multiple business areas. For example, with ERP, there is a solution for "Sales & Distribution" (SD) and there is another component for your financials (COPA). These components are related as documents will flow from sales to finance if you are recognizing revenue or cost on the sales transactions. Therefore, understanding this process in ERP is key. How does one know which sales documents will affect financials? This typically may be certain "Sales doc types". If you have some business users that work in the financial area, and have some business users that work in sales area, they may not be aware of what is going on in the other areas. Here, a BPX will have to come in and take a process oriented view. For example, many businesses may decide to use the month to date sales to project what the revenue will look like at the end of month. Therefore, you will need to understand the business process on how transactions flow from SD to Finance. Knowing these sales document types that affect revenue is extremely important if you are to build reporting or analytical solutions to project revenue. This provides the motivation for the BPX to approach this business scenario with a "process oriented" thinking view. If the BPX looked at components, they would not be able to effectively build out this scenario. Therefore, they will need to know the sales document types to restrict in the BI queries to be able to look at this data. The next section talks about utilizing this process oriented knowledge to build out a model to look at revenue from your BI solution.Designing with Process Oriented Thinking for BI
Traditionally, Business Intelligence solutions in general have been great for modeling data into a logical data model. Once these logical data models exist, the Business Intelligence users usually can use these tools to drilldown or slice and dice data however they see fit. The SAP NetWeaver BI solutions allow OLAP (online analytical processing) which allows users to slice and dice data without really knowing what they are looking for. They can run a report and then choose which fields based on what is in the data model. This is "adhoc" based thinking. Over time, however, users have become more analytical and now typically know their drilldown path to make efficient decisions. Therefore, these analytical users have evolved to become business process experts. They know the business so well that they can decide the optimal drilldown path to look at data. There will be people within the business that may still be in the discovery stage and will be looking at multiple different fields to try and find where problems occur within the business.The BPX, in general, has been through this. Therefore, the BPX can design applications that take users down this optimal navigation path. This actually now allows the users in the business to navigate the optimal path of information and take advantage of the optimal path developed by the BPX. An example is as follows:
For a typical BI solution, if you wanted to look at Revenue YTD, you would design a query with many free characteristics. You may decide to start with country as your default view because you are saying that most users will probably want to start with a view by Country. See this report below:
Figure 1 - Adhoc Web Analysis
When looking at this adhoc BI report, users can now drilldown by any number of characteristics. This isn't process based thinking. This is adhoc based thinking. You are leaving the user options and they have to decide what the logical drilldown path is. Now let us assume that we have a BPX who has run this report many times and has found out that logically, the best thing to do is look at the data by Country. Once you are looking at a particular country, if there are issues with those numbers, the best way to look at the data next is by Sales Organization. Now, within these Sales Organization, you see a problem with one sales organization. Typically the problems only occur with a one or 2 customers within a Sales Organization, so that would be the next navigation path. Therefore, logically, the navigation path that is optimal is Country -> Sales Org -> Customer. This will, in 90% of the scenarios, allow you to analyze the Revenue YTD most effectively and will put the problem customers in front of you in the most optimal manner. Here, the BPX can build a model in Visual Composer that allows users to utilize this navigation path. See the model below:
Figure 2A - Country View in Visual Composer Model
Figure 2B - Sales Organization View in Visual Composer Model
Figure 2C - Customer View in Visual Composer Model
Therefore, we see that through Visual Composer the BPX is now thinking in terms of process oriented methodology. The only thing that enables the BPX to do this is experience. They need to know the data and know the business in order to determine the best "process" towards analyzing the data. This is the key to building out process based models. Therefore, we see the difference between traditional BI solutions versus process-oriented modeling solutions. The process oriented models do leverage the investement in your BI solutions. For example, as I said earlier, the optimized navigation path within the process oriented model will probably cover about 90% of the analysis that most users will follow. For the 10%, you still may need adhoc capabilities. In the screenshots below, the "Open Query" button launches the adhoc web analysis which allows users to choose their own navigation path. This will allow flexibility for different navigation paths all from this single point of entry!
Designing with Process Oriented Thinking for Analytics
So far, we looked at traditional ERP and BI solutions and how to build process oriented models off of these existing investments. The next steps is to build process models across systems and build navigation paths across these systems. For example, we may want to extend our navigation from the previous BI solution we discussed to this:Country -> Sales Org -> Customer -> (Customer from ERP)
This solution now starts allowing you to build navigation paths across any system. Therefore, you can really think about the process without having to worry about system dependencies on where the information is staged. As a BPX, this allows you more flexibility to build the navigation path that makes the most sense. Therefore, the "Process Oriented" thinking is king, not the "System Oriented" thinking. See the new customer detail tabwithin your model below:
Figure 3 - Customer View in Visual Composer with details from ERP!
The "Address" section in this form is customer details that are coming from your ERP system!
Designing with Process Oriented Thinking for Composites
So what is the difference between an analytic and a composite? Well, the analytic application allows you to analyze data, independent of system. The composite application allows you to CHANGE data within your source systems. Therefore you can take action directly from your composite application. In this scenario, we see the customer details. We may want to display all the open transactions for this customer that will affect revenue and make changes to these transactions. Therefore, the process oriented thinking would look as followsCountry -> Sales Org -> Customer -> Open Orders for Customer
This application will allow you to change the open orders, (for example cancel them if this customer is loosing you money), directly from this composite!
Summary
As we see in this blog, the BPX must know the process oriented model within the ERP system on how transactions flow across application components. Beyond that, they must know the optimal navigation path within BI and extend this back to ERP in your analytical application. Also, they must know the process to update these transactions and how this will affect the business as a whole. This whole thinking methodology requires business experience. It is no longer about the tools or the systems. The BPX needs to understand a little bit about the tools, but more importantly, they need to approach the business problems with an anlytical mindset based on process oriented thinking. This is the power of the BPX!What's coming in Part 3 of this BLOG?
As always, I'm open to what our BPX community wants to hear about. The reason I wrote about process oriented modeling in this blog is people asked for that in my first blog. Currently, I'm thinking about talking about handling business process change and building analytical models with modular building blocks such that you can react to the business quickly. Therefore, the BPX needs to understand modular design concepts such that they can react to rapidly changing business processes.
1 Comment