Marketing – I Must, I Must, I Must

I attended a roundtable discussion yesterday evening organised by the Prague-based International Business Forum (IBF) on the subject of marketing, and especially marketing on a low budget. Low marketing budgets, unfortunately, abound when it comes to the members of the IBF, since most of us are small business owners.

The roundtable was led by the excellent Jo Weaver of JWA. Her theme was that marketing is as essential for most companies as desks, chairs, PCs, and telephones. (Actually, in my view, desks and chairs aren’t essential.) Marketing can be a website, a business card, a dinner with clients or prospects, a newsletter, a battery of telesales agents, a seminar, an advertisement, a Facebook Page, an article on LinkedIn, a well-crafted press release, a commissioned PR article, or a blog (such as this). She pointed out that the large multinational fast moving consumer goods companies (such as Coca Cola, Procter and Gamble, and Unilever) spend up to 20% of their revenue on marketing. And when times get tough they spend more, not less.

lamppost

Most of us in the room, as Jo pointed out, run or own small businesses, and small companies, unless they’re directed from abroad by larger headquarters offices, are reluctant to spend money on marketing. We’re also inclined to think we can do it ourselves without professional help, and we approach the task without forethought, without consistency, and expect immediate results.

All of this is true. Every company must spend time and money on marketing. Not, in most of our cases, since we’re not selling consumer goods, 20% of our revenue, but probably more than we’re in the habit of spending. Many of us trust to ‘word of mouth’, but that is marketing, too, and we should work hard to make sure that the ‘words of mouth’ that get bandied about are the right ones.

Most of us in the room were also at the helm of companies selling to niche markets, and the larger amongst us have tried marketing of many kinds. My company, LLP Group, resells and develops business software, and provides consulting services to international organisations in Europe and North America. How to reach our market? And where? In the countries in which we have our offices, or in the capitals where our potential clients’ headquarters are based?

And how? Website, obviously (we have four, aimed at different segments of the market), Facebook pages, LinkedIn groups, blogs, Google AdWords campaigns occasionally, sometimes telesales, and so on. Even over many months or years, these have achieved marginal results (or, looking at it another way, they have kept us in business). We might spend more money if we knew how or where it would be effective. Or should we realise that our markets are small and that we are reaching them as effectively as we can? One of yesterday’s participants stressed the need for measurement. He made some good points, but how do you measure the effectiveness with which you are reaching potential customers if your market is a niche market? It’s not obvious.

But there are many easy mistakes to make in marketing, and I always find myself telling a story about our early days in Romania, when our amiable but ultimately crazy managing director (so possessive was he of our subsidiary in Bucharest that eventually he stopped doing what he was told and we had to fire him) complained incessantly that we weren’t allowing him to spend enough on marketing SunSystems.

‘Look,’ he said, as we travelled through the city in his vast and vulgar limousine, ‘our competitor, Scala, has advertisements on every lamppost. Every taxi driver knows about Scala.’

‘And how many taxi drivers are looking for international financial software?’ I asked.

It’s easy to spend too little on marketing. We should all spend more, and we must accept that we will never be entirely sure as to how much of our money is wasted and how much is effective. But one thing is certain – market towards your customers – and if your customers aren’t taxi drivers, don’t waste money on telling them a single thing about your products.

The Illusion of Remote Control

Many years ago I undertook a short consulting assignment in Kazakhstan on behalf of a small oil company based in London. There’s almost nowhere I wouldn’t visit at least once (except, perhaps, Baghdad) and I looked forward with great excitement to the trip. The oil company’s administrative offices were based in Aktobe, a town northeast of the Caspian Sea on the imperial-era Trans-Aral railway line. The oil field itself, I understand, was a few hundred miles southwest across the steppes towards the Caspian.

It wasn’t easy to get there. I flew from Prague through Moscow, and returned through Astana, Almaty and Istanbul.

aktobe map

I was invited to visit Aktobe to find out how the company was using SunSystems. Infor’s SunSystems is a British financial accounting system that, better than almost any other system of its type in the world, enables both local statutory accounting and corporate financial reporting to international standards. When it comes to remote financial control of an organisation, and Aktobe is nearly as remote as you can get and still find a four-star hotel, there is no better solution.

The company had just bought an oil field in the north of Russia and was considering implementing SunSystems near Archangel. They’d heard about us through our Moscow office and the British financial director seemed to place some trust in our company (LLP Group), or at least in me, probably because I am British too. How better to start with SunSystems in Russia than to look at how the company was (successfully) using the system in Kazakhstan?

