A path for defining a Transformational Structure

You can approach the design of a new organization through the definition of roles and profiles for every position, in other words, a bottom-up approach. However, this approach is far from being transformational. If the company wants to make a transformation, we suggest following these simple steps (see diagram at the end as a reference):


1) Understand the Business Strategy. The strategic definition must be clear enough to obtain strategic guidelines for the design. Use workshops with the C-Level to assure that you capture the intent of the business for the transformation. Have clear in your mind how the company should look like in the future.


2) Map the Business Model. You can use a technique like “Business Model Canvas” to map the to-be Business Model (see http://bauzanotebook.blogspot.mx/2013/05/map-business-model-then-business_13.html). With the Business Model, you shall identify what will be the differentiating capabilities of the company, in order to provide value to its customers. The differentiating capabilities must support your competitive essence in the market (or your future competitive essence...).


3) Map the Capability/Process Model. At this point, you have identified what capabilities are important for the company and they should appear clearly and bold in the Capability Model (see http://bauzanotebook.blogspot.mx/2013/05/a-proposed-structure-for-business_2.html). If not, your design will not support the Business Model and hence, your Strategy. Make sure that the model support the Business Model and provide the value intended to the market.


4) Design the Operating Model. Having your inventory of capabilities and processes, you have to:



a. Classify the capabilities and processes. You can use tags like: Core, Non-Core, and Support. You may use a different classification, depending on the organization strategy. The classification will help you to understand what capabilities and processes can be outsourced or placed in a shared services center, for example (if a given capability is non-core, is a great candidate for outsourcing).



b. Localize the capabilities and processes. Define which capabilities and processes are Local, Regional, Global or Hybrid. This step will help you to understand where to locate these capabilities.



c. Prioritize. Define what should be attacked first, second, etc. It will help you to define a roadmap of implementation of the different capabilities.



In the Operating Model you define “where” is executed and “who” is responsible of executing specific processes. For example, you may define that the accounting processes will be executed in a Shared Services Center and the Demand Planning processes will be executed in a Centralized Center of Excellence. Also, you define the interrelations between the different elements of the Operating Model.



5) Based on your design of Operating Model, then define your different interrelated architectures. At this point you have already defined the capabilities and process inventory aligned to your strategy, so you can start to define you Process, Technological, Information and Organizational Architectures (or additional architectures you may need). Going back to the initial point of this blog, it is difficult to define an Organizational Architecture if you have not decided if you are going to implement a Shared Services Center, a Center of Excellence or a capability will be centralized in the Headquarters of the company. The Organizational Architecture must reflect that. If your Operating Model has a SSC, then you will need a box in your Org Chart to cover that need.

 

The Power of the Words in Business.

“Words are, of course, the most powerful drug used by mankind.” 
― Rudyard Kipling

I have seen a common problem in different businesses, and that problem is the lack of a common understanding of the terms used for the business strategy and execution, and in other cases, terms used in a wrong way. Although is not necessary that all employees have a thesaurus in their heads, it is important to select and have a common understanding of the key words for the business.

Key words are those that we have to guarantee that employees understand in the same way. These key words are important in the business strategy definition and in its implementation. Also, I have found that when a business uses properly a term and the variations of such term, tends to have a better framing of the opportunities they have.

I work mostly in Supply Chain and BPM projects, so we guarantee that everybody understand quite well what "inventory" and "process" mean, as an example. If we look for the definition of "inventory" we may find that is:

"The raw materials, work-in-process goods and completely finished goods that are considered to be the portion of a business's assets that are ready or will be ready for sale."(1)

However, if we look at the APICS dictionary, we may find 137 terms related to the word: safety stock, base stock, make-to-stock, pipeline stock, etc. We can get lost in this amount of terms, so in an initial stage, we need to have a selection of key words for the business.

We can face this problem in different ways. Some of the recommendations are:

- Use clear and unambiguos words in the Vision and Mission declaration statements. Make them short and easy to remember.

- Select the key words for your business. Link them to the business strategy and the key operations outcomes you want to achieve.

- When initiating a project, execute a training on basics and key concepts before starting the core work. Make sure everybody in the project understand the same. Use certification or exams to calibrate the understanding of the concepts.

- Use training as a tool to gain maturity. For example, Accenture has a set of on-line academies used extensively and massively to gain momentum in business concepts and practices.

- Measure maturity growth periodically.

More information:

http://www.accenture.com/us-en/Pages/service-accenture-academy.aspx
http://www.accenture.com/SiteCollectionDocuments/PDF/Accenture_Supply_Chain_Academy_height.pdf
http://newsroom.accenture.com/article_display.cfm?article_id=4182


Sources:(1) http://www.investopedia.com/terms/i/inventory.asp

5 steps to consider before starting your Process Mapping effort.

A process mapping effort, especially if it will be enterprise-wide, implies an important investment of resources and time. Hence, it is important to consider at least five important things before starting to map:
 
1.     Define the Strategy: be clear what the business objective(s) of the process mapping effort is. This objective (or objectives) must be shared with the project team. Depending on the strategy, the type of mapping shall be defined. For example, you may want to do a mapping effort for:


·        Compliance: to have the process maps to fulfill requirements of auditing, ISO-9000 initiatives, normative, company documentation, enterprise architecture, etc.
·        System implementation: the process maps will be the business blueprint for an ERP or another type of information system.
·        Process improvement: the maps will be used to detect areas of opportunities to be more efficient or productive.
·        Reengineering: the process maps will be used as the tool to reengineer the operation.
·        Process orchestration: the main purpose is to serve as the basis for the process orchestration using a methodology like BPM/SOA.
·        Training: main objective is to train employees in the way the company do the work.
·        Process harmonization/homologation: the company requires having standard process across geographies, business units, etc. Typically, we need this approach in a post-merger integration or in the preparation of the company to a global strategy.
·        Cost reduction: when you want to understand where the cost opportunities are in the different process of the company.

