Large scale implementations are complex

When vague or loosely followed standards are introduced, they add an unnecessary layer of complexity and risk. Managers and project sponsors do not like risk.

If you were given a choice, would you choose to a structured, simple, and easy-to-understand  approach if a little investment of time from your team is required?

So why bring this up? Well, this year is quickly coming to a close and I am reflecting on the lessons learned. Two projects comes to mind, so please allow me to explain through a quick contrast.

The first customer, Client A, had a small, but contentious implementation. I was brought in to perform an architectural review and to provide guidance and support.

Setting the ground rules with the naming standards and data modeling guidelines, the advice was well received and quickly implemented. The client was looking for a confirmation of best business practices and I was happy to provide some lessons learned.

What is the difference?

Fast-forward a few months, the internal development team continues to follow a clear guideline and maintains an efficient system.

The second customer, Client B, is another story altogether. Client B had a long, multi-year implementation with multiple vendors and many consultants and sub-contractors added and removed from the project.

As you can imagine, there were multiple opinions regarding approach, design, and implementation.

Since this is a blog post, I will keep it short and discuss one topic that is the bed-rock of a good or bad project, specifically naming standards.

A Comparison

Client A quickly takes my advice and follows SAP’s naming convention for their infocube. While SAP has pre-configured infocubes such as 0SD_C01, 0SD_C02, 0SD_C03, my client named their infocubes as ZSD_C01, ZSD_C02, and ZSD_C03.

The Z-prefix indicates it’s a customer object while the numerical suffix is the next available number. It’s easy to follow and see those are three different object.

Client B, for some reason, is more creative in their approach with the following scheme: FRORCON, FROCRCON, and FRCRCKON.

After running out of different ways of rearranging the consonants, symbols and numbers are added in various places. FROML_10, FROML10A, FROLML10.

Multiply this confusion by several objects and I find myself spent a few minutes each day wondering if I am looking at the same object.

Using a back-of-the-napkin calculation, I estimate that the cost to the company for this confusion is approximately $6,000 per consultant per year.  This project has 30 consultants so they have a burn rate of $180,000 per year. That’s on wasted effort alone!

A good, solid set of naming standards isn’t so trivial once you allocate a budget to it.

The Importance of Standards

Senior developers understand the importance of having a clear set of development standards and easy-to-follow guidelines. The above standard for infocube names is just one example with a surprisingly large financial impact. I recommend following SAP’s lead with the naming convention, which you can learn more at help.sap.com.

Now, imagine having an almost universal set of naming standards and conventions that your team could adhere to?

Also, what would be the cost-savings if you did not have to explain this set of rules in your on-boarding process? How much quicker would a new team member be engaged and ready to focus her attention to the important business goals if she wasn’t hampered by such a trivial issue?

Bonus

I am putting together a short guide for naming the common objects in a SAP Business Intelligence project. Send me an email and I will send you the guide as soon as it’s complete.

 

Hau Ngo is a SAP Business Intelligence Architect. Over the years, he has helped numerous companies build robust and efficient reporting solutions. If you enjoyed this article, join his monthly newsletter.