The Transformation Actors share Approach and Tools

1. Decomposition of the Transformation approach

   1. The Transformation Processes

      There are different Transformation Processes: Design a new Product, Build a Solution, Build an innovative Solution, but also Modify a Solution (evolution or correcting "bugs"), Build Foundations, Define a Road Map,...
      This document develops, in particular, the Building Process or Modification of Solutions.
      

   2. A Transformation Process is broken down into Phases

      We know how to formalize the Operational Processes well, like the order Process, and we progressively automate them. It is much more difficult for the Transformation Processes like the Solution Building Process, in view of the uncertainty linked to any project.
      Much progress has nevertheless been accomplished: each Enterprise has defined its own Transformation Process by breaking it down into progressive Phases. Each Phase has an objective and a deliverable. An end-of-Phase Milestone enables us to take stock of the situation, validate the Deliverable and move on to the next phase.
      

   3. Each Phase calls for Functions

      The Processes are different from one enterprise to another, but they all reuse identical Transformation Functions. We distinguish two types of Functions:
      

      • the Engineering Functions (like "Model Processes") in order to Build the Solution
      • the Management Functions (like "Plan") to Manage the Project well.
        

      The Engineering Functions are the Business Functions of the Transformation: they have to be accomplished whatever the established Organization. The Management Functions are the Organizational Functions of the Transformation: they depend closely on the Organization and the Approach. They are therefore specific to each Enterprise, whereas the Engineering Functions are universal.
      

   4. Progress in Management but inadequacies in Engineering

      Progress has especially been around Management.
      We have to continue down this path of improving Management, but not go overboard: too many Management tasks prevent the project manager from focusing on the Engineering Functions. We can Manage very well the project of a badly built Solution.
      
      

2. How do we Transform the Transformation Model?

   1. A multidisciplinary approach

      Define a single Approach, shared by all the participants in the Transformation, especially Business and IT, which is not yet the case in all Enterprises.
      This Approach will be accepted better if we have defined the Transformation language and Business language beforehand.
      

   2. Shared Modeling tools

      The Transformation must be tooled like the Operations: both to manage and to build.
      

      • Tools to manage: manage the scheduling, resources, incidents, budget, communication...
      • Engineering tools: design and 3D simulation tools, mapping tools, tools for modeling products, requirements, processes, software, user interfaces, tools to control the quality of the Model, test, document, analyze the performances, collaborative tools, configuration management tools...
        

3. Transformation Model for a Project

   

   This schema briefly describes the Transformation Process for a simple Project.
   

   • Define the Goal of the Transformation Project (one or two pages maximum)
     
   • • Define the scope and the associated volumetrics: geographic, Product Line, Process Domain, customer segment...
     • Define the objectives and the associated indicators to check the result obtained. Define the Project constraints, in particular regarding the budgets and timescales.
       
   • Define the Foundation
   • Build (or Modify) the Solution Model or the Offer Model
   • Deploy the Solution or the Product Model
     
   • • Migrate the information
     • Reorganize Organizational units and premises
     • Allocate and train the Operational Actors
     • Allocate, install, configure the IT-Actors
     • Prepare the hotline
       

4. Transformation Model for a Program comprising several Projects

   

   When the Transformation ambition is considerable, we have to divide the Program up into Projects to avoid the tunnel effect and isolate the short-lived Projects.
   We then distinguish

   • the overall Goal of the Program and the individual Goal of each Project, contributing to the overall Goal
   • the Foundation of the Program which will provide the overall coherence.
     

   Moreover, we have to decompose the Program into Projects, which enables us to provide an initial estimation of cost and timescale for the whole Program. These costs and timescales are then specified Project by Project.
   

   As the Projects are carried out by distributed teams, it is necessary to integrate the results of each team to ensure that the teams overall are working well while respecting the reliability and performance conditions.
   
   Finally, we have to Deploy: either Project by Project, or by grouping the results of several Projects together.
   
   Remark: for the more complex Programs, we can consider having more than 2 levels (Program, Project), but the principle is the same: to obtain a division in controllable Transformation units, we need a Foundation: Transformation Model, components and Architecture.

   We recommend carrying out an assessment of the Programs and Projects:

   • Has the Goal actually been reached? check with the indicators
   • What lessons can be learned?
     
   • • Can the Transformation approach be improved?
     • Assessment of the architecture
     • What new Components are reusable for the Foundation?
       

The story of George the Baker is made available under the terms of the
Creative Commons Attribution - NoDerivatives 4.0 International license.

Comments