Aktobe was built in imperial times, but bears all the hallmarks of a mid-sized brutal Soviet city – a simple grid of crumbling concrete apartment blocks, and wide wind-swept boulevards decorated with crude socialist realist monuments. In fact the city is less Russian now than for a hundred years, many of the Russians having left after Kazakh independence. A vast new mosque reflects the revival of local religion and culture, but in all other respects the city might have been anywhere in the former Soviet Union.

aktobe mosque

aktobe2

aktobe3

What persists, however, as in many former Soviet Republics (Moldova is another example) is Russian-style correspondence accounting (see Correspondence Accounting – The Russian Way of Debits and Credits) and most organisations in Kazakhstan use 1C, a Russian accounting software system that does Russian accounting excellently.

SunSystems has many advantages over 1C. It is more easily audited, it allows more analysis, and, crucially for international organisations, it enables statutory and corporate accounting in one system, with the relationship between the two definable and auditable. That’s why many international organisations use it in Russia and the former Soviet Union.

It was no surprise to me, though, to find, when I got to Aktobe, that my client’s accounting team were using 1C. Many companies keep two sets of books, one in 1C and one in a ‘Western’ system such as SunSystems. Sometimes they build a bridge between the two to ensure that the systems reconcile and to avoid wasting time in entering transactions twice. There’s often a debate about which system should be the ‘primary’ system, but I won’t bore you with that debate here.

The problem is that most local accountants find ‘Western’ systems uncomfortable and effortful. Whilst it’s perfectly possible to use only SunSystems in Russia (see SunSystems in Russia – Perfectly Possible for the Determined Amongst Us ), it’s less easy to derive statutory reports from SunSystems than from 1C, and all local accountants owe their primary loyalty to the state. This is entirely understandable. They are personally and criminally liable for their mistakes.

It’s not often, however, that hostility towards a ‘Western’ system is overt. The great surprise in Aktobe was that my client’s accounting team weren’t using SunSystems at all. They hated it, and told me so. They were sending their monthly financial reports to London, ostensibly derived from SunSystems, but in fact derived from 1C with a few adjustments here and there. I looked at the SunSystems ledgers and the latest journals were posted months and months earlier.

Remote control isn’t easy. As LLP Group has grown over the last twenty years I’ve seen how hard it is to maintain standards, whether they are ethical standards, HR standards, accounting standards or consulting standards. There’s no substitute for frequent visits, frequent training, frequent fraternising and frequent forensic investigations into what’s going on. Saying that something ‘must be so’ from a distance without ensuring it’s actually so, is a waste of time. It’s very hard to maintain remote control of a very faraway place, and it’s easy, in a faraway place, to deceive someone at headquarters whom you hardly know.

The client was excited by my findings and was ever more determined that they should abandon 1C in Aktobe, and that they should use SunSystems for their new oil field in northern Russia. They were properly alarmed by the fact that their financial statements, the basis for their stock-market valuation in London, were produced without much accountability, in Excel.

But then, just a few weeks later, another company bought them, and all projects were off. I doubt that the team in Aktobe ever posted another SunSystems journal.

I don’t believe in the Cloud

There, I’ve said it. I know it’s a heretical view, but I’m no follower of fashion, whether sartorial, gastronomic, linguistic or professional.

the cloud

But it’s not a simple issue, and I will qualify my views very carefully.

I’m talking of course, of the IT Cloud, that somewhere-nowhere place where software and data are held for private or corporate use. I don’t doubt that it’s a safe, secure and cost-effective place, (and if it’s not yet those things, it could be). And I don’t doubt that when it comes to certain kinds of ‘utility’ applications – word processors, spreadsheets, simple databases, and so on – it makes it easier for people to share data and ideas. There are plenty of benefits when it comes to certain, limited, kinds of Cloud. My objections are confined to the Cloud as it’s promoted for business applications, a field I’ve worked in for more than 35 years.

Business applications are at the core of all medium-sized and large organisations all over the world. Without them things don’t get made, sales don’t happen, deliveries fail, customers become unhappy, profits don’t get calculated, and vital things don’t get bought or just don’t arrive in time. I’m not sure if they save on paper, but they save on labour, doing those repetitive, communicative and administrative things more accurately, consistently and rapidly than humans can ever do them. They reach out across the internet to enable us to order pizza from our living rooms, or buy tickets for flights from one continent to another. They touch are lives hundreds of times a day.

