When and How to Automate

Software can save time, effort, and money, but not without demanding its fair share of resources first.

Business software such as CRM (customer relationship management) and CPQ (configure, price, quote) helps companies manage their commercial and pricing activities. Many more software companies focus on only one aspect of such activities, such as price analytics or data visualization.

For some large companies, their daily activities would be nearly impossible without such assistance. For others, such software may address a real problem, but is purchasing and implementing worth the cost?

Here are some factors to consider beforehand.

Where Automation Is Best

Software that helps to perform certain business tasks is getting better all of the time. AI and machine learning is expanding the scope of what jobs can be done.

However, software and automation is still primarily best in the presence of three factors:

• Lots of data: in order to find statistical patterns in data, you need a lot of it. Machines are much better at handling large datasets than humans are. Companies that produce and/or consume large quantities of data are particularly positioned to benefit from software that can help to manage and dissect all of it
• Standardized data: lots of data isn’t helpful if it isn’t in a format that is easily read and compared. Companies with different data systems and formats oftentimes will need to find a way to clean and prepare it (on their own or with additional software) in a way that is even usable by other programs
• Repeatable processes: sometimes the nature of a business means that processes and activities are rarely consistent. The flexibility of a human to understand, adapt, and adjust is therefore more important than the presence of automation

Let’s say your company passes these three factors. Software can help in theory, but what else is important to consider?

Relatively Stable and Effective Policy

Software is good at automating repeatable processes, but that doesn’t make them the right processes. Doing the wrong thing efficiently isn’t the same as doing the right thing. There’s a reason that Peter Drucker wrote about the effective, not the efficient, executive.

Automating existing processes and policy runs the risk of building a house on a weak foundation. That is why we recommend to have a comprehensive review of the strategy and methodology behind the tasks with which software will assist. This will create a strong foundation upon which to automate.

Efficiency should come after effectiveness. Stable and effective policy ensures that software makes the right things more efficient. It also lessens the risk of requiring substantial re-development in the future.

Vendor vs. In-House

Once a need for software has been identified, a critical choice for companies with more sophisticated IT teams is whether to develop such software in-house or look to external vendors. Many consider both, having internal developers “bid” to some degree against outside vendors.

The benefits of using an external vendor include:

• Faster project: since the vendor already has a developed product, it should be able to begin implementation sooner
• Best practices: companies can lean on the expertise of a vendor that has worked in their field, adapting to an existing framework or methodology
• Cost: depending on the situation, the cost of an external vendor may be less than the overall cost of developing, maintaining, and updating one’s own tool

On the other hand, using internal resources can have its own advantages:

• Unique business: if your company doesn’t operate like many others and wants to stay that way, it may prefer to build a tool to its own situation
• Iterative approach: if company requirements and processes are in flux but the software need is not, it may be more valuable to utilize an agile methodology and accomplish quick hits rather than look to solve everything at once
• Cost: needless to say, external software can be expensive. Even software-as-a-service (Saas) pricing models can be a substantial expenditure. At times, internal IT may be more cost-effective

There isn’t a simple answer that fits all companies and situations, of course. But it is important to have a realistic understanding of the tradeoffs between the two.

Is Software the Only Answer?

Sometimes after identifying a problem that could be ameliorated by software and going through a vendor selection process, the numbers just don’t add up. Perhaps the cost is an insurmountable burden, or the rollout timeline leaves you without a solution for too long.

Remember: doing nothing is also an option. And a perfectly acceptable one, if the costs outweigh the benefits.

“Do nothing” in terms of software may not be the same thing as “do nothing about the problem”. Shifting an employee’s responsibilities, or hiring someone new, to cover at least a portion of the problem area could be a much better option. This is especially true if the company situation doesn’t match many of the criteria under which software is most appropriate.

Pilot for Testing

Assuming that you go the software route, there is the question of how best to roll out. Even if the software solution you’re considering can handle large problems at the company level, it is still beneficial to figure out a way to have a pilot rollout.

Piloting is a way to demonstrate a quick win for your change management. For example, piloting a solution with one business unit returns quantifiable results faster. If such results are in line with or better than expectation, they represent great ammunition for expanding the scope to other areas of the company. If the results are poor, then the company has the opportunity to adjust from learnings or abandon a larger rollout.

Pilots are an opportunity to test implementation as much as software results. Implementation is time-intensive for the vendor and the customer. Any estimates for timeline are contingent at best. Using a pilot enables the vendor to familiarize itself more with the customer’s systems while allowing the customer to get more realistic estimates for a larger rollout.

And Onward

Implementation, training, and user acceptance are time consuming. Scheduling is hard. Things break. The role of the project manager and the need for continued change management won’t decrease for many months, if not years.

This short piece barely scratches the surface of what it takes to make a large software decision. But by putting careful thought in at the beginning of the process, at the recognition of an issue, a company can increase the odds that a large software implementation will have a positive ROI—and not cause more problems than it purports to solve.