Don´t design based in Processes. Do it based in the Customer Experience.

Last week, I went with my wife to buy her a new car. We planned to pay part of the price with our current SUV. We were attended by a nice salesman, he explained the characteristics of the car, we drove the car in a test drive and executed all the normal steps that should make the experience of buying a new car a pleasant and happy one.

However, near the close of the deal (actually, we gave some money in advance to secure the model we wanted…), we were directed to the "used cars manager” to offer him our used SUV. At this point, because of "their established process" the customer experience started to go south. We were asked to give them our used SUV and the property documentation, and "hopefully" they will pay us the price in a term of "near" 5 days. It meant that:

- We don´t have nor our car neither the property documentation (with all the security issues you may imagine)

- We have to pray (or “trust them because they are a big company” as the manager said…) that they pay us in the expected term

- We don´t have a car until they pay us. So we have to stop doing our normal life because of that.

The excuses were based on "their internal processes and to comply with recent regulations”. We asked to other dealers (just to check...), and they told us that we will give our used car and at the same time, we will receive the new one after we pay the difference. So, this a case were the "process" ruined the "customer experience".

What I learned is that, especially for front-office processes, we have to start with the design of the Customer Experience, then the Services we will provide to our Customers, and then (finally…) the Capabilities required, which imply the Processes, People and Organization required to serve our customers.

We will talk about that in other post, but for now, I will share some links that may help you to start designing starting with the Customer Experience:

- How to map and study Customer Journey? http://klou.tt/i3bbdqcyu8tl

- 5 Tips For Building Great Customer Journey Maps http://klou.tt/1708nirs1zr8i

- Build your Product around your Client http://klou.tt/12tb86trimq12

(More links in my twitter: @abauza)

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

So your company is starting a "Transformation Program"?

Transformation: In an organizational context, a process of profound and radical change that orients an organizationn in a new direction and takes it to an entirely different level of effectiveness. 

Source: http://www.businessdictionary.com/definition/transformation.html#ixzz2Yvvu4IG3


Due to the costants changes in the market, in the consumers, in the world in general, once a while companies start a "Transformation Program". It looks the right way to approach major changes, like we do when we have gained too much weight and start a diet, but not necesarilly we achieve (like with the diet...) the outcomes we expect.

Typically, a company starts a Transformation Program when some of this phenomena is taking place:

- Profitability is going south, or revenues are diminishing or cost are increasing (or all of them).
- After the acquisition of a company, to seize the opportunity to make long time postponed changes and achieve the expected sinergies.
- The implementation of a major enterprise system (i.e. an ERP) or a major application.
- A major change in the Operating Model (i.e. a transformation in the Supply Chain, the implementation of Shared Services, outsourcing initiatives, etc.)
- Standardization/armonization/homologation of different operations (i.e. a multicountry operation).
- Innovation and growth initiatives in the company.

In a study of Accenture, we found that most of the Transformation Programs are reactive and created to reduce costs, and not neccesarilly to strength the "Competitive Essence" of the company. Also, the proactive and innovative changes with an idea of a transformation culture are rare. On the other hand, the study shows that only 4% achieved ALLthe benefits expected for the Transformation Program, and 40% achieved the majority of them.

How to avoid these pitfalls?

There is no silver bullet because every Transformation Program has its own peculiarities. However, there are some recommendations that apply to most of them:

1) Start with a goal in mind. It implies taking your time to define clearly the objectives (including targets and time to achieve them), a compelling business case (with the commitment of the key actors) and a clear roadmap (a thought plan) to achieve the objectives.

2) Define "smart" KPIs. Again, with a baseline and target, and clear accountability of who is responsible to achieve it.

3) Align the objectives of the key actors. It means not only defining them, but also linking them to the pockets of the key actors.

4) Monitor the progress and the benefits, and adjust accordingly. Establish a clear Governance Model, and follow the journey till the end. Capture and show benefits, and seize the opportunity to identify new ones.

5) Identify and implement quick improvements. Show that the boat is moving and not stranded in the sea.

6) Sell the benefits, constantly. Like Moses in the dessert, if you don´t show benefits the crowd will desperate.

How to define Key Performance Indicators (II)

The KPIs definitions by themselves will not solve a problem. We have to create an enterprise performance management capability to achieve the expected outcomes, using the KPIs as a key tool. This capability is comprised of processes, organization and tools that guarantee the cycle which starts with the business strategy,  clear and measurable goals, and the execution measured with by the KPIs.

 

It implies that the business strategy has been defined in measurable terms, i.e. EVA growth, market share growth, talent retention, etc. You can use a methodology for the strategic management of the company like Balanced Scorecard, Value Management, or any other and use them to define the KPI and the KPI tree. Then, you should establish goals to those KPIs. There are several techniques to establish such goals but at the end, they will be linked to the expected business outcomes for the year.

Then, the KPIs and goals defined must be "cascaded" to the tactical and operational levels of the company in order to make them consistent. In such way, every employee will know how he/she will contribute to the overall goals of the company.

As a result of the Operation, the KPIs will be affected and we measure their variations and how close they are to the established goal. Then, we take decisions to improve them. Eventually, the KPIs will help to reshape the business strategy.

In the following diagram, we illustrate how the KPIs cascade from the Strategy to the Operation. As you can see, you can have:

- Functional KPIs, related to measuring the outcomes of a specific function.
- Process or Cross-functional KPIs, which involves the collaboration of two or more functions.

When architecting the KPIs tree, make sure that your definition will help to:

- Implement the business strategy
- Align function and processes to the business strategy
- Identify if the KPI will be lagging or leading and why
- Establish the frequency of KPI measurement
- Define who are accountable(s) for the KPI results

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.

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...