They are immensely complex. The largest of them, such as SAP or Oracle, contain millions of lines of computer code, and trillions of possibilities, and they’re developed by thousands of programmers over millions of man-days. The largest (and most expensive) of them also do absolutely everything that a company needs its business systems to do- from procurement and purchasing, engineering simulation, to distribution route-planning, payroll and career-planning.

The best of them are configurable and don’t need source-code modification to make them work well for a particular customer. Take Infor’s SunSystems, for example, a beautifully designed accounting system that is easily adapted for all sorts of purposes, or systems@work’s time@work, a professional services and expense management package that works for a wide variety of professional services organisations, from consulting and engineering, to law or oil and gas exploration. Neither system comes with source code, so ‘one size fits all’ and each organisation’s quirks are managed through configuration of the software’s parameters. My company – LLP Group – has worked enthusiastically with both of these products for more than twenty years. We love them, but except when life is very simple, I don’t seem them perching entirely comfortably on the Cloud.

The reality is that there is no core business system in the world that does all the mission-critical things that a company needs only through configuration (those vital things that enable it to be competitive). And there’s no core business software system in the world that does everything. There’s usually a need for the integration of several business systems – time@work with SunSystems and Microsoft CRM, for example – to cover 95% of a company’s needs. Some of these systems, particularly those that bring a particular competitive advantage, may even have been written specifically for one company.

Integration is difficult to do in the Cloud. I take the Cloud, in this context, to be a place where a single instance of a business software system is installed and used by multiple organisations of different kinds – one software version, but configured differently for each organisation. That’s ‘cloud cuckoo’ Cloud in my experience, certainly if we’re considering those essential systems at the heart of a competitive business.

The Cloud is best when it offers either a peripheral function that isn’t mission-critical and is more or less standard across a wide variety of sectors (expense management, for example) , or a function that is essential but can be configured sufficiently to suit most organisations (CRM systems such as Salesforce, for example). But it’s no good for those idiosyncratic areas that make one company stand out from another or when an ambitious fashion-following IT or Operations Director says, ‘I want everything in the Cloud.’

I’ve seen Cloud implementations fail at the first hurdle, especially when it comes to the almost always necessary integration of multiple systems. Integration code is rarely usable by more than one organisation, and as soon as you need something special up there in the Cloud alongside the ‘one size fits all’ copies of your core business software, you’ve descended from the purest Cloud to something that’s merely ‘hosting’, because no one else can use the particular combination of software and integration code that’s been installed and developed for you.

And, even if you’re in the purest Cloud, you’re still vulnerable to what can seem like the arbitrary upgrade of the core software, which is entirely out of your control. Sadly, business software contains bugs, and most companies want to test very carefully before accepting a new version. In the purest Cloud you don’t have that option.

So, no, I don’t believe in the Cloud. I love the idea that you don’t need your own IT department, that to others can be delegated the responsibility of procuring IT infrastructure, and of ensuring safety, security and performance. That’s hosting or the ‘private Cloud’. But when it comes to the mission-critical functions and very specific integrations on which your organisation depends – forget the Cloud in its most idealistic form.

Why Consultants Love SunSystems

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.

Clouds – Nimbus, 9, or Cuckoo?

I am distrustful of bandwagons, and rarely board them as they rattle noisily by. It’s not that I’m against enthusiasm, or novelty, it’s just that bandwagons are often driven with irrational exuberance, and very often they crash. I prefer the slower vehicles that come along behind. They set out in the same direction, but with more care and circumspection, and they reach their destination more reliably.

bandwagon

I remember the bandwagon of the Dotcom boom – and the bust that followed it. Whilst there’s no doubt that the internet changed our lives, I’d rather call it accelerated evolution than revolution. Its victims were more often its most ardent supporters, hell bent on delightful ideas that lacked even a modicum of commercial good sense or realism, than the ancien regime.

The advent of the internet was evolution. It simply extended what we already had, and what we already did as business IT consultants. It didn’t, despite the fears of some, invalidate what we already knew. Business systems nestle as comfortably in the internet as they previously did in their more confined circumstances. The basic problems of system integration, of manufacturing, retail, services, accounting, distribution, CRM, and the rest, are of the same type as before, as complex as ever and we, who understand them, are as valuable as ever.

