The Missing Step
I love Spring for many reasons – more daylight, warmer weather, holidays, and my poppies are starting to bloom, all of which all got me to thinking how everything in life has an order in which it happens, some natural and some imposed on nature by us, especially where business operations are concerned. I was reminded that every process, from baking a cake to manufacturing airplanes, has a sequence of steps to go through to end up with a successfully completed product. (I don’t know about you, but I like both a good cake and to arriving safely at my destination.) One might also look at these as cycles or evolutions from cradle to grave. What does this have to do with the realm of buying and selling mid-market Enterprise Resource Planning (ERP) solutions? Over time, it can be seen that, just like everything else, software has an effective lifespan and relevancy before it needs to be upgraded or replaced to meet current business needs or optimized for current technology.
Just as the sense of the acronym ERP has expanded beyond the standard four walls to include eCommerce, web portals, and so on, I think it’s time to extend and evolve the concepts of how solutions are purchased and sold – yes, the sales cycle in which we all participate to make it happen. While there are many clever and fine works on how to close software sales deals – “sell more!” – and even some superstar salespeople out there who actually have it all figured out, there is probably less written about how to purchase and even less about how to partner to obtain the best possible solution. Somewhere along the line, the word solution in ERP has come to mean a software solution. Go to any major software conference and you’ll find an expo hall full of software solutions and vendors all vying for your business – Original Equipment Manufacturers (OEMs), Channel Partners, Independent Service Vendors (ISVs) who OEM add-ons, and Customers (End Users) are participants. I’m often approached by many salespeople trying to interest me in their solution, but what problem(s) of mine or my clients are they trying to solve?
Let’s take a wider look at the term “solution”. The Business Analysis Body of Knowledge (BABOK ) Guide states in section 1.3.2 Solutions:
- “A solution is a set of changes to the current state of an organization that are made in order to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity. The scope of the solution is usually narrower than the scope of the domain within which it is implemented, and will serve as the basis for the scope of a project to implement that solution or its components.
- “Most solutions are a system of interacting solution components, each of which are potentially solutions in their own right. Examples of solutions and solution components include software applications, web services, business processes, the business rules that govern that process, an information technology application, a revised organizational structure, outsourcing, insourcing, redefining job roles, or any other method of creating a capability needed by an organization.
- “Business Analysis helps organizations define the optimal solution for their needs, given the set of constraints (including time, budget, regulations, and others) under which that organization operates.”
I especially like how this passage describes examples of solutions, which can encompass a whole lot more than simply a piece of software. Interestingly, many solution vendors will offer some sort of diagnostic service either paid or gratis as part of the effort to interest a buyer and secure commitment to buy. At risk of using yet another car analogy, it’s tantamount to bringing your car into the shop, check in with the service writer, the technician hooks up the scopes and various other diagnostic equipment, runs the routines and provides a report that tells you what’s wrong and what should be fixed. Maybe a better analogy to consultative selling would be where something is ailing you, you visit your physician and, after asking you a number of questions and running tests on your body, may (or may not) determine what the problem is and provide possible treatments, remedies, or cures. That’s traditionally how mid-market ERP sales proceed, however, I believe the paradigm has been shifting for some time now. Some are skilled practitioners and others could benefit from training. While the cycle still occurs, it often stalls due to indecision, confusion, or budgetary concerns. A company might luck into purchasing the right software, maybe for the wrong reasons, but, more often than not, ends up purchasing software for what they thought were the right reasons but, at the end of the day, the product did not really meet their business needs, gets misimplemented, overruns budget, or fails in some other way.
True business analysis differs from a diagnostic in that it seeks to deliver full business value by first understanding the business needs, goals, and objectives of the business and all it’s stakeholders, whereas a diagnostic could easily miss key requirements by just focusing on the major expressed pain points and what to fix. Diagnostics may work great for making a sale or performing a very finite engagement, yet in the grander scheme they fail to actually meet the true global business needs. The “diagnose and prescribe” method may only pick up part of the picture in a business, which has a lot of moving parts, and the vendor or purchaser for that matter may only have one or two solutions in their toolbox. Business analysis actually offers a more holistic approach where we would consider what really needs to happen to move a business from current state to desired future state and that may require multiple solutions, not just limited to one software application that we sell – my apologies to Sauron, there is no one ERP ring to rule them all and I won’t have to hike up an active volcano in Mordor to throw your great software in when it doesn’t work. Those solutions will consider how and why a process is performed, who performs the work, what is the business trying to change, improve or achieve, what solution(s) are available today that best fit the business requirements, and may even include integration to other great solutions. Business requirements may need to be carefully elicited from a number of stakeholders (and not just the managers), verified, validated, refined over and over until we have an accurate picture and then, and only then, would it make sense to start the solutioning phase of the cycle.
So, now we introduce the idea of sequence – there is an order in which to best make a decision. We now see that solution comes way down at the end of the cycle and that’s where it actually makes sense to start viewing and evaluating what software applications and vendors might actually meet the business need and requirements. Yes, it’s more work up front and not for the feint of heart, but why be penny-wise and pound-foolish by making an uninformed, uneducated leap into what you hope will work. One of those great books I alluded to earlier is aptly titled Hope Is Not A Strategy. Um, yeah. Anyhow, I cannot tell you how many times I have seen decisions that were going to cost hundreds of thousands of dollars being made with a very small amount of information of the business about itself and even less about the solution being purchased. How do you think that implementation’s going to go? It may or may not go well, a good technician and cooperative business might somehow muddle through to some degree or another of “success”; it’s been known to happen on occasion and leaves a lot to chance. But now we’ve entered the realm of risk and business value. And this risk is very high – time, budget, quality, not to mention actually achieving the goals and objectives of the business.
A lot of businesses just want to throw money at their problems, spin the wheel (put all my chips on red!) and hope solutions work rather than rolling up their sleeves and participating in the journey which consists of thorough analysis, scheduling, providing information, interviews, architecting solutions, approving designs, making purchases, training, testing, and resolving issues. When dealing with complex business solutions, there’s no “just hop in and flip the ignition switch”. One might think that spending a few hundred hours of time performing a thorough business analysis activity, eliciting functional and non-functional requirements, and synthesizing solutions is a large consulting cost reserved for Fortune 500 companies. Now measuring this against the cost of risk and what’s at stake, it suddenly becomes apparent that to do anything else less would be out of sequence and would violate the order in which to make a sound decision to ensure the best business value is achieved in procuring business solutions. On occasion, this gets done right, but more often than not, the cycle is all backwards and we start with or jump to the solution because that’s what we have to offer and we’re looking to see who bites or might have some kind of need it might fulfill, hence limited workability. Just like baking a cake or building an airplane, buying or selling software also has a recipe for success and that recipe still includes all the strategic, consultative, and solution selling. The reason for so much failure isn’t because companies are trying to do the right thing, but because they are not doing the right thing at the right time in the right order. Understanding the concept of what a solution really is and considering the proper sequence in which to arrive at the optimal solution, which includes beginning with first fully analyzing and understanding the business needs, requirements, and issues, will hopefully provide you with much future success in your next software purchase or, at the very least, mitigate some classic disasters.