Home Career

In some areas of automation and the use of information systems, there is a limited number of options available for establishing a relationship with a supplier. Relationships can range from the sale of standard, off-the-shelf software packages to the provision of full outsourcing. We shall call this the "relationship spectrum".

The relationship with the supplier changes as we move through this spectrum. In addition, the methods for selecting suppliers change as we move through the spectrum.

Packages

This is one end of the spectrum.

The characteristics of the sales situation are as follows.

Detailed level of specification

You need to describe the characteristics expected of the software and hardware systems before you make a decision on purchasing them. This may mean that you will need to specify some parts of the systems in great detail, to ensure that the standard package can provide them.

No ongoing relationship

The relationship with the supplier is unlikely to be ongoing.
Even if it is ongoing, that will usually mean that you will receive standard upgrades and fixes from time to time: there is unlikely to be any closeness in the relationship, and it is unlikely that the supplier will be aware of your needs beyond the end of the selection process.
This is especially true in the packaged software business, where the supplier's sales people will respond to your request for proposals and sign up the business, and will then hand the relationship on to someone else, such as their help desk. The people on the help desk are unlikely ever to see your request for proposals or their company's response to it. So the relationship, even if it is ongoing, will not differentiate you from any of their other customers.

Low, sporadic user involvement

It is highly likely that your users will be involved in the selection process, simply because of the high level of specification that may be needed. Where there is a detailed specification it is always useful to have the users involved, so that they can explain some of the requirements and ensure that the solutions match the needs.
In reality, users are often involved only during an initial round of requirements definition and a final round of acceptance testing.

Rigorous acquisition process

The process for acquiring packaged solutions is usually rigorous. In order to obtain a wide view of the market, you are likely to go through a registration of interest (ROI), request for information (RFI) and request for proposals (RFP) or through a registration of interest and invitation to tender (ITT) procedure.
Each stage of these procedures involves the setting of evaluation criteria before responses are received, and care must be taken throughout that a single provider does not offer a solution that cannot be appropriately and competitively evaluated. In other words, the original requests issued by you must anticipate all likely innovations from providers. This can be a lengthy and tedious business.

Package customization

It is possible, however, that you may have additional features added to a software package.

It is worth looking at what defines a "package", as the definition is sometimes less clear than it was a few years ago. It is clear that Microsoft Office is a package and that Oracle is a platform. It is possible to use Office without having any additional features added to it (making it a package), while Oracle will always require programming to produce a software application. It is, of course, possible to write macros for Word, and these may be regarded as additional features. They do not, however, detract from the definition of Office as a package, as it can be used "straight out of the box".

The split between a package and a platform was emphasized by SAP R/3. Although the SAP applications are sold as a set of modules that will perform specific tasks (and might therefore be regarded as a package), there is little doubt that a customer will always have to customize these modules for them to operate successfully for that customer. Therefore, based on the definition that a package can be used "straight from the box", R/3 is a platform rather than a package.

We shall look at the characteristics of custom developments additional to packaged solutions.

Detailed level of specification

The detailed specification will usually have been inherited from the package selection process. Most custom developments on packaged solutions are needed because there was no packaged solution that provides the required features. Once a decision has been made on the package to be acquired, the need for the feature remains.
The high level of specification used during the package selection process is likely to be enhanced for the custom development. The fact that the feature was not included in the package will suggest to you that great care must be taken over the definition of the additional feature.

Evolving relationship: close to distant

Relationships with software developers are usually in two phases.
During the development, the relationship is likely to be close but short term.
Following the development, when the software is under maintenance, the relationship is likely to be distant but continuous.

Low, sporadic user involvement

As with the selection process, your users should be closely involved. Again, as with the selection process, users are usually only involved in requirements definition and in acceptance testing.
It is worth noting that, even for their minimal involvement, through requirements definition and acceptance testing, users are often not the people in charge. Users are sometimes persuaded by project managers that they should perform these activities according to a specific method within a specific time period. The users in these situations have no control over the method or the timing. Often they do not understand the method.

Objective acquisition process

The process for customizing packaged solutions is usually less rigorous than the process for acquiring them. Much of this has to do with the fact that the provider tends to be more in control of customization than acquisition. There are usually several providers who can deliver a package; once a package has been chosen, there are usually far fewer providers who can customize it.