During the feverish years of the dotcom boom one of my colleagues told me that if we weren’t immediately reborn as ‘Dot LLP’ (instead of LLP Group) we’d be annihilated within six months. I laughed. We didn’t, and we’re still going strong. We learned some of the new dotcom tricks, and we go on learning.

thecloud

The Cloud, I fear, is currently another bandwagon. We won’t be boarding it with too much haste, even if its direction is the right one. We’ll be waiting for the slower train that won’t go off the rails.

The Cloud is an excellent idea. It comes in many forms. As those who tout it say, it allows businesses, even software authors such as we are (systems@work) to concentrate on what we do best. The business of managing IT infrastructure, handling communications, backups, performance, security, and so on, isn’t the business that most of us are in. It’s not our field of battle, so better to leave it to the experts. No need to employ specialists if others can do the job at a competitive price and relieve us of unproductive anxiety. We must concentrate on our core business activities.

All of that is true, and if we could all dump our systems onto rented hardware at reasonable cost, why not? Sometimes it’s possible and the right thing to do.

But that’s not exactly what the Cloud is meant to be. Certainly not all it’s meant to be. It’s not just a matter of hosting the particular collection of business software that we’ve amassed and integrated, it’s also about using a standard piece of software in a ‘multi-tenanted’ environment – one size, one copy suits all. And if we use this piece of software for accounting, this piece of software for distribution, and that piece of software for manufacturing, it may be about using multiple standard pieces of software in a number of different Clouds. It’s about business software becoming a commodity that can be accesses as easily as water through a tap.

Many business worry about the security of their data. But these issues of security are solvable, even if many companies are reluctant to let the ‘professionals’ look after their data. The fact is that data are vulnerable wherever they’re located, whether in-house or hosted, and the issues of security can be solved or not as easily in one environment as the other.

It is the issue of ‘standard software’ and ‘integration’ that don’t yet fit perfectly well within the Cloud. Sometimes, if the purpose of a piece of software is such that it can stand alone and if it’s used without alteration (even if configured for a particular company’s purposes) the Cloud can be a good place to put it, but if standard software has been modified, or extended, or is integrated in complex ways with other pieces of software, and other databases, then making this work with a Cloud-based solution will be difficult, and with a ‘pure’ multi-tenant Cloud based solution (one copy of the software serving everyone) it will be well-nigh impossible. Ensuring the consistency and coherence of systems and databases that are in multiple environments that you do not fully control will be difficult.

As time goes by, new techniques for integration may make this task easier, but we we’re not yet at that destination.

So, I am cautious about Cloud-based offerings in the world of business IT. They may work for some, but for many they aren’t yet the right solution. What seems initially like a good idea founders when a business needs something special from a standard software offering, or some special way of interfacing systems, and many businesses find themselves trapped by the choice they’ve made if it’s located in the Cloud. They’ve exchanged one limitation – the anxiety of running their own infrastructure – for another – the anxiety that comes from being limited by someone else’s standard software and infrastructure.

Whilst the provision and management of infrastructure isn’t usually the basis of a company’s competitive edge, the business software on it, often is.

As a software author (systems@work) we’re cautious. We offer configured systems in a hosted environment, and this suits customers who don’t need any software modifications and who don’t need interfaces between Cloud-based and non-Cloud systems, or who need only simple ones. And we offer on-premise installation and full-blown integrations when they’re needed.

But for now, the Cloud isn’t always the answer and we won’t be betting the business on it.

SunSystems and Manufacturing – A Transylvanian Tale

Imagine Transylvania in 1997, a part of Romania still largely populated by vampires and werewolves. It’s a place that’s bitterly cold in winter, scorching hot in summer, and most terrible of all, it was then a dark corner of the world where accounting was done largely on paper by huge armies of accountants, and a place where manufacturing planning systems were entirely unknown.

Welcome to my accounting department….

draculacastle

Imagine, also, that South African Breweries (SAB), a newly acquisitive international brewer, had acquired Ursus, in Cluj Napoca, one of Romania’s best-known breweries.

ursus

Acquisitions at any time, and in any place, are a cultural nightmare, but international acquisitions are the most difficult, especially in emerging markets. The nominal cost might be attractive, but the challenge can be almost unmanageable.

The first step in any acquisition is to establish reliable financial systems, but the brewery’s army of accountants couldn’t tell SAB what they really wanted to know about Ursus, at least not in a timely, GAAP-compliant way.

