Just as…

Just as playing a musical instrument or singing musically is far more important than playing or singing accurately (indeed, a friend of mine sings the right notes only rarely, and most of those accidentally, but his musicality is profound – imagine a male version of Florence Foster Jenkins), and just as a good consultant needn’t know anything about anything in particular (it’s more important that he or she should look smart, ask good questions and listen well, than spout dry technical truths), and just as sales is more about being liked than knowing something about what you’re selling, and just as speaking eloquently is more important for a politician than having anything useful to say, so what software actually does is far less important than how it looks.

Well, perhaps I exaggerate, but there’s an iota of truth in some of this nonsense and I’ve reluctantly accepted the view that what’s called the ‘functionality’ of software (how I hate that word, but continue to use it) is by no means the only thing that matters.

I design a configurable software system called time@work. It’s designed for Professional Services Organisation such as lawyers, engineers, and consultants, indeed any organisation that needs to record the time and expense incurred on projects. We have nearly 300 customers around the world, and we meet our customers requirements without needing to change the underlying software code – we click and build and configure the basic software to do millions of different things.

Of course, we bring out new versions from time to time, and most of the changes we make are inspired by our customers’ needs. We add new options and checkboxes and functions, and I doubt that we or our clients will ever run out of such ideas, but we keep fast to the rule that we’ll only have one version that’s ever more capable. I was once a programmer (and yes, once a programmer, always a programmer (it’s like being a Roman Catholic, I believe)), and it has often seemed to me that adding more ‘functionality’, ever greater capability, is more important than anything else. More important, for example, than that the system should look attractive.

But of course I’m wrong about that, though less wrong than I used to be, and I have to remind myself from time to time of that old adage in the business software implementation that projects fail more often for other reasons than that the software doesn’t do exactly the right thing.

That doesn’t mean that you can use Microsoft Word as a manufacturing requirements planning system, or Microsoft Excel as an airline booking system, but there’s a grain of truth in the idea. Configurable software such as ours, however brilliantly conceived (!), doesn’t always do exactly what customers want, and there must always be flexibility and imagination and compromise on all sides if an implementation project is to succeed. You can concentrate on nothing else but ‘functionality’ and you’ll never produce an infinitely capable system. A year of software development work might take you from a 94% fit to a 94.5% fit.

The problem is that if you concentrate only on capability, you’ll neglect those things that sometimes seem more trivial to you if you’re a programmer – the graphical look and the ‘usability’ of the system. If there was a road to Damascus for me, it was in the development of our iPhone App. Developing the systems@work App was a great lesson. The world of Apps is unforgiving and to succeed you must meet higher standards of attractiveness and usability than in the kind of software that’s used in the dark corners of accounting departments.

And so, in the recent version of systems@work’s time@work, expense@work and forms@work we’ve spent time and money on making the software look a lot nicer and easier to use. I don’t regret it. We released Version 6 a few weeks ago and it’s been received with enthusiasm by customers and resellers alike, and I, too, find it a greater pleasure to use.

This took months!


There’s still more to do. Weeks of programming time can be consumed in making paging controls and field lookups look consistent across the system, but we’ll continue. That’s not to say that checkboxes here and there that add to the capability of the system will be entirely neglected, but for a few weeks ‘functionality’ must take a back seat.


systems@work Version 6 -We’re Nearly There!


We hope to release systems@work Version 6 in the coming days/weeks. Today was the first day of the gradual release process – a first release of a pre-release version to me and to a few of my colleagues.

The next step will be the upgrade of our LLP Group system on Friday, so between now and then we must iron out the most alarming and noticeable bugs.

But I’m already pleased with what I see.

My first step, on receiving the new version this morning, was to upgrade a standard time@work demonstration database. The new Home Page looks like this:


We’ve narrowed the page header to allow the display of more transactions. We’ve arranged all immediate actions into a To Do panel and an Approval panel, we’ve provided a Shortcuts panel, and we’ve arranged the functions of the system into a tab strip.

It is easier to work with and it looks more modern.

