Software That Matters (Part 9)

Back to Knowledge Bank
Posted by: briansittley Comments: 0 0 Post Date: December 3, 2015

WhitePaper2010_Cover5 years ago we first published a series of posts entitled “Software That Matters.”  It was an ERP implementer’s point of view, culled from long experience, on why and how to purchase a business management software system.  Later, we turned Software That Matters into a popular white paper that has since been viewed hundreds of times.  
After five years, we thought it was time for an update, to reflect lessons learned since then.  As it turns out, the vast majority of what we said then remains every bit as true today.  Still, five years is a long time… so we decided to carefully retrace our steps, re-edit our paper, add some comments and present it as a series of blog posts that will carry us through November, 2015.  We think that’s timely, as many companies at this time of year tend to reconsider the software they use to run their business — and how they might do better.
In our series we will again try to convey what’s important, what to measure, how to buy, what works, what it costs… and the many other business considerations required of this strategic investment, in what is probably the most important (and expensive) software a company will ever buy.  In other words, the Software That Matters.  
Today we offer post #9 in our series.  Our full series begins here.  We hope you find it of value and welcome your feedback.


Start Small and Discrete

Having deployed a couple hundred accounting or ERP systems over 25 years, probably our most important recommendation on the matter can largely be distilled down to the one simple principle summarized in our headline above: start small and discrete (whenever you can).
Prior to ERP purchase and deployment, the wisest course is always to engage in a discovery process (or needs analysis, or business process analysis – they go by many names).  During the discovery process, pain points are identified.  How those pains affect others in the company should also be identified.  Bottlenecks and redundancies are uncovered.  A basic workflow is flowcharted that boils down to: How are things done now… and how should they be done in the future?  This by the way is the foundation of a process known today as Value Stream Mapping.
As you move through the discovery process, you’ll find various business process/problem areas that need to be addressed, improved or corrected.  Your job is to pick out just the one or two areas, departments or pains that warrant the most immediate attention.  These are the areas usually best suited to become the first phase of your ERP deployment – after all, they should be among the most urgent.  Solve those, and you will see some immediate ROI, a good benchmark for success and for continuation of the deployment.
The task at hand is to identify the obstacles and their potential solutions, and map out a project plan that addresses and resolves them.  The tasks should be confined to the one or two project areas that will initially be addressed.  For example, it may be that the company needs to deploy ERP across many functional areas including some or all of… the front office, billing/purchasing, payroll, order flow, customer service, warranty and returns, production, shipping, warehouse management, and so on.  Nonetheless, the prudent course is to pick just a couple – say financials and order processing for example – and start there.  You can’t always do it this way, but it’s the safest route when able.
This ‘small and discrete’ project approach will yield several benefits:
First, it gives project stakeholders on all sides a tangible, realizable goal to work toward.  Everybody knows the goal, though not everyone is affected (only the departments in question) and frankly, there’s less to go wrong.  The likelihood of bringing the company ‘to its knees’ due to a dramatic changeover is minimized or eliminated.  Besides, with a well-defined project plan, transition damage should be largely nullified.
Second, it gives you a chance to evaluate your provider.  Before committing to the whole project, you’re committed to only part of the project.  Also – worst case scenario — it’s easier to pull the plug on a small, phased project than on a large and sprawling one.
Third, it mitigates, or at least spreads, project costs.  While you’re usually going to buy substantially all the software modules up front, you are only committing to a manageable slice of the services at the outset.  Moreover, services are typically paid for as you go, so you’re spreading your costs over the timeline you define.
Fourth, it gives you the opportunity to celebrate small victories, while laying the foundation for rollout to other departments in a positive light.  When you change business management systems, everyone is watching, even the people not immediately affected.  Early successes make subsequent departmental adoptions that much easier.  Next we’ll look next at benchmarking steps, that is, how to know when you’re making progress.  After all, you cannot improve what you do not measure.
Next up: turning data into intelligence.  The Key Indicators you need to have before taking action.  Stay tuned…

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Knowledge Bank