What they really needed was a flexible financial system that could meet Romanian statutory requirements and report intelligibly to their South African headquarters. Given that SAB manufactures beer, a large system such as SAP or Oracle might be the obvious choice because they do manufacturing, sales, purchasing and distribution as well as accounting. But there wasn’t a hope in hell, nor in Transylvania, of implementing such complexity. And local financial software systems were fit only for the undead nature of Romanian statutory accounting, not for the sophistications of GAAP reporting.

So we, LLP Group, and our recently formed subsidiary in Bucharest got the job of implementing Infor’s SunSystems and of making it work in a manufacturing environment.

Manufacturing accounting is all about calculating the cost of finished goods. A finished item, such as a labelled bottle of beer, comprises packaging and content. Content, in turn, comprises this and that – water, sugar, yeast and whatever else goes into a bottle of beer. There’s a bill of materials that describes the component parts of every item, and the cost of labour and machinery involved in producing it. Most companies calculate a ‘standard cost’ for each item and component based on estimated costs of components and labour, and in many countries it’s perfectly permissible to value stock on the basis of standard costs, as long as the actual costs vary within reasonable limits.

But not so in Transylvania. The law demands that ‘actual’ costs be calculated, or the next best thing, a rolling average of actual costs. You can do this in SunSystems, using a T-code for each finished or semi-finished product, crediting a production account with all the products that come out of the production process at standard cost, debiting all the materials and labour consumed at standard costs. Purchase price variances, and manufacturing variances emerge, that must then be allocated against materials consumed at the next higher level in the bill of materials, and materials still unused. It’s an intricate calculation, and one that even manufacturing systems didn’t do well in the 1990s, but to do it in SunSystems takes more courage that knocking on the door of Dracula’s castle.

It helps, of course, if the number of finished and semi-finished products is few, and in the end the packaging materials were more complicated than the beer itself. It helps, too, if you know manufacturing systems, and we used Fourth Shift, a small but powerful manufacturing system, solely for the definition of bills of materials and the calculation of standard costs. It doesn’t help, though, if inflation is running rampant and you have to recalculate your standard costs several times a year.

But we made it work, or rather my colleague Jiri Stiller, now manager of all of LLP Group’s operations in Central and Eastern Europe, did it, spending a year in Romania, in Cluj Napoca and Bucharest. He wore garlic next to the skin and never went out after dark, but as far as I can tell, his blood is still human and he’s very much alive.

SAB used SunSystems for many years, but eventually moved to their standard software system – SAP. Romania has changed too, and Cluj Napoca is now a pleasant, modern, easy city, where you needn’t fear vampires nor accountants.

SunSystems is a wonderfully well-designed financial system. Its unified ledger and transaction analysis concept makes it one of the most flexible and versatile in the world. It can do almost anything, even in Transylvania.

NOT Jiri Stiller – at least not during the day.

vampire

SunSystems – To Be or Not To Be

At the recent Inforum conference in Paris (see Conferences) I was delighted to hear rumours on the grapevine that SunSystems is in the ascendant again in Infor’s firmament of software products.

SunSystems is the best mid-market accounting system in the world. Those of us who have been around long enough remember the SunSystems advertisements that borrowed the Carlsberg idea from the 1980s – Probably (crossed out) the best accounting system in the world. We all agreed.

It’s not as large a product or as broad a product, as SAP or Oracle, nor as powerful when it comes to sheer volume, but if you want globally consistent reporting in reasonable time, with low statutory risk wherever you’re operating, there is no better system. Its simple architecture – a single ledger, unlimited parallel ledgers for budgeting and accounting adjustments, its powerful multi currency and reporting currency capability, easy integration and, above all, its transaction analysis capability, are ideal in their flexibility, and the system can be configured easily as a core system for global roll out.

Consider the alternatives:

SAP Business 1 – a broader product and better looking, but not deep enough to squeeze through the statutory and corporate reporting hoops that SunSystems slips through more easily, wherever you are in the world.

Dynamics NAV – a fabulously flexible product (programmable, in reality) and applicable across a wide range of businesses, but its financial modules don’t come anywhere close to SunSystems’.

Dynamics AX – ditto. And AX is even bigger and more difficult to implement consistently.

Great Plains – a nice product for the Anglo Saxon world.