Reports can now be arranged into Custom tabs (such as Timesheet reports, Utilisation reports, Realisation reports, Audit reports, and so on).


There are also new ‘Static Data’ reports that enable you to list Employees, Clients, Projects, Tasks and Analysis Values, and you’ll be able to use Ledger Export (and Task Scheduler) for exporting such data to external systems.


We’ve also revised the way in which destination email addresses can be defined for invoices. You may define one or more roles (such as Project Manager, Client Project Manager, and Company Accountant) as the default recipients, and also allow the editing of the recipient list at invoicing time.

During the next forty-eight hours we will correct the most obvious problems, upgrade our own systems on Friday, and then prepare an official release for mid- to late July.

Why the delay?

  • Help Text
  • Documentation
  • Standard Demonstration Databases
  • Bug Fixes
  • Release Notes

There’s still a lot to do.



I was intrigued by Forbes’ list of the 100 most powerful women in the world. Not only by who’s included, but also by what it purports to be. Sadly, I’ve heard of only five of the top ten ladies:

  • Angela Merkel
  • Hillary Clinton
  • Janet Yellen
  • Melinda Gates
  • Christine Lagarde

The other five of the top ten are business leaders but I’ve as much interest in the business league as I have in the Football Association Premier League – none at all.  Though the latter is  an important client (they use expense@work for their expenses) so I should pretend an interest of a kind.

Out of the next 90 I’ve only heard of only ten. But that’s a measure of my ignorance rather than of anything else. I counted my way through the list with the intention of comparing my ignorance of powerful women with my ignorance of powerful men, but I searched in vain for the equivalent list of 100 most powerful men. I found only a list of the 73 most powerful people in the world.

But of the top ten men in this list I’ve heard of nine, so I suppose I’m less ignorant of men. Sadly, only nine women feature in the list, and one of these is Dilma Rousseff (she’s being impeached, so currently she possesses no power at all).


But what is power?

Wikipedia says of these Forbes lists that ‘Slots are allocated based on the amount of human and financial resources that they have sway over, as well as their influence on world events.

But what is sway? What is an event? What is influence? And does ‘amount of human resources’ mean number of people? These are lamentably vague ideas, even if the list makes for a good topic of conversation.

Looking at the list I can find various kinds of power.

  • Military power (Obama, Putin, Xi Jinping, Jong un)
  • Political power (Merkel, Obama, Xi Jinping, Moon, Putin, Netanyahu, Cameron,  Hollande, Modri, etc.)
  • Moral or religious power (Pope Francis, Khameini)
  • Power to do practical good in the world (Bill & Melinda Gates, Chan)
  • Power to sway political opinion (Trump, Clinton, Murdoch)
  • Economic power (Yellen, Draghi, Buffet, Bezos, Brin, Cook, and all those CEOs)
  • Power to change day-to-day behaviour (Page, Zuckerberg, Cook, Brin)
  • Power of invention (Musk, Cook, Page, Brin)
  • Legal power (US Supreme Court Justices)

But I find it hard to identify the kind of power that the Queen possesses. She comes 29th in the list of powerful women despite the fact that she’s forbidden to express an opinion.

And I miss the power of entertainers, writers, singers, the makers of sweet drinks, purveyors of fast food, makers of cigarettes, distillers of alcohol, pharmaceutical companies, designers, doctors, cooks, sportsmen and women, and artists. They surely influence us and inspire us in small and big ways every single day.

And then there is the devil and all his works.





Announcing systems@work Version 6


Version 5 of systems@work’s time@work, expense@work and forms@work was released at the end of 2015. It contained a number of enhancements, most of them enthusiastically received and put to use.

Version 6 will be released in early July. It seems soon for a new major release, but the radical revision of the browser-based Professional Services Workbench warrants it. Gone are the variously muddy-coloured lists of functional options, to be replaced by dynamic tabs, panels, links, and shortcuts.

