toyota pdca

Toyota IS Business Planning
All about Plan‐Do‐Check‐Act

Xiang Tjoa, BSc
BMI, 1202952
27 January 2008

Toyota Motor Europe
Information Systems Division
Business Planning
Avenue du Bourget 60
1140 Brussels
Belgium
Supervisor: F. Grauls

Vrije Universiteit
Faculty of Sciences
De Boelelaan 1081a
1081 HV Amsterdam
The Netherlands
Supervisor: Dr. S. Bhulai
Second reader: Dr. C. Verhoef

Version 2.6

Toyota IS Business Planning All about Plan‐Do‐Check‐Act

‐ 2 ‐


‐ 3 ‐


‐ 4 ‐


Preface

This internship is to conclude my Master Business Mathemetics and Informatics at the
Vrije Universiteit Amsterdam. Seven months I have spent at Toyota Motor Europe in
Brussels to try to understand the business processes within Information Systems and to
contribute in improving them. My internship has given fortunately enough foundation
of trust for Toyota to ask me to stay at Information Systems division after the
conclusion of it.
But to come this far, it took also the support and patience of a lot of other people. First I
had the goal to search for an internship abroad. Secondly, it was absolutely not easy
when it came to making the final decision. My parents, partner and friends helped me
to make this decision and kept supporting me during the entire period as an intern far
away in Brussels.
As of the first Monday I came in as an intern at IS Business Planning, my team didn’t
hesitate in giving me my first assignment with a deadline set on that Friday already.
With the right support from Ricardo (and on the background Frank as manager and
Tim as General Manager) I was able to meet that deadline. That culture of no fooling
around and to work the best you can was exactly to my liking.
The support that was given from the first day continued during my entire internship.
After Ricardo left in February, Frank became my direct mentor. Although it was a very
hectic period with a merge coming up between two so very different entities
(Manufacturing and Sales), the support was there when I needed it. My team members
were fun to work and chat with.
But not only Toyota made the conclusion of my internship possible, also the support
and trust of my supervisor from the university pulled me through some more difficult
periods. I would like to sincerely thank Sandjai for his support and advices. And not to
mention Chris; he (like Sandjai) did read through my report every time I sent it to my
supervisors so very short before the deadlines. Even after so many months spent at
Business Planning, I still act like a student ☺

‐ 5 ‐


‐ 6 ‐


Index
INTRODUCTION .................................................................................................................................... 9

1 TOYOTA ........................................................................................................................................... 11
1.1 KAIZEN! .......................................................................................................................................... 11
1.2 INFORMATION SYSTEMS DIVISION .............................................................................................. 11
1.2.1 THE CREATION OF TOYOTA EUROPE DATA CENTRE (TEDC) ................................................... 12
.
1.2.2 A LEGAL MERGER BETWEEN TMEM AND TMME ..................................................................... 12
.
1.3 THE TOYOTA WAY – PHILOSOPHY AND MANAGEMENT TOOL .................................................. 13
1.3.1 THE TOYOTA WAY ...................................................................................................................... 13
1.3.2 THE DEMING CYCLE: PLAN DO CHECK ACT ............................................................................. 14
1.4 DEMING IN IS ................................................................................................................................ 14
.
1.4.1 IS DIVISION WITHIN TMME AND RDMC .................................................................................. 15
.
1.5 OBJECTIVES OF MY INTERNSHIP .................................................................................................... 16

2 THE ANNUAL PLANNING CYCLE ........................................................................................... 19
.
2.1 INTRODUCTION .............................................................................................................................. 19
2.1.1 TOOLS USED ................................................................................................................................. 20
2.2 DRAWING UP BUDGETS ................................................................................................................. 20
2.2.1 BUDGET TYPE ~ PORTFOLIO ACTIVITY ........................................................................................ 20
2.2.2 BUDGET TYPE ~ MEMBERS ACTIVITY .......................................................................................... 21
2.2.3 BUDGET TYPE ~ PROJECT ACTIVITY ............................................................................................ 22
2.2.4 MY SUPPORT DURING THE BUDGET ACTIVITIES. ......................................................................... 23
2.2.5 HOSHIN ....................................................................................................................................... 24
.
2.2.6 MY SUPPORT DURING THE HOSHIN CREATION .......................................................................... 25
.
2.3 DIFFERENCES RDMC/TEDC/TMME IS ..................................................................................... 26
2.3.1 BUDGET PREPARATION (PROJECT, PORTFOLIO AND MEMBER EXPENSE) .................................. 26
2.3.2 HOSHIN ....................................................................................................................................... 26
.
2.3.3 MANAGER’S VIEW ....................................................................................................................... 26
.
2.4 CHALLENGE MEETINGS ................................................................................................................. 27
2.5 CONSOLIDATION SHEET ............................................................................................................... 27
.
2.5.1 BASIC IDEA CONSOLIDATION SHEET .......................................................................................... 27
2.5.2 REQUIREMENTS ........................................................................................................................... 28
.
2.6 AFTER DECEMBER .......................................................................................................................... 29

3 KEY PERFORMANCE INDICATORS ........................................................................................ 31
3.1 INTRODUCTION .............................................................................................................................. 31
3.2 TOYOTA KPIS ................................................................................................................................ 32
.

4 HARMONISING THE KPIS ......................................................................................................... 33
4.1.1 NEXT STEPS .................................................................................................................................. 34
4.2 RDMC ............................................................................................................................................ 34
4.2.1 CURRENTLY ................................................................................................................................. 34
4.2.2 NEXT STEPS .................................................................................................................................. 36
4.2.3 MANAGER’S VIEW ....................................................................................................................... 39
.
4.3 TEDC .............................................................................................................................................. 39
4.3.1 CURRENTLY ................................................................................................................................. 39

‐ 7 ‐


4.3.2 NEXT STEPS .................................................................................................................................. 40
4.3.3 MANAGER’S VIEW ....................................................................................................................... 41
.
4.4 TMME ............................................................................................................................................ 41
4.4.1 CURRENTLY ................................................................................................................................. 41

5 CONCLUSION ................................................................................................................................ 43
.

6 (APPENDIX) ..................................................................................................................................... 45
6.1 TME IS TEAMS. .............................................................................................................................. 47
6.2 ANNUAL PLANNING CYCLE – OVERALL PROCESS ...................................................................... 49
6.3 ANNUAL PLANNING CYCLE MASTER SCHEDULE ........................................................................ 51
6.4 ANNUAL PLANNING CYCLE – VISUAL CONTROL ........................................................................ 53
6.5 HOSHIN – FIRST DRAFT ................................................................................................................. 55
.
6.6 HOSHIN – FINAL ............................................................................................................................ 57
.
6.7 BUDGET CONSOLIDATION SHEET. ............................................................................................... 59
6.8 KPI REPORT – FRONT PAGE ........................................................................................................... 61
6.9 GUIDELINES WEEKLY KPI TEMPLATE .......................................................................................... 63
6.10 TMME AND TEDC KPI REPORT .................................................................................................. 65

‐ 8 ‐


Introduction
Today Tomorrow Toyota.

This is the slogan Toyota uses in the current advertisements. Apart from the alliteration
(all words starting with the letter ‘t’), this slogan also symbolises the mission of this car
manufacturing company. It shows the long‐term view of Toyota and the intention of
maintaining and improving the quality of its products in order to become the
manufacturer of the car of the future.

Toyota has developed a philosophy containing fourteen principles, the Toyota Way,
which is famous throughout the world and which has been copied to other
organisations, some with more success than others. One of the pillars of a car
manufacturing company is the plant where the cars are being built. The choice for a
logistic system is crucial for the success of any manufacturing company. Efficiency, low
costs and low inventory stocks being the keywords, Toyota has developed the Just‐In‐
Time pull system. This system is not the only factor to define the success of Toyota, also
the philosophy of –amongst others– continuous improvement, respect for your
colleagues, standardisation and decision making based on consensus of all parties
involved creates an environment which is open for development of both the business
processes and the Toyota employees.

