Enterprise software is not a commodity

This post was prompted by a recent blog I read – Refuse to be a Cloud data hostage. The point of this article is that businesses should treat their cloud software like a commodity and be able to switch as they please. This stems from the argument by the Chief Technology Officer of Amazon, Werner Vogels, that:

“You should keep your providers on their toes every day. If we are not delivering the right quality of services, you should be able to walk away. You, the consumer of these services, should be in full control. That is core to our philosophy.”

When I read this, the word that stood out was “consumer”, not business. Consumers may have the privilege of being able to jump whenever they want, but my view is that businesses do not, and perhaps should not.

If you’ve ever worked in a manufacturing organisation, you will know that they invest in machinery only after a long evaluation process. Why? Because it is expensive, they may have to make changes to their processes in order to benefit from it, and they have to train staff to use. Then, if they want to keep getting benefit, they partner with the machinery manufacturer to maintain and improve it.

That is what should happen with enterprise software, whether it is in the cloud or not. Enterprise software is not a commodity, it is likely expensive machinery, and should be treated as such. If you think enterprise software is a commodity, then you are going to get very little benefit and far less than you had expected.

Enterprise vs consumer applications

There is a discussion around the Internet about making enterprise applications work more like consumer applications. What the proponents mean is that applications should look like the ones that run on smart-phones and tablets.

While I appreciate the need to re-engineer the user experience of enterprise software, I am beginning to wonder how much of the discussion is really only a marketing or promotional veneer for some people. What I have not seen covered or appreciated are the deep structural issues that differentiate enterprise and consumer applications.

Let’s first accept that the differences between individuals and business matter. Individuals are like a single cell, whereas a business is like a complex organism. A business is a highly complex society, with rules and practices, as well as a body of knowledge made from the contributions of many people. An individual does not have the complexity or the rules but does have a body of knowledge.  How that knowledge is updated is also an important difference. Individuals modify it implicitly through the natural and adaptive process of learning. Businesses have to do it explicitly through periodic strategy reviews and training sessions.

When new or different software is introduced to a business, people not only have to learn how the software works, they also have to understand how it fits into the other processes and operations of the business, so they have to be taught how the software applies in their specific case. The same thing happens for new employees; they just can’t be let loose on the software, they have to learn the rules and practices of the organisation and how the software applies to that.

Now let’s look at the differences between consumer and enterprise applications. All the consumer applications have been written with a single function in mind. This does not apply to enterprise software. When the early enterprise solutions were initially developed, they were done so with the purpose of enabling a specific functionality. There was software for MRP, others for accounting, etc. But over the years, organisations found it easier to use software that combined various functions, and modern enterprise solutions like ERP grew. Consequently, enterprise systems are now diverse, multi-functional and highly complex pieces of software. That presents a problem if you want to make them like consumer applications – it’s like trying to mix oil and water.

I’m not ruling out that a Zuckerberg-like person may one day create a revolutionary user interface and experience for enterprise applications. At the moment I just struggle to see how it can be done.

Approaches to selling enterprise software

In the last decade or so there have been a number of books written, and practices proposed, on how to sell enterprise software. It probably started with the grand-father of business sales techniques, the SPIN methodology. I went through that technique in order to sell a data warehousing solution. (SPIN was an acronym for Situation, Problem, Implication, Need-payoff).

Since then, I have been introduced to the approach of solution selling, mainly because Microsoft adopted that process, and more recently Jeff Thull’s books – The Prime Solution, and Mastering the Complex Sale – which I believe are a more realistic methodology for understanding how to sell complex products like enterprise software.

All these approaches seem to have one central assumption, that selling complex business applications is the same where ever you are. But arising from the sales discussions at SYSPRO’s international executive conference, I came to believe that there is no standard way of selling throughout the world, and that different cultural perceptions and expectations play a large part in the process of how enterprise software is sold.

Three brief examples:

1. In the UK, business software buyers seem to have arrived at a standard perception of the price per seat at which certain types software should be licenced. So talking about value of a product is waste if your price per seat is higher than the generally-accepted price.
2. The concept of not devaluing your product in the initial sales encounter seems to have gone out of the window in the US, where even the ERP mega-vendors are coming in at the early sales stage with significant discounts.
3. In Australia, where large trans-continental distances between a company’s customers and suppliers are common, it is not necessarily the whole product that has value, but certain functionality, like SYSPRO’s Landed Cost Tracking, has a much higher premium in terms of customer need than other countries.

It seemed like the only aspect that everyone was prepared to agree on is that people still buy from people.

SYSPRO conference in Cape Town

A few days ago I was privileged to be included in a conference that SYSPRO held for all its international executives and senior managers. The title of the conference was ‘Future Focus’, as the conference was primarily around the company’s future strategy, and as SYSPRO CEO and founder Phil Duff pointed out, the key to making strategy work is focus.

The conference took place over several days and in two locations around Cape Town. Initially, the sales and marketing people were at a hotel in Milnerton; then everyone came together in the Franschoek valley, about an hour out of Cape Town. I stayed at the stunning ‘Le Franschoek‘ hotel.

Here are some of my photos.

Table Mountain from Milnerton

Franschoek mountains from Le Franschoek

The conference venue - L'Ermitage, Franschoek

Le Franschoek view

If you want details about the actual conference, check the official SYSPRO blog – I’m sure there will be something there shortly.

Finally, a photo of some of the people I work with.

Members of SYSPRO Corporate Services

Implementing ERP more effectively

Part 2 of a series on enterprise information systems

Building a house on a solid foundation

This blog has been cross-posted on the SYSPRO corporate blog.

You can hardly miss it these days: questions about why Enterprise Resource Planning (ERP) projects hit problems, or worse fail, are appearing on many websites. I have seen many ERP implementations and thought I had some answers, but it was only after I had been involved in building a house that I could see the similarities between building projects and ERP implementations, and why we don’t see buildings collapsing in the same ways some ERP projects fail.

Eric Kimberling’s Panorama Group identified this similarity at the same time I was building the house. The critical requirement for construction is the blueprint; the drawings of what the house will look like, what its parts will be and how it will be constructed.

The problem with projects, especially complex ones (like a house or an ERP project), is how to communicate the varied components, interactions, hierarchies and responsibilities to all parties concerned. You need a representation that will capture all these elements in a way that is clear and easy to understand, even if you are not a professional in the field. This will ensure that the various parties involved can achieve alignment in terms of common understanding of business needs and technology capabilities.

You also need a way for the plans to develop as your ideas and perspectives evolve. When you start planning a house you don’t go straight into the details. You may have some thoughts (even a vision), but you need guidance from an architect on what is possible, feasible and within budget. So you start with drawings that help you decide on the appearance of the house, then move into the technical and architectural details, and finally the construction and engineering specifications.

Until recently there was no easy way for ‘ERP novices’ to see the business in terms of how it would look after an ERP implementation. But now, with the integration of business process modeling (BPM) and ERP, those visual representations (the drawings) can be done. For an ERP implementation, the functional requirements and business processes are like the rooms and materials of a house, and a business process model is the equivalent of an architect’s drawings. The Business Process Modeling tool can be used in the same way that you start a house with some initial sketches. It allows you to view the business from a high level to make sure executives agree with the ‘look’ before going into more detail.

This graphical way of representing an ERP project can replace the mountains of design documents that were the staple of past ERP projects. This pile of paper used to be the main documentation a business had to describe its strategy, plans and processes. The sad fact was that only a few people ever probably read them, and even fewer understood them.

It’s about time that “the big freakin’ requirements document must die”. What is needed is one tool which can capture scope at different levels in one place, which provides traceability between business requirements and IT capabilities, and which uses better means of communication to illustrate than the common legal-style text of many project documents.

If you are an ERP implementer, how did you experience communicating via traditional project management tools? If you’ve experienced an ERP project as a business user in the past, what did you think of the project documents that you had to use?

At SYSPRO, we now provide a tool that can replace the big project document, which is graphical and shows how integrated BPM and ERP functions: SYSPRO Process Modeling (SPM). Analyst Brian Sommer described the combination as “A Key Mid-Market Need”. With SPM we believe that our customers will get more value, and have a far lower risk of problems in their ERP implementation projects.