Of course, if you need manufacturing, or complex logistics functions, or retail, or any specialist ‘business’ functionality closely integrated with financial modules then you’ll probably put this first and buy a fully integrated system.

But, if you’re happy with best-of-breed solutions, for example if you’re running a hotel using Micros Opera, or a financial institution with highly-specialised, often bespoke, software for your front-office operations – then SunSystems is the best choice.

‘Cloud’ is all the rage these days, but I see no reason why SunSystems cannot be deployed in the cloud or in private hosting environments.

Infor’s CloudSuite has for the last few years received more marketing oomph from Infor than SunSystems, and there’s no doubt that CloudSuite offers broader functionality. But is it deeper? Can it as easily be designed for deployment anywhere, both in the relatively benign regimes of Anglo Saxon accounting and in the accounting jungles of Italy, Greece, Russia, Brazil and other more challenging accounting regimes, where you need to run the obstacle courses of negative debits and credits, provisional journal postings, correspondence accounting, cash-based VAT reporting, etc. SunSystems overcomes all of these – not always easily, but it can do it when many cannot.

The rumours I heard at Inforum are that Infor is beginning to recognise that SunSystems has some unique strengths, and that CloudSuite Financials isn’t going to be an easy ‘upgrade’ for current SunSystems users.

Long live SunSystems!

SunSystems in Russia – Perfectly Possible for the Determined Amongst Us

SunSystems’ financial modules can adapt themselves to almost any statutory regime, but in some countries implementation is more difficult than in others. Probably none is more difficult than Russia (and all those other countries where Russian accounting standards apply).

What’s so difficult about it?

Isn’t it just a matter of capturing data and reporting it, just like everywhere else?

Yes, but it’s also a matter of defending yourself against the suspicions of statutory auditors.

First of all there’s a statutory chart of accounts. You must decide very carefully whether this will be your primary chart of accounts, with each local account mapped to a corporate account, or whether it’s better to do it the other way round.

Then there’s the issue of ‘correspondence’. Every debit must have a corresponding credit. So when you book a sales invoice you must book it this way:

Debit DEBTOR account, Credit SALES account,

Debit DEBTOR account, Credit VAT account.

The DEBTOR account is the corresponding account both for the SALES account and the VAT account.

‘So what?’ you might ask. That just means a few more debits and credits than you would usually post to your ledger. The overall balances will still be the same.

True. However, the problem, such as it is, lies in the reports you must show when you’re defending the correctness of your ledgers to a statutory auditor. An auditor may ask for a cross reference or tabular report that shows all the correspondences between accounts – debited accounts on one axis, credited accounts on the other. And woe betide you if there are some debits or credits between accounts that are NOT ALLOWED to correspond.

SunSystems cannot, itself, produce this kind of report, even if you’ve taken the trouble to record the corresponding account for each debit or credit in a transaction analysis field. There are some commercially-available add-on programs that can determine correspondence and produce the cross-reference report by following the relationships established within each journal, as long as debits and credits individually balance, but it’s not straightforward.

Then there are the negative debits and credits.

And there’s the obligation to submit your statutory reports using XML.

SunSystems wasn’t initially designed with Russian accounting in mind, though SunSystems’ Extended Analysis concept certainly helps with statutory reporting. The issue is a profound one. SunSystems is a ‘Western’ accounting system, like all the others that you may be familiar with, such as SAP and Oracle. All ‘Western’ systems struggle to manage Russian accounting rules and conventions with ease. At best they mimic the home-grown systems that were created specifically to meet Russian standards. Foremost amongst these is 1C, which almost every company in Russia and in the countries of the former Soviet Union (Kazakhstan, Moldova, etc.) uses. It’s regularly updated as statutory reporting changes, and it works more or less straight out of the box. The XML reporting formats defined by the state are exactly those that 1C produces.

And yet, 1C doesn’t easily serve corporate reporting and management accounting needs, and often doesn’t even meet ‘Western’ corporate auditing standards in terms of controls on journal modification, period closure and so on.

So, when implementing SunSystems in Russia, you have a number of choices:

Implement ONLY SunSystems.

Your local accounting staff won’t like this. It’s harder work for them to construct the reports that 1C would do at the press of a button.
You’d be well advised to enter the corresponding account on every debit and credit using a T-code. Easy to make mistakes.
You’ve got to use some specially written software to create a cross reference report if someone asks for it.

Implement BOTH SunSystems and 1C.

You’ve either got to enter every transaction twice, or
You’ve got to build an interface from one system to the other to transfer the transactions

