How do you measure compliance with a core SunSystems design?


Since LLP Group was founded in 1992 the company has specialised in the deployment of ‘core’ SunSystems designs. Infor’s SunSystems, with its concept of transaction analysis, account analysis (enabling the mapping of local to corporate charts of accounts, or vice versa) and its unified ledger (accounts payable, accounts receivable and general ledger all in one), is ideal for this purpose.

Aspects of financial analysis that are common to an international organisation, such as balance sheet and P&L structures, departmental organisation, asset classifications, and product categorisations, can be standardised for all instances, and those elements that are required for local reporting, such as a local chart of accounts, tax classifications, and so on, can be ‘filled in’ when the core system is deployed in a particular country. The idea can also be extended to procedures, and international organisations will often try to standardise their purchasing or sales procedures.

A Core System is thus a skeleton that reflects elements common to an entire organisation, together with some Statutory Space to enable local requirements to be met.


But it’s one thing to implement a ‘standard system’ and it’s quite another thing to ensure that it doesn’t drift away from the standard once consultants and sponsors have gone home.

Nearly eighteen years ago LLP Group was asked to design a core system for the aviation division of one of the world’s largest oil companies. We implemented this system in Southern Europe, the Middle East, the Balkans, Central Asia, the Caribbean, and in both North and South America. As the years went by each of these countries began to drift away, ever so slightly (in some cases), and ever so considerably (in others), from the standard we’d established.

The organisation wanted to rein them in, so they set us an interesting task, to analyse each system and assess its compliance with the standard core system.

We hadn’t, until then, ever thought of how you would ‘measure’ system compliance. You would think that such a measure is generally qualitative rather than quantitative. But I like the idea of reducing things to numbers, and to reduce something complex to a single number is best of all.

The question of overall compliance raises subsidiary structural questions, such as the compliance of ‘what’ and ‘for what purposes’ as well as issues of importance and priority. Some things matter more than others. We needed to impose some order and structure on the hundreds of elements that make up a system.

So what we did, was first to consider what we called ‘Broad Functional Areas’. These reflected the purposes that the system served (at least those pertinent to this organisation):

CBPI Corporate Business Process Integration

  • International Sales recording
  • International Invoice recording
  • Cash receipt recording

LBPI Local Business Process Integration

  • Local sales recording
  • Local invoice recording

CMI Corporate Management Information

  • Provision of Sales Information to Corporate HQ

CFR Corporate Financial Reporting

  • Provision of standard financial reports (P&L, Balance Sheet, etc.)

LFR Local Financial Reporting

  • Provision of local tax and other reports to local financial authorities

LMI Local Management Information

  • Provision of Local Management Information

Each of these areas is served by a different set of Core System components, which we divided into these areas:

  • Coding (coding of key elements such accounts, products, etc.)
  • Preconfigured Reports
  • Set Up (Journal Types, Sales Types, Calculations, etc.)
  • Programs (additional supporting programs, especially those handling interfaces)
  • Statutory Space

And each of these areas can be broken down into individual components, each of which may also be given a rating in terms of importance.

We could then measure compliance at the lowest component level (weighted for importance) and determine the overall compliance of these five sets of components and their impact on the six broad functional areas. The result is a matrix of compliance % measures – five sets of components against six broad functional areas.

And an average compliance % across all broad functional areas, and then a single overall %.

You might think that this is a somewhat academic exercise, but it’s not. SunSystems experts may find it easy to grasp the hundreds of details that make up a system but when your sponsor asks you ‘how compliant is our system in, say, Tanzania’ how else can you put it in a nutshell?

87%, for example, puts it neatly and succinctly.

We calculated scores as high as 96% and as low as 46%.

And then, of course, the question arises as to what to do about it. But that’s another story.

Contact me through LLP International if you’re interested in learning more about this approach.

2 thoughts on “How do you measure compliance with a core SunSystems design?

  1. LLP International - SunSystems consulting and implementation across borders

  2. How do you measure compliance with a core SunSystems design? | LLP Group - software consultancy & implementation

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s