Note: we prefer the term “interdisciplinarity” to “multidisciplinarity”. We consider that it is not simply a question of involving several disciplines, but more particularly the way in which they are articulated and ensure synergy, so that their contributions flow naturally without any loss of effort along the transformation chain.
This is the constant preoccupation – and original impetus – for Praxeme: enable the enterprise to benefit from the disciplines that can enrich its practices and help its transformation.
To give an example, if an investment in processes is not thought through from the outset in relation to other components, the potential rewards will not be as great as one might have hoped for. In the same vein, a new dashboard can not simply be implemented without having first considered all the implications it may have in other areas of the enterprise. So, expertise in a given subject, albeit precious, will never guarantee the depth or pertinence of transformation. One area of expertise must be associated with others, so as to ensure as full a coverage as possible of the entire reality of the enterprise.
In our examples, it is necessary to evaluate the receptiveness of the people concerned, and so to have revealed the values at stake. Of course, it is not possible to avoid a minimum terminological effort upon which the shared understanding can be built. Potentially we may need to turn to some other models to clarify things. The rewards are almost always greater when change is prolonged by an appropriate computerization.
For the blend of competences to be successful, it is essential to share a common framework and to know the rules of passage from one speciality to another and from one universe to another. Praxeme arranges the competences around its framework, the Enterprise System Topology. In addition, the method provides the rules of passage (or derivation) which allow you to go from one aspect to another: for example, to infer one part of the software services from the processes (see the Logical Aspect Guide).
The framework enables the disciplines to be positioned “objectively”, helping to define them and to dispel the uncertainty that can mar the definition of some of them (see the debates surrounding enterprise architecture and business architecture for example). By so doing, the method assigns responsibilities by expressing them in objective terms, in other words, naming the elements that make up the object we affect: the enterprise and its systems. This work is done, at the first level, in terms of enterprise aspects and then, at a more detailed level, thanks to the underlying metamodel.
Back to the arguments