Our aim has been fourfold:

  • To comply with current standards and graphical fashions
  • To present the user more clearly with To Do lists for data submission and approval
  • To enable navigation with fewer clicks
  • To make navigation pages responses to the user’s device (responsive design)

The result is a Home Page (for time@work) that is more pleasant to look at and easier to use.

Version 6

And list pages that look more modern:


Version 6 will also contain the following enhancements:

  • A new reporting option that allows you to report on and export static data (such as Employees, Clients, Projects and Tasks). This will be of particular benefit for integration.
  • Credit Notes in the browser-based PSW
  • Enhanced emailing options for Invoicing, including an option to select an Employee as a destination and to allow emailing to multiple email addresses
  • Workflow Control for Timesheets to allow diversion of a timesheet from one authoriser to another


Fixed Price and Agility

I’ve come to love ‘agile’ systems implementation methods, and they are rightly fashionable in the nerdy circles in which I move.

But when I was trained on business software implementation methods many decades ago, I was told that it had to go like this:

  • find out what the customer wants, and write it all down,
  • get his sign-off on the requirements document,
  • design the system, and write it all down,
  • get his sign-off on the system specification,
  • build the system,
  • get his sign-off on the system,
  • and so on.

It didn’t work well. In the first step you might get it nearly 95% right, though there was still a danger that the customer didn’t know what he wanted until he’d seen what he might get.

But the second step was usually the dangerous one. If you’d gained the customer’s trust by the time you’d put the specification in front of him, he’d usually sign it off, even if he had no idea what it meant. System specifications are usually written in an inhuman language using the terminology of the target system. Crucially, they convey nothing at all about what it might be like actually to use a system.

The system build would often happen somewhere far away in a software laboratory, to which, of course, the customer would usually be denied access.

And then the last step didn’t happen, because when he saw what you’d built he wasn’t usually very happy.


This was the old-fashioned ‘cascade’ method and it’s rightly out of fashion. The ‘agile’ method involves more frequent meetings, discussions and demonstrations, so that the customer sees what you’ve understood, what you’ve designed, and what you’ve built and can quickly tell you if you’ve got it wrong before it’s too expensive to change course. When you’re implementing highly configurable software systems such as our time@work, expense@work or forms@work products, or Infor’s SunSystems, prototyping is relatively easy and this method is perfect.

At systems@work we’re doing a big implementation project for a fund services provider. It involves expenses, vendor invoice management, billing, timesheets and lots of workflow and reporting, and all the accounting that goes with all the transactions that are implied. Yesterday we conducted an important  prototyping session, and I’m happy to say that it went well. There are a few things that we must change, but there are no fundamental misunderstandings.

But what about the agile method when a project is a fixed price one? Isn’t it potentially a recipe for disaster, in that changes of course are unpredictable and there’s no single moment when you can pin down the project scope in a system specification and treat all subsequent changes as separately chargeable?

This is not an easy question to answer. Wise and experienced project managers will build in a large ‘contingency’ component and perhaps put more emphasis on getting the requirements document right (even this stage of the project can involve proof-of-concept prototype demonstrations). But if you allow changes at later stages it’s hard to charge extra for them.

There is no perfect method. I would only say that if you believe the old ‘cascade’ method is a better one for large fixed price projects you are probably deluding yourself. You may be able more easily to define what’s out of scope, but it will be no easier to obtain the customer’s agreement that he should pay for all the ‘mistakes’ and scope creep, whether they are demonstrably his fault or yours.



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.


systems@work for Android


We’ve just launched our systems@work App for Android mobiles, so (with a little configuration and an upgrade to the central server application) our users all over the world can connect to their company’s systems@work database and submit and authorise forms through their Android mobiles.


It’s hard to find reliable statistics on relative market share for Android and iOS in the business sector (precisely those who might use time@work, expense@work or forms@work), but it’s clear that Android has won at least half the market, and in some areas of the world, much more than half. When, at a recent LLP Group company get-together, I asked my colleagues which of the two they use, a clear majority put their hands up for Android. A couple rather sheepishly owned up to Windows Mobile, but, with apologies to the two of them, for the moment I’ll ignore that opportunity. And the Blackberry one too.