In the next part of this series: changing the system as business realities change.

Microsoft wins on the swings as well as the roundabouts

The saying “swings and roundabouts” is a British one that describes a situation where you can win and lose. I am using it here to point out that Microsoft’s combination of business divisions may be giving it advantages on both the traditional (Windows, server) as well as the Dynamics (ERP) sides.

What kicked off this train of thought was an article by Josh Greenbaum: The Realignment of the Enterprise Software Market: Oracle vs. Everyone, Microsoft in Ascendance, and Watch out for Infor. The article notes that Microsoft’s Dynamics division

… the former bastard stepchild of the Microsoft portfolio, is now becoming the poster child of innovation in Redmond. And Redmond is taking notice big time[.]

Dynamics is one of the smallest divisions in Microsoft, and I have discussed its problems in the past here, here and here, but the company now seems to have discovered a major advantage.

Dynamics is a great driver of product pull-through. Today, every dollar of Dynamics generates from $3 to $9 in additional software sales for Microsoft.

Note: the article mentions other points but my focus is the first one.

I know from a Microsoft partner perspective that product pull-through is one of those phrases that brings a sparkle to the eyes of Microsoft’s partner managers.

Does this mean that Microsoft is discovering the value of a wide eco-system? Greenbaum makes an interesting comment about Microsoft, in comparison to Oracle:

This places Microsoft front and center in a battlefield where it is deploying 21st century technology against an Oracle that fighting the battle as though this were still the 20th century.

Microsoft’s strategy seems to provide a whole range of “interchangeable, plug and play” components. In my opinion this is far better than the Oracle strategy which wants to control the full stack – from hardware, to database, application, and middleware.

I have thought for some time that the Oracle strategy of vertical integration is an anachronism since so many other industries have abandoned the practice. In effect, it is a throwback to a bygone era when IBM ruled the computer world in the 1970s.

I also wonder how customers would feel about putting all their computer ‘eggs’ in the Oracle ‘basket’? There is an advantage to having a single, strategic supplier, and a single ‘throat-to-choke’, but a small customer has very little bargaining power with such a large supplier.

Joburg City’s project failure record

Last year I wrote about the problem with the billing system that Johannesburg City Council had implemented. The project, a SAP-based implementation internally called Project Phakama, is in the news again for all the wrong reasons. According to one report, the project has cost the City over R800 million (over $100 million). The situation has reached such a bad state again that there was a report that central government was considering stepping in.

This is obviously a highly strategic and visible project, and it’s not uncommon for these kind of ‘heroic’ projects to have very public bugs. As I mentioned in my previous blog about this project, SAP had won a quality award for it, but has readers of Michael Krigsman’s Project Failure blog will know, the software is only one part of the issue.

In the ‘Billing Crisis’ news report, an opposition spokesman says the problem is that it is a complex system

“…and people have not been properly trained for the system”.

In another news report:

‘The city’s head of finance, Parks Tau, said implementation of the IT project had been completed and that problems with it were “interface-related”.’

So here we have two issues which need to be addressed – people-related, and external systems.

On the one hand, the project owners (City officials) seem to be saying that the project is nearly done. On the other, they don’t appear to have the complex IT project experience to know “What ‘Done’ Looks Like”, to use Glen Alleman’s phrase.

SAP is fortunate that it is not their name that is being publicly criticised, as has happened in other municipal projects.

One thing I am glad about – that I am not the vendor or implementation partner project manager on that project.

Update #1: SAP have distanced themselves from the project – ‘Don’t blame us‘

Update #2: The story behind the project chaos is revealed – The connections that disconnected Joburg

From the old – It’s not the software

This is the first of some blogs I will be repeating from my previous site - this blog from January 2006.

Anyone who has implemented business management software – whether ERP, CRM, BI etc – knows that the success of the application doesn’t depend on the software, but the way it is introduced and adopted in the organisation deploying it.

I know of two companies that deployed the same ERP system from JD Edwards, on the same hardware, at the same time, but one became a reference site within 2-3 years whilst the other was still struggling and complaining about the system.

