Beyond the Call of Duty – How Far Would You Go for Your Client?


There’s a Monty Python sketch – Four Yorkshiremen – in which four prosperous but nostalgic middle-aged men compete to recall the misery of their childhood, each trumping the other with the degradation they suffered.

4 yorks

‘Who’d have thought, forty years ago, that we’d be sitting here drinking a glass of Chateau de Chasselan.’

‘I’d have been glad of the price of a cup of tea then.’

‘A cup of cold tea!’

‘Without milk or sugar!’

‘Or tea.’

‘Out of a cracked cup.’

‘We never had a cup… we used to drink out of a rolled up newspaper…’

…and so on, until…

‘We used to get up in the morning at half-past-ten at night half an hour before we’d gone to bed, eat a lump of cold poison, work 29 hours a day at the mill for tuppence a year, come home, and then each night our dad would strangle us to death and dance about on our graves.’

‘You try telling that to the young of today. They’ll never believe you.’

At risk of provoking a similar competition I was thinking about the most inconvenient things I’ve had to do to keep a customer happy.

There was the time I got up, still a tiny bit drunk, in the middle of a Saturday night in Budapest and took a taxi to a town 60 km away to deal with an MRP program that had inexplicably ground to a halt.

There was the time I interrupted a skiing holiday in France to fly to the UK to present a proposal to an oil company.

There was the time I spent a thousand pounds on mobile phone calls from Turkish Cyprus to a client in London to try to resolve a persistent system failure.

There was the time I spent a whole night importing historical data into a SunSystems database for a large auditing firm.

And there was the time I spent a few nights in an unheated flat in a closed city on the outskirts of Moscow in the company of a family of cockroaches.

In retrospect, I suspect that the world wouldn’t have ended if I hadn’t done some of these things, but I hope they made a difference.

None of these stories, though, comes anywhere close to the devotion of one of our LLP Group consultants to her client. I won’t name her, and though perhaps she went a tiny bit too far, I admire her shameless and single-minded determination to support her client, come what may.

No resemblance…


She’d spent a whole week in London working on a new system implementation, and come Friday evening she was standing in the boarding queue at a gate at Heathrow Airport, on the way home to a Central European capital. The phone rang, and it was the project manager. They were having difficulties in closing their accounts at a site in the north of England. They needed her help.

She tried to resolve the issue over the phone, and kept joining the back of the queue to give herself more time. Whether the project manager knew where she was, I don’t know. Finally, there was no one left in the queue and she was the last to board. At which point she told the ground staff that she wouldn’t be boarding the flight and would be making her way by train to the north of the country instead.

Understandably, ground staff, cabin crew, pilot, flight controllers, passengers, everyone was furious. The plane would miss its slot, other passengers would miss their connections, and so on. But our consultant was adamant. So they offloaded all the blue Samsonite suitcases they could find, our consultant identified hers right there on the tarmac, and then scurried away to the north of England, by taxi and train.


I wonder that she’s not on a blacklist of unwelcome passengers and that any airline will fly her anywhere. But they do.

Can anyone trump that?


Developing a Software Package – Dream or Nightmare?


In the world of business software development there’s nothing more fun and more challenging than designing packaged software, software that’s designed to adapt itself to the particular circumstances of each customer, without software modification. Basically you’re building software that’s packed with parameters and switches to make it work one way or another. This can be elegantly and well done if you get it right at the start, but if you’re led this way and that way by the demands of each particular customer, you can end up with a dog’s dinner.

software package

Either way, it’s an expensive venture. It costs more to develop this kind of software than code that’s designed for just one purpose, because it takes a lot more time, but the reward, when it comes, is that you can sell the same package time and time again. There’s just one body of code to look after. So, if you’re an expert in a particular area of business, and if you’ve got the right logical imagination, it’s surely an opportunity not to miss.

Or, so you might think.

I’ve done it myself. I’m the designer of systems@work, a single software package designed for professional services management (time@work), expense management (expense@work) and workflow (forms@work).