Standardisation and continuous improvement will be the keywords throughout my
internship and throughout this report. With a merger between the organisations
Manufacturing and Sales & Marketing of the European head office, common business
activities and functions need to be harmonised. I will be supporting this process within
the IT functions for Toyota Motor Europe.

I will support the further standardisation of business processes and implementation of
improvements within the budgeting processes. As this year will be the first time that IT
Sales & Marketing participates in this budget process, it will probably bring forth some
adjustments to the IT Manufacturing templates, which are currently being used. After a
further introduction on Toyota in Chapter 1, an elaboration on the budgeting process
will follow in Chapter 2.
After establishing the budgets, it is time to define the Key Performance Indicators to
measure the progress on both financial and non‐financial terms. Within IT
Manufacturing, a set of indicators already exists based on cost, quality, performance
and productivity. The goal is to extend this philosophy to the other two IT
organisations within Toyota Motor Europe. Before the start of the next fiscal year on
April 1 2007, a format for each of the IT organisations should be ready for
implementation. In Chapter 3 (introduction into KPIs) and Chapter 4 (way of work and
results) you will find this harmonisation process.

‐ 9 ‐


‐ 10 ‐


1 Toyota

1.1 Kaizen!

Continuous improvement, also known as “Kaizen”,
is, next to standardization, one of the magic words
within Toyota.

According to the Just‐In‐Time method, which was
developed in the 1950s within Toyota, Kaizen has
always been a part of the manufacturing processes in
the plants. With implementing the Deming Cycle
(Plan‐Do‐Check‐Act), Toyota has extended this
philosophy to the business processes as well (please
see next paragraphs for more information about the
Deming Cycle).

During 2004 two important changes were to be rolled
out next to each other, although they were not directly
connected.

1.2 Information Systems Division

The Information Systems division (IS) introduces itself with the following texts:

“The Information Systems Division develops, installs and maintains the systems,
which support all the areas of our business. The team works as an internal provider for
other divisions to precisely define user and business requirements, analyse all available
options and make the company efficient and effective by recommending the latest
hardware and software that provide the most appropriate solutions.”1

and

“The Information Systems division is fully involved in providing IT solutions to all
business operations from design to dispatching of vehicles, covering as well R&D, pre‐
production support, procurement, supply chain, manufacturing support, Finance and
HR. Most core business related applications are developed in house.”2

The IS division does not exist only of business support teams, that provide IT solutions
to the business operations. The Business Planning team, of which I will be part during

1   Source: http://www.graduates.toyotajobs.com/html/grad_prog_is.htm
2 Source: http://www.graduates.toyotajobs.com/download/IS_2006.doc

‐ 11 ‐


my internship, supports the IS management by consolidating, explaining, and checking
the IT results and complex IT plans. This team also provides guidelines, standards, and
assistance in IT planning and administration functions for the entire IS division. See the
figure below for a visual overview of the portfolio of Business Planning.

Business Planning

Performance & Process Strategic Planning
Financial Management Resource Management Vendor Management
Key Performance Mid Term Plan
Budgeting Staff Planning Contracts
Indicators Annual Planning Cycle

Figure 1 ‐ Business Planning (November 2006)

1.2.1 The creation of Toyota Europe Data Centre (TEDC)
In 2004, discussions started about bringing IT Services of TMME and TMEM under one
organisation. Common IT services, like hardware and software purchasing and
defining IT infrastructure, were provided separately by both organisations and it was
thought that more efficiency and lower costs could be accomplished when the services
in this part of the IT area would be combined. The virtual organisation came into
existence in January 2005 when daily operations started. In 2006 a dedicated
organisation was established. The members of this new organisation were transferred
from the existing ones. This was to enable and emphasize that TMME and TMEM were
integrating their common activities with regard to IT Services.

2004 2005 2006 2007
Start Discussions Start Operations
Virtual Organisation Dedicated Organisation

Figure 2 – TEDC

1.2.2 A legal merger between TMEM and TMME
Next to centralising the IT Services of TMME and TMEM, discussions were held about
merging the two head organisations into one. In 2004, three entities existed for Toyota
Motor Europe:

1. Toyota Motor Europe – Holding Company;
2. TMEM – Coordinating the Manufacturing and R&D operations;
3. TMME – Coordinating the Sales & Marketing operations.

‐ 12 ‐


In September 2005 it finally came to a legal merger. Instead of separate organisations,
the two companies changed into two groups under the responsibility of the official
company TME. TMEM changed names into RDMC (Research & Development and
Manufacturing Company), whereas TMME kept the old one. Although the merger was
official, the operations for common functions such as Corporate Affairs, Information
Systems, Finance, and HR for Sales and Manufacturing side continued to be separate.
The prospect is to integrate those common functions as well in the very near future. In
this light, harmonising and standardising business processes become a very important
topic.

2004 2005 Sept 2006 2007 2008
‐ TMEM TME Integrate common functions
‐ TMME
‐ TME Holding RDMC TMME
Legal Merger

Figure 3 – Merger

1.3 The Toyota Way – Philosophy and Management tool

1.3.1 The Toyota Way
Since the Toyota Way has been successful in the manufacturing plants, this philosophy
has been implemented within the business processes throughout the company as well.
The Toyota Way consists of fourteen principles:

1. Base your management decisions on a long‐term philosophy, even at the expense of
short‐term goals;
2. Create continuous process flow to bring problems to surface;
3. Use “pull” systems to avoid overproduction;
4. Level out the workload (Heijunka);
5. Build a culture of stopping to fix problems, to get quality right the first time
(Jidoka);
6. Standardised tasks are the foundation for continuous improvement and employee
empowerment;
7. Use visual control so no problems are hidden;
8. Use only reliable, thoroughly tested technology that serves your people and processes;
9. Grow leaders who thoroughly understand the work, live the philosophy, and
teach it to others;
10. Develop exceptional people and teams who follow your company’s philosophy;
11. Respect your extended network of partners and suppliers by challenging them and
helping them improve;
12. Go and see for yourself to thoroughly understand the situation (Genchi
Genbutsu);
13. Make decisions slowly by consensus (Nemawashi), thoroughly considering all options;
implement decisions rapidly;
14. Become a learning organisation through relentless reflection (Hansei) and continuous
improvement (Kaizen).

‐ 13 ‐


Seven out of these fourteen principles lie at the basis of my internship at Toyota Motor
Europe (see the italic principles).

1.3.2 The Deming Cycle: Plan Do Check Act
The Deming Cycle is a framework for management to implement continuous
improvements into their processes. This Cycle enables them to track, visualise and act
upon the actual progress. The Deming Cycle consists of four phases that are connected
through a loop construction.

Plan Do

Act Check

Plan: During this phase, a plan has to be drawn up. This plan consists of targets
that have to be reached during a certain amount of time. In a project
environment, these targets can be seen as clear milestones achieved through
following a schedule. Targets can also be – for example – to plan a cost budget
and to not overspend this budget.

Do: After planning, the plan needs to be implemented and executed.

Check: During the actual execution, some tracking and checking need to be
done to monitor the progress of the project schedules or expenses. Regular
evaluations need to be conducted of the original plan versus the actual
condition.

Act: If during the evaluations issues are identified that may endanger reaching
the targets set, countermeasures or improvements can be taken. According to
these revised “plans” a new Deming Cycle can be entered.

1.4 Deming in IS

The RDMC IS division has implemented the Deming Cycle (or PDCA Cycle) for their
own division activities. In the figure below you can find the link between the Annual
Planning Cycle and KPIs.

‐ 14 ‐


Plan Annnual Do
Planning
Cycle

Hoshin Projects

Mid Term Plan HR
Mid Term KPIs
Plans

Improvement Evaluation

Act Check
Figure 4 – The Deming Cycle

