SAP BW

It’s the end of 2012 and this will be my last article for the year. 2012 has been filed with the buzz around SAP HANA and SAP BusinessObjects 4.0. SAP HANA is on course to be a real game changer in terms of in-memory data analysis and storage. From my standpoint, SAP HANA is true innovation that will lead future markets and competing vendors into a bold new era of instant and on demand analytics. SAP BusinessObjects 4.0 was the long-awaited answer to true SAP BW integration and next generation visualizations. Web Intelligence 4.0 received a full body aesthetic makeover, Universes received a new sibling in the form of IDT / UNX, the Import Wizard was laid to rest, Crystal Reports received a new sibling too and Explorer took its first steps in becoming a true visualization tool. With all of these innovations and enhancements, one would think 2012 was a real winner for SAP Business Intelligence. While SAP HANA was first to cross the finish line of both innovation and ability to deliver, SAP BusinessObjects 4.0 finished somewhere in the middle of the pack. It was chopped full of innovation but its inability to deliver was a “battleship sized anchor” that slowed it down in the race to the finish line. That is not to say to that SAP BusinessObjects 4.0 was a complete failure. There are several new features, tools and options in 4.0 that were true innovations or enhancements. Its problems were largely based on buggy software, removed features, and inconsistent support for data sources. I could dedicate several articles to listing out all of these issues in detail, but I will try to keep it high-level for now. However, the SAP BusinessObjects 4.0 release provoked me into thinking about what garners a bad software release. Using the recent Apple maps example, I will try to share those thoughts and my opinions on the topic. With that said, let’s get to the main point of this article.

While my opening statements were dedicated to picking on SAP BusinessObjects 4.0, SAP BusinessObjects is not alone in receiving criticism in terms of product upgrades and blunders. Over the past 15 years I have seen my share of blunders. Think back for a moment. Do you remember Microsoft Windows ME and Microsoft Windows Vista? What about AOL and dBase IV? Then there was the IO Mega Zip Drive (I actual still have one). What about this fabulous list which includes Microsoft BOB, Microsoft IE6, Microsoft Works and pay-service Napster? Then there is Apple. For years Apple has served as the pinnacle for intuitive user interfaces and simple to use technology. This pinnacle was not always achieved without some customer dissatisfaction or failure. In addition, not every Apple product was a proven winner. There was Apple’s Bandai Pippin, the Apple Power Mac G4 Cube, Apple’s Lisa ($10,000 PC) and finally Apple TV. With the success of the iPhone, iPad and iPod in recent years, we sometime forget that Apple has had its fair share of blunders. Another issue that has plagued Apple for decades is its lack of openness. Tech savvy users are always put off by Apple’s will to control it platform by preventing deep access to its core operating systems and limited API’s for 3rd part products. However, for this article I would like to focus on a more recent Apple blunder in the form of Apple maps. It’s a blunder that embodies the typical failures that most vendors make with upgrades. Below I will list the top 5 reasons Apple maps failed and what vendors can learn from its failure.

Map functionality was removed: Apple’s maps lacked the level of detail that Google’s maps provided. What happened to the building outlines in standard view? Why are there so few points of Interest listed on the map? Why are lakes, rivers and ponds no longer displaying their names? When a vendor offers an upgrade to a product, they need to be mindful not to remove functionality. This is what leads to dissatisfaction in the user community. If functionality is removed, the alternative better be 10 times better. Vendors need to understand how the product is used and what users actually find useful before removing functionality.

The GPS coordinates for many destinations were wrong. There are numerous horror stories of Apple’s maps leading people several miles off course. In general terms, vendors need to make sure that the basic functionality of the product works as well (if not better) than the prior release. This has to be the most frustrating inevitability of a product upgrade. Vendors always try to change something with each upgrade to generate renewed interest. The problem is that they always break something basic. Vendors need to find a way to innovate without breaking.

The maps moved slower. It’s understandable that Apple wanted to provide turn-by-turn navigation to its iPhone users. For some reason Google and Apple could not make this happen with Google maps. Apple then decided to go the “do-it-yourself” route. Unfortunately Apple did not have all of the required infrastructure and technology implemented to maintain the same level of performance and detail of Google’s maps. The irony of it is that Google recently released an iPhone app that provides turn-by-turn navigation using its own maps. The lesson that all vendors can learn from this is twofold. Vendors need to learn to work with their partners and they need to make sure the new stuff is as fast as or faster than the old stuff.

There was no alternative to Apple’s maps after upgrading. You wake up one morning, notice that there is a new iOS available, upgrade and then discover that you are now stuck with a crappy mapping application. Apple could have given its users a choice to use basic Google maps or turn-by-turn enhanced Apple maps with the release of iOS 6. Instead they did a bait and switch. In turn, iPhone users found it more satisfying to run Google maps in the Safari or Chrome browser then to utilize a native iOS 6 mapping application. Now to the lesson. Vendors need to learn how to give their users a choice before forcing them to a new product or methodology. Every new product or enhancement can benefit from a burn-in period. Feedback from users is the most valuable tool in achieving perfection. It’s “OK” to innovate, just don’t handicap users with sub-par alternatives.

Apple fired the decision makers and apologized. Apple inevitably took responsibility for the blunder, took action to prevent it in the future and apologized for the mistake. While this did not actually fix the major problems with Apple’s maps, it did demonstrate Apple’s willingness to fix the problem. I don’t like it when hard workers are fired for their mistakes but sometimes heads need to role to help temper bad publicity. Apple still has to make sure they fix the problem or provide alternatives in order to fully move past their mapping problems. The main lesson that all vendors can learn from this is the following. Vendors need to acknowledge their mistakes and devise a plan of action to remedy the problem. Nothing is more frustrating than a vendor that acts like nothing is wrong when every users of their product knows “something is wrong”. As I stated above, there is more to this than just apologizing. A real solution must also be provided in order for a user community to continue accepting a product. It’s also wise for a vendor to understand the root cause of the issue so they don’t repeat the same mistake with future releases.

While this list only includes my top 5 reasons, there are more lessons that vendors can learn from other Vendor’s mistakes. In terms of SAP Business Intelligence products, SAP has done a great job in developing enhancements to BusinessObjects in the 4.0 release. However, like all vendors, they have room for improvement. Rumor has it that the goal of the BusinessObjects 4.1 release is to re-focus on stability and usability. I truly hope that is the case. I look forward to an exciting 2013 with SAP BusinessObjects and SAP HANA.