/

 

Our products:

Storga

PackInTouch

Pliant

 

Think

 

The associates

Contact information

Contact

Solow's paradox

In 1987, Robet Solow, an American economist, highlighted the following paradox: we do not find the expected spectacular productivity gain linked to the progressive computerization of companies in the years 1980-1990.

This initial finding has led to many further studies, and many explanations. The paradox itself became less evident over the next two decades.
However, a dominant trait emerges from the whole: business productivity is not the result of parameters independent of each other, but rather of a clever alchemy between multiple factors. In particular, productivity gains are only seen in the event of concerted action between the computerization effort and the organization (or reorganization) of work in the company.

What are the elements that impact productivity gains linked to computerization

These cultural elements, driven mainly at the macroeconomic level, have led us to ask ourselves the question: in the few SMEs that we know, what has been and what is the effect on the productivity of computerization?
We observed two main lines:

   •   

On the one hand, productivity gains are limited by the fact that IT is generally centered on the core business (orders, planning) and that ancillary activities remain confined to not very productive office automation. However, if taken individually the ancillary activities have a negligible effect on the overall productivity of the company, their number means that in total, they are collectively a key and neglected factor.
We see that too often the business manager has a vague vision that he tends to group together under the term 'administrative red tape'. However, if the activities that are grouped together under this name are in part the result of French administrative red tape, on the one hand this does not mean that the company has no other solution than to suffer them, and on the other hand, it is, much more often than one perceives intuitively at first glance, co-responsible for the problem, not even to mention the weakness of the customer-supplier dialogue with a view to a global optimization at the level of the plugged.

   •   

On the other hand, the productivity gain that IT could bring is largely eroded by the additional costs and burdens induced by this same IT: manual copying of data, maintenance of unnecessarily complex systems, de-involvement linked to users' feeling of powerlessness. facing their tool.

Once these observations have been made, what are the possible strategies?

Outsource

One of which we have seen great success since the arrival of web 2.0 is application outsourcing, or Saas to use the jargon of the moment.
It is in fact focused on reducing the cost of maintaining unnecessarily complex systems.
However, it appears to us as a short termist approach; a bad solution to deal with a real problem that is internal IT that no longer gives satisfaction.
Indeed, outsourcing does not in any way simplify the problem of data sharing, and therefore risks only aggravating the problem of manual copying of data between applications.

Then, the competitive advantage of SaaS applications is largely linked to the fact that they are very recent, so they have not yet had to deal with long-term maintenance issues. However, an application that must be shared among 1000 users will ultimately be much more complex to maintain than 1000 separate applications, since the need to evolve the application to attract new customers will conflict head-on with the need for stability of existing users as soon as the application is at all critical for their activity. We are already seeing the first signs of this with older SaaS applications such as Gmail.

In addition, the last 30 years have seen a very significant reduction in the cost of computer equipment, so that nowadays a server with the best level of reliability costs only 1000 €.
It is therefore clearly on the side of costs linked to application complexity that savings should be sought, and not by outsourcing the equipment.

Finally, the decision-making process linked to an outsourcing seems to us unsuitable since the objective is a gain in productivity rather than a simple headlong rush.

Changing the decision-making process

As we have just seen, the decision to outsource is often (too often) taken a priori, as a (too) obvious response to IT that no longer gives satisfaction.
Then, the standard process for selecting the provider to whom we will outsource is similar to that for selecting a turnkey application provider:

   •   

establishment of the specifications,

   •   

functional comparison and the cost of deploying each solution,

   •   

deployment.

The problem is, organization is inherently iterative, in small steps, and continually challenged by environmental changes, where the process just described involves one big step without going back. .

Most users will not be able to 'model' their requirements on paper. They need to do to realize. Even less will they be able to anticipate with precision the consequences on productivity of a compromise between what they asked for and what is proposed at the level of the existing application studied.

In the end, if the objective is productivity, the best computer system, it is not at all the one that corresponds to the idea that we have a priori of our activity, therefore which presents the best game. initial functions, but the one that costs the least to change when you realize that what you want has changed.

Strengthen management capacities

Now that we have denounced the mirages of the moment, let's describe what seems to us the way of the future, and therefore interests decision-makers who want to be in the long term.

For this, let us ask ourselves the question of the role, and therefore of the skills and tools of management in a company. Let us return for a moment to the technological environment of companies of the XIXth century, a period during which productivity exploded.
At that time, no computers, but already a rational organization, with order forms, cards, files, etc.
In this environment, the role of management is to organize the work of operational staff: setting up forms, procedures, etc.
What company at the time would have had the idea of \u200b\u200brecruiting illiterate staff and adding a service of scribes specializing in calligraphy?
In short, at that time, the management mastered writing, without being a specialist.

Let's go back to the present time, or to the near future, where the organizational support of the company is becoming digital, computerized.
Common sense dictates that management must be able to set up computerized procedures, without being an IT specialist.
Returning to the Solow paradox at the beginning of this article, we can see that:

   •   

office automation is not an effective organizational tool on a company scale, as the files were in the 19th century,

   •   

database type applications remain technically complex which requires specialists (not to mention their problem of adaptability).

In short, the problem comes down to providing IT tools adapted to the management of companies. However, to achieve this, it is necessary to return to common sense, excluding two extreme attitudes.

The first is that the right IT tool for management is one that can be learned intuitively, without investment in learning.
This is not the case with writing.
What would have happened if in the 19th century, we had posited that writing should be sufficiently intuitive not to require specific training? Well we would have built an impoverished writing, which in the end would not have given the productivity gains that we have seen.

The second is that, conversely, we can allow ourselves to base a company's organization on tools so complex that they require a lifetime and a whole team to be mastered, so that management loses the capacity for autonomous and rapid action.
If we had done this in the 19th century, it's a safe bet that the productivity gains obtained over 1 century would have taken 5 or more.

For further

Statement on Wikipedia of Solow's paradox

Article dealing with the Solow paradox, and summarizing the book 'Wired for innovation'