The limits of traditional ways to build a digital organization
Statement n ° 1: we cannot escape programming
The diversity of organizations, even within the same sector of activity, is far too great for purely parametric solutions to be efficient. This is all the more true as there is in any organization a need for permanent readjustment, either to adapt to changing customer needs, or to adapt to changes in people. Choosing a turnkey solution means in fact that it is the processes that we will adapt to the software, and it is now archaic from a management point of view.
Statement n ° 2: complexity must remain under control
For the perpetual evolution of the organization to be truly possible, the necessary programming must remain simple enough so that it becomes the tool of executives and not the business of specialists. To meet this constraint of simplicity, the code must be efficient (or minimalist) and local.
•
|
Efficient: when in current programs we have 90% of lines used to operate the user interface, and 10% used for 'core logic', we are close to the target.
|
•
|
Local: it is necessary to be able to ensure isolation between real activities. The good property that we ask of the computer system is that when we study a real activity, we can find and understand all the code related to it in a few minutes.
|
Storga meets these requirements, unlike the latest languages \u200b\u200b(such as Java or Swift), relational databases, non-relational databases other than Storga, new smartphone platforms, or even simple migrations of services to the Cloud¹.
In the rest of this article, we will review the various traditional strategies for building a digital organization system and show why their limits are not linked to the defect of the particular software chosen, but to the fact that the underlying structure does not respond. not to the above specifications.
¹ Conversely, when the digital part of an organization is supported by Storga, it can be deployed on corporate servers, in the Cloud and on smartphones.
Bureautics
This is often where an organization starts today, because it is the easiest way to start.
Another element that favors this path is the illusion of control that it brings to each user of the system. He does not need to contact the IT department to set up the IT part corresponding to a new project or a new activity.
However, the multiple associated problems appear quite quickly:
•
|
Managing a large volume of data with office automation is problematic because the concentration to obtain the reporting is largely manual.
|
•
|
The more we integrate it and try to automate it via macros, the more the system tends to become unstable. The explanation is twofold: On the one hand, office automation applications are much too complicated to be able to be stable in terms of withstand load and evolution over time. Comparatively, a database server is something very simple. On the other hand, building reporting from office documents is much more complicated than building the same reporting from data in a database.
|
•
|
Finally, such an infrastructure promotes behavior where everyone 'makes' their organization in their own corner, and copies all the data that interests them there, to the detriment of collective optimization. It is the counterpart of individual freedom of organization which too often, which for lack of consultation and sufficient reflection, generally results in mediocrity.
|
Very simply, the word processor was created to do the secretarial work, and the spreadsheet for the financial modeling. Believing that we can divert them and use them as organizational tools is an illusion. Let me explain. Building an organization on the basis of office tools is more difficult than building it on the basis of tools originally designed for the organization. However, the great motivation, not always avowed of some users to keep their office-based organization, is not to have to learn something new, therefore to save effort, which is neither silly nor reprehensible in itself. However, to believe that these same users will put in the extra effort required to effectively wear such a system is just to hide the facts. The real thing is that they will be satisfied with mediocrity.
The big mistake at this level is to believe that it suffices to put one or more crutches to the system, for example via sharing in the Cloud, for the system to become efficient. This makes it possible to apply office automation to a common workspace, just like servers in the 1990s, but it does not solve the problems with reporting and the difficulty of automating on such a basis.
In short, and very brutally, an organization based on office automation tools can only be mediocre.
The assembly of existing solutions
To understand the problem, you have to change your angle of view, and put yourself in the shoes of a developer. To create and sell a business solution, we start by looking at how a certain number of organizations work, and determining the common or largely common elements. In fact, we are developing a virtual company, which would be a bit of the median of what we have seen, and we are developing software to meet the needs of this virtual company. By the way, we try to make as many things as possible configurable, adaptable. Then, we start selling to the first customers, and we very often notice a gap between the initial virtual company and the real need of the new prospect, so we add functions, and we generalize existing functions. The problem is that in this little game, the general complexity of the code explodes very quickly, so after a short time, we are faced with the following dilemma:
•
|
Either we continue to enrich the common software, and then on the one hand its development cost increases very quickly, and moreover the start-up cost (configuration) for each new customer increases.
|
•
|
Either we freeze more or less the whole, and in this case we quickly arrive at a software that responds poorly to the real needs of the customer, and the rejection rate (the software is abandoned a few months after its commissioning) increases, at the same time that the overall productivity in the cases of non-rejection decreases.
|
So the classic way to get out of this dilemma that arises very quickly is to allow customer-specific developments, which will not be part of the general code. However, we immediately fall into a second dilemma:
•
|
If the common code is limited, then each new customer will have a lot of adaptations to make, and that makes the commercial approach difficult.
|
•
|
If the common code is extended, it is the maintenance of the specific modifications that will pose a problem, because with each new version of the common code, the specific code will have to be adapted to a common system which is unnecessarily complex from the point of view of the target organization. , since it only uses part of it.
|
Then, a third dilemma arises: Do we base our organization on a single super software (ERP) to manage all the activities of the company, or do we use multiple software?
•
|
In the case of a single software, the previous dilemma of either the software is very complex, therefore very expensive to maintain, or it is ill-suited to the actual functioning of the target company, will arise with even more severity.
|
•
|
In the case of multiple software, it is the interconnection problems that will prove to be prohibitive. Indeed, we will first of all have a technical difficulty in circulating information between multiple databases that are not necessarily identical, in particular when the traffic must be bidirectional, but this is still only the visible part of the data. 'ice berg: the insoluble problem comes from the difference in modeling, from the very organization of the activity which will not correspond in the different software. Basically, a box in software A will not necessarily correspond to a box in software B. A human, thanks to the flexibility of his cognitive abilities, will more or less manage to make the connection, to establish approximate equivalences, but certainly not an automaton. In the end, we will find the syndrome of office automation: a lack of automation which annihilates the gain in productivity and working comfort that computerization should have brought.
|
Classic specific development
Specific development is the promise of being able to set up an organization that corresponds well to the needs of the target company. Yes, but ...
The first problem is that to launch a classic development, you have to establish specifications. However, in practice, you only really know what you want when you have experimented a minimum, so not when establishing the specifications.
Then, a specific development, that supposes to maintain the code in time, and we see in practice that after a relatively short time, the maintenance of the basic activities of the company (flow of orders) consumes all the resources allocated to IT, to the detriment of ancillary activities, insignificant one by one, but numerous, so that the mediocrity of the computerized organization of these activities very significantly affects overall productivity. In other words, an organization based on specific development is never complete.
Finally, and this is the most problematic, specific developments do not hold up well over time to three types of changes:
•
|
The activity is changing to better meet new customer expectations. Basically, specific development will push the company to become self-centered to the detriment of customer relations.
|
•
|
The people who carry out the activities change. This is the point that is often the most misunderstood and overlooked. When you replace a human by another in a given position, the new person does not have exactly the same capacities and limits as the previous one, so it is necessary to readjust, re-optimize the scope of his activity. By not doing so, we accumulate losses: loss of quality when the person does not have all the necessary skills, loss of motivation when we ignore some of their capacities, which are nevertheless relevant to the activities entrusted to them. In short, we underutilize human capital, and then we complain wrongly and in good faith that the cost of labor is too high, that people are not motivated, etc., etc., without fully understanding that the real origin of the problem is largely at the level of the nature of the digital tools of organization.
|
•
|
Bringing together several production units. There is no good solution in this configuration: We can choose to let each entity continue with its own system, but then we drastically limit the positive effects of synergy, we do not make economies of scale, etc. You can choose one of the systems and generalize it, but you weigh down the productivity of the site on which you parachute the change and you increase the risk of failure of the merger. We can launch a new common application, but it is a safe bet that the migration of existing data will be unsatisfactory because of the gaps in the representation of the activity (to a field in software A does not correspond to a field in software B , or software A implied a certain way of carrying out such activity, while software B assumed a completely different approach, exactly as in the case of the assembly of existing solutions mentioned earlier in this document) What must be understood at this level is that the source of the problem is linked to the very nature of the relational model which serves as a support for all these developments. A relational database is by nature the fixed modeling of an organization, therefore the reflection of a homogeneous, immutable, and closed world. In contrast, Storga was designed to establish automatisms between heterogeneous entities.
|
An additional cause of the difficulty in maintaining the code is the separation between the program and the data which one finds in all the traditional development systems, as opposed to a spreadsheet for example.
|