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

analysis

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?

Utilisation

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

realisation

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.

Money is a Charmless Motivator

There’s nothing more vexatious than worrying about what to give your staff as an extra token of appreciation at Christmas.

At this time of year, at LLP Group, as at other companies all over the world, we’re busy trying to finalise projects and close outstanding sales, so that we can end the year with the highest possible revenue and profit. This year is no exception. But such anxieties are child’s play in comparison with the woes of deciding what gifts to give our staff.

I don’t mean bonuses, which may be substantial, or trivial, or indeed non-existent, depending on performance and position, and which are always monetary. Rather, I mean that little, and more effortful, token of appreciation that should be more personal, and which isn’t usually money.

Every year we struggle to please everyone, so every year we take soundings on what went down well in previous years. But, of course, we always fail.

We’ve given vouchers for Marks and Spencer.

mands

We’ve given ‘experiences’, whereby everyone can choose from a list of ‘adventures’ such as driving a double-decker bus, a day of facials, massage and other forms of indolence at what’s called a ‘wellness centre’, a parachute jump, a dancing or a cooking lesson.

parachute

We’ve given company-branded items such as backpacks, jackets and polo shirts.

backpack

We’ve even given smoked salmon (I remember one employee saying, ‘All they gave me was a slab of wet fish.’).

salmon

Last year we did a sort of secret Santa thing whereby each employee chose a gift for another randomly nominated employee (I got a bottle of vintage Port and gave a collection of Japanese items to a colleague who’s learning Japanese).

secret santa

We’ve given LLP-branded mugs. We’ve given iPod Minis.

In Budapest this year, we’re giving dining-out vouchers.

romantic dinner

But I’ve learned that you can never get it right. True, you only hear about your failures to please, rarely that you have delighted anyone, but that is the way things are, and I am long since inured to it (any form of remuneration is naturally understood as entitlement rather than gift). So the scale of disappointment is always exaggerated.

A close friend of mine described how, even in a very difficult year, she managed to give cash bonuses to her staff, and heard not a word from them. (Her partner, seeing how hurt she was, gave the staff a stern dressing down.)

There’s a strong lobby in favour of ‘branded’ items with our logo on them, but my own view is that a gift shouldn’t come with too many strings attached. ‘I’ll give you this, but you’ll be advertising the company by wearing it or using it.’

We could debate this issue for hours, and often we do.

My advice, though, is not to worry too much about it. You’ll never please everyone. All in all, you’d be better off worrying about the sales you need to close.

This year we’re giving vouchers, which, to my mind is more or less money. It’s charmless, and impersonal, but it’s convenient, and easy, and it’s apparently what everyone wants. You’ve got to please the majority at Christmas if you can.

Now, four more working days to close those sales.

systems@work App – A New Version

Learning how to develop and manage Apps has been a difficult and essential experience for our development team at systems@work. ‘Mobile’ is the buzzword these days, even if last week it was ‘Cloud’.

We recognised three or more years ago that we needed to develop an App for our largely browser-based ERP software – time@work for Professional Services Management, expense@work for Expense Management, and forms@work for forms workflow management. In some ways it’s not easy for traditional ERP developers and consultants such as we are to learn the new tricks of the App world, but if you’re in the business of packaged ERP software you’ve got to keep up with technology and be near the leading edge, if not quite at the edge itself. Just as the browser revolution demanded that we think in a different way both technically and in terms of user experience, so the App imposes new demands. Apps must be even easier to use, indeed almost a joy, manipulable with a single finger or thumb. But making the complex seem easy is always a challenge with complex business applications.

The tradition with Apps is always keep it simple, or, rather keep it looking simple and easy to use. Specialist terminology must be avoided, and functions must be intuitive and easy to use. The space you have to work with is small, but nothing must look cramped. Obviously there’s no point in crying RTFM when users complain that they don’t know what to do next. If your Granny can’t use it, you’ve probably failed the keep it simple rule.

