Tag: transformation

How can certification help with enterprise transformation?

  By ,

If you don’t think that the economic situation justifies the attention given to the topic of transformation, this post is not for you.

If you think that putting a “transformation” label on everything we usually do (projects, strategies, organizations, architectures…), without changing a single thing about how we think about things, this post is not for you.

Compared to classic approaches, enterprise transformation requires a truly interdisciplinary approach. It has to mobilize different skills coming from varied, and usually quite impenetrable, universes. It has to organize how things circulate between the organizational and cultural silos.

Nothing is less natural! In our organizations, everything conspires to stop this momentum. Managers know this more than most. To save the very notion of transformation, we need clearly established reference points. Can we find them in the reference frameworks of customary practices? No, for a very simple reason: these reference frameworks are always, and without exception, the expression of a professional community (IT architects for TOGAF, analysts for BABoK, managers for other reference frameworks, etc.).

They always approach the enterprise from a particular angle and only ever provide an incomplete glimpse of it. By a natural – and necessary – movement, each profession fosters its own doctrine. These reference frameworks remain perfectly useful and commendable, but their use is restricted to a professional body. To serve transformation, we seek a framework that can channel knowledge from a wide range of fields. At the very least, we have to summon all transformational disciplines and get them ready to work together.

It is precisely the mission of enterprise transformation methodology to establish these reference points and to share them between all actors of the transformation. It proposes a common framework, covering the whole enterprise in all its aspects. It is from such a framework that individual contributions can be positioned and articulated together. The synergy within a transformation program can only be created if each person recognizes the other cultural universes and accepts to go towards them.

For a long time, enterprises and HR departments turned to certifications to support their transitions and their requirements regarding professional practices. Indeed, certification makes us objectify skills and evaluate individual capabilities as rigorously as possible. The result is an assurance regarding the capabilities mobilized in the enterprise and in its projects. However, enterprise transformation is a “game-changer”. As the key to transformation lies in interdisciplinarity, certifications developed around a framework of practices, in the context of a profession, are not enough.

The qualification diagram

The qualification diagram

This is what leads us to the idea of a certification built on enterprise transformation methodology. The difficulty to overcome is due to the area covered by the method: one single brain cannot contain all the knowledge relating to the enterprise and its transformation. The equation is solved, as shown above, in the qualifying diagram. It contains a common core that increases awareness of the enterprise’s holistic approach and provides common reference points. This corresponds to the level that we expect each actor of a transformation to have, from designer to decision-maker, from strategist to IT worker.

This common core enables us to create the conditions of a collective approach. That doesn’t mean that we can neglect highly specialized skills: they are based on the sharpness of the design and the capability to truly innovate. These skills are the subject of specialized certificates. The criterion of this specialization is none other than the enterprise aspect. This choice is along the same lines as indicated earlier: if we had chosen, as a criterion, the function or the discipline of the actors of the transformation, we would have instinctively fallen into the profession itself, impeding thus the stimulation of interdisciplinarity.

Started in 2013, with APMG International, the development of the certification has resulted in the “Foundations” certificate, the second of the common core. The exam is now available and is offered at the end of the “Praxeme Skills” training course, under the supervision of the Praxeme Institute.

The next session will take place in Paris, from September 15 – 17.

For more details:

Four key concepts for SOA

  By

The buzz about SOA seems to have faded away. There are no more conferences dedicated to the topic; the demand for training is declining; market leaders are trying to push new tags. Is it a sign that the SOA approach has been broadly accepted? Does it mean that the SOA logic has been assimilated and understood in depth? After a decade or so, do we have to draw the conclusion that the so-called paradigm has failed?

When considering the low level of modeling practices and the hesitations about architecture (EA, BA, CA…), one might wonder if the topic has really been exhausted. Being confronted with all sorts of issues due to low quality in IT, as a customer, as a citizen or as an agent, we surely expect dramatic improvements in the IT systems to come. At an age when digital business and innovation are commonly acclaimed as the new Utopian myth, the task of overhauling the systems is still on the table. SOA is precisely about rebuilding our systems, drawing up an optimal structure so as to avoid redundancy and to allow for interoperability.

It is about IT, but it is also an enabler for some strategic directions. Indeed, the SOA approach relates to business concerns since it can help by:

  • better serving scorecards by merging the decisional and the operational systems;
  • taking advantage of big data capabilities;
  • adding feedback loops throughout the business processes and the organizations;
  • contributing to enterprise transformation by simplifying and extending the value chain.

As an enterprise transformation methodology, Praxeme promotes a rigorous approach in order to improve our IT systems in depth. It proposes a method for designing services and architectures. This SOA approach can be summarized through four simple messages:

  1. SOA is an IS architectural style (which implies a specific role play between logical and technical architectures as disciplines).Styles
  2. If we are to live up to the expectations raised by the SOA movement, if we are to deliver on the promise of better quality, reusability, and interoperability in IT, we have to choose overhaul SOA over cosmetic SOA (or “False SOA”).FOA versus SOA
  3. To achieve the optimal system that will ease business and spur transformation, we have to summon and link together several disciplines, namely IT city planning, logical architecture and design, and technical architecture. We also have to equip them with proper representation techniques.POS versus Graphe d'architecture logique
  4. Due to the complexity of the systems, the scope of the endeavor and the diversity of skills required, it would be naïve to think we can reach the target without a method.
Positioning the Logical Aspect

Positioning the logical aspect

These four messages are detailed in the article “Praxeme’s four key concepts for SOA”.

French version: “Quatre idées fortes de Praxeme pour SOA“.

Formulating knowledge

  By

Terminology, ontology, semantic modeling

Whatever we do – be it transformation, innovation, automation… –, the starting point is always the same: business knowledge. Not only is knowledge a prerequisite, but it also has to be expressed in such a way that it complies with several criteria. It has to be:

  • complete, so as to avoid any surprises along the way,
  • unambiguous, in order to prevent conflicting interpretations,
  • accurate, reflecting reality, to support a relevant design,
  • lean and efficient, without redundancy (expressing as many things as possible using a minimum number of terms),
  • open and free from the presuppositions that could limit its reach.

This quality of expression is not guaranteed from the outset. It is reached only by constant efforts and endeavors. It is found neither on the business side nor the IT side. Indeed, we are forced to admit that it is not readily available in the enterprise. We only have to bring two business experts together and have them work on some definitions to realize that practices are based largely on what is left unsaid and that expressing ideas in words shatters the apparent consensus.

To gain an appropriate expression of knowledge, several techniques are available to us: terminology, ontology and semantic modeling. Each one has its own benefits and limitations. How can we make use of these techniques? Can they be linked together? What level of requirements should we target following the objective we have set ourselves?

These are some of the questions addressed by the article “Formulating knowledge”.

French version: “Formuler la connaissance”.

The six fallacies of business process design

  By

For decades now, it has been common place to assert the importance of a business process approach. However, when it comes to assess the outcome in terms of productivity, simplification or innovation, one could wonder: Why the hoopla?

This short article examines the six fallacies that hamper the approach to business process and business design. A second part introduces to the Praxeme method for designing processes.

 

A reference framework

  By

Enterprise methodology must not let anything escape from the reality of the enterprise. It is one of the conditions for mastering transformations.

The Enterprise System Topology provides an analytical framework and allows us to grasp and put in order everything connected the enterprise, from strategy to infrastructure, from the values to logistics, including knowledge and processes.