I’m typical of many a programmer who spent years writing one-off programs for specific businesses. I developed a practice management system for Coopers & Lybrand, in Paradox, from scratch, and adapted another software package for KPMG for the same purpose. So it occurred to me, as it does to so many of us, that if I could only distil what’s common from all the code I’d written or adapted, I could design a single all-purpose package that would, with appropriate parameters and switches, do everything all at once.

People like me dream of a few months’ fervent coding, and then, almost immediately, a crowd of buyers. We dream of license and maintenance revenues rising exponentially, and finally, at the end of the rainbow, a buy-out proposition from an enormous corporation (preferably beginning with M). The rest is a pleasant after-life that won’t involve work.

We know we can do this. We, alone, have that very special idea. We’re up to date with the latest technology. Why not begin at once?

But if you wake up one morning in the after-glow of a dream like this, then close your eyes and dream of something more sensible, like winning the Singles Title at Wimbledon. Only if the dream returns incessantly, and if it survives all the scepticism you can throw at it, should you begin to take it seriously.

But before you spend every last penny of your own or your company’s money, have another cold shower or two and ask yourself some questions – at least sixteen of them.

Here are the first three:

  1. Who are your customers?

There’s a world of difference between the package software market and the market for custom-developed software. Your customers are going to be those who realize that there’s ultimately more security in a general purpose package that’s going to adapt and grow with their business, than in a piece of one-off code for which support may not be eternal.

They’re going to be customers who understand that they won’t use everything the package does, and who will compromise their own needs if the fit is good enough. They are simultaneously buying more than they need, and less. So be ready to sell the idea of compromise. Beware of promising a long list of enhancements to every customer who’s interested, because If that’s the route you choose, you’ll end up with an ugly amalgam of cobbled-together code.

  1. Who are your competitors?

If your customers have decided on a package, then they’re not only going to look at yours. Let’s face it, most software markets are pretty saturated already. At the top end there’s Oracle and SAP, and if you’ve got enough money to buy them, those systems will do just about anything you need. But even if your customer is in the mid-market, then there’s still a crowd of mid-market systems for him to choose from. Does Navision, or SunSystems, or Great Plains, or Exact, or Scala already do exactly what you’re thinking of? Or nearly do it? It’s unlikely that you’re going to write a complete system that covers a company’s needs from payroll, to accounting, CRM, manufacturing, and distribution.

You’re insane if you’re going to embark on a completely new package that fits the ‘integrated’ model. Rather you’re going to be going for the ‘best of breed model’, with the idea that your piece of software is so special that your customers won’t mind fitting it into a tangle of other modules from other package systems. So whatever else you do, make sure you design open interfaces to a broad range of third-party products.

And keep asking yourself, do you really have some special knowledge that will make your software special?

  1. How are you going to make it simple enough but flexible enough to fit a broad range of customer needs?

This is the difficult part to get just right. If you’re going to appeal to sufficiently large numbers of customers to cover your investment, your package is going to be complex. It’s going to have screens of parameters that make it work one way for one customer and another way for another. After all, if it’s a package, you’re only writing one piece of code. If you end up with multiple versions for multiple needs, then your dream will become a nightmare before you’ve even sold five copies. So, think about your market, and choose just enough of it to make your coverage sufficient whilst making it possible for your customers to understand the software they’re buying.

More questions in a day or two…

The Niagara Falls – Pristine is too much to expect

I visited the Niagara Falls two days ago in the company of a new business partner based in Toronto (and occasionally Bermuda). It was a pleasant mid-afternoon drive from Toronto in fine Autumn weather and the car was a better pace to discuss business than an office or the foyer of a hotel.

The Falls, when we reached them were spectacular, and mercifully quiet. I don’t mean the Falls themselves, which were thunderous, as you would expect, but the crowds. It was late Season and late afternoon and the selfie-stick wielding tourists were no great danger to life or limb.


