- Vendors provide information that is used during the software selection process.
- How should this information be used?
Software sales is known as one of the more aggressive types of sales. Good software salesmen are highly compensated, and are given every incentive to sell as much as possible. In some cases, such as a software company for whom I worked called i2 Technologies, the salespeople were so out of control in their lust to sell that they actually derailed the company. This orientation began at the very top of the company. The head of sales for i2 Technologies was famously to have remarked in a highly-charged sales meeting (all i2 sales gatherings tended to be highly-charged affairs): “I never want to hear the excuse that software does not exist as reason to not sell.” Information about software comes from either sales or marketing. Marketing includes the development of collateral materials, both printed materials and the website copy, which are designed to put the company’s products in the best possible light. Both sales and marketing are under a great deal of pressure to compete with statements and literature provided by other companies. A big part of sales and marketing is about creating a vision, which has nothing to do with communicating real features in software.
Claims Made in Marketing Literature
Software vendor marketing literature can take the form of pamphlets or website copy, and can be quite easy to get hold of. This literature is very influential in software selection but, depending upon the vendor, often contains false information and is unreliable. For example, I have read numerous marketing documents that explain how a product performed “inventory optimization” (a particular set of mathematics for supply planning), when the software discussed did not actually possess this functionality.
To provide further examples and explain what I mean, I have extracted quotes from some marketing literature. Below are some lines from SAP’s marketing literature on their product NetWeaver, called SAP NetWeaver, interspersed with my critique on their statements. My critiques appear so frequently because the falsehoods are so prevalent throughout the document.
SAP Netweaver Reduces TCO?
“The SAP NetWeaver technology platform is a comprehensive integration and application platform that helps reduce your total cost of ownership (TCO).”
NetWeaver is not actually a product (outside of a little used application server which is inferior to the free Apache) but a marketing construct; it is simply nomenclature added on to existing, mostly IT infrastructure, products thus making this statement untrue. In our TCO calculations we estimated SAP to have the highest total cost of ownership in any software category in which it offers a product.
Netweaver Facilitiates Integration and Alignment?
“It facilitates the integration and alignment of people, information, and business processes across organizational and technological boundaries.”
No, it does not. NetWeaver only relates to infrastructure, and does not help out a client in areas outside of infrastructure, and not to belabor the point, but NetWeaver is itself not a distinct product.
Netweaver Integrateds Informations from Any Source?
“SAP NetWeaver easily integrates information and applications from virtually any source.”
No, it does not. None of the products that were placed within the “NetWeaver umbrella,” which relate to integration, the most prominent being SAP PI, enables integration any easier than other integration products. In fact, SAP PI is not even competitive with other applications in the same category. Companies primarily buy SAP PI because they either can’t differentiate good integration software from bad integration software, or they think that they will be able to leverage SAP-to-SAP integration capabilities. Those individuals familiar with both applications would not support the idea that SAP PI is competitive with enterprise integration products such as Informatica. In fact, SAP misrepresents application integration completely with this sentence. Integration is always work—files must be transformed and converted to match with the data requirements of the receiving system. Jobs must be setup to carry the data from one application to another, and it must be scheduled in a way to run automatically. No application has been developed that makes integration “easy” anymore than a battery has been developed to easily store power. In fact, SAP PI makes application integration more difficult than other vendors.
This should not be surprising, because ERP vendors have no special knowledge or ability to develop superior applications in this area. Application integration, like power storage, is always complex, and both have proven immune to magical promises about how transformative they would be. Vendors, not just SAP, have been pitching easy integration for decades now, and integration still is problematic, and still consumes a consistent percentage of the IT budget of buying companies.
Netweaver Operates with Everything?
“It interoperates with and can be extended using the primary market technologies—Microsoft .NET, Sun’s J2EE, and IBM WebSphere. SAP NetWeaver is the technical foundation for mySAP™ Business Suite and SAP® xApps™ and ensures maximum reliability, security, and scalability, so your mission-critical business processes run smoothly.”
This is the technical gobblygook portion of the document. The intent here is to throw so many terms at the reader (who is typically an executive and is not familiar with these technologies) so that they will be impressed. It is also very unspecific about how this would all work, so the reader has to take the author’s word for it. Many of the terms that are used in this quotation are already no longer relevant. I have already addressed the fact that NetWeaver is a meaningless term. The term “mySAP Business Suite” is no longer used, but it never was anything beyond a collection of other SAP products. The xApp program was a “brand” that held out the potential to smaller vendors of getting into SAP projects. In fact, the xApp program was a giant competitive intelligence operation, which allowed SAP to take intellectual property from other vendors in order to bring out competing products.
SAP Rduces the Needs for Custom Integration?
“This Web services-based platform offers a comprehensive, tightly integrated set of capabilities. And by providing preconfigured business content, SAP helps reduce the need for custom integration and lowers your TCO.”
I work on SAP projects for a living, and this document is a few years old now, but I have never seen any of these “products” used on a project. I never saw any “preconfigured business content” and have never heard of this term used by anyone on any project at any time. SAP still has some of the highest integration costs of any application vendor because of the nature of their data backend, which does not allow the underlying relational database to be directly addressed. As I stated several paragraphs ago, SAP has always had the highest TCO (total cost of ownership) of any application I have reviewed, and continues to have the highest TCO.
Netweaver is a Blueprint for Complete Business Integration?
“Enterprise Services Architecture is also a blueprint for complete business integration. Regardless of the functional or technical barriers and isolated applications that may have grown up over time in your company, Enterprise Services Architecture brings back flexibility, allowing you to design complete solutions that span all people who participate in your value chain, all information that is relevant to you, and all systems that are involved for each business process or problem. This means that you can now respond to workers’ needs for business processes that are driven by collaborative, knowledge-based, and team-based processes rather than by isolated applications.”
No, it isn’t. Not only do the products that pre-existed “NetWeaver” and were then added under the NetWeaver umbrella, not have the magical properties described in this quotation, they are not even competitive products. Workers in companies where SAP has been implemented do not have more responsive systems than other environments; they have decidedly less responsive systems. The last part of the quotation is pure hyperbole. In one part of the document, SAP breaks down the benefits of NetWeaver by the different areas:
“Portal infrastructure—Gives workers unified, personalized, and role-based access to heterogeneous IT environments. Increases the efficiency of business processes spanning customers, suppliers, partners, and employees.”
SAP has been trying to get its portals used for more than a decade now, and they are still not used. SAP has a portal, but the potential that companies will benefit from it is low if they don’t use it. Now I almost never hear about portals on projects.
Solution Manager is Knowledge Management?
“Knowledge management—Manages and makes accessible unstructured information such as text files, slide shows, or audio files. Includes integrated search, content management, publishing, classification, and workflow capabilities, as well as an open framework for third-party repositories.”
SAP has a product called Solution Manager, which has a few advantages in terms of documenting the implementation and allows Solution Manager to take you directly to configuration within the application. I analyze Solution Manager in the article. However, these other things described in this quote either do not exist or are so overstated that they do not communicate what SAP’s knowledge management products use. Furthermore, Solution Manager is really only used (and lightly used at that) by configurators like me. Solution Manager is not used in the way described above and no other portal, which SAP may offer to clients, works in that way.
Business Intelligence Offered by SAP is Robust?
“Business intelligence—Enables organizations to integrate, analyze, and disseminate business-critical information. Includes a robust suite of tools for creating and publishing customized, interactive reports and applications, which supports your decision making at every level.”
Business intelligence, which is covered by SAP’s BI and Business Objects products, is not any more robust than any other reporting platform. In fact, according to the research firm Gartner; SAP has the lowest scores for both software quality and customer support of any application vendor in the space. I rarely see SAP BW add value for clients; in fact in most cases BI reports are missing in action.
SAP is About Master Data Management?
“Master data management—Promotes information integrity across the business network in heterogeneous IT environments. Provides services to consolidate, harmonize, and centrally manage your master data, including business partner information, product master and structures, and technical-asset information.”
SAP brought out a master data management product called MDM. However, it never gained much of a following and had many implementation problems. It was not competitive with other master data solutions in the marketplace. I could go on and on about SAP’s marketing documentation, but hopefully you get the point. And while SAP takes enormous liberties with the truth, most vendor marketing documentation is in some way misleading. In fact, aside from entertainment value, there is little reason to read SAP’s marketing literature. However, this is not always the case with all vendors.
How Arena Solutions Differs from SAP in Information Accuracy
For instance, a vendor whose marketing documentation is quite accurate is Arena Solutions, a vendor that makes bill of material management software and for which I wrote a book that featured their software. I have never read any documentation from Arena that seems “off” or misrepresentative, and in fact a very good amount of Arena’s documentation is quite educational. This is in fact what marketing documentation should be, but is very rarely the case because most companies cannot resist embellishing in order to make their case and to persuade in the hopes of selling more software. Let’s review some of Arena’s statements from their marketing literature to see how it differs from SAP.
“Item management is easy when part data, assemblies and documents—including drawings and data sheets—are all in one place. Give your team and designated suppliers controlled access to all the information they need to design and manufacture your product. A centralized product record allows your team to make faster and more efficient design decisions—like reusing part specifications from old designs—and save time and money.”
This is all true. When all information is in one place it’s easier to find, and in fact Arena’s software does just this. Arena’s product also significantly increases the reuse of old designs. Observe that the hyperbole of these statements is minimal, and when contrasted to the highly-generalized statements that SAP made in their marketing literature for NetWeaver, these statements are quite specific. Arena is not saying their software will do everything, but that it will do something specific, and then explains how it will do that thing.
“Create a unique record for every part in your item master with customizable part numbering schemes and categories. Customizable categories can be used to determine the layout and sequence of fields in your part record. With up to 250 customizable attributes per category, BOMControl allows you to record and track the data you need, at big-picture and granular levels.”
Again, more specifics are provided by Arena of what they can do. Arena’s application can hold up to 250 customizable attributes per category. A person who works in this area should have no problem understanding exactly what this means.
“Immediately see what’s changed in any version of your bill of materials with a simple toggle to Redline mode. Stop wasting time with phone calls or notes explaining every small change you’ve made to your BOM. When you grant supplier access to your contract manufacturers, they can see for themselves exactly what you’ve modified and how it impacts the overall product. Quickly compare multiple BOMs to see what has changed, or what is different. Optimize procurement and production with side-by-side bill of materials comparisons that reveal component needs across multiple product lines.”
These statements tell the reader quite a bit. They explain how a company can stop wasting time by leveraging Arena’s functionality with regard to managing revisions. The BOM can be compared to see what has changed and procurement and production can be managed by component need across multiple product lines. This is just a sampling of Arena’s marketing literature of course, but all of Arena’s literature reads this way. One can learn a lot from reading Arena’s literature because they describe a reality, not only of their software, but also of the environment in which their software is implemented. On the other hand, it is very difficult to learn by reading SAP’s marketing literature (and the marketing literature of many other vendors) because they are so busy selling, that they have no time or space to educate. SAP’s explanations are absolutely overwhelming, as if they are attempting to include as many accolades as they can. They attempt to sell the reader in every possibly sentence instead of selling the reader on the overall paper. In fact, SAP’s marketing literature is insulting to one’s intelligence and to one’s time. SAP marketing literature is not much read as it is “parsed.”
How to Read and Differentiate Vendor Marketing Literature
In addition to learning from vendor marketing literature, there are more benefits. For example, more often than not, vendors who engage in extreme exaggerations and hyperbole are problematic vendors who are selling “pie in the sky.” The marketing literature is telling you something about the company. The company who is ready and willing to sell you a bunch of baloney and has no standards for truth in their documentation will have a strong tendency to behave that way in other parts of the company and in their dealings with you. By reading between the lines of their literature, you can learn to steer clear of these vendors. In addition, misleading marketing literature impacts the sales and presales groups of software vendors. Individuals who work in sales and presales rarely get first- hand experience with the application. Much of what they know about products comes from the marketing literature. They don’t spend the time to talk with consultants who implement the software to determine what is true and what is not, and learn to be as accurate as possible. Most individuals simply don’t care. If the marketing literature says that the vendor has developed a time machine, the sales group is going to go out and sell time machines. And of course as a buyer, it’s your job to steer clear of companies selling time machines.
The software demonstration (or demo) is one of the few opportunities to get first- hand experience with the software. Most information on demos (and there is not a lot to be found) explains how to put on a good demo. However, I could find nothing on how to get good value from a demo if you are the software buyer. There are several issues that negatively affect how accurately demos can be said to represent reality. However, from the perspective of buyers, the weaknesses of demos are that they tend to be artificial and are controlled by the vendor. The common issues with demos are listed below:
- The company’s presales consultant typically runs demos. The demo is not an accurate representation of how the software will actually be used because this person specializes in knowing all the ins and outs of the software and is typically quite specialized in that application. Users will never attain the ease-of-use demonstrated by the consultant because they use several applications throughout the day and won’t gain the same depth of knowledge about the product as the consultant. Therefore, the consultant’s level of knowledge allows them to make the product look much easier to use than it really is, and to gloss over its imperfections.
- Demos use dummy data, which provides a great deal of flexibility to the presales consultant who drives the demo. Applications run faster and more smoothly with smaller data sets.
- Demos tend to be tightly controlled in that they follow a script. The script makes the application look much more fluid and fully featured than it actually will be when implemented.
- Too often the users are excluded from the demo, meaning that the demo tends to be a high-level affair. However, it is the users who ask the most pertinent questions related to how the software would be used in an everyday setting.
- The same bullet point above applies for technology resources. They are needed to ask questions related to how the software actually works under the covers, how it loads and updates data, makes decisions, etc.
- Demos tend to be short. Most range from between forty-five minutes to an hour. This is not enough time to explore an application, particularly if it is complex. Large audiences tend to shorten demos because the demo is often seen as just one part of the presentation that day, and the more senior members tend to want to spend an hour on several occasions going over software. This short exposure time to the actual software is a mistake because the shorter the demo, generally the more the vendor can hide.
- While I have never heard this mentioned in other published material on software selection, I find it very useful to have screenshots sent of interesting functionality. Once a buyer has screen shots they can mark up the screenshots, and then compare and contrast to screen shots of other applications. Comparing and contrasting functionality in this way is something I do when I chose software to showcase in books. This can allow a software selection document to be created that really explains the specific differences between the different vendors. However, demos are extremely important. While it should be remembered that the vendor would like to control the demo, ultimately, the buyer is in control of how the demo progresses—if the buyer wants to take that control. It is the buyer’s time that is being taken and the purpose of the demo is to inform the buyer if this is the right application for them. The best way to take control of a demo is to declare how you would like the demo to run, and to do so well in advance of the vendor actually making the presentation.
Without this communication prior to the presentation, the software presales consultant can legitimately say that she is not prepared to perform the demo in that manner. This is because demos must be prepared both in terms of the data that is used and how the presales consultant manages the demo. Most presales consultants are not comfortable with individuals from the buyer navigating through the application himself or herself, so they must be told beforehand if these individuals would like to do so.
However, this can be accomplished even if the demo is not performed in person because all screen-sharing applications allow transfer control of the computer to anyone who is part of the screen sharing session. Another way of taking control of the demo is to stop the flow of the presales consultant’s presentation. The presales consultant may have a set of things he wants to show, and plan on leaving questions until later, but this is a way of taking control of the demo. As a buyer, you should remember that the entire purpose of the demo is for you to understand whether this software should be selected. Therefore, the presales consultant’s desires must rank as a distant second to the buyer’s needs. Ways to make demos more useful to the buyer can be determined by working backward from the limitations of demos:
- The presales consultant can explain the software, but someone else should drive the demo, at least for part of it. By doing so, you are controlling the presales consultant’s skill level. Yes, certainly a presales consultant can move very quickly between the screens, but how intuitive is the application for a first-time user? If I take the example of SAP versus Arena Solutions, SAP allows companies that have included SAP in their software selection process to view their software only through the presentation of a software consultant. Arena Solutions allows anyone to self-navigate through their online demo environment for thirty days. This speaks to the confidence level that Arena Solutions has in its software and its usability. SAP would never allow this because the difficulty in using SAP could become apparent. Not all companies have an online demo environment like Arena, but still, when a demo is presented the request can be made to have someone from the buyer actually navigate the software under instruction from the presales consultant, or the buyer resource and the presales consultant can take turns running the application. The more usable the application, the more open the vendor will be to getting the maximal exposure to the application for the buyer.
- There is nothing wrong with allowing a presales consultant to start from a script. There are some things that need to be shown; however, the entire demo should not be from a script. It makes little sense for most of the demo to be “canned” or from a script as the standard things the vendor wants to show should be available for multiple viewings in video format on the vendor’s website. At this point, the demo should center on things that the client has asked specifically to see (in advance) and the vendor should have built the demo specifically to answer these questions. Demos can also be made more interactive simply by driving the demo with questions. Presales consultants are under a lot of pressure from the sales team to provide short and smooth demos that leave the buyer with a good impression. However, if it is explained that the buyer does not desire this, typically the demo can be driven differently.
- Users need to be included in the audience during the demo, and their opinions should be solicited after the demo. Would they personally want to use the software? They should also be told to ask questions whenever they see fit and not at the end of the demo only. Users will pick up on things that executives will not. There is absolutely no logic to exclude the eventual users from a demo. When I worked at i2 Technologies, I recall that on one account the presales and sales team convinced the potential customers to keep users out of the demos. The sales and presales team explained to me that they knew the particular software they were showing was weak and that they would not be able to answer users’ questions, so they needed to, in their words, “sell directly to the top.”
- Demos should be lengthened. A demo lasting an hour or less, or even multiple demos lasting an hour or less, is not sufficient to really understand how the application works in a variety of circumstances. The shorter the demo, the less representative the demonstration, and the easier it is to cover up weaknesses in the application. After the salespeople and the implementation consultants are gone, what will remain is the software. The software needs to work as the company desires and needs to be able to stand on its own and work efficiently the way the users need it to.
The SAAS/Cloud Vendors Versus On-premises Vendors for Long-term Software Evaluation
Most enterprise software that is sold is called “on-premises,” meaning that the software is installed on the servers of the buyer and is managed by the buyer. With SaaS/Cloud, the buyer does not actually install any software. Instead, the buyer receives the right to use the software that is installed at the vendor’s location. There are a number of advantages and disadvantages to this approach; however one of the major advantages is that companies that offer their software as a SaaS/ Cloud solution are in a very good position to offer trials of their software. However, only around 4% of all enterprise software is delivered as SaaS at the time of this publication. Some companies like Arena Solutions allow companies to test drive their software for thirty days by logging into their demo environment. However, other SaaS vendors do not offer this service. For instance Data Alliance, an SaaS vendor that I was analyzing recently, chooses to follow the on-premises model of presenting demos to potential clients, even though they could easily provide an SaaS demo environment for companies to test drive at their leisure.
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 sales people 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. 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, technical benefit to the implementation as I explain in the article What are Vendor Certifications worth on Projects?
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. 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.
It should not be news to anyone that information that comes out of sales in any area is often not reliable. This of course also extends to marketing literature. However, there is also an enormous continuum of accuracy along which any vendor can reside. For instance, I have found that when a marketing message comes from SAP it will be either outright false, an exaggeration or a misrepresentation of the facts. Because of this, I have to verify the statement through my own research. However, on the other end of the continuum is the example of Arena Solutions, where I have yet to find something inaccurate in their marketing documentation. However, I can say these things with confidence about both of these software vendors because I have worked with these software vendors for years and read a very large amount of documentation by both companies and have firsthand experience with their applications. When one is new to a software vendor it makes sense to take a skeptical approach to their marketing documentation and statements. When the topic turns to the software demo, there are all types of simple ways to improve the accuracy of information that is received from a demo that buyers do not take advantage of. The first principle on which the demo should be based is that the demo is entirely for the benefit of the buying company. This means that the buyer has the right to control the demo as they see fit, and to have his or her own people participate in using the application during the demo.
Luckily this is an easy matter with modern web conferencing applications where various people can take control of the computers that are presenting. Demos have well-known limitations, the easiest to understand is that demos provide a small amount of time to the evaluators to actually get exposure to the application. Companies with the weakest applications have the greatest incentives to limit the buyer interaction with the application and have the software selection made on more strategic and abstract grounds. The converse is also true. The vendors with the best software want you to spend more time with their application. One example of this is Arena Solutions. Arena Solutions offers a 30 day free trial of their software, and is happy to sell a single license to a company for roughly $80 per month for one user. They know, that once in the door, their application has a high likelihood of being used, and for more users to ask their management for a license. Software vendors like SAP want a major commitment up front. Once the commitment is made, the buyer’s flexibility is greatly limited. I have performed software recovery analysis for many companies for applications that never should have been purchased. However, after so much money has been spent on the software license, as well as the implementation, there is a very strong disincentive to move away from the sunk cost of a bad decision. This is actually a major difference between on-premises versus SaaS vendors.
With SaaS vendors there is a much greater incentive to keep their customers satisfied, because a SaaS customer can more easily terminate their software subscription. Integration is a major area of overemphasis in software selections. First, any application can be made to integrate with any other application, and many pre- built adapters that are marketed by software vendors are often much less than they appear during the sales process. Some software vendors, because of their desire to control the purchases of their clients toward their products have deliberately exaggerated the costs of application integration to clients. In fact, ERP purchases have been greatly justified by the desire to reduce integration costs. However, as is explained in the book The Real Story Behind ERP: Separating Fact from Fiction, the percentage of integration costs that make up IT budgets has not declined after the introduction of ERP systems so the concept of ERP reducing integration costs has been all marketing hyperbole. The primary objective of any software selection should be to get the best application, which can meet the business requirements, not to attempt to save money, for which there is no evidence will be saved, by trying to minimize integration costs with other applications. Client references sound like an easy way to find out information about how effective the software has been in other accounts. However, in practice client references are tricky. It would be more useful to actually speak to the system’s users than the executives, but those resources are generally not made available during a client reference check.
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