How to buy a digital internal audit management software? Part 1 (Introducing the 14 most important evaluation criteria)

Internal Audit departments across the globe are posed with a unique challenge – to reduce risk-exposure to their own practice by building digital controls & enablers.

The threat is real.

After the pandemic, the need to have digital controls has become urgent because of these top 3 reasons,

1. To control costs

2. To increase the speed of internal audits that matches the speed of business

3. And, to add more value to the business

Richard Chambers, former president & CEO IIA, in his recent book coined the term “Change Agent” - an internal auditor who will redefine the course of internal audit in the post-pandemic world.

Digital transformation is one of the important agendas for a change agent. And leading it can be a rewarding experience.

Many change agents have already commenced this journey.

You need Software

One of such decisions, with a long-term impact, will be – what software to use?

Here is the thing, even today when you use excel and email-based systems, your work is essentially dependent on different types of software.

So, any further transformation you undertake will depend on software too.

Once you have answered the necessary questions of change management & convinced all stakeholders that digital is the way to go, you will figure there are 3 ways you can bring in new digital controls and enablers to real existence,

1. Buy a packaged digital software (a digital product)

2. Build the digital software in-house or outsource the work.

3. Build some, buy some

Why would you buy a digital software?

One of the driving factors is the specialized nature of the software.

While no one packaged software / digital product might be able to cover all the functionalities that an organization wants, buying does help you fulfill specialized requirements in a short span of time.

Typically, when software vendors build a product, they focus on tackling specific problems well. They tend to specialize.

Also, because they are solving a problem that is faced by many teams, the product when sold results in a lower cost of ownership for you as a buyer.

So, the cost-benefit.

Yet, the downside of a software product could be that it does not cover solutions to all your problems, or it does not solve problems in the fashion that you want.

Why would you build a software in-house?

Ideally, you should not do it from scratch.

Unless there are very compelling reasons.

If you are deciding between “make vs buy”, a cost-benefit analysis should easily help you arrive at a decision.

To do a cost-benefit analysis, you should be clear about your own evaluation process and especially the costs.

For example, if you are adamant about building your own software from scratch, you might be underestimating the need for a configurable software with a flexible architecture, added support for changes, & regular support for day-to-day running of the software.

You might also be underestimating the time it will take you to get a comprehensive software built.

While you might have a great initial budget available to get started, you might face a sudden rise in unaccounted costs when subsequent improvements or developments must be done.

Also, you might be underplaying the risk of technical & techno-functional talent acquisition.

Of course, in the end, you will need a buy-in from the CEO, CFO, CIO & board.

Even if you get a resounding yes there, sooner or later, you will end up competing on IT budgets with other customer-facing processes.

There are no prizes for guessing who wins this kind of competition?

Having said that, a part buy part build approach is a great option.

A software product can provide you say 80% of the functionalities you need and then you can build custom automations around it.

Another way is, you can combine different software to get the job done.

The Big Question – How to pick the right software

As a seller, I have sat through many software buying evaluations for the purchase of a digital internal audit management system.

There were times when my product, Audit360, was selected by clients for solving their problems.

And there were times when it was not.

Every time, I have asked the CAEs, “Why did you choose Audit360 over other software?”

Or “Why did you not choose Audit360?”

This led me to have insights into what different stakeholders evaluate (in my case, CXOs, CAEs, and Audit heads).

I have compiled this knowledge over time and now, I am putting it out in form of this series of articles.

“How to buy a digital audit management software”

I will be presenting different criteria for evaluating a digital software.

You can use it as a framework or an insight to make your decisions.

You could make a wrong choice

As I said earlier, for Audit360 I have sat through many evaluation meetings.

These evaluation meetings and then subsequently the process of implementation and running of Audit360 by our clients has given me a very good idea on -

What benefits do businesses aim for?

What are the hidden expectations?

What are the spoken expectations?

How do things evolve over time?

Now, there have been some outlier occasions for me when Audit360 was not chosen in the evaluation process, but the organizations came back to us after a few years, with the same requirement saying they made a wrong choice earlier.

What happened?

Why do stakeholders end up making wrong choices?

What makes them relook at the decision after a few years?

While I am not advocating one product over other, such situations point to the fact that to get a reasonably accurate evaluation done, you must look at many aspects.

So, it boils down to how should you evaluate a digital software?

Here is the list

While the ideas I present are applicable for any digital software evaluation, I will stick to audit management software evaluation as this is where I have a better understanding of the domain.

Let me list out the broad criteria that you should investigate when evaluating an internal audit management digital software.

The top 14 criteria are,

1. Customizability of the software

2. Domain understanding of the vendor

3. Workflow sufficiency of the software

4. Configurability

5. Evolution of the software over time & its future roadmap

6. Complex or easy to understand

7. Support channels

8. Other value-added services

9. Cost (CAPEX or OPEX model)

10. Users & concurrency

11. Configurability

12. Product innovation

13. What is your goal?

14. Reputation of the services provider

In the current article, I will just pause here at the list.

In the upcoming articles, I will give a full breakdown explaining the 14 criteria with examples.

But before you do anything else, I want you to quickly frame some of your own ideas.

Here is some food for thought.

Which ones are your top 5? Are they really?

Now, some of these listed criteria might intuitively sound relevant to you, and some might not.

Right now, in your mind, you must have already made a list of the top 5 criteria that you immediately connect with.

This is good.

Which are these top 5 criteria?

Note them down.

Why are they your top 5 criteria?

This is an important question.

While you might think that other criteria are not so important, stay with me for next few articles.

And let me change your mind on that.

It will amaze you, how ignoring some basic analysis could lead you to a very faulty evaluation.

The balanced approach is the best one

Say, for example, you have a software product for evaluation that in the first appearance seems to have exactly the features that you want. It is a match made in heaven; you think.

But changing anything is difficult in this software.

You might think customizability is not such an important criterion when the software exactly fits your requirement.

But you will be scratching your head later when you make your first small “tiny-mini” change request.

“You can’t change even this much???

Are you saying for every small change now I need to come to you???”, you might find yourself shouting at the vendor.

But it was not part of the deal anyways. You have only yourself to blame.

This is where you must understand the life cycle of an enterprise software.

On the other end, you could be evaluating a software that provides you a lot of flexibility but doing anything concrete requires you to model your processes from scratch.

You could be over-joyed by the fact that there will be so much freedom.

What you might not realize then is that modeling everything from scratch could be a wasteful activity for you and your team.

Just like in governance & auditing practice, you balance the strictness of controls, you need to take a similar approach here.

A balance of out-of-the-box features and customizations.

With this overview, in the next few articles I will discuss the 14 criteria of evaluating an internal audit digital system in detail with concrete examples.

Till then let me know your comments.

‍