On Integration – Developing Software with Integration in Mind

I’ve posted two articles on the challenges of systems integration, firstly on the advantages and disadvantages of Best-of-Breed and Fully Integrated Solutions, and secondly on how to approach integration if you’ve chosen Best-of-Breed.

See Systems Integration and Reducing the Risks.

This post is concerned with how software should be developed if integration is anticipated.

You can think of it in this way:

Systems respond to EVENTS by executing software PROCESSES that update DATA.

In a single ‘fully integrated’ system the ‘complete’ response to an EVENT is contained entirely in one system and is reflected in one set of DATA. ‘Fully integrated’ systems can thus always ensure a complete response to an EVENT or no response, but are rarely left in an incomplete state resulting from partial processing. Typically, databases roll back incomplete PROCESSES, and all the consequent DATA changes, if there is a failure at any stage. It’s all or nothing, if you want it to be.

Integrating best-of-breed systems, working with more than one database, makes it more difficult to achieve this kind of integrity. The failure of a PROCESS in one system can’t easily trigger the roll-back of a PROCESS in the other.

Integrating separate systems requires therefore that you should easily be able to identify the success or failure of each part of a PROCESS and identify and control each set of DATA changes that each PROCESS effects.

For example, suppose you’re a company that distributes imported goods and you’re obsessive about calculating the margin you obtain on each product (this may be for good statutory tax reasons, or simply because you are unnaturally pedantic). The cost of the goods you sell is determined by the price you pay for them, the duties you pay on importing them and the cost of transporting them to your warehouse. You only know the true cost of each product once you’ve received the invoices that make up all of these costs. But, in the meantime, you may have shipped them.

Let’s consider an EVENT such as the arrival of an invoice for transportation. If the calculation of ‘actual’ costs is automated then your system must carry out the following PROCESSES:

Invoice Registration: The invoice is booked against supplier, tax and cost accounts.
Accrual Reversal: If an accrual for this cost has been made earlier it must be reversed.
Stock Value Correction: The difference between accrued and actual transportation cost must be calculated and allocated against all the stock items it is related to.
Cost of Goods Sold Correction: If there are items to which this difference in cost relates that have already been sold, then the appropriate portion of this difference must be allocated to a cost of goods sold account rather than to an inventory account.

Each step involves updating transaction tables, and if all these PROCESSES are occurring in a single integrated system then either they all succeed or they all fail, and the database either reflects a complete response to the EVENT or no response at all.

But if your finance system is separated from your manufacturing system then some of these PROCESSES must be carried out in one system and some in the other (and parts of some in both). It’s likely also that they will take place at different times (if there is ‘batch update’ of one system by the other rather than immediate update). It doesn’t matter for the moment which. In consequence it is possible that taken together the systems may reflect a partial response to an EVENT.

When developing systems that must be capable of handling partial failure in response to an EVENT the following approaches are wise:

Ideally there should be an explicit database table that identifies for each uniquely identifiable EVENT the PROCESSES that have been completed successfully and which are therefore fully reflected in the system’s database. Ideally such tables are present in the system that is sending and the system that is receiving. In reality, it is the state of the data that implies whether a PROCESS is complete, and it is rare to find an explicit table that records this separately, but it would certainly be useful. However the success of each PROCESS is recorded, the changes in data associated with each PROCESS should be easy to identify.
Transaction data that have been processed by an interface program must be marked as such.
All modifications to data that imply additional interface processes should be handled with a full audit trail. Ideally a modification to a transaction involves the insertion of both a reversal of the earlier transaction and a new transaction.
All transactions should have a field that identifies the order of events. Ideally this should be a date/time stamp. This enables execution of interfaces in the correct sequence, as well as the unwinding of PROCESSES if required.

If these safeguards are observed reconciliation and correction should not be too difficult.

System integration isn’t easy and there is no reason to believe it will get easier. There are still no standards for the description of data to which all system developers and integrators can refer. This is no surprise. Data are not objective objects which can be explored and described without reference to purpose, context and culture, and they never will be. They are not like the objects of material science; they are human artefacts.

Over the last decades I have witnessed a number of false dawns with regard to ‘easier integration’. These usually turn out to be useful advances in technology but rarely make functional integration any easier.

Two weeks ago I read an article on Data-centre Software in The Economist (Sept 19th 2015). That’s what made me think about integration issues. The article mentions Docker, a successful startup that’s making it easier and more efficient to move applications from one cloud to another. Laudable, clever technology, but, as far as I can tell, it represents no progress in the more difficult task of integrating business processes. Those of us who do such work can be assured of work for many decades to come.

Time-Based Cost Allocation in the Oil and Gas Industry

Oil and gas prospecting involves the deployment of highly experienced and expensive engineers in remote and uncomfortable places. They’re typically working on a number of potential oil or gas fields at the same time. Or rather, each may spend some hours or days on one field, and then some hours or days on another, doing seismography or other forms of wizardry.