granny

But ERP systems are complex, and our systems@work software is highly configurable. It’s all about forms – forms for expenses, forms for absence requests, forms for recording time on projects, forms for stock movements, forms for this and that. You can configure a form to do any number of things, offering different fields with different lists of items, calculations with different rules, and so on. You can also attach photos and record voice memos and use forms in any number of different languages. You can also set up any number of form types and control who sees which ones.

All the lists, labels, definitions and rules that form types need are held by our system in a central database. So we have to make everything work with a single App, an App that can read and download these rules and interpret them on your mobile device. Moreover we need to make this download work swiftly. You can’t keep Granny waiting.

Apps must also work whether you’re online or offline. Actually, that’s not a necessity, but given that the rules that govern forms must be downloaded to the simple database that sits inside your mobile, then why not? Some of our users have been clamouring for years for a way to enter their expenses offline whilst flying, for subsequent upload in the Arrivals Hall. So it was part of our plans to produce an App that could be used offline as well as online.

We set ourselves these objectives:

Our App must be easy to use
Our App must look good
Our App must work with any configuration of our software
Our App must work offline and online
Our App must be fast in terms of upload of data and synchronisation

iPhone technology is very different from the Microsoft technology we were used to, and we had a difficult choice, either to find an iOS expert and teach him or her how our system works, or retrain one of our programmers on iOS technology. We chose the latter but had recourse to App expertise when we needed it. Even so, it took nearly 18 months to develop the first version of our App, together with all the server-side web services we need to serve it.

Take up is gradual but accelerating, and yesterday we released Version 2.0, taking account of immediate feedback from our users. We’ve improved usability, extended the use of the App to include form authorisation, and improved graphics. In the coming weeks we’ll release an Android version, and in the coming months a Windows Mobile version.

APPV2

There’s also one more challenge that ERP software authors face – how to manage the release of App versions. The problem is that ‘delivery’ is uncontrolled. Release an App to the App Store and everyone gets it almost immediately. It’s got to work first time for every Client who’s already using it irrespective of their configuration, and without a chance to run in test mode. This also implies that each new version must be compatible with prior versions of the core software. We’re still thinking about how to do that in the best possible way.

Just Three Days After Two Days to Go

Yesterday we finally released Version 5 of time@work (expense@work and forms@work to follow shortly), just three days after we were only two days from completion. As I wrote on Monday, estimating and predicting in the area of software development is immensely difficult (Two Days to Go).

At systems@work we develop specialist software for professional services management, expense management and workflow. Our software is used all over the world.

PSWV5

Version 5 includes many improvements, though, inevitably, not as many as were on my list when we began our development work a year ago, and some improvements weren’t on my list at all. Priorities inevitably change from one month to another in response to the demands of customers and potential customers.

With every new release we must make advances on at least four ‘fronts’:

The ‘functional’ front. Every new release must be more capable than its predecessor.

We’ve made the calculation algorithm more powerful by enabling parallel sequences of calculations.

We’ve made it possible for invoices to be emailed directly to clients in Word, Excel or PDF format.

We’ve enabled drilldown ‘sub-reports’ from timesheets and forms.

And more.

The ‘technical’ front. Every new release must work with the latest operating systems, browsers, and devices.

We’ve added time capture to the capabilities of our App.

We’re shortly releasing an Android version of the App.

We’ve made some processes faster, such as invoicing and data import.

We’ve provided invoicing and data import capability in the browser. This means that end-users of time@work can now do everything in a browser:

Timesheets – submission and authorisation

Expenses – submission, authorisation and review

Forms – submission, authorisation and review

Approvals

Invoicing

Planning/Budgeting

Skills Matrix

Reporting

Data Import

Data Export

We’re therefore ever more ‘cloud’ ready.

We’re investing in ‘mobility’ by providing more options through our iPhone and Android Apps.