At least Android phones can be cheap. When we reached the final stages of testing the Android version of systems@work a couple of months ago, I went out and bought myself one for just 40 GBP (with about ten minutes of free local phone calls thrown in to sweeten the deal). It took me some time to get used to the different style, but once I got inside our App it seemed like familiar territory and our App worked just as well. I was able to submit the invoice for the Android phone, as a legitimate business expense, using the App itself just twenty minutes after I bought it. (That’s logically equivalent to driving home a car salesman in the car he’s just sold you. Or something like that.)

Developing apps hasn’t been a painless experience. The problem for App developers is that the technical environment for App software is utterly different for iOS and for Android. And when it comes to Android you have the additional worry that you must make sure that what you’ve developed will work on the most ‘vanilla’ version of the operating system, because Android can be ever so slightly different on different devices. Apple’s iOS, on the other hand, is always the same (barring new versions).

So, App development is expensive. It took us more than a year to finish the iPhone version and around six months to complete the Android one. At least the web services that read and update the systems@swork database are the same for both Apps.

Our App is complex, though very simple on the surface. When you connect it to your systems@work database, it takes the forms that are defined there, and which are always very different for every one of our systems@work customers, and renders them in your mobile, together with all the lookup lists, date fields, numeric fields, and so on. that you need to fill in.

You can have as many forms as you like – for time entry, for expense entry (in local or foreign currency), for mileage calculation (with the distance between two place names or postcodes being automatically calculated by Bing if that’s what you need), for absence requests, for just about anything. You can photograph a receipt (or the Tower of Pisa for that matter) and record a voice memo. When you’ve finished entering data (online or offline) you can upload your transactions, photos and voice memos, to the server, sending forms for immediate authorisation or feeding the data into forms and timesheets that you can finish off in the browser.



I dream that one day there might be a single programming language that will work for both iPhone and Android, even if we’d then have to write a third version of our App. Stepan, our development manager, tells me that there’s talk in the technosphere about a new language or development environment called Swift that might solve just this problem. I look forward to it, but not tomorrow.

For the moment, and for some considerable time to come, we’re happy to have launched systems@work for Android as a separate App. It’s functionally identical to the one that works on an iPhone, so we’ll go on developing both in tandem, at least until we’ve finally caught our breath and have the stamina to begin again with Swift,

Keeping Up Appearances


Fashion can catch up with you without you even noticing it, until suddenly it’s nearly too late. I don’t mean skinny jeans, or leg warmers, or platform heels or first press extra virgin olive oil. Rather, I mean the way that software should look. What was modern and attractive five years ago looks worn and dated today.

Fashion creeps up on you gradually. At first there’s just a murmur, but as the years go by you hear it more and more – yuk, that’s not a very attractive interface! You ignore the criticism for a while, thinking that what software actually does is far more important than how it looks, but you’re foolish if you go on doing that for long. The problem is, of course, that it takes more than a few days to redesign and rewrite the surface layer of business software.

There’s also the issue of devices. We may still do most of our work on PCs or Macs but at times we’ll reach for our mobiles and tablets to do serious things there too. So interfaces must nowadays use responsive design techniques, so that a webpage will rearrange itself to suit the device it’s running on.

systems@work is a software author. We’ve developed a professional services management system – time@work , an expense management system – expense@work, and a forms workflow management systems – forms@work. All are different ways of configuring the same underlying systems@work software. It’s mostly browser-based software that runs on any browser with some configuration work managed through a back-office desktop tool.

We’ve been successful. The UK’s MPs use our software to record their Parliamentary expenses (we’re the solution not the ‘scandal’ that happened seven or so years ago). Consulting, IT, legal, pharmaceutical, financial, NGO and software development firms use our software all over the world. We have more than 40,000 end-users.

This is the browser Home Page that our current users use and love:


