Anyone who’s ever been involved in choosing enterprise software knows it’s not an easy job. It takes months of preparation that involves gathering information from various departments, mapping business processes, preparing a business case, interviewing stakeholders, and getting buy-in from executives and users on the project. And that’s only the beginning!

But whose job is it to do all of this anyway? It’s often assumed that someone in IT (a technical professional) will be responsible for it. Other assumed targets are the Chief Executive Officer (CEO), the Chief Technical Officer (CTO), and sometimes even the Chief Financial Officer (CFO)—depending on the type of enterprise software that is required. But believe it or not, most often the person that is handed the title of software selection “Project Manager” or “Project Champion” is just an ordinary Joe—(or Jane to be politically correct)—a department manager or project coordinator who knows the organization’s business processes like the back of their hand. While he (or she) may not have any particular technical expertise, he may certainly be able to add value to the project by knowing the business. So, why not; who better to handle this type of job, than someone like that?

Which brings me to the point of my story…

I found myself involved in a “blog debate” recently regarding the topic of white papers and the use of the word “solution” to describe enterprise software. My take on the word “solution” was that it is often misused or abused by software vendors trying to market their product. I wasn’t surprised to see that others were not inclined to agree with my point of view.

The point I was trying to make was not to come up with a better word to describe enterprise software or systems, but to simply suggest that the word “solution” be used only when warranted:

“Sure, white papers are used for a sales purpose, but if the terminology isn’t used properly or the vendor is heavier on the sell rather than providing useful information, then they lose their impact of what makes them valuable to the customer in the first place.”

In the end, I offered up an alternative by suggesting the word “tool”, to which I received the following reply:

“In technology circles, the word “tool” has a very specific meaning relating to software development. Since the majority of white papers produced today fall into the technology camp, the use of the word tool in a business white paper could be misconstrued when read by technical professionals.”

If you’re not sure where I’m going with all this, just keep reading; it’ll begin to make a little more sense shortly.

Let’s start by looking at two examples of how the word “solution” could be used.

Example 1—CORRECTLY using the word “solution”

An apparel manufacturing company was looking for a new way to increase its productivity and reduce its costs. After many months of searching, it decided to purchase an enterprise resource planning (ERP) system, which could take care of billing, purchasing, inventory control, production planning, and much more. By implementing this type of unified system, the company was able to eliminate the need to keep several of its legacy systems throughout the organization—therefore making its new ERP system a true overall “solution” to its problem.

In this example, the software system was implemented on its own—with no other additional requirements. Considering it a “solution” is therefore legitimate.

Example 2—INCORRECTLY using the word “solution”

A financial institution was looking for a more robust way to backup its data. In order to do so, it would require an enterprise backup system in addition to a variety of other tools. This complete backup solution would be comprised of a backup client agent, backup servers, the storage media—as well as the hardware to support such media, and the infrastructure that would link it all together. The backup policies—such as retention, scheduling, and offsite storage would also have to be considered a part of this final solution.

So, what is a backup solution exactly? Is it the software on its own that enables you to backup and restore a file? Or is it all of these things together that makes it possible to recover data ranging from a single file to full system recovery?

In this example, the chosen backup software and additional technical components are considered the “tools”, whereas the “solution” is the sum of all the parts.

Is it not true that all these “tools” together were what created the “solution” to the financial institution’s backup problem?

So, getting back to my original point at the start of this blog post—who is reading these white papers anyway?

White papers cover a wide variety of topics—from hardware to software, from middleware to legacy systems, from IP telephony to decryption, encryption, and so on. It’s a smorgasbord of technical issues and conclusions.

In the grand scheme of things…

…everything that goes into an enterprise software implementation can be considered a tool—aimed at providing an organization with a “solution” to some kind of problem.

…everything that goes into the development of software can be considered a tool—aimed at creating a marketable product.

So whether it’s C-level manager, a software selection project manager, or a technical professional who’s reading the white paper, it doesn’t really matter; tools are tools.

At the end of the day…

An esteemed colleague if mine wrote recently—in defense of my opinion of the word “solution”.

“Have you ever tried to hammer a nail with a “solution”? “Hey, honey! Pass me the solution, wouldja?” Solutions are your department—given the right tools.” - David Clark

I couldn’t have said it better myself.

The job of software vendors is to provide the tools. The job of the end user is to apply the solution.

“It’s so much easier to suggest solutions when you don’t know too much about the problem.” - Malcolm Forbes

I rest my case!

If you’re in the market for enterprise software and want to read up on the latest offerings, check out “TEC’s White Papers“.

For a look at how to write a white paper on the subject of “tools” and “solutions”, check out Michael Stelzner’s “Writing White Papers Blog”

Another interesting read on the topic is the “White Paper Company Blog” written by Jonathan Kantor.