On Systems Integration – How to reduce the risk?


A couple of days ago I wrote about the challenges of systems integration, and the advantages and disadvantages of Best-of-Breed and Fully Integrated Solutions.

See Systems Integration.

If you’ve chosen the Best of Breed approach, how can you reduce the risks of integration, and design systems that enable integration that’s as ‘seamless’ as it can be? 

integration 2

The first way is to keep things simple. Don’t integrate the impossible. In my experience of business systems, which is largely with financial, manufacturing, expense management and professional services management systems, integration usually involves a ‘front-office’ system that reflects the special needs of an organisation, and a financial system.

I’ve come across two main reasons why organisations choose to do this:

  • Some ‘front-office’ systems, such as our systems@work software, don’t include accounting modules. This is deliberate, in that they aim to work with any system.
  • Some ‘fully-integrated’ systems don’t possess powerful enough accounting modules to meet organisations’ corporate, management or statutory reporting needs in every country in which they operate.

In many instances I’ve found myself working on the integration of, for example, hotel management systems, or time@work (our timesheet, expense, planning and billing system for professional services organisations) with back-office accounting systems.

The synchronisation of ‘reference data’, those core data items such as ’employees’, ‘products’, ‘projects’, ‘departments’, even ‘accounts’, is usually handled manually, though on occasion automatically too (if automation is cost effective) with ‘slave’ and ‘master’ well defined.

When it comes to transactional data it is usually the ‘front-office’ system that is passing data to the ‘back-office’, and rarely vice versa, the back-office accounting system being essentially more ‘passive’. Even if this transfer is done periodically rather than daily, it is not so difficult to ensure reconciliation.

In all of these cases integration is relatively easy. Data flow from ‘front’ to ‘back’. But the integration of manufacturing systems with accounting systems is much more difficult, and although I have done this too, there are areas, such as ‘costing’ (the determination of the ‘actual’ cost of a product) where the task becomes much more complex. Costs of raw materials, components and semi-finished items, often based on accruals, may already have been transmitted to the accounting system, and will usually need subsequent revision as further costing details are obtained. Techniques such as standard costing can alleviate problems of this kind, and data may still flow generally in one direction, from the manufacturing to the financial system, but the number of transactions and the reasons for passing data are many more.

Where, first, to record transactions?

More complex questions also arise when you must decide where to record various types of transaction. In which system, for example, should supplier invoices be booked? Most organisations prefer to record similar transactions in just one place in order to avoid mistakes and to simplify procedures for the finance department. But the data derived from supplier invoices may be needed by both systems.

In the professional services world, supplier invoices are often recharged to customers, so supplier invoice data are needed in the professional services modules. If they are first booked there, then the question arises as to whether it make sense to book, say, utility invoices there also, rather than directly into the financial system’s accounts payable module?

In the manufacturing world, supplier invoices contribute to the cost of products, so must find their way either by direct initial input or through integration into the manufacturing system’s database.

The choice of where to enter data is further clouded by the fact that many ‘front-office’ systems are less well adapted to meet the burdens of statutory reporting, such as VAT reporting, and do not capture the information required for this purpose.

Transaction History

You must also make sure that modifications of data are achieved through additional transactions rather than through change to existing ones (the original values thereby being lost). You always need to know the before and after status of data. This is commonplace in most transaction systems, such as accounting systems, where posted journals are not usually modifiable. Corrections and any other kind of value changes are achieved through new journals. This is important because you must always know exactly which transactions have been transferred during integration, and once passed to another system, a transaction must not change.

Marking as Passed

It is also essential that there be some way of determining whether integration processes have been executed in respect of particular data. If you’re exporting transactions from one database to another you need either to be able to mark a transaction as exported or to store details of exported transactions in a separate table. And, of course, assuming that you have taken note of the second rule of integration, and as noted earlier, a transaction that has been exported should never change its value.

Date and Time Stamp

Make sure that all transaction data are ‘date and time stamped’. This isn’t essential, even if it is wise, in a ‘fully integrated’ system because processes are executed fully and at once and any processes that depend on the evaluation of data at the time of processing will of necessity evaluate that data correctly. But if a process is split between systems and cannot therefore be completed fully and at once any data evaluation may be influenced by later transactions and processes. Separated processes therefore need some other way of determining how to evaluate data ‘as of’ a particular date and time.

In a final post we will look at how software systems should be developed with integration in mind.

Launching LLP International


Ever since I started LLP Group in 1992 the company has specialised in the development and roll-out of financial systems for international organisations based around Infor’s SunSystems, a powerful mid- to upper-market accounting system that works everywhere in the world, whatever the local rules.

globe 2

We’re now a substantial group with offices in ten countries:

  • Czech Republic
  • Slovakia
  • Hungary
  • Romania
  • Bulgaria
  • Russia
  • Luxembourg
  • Belgium
  • Mexico
  • USA

Each of these countries participates in group-managed projects but each also has its own specialist areas and resells other software products besides Infor’s SunSystems.

Recently we’ve managed several enormous projects, including one for a large pharmaceutical company and another for a digital entertainment corporation. What’s important to these organisations is that they should comply with local accounting regulations and still report their financial results in a consistent way to their headquarters. SunSystems does this well.

Where such projects take us outside the ten countries where we have our offices, we have subcontracted to other companies who work in the SunSystems world, ensuring, though, that the core design is not compromised.

We’ve delivered projects of this kind for:

  • Shell
  • Kraft
  • Johnson & Johnson
  • BP
  • Air BP
  • Regus
  • HBO
  • Unilever
  • Glaxo Smithkline
  • Roche

..and many others.

We’ve done more than twenty years of such work, and over these years we’ve developed methods and approaches that we can apply anywhere. So, bringing all of this know-how together, we’ve launched a new concept – LLP International.

LLP International, though LLP Group, has probably the largest and most experienced team of SunSystems functional, technical and project management consultants in the world.

If you’re using SunSystems or considering using it and need to implement it consistently in several countries, then contact us through our website and we can tell you how we can help.