Why Consultants Love SunSystems

Share

There was a time, many years ago, when the future of SunSystems was uncertain, though everything looked wonderfully rosy at the time. Systems Union, the British company who developed the product, was still in friendly private hands, and sales were booming. SunSystems was the best (as it still is) international financial software system on the planet. Those of us whose lives depended on the product were prospering. Actually, Systems Union’s  P&L looked good. The problem, the company’s balance sheet, was probably one of inattention. The sails were billowing, the sun was shining. They just didn’t notice the rocks beneath the surface.

Resellers such as our company (LLP Group) enjoyed unusually comfortable payment terms and Systems Union’s dunning style was gentle and ineffective. It was a cosy, successful, touchy-feely company and we were all one happy family. They even took all of their employees on expensive foreign holidays, and, on one occasion, some of us resellers too.

They had also embarked on huge enhancements to SunSystems, both functional and technical. GUIs were new and improving rapidly (yes, we’re talking about many, many, years ago) and COBOL, which they were using them, was an impediment to some of this. All these development projects were late and ever more expensive programmers were being thrown into the development den.

And then there came huge devaluations in Asian currencies and debtor and cash values at Systems Union’s successful Hong Kong offshoot had to be revalued down. All in all, the balance sheet didn’t look good, however bright the operating profit.

So, many resellers looked for lifelines, just in case. We looked at SAP R3. As it turned out, this was an expensive and very instructive mistake.

barbie and ken

It would be wrong to suggest that I had thought of SunSystems as a toy. Its simple and elegant building blocks come in a relatively small kit, but, just as with Lego, you can build nearly everything with them. But I had certainly thought of SAP R3 as a ‘grown up’ product, and just as when we’re young we dream (foolishly) of getting ‘grown-up’ versions of toy cars, toy guns and Barbie dolls (or Ken), so I had assumed that our consultants would enjoy the upgrade to SAP R3, a chance to become adult in the ERP consulting world.

SAP was then trying (it still is, perhaps) to come down in the world by selling to mid-sized companies rather than only to the largest ones, so they leapt at the opportunity to work with a company such as ours who knew how do deliver projects in under hundreds and thousands of days.

So we sent out best SunSystems consultants on SAP R3 courses. This one would learn about the inventory control module, this one about the sales module, that one about the asset register, and so on. And therein lay the problem and the reason why our consultants, unexpectedly, hated the whole experience.

Their worlds shrank, and their horizons shortened.

The wonderful thing about working with SunSystems is that you can know the whole product, understand the whole of the company you’re working for, and design a complete solution. You can see from one end of an organisation to the other, from sales discount policy to the resulting debits and credits, and the management reports that international managers need. This wasn’t the case with SAP R3. You just couldn’t know everything.

And the style of the product turned out to be different too. It may be an imprecise analogy, but if SunSystems is like Lego, a small number of small components from which you can build just about anything, SAP R3 is more like a vast array of very large fixed-purpose machines that you have to put together, joining up all the wires and cogs and panels, unsure if they really fit together. The consultant who knows this machine, doesn’t know the others.

Those of us who work with SunSystems love its simplicity and the infinite possibilities that follow from it. Consultants can use their imagination to configure what the customer needs, albeit sometimes with workarounds (equally necessary in SAP R3 I believe). There’s no coding to do, unlike with SAP R3, and in any case coding isn’t possible.

Customers love it too. In some cases they’ve even ‘downgraded’ from SAP to SunSystems. In other cases, when they’ve grown and ‘grown up’ into SAP R3 they express nostalgia for the flexibility and relatively low cost of ownership of SunSystems.

SunSystems is an ideal consulting product. If you’re proficient in it it’s like a musical instrument on which you can play any tune. I’m happy to say that all of those SAP R3 consultants we thrust into adulthood are back in the SunSystems world, and all the happier for it.

See LLP International.

And when I came to design our own products – time@work for professional services management, and expense@work for expense management – I took inspiration from SunSystems and not SAP. I designed it as a set of building blocks, like Lego.

Designing systems@work – with a little inspiration from SunSystems

Share

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.

s@w small

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.