Yuk?! Well, not entirely. The options available to the user are clearly laid out in sections related to the functions of the system. Everything is more or less one click away. I hardly notice the interface when I do my timesheets, expenses and run my reports. And that, perhaps, has been the problem. I’m so used to it I haven’t noticed that by today’s standards it’s a bit dull and out of date.

I’m the software designer and I’m confessing that in this respect we’re not up to scratch because now that we’ve released Version 5, we’re working on a redesign, hoping to release Version 5.1 in about three months’ time.

We’re changing buttons, fonts, and other bits and pieces, but the big changes will come in the way the system can be navigated.  As well as adopting a more fashionable style, we’re going to ‘advertise’ the system’s options more noticeably and provide configurable shortcuts to diaries, skills databases, and reports. And instead of scattering notifications of things you’ve got to do across the page, we’ll list tasks, upcoming consulting allocations, and news in one easy to read ‘Today’ tab.

The Home Page is going to look more like this.


I think it’s better, but it’s work in progress, and I’m open to suggestions.


Undergoing Analysis


It’s a well-worn truism of business systems that there’s no point in a report if it doesn’t change what you do. If you’re to control something you must measure it. Conversely, if you don’t need to control something, then there’s no point in measurement.

Even so, for nerds like me, there might be some pleasure in measurement. Analysis for its own sake.

I love statistics. I am an out-of-the-closet nerd. At school, although I was no genius at mathematics, I wasn’t bad at it either, and I took particular pleasure in statistics, the art of deriving meaning from apparent chaos (yes, and lies too, as they suggest). Whilst I’ve forgotten most of what I knew (nowadays I don’t know my mean from my median) I still love the idea of distilling something interesting, if not useful, from vast reservoirs of data (I think the fashionable term is BIG DATA).


Over a decade ago my company LLP Group sponsored a music competition in the Czech and Slovak Republics. We traipsed around both countries with a jury of four distinguished teacher/musicians, one from each category (strings, woodwind, brass and keyboards) and we listened to nearly two hundred young musicians. We had a relatively simple scoring system that delivered a single number between zero and ten for each player, and at the end of the tour, we promoted the top four from each category to the semi-finals.

I ran the scoring system using an Access database of my own devising, and every morning after I’d crunched the previous day’s numbers I’d produce a report for each juror, laying bare the unconscious stirrings that influenced his or her preferences. I was particularly keen to analyse these biases – a preference for Slovaks or Czechs (nationalism is always a danger in this part of the world), a preference for their own category of instrument, a preference for men or women (numbers I didn’t make public) and their average score and standard deviation. In the case of average score I had great difficulty in convincing them that the lower the average the less influence they might have on the final result. As for standard deviations, they didn’t like the sound of that at all.

Nationalism was a clear bias, unsurprisingly, but I found that each juror was biased not for, but against his or her category of instrument, as if he or she knew exactly where to find fault. As for bias towards men or women, this was fascinating, but I was careful to keep the sometimes surprising results to myself.

The systems@work part of LLP Group produces software for professional services management, which I design, and we’ve implemented the system across the group. In idle moments I speculate on certain questions such as ‘Is utilisation different on different days of the week?’ and ‘Is realisation related to the length of a client engagement?’ Utilisation is a measure of how much available time a consultant spends on client-directed work. Realisation is a measure of how much client-directed work is finally billable. I’m not sure that one can do anything with this knowledge, but it’s fun, and when I looked at all the reports in our system the other day I came across some of the reports I’d idly written a year or two ago to answer these two questions (it must have been a rainy winter weekend).

Here for example, you can see that utilisation is slightly lower on Mondays and Fridays. No surprise there, I suppose. What could one do about it? Well, maybe make Monday and Friday six-hour, rather than eight-hour days, making the midweek days longer ones?



And here you can see that average realisation is not significantly a function of engagement length.


time@work can do all of this (and less!). And no doubt more. Utilisation by nationality, by sex, by age, by client sector? Average engagement length by season? Hmmm…work to do!


For me this is fascinating, but perhaps it is I who should undergo analysis.




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.