Why Consultants Love SunSystems

Share

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

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

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

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

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

barbie and ken

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

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

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

Their worlds shrank, and their horizons shortened.

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

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

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

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

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

See LLP International.

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

Fraud and Conscience – ‘It’s OK if Everyone Else is Doing It’

I’ve just read an account by Tyler Hamilton of his career as a drug-boosted (and eventually drug-busted) world-class professional cyclist  – The Secret Race – Inside the Hidden World of the Tour de France. His confessions, and others’, provided the evidence that nailed the world’s most famous doper – Lance Armstrong, seven times winner of the Tour de France and seven times loser (all seven titles were eventually stripped form him).

So prevalent was drug use, so essential if you were to stay amongst the world’s most successful riders, and so much part of what it meant to ‘belong’ to the heroic, winning fraternity, that to those in the game it seemed entirely justified. And so strongly was this felt that riders could lie for nearly a decade, with complete equanimity or outraged aggression, to the media, to the sport’s governing bodies, to their friends and family, and even when undergoing lie-detector tests.

‘Everyone is doing it,’ they said to themselves, ‘so it’s ok. It’s a level playing field.’

Indeed, large swathes of the public thought so too. When I was in the USA three years ago and Lance Armstrong had just admitted doping on prime-time TV, there were many Americans I met who thought he was being unfairly treated ‘because, after all, they were all doing it.’

But it was no level playing field. The best drugs were available only to those with money, guile and influence. It was a risk to the riders’ health, and clearly against the rules. It was cheating, pure and simple.

devil

When I get phishing emails telling me I’ve won an obscure lottery in Lesotho, when I hear about the cruel deceptions practised on vulnerable people (the elderly, in particular, are viciously singled out by telephone scammers) I try to understand the mentality of scammers, fraudsters and cheats. How does it feel like to them, how does it look like to them, as they rip people off, humiliating and impoverishing vulnerable people? How do burglars feel when they empty or trash an apartment?

Surely, all of these unusual creatures must have a special way, as dozens of top cyclists and other sportsmen and women have, of justifying it all to themselves. Or am I too generous in supposing they think and feel at all?

‘These people have plenty, and I have nothing. They won’t miss what we steal from them.’

‘I have to feed my family.’

‘If I didn’t do it, someone else would.’

‘If I don’t do it they’ll hurt me or my family.’

We’ve all come across similar justifications in more mundane areas of life and business.

‘Everyone cheats when they claim their expenses.’ (Even the UK’s MPs fell foul of this self-serving justification.)

‘You’ve got to bribe if you want to win a public tender. Everyone knows that.’

‘No one pays all the tax they should. I’d be a fool if I were the only one.’

‘If I didn’t take cash and were to issue an invoice instead, I’d be paying much more tax, I wouldn’t be able to compete and I’d soon be out of business. I have a responsibility to my employees.’

How do people get started with fraud or other kinds of crime? How do they manage their consciences? How do they come to believe they’re justified in what they do? How do they acquire the necessary moral agility?

Well, none of us is an angel. It probably starts with just a penny here or there that no one notices or cares about, and then it grows. Finally, for a few, it’s out of control.

But, as Tyler Hamilton explains, the worst situation is one where there’s peer pressure to join in. It became a rite of passage in the world of top-class cycle racing to accept the testosterone, the EPO and all the other stuff. You were ‘in’. You were good enough to win. It’s probably peer pressure rather than greed that gets most people started on a life of deception and crime.

To this day I remember stealing sweets from a shop in a small town in Germany. I was about ten, and I was ‘made’ to do it by a rather delinquent friend. I regretted it even then, which is probably why I remember it now. I wish I had been more priggish and goody-goody (well, that period, together with excessive church-going came later!).

Serious wrong-doing often starts with small misdemeanours and the encouragement of others. The academic, novelist and religious writer C S Lewis puts it well in his Screwtape Letters – Letters from a Senior to a Junior Devil:

“Indeed the safest road to Hell is the gradual one–the gentle slope, soft underfoot, without sudden turnings, without milestones, without signposts,…”

There’s a stark difference between those who are mildly sinful and those who are steeped in crime, but to those who travel the path from one to other it must seem like a gentle, if slippery, slope. I can only suppose that if they are human and possess the same mental landscape as the rest of us, they feel the same to themselves at the end of it as at the start, hardly having noticed the subtle and gradual erosion of their conscience.

On Systems Integration – What’s the problem?

Share

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

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

systems integration

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

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

Why is this difficult?

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

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

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

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

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

There are several good reasons:

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

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

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

Let’s look at that in the next post.

Rare and Precious Creatures

Share

I had lunch today with a former colleague. She was, when she worked for LLP Group, one of the best business IT consultants in the world, at least in the world I knew and know, which wasn’t small then, and isn’t small now.

She was, and is, meticulous, imaginative, extremely clever, pragmatic, and determined. She knows what can be done and how to get people to do it. When she worked for me, and on some projects with me, she travelled to Asia, to the Middle East, to Latin America and elsewhere, and learned about cultural sensitivity too. Of course, she wasn’t perfect, but I’ve long since forgotten the imperfections.

In the end, she was too good for us, and we were too small for her, and she left us to work for a large bank in the Czech Republic. There she manages enormous development and implementation projects.

Not my former colleague, I can assure you….but equally rare and precious.

rare and precious

From time to time we meet for lunch to catch up on family things, world affairs and, because they still interest us both, professional matters too. Amongst other things we talked about how hard it still is to find those rare and precious creatures in our profession who are really good at designing good business software systems.

The problem is in bridging the gap between those who have the business ideas and the business vision, and those who understand the precise world of IT systems and know how hard it is to go from idea to system. The job of the systems analyst lies between these two worlds, but finding good people who understand both sides of the chasm is really hard and I see no sign that it’s got any easier in the last twenty years.

A good analyst must grasp the essentials of what the ‘business’ wants, and what a system must be like to be usable by people who are not IT nerds. Such people are most easily found in the ranks of business tacticians or those who work in business operations.

A good analyst must grasp the essentials of what IT systems can do, how rigorously the rules must be defined, how information can be stored and transmitted from one place to another, and how difficult it is to program software. Such people are most easily found in the ranks of IT specialists.

Rarely can you find someone who isn’t very much more one type of good analyst than the other.

To mitigate this problem practitioners have adopted more flexible methods of development and design, such as the ‘agile’ method, whereby ‘users’ and ‘developers’ are more frequently brought together so that what one side thinks it’s understood, and what the other side thinks it’s asked for, are more frequently compared. The old ‘cascade’ method of finding out what’s wanted, building it in a remote laboratory and then bringing it back, finished, just doesn’t work. Probably even less successfully nowadays because business systems have become ever more complicated, and must be ever more easily usable by ordinary people.

But although ‘agile’ methods are better, they don’t eliminate waste. With iterative design and development procedures you move ten steps forward and then three steps back, so there are plenty of costly steps that you wish you hadn’t taken. A good analyst will save you perhaps two of these wasted steps.

I don’t see a better solution than finding the best possible people for the job, and neither does my former colleague. Method only gets you so far.

So where can we find business analysts who understand how to design good business systems? The skill can’t be taught. You can’t itemise it on a CV. Some recruits can’t even learn these skills from experience. It seems to me that it’s a matter of talent, of art. You might as well try to identify a good pianist from some words on a page.

Such people are rare and precious creatures. Hold on to them tightly..

Are programmers an endangered species? I saw an amazing thing in Australia.

I am an old dog when it comes to programming. I began nearly 35 years ago, coding in COBOL (an acronym for Common Business-Oriented Language), invented by Grace Hopper, who worked for the US Department of Defence in the 1960s. It’s a verbose language – lots of words to do only a little. Indeed, there really isn’t much that COBOL does to make your life as a programmer easier.

