Designing systems@work – with a little inspiration from SunSystems

I’ve spent the last few years designing systems@work’s time@work (for professional services management), expense@work (for expense management) and forms@work (for forms and workflow management), three highly configurable software packages all inspired by SunSystems financial and business software.

SunSystems was developed by colleagues of mine who formed Systems Union in the 1980s. It’s still the mainstay of LLP Group, a SunSystems reseller and consulting group which I founded in Prague in 1992.

SunSystems’ excellence lies in a few remarkably simple concepts:

A single ‘unified ledger‘ handling accounts payable (AP), accounts receivable (AR), general ledger (GL) and fixed asset ledger transactions. Accounts of types Creditor, Debtor, Client (both Debtor and Creditor), Profit & Loss, Balance Sheet, and Memo accounts all co-exist in a single chart of accounts. The unified ledger idea actually spawned at least two well-known accounting software systems – CODA, and SunSystems, both British.
The use of transaction analysis codes instead of structured general ledger codes for the purposes of management accounting and statutory reporting (VAT reporting, for example). An analysis code need be set up only once, and then selected and posted during journal entry to any account that is defined as requiring it. The chart of accounts thereby remains simple.
The option to set up additional analysis on other entities (such as Account Codes and Asset Codes) for reporting purposes (this makes the translation of reports from corporate to local account codes easy, or vice versa)
The use of parallel ledgers for budgeting or alternative treatments (e.g. alternative asset depreciations). Each user-definable budget ledger has the same structure as the ‘Actuals’ ledger.
The option to enter ‘other amount’ and ‘currency code’ values on any transaction in any ledger (in the latest version of SunSystems you may enter five amount fiels and four currency codes)
The use of additional ledger fields for asset codes, etc.

The result is an extremely simple, easy to understand, ‘flat’ structure (reflected in a non-normalised database) that is nevertheless extremely powerful and flexible. In terms of database tables, the essentials include:

A Chart of Accounts table
Ledger tables (an ‘Actuals’ ledger and a number of parallel ‘Budget’ ledgers)
Optionally, a Fixed Assets table

Everything else is merely supportive.

The advantages are many:

No issues reconciling AP, AR and GL
Reporting tools that can range easily across transactions on any type of account and in any set of ledgers
It’s easy to set up new analytical dimensions at any time
It’s easy to handle multiple currencies (typically local currency values that must balance, transaction currency values (e.g. foreign expenses), and reporting currency values (enabling consolidation of several ledgers in a single corporate currency)

The product was also designed with language translation in mind – all textual terms being held in files external to the program files.

It’s not surprising that SunSystems remains an excellent choice for corporations planning to use a single system across the globe. It can be rapidly implemented in a standard way, meeting corporate and local requirements simultaneously.

I spent many years implementing SunSystems in many parts of the world and came to appreciate the powerful simplicity of its design. In designing time@work I adopted many of these ideas and in some cases took them one, necessary, step further:

A single ‘Actuals’ ledger containing transactions of all kinds, whether originating in timesheets, forms, invoices, or attendance forms
Any number of parallel ledgers of exactly the same structure for planning and other purposes
Analysis values on transactions (the same set of 50 dimensions available for use on timesheets, forms, and invoices across all ledgers)
Analysis on entities (Clients, Projects, Tasks, Employees)
Multiple value fields on each transaction (20 values, and 20 ‘currency’ codes to identify the currency in which each value is expressed)
Reporting tools that can range across multiple ledgers
Data Dictionaries accessible to the end-user where different language texts are held, as well as industry specific textual alternatives (e.g. engagement, or case, instead of project)

Where I extended the design was to enable multi-company functionality in a single database, making it possible for an organisation to define one set of projects and one set of employees for use group-wide. In a professional services organisation this makes it easy for an employee belonging to one company to report time or expenses against a project belonging to another company, and makes it possible for an employee in one company to manage employees and projects in another, and to be involved in workflow regardless of the company to which an employee or project belongs.

Multi-company capability, though, implies at least the following:

The need to handle multiple base currencies (an organisation may be operating in several countries but may still need to see employees and projects as a single pool). Holding the currency code on each of twenty values in every ledger transaction makes this possible.
The need for multiple charts of accounts. When transactions must be sent from systems@work software to one or more finance systems the appropriate transactions for each company must be easily identifiable and must be constructed using the appropriate account codes for the destination ledger
The need for separate invoice sequences
The need for separate sets of expense types, each appropriately implying a general ledger code

Achieving all of this, whilst retaining simplicity on the surface has been our aim. The result is a set of simple components that can be assembled in millions of different ways to meet the needs of a wide range of organisations, without software modification.

systems@work works with any finance system, but it’s conceptual similarities with SunSystems makes it an ideal extension for timesheets, expenses, planning and billing. Contact me for more information.

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.

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?

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.

On Systems Integration – What’s the problem?

Integrating business systems can be a nightmare, and we who talk confidently of ‘seamless integration’ during sales presentations know this well. The fact is that it’s often a difficult and complex task, and advances in technology have done little to make the task easier. Rather, as systems have become more complex, reaching us wherever we are on devices of many different kinds, integration has become more complex too.

XML, web services, BizTalk, middleware, all these ease the passage of bits and bytes from one system to another, but none solves the underlying problem, which is only partly a technical one.

The issue is particularly acute for those of us who sell ‘best-of-breed’ solutions rather than ‘fully integrated’ solutions. A ‘fully integrated’ solution is one where all the functions you need for your business, from accounting, to manufacturing, to distribution, to HR, can be found in a single large piece of commercial software. Whatever integrations are necessary are already there in the software code itself, and in the database that the entire body of code shares.

A ‘best-of-breed’ solution, by contrast, has its own database and software processes and when integration is required, a separate process must obtain data from one database and pass it to another system.

Why is this difficult?

Part of the problem lies the fact that systems often speak very different languages. I don’t mean that they use different programming languages. They may do that too, but that’s not the point. They speak different languages because they don’t always share a common ‘understanding’ of the ‘events’ which drive them and they don’t usually represent ‘events’ or ‘transactions’ in the same way in their respective databases. They may come close, but the devil lies in the detail. What an ‘invoice’ is, or how it is represented in one system, may be different in another. How an ‘item’ is represented may differ, and so on. At the heart of ‘fully integrated’ systems lie common concepts of what things are and how they are to be represented by data.

Another problem lies in the detection of change. When systems don’t share a database items that are more or less common to both must be replicated from one database to another (you must usually define which is the ‘master’ or the ‘slave’ in this respect) and the relationship may not be one-to-one. To keep both systems up to date you must detect changes as they occur in one in order to pick them up and copy them to the other. You must do this as rapidly as possible if you are not to cause inconsistencies in the behaviour of both.

And of course ‘fully-integrated’ systems complete their processes in response to an ‘event’ (such as the arrival and booking of a supplier invoice), all at once. Such processes are usually designed so that they entirely succeed or entirely fail. Integrated best-of-breed systems, on the other hand, must do things in sequence. Sometimes it matters if systems get out of step with one other, and sometimes one or more steps may fail.

So when you’re integrating best-of-breed solutions there’s an additional task you must execute from time to time. You’re constantly reconciling your systems to ensure completeness and consistency. This is, in itself, an overhead, but the cost of dealing with failure to reconcile, and the know-how you must possess in order to handle this, add further to your system management costs.

So why would anyone ever choose to buy best-of-breed software systems and go to the trouble of integrating them?

There are several good reasons:

‘Fully integrated’ systems are hugely complex. They must cater for far more variation in implementation. They have many more ‘switches’ that you must know how to control.
Their complexity makes them more expensive to buy and to implement.
They cause more disturbance to the status quo during implementation because you must throw away everything you already have and start all over again.
They’re often not as powerful or clever in some particular areas, despite their complexity, so you’ll sometimes need to choose a best-of-breed solution because it fits your particular needs better. These particular needs may be what makes your company special.

Sometimes, indeed often, the implementation of best-of-breed solutions will be the right choice.

But, what’s the best way of minimising the risks?

Let’s look at that in the next post.

Mutual Frustration – Why do IT systems users wait so long for features that already exist?

I attended a conference recently where, by chance, I met someone who’s using the expense management system that I design – expense@work. It’s always a little alarming when you meet a real user since you must expect them to be honest, and there are no better judges of what you’ve done. This one was direct:

‘I hate it,’ he said, with the kind of mock fury that told me that he knew he was exaggerating and didn’t really want me to go away and kill myself.

‘Why?’ I asked.

‘Well, it’s so out of date. I can’t attach images to my expense claims, and I can’t use it on a mobile device,’ and so on.

‘But you can,’ I said. ‘We’ve had those features for years.’

‘Then why haven’t we got them?’

‘I don’t know.’

It’s so frustrating, but this happens time and time again. And not only with our own software. We also sell and implement a financial system, SunSystems, and again, we often have to deal with users who want features that we have, but who aren’t getting them.

This is actually a widespread problem in system implementation and the end result seems to be unnecessary reputational damage for the software author.

Why does it happen and how can it be avoided?

It happens because system implementation is a lengthy, expensive and risky business and end users don’t often determine what’s on the list of features that they’re going to get. Sponsors and project managers on the client’s side have a highly controlled, and usually narrow, list of objectives, and their criteria of success won’t usually include the implementation of features that are merely ‘nice to have’ but not necessary.

That’s why ‘nice features’ don’t make the list during an initial implementation, but it doesn’t explain why nice new features don’t get implemented later as soon as they become available.

The problem is that once a system is implemented, the policy becomes ‘if it ain’t broke, don’t fix it’, so new versions with ever more up-to-date features, don’t get implemented either. And this is eminently sensible, because upgrades take time, often go wrong (for a while at least), and cost money. Upgrade projects are sometimes almost as large, expensive and risky as initial implementation projects, even if the software automates many aspects of the upgrade (such as updates to the database).

Software authors want their software to be liked by their end users. End users want ‘nice’ features. The obstacle lies between the two, in the conservatism of the client’s project managers and IT department.

Sadly, I can’t see what’s wrong with this. ‘Conservatism’ is a very sensible policy with business systems. The tragedy is that result is frustration on one side and unhappiness on the other. is there anything we can do about it?

I ask this question without knowing the answer. I wish I could find a way to deliver new features in software without risk or disturbance. But this is difficult. Business software isn’t like a desktop productivity tool. The problem is that what you do in one corner of the system can have unintended consequences in another corner. And when a system is implemented for a client it’s often integrated with lots of other systems, so a change in one corner of our part of the whole, can disturb a corner in another part that isn’t within our control, as authors of just one part, at all.

To some extent this problem is solved in ‘cloud’ or ‘hosted’ solutions, because authors then control the version that an end-user uses, and can introduce and publicise new features without obstruction from intervening project managers.

But ‘cloud’ and ‘hosted’ solutions aren’t always suitable when it comes to complex business software, especially when the software must be integrated with a client’s own systems. When there is deep integration, conservatism rules, and must do so.

And yet, it’s so frustrating to meet end-users and to have to repeat time and time again,’But our software CAN DO THAT!’

Any ideas?

“It is not enough to succeed, others must fail”

This splendidly waspish remark is attributed to the writer, Gore Vidal. He was, himself, immensely successful, though acclaimed more for his ‘unserious’ writing than for his political novels, which I find, frankly, quite indigestible. It was these thoughtful and interminable novels about politics that he wished to be remembered for (rather in the way Leonard Bernstein longed to be remembered for his vast symphonies instead of West Side Story, when most of us would have been glad merely to have written one good tune from the show).

Gore Vidal wrote screenplays too, mystery novels under the pseudonym Edgar Box, made a lot of money, and mixed in the Princess Margaret set. But, struggling, despite his success, with some crippling insecurities (I suppose) he suffered fools very gladly indeed, in that it gave him immense pleasure to be both socially and intellectually superior to almost everyone he met. In most cases he was certainly the latter, but I can’t help thinking that those who are conscious of the former have already failed miserably in some way.

Envy is also a sentiment of the young. When we are striving for success or recognition, other people’s talents and successes are an affront. We must grin or grimace determinedly when we hear news of some friend’s astonishing triumph, triumph of a kind that has, as yet, eluded us. But as we age, we begin to take genuine pleasure in others’ success. Success and failure are not the necessary and balancing outcomes of a zero-sum game.

On the way to Bucharest airport yesterday, my colleague, Ioana, and I popped in to see our former colleagues, those working for the company that LLP Group sold 19 months ago. It was LLP Dynamics then, and is Xapt Romania now. Not so successful then, but conspicuously, confidently successful now. Microsoft’s Dynamics suite of software was never my cup of tea, and certainly, under my direction (and others) the company hadn’t thrived. I knew I couldn’t solve the underlying problems, and by the middle of 2013 it was wearing me down, so selling it brought me some guilty relief (and some cash, too, of course, though nowhere near the amount we’d lost). Guilty, perhaps because I felt I might be putting my own interest before my colleagues’. I was the captain, and I was abandoning the ship.

But it wasn’t like that. The sum of human happiness has been greatly increased by the sale – my happiness I was sure of, but theirs too, as I could see yesterday. Now Xapt Romania is doing very well indeed. It’s the largest and best Dynamics AX reseller and consultancy in Romania. It’s profitable, it’s growing (now it employs nearly 50 staff), and it feels happy to me. Hats off to Mihai Madussi and his team.

It’s actually ok to fail, even if others succeed!

And, let’s face it, we haven’t failed everywhere. What’s left of LLP Group, (LLP Group, LLP CRM and systems@work) is still very much more my cup of tea, and it’s doing very well indeed.

We’ve released a new App – systems@work – to the App Store

We’ve released Version 1.3 of our iPhone App to the App Store and it’s now available for download.

After some reflection, we decided to release the App as systems@work, rather than as expense@work, forms@work or time@work. This reflects the fact that the App works with forms created in any of these three products, adapting itself, when first used, to the form types and rules set up in your database.

The expense@work App will therefore shortly be withdrawn from the App Store.

Version 1.3 contains new features:

revised data communication with the server for faster and more reliable transfer
optional automatic upload of data

We are now adapting the App for the Android environment.

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: systems@work