Solving unique problems with standard solutions

March 02, 2016

Standard systems: a good way to lower your system management costs? Definitely, as long as you do not customise or rebuild the standard system. But is it possible to compete and be unique if you build the business around that standard system? Probably not.

“System support is a critical factor for the success of our business. We have a great deal of business and organisation-specific processes. We operate in an intensely competitive market environment, which requires that we constantly strive to become more efficient. For many years we've been building proprietary system solutions for our business and organisation-specific processes. These systems are now getting long in the tooth and very "expensive" to maintain, so we now have a major need to update these systems. So we've kicked off a project with the objective of replacing these systems with standard systems.”

I quote verbatim from a conversation I had with someone recently. Unfortunately, it's hardly an unusual attitude/notion to believe that it would be better and cheaper to use standard systems. But what supplier of standard systems out there do you think develops systems to support the unique processes specific to your organisation? Or, to put it in business terms, what kind of business do you think would develop a product with such a limited target group in mind? And yet this belief remains quite common, even though more and more businesses are beginning to understand the opportunities to be had by developing their own systems. It goes without saying that there are lots of great standard systems available that support a variety of processes, yet the common characteristic of all these systems is that the processes are more or less the same across most organisations.

Anyone with experience in and knowledge of systems development knows that you are constantly learning as you go along.

To draw on an example that has received a lot of attention already in Sweden and which some might view as tired and banal, but whose lessons are still highly relevant today: The Police’s PUST Java* v. PUST Siebel** Important to point out for the purposes of this blog that neither I myself nor those of us at Valtech were part of the project; on the other hand a great deal was written about the project about a year ago, both by people with access to the project, by users (Police) and by those who tasked with investigating the outcome. How is it that they did everything right – only to do everything wrong afterwards?

PUST Java started with a question: “Why aren't we seeing any police officers out on the street?” One of the explanations was that the police officers were stuck at the station wrestling with a mess of an IT landscape. PUST Java began by putting together a team whose task, working in close cooperation with the users (the Swedish Police), was to map out and identify the users' daily workflows. Before integrating anything into the system, they started by building prototypes that were tested in the field to make sure they worked as intended. PUST Java is a perfect example of a system/business project that was designed according to the principles of of Agile/Lean and Design Thinking. The system was a success; the handling effort required for certain everyday crimes was reduced by up to 85%.

Most organisations, hopefully, would have continued developing the existing PUST Java platform. In this case however, a new initiative was pushed through after the system had been in operation for only a few months. The idea was to implement a “standard system strategy” with the objective of reducing system maintenance costs. The result was to turn PUST Java into PUST Siebel with the objective of “migrating the same functionality” over to Siebel in order to reduce costs. The outcome was disastrous. Which shouldn't come as a surprise, considering that Siebel is meant to be used as a CRM system (Customer Relationship Management). It would be interesting to learn how they came to the conclusion that the work done at the Swedish Police was consistent with Siebel's approach to CRM. Evidently, Siebel has been sold to police authorities in other countries, including Finland, but they appear to use Siebel for completely different purposes, such as their weapons register. Like I said, I personally do not have any insight into the project beyond the information that is publicly available, but this is a good example of how badly things can turn out when you try to solve a unique problem with “standard” solutions.

The Swedish Police's PUST Java v. PUST Siebel is a clear example of the difference between how differing visions and differing execution impact the result. The example clearly illustrates what happens when you try to solve unique problems with standard methods, and what happens when the primary objective is to lower system administration costs.

In order to cater to the demand for business-specific processes, standard systems can be customised, i.e. making it possible to convert/adapt them “a little bit”. As a purchaser in other words, you sign an agreement with a vendor, or more likely with a systems integrator, as work will be required in order to implement all the customisations. The agreement governs the licensing costs and annual update costs for a standard system that you will presumably be converting or adapting “a little bit”. The thing a lot of people miss however, is the actual cost/TCO (Total Cost of Ownership). For example, it won't be possible to integrate upgrades into a converted standard system – at least not without considerable effort. And every time you introduce new conversions and adaptations, the system becomes that much more difficult to maintain and renew. In other words, the result is higher system administration costs, when the objective was just the opposite.

Another interesting example comes from the Swedish Armed Forces and FMV (the Swedish Defence Materiel Administration): while the Swedish Armed Forces have invested huge amounts of money and time in their SAP project, FMV is pursuing a completely different strategy. FMV has chosen to use smaller components to build a system that supports its operations, and not vice versa. It is easy and inexpensive to make modifications and upgrade the system – I won't comment on whether the same will hold true for the Armed Forces' SAP system. FMV has built a system for its organisation that is also cheap to administer/further develop (and which enables rapid response to changes).

Change is part of the work

It's true that conversions or adaptations of standard systems are behind many system breakdowns and situations where project costs spiral out of control; but the approach and methodology used in the project are another important reason, too. There is still a tendency to rely too heavily on feasibility studies and detailed requirement specifications. Wanting to make sure of what they are buying, organisations turn the requirement specification into a table of contents where you just go through in order and tick off the items. Anyone with experience in and knowledge of systems development knows that you are constantly learning as you go along, and that new knowledge paves the way to opportunity. If your focus is just on ticking off items in the “table of contents”, these opportunities never come to fruition. Although more and more organisations are starting to implement agile methods such as Scrum, these are still just methods. To actually be Agile or Lean involves more than just implementing a method. It's about implementing a new outlook, a new culture. In many cases it involves changes/adjustments to the organisation's “DNA”. But even that is not enough. The technology itself also needs to be agile/lean. It’s about:

• acting on the basis of validated learning instead of assumptions and qualified guesses.
• change being part of the work
• releasing in small and frequent batches instead of large, infrequent ones
• budgeting for a team instead of for a table of contents
• having an objective and vision in mind, with a focus on creating measurable value
• setting up a technical architecture that enables rapid change
• us working as part of a team, not in different silos or groups.

There are numerous examples of systems and technology actually having changed an organisation's operating conditions, and in some cases even having “revolutionised/reformed” entire industries. But what do we find behind the success stories? I would say that there are two main components:

• The approach and culture in terms of methodology: they work in an insight-driven way, releasing things constantly while rapidly harnessing new knowledge and new insights – it's not a project, it's a state of constant development.
• They’ve built a “tailor-made” system by drawing on a variety of components to create a flexible and agile system architecture, a micro-services architecture that enables ongoing modification/improvements. The system is part of the organisation.

For processes that are unique to the business, you have to start by realising that system support for these business-specific processes is part of the organisation's core operations. So instead of trying to convert a standard system, what you do instead is to build a system comprising a number of small, well-defined components that interact with one another using a well-defined protocol. This way you can swap out individual parts over time, thereby reducing your risk and cost. Simply put, what you get is a solution that is prepared to handle change, or rather: continuous improvement.

Just as the development of your core operations does not have a final destination, nor does the development of system support for business and organisation-specific processes have a preset final destination.