Often such oil and gas fields are explored by joint ventures, each of which may be owned in different proportions by a number of different investors. It is essential therefore that costs should be distributed fairly across each of them. This ‘fair allocation’ of employee-related costs is usually based on the time that each engineer reports against each field.

SunSystems is an excellent financial system for oil and gas companies. It has the flexibility to deal with both local statutory reporting (which may be based on a statutory chart of accounts and will certainly involve many different kinds of tax report in local currency), and with corporate reporting (which may be based on a corporate chart of accounts, may require corporate accounting policy adjustments, and may involve translation into a foreign currency). SunSystems also contains a module for the automatic redistribution of costs against nominated entities (these may, for example, be departments, or projects, or, for that matter, oil and gas fields).

But SunSystems doesn’t include a timesheet module.

systems@work’s time@work fills this gap with a browser-based timesheet module that can be accessed by users whether they’re in the office or at large, using their PCs, Macs or mobiles.

Engineers record time against individual projects, in this case projects related to oil and gas fields, and at the end of each month or accounting period, time data are exported from time@work into a SunSystems Memo account (where the Project code in time@work is represented by a transaction analysis code in SunSystems). SunSystems Corporate Allocations module can then be used to pick up all the costs related to each engineer and to allocate them across projects in proportion to the time spent on each, based on values in the Memo account.

systems@work’s time@work is used by many international petrochemical companies:

OMV
Lekoil
Afren
Addax Petroleum
E.ON
Enquest
JKX
KBC
Lundin
Oryx
West African Ventures
Seplat Petroleum
Gazprom
Dana Petroleum

time@work can also be used for the capture of employee expenses, with authorised expenses being automatically transferred to SunSystems, where reimbursement can be initiated. Expenses can also be imported from electronic credit card statements.

It can also be used for scheduling and planning the allocation of staff to projects.

It’s relatively easy to implement, since it’s configurable software rather than software modifiable at source code level. It’s simple on the surface and therefore easy to learn and use, and yet flexible and powerful as an analytical tool.

Contact me if you are interested.

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.

The horrors of high inflation…the messenger doesn’t always get shot

In the mid-1990s, a few years after I’d started LLP Group, I was asked by one of our international customers to go to Moscow to sort out the mess they’d made of their SunSystems implementation. They were using the system for the purchase of their affiliates’ products, for inventory management, and for sales to their direct customers and distributors all over Russia. And of course they were using SunSystems for both local Russian accounting and for balance sheet, cash flow and P&L reporting to their head office in the USA, in USD.

The mess was a mess of several kinds. The Russian authorities were accusing the company of understating its Ruble profit and of implicit tax evasion, and Head Office couldn’t make sense of the USD-denominated reports it was getting, which seemed to overstate profit. A major factor in both of these messes was the fact that Russia was then a ‘hyper-inflationary’ economy. Special accounting rules are supposed to kick in when cumulative inflation over three years exceeds 100%, but this organisation hadn’t even got the basics right, let alone Inflation Accounting.

Now, SunSystems is a superb tool when it comes to dealing with demands from multiple directions. It can manage local Russian reporting in Rubles against a statutory Russian chart of accounts at the same time as USD reporting against a corporate chart of accounts. And it can do all of this without your having to enter a transaction more than once. Of course, there are always a few adjustments you need to make to reflect differing accounting policies (depreciation rates, for example) but these are few. LLP Group’s LLP International team has built its reputation on helping international organisations to do these kinds of things in SunSystems.

So my job was to set up the right structures and processes, export the entire set of ledgers, and bring them back into the system in the right way.

The biggest difference was that the previous set up had taken no account of the rules that apply in a hyper-inflationary situation, in particular of the requirement that for corporate reporting stock must be valued at historical exchange rates. When stock is bought in USD it gets valued in the Rouble balance sheet based on the exchange rate on delivery day. But when it’s sold, you can’t just convert its delivery Ruble value into USD on the day of sale, since this will show it as having depreciated materially if exchange rates have changed markedly. Profit, as stated in USD, and reported to Head Office, will thus be overstated. Margins will have been exaggerated.

When we’d finished the reprocessing of the ledger we ran the corporate balance sheet and discovered a ‘translation difference’, a loss, of more than a million USD. This translation difference, which always emerges when you go through the process of converting a balance sheet at a variety of different exchange rates, is reported as part of the P&L. I thought at first we must be wrong, so we checked and checked and checked again, and came reluctantly to the conclusion that it was right. The company needed to report an additional unexpected loss to its Head Office of more than one million USD.

The Russian Chief Accountant and I, once we were absolutely certain of our findings, nervously reported this to the CEO.

‘Are you sure?’ he asked.

‘Yes.’

‘Are you really sure?’

‘Yes, really sure.’

‘@!£$,’ he said, ‘but not your fault. I was afraid it would be bad news. But thanks for sorting out the mess.’

You don’t always get shot for passing on bad news, even in Russia.

SunSystems is still one of the best options for businesses that need a common accounting system all around the globe. It is extremely agile, powerful, and cost effective. And you can find SunSystems consultants to support you in almost every country in the world. Contact me to find out more.

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.

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.