The ‘graphical’ front. We have to keep up to date with graphical fashion.

In this respect, we’ve still got some work to do. I have many faults, but one of them is certainly to think that in the end what matters most is what software DOES. I do believe that, and I probably don’t give enough weight to graphical considerations. But over the last months I’ve heard too many comments that our software is looking old fashioned, so over the next two months we’re going to modify the browser interface radically to bring it up to date.

The ‘usability’ front. We have to make our software ever easier to use.

We’ve made it possible to work with forms in ‘page’ mode as well as in ‘grid’ mode.

We’ve made it possible for end-users to import data into forms from Excel spreadsheets. This means that expenses, for example, can be entered into a spreadsheet offline and then uploaded.

We’ve added search capability and two-column lookups in the App.

But in this area , also, there is more to do. We’ll be looking at improvements in Planning and the provision of responsiveness in search tools so that searches are conducted as characters are typed.

I have a list of hundreds of suggestions from customers and colleagues, and I have lots of ideas of my own. Plenty of work to do!

Countdown – Two Days to Go

Building software isn’t necessarily more difficult than building a building or a tunnel. You don’t get wet, or get mud on your boots. You don’t work with dangerous machinery or risk falling from a high place. You don’t need a hard hat to write software, you just need a chair, a warm place, a mug of tea and a computer.

building site

You would think that there are fewer unpredictable things in the logical space in which we software developers work (barring the malfunction of other pieces of software that form part of the system – equivalent, I suppose, to malfunctions in materials that form part of a building). It’s not an exploration of unknown conditions, either. You don’t unexpectedly discover that a logical turn takes you into more difficult ‘logical’ space, whereas the digging of a tunnel might take you into muds of different textures and load-bearing capability.

Assuming that requirements don’t change, there should be nothing unexpected when you’re programming, and nothing should get in your way.

So, why is it so difficult to finish software systems on time?

Perhaps the answer lies in the fact that whereas a building is conceived fully before construction starts – its outline, its height, its weight, and all its components and how they’re to be put together – the details of a software system are ‘worked out’ as it’s developed. A full description of it would be the system itself. Perhaps it’s like the development of a mathematical proof. The destination, the theorem, may be known in advance, but the tortuous path towards it has yet to be described. The full description is the solution.

We’re just two days away, we hope, from releasing a new version of time@work. We’re late, of course. We should have been two days away some weeks ago (perhaps months, if I’m really honest). But I’m not complaining. This is the way development goes. We’ve moved the goalposts a little, we’ve found some things more difficult than we’d expected. We’ve reversed out of wrong turnings when the ‘final’ version of a new feature wasn’t as easy to understand and use as we’d imagined. We’ve sometimes not anticipated that a change in one part of the system would cause logical problems in others. Who can eliminate such issues from the software development process?

It happens every time. Even after years, our estimates are sometimes wildly inaccurate. I hesitate to abandon estimation, since in software development you must choose between priorities, and knowing how long something will take and therefore how much it will cost is an important component of that judgement. I’m still not ready to shrug my shoulder and go down the route of ‘It will take as long as it takes.’

But it’s wonderful to be just two days away (or three, or four, perhaps) from Version 5. It’s been a year since we produced a major new release, and this one contains some exciting new features. I’ll list them when we get there in a few days time but for the moment we’re doing final assembly and a bit of cleaning up.

We need a revised demonstration database to issue with the new version. Not only must all the data be updated from 2014 to 2015, but changes have to be made to illustrate the new possibilities in the software.
We need to update the system help text with text from the new complete reference guide to the product.
We need to make some final graphical adjustments (consistent fonts, colours, styles, new login screens).
We need to fix some final bugs.
We need to run a ‘release check’ across the entire product to test as many functions as possible in as many permutations as time allows (testing all of them would take longer than the lifetime of our solar system).