The Annual Planning Cycle provides guidelines in making a plan on resources, cost
budget, and long‐ and short‐term goals, whereas the KPI reporting supports the
tracking and evaluating of the progress made during execution of the plan. Both are
management tools and should be used and treated like ones.

1.4.1 IS division within TMME and RDMC
Both RDMC and TMME have an IS division. Taking the upcoming integration into
account, RDMC IS took the initiative to standardise some of their activities, namely the
Annual Planning Cycle and the measurement of the Key Performance Indicators (KPI).
As can be seen in Figure 1 – Business Planning, the Annual Planning Cycle has its
influence on the financial and resource management. KPIs are part of tracking
performance and processes within IS.
Figure 5 – IS organisation chart on page 12 shows the current status of the Annual
Planning Cycle and KPI reporting between the three IT organisations of Toyota Motor
Europe.

‐ 15 ‐


1.5 Objectives of my internship

During my internship, my responsibilities lie in the support during the Annual
Planning Cycle and the harmonisation of the KPI reporting across the three
organisations.

In Chapter 2, the Annual Planning Cycle will be discussed. The objective here is

to support in preparing and answering to requests and concerns with regard to the tools
used. Next to this the goal is also to manage and visualise requests in order to make
sure that they are followed up and all stakeholders are aware of them.

The KPIs will be elaborated upon in Chapter 3 and 4. The main objective here is

to identify the ideal situation based on Executives direction, find the gaps with the
current situations and propose a new structure for an equal KPI reporting across TME
IS to enable fair comparison and healthy competition.

In addition to supporting everyday operations, I will also try to capture whether the
management tools to support the PDCA Cycle is implemented and used as it is meant
to be. Within Toyota, the KPI reporting should be used as a management tool rather than
another administrative report to check the progress on each target set during the
Annual Planning Cycle.

‐ 16 ‐


TMC
Tokio, Japan

TME IS
Head Office Europe

VP STEERING COMITEE VP
RDMC TMME
IS IS/ITD

Information Information
TEDC
Systems Systems
(RDMC) (TMME/ITD)

Business
Business Planning Business Planning
Management

1. Annual Planning Cycle

The annual planning
The annual planning
cycle has been The annual planning
cycle as drawn up
implemented since cycle as drawn up
for RDMC and
2004. FY2005 has for RDMC has been
TEDC is now in
been the first year implemented since
practice for making
budget drawn up 2005 for making the
the budget for
according to these budget of FY2006.
FY2007.
guidelines.

2. KPIs

KPIs based on First steps for KPIs
Cost KPIs regard systems for Projects based on
Time and operations (f.e. Cost
Quality topics concerning Time
Productivity Helpdesk or outages Quality
with regard to both of systems affecting Productivity
Maintenance/Support the Business). Maintenance does
and Projects. not have KPIs.

Figure 5 ‐ IS organisation chart (November 2006)

‐ 17 ‐


‐ 18 ‐


2 The Annual Planning Cycle

As Figure 5 in the previous chapter shows, the Annual Planning Cycle is more
established within the three organisations compared to the set up of KPIs. However,
seen in the light of the philosophy within Toyota, improvements and further
standardisation need to be implemented.

2.1 Introduction

Before having a final budget for next fiscal year that has been approved by the
Accounting & Finance department of TME, an internal budget process has to be
followed. The Annual Planning Cycle has been developed by the RDMC IS Business
Planning to provide guidelines to come to a plan for next fiscal year. During the
Annual Planning Cycle, managers from the first level until the high executive level
should think of which way to proceed, which projects to pursue, etcetera. Planning is
the crucial thought behind this Cycle. When the plan is drawn up, the budget, resource
plan, annual and mid‐term plans for the next fiscal year for each team within IS over
the three groups (RDMC with 16 teams, TEDC with 12 teams and TMME with 10
teams)3 will come naturally.

The Cycle describes the entire budget process that exists of four different budget‐
planning categories of which the fourth is slightly different compared to the first three:

1. Portfolios ‐ The portfolio budget shows the plan for next fiscal year for portfolio
items and calculates the budget and resources of support for existing
applications, technologies and/or services;
2. Member Expenses – The member expense budget takes expenses into account
with respect to ‐for example‐ expected travel, training, and office supplies;
3. Projects – The project budget is used to list all new projects and schedules with
their resource requirements (both on personnel as well as on technical area);
4. Hoshin – Hoshin is the Japanese word for policy management. In the spirit of
continuous improvement, Kaizen, the top management evaluates the old and
defines the new long‐term visions and company policies. They will be
translated into an action plan (Mid Term Plan).

Complete with timelines, this Cycle also provides an overview of how each budget
category is linked to the other categories and when they need to be synchronised.

From September to November the IS management have to work on drawing up
their budgets in order to have a draft ready by the start of December.


3 See for an overview of teams Appendix 6.1. Situation as per October 2006.

‐ 19 ‐


This draft will be reviewed with the General Managers and if all goes well, it
will be turned into a final (internal) budget proposal, which will be sent just
before Christmas to Accounting & Finance.
From January to March, Business Planning takes the lead to change the status of
a final “internal” IS budget into a final “external” IS Budget approved by
Accounting & Finance of head office.

The fourth category, the Hoshin, is not really a budget category. It is a contemplation
about the direction Information Systems has to follow next fiscal year and to translate
this into objectives and measurable targets. In general the elaboration of the Hoshin
starts in January and continues until a final version is ready. The deadline will be
before the start of the new fiscal year, which is April 1.

Although each budget category has its own process, deliverables and deadlines, they
are connected to each other and have to be synchronised before they can be finalised.
An overview of the whole process can be found in Appendix 6.2.

October November December January February March
September April
GM & IS executives review & SYNCHRONISATION

Portfolio activities
TME executives review & SYNCHRONISATION

final final
GM review & SYNCHRONISATION

-internal- -external-
draft (approved by TME
(approved by
IS executives) executives)
Member Expense
activities