It’s not a wilderness site anymore and it would be foolish to expect as much, but the brasher aspects of tourism are more or less kept at bay. Tall brand-name hotels and casinos tower over the gorge from a reasonable distance, and I suppose they must balance the need to provide their guests with a view with the need to preserve the atmosphere of the Falls themselves. I don’t doubt that most visitors would wish the hotels, indeed the whole town, were not there at all, but then there wouldn’t be jobs and taxes.

Worse than the hotels, casinos, souvenir shops and cafes, are the crumbling and brutal relics of early hydro-electric schemes which lurk just below the Falls. They’re as lovely in their dereliction as the abandoned industrial ruins of Eastern Europe which were built with equally complete disregard for the environment. But there’s still a rigorously defended strip of parkland that follows the gorge, and the Autumn leaves on Monday were splendid. With a little imagination you can picture the Falls as they must have been. And the water falls as reliably as it always has.

As great natural wonders of the world go, the Grand Canyon is better managed. Hotels are situated some miles away, and human interventions (pipes, walkways, toilets) are few. It’s a magnificent example of minimal intrusion and careful preservation. No cable car, no escalator, the only way up or down is on foot or on horseback.

At the other extreme lies Halong Bay, in Vietnam, which I visited in February. Magical from a distance, murky and polluted up close. A few quick bucks, no doubt made possible by corruption, are trumping conservation.


But pollution, sadly, is everywhere. Even three hundred metres below the Niagara Falls there is this foul mess…


But one mustn’t lament too much. Modern dentistry, at least, is some kind of consolation in the world we are spoiling.

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)!

The Art Gallery of Ontario

You’re lucky if you can find the way to your plane at most of today’s airports. They’re no longer merely the arrival and departure points for aircraft, but also shopping malls, restaurants, clubs for the privileged, and places of entertainment too. Heathrow Terminal 5, for example, is an obstacle course of retail and gastronomic distractions. So much so that sometimes the airport is the most fun you’ll have on holiday. Why board the plane?

Art galleries, too, have caught on to this, albeit for loftier motives. Ticket sales aren’t enough to keep the paintings on the walls. Without substantial subsidies galleries can’t afford merely to provide space for their paintings to hang, and cabinets for their curiosities. They must explore every possible avenue of cash generation.

The Art Gallery of Ontario (AGO) in Toronto, which I visited on Saturday, is a fine example of this approach. Since its reworking in 2008 by Frank Gehry (a native of the city) it houses an upmarket restaurant, a shop that’s as large as any of the exhibition rooms, a café, a ‘function room’ for hire (where better to get married than in the company of a Francis Bacon and a Bernini Pope), and a cluster of education and research centres.

Once you’ve passed through the arrivals hall, avoiding the VIP check-in desk (a kind of art gallery version of business class), you’re left wondering where to go if you’re to see any actual paintings.

If you’re interested in architecture, though, the building is probably your destination (just as, if you’re a fan of Norman Foster, then Heathrow Terminal 5 is probably as much fun as wherever you’re off to). Gehry’s adaptation of the neoclassical central courtyard, and a hotch-potch of 1970s extensions, is an imaginative balance of the classical, the modern and the extravagant (a wooden spiral staircase twists and slithers its way from the first floor to the roof and beyond).

Gehry slither

The tall tower building at the rear of the gallery is clad in cool blue, reflective titanium.

gehry blue

But somewhere inside, if you can find it, there’s the collection itself (a selection from 80,000 paintings and other kinds of bric-a-brac) – a very manageable display of paintings by the French Impressionists (a beautiful Renoir, a Degas, a Monet (usually just one of everything)), the Renaissance and Flemish masters, all generously arranged and well lit. There’s an unexpectedly huge roomful of Henry Moore’s vast and dignified reclining and standing figures, in quiet but far from lonely communion, perhaps more of them together in one place here than you could ever see together elsewhere.

There’s a whole floor devoted to the work of Canada’s native artists. And you mustn’t overlook the African and photographic collections either, or a special temporary exhibition of disturbing images related to nuclear power, explosive and utilitarian.

Get a slice of this…

Atomic Cake-lo