We do this with a series of iterations of the product. The problem is that this means we’re tilting at a moving target. I received a new iteration on Friday and worked on it over the weekend. Everything that wasn’t working before worked, but one thing that worked in the previous iteration didn’t work in this one.

Perhaps just one more iteration, today or tomorrow, and we’ll be ready to release on Wednesday. Fingers crossed.

Sweetening the Pill

‘People buy from people,’ we’re told, again and again, if we’re in the business of sales. It’s not about the product: it’s about YOU.

I say this myself to our sales staff in LLP Group and systems@work. We write and sell software, and provide the consulting days that make the software work. Of course, I don’t mean to imply that the software product and what it can do is irrelevant, but rather that in making our software work for a customer it’s only partly about the product, and as much about the skills of the people involved in the sale and implementation, including their personal skills of persuasion and determination. Assuming, of course, that during the sales process our sales staff are selling as if they are honest and realistic consultants, which, often, they have been.

People buy from people. And people buy from people they like. And sometimes people like people because they give them things.

Sales has always been a muddy business. The trick of making people like you should be about what you’re bringing to them ‘professionally’ rather than ‘personally’, but sometimes it isn’t. There are the dinners, the gifts, the ‘training’ trips, the nightclubs, the seats at sporting fixtures, all those benefits that oil the wheels of sales. They’re often above board, completely visible, accountable (even tax deductible) and bring no long-term personal benefit to the recipient, but sometimes they’re not.

The rule in my company is that anything we give to a client or a potential client (and we set a very low maximum) the recipient must be able to declare to his or her boss. We give bottles of wine at Christmas, and we take our visitors out to dinner.

Sales is certainly cleaner than it was, but we’d be lying if we suggested that the reason we are generous to potential clients and existing clients has nothing to do with wanting their business. There are grey areas.

In the world of business-to-business software sales in the private sector it is not complicated. But it all gets much more difficult in areas where ethics and public money are involved, such as in the purchase of pharmaceutical products by publicly funded health services. Pharmaceutical products must be good for the patient, and affordable for the tax payer.

pills

Over the last few years the practices of pharmaceutical sales teams have come under the spotlight and, as in China recently, pharmaceutical companies have been prosecuted and fined for ‘bribing’ doctors to buy their products.

I don’t know if there has ever been direct under-the-table bribing, such as cash in brown paper bags, but the tentacles of pharmaceutical companies go so deep into the institutions they sell to that it’s difficult to disentangle the ethical from the unethical. They sponsor research, they provide samples, they run training courses, they pay for doctors to go to, and speak at, conferences, they run educational seminars, and often entertain on a lavish scale. It is no wonder that the objective independence of those who recommend and prescribe particular products is undermined, consciously or otherwise.

So great have been some recent scandals that regulation has now begun to intrude on these practices. One consequence is that pharmaceutical companies must now track and report on all the ‘benefits’ they provide to Health Care Professionals (HCPs). This reporting is enforced both internally but also by statutory bodies. The value of all benefits must be reported by expense type, by organisation and by individual (and by the role they perform in the organisation).

This is where expense@work comes in. I’ve recently been engaged in trying to sell our expense management software to a pharmaceutical company that’s under pressure to provide exactly this kind of HCP reporting. It’s easy for us, and I can easily configure the system to track expenses not just by the elements that are needed for accounting purposes (expense type, description, gross value, VAT value and net value, in transaction and local currency) but also by organisation and particular health care professional (if appropriate) and by pharmaceutical product area and product.

I can picture the sales representatives assiduously entering these data into our system and I don’t suppose they would like doing it, but transparency in the slightly murky area of pharmaceutical sales is long overdue.

Pharmaceutical companies are essential. Where would be without them? And it is legitimate that they should actively advertise and promote their products. This means relationships with HCPs at all levels. The provision of education and training is part of the process too. But even if there’s complete transparency, it’s still important to be nice. People will always buy from people.

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.

Developing a Software Package – Sometimes the Nightmare Ends