Facilities management

Facilities management (or "FM") is the arrangement by which the customer retains ownership of the assets - the facilities - and the facilities manager manages them on the customer's behalf.

Many information systems are "facilities managed", ranging from data centers packed with mainframes to a small company's PCs and networks. There are many advantages to facilities management, particularly when specialists are required intermittently and at short notice. Network support specialists, for example, can be shared by a facilities manager's customers, rather than each of those customers having to employ a full-time specialist for part-time use.

Under facilities management, the customer retains ownership and all of the risks and responsibilities that go with it.

Medium level of specification

There is likely to be detailed specification of the systems and services to be managed by the provider, in terms of their inputs and outputs, without detailed specification of the way in which those systems and services will deliver the outputs.

Evolving relationship: close to distant; tentative to trusting

Relationships with facilities managers are usually in two phases, although these are markedly different from the relationships with software developers.
Early in the relationship, the relationship is likely to be close (as for software development). The reason for this closeness is that the two organizations need to learn more about each other in order to work together effectively in the future.
As time passes, if the relationship is successful, the relationship is likely to become more distant, if only because the periods between reviews grow longer. The relationship can operate successfully in this way because trust has been developed between the customer and the provider, and they no longer have to work in close proximity to be able to anticipate each other's needs and to work towards achieving them.

Medium, continuous user involvement

Although the need for user involvement is about the same as for package selection and package customization, users do seem to be more involved in the selection of facilities managers. To some extent, this is because the contracts involved are different. With a purchasing or development contract, the provider will usually ensure that it bears no risk if the users become dissatisfied after the package has been purchased or the customization implemented; with facilities management, the provider has to ensure long term user satisfaction in order to avoid termination of the contract.
Package vendors and applications developers may label this comment as "cynical". My view is that it is cynical of vendors and developers to imagine that they can influence a customer's management to purchase further software or systems from them when that customer's users have become dissatisfied with their earlier "offerings".

Objective acquisition process

There is usually a formal RFP or ITT process for acquiring facilities managers.
There is a need for trust in the ongoing relationship between a customer and its facilities managers. This trust underpins the reliance that the customer has on the ability of the facilities managers to continue to deliver systems and services. Because of this, many consultants prefer to use acquisition methods that involve a greater degree of subjectivity than the RFP and ITT processes, which are both highly objective.

Contracting

With contracting, the responsibility for performing an individual task is passed to a contractor. The assets required to accomplish that task can continue to be owned by the customer or they may be provided by the contractor.

Facilities management and contracting can operate together. A facilities manager can maintain a company's computer systems while contractors operate those systems.

Facilities managers usually manage non-human assets on behalf of their customers; it does not matter to the customers who actually manages the facilities.

Contractors usually are human assets; it is often important to the customer that individuals, or at least people with specific skills, work on their behalf.

Medium to high level of specification

The systems and services to be provided are usually defined in terms of:

1. specification of outcomes, rather than inputs and outputs; and
2. service level agreements.

It is true that service level agreements are usually in place for facilities managers. For facilities management, the emphasis in SLAs is often on the escalation procedures for when things go wrong. The SLAs for facilities management are oriented towards achieving at least a minimal level of service for the "systems" and "engines", rather than towards achieving a high level of consistent service in the production of outcomes.

Evolving relationship: tentative to trusting

Relationships with contractors have to pass quickly through the stage of a tentative relationship to the long term stage of trust and confidence. The longer that a tentative relationship exists, the less will the customer be inclined to "let go" of the day-to-day supervision of the contractor's performance. There is little point to engaging a contractor to provide outcomes for you and then building a whole new section devoted to contractor performance monitoring: you have to be able to rely on the contractor.

Minimal, continuous user involvement

Most user involvement will be communication with the contractor, and much of that communication will involve the service levels that the contractor is expected to achieve.
As such, the user involvement with the contractor will be ongoing and it will not require a great deal of the users' time, provided that the service levels are being met. Despite this minimal, continuous user involvement, such involvement as there is may be critical to the customer's business.

Objective acquisition process