In the end it depends on your determination and on the flexibility of your local accountants. My experience is varied:

I’ve worked on a SunSystems implementation for a large US consumer goods distributor where only SunSystems was used, and without the posting of ‘corresponding’ account into a transaction analysis field. A locally provided program was used for the construction of cross-reference reports and other statutory reports, as required.
I’ve seen a SunSystems implementation at a hotel where only SunSystems was used, and a transaction analysis field was used for the posting of corresponding account.
I’ve seen a SunSystems implementation where all transactions were additionally and separately recorded in 1C.
I’ve seen a SunSystems implementation where all transactions were initially entered into 1C and then exported into SunSystems for adjustment.

None of these scenarios is straightforward, but all can work. LLP Group has been supporting SunSystems in Russia through its Moscow office for nearly twenty years. If anyone can help, we can. See more on our approach to global SunSystems implementations on LLP International.

One last but important point: don’t for a moment think that you can ignore Russian reporting requirements and just accept whatever sanctions might follow. That would be a very foolish choice (see High Inflation)!

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.

SunSystems Implementations – Short is Beautiful

I’ve implemented SunSystems dozens of time. In Europe, in North America, in South America and in the Middle East. Not yet in Far East Asia, or Africa, but there’s still time if I hurry.

LLP Group is based in Central Europe and so most of my implementations have been in the post-Communist states of the former Soviet bloc. These were not then, and are not now, the easiest places in the world, but they are by no means amongst the worst (except perhaps Russia).

SunSystems has a simple beauty and once you’ve appreciated the power and simplicity of the single ledger concept (Accounts Payable, Accounts Receivable and General Ledger all in one) and the way in which general ledger analysis is achieved through transaction analysis codes rather than through complex, structured account codes, implementation should be simple.

The fun for us consultants lies in working out how a company wants to analyse its business performance, and to a lesser extent how it must calculate and report its tax liabilities, but once the analytical fun is over it’s usually a simple matter of system configuration, report configuration, data transfer and training. No programming. This is true, of course, of the implementation of the financial modules, not of the business process modules. These are more complex and involve more staff, making an implementation more disruptive.

But management accounting, the fun you can have with analysis, was alien to the emerging economies of Central and Eastern Europe when we began LLP Group in 1992 and for no particularly good reason implementations in our region took longer than they should. Good for us, of course, since we were charging fees, but also sometimes frustrating. I remember starting a system design workshop at a cooking oil plant in Bratislava in Slovakia with the question,

‘So, what do you want the system to do for you?’

A long silence. I think they were simply waiting to be told what the system does, and weren’t expecting to make any choices.

‘VAT reporting,’ was the first and only eventual answer.

So, when one of our earliest Prague-based clients, a British insurance company, unexpectedly asked us to implement SunSystems at their office in Brighton in the UK (coals to Newcastle, you might think), I expected things to be a lot more simple. Even so, I felt uneasy when the financial director suggested that just one day in his office might suffice.

‘I think it might take quite a lot longer than that,’ I suggested.

‘Well, come down for a day and we’ll get started and if I need you to come again, then fine,’ he said.

I was in London for a week so I could easily be flexible.

I took the train down to Brighton from Victoria and, astonishingly, by lunchtime I was already on my way back. I’d showed him how to set up a chart of accounts (20 minutes). how to set up some analysis codes (10 minutes). I set up some journal types (20 minutes). a few simple reports, and showed him how to run the inbuilt Trial Balance. And that was that. Four hours or so. Instant understanding. Nothing that defeated the capabilities of the system. No subsequent complaints. Very few support calls over the following years. In some senses an ideal client, though I confess that we like to make a little more money out of consulting fees than in this particular case. Generously, the finance director permitted me to charge for an entire day of consulting.

It made me wonder what on earth all the fuss is about in Central and Eastern Europe.

Times have changed, and life and accounting have gradually become more ‘Western’ in the former Soviet bloc (except in Russia). Gone are the Negative Debits and Credits and the reports that are based on Correspondence Accounting. Ask the locals nowadays what they want from the system and they’ll list a dozen Key Performance Indicators that you’ve never heard of. And SunSystems is still as good as ever at the job.

Has anyone has implemented SunSystems in fewer than four hour?. Let me know.

Adam Bager

Occasional thoughts on IT, Business and Other Matters

Tag Archives: sunsystems