- Vendors provide information that is used during the software selection process regarding integration.
- How should this information be used?
Interpreting the Vendor Presented Story on Integration
Software vendors habitually present integration of the application as simpler and less expensive than it is in reality. This is true of both vendors selling a product that integrates to another product that you already own, or a suite of products from a single vendor that has prebuilt adapters (although not necessarily comprehensive adapters) between the applications to companies that provide point solutions. Of all the information provided by vendors to software buyers, some of the biggest misrepresentations exist in the portion of the presentation devoted to integration. When I worked for i2 Technologies during the late 1990s, the salespeople out of the Singapore office told their clients that XML would handle the integration between the i2 applications and other applications that the company already owned, as well as between i2 applications and applications outside of the company. I spent a good deal of time explaining to executives in i2’s Asia client base that XML was just an integration document format, and not an actual integration harness. This was at the height of the XML craze.
The Java API??
Then I noticed that the sales team had begun to insert the term “Java API” into sales presentations. API stands for “application programming interface,” and this API was written in the Java programming language. Java API was supposedly better than an API written in the C language because it would be platform-independent. The problem was I didn’t recall us actually implementing projects with a Java API. It became apparent to me that the integration development group would say anything to sales, and sales seemed to be putting things in the sales presentation slides because the customers responded favorably to our “forward thinking,” regardless of whether our product actually worked that way. If you attempt to dispute how the integration will work in practice, the vendor can always bring in someone more technical than anyone in your IT organization. This person will use a wide range of technical jargon to explain how smoothly your integration will be. It won’t and there is little point in debating the point, but evidence indicates that integration will consume about the same amount of resources as it is currently consuming.
Another story in the integration pantheon relates to SAP. In sales presentations, SAP misrepresents the comprehensiveness of the adapters they have built between their own products. The executives come out of SAP sales presentations thinking prebuilt adapters cover them if they choose SAP. However, if they were to check the adapters, he or she would find that the adapters do not cover all of the company’s requirements. SAP is a very large enterprise vendor, and many smaller vendors attempt to improve their marketability by becoming “certified” SAP, which amounts to the vendor submitting to the certification process where a minute amount of data is moved between two systems. After the fake test is passed, the vendor gets a certification badge that they can put on their website to improve sales. Outside of the marketing effect, there is little, if any, the technical benefit to the implementation as I explain in the article What are Vendor Certifications worth on Projects?
Vendor Integration Exaggerations
I have sat through many presentations on applications integration and have heard about all manner of Star Trek-like integration technologies, and yet integration works about the same as it did when I began working in IT consulting many years ago. Client References References are important not only for the initial software selection, but also to learn what functionality to enable in applications that are already owned. Vendors will often build functionality into applications that is either never accessed or infrequently accessed by clients because the functionality is not very good or is too high in maintenance.
Vendor Integration References
Here are some of the reasons as to why software vendor references have limited usability.
- Generally speaking, the vendor will supply only references who are satisfied with the solution (although I have heard of a number of strange stories where the reference provided by a vendor did not implement the software the vendor said they did, but the vendor still provided the reference). Reviewing vendor references sometimes gives preferential treatment to larger vendors who have more implementations under their belt, and that means more of their functionality has been implemented “someplace.”
- Companies that have agreed to provide references for a vendor typically feel some obligation to that vendor for no other reason than the relationship that they may have with their vendor consultants or vendor account rep. This same interpersonal allegiance is at work when clients co-present with vendors at conferences. Not wanting the vendor to look bad, the client sometimes stretches the truth in terms of how well the software is working. I have personally seen this happen at several conferences where I knew the state of the implementation and it bore no resemblance to what was actually presented.
- I suppose I am naïve, but I was surprised to learn that vendors and consulting companies may on some occasions pay their references to provide them with a reference.
- The reference that is provided oftentimes will not have completed their implementation, or the implementation may be so new that the reference account is unsure as to what they actually have. Vendors are quick to declare victory because they know good references can drive sales.
- Implementing companies are very reticent to admit that a software implementation has gone badly. I am aware of a company that has been implementing two applications for roughly ten years, and has yet to get much functional use from the applications. Therefore, bad implementations are hushed up. However, if software is implemented successfully it is typically discussed openly. Therefore, much like the floor of a casino (where the winning slots make a lot of noise and the losing slots are quiet) the positive observations are greatly over-estimated and over-emphasized.
- Even if the reference company likes their present software, to what are they compared? This is explained well in an article on software selection. “Before making a final decision, you should always check vendor references, but take them with a healthy grain of salt. An organization’s satisfaction with software depends not only on how well it meets their needs, but how familiar they are with their options—there are a lot of people who are happy using difficult, labor-heavy, limited applications simply because they don’t know there are better alternatives.”—Idealware However, reference checks can be much better managed and much more useful than they generally are. Rather than asking if the company was happy with software XYZ, it can be more useful to ask how they are using software XYZ. This is much less judgmental and will tend to get to the bottom of how deeply the software is being used. The less judgmental the question, the more likely one is to get to the bottom of what really happened in a software implementation. It can also make sense to prepare a questionnaire that can be sent to the reference in advance. This questionnaire needs to be limited in the number of questions it has, because references cannot be expected to put a great deal of effort into answering these questions.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
Software Selection Book
Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Sources of Information
What the Book Covers
Essential reading for success in your next software selection and implementation.
Software selection is the most important task in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software—the software that matches the business requirements—is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection. This book can be used for any enterprise software selection, including ERP software selection.
This book is a how-to guide for improving the software selection process and is formulated around the idea that—much like purchasing decisions for consumer products—the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision, and gives the reader an insider’s understanding of the enterprise software market.
By reading this book you will:
- Learn how to apply a scientific approach to the software selection process.
- Interpret vendor-supplied information to your best advantage. This is generally left out of books on software selection. However, consulting companies and IT analysts like Gartner have very specific biases. Gartner is paid directly by software vendors — a fact they make every attempt not to disclose while consulting companies only recommend software for vendors that give them the consulting business. Consulting companies all have an enormous financial bias that prevents them from offering honest advice — and this is part of their business model.
- Understand what motivates a software vendor.
- Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to properly interpret information from consulting companies.
- Make vendor demos work to your benefit.
- Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
- Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
- Better manage your software selection projects to ensure smoother implementations.
- Chapter 1: Introduction to Software Selection
- Chapter 2: Understanding the Enterprise Software Market
- Chapter 3: Software Sell-ability versus Implement-ability
- Chapter 4: How to Use Consulting Advice on Software Selection
- Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
- Chapter 6: How to Use Information Provided by Vendors
- Chapter 7: How to Manage the Software Selection Process