Of course, in ancient times, there were languages that were even closer to machine code, such as FORTRAN, but even with COBOL you still had to ‘lay out’ your use of memory and take care to prevent your variables from interfering with each other.

programmers

Over the years I’ve seen programming languages become more powerful. I wouldn’t say it’s made the job any easier. Whilst you no longer have to ‘lay out’ your use of memory, other complications have developed of another kind, as the possibilities and demands have multiplied.

Every few years or so, someone’s suggested a new ‘generation’ of programming environment where there’s more intelligence inbuilt into the language. But usually these ideas have disappointed. Either the language has to be so constrained as to be useless, or it simply doesn’t work. It’s either ‘you can have any colour as long as it’s black’ or ‘syntactical error at line 403’.

So, sceptic that I am, I was surprised to find myself responding enthusiastically to something a former colleague, Tamas, now living in Australia, showed me last week when I was in Sydney. He’s been taking some evening courses at the University of Erehwon in Sydney and he got drawn into a research project run by a Professor Kempinski. They’d heard about Tamas’s experience with business systems and were getting bored with the Professor’s obsessive experiments generating manufacturing systems for nylon stockings.  Tamas showed me how it works on his own PC and if it’s really what I think it is, then perhaps the programmer productivity revolution is finally about to happen.

I’m used to the idea of agile development. It’s a justifiably fashionable way of building systems, since it brings developers and consultants closer to the minds of those who will use the resulting system. The idea is that you involve real users in frequent prototyping sessions so that you can tease out what they ‘really’ mean when they say what they want, and they can see what you’ve ‘really’ understood when you show them what you’re building. But you still need consultants, and you still need programmers, so there are still the same two sides to the process – the users and the developers.

So, what if the users can simply ‘say’ what they need to a PC (or a Mac) without programmers or consultants present (and no Lilliputian programmers inside the computer).

The machine starts by asking you:

‘What system can I build for you today?’

You can’t exactly babble. There’s a kind of lexicon you must use. For example, you’ve got to say ‘location’ rather than ‘warehouse’ or ‘store’, and abide by many other similar rules.

So, I said, casting around for an application:

‘I need a system to manage the purchase, storage and sale of plastic bath mats.’

‘In how many locations can this bath mat be found?’ it came back at me, after only a very brief pause for ‘thought’. (One thing I should mention is that it only works if you adopt an accent somewhat like Professor Kempinski’s (Australian with a touch of Belorussian).)

‘Five locations,’ I answered. (I had to say ‘fife’ before it recognised the number, with a bit of a drawl on the ‘i’ to make it more Australian.)

‘Where exactly are these locations?’ it asked (the computer’s voice is modelled on that of Sheila, his wife, who is Australian, so actually there are risks of misunderstanding on both sides).

Once we’d got over locations, Sheila asked me how they might be assembled, what colour packaging they would come in (she rejected my suggestion of pink), who the suppliers are, whether they’re perishable (she obviously doesn’t ‘know’ what a bath mat is), what the pricing structure should be, and so on.

Finally we got to a very tricky area.

‘What do you imagine in the area of costing, mate?’ she asked.

‘I was thinking of actual costing, working out the true cost of products. Can you do that?’

‘True cost is an illusion, mate. There’s no such thing. Better use standard cost with monthly allocation of variances,’ she said. I have a strong feeling that Tamas was involved in this part of the algorithm.

After about an hour, I had a credible distribution system in front of me. In fact it looked like a system based on Microsoft NAV, but with more vibrant colours. Such systems usually involve months of programming work, not just an hour more or less alone with a PC.

I don’t know if the system would work in areas other than manufacturing or distribution (I see difficulties with simulation or planning), but it was an impressive demonstration, and for the first time ever I believe that we may not need programmers any more.

The software is still not ready. XI-Mera Version One will be launched exactly a year from now, on April 1st 2016. But when it comes, what will we do with our programmers?