A new article from MIT’s Sloan Management Review (subscription required), has the following comments:

“New tools must first be integrated into a system that’s already in place. It is important to remember that tools are embedded both within the organizations that deploy them and within the tasks the tools themselves are dedicated to performing. Moreover, each organization’s approach to how people, processes and tools are integrated is unique — a result of formal and informal routines, culture and habits. All too often, companies spend millions of dollars on tools that fail to deliver on their promise, and the culprit is typically not the technology itself but the use of the technology.”

… as my kids would say, ‘Duh’!

Kinect: the next business user interface?

I am not a gamer so the technology in that area is not something I follow, but I’ve been seeing lots of comments about Microsoft’s Kinect appliance so I looked it up on the Microsoft website. What astounded me was the user experience the Kinect provides, both physical and vocal.

In the past, computer technology came into the business world first, then was adapted into the personal world. With the Kinect though, I reckon the process will be reversed, the user interface (UI) and user experience (UX) that the Kinect introduces will move into the business world.

Let’s face it, the UI of business computing hasn’t changed much since the 1980s with the advent of the graphical user interface (e.g., Windows). In the ERP implementations I’ve seen over the years, it’s learning and adjusting to the UI that the average user can often find difficult. But if they had a UI that just required voice commands, or hand gestures and movements, wouldn’t that make using the system easier?

A story out yesterday announces that open source interfaces for the Kinect have been given approval by Microsoft, who probably recognise the potential the device has.

I’m sitting here frustrated that I might have come across a possible ‘big thing’ in business software but don’t have the technical expertise to execute on it.

Hospital information systems

Part 1 of a series on enterprise information systems

This is the start of a series of blogs looking at various ways enterprise information systems are used

Hospital systems are not an area I thought much about – until I had the chance to experience them when my son was admitted to a private hospital in Johannesburg for an operation.

To start, the process of admission took a long time with multiple forms to sign and authorise, and foolishly I thought the process after that would be straight-forward. When we got to the ward, however, there was even more paperwork to complete, some of it involving duplication of other paperwork, and this took even longer than the admission process did.

I am aware that hospital information systems are a major drive by some advocates of improving information management and flow in hospitals. But I am married to a doctor and when I have asked her why there is so much paper in hospitals, her response is that doctors need the information in that way. What is provided on paper has evolved over time so that the information doctors and nurses need is in a way that is easy and quick to understand and interpret.

The other aspect of the medical world that is now apparent to me is how expensive a relatively minor operation has become. Fortunately my medical insurance covered the operation but they provided reports on the various costs, and I was amazed at the expense.

If new information systems are to be introduced into hospitals, they cannot be a factor that increases costs further, or give doctors and hospitals a reason to charge more. Eli Goldratt argues in the Theory of Constraints, and in his seminal book, The Goal, that a business benefit is only real if it does at least one of three things:

1. increases throughput (the rate at which revenue is generated);
2. reduces inventory;
3. reduces operating expenses.

In a hospital, Item 1 is constrained by regulation and medical practice. Item 2 is one area for improvement considering the cost of medical material these days, but it would be Item 3 that new systems would have to be focused on.

Where in the hospital process chain can operating expenses be reduced? One area might be administration-related costs – all that paper pushing. So could hospital information systems reduce operating expenses by focusing on information delivery, its content and context? If information on a form was captured once, then other forms could be generated from that information.

It did occur to me that all the paper forms that I saw had to cost the hospital something, and storing it must have a cost. However, I could not personally justify a new system that, say, used tablet computers (like the Apple iPad) to record and display information if that cost was more than the paper processing and storage cost.

The same applies to enterprise systems in other businesses: what are the real business benefits of a new system. I will be getting to that issue in a later article.

For benefits that are less easy to quantify – such as improving risk or governance, information visibility, or alignment of operations and strategy – the difficulty is to collectively decide and agree on the assumptions that make up these benefits.

What is your experience of assessing business value of an enterprise system? Specifically for hospitals, I would be very interested to learn how new systems have performed in terms of the Goldratt measures.