Getting your search for client software started
Let’s face it. Many business owners and decision makers don’t have the slightest clue where to start when looking for a new accounting or ERP software system. And, really, how could they? “Accounting Software Buyer” isn’t stamped on anybody’s business card. Not that we’ve seen, at least. It’s an intermittent type of thing. Project work. The average business will look for a new ERP or accounting system maybe once every 4-7 years. Much of what even an experienced software buyer has learned will be outdated by the time they search again. Purchasing a new financial management system is a major business decision. But it is one where companies are unlikely to have internal expertise. In other words, it’s a perfect consulting opportunity.
Many times consultants will have the same questions and anxieties when it comes to finding the right software that business decision makers have. Essentially, the key point of concern comes down to this: How do you find the right program in a sea of options and get it effectively deployed? This eight step process provides best practices for you to follow as you address your client’s software needs.
1. Understand your client’s business problems
Every great solution starts with a problem. Whether your client has asked you for assistance to resolve a specific issue or you have personally identified an issue in your client’s business, defining the problem is the best place to start. To do this, you’ll want to identify a project contact lead. This will be the person or people at your client’s company that you will work with most closely on the project. At this point you may want to spend some time interviewing the client and understanding their business processes from start to finish. Surveying the users of their current software can be very useful. These users will be able to identify what’s inefficient or tedious with their current processes.
Once you have issues defined it may be advantageous to have your client rank the importance level of each problem area. After this is done you may want to have your client estimate the financial costs generated with the problem areas. After all, each problem area will create an inefficiency which results in increased expenses and/or lost revenues. This information can then be used in step three to determine which software to evaluate.
2. Define the scope of the software requirements
In the business software market there are solutions designed to meet virtually any need. To define the scope of the project you should ask yourself if the problem is limited to one particular function of an existing software system or an overall problem in business processes. Answering this question should be pretty simple based on the work that was done in the first step of the process.
If you find their issues are confined to one particular area of the business, it may be wise to look for a software system to address this one issue while leaving their rest of their systems intact. If however, they have an overarching issue with their current software it may be best to look for an all-encompassing software package. After this determination is made, it is best to prepare a summary of the project scope. This summary can then be presented to the client for approval. In the end the scope summary will ensure that you will return with a deliverable that will meet the client’s expectations.
After the client has signed off on the summary of the scope of the project, you should begin mapping the issues identified to solutions. For example: a problem with unapproved purchasing by staff could be mapped to a system with a purchase requisition management module. If they have identified inefficiencies in their billing process you could map this to finding a system that can automate invoicing. This mapping process should leave you with an outline of modular and feature requirements.
After identifying particular feature needs, you will want to gather some information about the context of the software. What existing systems will the client need integration with? How many users will need access to the system? Is the client looking to host the system internally or on the cloud? What is their OS environment? All of these will be factors that you can use to narrow down the list of appropriate options.
3. Identify appropriate software to review
The act of identifying appropriate software packages to review is largely determined by the specific requirements your client has. The benefit of preparing that project scope document is you have your requirements already laid out. At this point you simply need to identify which packages meet the requirements so you can review them in-depth.
Now then, it’s time for a quick plug. You knew it was coming, didn’t you? If you are having problems defining the requirements for your client, feel free to give us a call. We’d be happy to go through some questions to help understand their software requirements. We can then use your requirements to match you with appropriate options to meet the requirements. Instead of spending hours surfing the Internet to determine if a software package is worth further review, we can match you with a group of appropriate options based on your client’s specific needs.
4. Evaluating your software options
Once requirements are fleshed out and a group of appropriate software options has been identified you can begin your in-depth reviews. The first step to any software review is gathering product literature. Since so many products are modular based, allowing you to purchase only the modules you need, you may want to engage with software providers to ensure that you are reviewing relevant product literature. During this initial engagement you can also give the software provider the project scope documentation. A smart move would be to ask the providers to show you how their software will meet each of the key problems that need to be addressed.
At this point you should be able to make a determination of which providers have the strongest grasp of your challenges. Those providers should then have the best ability to provide solutions to the challenges. This will then give you a short list of options to really review in-depth allowing you to arrange demonstrations and request proposals from the providers.
5. Determining when to bring the client into the review
After your review of the software packages the question of when to bring your client into the review presents itself. To provide a quality deliverable you will likely want to handle an initial review or screening of the software packages. Depending upon your role in the process you may even want to view demos yourself before bringing your client in for reviews. If your client has given you the okay to make a final selection there is obviously no need to include them them in the review. Chances are though your client will want to see the software before a selection is made.
In order to maintain your role in the project it may be best to look at several options and pick two or three for your client to review in-depth with you. This way you can explain to your client which packages were excluded and why. You can also show them why the top few have been selected and what benefits they provided over those that were excluded.
6. Determining your role in implementation
Implementation can be an extensive process involving a number of steps from software configuration, to hardware setup, to setting up integration with other systems. There are numerous tasks to ensure that when the software is switched on the organization will hit the ground running. Depending upon your arrangement with your client there are many services you can offer. Some consultants will handle hardware configuration while others will receive training from the software provider and in-turn train the client. If your client is outsourcing the entire implementation you can position yourself as the liaison between the software vendor and your client. The point being, during an implementation there are many ways to position yourself to offer services to your client and generate revenue.
7. Making the final decision
Once you have finished reviewing software functionality and have an implementation plan laid out, you’re almost to the point of making a final decision. Before making the decision though it’s always advisable to seek references. These references should be able to provide you with feedback from a user’s perspective. That way you can identify possible pitfalls in implementation and unrecognized benefits of a particular system. There is only so much that you can glean from reviewing the system yourself, whereas a user with countless hours of experience on the system can provide much more insight.
You’ll then want to meet with your client to debrief them on all the reviewed packages. At this point you and your client can assess your final thoughts regarding the solutions that each system will provide to the issues/problems identified at the start of the review. Using the project scope and requirements document you can then determine which package will meet the most requirements and solve the most issues. After this is completed you should be ready to make a decision and move ahead with the implementation of a new system.
8. Determining your on-going role after implementation
Once implementation has been completed the job is not over. In fact there will be many opportunities to continue to offer services to your client. If your role is that of an accountant or CPA you can offer financial services like reporting, auditing, tax preparation, etc. If you are an IT professional you can offer hardware support & maintenance services. At some point down the road there will likely be a need for an upgrade offering you the opportunity to assist with another project.
When you take on the task of helping a client find software, you have a great opportunity to provide years of valuable services to that client. Following these steps should provide you with a clear road-map from problem diagnosis to completed implementation while establishing a future revenue stream.