It is clear that depending on the purpose, the information reflected in the process map (so, in the same way, the methodology used for mapping) will be different. The other aspect that must be well defined is the time horizon of your mapping:

·        Is it an “As-is” process mapping?
·        Is it a “To-be” process mapping? If so, what is the time horizon (i.e. next year, aligned to a milestone, etc?)

This time horizon must be applied to the whole process mapping. If not, you are going to have a mixture of future with present processes.

If the strategy is not clear, you will have an organization “frustrated” because it didn´t get the expected benefits of the mapping effort.

2.     Create a process inventory: have a preliminary list of all the process that will be part of the mapping effort. This inventory will change, but you should have a starting point. This inventory and the complexity of each process will help you to dimension the size of the teams. The approach should be “top-down” with adjustments coming “bottom-up”. This is one of the reasons that you may start with a business process framework for the company and then go down to the list of the further levels.

3.     Establish the plan: have a detailed plan of the process mapping effort, indicating clearly time and resources required in each activity. You should use the estimation based on the process inventory to identify quantity and skills of resources needed.

4.     Select and prepare a process repository: based on the strategy, you should define the type of repository and tools needed. If for example, you want to do simulations, you have to be sure that the tool will support this functionality. The same applies to other functionalities like process orchestration.

5.     Establish the process mapping conventions: define clear rules for the process mapping. You should not start any process mapping effort without the rules of mapping. You can use a standard as a basis (i.e. BPMN), but always aligned to the strategy you already defined. The conventions must help you to achieve the project objective. The rules must be easy to understand and to apply, and be as exhaustive as required. You have to define, in this convention:

·        The standard that will be the base of the convention
·        The naming conventions
·        The symbols conventions
·        The style conventions
·        Diagrams of what is allowed and what is not, and examples of good mapping
·        Attributes to be filled in the diagrams
·        Change control procedures and documentation
·        Users and security standards

If you fill these steps, you will have a better chance to start with the right approach the mapping effort.

The right sequence: Process, Organization and then, Technology.

It is normal to consider that one way of making changes to a better level of operation in the organization is through the implementation of a new technology (i.e. a new ERP or information system). One of the paradigms behind that is that the "ERP brings the best practice". Although this statement is partially true, this road has driven to more problems than solutions. With the high investment in technology the companies make, it is recommendable to take a second look to the sequence.

The main subject is that we are humans (and should be treated like that...), and there are some steps to be fullfilled to achieve the change required. In this article, we consider the definition on each element as follows (I´m assuming that the Strategy is clear for all cases):

- Process: changes in activities, way of doing the work, techniques, methodologies, KPIs.

- Organization: changes in roles, responsibilities, objectives, targets, job title, job description, organization charts.

- Technology: changes in systems, new technologies, equipments.

Let´s take a look to the combinations and see the possible outcomes (I do not pretend to be exhaustive...). Ideally, you should do all changes at the same time, but depending on the degree of the change, the organization may or may not absorb it completely. Also, the "Solution designer" may have a clear picture about the vision of all elements working together and not to be completely sequential. It means that if you are designing process supported by an ERP, you have to consider the ERP restrictions from the very beginning.

Map the Business Model, then the Business Process Model (II).

Someone can think "it is very difficult to understand the Business Model, let´s do the work and let´s start mapping processes...". The reality is that if you gather the  required audience (leaders and decision takers of the organization), you can have a good understanding of the Business Model, before starting to map a Business Process Model.

I recommend to take a look to the book of Alexander Oster and Yves Pigneur, "Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers", or review presentations that explain quite well the concept and the methodology, like http://www.slideshare.net/Alex.Osterwalder/what-is-a-business-model


Let´s try, for example, to map the business model for a non-alcoholic beverage company. For this company, we start with the Customer Segments, and then move to the left in the canvas. It is desirable to create a first draft model, and complete the model with the leadership of the company during a workshop.

Then, we can analize the model in terms of required capabilities to deliver the value to the clients, and start to list them. Such capabilities will be part of the Business Process Model of the company. In this case, we find that some of the capabilities are:

- Client and consumer sales capabilities
- Supply chain management capabilities (procurement, manufacturing, distribution, warehousing, transportation)
- Product lifecycle management capabilities
- Marketing and Trade Marketing capabilities
- Support capabilities (HR, finance, TI)

As a first draft and as simplified example, we can create a Business Process Model that will contain the capabilities mapped in the following way:

You should refine this model (and its representation) with leadership. Macro-process, processes, subprocesses and so forth will be linked to these capabilities and will form the process inventory for the company.

A proposed scale to achieve process adoption.

Adoption is one of the principal challenges for the processes defined. In this article we will understand "adoption" as the execution of the process as it was designed, i.e. following the steps, executed by the designed roles, using the inputs, generating the outputs and complying with the process KPIs.

We may have the best business blue print, very well structured and consistent, but if the business does not execute the process as it was mapped, it is useless.

We tend to think that if we make the effort (most of the time, a daunting effort) to map the business process, we will have a big advance in the execution of the process in the real life. My experience is not like that...

From my point of view, the adoption scale will depend of the methodology and tools that we use to achieve this goal. This scale can be depicted as follows:

The scale is cumulative, in other words, you should have the previous methodology and tools in the scale to achieve the required level of adoption. What the figure suggests is that we stop at Process Mapping, we are not going to achieve much. We should train the actors that will execute the process, or even better, design the new process with them.

When you have the responsibility of process design, think in adoption. It will make the difference...