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.
This is a very good read and includes everyone. I enjoyed it so much; I want to add to it myself…
Here is my input:
Yes I think simple is best to describe product and services.
Someone once said to me
“I gave your name to someone with a probleand told them he you would sort it out if anyone can.”
I was thankful for the business which was actually slow.
He added, “In the process I referred them to your web site, but I admit when I looked at it too for the life of me I could not figure out what you do.”
That was like a bombshell so I immediately went and had it changed.
I was very thankful for the lead. Our website is till not the best but when people are referred there we get a lot more business.
Software vendors who talk about solutions make their own life hard too and put everyone back while we sort out their confusing acronyms and badly positioned sales mumbo jumbo and sometimes mis-information as we try to see what they really have.
I like the carpenter’s tool example the hammer, to drive a nail. In another spectrum to resolve a war conflict we can us the army that is are not a solution. It is a tool of war or a defence tool. Equally to negotiate uses a diplomatic tool.
Software is software, no-more no-less so why not just call it that. And of course we all agree it is not just technology but includes people with skills to set it up and train us how to use it. And to put it into a process requires consulting and setup for the change which can add to the effort. But in the end what we end up with is still just a software tool.
Operational, accounting, workflow, client, project budgeting, collaboration, presentation, communication asset and human management reporting and so on you can go, they are all software tools to do a job. Analytical mathematical scientific educational etc in every walk of life and function of business you will find software.
As I rattle them off I can see synergy to combine some or all into enterprise level tools that provide structure rules and a place of work for many elements of business and operational process.
Like any invention or idea software is invented and used to solve problems of many origins. But there is no way it can presume to be a solution. It is still just a tool.
When enterprise software vendors talk about solutions I think of problems and I am turned off.
If I have something to do I use a tool to do it. If I have a problem I figure what to do to fix it. Then I use a tool to do it. Even the end game, the result, may depend on my approach is it is the not the tool, the solution or outcome. It is the benefit it delivers that I want. (Sorry Ms Jane Ordinary but I still need the business case.)
And I don’t always have a problem but just have something to do; Such as a strategic change or tactical move for an opportunity. For this I plan an approach then get the tools and resources I need, to get me the outcome I seek. In the process I look at choices and choose. This could have many solutions as we proceed.
So the real test is: if
“I need to get a result I would never asked the software company get it for me.”
I would ask an expert to look at the choices. Then set up a team to go and see if there is a business software tool (not a solution) that can fit our culture and we can learn to use it to get what we seek.
What Software Vendors have is only one piece of the process. So they always confuse me as often they are talking about all of these aspects in the same terms of as a “Solution”.
I am just your average Jo C who likes to use the best tools to get the best result. And assembling solutions is just a step in the process to get there.
By the way if my daughter who just started work recently asked me what I did and I said I was a Solutions Salesman she may figure it was important and tell her friends. If I said I sold accounting software she would know what I had and may offer a choice for a solution for her boss.
My advice to Software Vendors is drop all the bull. Make it easy on yourself guys and just call a spade a spade.
Thank you for your comments and insight; well said. It’s nice to know there are others out there that share my opinions.
[…] Who Are White Papers Aimed at Anyway? A good read that gets you in with a leading question and? discusses this subject and some misleading terminology used by the software industry papers. This is a lead? on something we are? preparing as a “clean up your act paper” on the same subject which will be issued in December 2008. […]
Thank you Ralph for your kind comments. I look forward to reading your paper in the near future. Please let me know when it will be available.
[…] recently seen some intriguing (if not bizarre) press releases (PRs), which read like some type of whitepapers or presentation […]
[…] fluting assumptive terms about basic processes and activity. I was drawn to an article I read at Technology Evaluation.com by Sherry Fox This is good read about enigmatic terms used by the software vendors.? My contribution here adds my […]