Return on investment, as traditionally understood, is the ability of capital to generate dividends after recovery of the initial investment.

So, when applied to software infrastructure, what does it mean to generate dividends? When a company makes a long-term investment, it’s vouching for the future. It’s sending a message inward to its employees and outward to its clients that they are in the path of growth, and that the company is equipping itself with better business systems to cope with current and increasing demands.

But, behind closed doors, a different story is cooking. The shareholders demand to know when the investment is going to be translated to the bottom line – to see where and when the benefits will start to grow as a result of the investment.

Benefitting the Bottom Line

The answer is not a simple one, but we have good news. Yes, there will be benefits to the bottom line as a result of having better technology drive the operation, but that’s not enough. The technology improvements will have to be co-joined with several factors, most of which will come from within the organization.

The investment in newer software, increasing computing capabilities, and better systems infrastructure is not enough and will decrease profits if not properly managed. Imagine having a compact car; you have very low maintenance but limited cargo capacity and speed. If you switch to a fleet of newer, better-equipped trucks, you’ll be in better shape – but only if you can haul the trucks in time, find the right drivers, and understand that increased speed and cargo capacity require more maintenance.

Project Considerations

This little parable takes us to several issues to address before, during, and after a technology project takes place. Let’s list them; we’ll be expanding on these subjects in future blog postings:

• Define your business processes. This is the canvas that will be used to mold new and improved methods.
• Understand that you’re looking for a partner in a software company that will assist you with the implementation of the new technology. ‘Partner’ and ‘assist’ are the key words here.
• Define the scope; it should be based on budget, time, and organizational constraints. Too much of a new thing is sometimes counter-productive – we’re here for the long haul, so why not break the project into phases? Rome wasn’t built in a day.
• Create a set of lean processes where the new software will be the driving tool, not the end itself. The desired outcome will always be to work efficiently and rationally manage the limited resources.
• Embrace change. Not everything you were doing before is wrong, and not all changes are positive, but it’s always worth it to ask: What can we change to better our business and ourselves?
• Resources. Do we have time to devote to the process? There’s an 80/20 proportion of time that the company needs to assign to the project versus the time the software firm devotes to it. People are another resource. Do we have an internal project manager? Are people motivated enough to change? And the dreaded question: Do we have the right people?
• Define parameters for success: key metrics. Is our objective to reduce inventory? Turnover? Create sales growth? Improve purchase-to-pay and sales-to-collect processes? All of the above? It’s important to take the key objectives and establish a before-and-after comparison.
• Understand that the system will be as good as the information that it will retrieve for the company: system intelligence tools will assist in transforming data into meaningful information. These are not an ‘add on’ to the system – they’re a necessary step to evaluate the implementation’s success.
• Limit customizations by normalizing the business. Adopting vertical market business practices is sometimes a compromise between what the company used to do and the new ways it’s finding to achieve the same or better results.
• The end? Not even close! When the company is live with the new software, it’s just the beginning of a deeper transformation that will now take place because of the new tools: the system will be the launching platform of changes in yet a bigger scale. These mutations will have a solid foundation in the new and refined processes.

This is a non-comprehensive list of tasks that companies should do as part of a paradigm change: the shifting in the return on investment concept to a bigger picture – an infrastructure project that will help the company’s future growth.

Think of a leap forward in technology as similar to acquiring a new building – it won’t bring immediate results, but it will remove factors that inhibit growth and create new tools that will be assets of great value in the future: mobility, scalability, web integration, increased controls, traceability and many more.

ROI of Software Projects

So, at this point, it’s required to go back to the original question: what is return on investment applied to software projects?

The ‘return’ on a typical investment will be the percentage of profit in excess of the costs. It’s not easy to identify the costs because software acquisition, licensing, maintenance, and implementation disbursements will be only a fraction of them. It’s necessary to add the internal, hidden costs of devoting company resources to the project: human resources, time, expenses, and several miscellaneous resources that should be collected to truly assess the cost. Once the cost is determined, the most difficult task of determining the profit starts. What is ‘profit’ on a software project? We’ve seen that it’s difficult, if not impossible, to isolate how new software or new processes will impact the bottom line. But we can use indirect methods to track the benefits and assign dollars to these problems.

Here are some examples:

• Faster inventory turnover means reduced working capital. Therefore, more resources can be assigned to new investments. The internal revenue rate of the reduction in working capital can be quantified in USD.
• Less processing time to sales orders means less idle time for customer requisitions. Similar for purchases. In the ‘Return from customers’ process a reason can be added – “not shipped on time” – so the reduction in these returns after the go live shows more efficient sales processing.
• Increased controls in costs and sales price mean fewer errors; if 1% or 2% of the sales have a small price mistake, the savings could be quantified by making an average of dollars times orders, then applying the percentage to that average.
• Faster analysis time means that finance people can drill down from the financial records to the final results to conclude the analysis and make, if appropriate, corrections. This means more accurate financials and less processing time for month-end closing. A metric there could be ‘days to close,’ assigning a dollar value to each day saved for closing a period.
• The ‘cost of opportunity’ of having enough inventory to meet the sales and/or manufacturing demand. The ability to have the minimum required quantity to do business without overstocking and anchoring capital but also without losing sales or slowing production due to lack of raw materials. The quantification here is difficult, but it can be summarized as the percent of orders shipping complete and pairing the index with the processing time of the sales orders. The value to quantify here could be the sales lost due to lack of inventory, the USD aggregated of sales lines closed without shipping plus the customer returns associated with tardy shipping.
• Quality assurance. Fewer returns to suppliers due to increased quality controls prior to moving the stock to inventory means fewer defective products; in manufacturing, lost batches can be quantified, and customer returns and inventory issues (stock going out) due to supplier defects not previously detected means reduced storage costs or non-recoverable shipping charges. All these can be quantified, and that’s the savings by applying QA up front, prior to receiving materials into the warehouse.

The real cost of not having these metrics is to keep doing what the company currently does, just with new software. That is really a missed opportunity to assess the organization leanness and, many times, drives the perception of not getting the desired results after the software is live.

To summarize, there’s no right and wrong software implementation – each one is as unique as each company is, and that’s the challenge. But adopting a mindset other than the quick return on investment, one toward the model of acquiring a partner in the software firm that will help the company take on growth challenges is the first step toward a successful implementation. And key measures in strategic areas of the organization prior to go live, at go live, and during each semester will ensure that the investment provides the desired changes in the right direction.