Standardization vs Customization: Finding the Right Balance

In October 2022, the European Parliament voted by a landslide in favour of mandating USB-C connectors for all handheld electronic devices from 2024. The most notable impact was to force Apple to ditch its longstanding lightning connector on its iPhone’s saving many of us from carrying that one extra cable. The mandate is an obvious and compelling use case for standardisation. Apple aside, who has a notorious ironclad grip on its product’s eco-system and its ability to monetise their walled gardens, standardising all devices to connect with a single connector benefits everyone, saves cost and reduces unnecessary waste.

This example follows many other global shifts to standardise and lays the foundation of many finance transformation programmes, pushing standardisation as the key to the promise land. Reducing unnecessary complexity is a good thing but there is a delicate balance between standardising and maintaining flexibility.

Why standardise?

Standardisation is the process of developing standards to maximise compatibility, interoperability, repeatability and quality. The definition itself lends itself to the obvious benefits of moving away from customisation to commons ways of doing things. We’ve seen use cases across the globe where this has brought immense benefits well before USB-C. Think EV charging connectors with CCS2, shipping containers with eh ISO 6346 standard dimensions, SQL databases and of course for fellow accountants, the International Financial Reporting Standards. It also applies to more innocuous everyday activities from self-service checkouts to the way we interact with the internet pages – think of the burger menu on mobile devices or the nav bar at the top of most web pages. We’re increasingly finding that many of our daily tasks are becoming the same to the way we shop and communicate.

Global phenomenon: The standardisation of shipping containers to the ISO6346 code transformed the scale of the global transportation of goods.

In Finance, there are many benefits to standardisation that can enhance the performance of the finance function such as:

• Eliminating spreadsheets and offline working to cloud based tools and forms

• Automating transactional tasks using AI and machine learning

• Utilising APIs and interfaces to schedule activities rather than executing them manually

Doing so bring immense benefits to an organisation such as knowledge risk when staff leaves, faster reporting, quality data and the allowance of staff to do more meaning value adding tasks such as analysis and commercial partnering.

One size fits few

This fissure between Workday and Amazon is a story that has played out, albeit on a smaller scale, with many finance transformation programmes. At the beginning, the project starts with unbridled optimism promising standardisation that will make everything more efficient and effective. Months or years later, that optimism dissipates and animosity brews between those who made the promise and those who need to live with the new standardise environment knowing that the ‘standardised’ way doesn’t perfectly align with local GAAP, tax or business requirements.

It was 2019 when Workday, the global cloud HCM and Financials platform, had a watershed moment – it partnered with Amazon, one of the world’s largest workforces. Sadly the HCM deployment was abandoned with Amazon returning to its original HR solution. Workday later revealed that the agreed withdrawal resulted from Amazon’s unique requirements that differed from what Workday was built to deliver. Workday operates on a core architecture and process model and cannot easily alter its approach to accommodate a single customer, even it that customer is Amazon.

Landslide: The European Parliament vpted with 602 votes in favour with 13 against.

Close to home, we had one example with a client who were making efforts to control spend by introducing tighter processes to supplier payments by introducing a no-PO no-Pay policy. The new process introduced robust controls but the issue was that the initiative some flexibility during certain situations such as:

• Many items of spend weren’t conducive to purchase orders such rent costs, utilities and phones where spend were tied to pre-agreed tariffs and rates and payment couldn’t be help up with delayed purchase orders

• A significant part of this business required paying many of its direct field costs upfront before work was done, let alone before the purchase order or invoice was issued.

In a second example, we were tasked with supporting the implementation of a sourcing system to a mining operator with mines in Tanzania, South Africa and Namibia. The management team were sold the benefits of replacing its legacy ordering system with a single application to provide uniformity with spend reporting and global sourcing. What was overlooked and not carefully considered were the the local requirements amongst the regions where the mines operated. The variations with requirements were so great the software vendor threw the kitchen sink with the single application so that it became all things to everyone. This issue was this ‘standard’ single application became so complex that it took 20 steps to order a simple part with many unnecessary functions and steps for a specific user.

In both cases above, the standardised way of working ruined the user experience so severely that staff either circumvented the system to procure goods and services or gave up altogether negatively impacting the company from running its business. In finance, and other support functions, its always important to maintain sight of the true objective, which generally speaking, is to enable the business do what it does by providing management with quality financial insight promptly.

Striking the right balance – The Sub One approach

Throughout our two decades with finance transformation, we often hear from other consultants ‘is this standard?’. Clients perceive this question as the appearance of intelligent dialogue but doesn’t really achieving anything nor does it provide any insight on what or whether there is actually a problem.

It’s imperative to understand why custom processes are done in the first place and to keep asking questions on why its done this way before making the decision and investing the time and effort the change the process in the standard way. On many occasions, the requirements may no longer be relevant so standardisation is possible or misunderstood so that the current process can be simplified.

Defining strong design principles from the start is critical so that each decision on whether to change something can be assessed against those design principles. On an ERP deployment, we had the following design principles:

• Financial activity must be reported consistently to enable comparability and visibility as group level

• The system must enable the efficient execution of business activities to maximise customer service

• The benefits to change something must outweigh the cost of not doing so

When faced with a custom process in a business unit that wanted to retain its custom workflow of paying its direct costs as opposed to a group wide approval process using the delegations of authority, we advised that there should be a separate framework for direct costs that enabled a quicker turnaround of spend approvals so that it didn’t impede the client from running its business. This set a foundation of back office and field spend across the whole group and enabled the business to be more agile, while adopting a system that was transparent and easy to monitor.

To learn more about what we’ve done, please contact us at Subone

Image source: Sub One Group Limited Copyright

Back to Articles