Most contracting is subject to a objective acquisition process. Often, contracts are placed following a tendering process.
When consultants have been known to advocate "revolutionary" methods of acquisition, then they can be expected to argue against the tendering process for contracting. I have spent much time and effort in promoting such acquisition methods, and my answer to anyone asking whether they should use an "objective" procedure, like tendering, or a "subjective" procedure, like preparing a memorandum of understanding, is: it depends.
If you intend to contract out services where it is easy to define the service levels in concrete terms, and where there is unlikely to be a need for you to seek ideas and innovation from the contractor, then an objective procedure will work effectively. This is true of many business sectors, such as local government refuse collection, and in many business functions, such as finance and administration.
Where you have a need for input from the contractor which is more than straightforward service provision, then you need a closer relationship than an arms-length communication about monthly service level statistics. You may then wish to consider a subjective procedure for selecting your provider.

Sourcing

There are now two forms of "sourcing", which are best explained from an historical view.

Originally, there was "outsourcing". This meant that you could take an entire function of your organization, such as information systems or records management, and "sell it off" to an external provider. The external provider would then provide services to you to produce the outputs required from the functions.

In many organizations, outsourcing failed. The increased levels of service were not achieved, and costs rose. A large number of organizations "bought back" the departments that they had outsourced, and looked for a better way. At the time, that "better way" was often retaining the departments and their functions in-house. Sometimes, the organizations have tasks provided by contractors or resources maintained by facilities managers.

With the coming of business process re-engineering in the 1980s, many organizations understood what had gone wrong with their attempts at outsourcing. One of the major problems had been that they had outsourced functions rather than processes. Outsourcing could now be approached on the basis of a process map rather than an organization chart.

Some of the organizations who have been most successful at outsourcing their processes have done so as a result of BPR.

It was at this stage that the reason for the failure of so many attempts at outsourcing information systems became apparent. In many organizations, IS supports a range of processes. The traditional pattern of a wholly outsourced IS department could produce problems with the priorities of the various processes that IS supported, leading to conflict and to competition for budgets and resources.

The thinking of many such organizations, for whom outsourcing of IS had failed, was that they should individually "source" those parts of IS that supported each single process. It might be that all of this sourcing was placed with the same service provider: the point was that each business process would be supported by its own sourcing contract, independently of the other processes within the organization. This has become known as "selective sourcing".

Both "full outsourcing" and "selective sourcing" can be called "outsourcing" or "sourcing", and they are both performed by "outsourcers".

It is, of course, up to you to decide whether outsourcing or selective sourcing is an appropriate solution for your needs.

The characteristics of outsourcing are

High level of specification

As with contracting, the services are usually defined in terms of:

1. outcomes; and
2. service levels.

Close, trusting relationship

An easy way to describe the kind of relationship that you need with an outsourcer is to consider some of the reasons for choosing that outsourcer in the first place. One of those reasons was likely to have been the fact that the outsourcer provided the services for other clients, so that the outsourcer would be able to spread overheads over a number of clients. Other reasons were probably that the outsourcer could offer innovative solutions and world class capability: the outsourcer's investment in these requires funding from a number of clients. It is clear that some of the reasons for selecting an outsourcer depend upon that outsourcer having other clients. Also, that outsourcer must be expected both to expand its client base and to provide additional services to existing clients.
It is essential that an outsourcer maintains a continual communication with its clients, so that the outsourcer's expansion of its clients and services will not damage the service it provides to its existing clients. This requires an open and honest relationship between the outsourcer and its clients.

Minimal user involvement

With outsourcing, user involvement becomes even less than with contracting.
The main reason for this is that the organization will be interested only in outcomes from the outsourcer rather than the outputs of a contractor.
In some instances, the focus on outcomes has been translated from outsourcing into contracting. An example is in flood management contracts for local authorities. A few years ago, these had a high degree of specification of all the outputs that a local authority would need to monitor the contractor's work in detail. Recently, there has been a move to enter contracts based solely on the outcomes that the local authority wants to achieve. Provided that these outcomes (or "deliverables" or "end products") are delivered, the authority will not require detailed monitoring of a contractor's performance.
A move to outcome-based contracting can often be perceived as riskier than a move to outsourcing, and many executives have taken brave decisions in the light of internal opposition to adopting it.

Subjective acquisition process

There is an increasing realization that a subjective acquisition process is more likely to be successful in acquiring an outsourcer than an objective one.