http://www.llpinternational.com

Good Design is Timeless

There are no absolutes in good architectural design. Personal taste differs from one individual to another. Some like simple austere forms, modernist and functional, and some like exuberant decoration, from the gothic to art nouveau. Some like both, as I do, preference depending on the day and my mood.

But when it comes to software design decoration has no place. Simplicity, elegant or not, is the most fundamental design principle, in combination with readability. There should be no more moving parts than are necessary (which paraphrases 14th Century William of Ockham’s Law of Parsimony), but it’s equally important that function should not be obscured by the reduction of code to its logical minimum. ‘Clever’ code is dangerous if it doesn’t easily reveal its purpose.

So good software design is more like functionalist/modernist design than any other, simple and easy to navigate, and good functional design is timeless.

Take the Bata House in Wenceslas Square in Prague, built in the late 1920s. It became the model for thousands of shops and department stores, and if you look at it today it looks as new and fresh and perfect as it ever did. You would not think it is nearly one hundred years old.

And take Roma Termini, the main railway station in Rome. I remember arriving in Rome in the mid 1960s, after a long journey over sea and land from Victoria Station in London. The brilliant white walls were dazzling in the Italian summer sun, and the station was visible from miles away as we crawled to a full stop several hours late. It made an impression on me then, and it still impresses. Look at how well this cluttered hall is designed, how simple and light the long glass panel looks, not actually supporting the cantilevered roof. Perfect.

The same aesthetic is ‘visible’ in software, and particularly in the financial package we sell – SunSystems. Its principles haven’t changed in 25 years. It’s simple, elegant, easy to understand, powerful and functionally fit for purpose.

William of Ockham would have loved all three of these artefacts.

Riding the Russian bear

I’ve been living in Central and Eastern Europe for nearly three decades, so I’ve seen the region take three steps forwards, and then a step or two back, both politically and economically. Never more so than in Russia. I particularly remember the heady 1990s, when the Russian economy burst into chaos after the collapse of the Soviet Union. Freedom reigned in Moscow, too much of it for some. It was exuberant, expressive, socially liberating, unpopular, and on the whole disastrous.

We were well into the more sober Putin era when my company (LLP Group, based in Prague) was persuaded to dip its toe into the Russian market. We took over the customers of a firm for whom things had gone disastrously wrong. It was difficult at first because almost everything gets in the way in Russia (the form-over-substance financial regulations, the appalling cost of business services, the aggressive nature of customer-supplier relations, the prejudice against ‘Western’ software), but we made progress, and even some small profits in due course.

But these last few months have been more difficult. When the rouble fell in value some weeks ago we found that our bank simply couldn’t or wouldn’t convert our rouble balance into a safer currency and we saw our bank balances shrink in EUR value.

We resell software and consulting mainly to international companies investing in the Russian market. The accounting software we sell, Infor’s SunSystems, can meet both Russian and corporate requirements simultaneously. But, now, with many companies downsizing, or even leaving, it’s hard for us to know what to do. There are fewer companies who need what we sell.

Where is Russia going? Has the country set out on a path towards isolation, or has it been unjustly expelled?

Whatever the situation, we have no plans to leave. We have an excellent team of consultants in Moscow and St Petersburg, and we can break even at the moment, serving our current clients. It’s hard to know, though, if there will ever be new business for us in the future.

Granted, Western ideology informs much of Western reporting on Russian issues (Ukraine first and foremost), but I can’t help thinking that, for the moment, Russian pride has trumped pragmatism. Surely, things will only get worse for ordinary Russian citizens if Putin doesn’t seek a change of direction.

We don’t want to abandon our business. If only Russia were a little more like us, we wouldn’t have to.

Choosing New Software – Best of Breed or Integrated?

When you’re looking for new software, one of the first things you must decide is whether to look for two or more systems that are best in their particular fields, or one software system that does nearly everything you need.

This choice is between ‘best of breed’ systems:

or ‘integrated’:

The problem with the best-of-breed choice is that you have to do the integration yourself, or commission it. This means developing software to map the data in one system to the data in the other, scheduling the execution of the integration software, ensuring that reference data such as account codes and department codes are synchronised in both systems, and that both systems can be reconciled. It gets even more complicated if there are more than two systems in the mix.

The problem with the integrated choice is that you rarely get everything you want from one system, or, not affordably. And it means that if you only want new software for one particular purpose (e.g. professional services management) then you have to throw away everything else that you have and start again.

It’s not easy to choose.

But if you decide to go the best-or-breed way then Infor’s ION integration framework solves the integration problems by providing technical, logical and procedural management of all aspects of integration.

See this YouTube video to see how we’ve integrated time@work (for Professional Services Management) and Infor SunSystems (for back-office accounting):

http://youtu.be/nS78-f8yU-g

Adam Bager

Occasional thoughts on IT, Business and Other Matters

Tag Archives: sunsystems