The warehousing benefit of the SAP business warehouse......

[Former Member]

Going around various organizations, I often hear complaints about how SAP BI/BW is "slow", "expensive", "rigid", and "carries long development cycles".  In the era of HANA, the prediction of BW's immediate demise resonates seemingly everywhere.

Yet, for all the years I have been working with SAP BW, I find it is a tremendous tool for both developers and self-servicing business users.  First coming to mind: It has a model driven GUI, and is database agnostic.  You don't need a DBA every time you want to touch a data model.  Even data staging, governance, and DB statistics come packaged within the graphical system administration tools and transactions.

Do you want to create a master data object with Attributes and Texts ? Go ahead open Tx RSD1, and fill in a few "forms" as in wizards.  The underlying tables and joins are created for you in the underlying database.  You don't need to have specific database and SQL knowledge.  Even in the wonderful world of HANA today, you need to bring a couple of wonderful tables into a join, define the join type as Text Join, and remember to add in the language column.

What about the "Long Development cycles" ? BW data model, even under the best practice, is a little extra compared to working directly with tables.  We see SAP trying hard to bring the "agile" and "fast" into BW:  Open ODS, ODP, Transient providers are a few.....

That still doesn't sound fast enough ? Well, have you visited a brick-and-mortar warehouse lately ? If you haven't, I encourage you to do so whenever you get a chance.  Large warehouses run by the likes of Fedex or UPS are a thing of beauty, if you enjoy watching well-run processes.

When I stopped by a warehouse the first time, I noticed one significant overhead--or a "waste of time": Incoming well-packed pallets were unpacked and had items individually scanned.  New pallets were built from scratch before being put onto the shelves.  It would have been obviously a lot quicker to directly put the inbound pallets onto the warehouse shelves, right ?   For that matter, shipping directly out of the manufacturing plant and skipping the warehouse step would be even faster ?  Yet, unless you are a mom-and-pop store-front operation, warehouse and warehouse processes are the necessary evil to bring out the efficiency, speed, and savings in supply chain management.

In many regards, data warehouse represented by SAP BW is the equivalent of physical distribution centers.  When organizations accumulate large amount of information, a well-designed and well-run BW enables the consolidation, self-service, and 360 degree view.  This "overhead" of data warehouse modeling, in turn, provides the streamlined and consolidated information delivery and discovery.

Digging in a little deeper into organizations where SAP BW's very existence is challenged, I realized that their BW system is often run under the shadow of SAP ERP.  For example, despite BW's elaborate data level security and task access which can distinguish owners, BW authorizations are setup based on the Transaction-code mode of ECC.   BW developers are starved from many useful BW transactions and capabilities, let alone the business community.

On the opposite end of the trajectory, organizations that fell in love with BW are those where the BW system is "open" and "inviting".  There are business users who write and navigate almost all of their own queries , which became extensive analytic workbooks/Web reports. 

Not dragging the story too long, bits and pieces came to mind during a recent conversation regarding how to start on the right track towards BI success.  Let me share them here, perhaps invoking some open discussions.

Let BI thrive under its own merits.

BI has many unique aspects that make it unfit with some traditional IT principles:

1) BI is access to ever-changing information and uncovering the dynamic truth underneath, beyond long-lasting static formatted reports.

2) BI is a decision support system.  BI is not necessarily a "must-have" to run a business.  The tagline is: ERP runs the business, BI manages the business.  Leadership and senior management sponsorship and adoption can go a long way to jump-start BI success.

3) Adoption: The ONLY success criteria for BI is business adoption.

ERP projects are measured by delivering on target, per functional requirement and process definitions.  While BI projects can be bench-marked against initial requirement, time, and budget, the true measure of BI success is whether the user communities adopt the BI deliverable as their own.

A few years ago, there were studies showing half of the dashboards delivered to users went ignored after a few months.

Two conclusions we can derive from the study:

      a) Dashboard lifetime may not necessarily be long...The initial design can have some short-term decisions built-in, as the outputs could well need to be updated soon after use.

       b) Even when those BI projects came in on-time and on-budget, unless the outputs are truly adopted and truly reflect users' REAL need, we can not claim success.

Coming to the execution, a couple of quick sparks:

1) BI, more than ERP, is about relationships between IT and business.  We should encourage the business to have a sense of Ownership in the BI process, not making them feel "us vs them". Consequently, the BI project methodology often works better when we allow Joint decisions, Flexibility, and Quick turn-around ---Agile.

Many modern BI tools, counting in BPC for example, are designed to allow business to take center stage and ownership.  That is also why we have a mushroom from the likes of SAP Lumira, Tableau, and Qlikview.   One of the three pillars for SAP BI tool-set is agility.

BI team needs to directly connect to the business we are supporting.  We need to understand the personalities of the business process and the people.

Open dialogues, direct contacts, and regular workshops are key to put BI into the users hands.  Many significant BI requirements come from informal or private inquires/conversations, and observing business operations.

If we only allow formal SDLC requirement process in place, we may discourage the business from coming forward with "immature" thoughts or ideas.   The maturity of decisions often comes after uncovering the truth through business intelligence, not before.

In practice, the emphasis of formal SDLC and IT ownership had often forced business to grab raw data, opening their own departmental data marts or BI shops...

Open is key.....

2) Following the Open theme: BI Access and security authorizations should attract people in, not keeping people out.

BW's analytic authorization model is a different concept from the ECC's Transaction Code model.

BW, BOBJ, and BPC have elaborate and extensive data and task level securities, which can be utilized effectively to protect the information.

In the meantime, BW transactions and BI tools should be open at the "maximum" level to BI developers.  Power users should be encouraged to report on their own.

Many of the finest improvements in BW came in the form of new transaction codes.  BW developers should be encouraged to explore those functionality to take advantage of the investments.

In principal, BW developers should be treated as DBA and ABAP developers in the BW clients, not as simply report developers.  This is especially true when we want to emphasize lean and creativity in the BI groups.

Rounding back to the top of the paragraph:  BI's success is directly tied to the BI groups's creativity, user experience, and ultimately user Adoption.  The more organizations open up and foster those, the better we will be in the BI journey.

More to come.....