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? 

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.