The AGO is also a monument to generosity, and its fabric is as labelled as its contents. Indeed the labels are larger. You’re passing from one room to another through the ‘Rosy Tannenbaum walkway’, the roof is supported by the ‘Wasabi Family supporting girder’, the ‘Helen Battersby’ door sits snugly in ‘the Mary Minder door frame’, and the paintings are kept in good condition by ‘the David Clark and family humidifier,’ and so on. I presume the lavatories too are named, but I didn’t feel the need to check.

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.

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.

Singing is Just Saying

I spent the morning on Sunday at the Royal College of Music, at a Master Class on Schubert lieder given by the pianist Roger Vignoles. It was one of several events marking Vignoles’ 70th birthday, (though it seems an odd kind of celebration where he does all the work). He’s best known as an accompanist for singers, but he’s also a teacher at the College, and a soloist. My nephew, Frederic, studies the piano at the College and was taking part as an accompanist.


It was a long morning, without a break, and the seats were hard, but it was an inspiring and educative morning too – three hours of patient encouragement, explanation and constructive criticism that utterly transformed the performances, by five different baritones and sopranos, of seven of Schubert’s settings of Goethe. They were unhappy songs, mostly about unrequited love, depression, misery, loneliness, anguish, misunderstanding, hopelessness, grief and longing, indeed the full gamut of German angst. One after another the singers stood up and poured out their anguish. Three hours is a lot of anguish, especially without a tea break.

But if there was one thing that Roger Vignoles urged repeatedly, it was not to try too hard.

‘Be less musical,’ he said. ‘Don’t do too much. Don’t try too hard. Don’t feel too much. Let the music do the work.’

It was an informal event with performers and audience gathered on the stage. So informal, in fact, that the audience could even venture its own insights. A lady in front of me piped up with a very good point:

‘If you do too much with the song, you don’t leave anything for us to do,’ she said. ‘An audience mustn’t be told what to feel. We’ve got to listen and make something of it ourselves.’

It was a telling point. The more the singer expresses the meaning and feeling of a song, the less we, the audience, feel. It can be the same with emotionally extrovert music. Reginald Goodall, the slowest Wagnerian conductor in the entire universe, particularly avoided acceleration during the liebestod at the end of Wagner’s Tristan and Isolde, even as Isolde rushed towards her own death, and it was all the more effective because he let the music do the work.

I also remember listening to a well-known long-retired singer talking about his career (so long-retired and so long ago that I’ve forgotten his name). It was one of those ‘An Evening with…’ events at an arts festival. He spoke about how often he was persuaded to sing ‘Ol Man River’ as an encore. So often that almost no song bored him more, though it always brought the house down.

‘So full of feeling,’ his admirers would say. ‘But I was actually thinking about what I’d be eating for dinner,’ he told us, to much hilarity.

Not that singers and actors should be completely disengaged, as he was. Performers should be acutely conscious of their audience, more so than of their own emotions, and they must sing to the audience, tell them things. Singing is saying. But the fact is, a song can move an audience even if the singer is thinking of his dinner.

Roger Vignoles mentioned something David Mamet, the writer and director said – that the actor’s job is just to ‘deliver the text’, no more than that. Singers, too, must deliver the words and the notes, but as simply as possible, without overindulging in interpretation and characterisation.

Not that he could have meant this quite literally. After all, an actor delivering his text as a Dalek in a strident monotone wouldn’t, I think, be effective (unless it’s ‘Exterminate’), but I know what he means. Delivery should be simple and natural. Too much work, too much musicianship, and the song becomes the performer’s, not the composer’s or the poet’s.

David Mamet says the same of writing:

‘A good writer gets better only by learning to cut, to remove the ornamental, the descriptive, the narrative, and especially the deeply felt and meaningful. What remains? The story remains.’

It’s a lesson that applies to nearly everything we do. Don’t wear too many bright colours. Don’t add too much flavour to a soup. Don’t use too many adjectives. Don’t plead too explicitly when you’re selling. Don’t argue too passionately in front of a jury.

Leave something for the audience to do, to think and to imagine.