I’ve posted two articles on what you need to think about if you’ve decided to develop a business software package. You might have a fantastically good idea, but developing, marketing, selling and supporting a package isn’t as easy as you might suppose. There’s far more to worry about than logical design.

The Nightmare

The Nightmare Continues

Have you thought about quality?

If you’re building parameterized software then it’s going to be capable of millions upon millions of permutations. Have you any idea how you’re going to test a sufficient number of these? Or even the most commonly used ones? The more that your package can do, the more ways it can go wrong. The quality level that you aim for is a matter of choice. Perfection is impossible, and near-perfection possibly unaffordable.

Have you thought about documentation?

You’ll need help text (and the capability of multi language help text), reference manuals, installation manuals, user manuals, training manuals, demonstration manuals, and so on. Your customers and resellers expect this (though don’t bother printing them). Electronic versions that can be accessed through a browser will do quite well enough.

How much of the product should you finish before you market it?

Your vision must be complete before you start, with an outline design for everything you intend to develop. You’ll want to sell your package as soon as you can, to make back your investment, but If you sell too soon, you’ll get diverted from your vision, and most dangerously, you’ll find yourself in obscure alleyways of customer-specific code. But if you sell too late, you’ll have used up all your money.

And have you thought of how you’re going to take your package to the market?

If you’re not yourself in possession of an international company, then if you’re going to sell beyond your domestic market you’re going to need distributors and resellers. You’ve got to see things through their eyes. How can they make money from your product? What will be their upfront investment, and their ongoing cost of sales? Is the balance between service revenues and licence fees the right one for them? Can they learn enough about the product quickly enough to be able to present the product and then implement it?

You need to think of the marketing material they’ll need, the return on investment arguments they’ll use, the contracts, the multi-lingual support service, the case studies, the training, the guidelines you’ll give on implementation duration and costs, and so on. If they can’t make money, then there’s no way you will.

And your pricing model has to be one that can, in theory, and even after discounts, return a profit.

But whatever you do, don’t try to set up a reseller network until you’ve won some deals yourself. When recruiting resellers, just as when selling to customers, references are everything.

How are you going to win your first customers?

Whether your first customer is your own or a reseller’s be aware you’re not going to make any money from the first few deals. Your first customers won’t buy your package, however unique, unless you give them a special deal and extraordinary service. It’s hard to sell without references. You have to ‘buy’ the first deals.

And have you thought about how you’re going to keep your development team happy during the long development period?

If you do lose a developer, is his code sufficiently well documented that another can take his place and maintain his code?

Have you designed a feedback mechanism so that your customers’ wishes are reflected in subsequent versions of your package?

If you don’t listen to your customers’ needs, they’ll soon stop paying for maintenance.

Have you made a prudent investment plan to take you from concept to sales?

If you can’t afford the long-term investment that package software requires – the employment, travel, technical and marketing costs that will take you to your goal – then don’t even think of beginning.

My company, systems@work, set out to develop software for professional services (and expense and forms management) more than a decade ago. Did we ask ourselves all these questions when we began?

Some of them, certainly, but by no means all. time@work is a ‘best of breed’ package for services organizations from accountants, engineers and lawyers, to architects, consultants and charity workers. It’s now used by more than 250 companies from Tokyo to Sydney, from London to New York.

If we’d known there were so many questions, we might never have started. During the first few years there were certainly times when we were close to giving up. But if there are two questions we certainly should have asked ourselves more aggressively, they are ‘How are you going to win your first customers?’, and ‘How are you going to take your package to the market?’

We’re securely profitable now, and my anxieties, if any, are operational ones rather than existential ones.

So, if you have a dream and you can answer these questions positively, and if you’ve got nerves of steel, then good luck. After all, someone has to write these packages.

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.

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:

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.

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?

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.

Adam Bager

Occasional thoughts on IT, Business and Other Matters

Tag Archives: systems@work