final final
(approved by

Project activities

final final
(approved by

2.1.1 Tools used
The tools that are used to come to a budget are created within Excel. Each tool is
numbered alphabetically (as can be seen in Appendix 6.2). I will go into further detail
in the next paragraphs.

2.2 Drawing up Budgets

2.2.1 Budget Type ~ Portfolio Activity
Within the Portfolio Budget three types of portfolios exist which are not always
applicable to all the IS teams and for some teams more than one type is applicable:

‐ 20 ‐


Type number of number of number of
RDMC teams TEDC teams TMME teams
Applications (B) 15 0 4
Services (AA) 5 4 3
Technologies (A) 6 10 1

Per type a file (the portfolio templates A, AA and B) has to be updated by the
responsible managers of the IS teams, stating all the expected supporting activities for
fiscal year 2007. These files will be used as a base for drawing up the actual budgets for
each team.
With regard to the applications, technologies and services, an Asset Usage Forecast (C),
also known as Capacity Planning, is needed in order for TEDC to calculate their soft‐
and hardware budgets to support the growth of the business. Next to forecasting the
usage of applications, managers also need to define the resources that are necessary to
support the several portfolio items in the template Portfolio Budget (D). In short:
Portfolio Budget is resource and asset management on all existing support items.

<< SEPTEMBER OCTOBER NOVEMBER DECEMBER

LEGENDS:
Final Document
(Sr. Manager resp.) B
SYNCHRONIZE

SYNCHRONIZE
Updated Analysis of previous
Confidential: year portfolio
Need to know basis.
Applications
budget vs. actual
Quality Check by GMs <Challenging>

Portfolio
expense.
GM Approval
1 PORTFOLIOS ACTIVITY

AA
C D D
Updated
Asset Usage New Year Business
New Year
Services
Forecast Portfolio Budget Divisions/ Portfolio
Portfolio. Including Labour
(Capacity Units Budget
Management) -draft- Confirmation -final-
New Year
Budget
-initial-
A
Updated
Technologies
Portfolio

Figure 6 ‐ Portfolios Activity

2.2.2 Budget Type ~ Members Activity
Of all the budget types, the Member Expense Budget is the smallest. “Only” a couple of
million euros are consumed for these expenses.
Toyota has two kinds of employees: members and contractors. Members are the life‐
long employees of Toyota and contractors work at Toyota on a project (and thus on a
temporary) base.

Several steps are needed to come to a budget which covers all activities regarding the
IS members and contractors. The first step is to evaluate the contractors (E – Contractor
Evaluation) and draw up a Resource Strategy (F) containing the current structure of the

‐ 21 ‐


manager’s team – highlighting issues, foreseen business changes – and the proposed
structure for next fiscal year.
When both have been completed and approved, a Resource Forecast (G) can be drawn
up, in which all the names of the contractors and members and a consolidated
overview of their expected usage on projects and portfolio items can be found. Next to
this forecast, a Member Expense Budget (H) needs to be defined. In this budget, the
categories for expenses like long and short haul travel, training, exhibitions and
entertainment should be estimated for next fiscal year. All IS managers should draw
up a budget and strategy for their teams.

Need to know basis
LEGENDS: New Year
Final Document New Year Organisation
(Sr. Manager resp.)

SYNCHRONIZE

SYNCHRONIZE
Organisation -final-
Confidential: -initial-
Need to know basis. Organisation


Impact
GM Approval
MEMBERS ACTIVITY

E
Contractor G G
Evaluation Resource Resource
F Resource Forecast Forecast
Organisation Succession
Strategy -draft- -semi final-
Strategy Planning
-high level-

Analysis of H H
Member Member
previous year New Year
Member Expense Expense Expense
2

Budget Budget Budget
Budget vs. actual
-draft- -final- -initial-
New Year expense.
Headcount
-first estimation-

Figure 7 ‐ Members Activity

2.2.3 Budget Type ~ Project Activity
The Project Activities involve more than just drawing up the Project Budget. Projects
need plans; Mid Term Plans (I) for long‐term planning and Annual Plans (J) for next
fiscal year’s planning. As can be seen in Figure 4 – the Deming Cycle, Mid Term Plans are
closely linked to the Annual Planning Cycle. The decision to include this plan into the
Annual Planning Cycle was a natural one.
The Project Budget (K) itself is more resource management rather than asset
management. In this template a manager can indicate the support of other teams
he/she might need for a particular project. These other teams do not necessarily have to
be IT teams. In some projects support from the Business itself is required to make a
project successful.
Prioritisation of projects is important since budgets can be downsized if the amount
that the managers propose is too much in the eyes of the executives. If this is the case,
the low prioritised projects should be deleted.

‐ 22 ‐


<< SEPTEMBER OCTOBER NOVEMBER Infrastructure Teams DECEMBER
confirmation
LEGENDS:
Final Document K Project K Project

SYNCHRONIZE
SYNCHRONIZE
(Sr. Manager resp.)
Budget Budget New Year
Confidential: -draft- -final- Budget
Need to know basis.
-initial-

GM Approval Review against EMC
Annual Plans to
Analysis of
eliminate duplication
Previous Year J J


Outstanding Annual Plan
Strategic Annual Plans Annual Plans
Major Systems achievement + -1st draft- -semi final-
Planning Inputs Requests identify carryover
User
PROJECTS ACTIVITY

Previous Year's Confirmation
Mid-Term Plan
Prioritisation of Projects
Global Systems L
Implementation
Calendar I
Systems Map L
New Year IS I Systems Map
Mid Term L New Year
Systems Map
5 Years Plan Plan I Mid Term
provided by -1st draft-
New Year Plan
NMSCs, EMCs IS Management to Mid Term -final draft-
3

visit Divisions/Units Divisions/
and Business Plan Units
Divisions/Units & EMCs/NSMCs -draft after
and upgrade MTP Confirmation
review-
M
Business
Preconditions

Inform Business Business Divisions/
Divisions/Units and Units to meet
EMCs/NMSCs of IT EMCs/NMSCs
Annual Planning Cycle

Figure 8 ‐ Projects Activity

2.2.4 My support during the Budget activities.
My main tasks during the budget Cycle include the following per Budget category:

• Prepare the templates in
o Making sure that the formulas and links in the templates are working
properly;
o Pre‐filling where available information for the IS management to
facilitate them in completing the documents.
• Support in
o Answering questions of the management with regard to process and
templates;
o Implementing Kaizens when formulas or links are broken in the Excel
templates.

Across the Budget categories and running activities it is
very crucial to manage requests from IS management and implement Kaizens
efficiently.
Especially when the Cycle is up and running and several Budget activities are
simultaneously conducted, it is very important to have an internal Business Planning
PDCA Cycle to check on progress and to act upon issues (and where necessary to re‐
plan activities).
After realeasing the templates to the IS management, they can come up with questions
or concerns while completing this exercise. Questions can range from supporting or
explaining them how to use the documents to the implementation of Kaizens on
formulas and links when they get broken. All documents are created in Excel. This is a

‐ 23 ‐


very good tool but formulas and links that work fine at release can get corrupted when
during the budget exercise rows get added or deleted. Despite the emphasis of not just
merely add or delete lines during the introduction sessions in which the Annual
Planning Cycle is introduced process and template wise, IS management still manage
to do as they please.
Within Business Planning a visual control has been created to list all requests, who has
been assigned to solve them and when they have been completed. In this way we were
able to manage and respond to each request timely.

Budget category: Portfolio Expense
The framework of templates to come to a Portfolio budget has already been prepared
when I started. What still needed to be done was pre‐filling the templates with
information available (in the spirit of providing IS management half‐completed
templates and hereby reducing the time for them to complete the documents).
The information that was already available to prefill this set of templates were taken
from last year’s Cycle. Portfolio items regard the IT support of already existing
applications/technologies/services. This set of items does not change dramatically on
yearly basis. Next to this the budget as was planned for current year is also provided to
create a reference for next fiscal year’s planning.

Budget category: Member Expense
I have supported these activities by prefilling the Member Expense Budget template
for all managers concerned. The pre‐filled information regards the member expense
budget of previous year and the actual expense to year‐to‐date September. This
information was provided out of the financial reporting system by the Financial
Management area of Business Planning itself.

Budget category: Project Expense
From the second day of my internship I have participated in preparing the new Mid
Term Plans for the senior managers. My task was to set out the first draft taking the old
plans and updating them into a new Mid Term Plan template given by TMC.
During the last week before Christmas, all Mid Term Plans of all the IS senior
managers need to be bundled into one file according to TMC standards. I have been
working on this file as well as on updating the high level IS 5‐year plan.
With regard to the Project Budget, I have been supporting the activities by applying
Kaizens on the Project templates throughout the planning Cycle (for example updating
and correcting formulas).

2.2.5 Hoshin
The Toyota Hoshin exists of two sections: IT Processes and IT Products. The first
section defines targets to be reached with regard to IT Management topics, such as
further harmonisation and improvements of business processes and member
development. The second section consists of (large) IT projects that will be carried out
through the new fiscal year, supporting the requirements from TME head office
functions (such as HR, Logistics and Purchasing).

‐ 24 ‐


This year will be the first time that a combined TME IS Hoshin will be created, since
one IT organisation will be implemented as of April 1st. Previously, all three
organisations have their own Hoshin. The challenge this year is to create a combined
one with equal involvement from each organisation. The people involved in this
activity are the top management (in providing feedback) and Business Planning in the
coordination and ensuring quality of this document.


LEGENDS: Summary
Final Document
IS Division
4 IT MANAGEMENT

(Sr. Manager resp.) Divisional Annual
KPIs Internal
Confidential: Reflection
Focus Items
Need to know basis.

GM Approval Previous
Year's
Hoshin

Figure 9 ‐ IT Management Activity

After December the following steps have to be taken to come to a final IS Hoshin in
March:

Annual Reflection

1st draft Review Senior 4th – nth Final IS
2nd draft Executive direction 3rd draft
by BPMO Management draft Hoshin

2010 IS Company
Vision Hoshin

Figure 10 ‐ IS Hoshin after December

NB. These flow charts are not the only tools to visualise the process flow4, other
documents to guard the status of all activities are also being used. For example the
Annual Planning Cycle Master Schedule, which is an Excel file containing all budget
activities broken down per (sub) deadlines. Another tool is the Visual Control FY20075
that visualises the status per manager per (sub) deadline.

2.2.6 My support during the Hoshin creation
The support I provided during the creation of the Hoshin was creating the first draft
before asking for the first input from the Senior Managers. This draft was based on
several documents.
1. the (draft) Regional Hoshin FY07: which is the Hoshin on European level;
2. the 2010 Vision: long‐term goals until the year 2010;
3. Mid Term Plans from each team;
4. Annual Reflection of the Hoshin of previous year.


4 See for an overall overview Appendix 6.2 – Overall Process
5 See for an impression Appendix 6.3 ‐ Master Schedule and 6.4 – Visual Control

‐ 25 ‐


When the Hoshin activity was started up, the Annual Reflection had not been
conducted yet. My only input for the IT Processes section during that period was the
2010 Vision. Creating the IT Products sections was somewhat easier, since I could use
the Mid Term Plans of each Senior Manager as a reference for selecting the largest
projects (based on estimated investment cost). Everything more than approximately
250.000 was selected to be on the draft.
Since this first version, the management and executives have given many comments
and Business Planning made even more adjustments. See Appendix 6.5 and 6.6 for a
comparison between the first draft and the final version of the TME IS Hoshin.

2.3 Differences RDMC/TEDC/TMME IS

2.3.1 Budget Preparation (Project, Portfolio and Member Expense)
Differences have been identified before and during this year’s Annual Planning Cycle.
As expected, the templates that have been used in the previous years needed some
adjustments for TMME IS. One of the main differences is that RDMC IS and TEDC
have teams defined in specific areas and in which the members are set and in general
will not change during the year. Whereas in TMME IS a pool of resources is used in
which the resource’s profile defines whether he or she will work in a project or
portfolio item in a certain area. For TMME IS the templates had to be adjusted in such a
way that managers were enabled to choose out of resource profiles instead of names of
their team members.

Other small but natural differences were the rates per resource profile and the travel
rates for each of the travel destinations. The first is crucial for calculating the budgets of
the portfolios and projects; the latter is necessary in calculating the member expense
budget. A difference between RDMC IS and TMME IS is that TMME IS members have
a higher allowance for having dinner or other expenses when they are on a business
trip.

2.3.2 Hoshin
Thanks to the implementation of the Annual Planning Cycle in all three organisations,
the information that was needed to create the first draft of the Hoshin was already
available.

2.3.3 Manager’s view
How managers see the Annual Planning Cycle is different between RDMC, TEDC and
TMME managers. RDMC has acknowledged after two runs, that this Cycle has shown
an added value to plan as structured as the Cycle prescribes. TEDC has less difficulties
in complying with the guidelines since it has shown the first time that in the end it has
added value. Still some improvements are needed, like creating more awareness in the
importance of good planning and all things connected to that.
TMME however, has never really had the culture that the managers had to
acknowledge their responsibility to plan and align. This should gradually change
through the Annual Planning Cycle, during which they have to plan, review and
obtain approval uptil executive level.

‐ 26 ‐


2.4 Challenge Meetings

Each manager builds his/her plans and budget on these three types. As is common for
many plans and budgets, they need to be approved by the top management. First, the
managers need to check their plans with their senior managers. When they have
agreed on all terms, the general managers will take a look and challenge the figures
mentioned. As of December all budgets must be final and checked.
These meetings are called challenge meetings. During these meetings the managers will
explain any deviations with regard to the previous year, both increases as well as
decreases. A file or system that consolidates all separate budget files of the several IT
teams would come in handy. Until now, no formal consolidation file exists and ad‐hoc
comparison is taking place. My extra assignment was to build a system or a file in
which all amounts were visible and automatically updated and in which graphs were
drawn to further support the review meetings.

Although the process to come to an approved budget is the same for RDMC IS, TEDC
and TMME IS, the reviews of the budgets is still done separately by each organisation.
The Business Planning teams in each organisation will provide the support during and
before the reviews.

2.5 Consolidation Sheet

2.5.1 Basic Idea Consolidation Sheet
Figure 13 shows the setup of a consolidation overview, which will be made for each
organisation. The need to have an overview was identified by the IS Executives
(General Manager and above). They have given direction in what they would like to
have visualised based on the existing budget templates. It should be clear how big the
budget will be in the different Budget Types (Portfolio, Member Expense and Project
Budget). Not only a grand total should be calculated, but since the challenge meetings
are to review the budgets per manager, the totals of these Types should also be
visualised per manager (manager subtotals) grouped by their responsible senior
managers.
Not only the amounts that managers have budgeted for the new fiscal year should be
visualised, to be able to build a case why more or less money will be needed a point of
reference might be useful. This means that the budget of fiscal year 2006 (which is the
current running year) and the forecast for that year should be visualised in the same
categories as well.
This leads to the identification of an overview per Budget Type and per Senior
Manager. The Budget Consolidation Sheet therefore should consist of two ways of
visualising all information available.
Figure 11 gives a schematic overview of how this Consolidation Sheet should be set‐
up.

‐ 27 ‐


Budget Consolidation Sheet Budget Consolidation Sheet

Overview per Budget Type Overview per (Senior) Manager
Portfolio Budget Senior Manager

Manager Manager

Subtotals per Budget Type Category (4) Total Portfolio Budget

Manager Total Member Expense Budget
Total Project Budget
Subtotals per Budget Type Category (4)
Manager
etcetera
Member Expense Budget Total Portfolio Budget
Total Member Expense Budget
Senior Manager
Total Project Budget
etcetera
Manager Senior Manager
Subtotals per Budget Type Category (10) Manager
Manager Total Portfolio Budget
Subtotals per Budget Type Category (10) Total Member Expense Budget

etcetera Total Project Budget
Project Budget Manager
Manager Total Portfolio Budget
Subtotals per Budget Type Category (6) Total Member Expense Budget

Manager Total Project Budget

Subtotals per Budget Type Category (6) etcetera
etcetera
etcetera
(Sub) Totals (Sub) Totals

Portfolio Budget Senior Manager
Subtotals per Budget Type Category (4) Manager
Member Expense Budget Manager
Project Budget etcetera
Subtotals per Budget Type Category (6) etcetera

Grand Total Grand Total

Figure 11 ‐ Setup Budget Consolidation Sheet

The main difference can be found in the classification of the rows. The column
classification will be the same for both overviews. It visualises the amounts needed per
month and totals for the entire fiscal year 2007 (both in units/man days as well as in
euros).

2.5.2 Requirements
Next to the requirements of the basic idea in the previous paragraph the following
features are desired:
- reflect the up‐to‐date data
- graph visualisation of the budget amounts per manager

For the Budget Consolidation Sheet to reflect data, which is up‐to‐date without
performing any manual copy/pasting of figures, I have used formulas that link the
consolidated sheet with the dynamic budget templates that the management use to
draw up their budget. These links will only work well, if the names and locations of
the budget templates are not changed. In other words, version control is only possible
within the document itself and not in the document name. Secondly, it is preferred that
the templates will not be stored in a different location on the network. Another point of
attention is that when rows are added or deleted in the templates, the links to the
correct cells will not be automatically updated in the Consolidation Sheet. So in any
case, a check of the links is necessary through the budget process.

‐ 28 ‐


During the meetings a visualisation of the data would add value to the reviews. The
idea is to visualise the budget of fiscal year 2006, the actual forecasted budget for that
year and the proposed budget for fiscal year 2007.

Please see Appendix 6.7 for the results of this Budget Consolidation Sheet.

2.6 After December

By December 2006 an initial budget has been drawn up and sent to Accounting &
Finance. The remaining months of this fiscal year will be used to finalise the proposed
budget through receiving an approval from Japan. January will be used to explain the
budget through a so‐called Budget Story. This Budget Story should not only contain
the explanation of the differences with previous year, but also of the strategy for next
fiscal year.
The Mid Term Plans need to be aligned with the division and TME Group Hoshins. By
March 31st 2007 everything should be ready to start a new (successful) fiscal year using
the budgets and plans as benchmark.

Another step is a reflection on the past Annual Planning Cycle. As Toyota’s philosophy
is to continuously approve processes, this budget cycle will undergo a reflection on the
success items and the items that need improvements. This year, as TMME IS
participated for the first time, the expectation is that most Kaizen proposals will come
from TMME IS.

‐ 29 ‐


‐ 30 ‐


3 Key Performance Indicators

3.1 Introduction

After defining the planned projects and goals (PLAN), just executing the plan (DO)
and see what you have achieved at the end of the fiscal year will not suffice of course.
If the intention is to make a success of what you have planned, monitoring of the
progress of all the activities related to achieving these projects and goals is necessary
(CHECK). Tracking, analyzing, evaluating, defining and implementing
countermeasures are activities that are inadmissable in achieving the goals. During
evaluation meetings, sharing experiences in encountering and solving similar issues
with other managers will make the problem solving process even more efficient.
One of the ways to track the progress of activities and will therefore enable an efficient
evaluation is through Key Performance Indicators (KPIs).

Key Performance Indicators are measurements that are quantifiable and reflect the
goals and targets to be met. To define good KPIs, they should be SMART and the right
environment should exist.

SMART means
• Specific: it should be clear what the expectations are towards the KPI (when is
one successfull).
• Measurable: a KPI should be quantifiable.
• Agreed To: KPIs should be built on mutual consensus, the understanding of the
target to be achieved should be clear to the people who should realise the KPIs
and the ones who are measuring the performance.
• Realistic: a KPI should motivate the people involved to realise the KPI. When
too high targets are set or it regards a KPI over which they have no significant
control, immotivation already steps in before the activities to achieve them
should start.
• Timely : a KPI should be set against time. It should be clear, when the targets
have to be reached.

The right environment would be one in which the following exist:
• pre‐defined business processes,
• clear goals or performance requirements for these business processes,
• quantitive measurements of results,
• comparison with set goals,
• investigation of variances and
• implementation of countermeasures.

‐ 31 ‐


When KPIs are defined and set, they should remain the same for the years after to
enable annual reflection and comparison. This will contribute to continuously
improving the definition of the goals of next year. KPIs (Check in the PDCA Cycle)
contribute countermeasuring (Act in the PDCA Cycle), which contributes to the
Annual Planning Cycle (Plan in the PDCA Cycle) and this makes the circle go round.

3.2 Toyota KPIs

The KPIs within TME IS are focussed on progress on the several targets set during the
Annual Planning Cycle. These are mainly project process wise defined. So for example
progress on the schedules of projects, progress on spending of the budget to which a
specific item is entitled. Out of scope are IT specific KPIs that for example deal with
risk (mitigation).

The objective in this part of my internship is to

to identify the ideal situation based on Executives direction, find the gaps with the
current situations and propose a new structure for an equal KPI reporting across TME
IS to enable fair comparison and healthy competition.

Within Toyota, the KPI reporting should be used as a management tool rather than
another administrative report to check the progress on each target set during the
Annual Planning Cycle. This is the reason why direction given by the IS Executives
(General Manager and above) is so important.

‐ 32 ‐


4 Harmonising the KPIs

Within the IT activities within Toyota, a distinction has been made between Support
(or Portfolio) and Projects. Support regards all activities conducted to support existing
IT technologies, IT applications and IT services. Project activities regard starting the
investigation, design and implementation of a new technology or application.
With regard to defining KPIs for these two areas, Toyota has identified four different
categories: Time, Quality, Cost and Productivity.

Time Quality Cost Productivity
Project Delay tracking in the Quality during the Cost tracking (plan (not yet
three project phases: three project versus actual) on generally
1. User Requirements phases, based on   investments and defined)
2. Development 1. Resource,   labour expenses.
3. Implementation 2. Process and
3. Product.
Support Meeting the The number of Cost tracking (plan Number of
requirements agreed batch failures on versus actual) on transactions
in Service Level network and data processing on network
Agreements (SLAs). mainframe against items, labour per Full
set targets. expenses and Time
member expenses. Equivalent.

Information for the KPI reports are in general collected on monthly basis and the
reports themselves are also sent out on monthly basis. The reports are sent to the
management.

Currently all three organisations have their KPIs differently identified and visualised.
As Figure 5 shows, RDMC has its KPIs already defined according to the table as
discussed in Chapter 3 – Key Performance Indicators. TMME has taken a few steps to
organise their KPIs according to the four categories. TEDC, which is taking care of the
IT Infrastructure within Toyota Motor Europe, however, has KPIs only based on their
systems and operational activities (for example system outages, helpdesk topics).

For fiscal year 2007, the target is to align the KPIs for the three IT organisations. Since
all three organisations participated in the Annual Planning Cycle this year, the next
step is to identify common KPIs that can be set out in all three organisations. We
should take the different IT activities into account, since taking care of IT infrastructure
implies different stakeholders than deploying new technologies or applications. IT
infrastructure supports the deployment of the new technologies or applications RDMC
and TMME IS is planning. While the deployment of new technologies or applications
supports the business needs of the other divisions within Toyota Motor Europe, such
as HR and Accounting & Finance.

‐ 33 ‐


Aligning is one side of the KPI reporting, what is as important is how the reports are
being used by the management itself. The question is whether the management sees it
as true management tool or more as an administrative tool.

4.1.1 Next steps
Since Toyota’s philosophy is based on Nemawashi (slowly building consensus) and
harmonising the KPIs have many different stakeholders, the aim is to implement this
idea step by step. This process will probably take until July 2007. Of the four categories,
the Cost KPI is the only KPI, which exists in a more or less harmonised way within the
three organisations. The focus will be on rolling out a common way of measuring the
Project KPIs on Time and Quality, since this regards project management and a very
valuable part of making an organisation successful. Next steps would be to put the
focus on improving (Kaizen) the existing RDMC KPIs not only on definition but also
on operational level. These KPIs are already divided into the four categories in the two
areas as discussed in Chapter 3. Secondly, a gradual implementation of Project KPIs on
Time and Quality will be rolled out. After the harmonisation of the entire IT
organisation on April 1st, slow but steady steps will be taken to also implement those
KPIs for the TMME application and technologies as well.

The responsibility on implementing these steps lies at IS Business Planning and I will
take into my portfolio of responsibilities the largest part of the preparation of
implementing the KPI process and training the ones involved into the use of the
templates and reports.

4.2 RDMC

4.2.1 Currently
As said before, within RDMC the KPIs are aligned according to the ideas of Toyota
headquarters in Japan since two years. In other words, seven KPIs are identified,
divided into the four categories and two areas. Only one is missing, which is the
Project KPI on Productivity. To measure the productivity within a project is not a very
easy KPI to define. It already starts with the definition of Productivity: productivity of
the team members involved in the project (time spent versus time planned at start of
the project) or the end result of a (new) application or technology (counting of
functionality points, i.e. the number of functionalities available before the start of the
project versus the number at the end of a project)?
The first option of productivity of team members within a project will need a target
that is clear. It might be useful to track the productivity through predefined guidelines
of how much time a member or contractor should spent on either portfolio or project
activities. On the Hoshin for fiscal year 2007 an item exists that investigates first the
roles and responsibilities of a member versus a contractor. And secondly based on that
how the time allocation on the different activities should be ideally distributed. The
results coming out of this investigation can be used as clear targets to plan for fiscal
year 2008. When “planning” is finalised and “doing” is in progress, “checking” can be
done through tracking the actual spent time against the targets.

‐ 34 ‐


Project Delay tracking in the Quality during the Cost tracking (not yet
three project phases: three project (plan versus generally
1. User Requirements phases, based on   actual) on defined)
2. Development 1. Resource,   investments and
3. Implementation 2. Process and   labour expenses.
3. Product.
Exists Exists Exists Not available
Support Meeting the The number of Cost tracking Number of
requirements agreed batch failures on (plan versus transactions on
in Service Level network and actual) on data network per
Agreements (SLAs). mainframe against processing items, Full Time
set targets. labour expenses Equivalent.
and member
expenses.
Exists Exists Exists Exists

All information is available in Excel sheets. The KPI report is created in Excel as well.
See Appendix 6.8 for an impression of such a KPI report.
Of the seven KPIs, two KPIs are updated on weekly basis (see the colored cells) and the
other five are updated on monthly basis. The weekly KPIs are the Project KPIs on Time
and Quality. This should visualise and enable the management to implement
countermeasures timely. The monthly KPIs will be discussed during so called M3
meetings (these are meetings with Senior Managers and above). Senior Managers
should explain the issues raised, which are shown on the KPI reports.

Next to the high‐level overview (RDMC IS total overview), two pages (divided into the
two areas: Project and Support) exist with detailed information per Senior Manager
and another page with detailed information about the delays that occur during that
week per project phase. This information should include what the issue is and what
will be the countermeasure to solve this issue.

Currently RDMC IS Business Planning sends out the KPI reports. The information
gathered for creating the KPI reports come from different locations and are manually
filled into the KPI reports to create the graphs. This is a time consuming activity: it
takes almost two days to gather and update all the data. Next to this, manual input
does not give 100% guarantee of showing the real data. An input error is soon made,
especially when in a hurry. The objective is to automate the input of the updated data
as much as possible.

Right after the User Requirements phase a review should occur of the expected benefits
versus the investment costs that have to be made during that project. This review
should ensure that all stakeholders agree on the schedule, costs and benefits of that
specific project. This review is called a Ringi review and should be preceeded by a Story

‐ 35 ‐


Line review, which is basically a Nemawashi activity for this project to achieve an
approval of the Ringi. The Story Line review should happen at least one month before
the actual Ringi has to be approved. Without a Ringi a project is not allowed to
conitnue. Therefore it is important to have an overall Story Line and Ringi schedule
visualised. This will enable follow‐up of which projects are progressing after the User
Requirements phase without a Ringi. In summary: a schedule containing all projects
for which a Ringi is required will provide in the need:

1. To ensure that an alignment between all stakeholders takes place;
2. To enable budget tracking for Ringi projects;
3. To enable follow‐up when a Ringi review has not taken place, but the project is
still progressing.

Currently this schedule is updated through a weekly follow‐up through e‐mails or
phone calls to managers. An idea is to include these milestones as well in the schedules
of the projects in the Weekly KPI Templates.

4.2.2 Next Steps
Next steps are

1. to map all the documents that are used to create the KPI reports and to
automate the input of the updated data as much as possible;
2. to create the new Weekly KPI Templates per Senior Manager for next fiscal
year;
3. to update the guidelines for the Weekly KPI Templates;
4. to communicate to the Senior Managers, that the new templates are ready for
set up for next fiscal year;
5. to follow up on the set up by the Senior Managers;
6. to finalise the set up and create the KPI report format to be used for fiscal year
2007 with the updated automated links.

1. Mapping of the documents
In the table here below an overview can be found of all documents that are needed to
create the KPI report:

‐ 36 ‐


Project Weekly KPI Wall Charts Budget Not available
Template (updated per Consolidation
(created by Business project by the Sheet
Planning but responsible (supplied by
updated by Sr. Mgr. projectmanagers on Business
on weekly basis, weekly basis) Planning on
containing the monthly basis)
schedules of the Weekly KPI
milestones per Template
project) (created by
Support SLA reports Failure Reduction Business Headcount
(supplied by TEDC Reports Planning but data
on monthly basis) (supplied by TEDC updated by Sr. (supplied by
on monthly basis) Mgr. on monthly Business
Major Trouble basis with Planning on
Reports explanations monthly basis)
(supplied by TEDC about differences
on monthly basis) in plan and
actual)

In the KPI report a tab exists in which the numerical data is collected from these
different files. Currently these data are copied and pasted into the KPI report. I have
identified what information is suitable to automate to gain time efficiency: Weekly KPI
Template, Budget Consolidation Sheet, SLA reports, Failure Reduction Reports.
The data section contains all data needed to create the graphs for the Project and
Support KPIs. To maintain some easy overview, I have created two Data tabs, one for
Project information and one for Support information. Next to this I have listed all files
from which the information has to be extracted.

Figuur 12 ‐ Data Tab Previous

‐ 37 ‐


In the Kaizened version of the KPI report, I have made distinctions in the data that are
fed automatically from other files by colouring them blue. In this way, it is clear what
still should be checked manually and what not. Yellow cells are cells that contain
mathematical formulas.

2 & 3. New Weekly KPI Templates and update Guidelines.
The Weekly KPI Template consists of two major sections: Project Management and
Budget. The Project Management section is based upon the Project Management
Methodology that describes the different phases a project has to go through. Each
project phase is concluded with a milestone. In the Weekly KPI Templates these
milestones are visualised in a schedule overview. If a delay occurs in achieving these
milestones, the managers have to give an explanation. An explanation should contain
at least the project name, who is responsible, what the cause of the delay is, what
countermeasures are taken and by when they expect to have this solved.
The Budget section visualises the planned amount and the actual amount. When
variances occur, the managers have to explain the reasons why (delayed project,
less/more resources needed than planned, etc).

For the new fiscal year this template has to be set up again:
• adjusting the calendar from fiscal year 2006 to 2007,
• checking whether all the formulas are still correct,
• creating templates for each senior manager.

For a detailed explanation about the creation and use of the Weekly KPI Template, I
refer to Appendix 6.9, where I have included the guidelines of the Weekly KPI
Templates.

‐ 38 ‐


4, 5 and 6. Finalise the set‐up
After creating the templates for each of the senior managers, it was time to send out the
communication towards the management that they can fill in their project schedules.
Not every project should be in this template, only projects that require more than 20
man‐days or require a Ringi approval. Basically the projects that are on the Annual
Plan that had to be set up as part of the Annual Planning Cycle should be in this
Weekly KPI Template as well.
Managers had the time to finalise this until the first week of April. Experience shows
that it will take more time; so following up is essential to reduce the delay in finalising
as much as possible.
After the managers have confirmed that they have filled in their projects, I will make a
final check whether everything has been correctly filled in. After this, the template is
ready for use.

During the process of implementing the new templates and discussion with the
managers, I have noticed (not in so many words, but more in attitude) that most of the
managers see updating the templates as a burden. Some managers even delegate the
updating to administrators who often have nothing to do with the projects that need
reporting. Although it takes no more than 10 minutes (when no delays occur) to 30
minutes (when explanation is needed because a delay occurs) to update the templates,
managers still don’t meet the deadlines set to update the templates. This causes more
workload for Business Planning members to come to a realistic and reliable issue of
reports and more workload at the end of the month to all when managers realise that
during the next Senior Management meeting their issues will be discussed.

4.3 TEDC

4.3.1 Currently
Within TEDC, no distinction exists between Support and Project. Small and large
impact projects are all included in the KPI reporting. No categorization in Time,
Quality, Cost and Productivity exists. Next to this, the KPI report is sent out on
monthly basis together with the TMME KPI report. Tracking of the cost is done
differently than within RDMC. Next to all of this, managers have not really been asked
to provide some input from their own when differences occur.

‐ 39 ‐


Project Delay tracking in the Quality during the three Cost tracking (not yet
three project phases: project phases, based on   (plan versus generally
1. User Requirements 1. Resource,   actual) on defined)
2. Development 2. Process and   investments and
3. Implementation 3. Product. labour expenses.
Support and Project Support and Project Support and Not
Combined, not per Combined, not per Project available
project phase project phase Combined, not
included in KPI
report
Support Meeting the The number of batch Cost tracking Number of
requirements agreed in failures on network and (plan versus transactions
Service Level mainframe against set actual) on data on network
Agreements (SLAs). targets. processing items, per Full Time
labour expenses Equivalent.
and member
expenses.
Not available Support and Project Support and Not
Combined Project available
Combined, not
included in KPI
report

4.3.2 Next Steps
While doing this exercise of trying to find a harmomnised KPI report, it became clear
due to political sensitivity within the organisation that a step‐by‐step approach has to
be conducted. This has lead to the decision that during my internship the Project KPI
on Time should first be implemented. The other KPI reporting as is currently in
existence will still be continued and step‐by‐step transformed into a more aligned
report.
Within TEDC, the Project Management Methodology was different than within RDMC.
It has been decided that it would be meaningful to track the Ringi review progress and
when the project has finalised the implementation phase. During the development
phase no specific or general defined milestones exist, so tracking as is done through the
Weekly KPI Template will not be possible.

The way to proceed was:
1. Create the Weekly KPI Template, TEDC guidelines and TEDC KPI report;
2. Introduce this Project KPI to the TEDC management;
3. Introduce the way of capturing the data to the TEDC management;
4. Assist the managers into setting the Templates up;
5. Issue the first TEDC KPI report.

‐ 40 ‐


1. Create the Weekly KPI Template
The same procedure as when creating the RDMC Weekly KPI Templates should be
followed. I would like to refer to paragraph 4.2.2 Next steps.

2 & 3. Introduction of the Project KPI and way of capturing the data
The introductions took place through meetings with the management. During these
sessions I have introduced the KPI report to the TEDC management and the way that
the data should be captured. Starting with the purpose (PDCA Cycle), followed by the
categorisations and ending with showing the Weekly KPI Template.

4. Assistence of managers in the set‐up
During this period I have been available when managers had questions while they
were setting up the Weekly KPI report.

5. First issue
The first issue has been planned in the third week of April. It is expected that it will
take some time before this way of reporting will settle in and of course that the
managers may have comments and Kaizen proposals, that are more than welcome. Just
introducing a KPI to the management is one thing, but all persons involved should
agree upon a KPI and a two‐way communication is therefor very important.

The implementation of this KPI is still quite young. It is at this moment a little different
how the managers will see this way of reporting. My experience until now is that all
managers are quite cooperating and are asking valuable questions while they are
working with the templates. They currently realise, that if they update on regular basis,
that the workload will not exceed their normal workload. The future still has to show
whether their attitudes will remain the same, when more projects are kicked off and
they will have less and less time on their hands. But for now, everything looks good.
The major difference is that Business Planning is asking the managers to take
responsibility into their punctuality and accuracy of their updating. This at least gives
back the responsibility to the managers of explaining issues during management
meetings.

4.4 TMME

4.4.1 Currently
Within TMME KPI reporting the categorisation in Time, Quality, Cost and Productivity
already exists, but no clear definition of Project and Support has been defined yet.
Since it has been decided that implementing a more aligned approach to KPI reporting
is something for the (near) future, I have only captured what the current situation is.
Next steps are still to be defined and will be achieved through Nemawashi from
executives level spiralling down to managers and members level. One thing is for sure

‐ 41 ‐


though: alignment will take place and managers will be asked to take responsibility in
it!

Project Delay tracking in the Quality during the Cost tracking (not yet
three project phases: three project (plan versus generally
1. User Requirements phases, based on   actual) on defined)
2. Development 1. Resource,   investments and
3. Implementation 2. Process and   labour expenses.
3. Product.
Support and Project Support and Support and Support and
Combined, not per Project Combined, Project Project
project phase not per project Combined Combined,
phase, based on based on
compliance of counting
project function
deliverables points
Support Meeting the The number of Cost tracking Number of
requirements agreed batch failures on (plan versus transactions on
in Service Level network and actual) on data network per
Agreements (SLAs). mainframe against processing items, Full Time
set targets. labour expenses Equivalent.
and member
expenses.
Not available Not available Support and Based on
Project actual billable
Combined Mandays,
spent on
billable
projects

See Appendix 6.10 for an impression of how a TMME and TEDC KPI report looks like.

‐ 42 ‐


5 Conclusion

The objectives for my internship were to support during the Annual Planning Cycle
and Kaizening and harmonising the KPI reporting process. Next to this, the focus
should be on the analysis whether the management tools that have been implemented
to support the PDCA Cycle are actually used as management tools and not as
administrative ones. The Annual Planning Cycle should be used as a tool to Plan
(PDCA) and KPI reporting as a tool to Check (PDCA).

With regard to the Annual Planning Cycle, my experience is that this seems to work
quite well. At least within RDMC and TEDC, the Cycle is well known and most
managers completed this Cycle without many issues than the usual ones (lack of time,
etcetera).
Since TMME has gone through this Cycle for the very first time, it was expected that
from their side many concerns were raised and more effort was needed from Business
Planning to coordinate this and bring it to a good end.
For some managers the concerns were more focused on financials, although the Cycle
is a tool to plan. Budget will follow naturally.
But all in all, everything came to a good end and good hopes are to start with a new
Cycle for next fiscal year in October this year (of course after identification and
implementation of another set of Kaizens). The Annual Planning Cycle can be called a
success with regard to the further harmonisation of the IT Business Processes.

Since the Annual Planning Cycle has now been implemented within all three IT
organisations, it will now also be easier to start tracking in an aligned and harmonised
way across all teams. This phase still has to be completed, but gradually it will happen.
Currently, the KPI reporting is not really used as a management tool. Some managers
see it as an administrative tool (since some delegate the responsibility of updating to
administrators who are not participating in projects). In the Toyota culture, this should
be done through Nemawashi and step‐by‐step approach. During this fiscal year more
steps should be taken to further harmonise and create healthy and fair competition
between the IT teams. KPI reports as a management tool to check can play a key role in
achieving this.

‐ 43 ‐


‐ 44 ‐


6 (Appendix)

‐ 45 ‐


‐ 46 ‐


6.1 TME IS teams.

‐ 47 ‐


‐ 48 ‐


6.2 Annual Planning Cycle – Overall Process

‐ 49 ‐


‐ 50 ‐


6.3 Annual Planning Cycle Master Schedule

‐ 51 ‐


‐ 52 ‐


6.4 Annual Planning Cycle – Visual Control

‐ 53 ‐


‐ 54 ‐


6.5 Hoshin – first draft

‐ 55 ‐


‐ 56 ‐


6.6 Hoshin – Final

‐ 57 ‐


‐ 58 ‐


6.7 Budget Consolidation Sheet.

Please see attached file: A. Budget Consolidation ‐ RDMC ‐ v11.xls

‐ 59 ‐


‐ 60 ‐


6.8 KPI report – front page

For a more detailed look I would like to refer to the attachments:
B1. TMEM IS KPI report 301006.xls and B2. TMEM IS KPI report 160407.xls.

‐ 61 ‐


‐ 62 ‐


6.9 Guidelines Weekly KPI Template

Please see attached files:

C1. Guidelines to Using the RDMC Application Weekly KPI Templates FY2007.xls
C2. Weekly KPI template Miles 200.xls
C3. Guidelines to Using the Weekly KPI Templates TEDC FY2007.xls
C4. OPS‐07‐Weekly KPI template Jean‐Marie 200.xls

‐ 63 ‐


‐ 64 ‐


6.10 TMME and TEDC KPI report

Please see the attached file:

D. 24‐26. TME ITG, Achievements & KPIs, 200610, Q2, v0.11.xls

‐ 65 ‐

toyota pdca

More Related Content

What's hot

Viewers also liked

Similar to toyota pdca

toyota pdca