Content uploaded by Magnus Wiktorsson
Author content
All content in this area was uploaded by Magnus Wiktorsson on Dec 17, 2015
Content may be subject to copyright.
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
1
Lean automation development: applying lean
principles to the automation development process
Anna Granlund (anna.granlund@mdh.se)
School of Innovation, Design and Engineering
Mälardalen University, Eskilstuna, Sweden
Magnus Wiktorsson
School of Innovation, Design and Engineering
Mälardalen University, Eskilstuna, Sweden
Sten Grahn
Swerea IVF AB
Stockholm, Sweden
Niklas Friedler
School of Innovation, Design and Engineering
Mälardalen University, Eskilstuna, Sweden
Abstract
By a broad empirical study it is indicated that automation development show potential of
improvement. In the paper, 13 lean product development principles are contrasted to the
automation development process and it is suggested why and how these principles can
facilitate, support and improve the automation development process. The paper
summarises a description of what characterises a lean automation development process
and what consequences it entails. Main differences compared to current practice are also
identified. The incentives for, and expected effects of, applying the identified lean
principles to the automation development process are discussed.
Keywords: Automation development, lean, process development
Introduction
Automation is a well-known means of improving productivity, efficiency, quality and
safety as well as lowering cost in operation. However, in spite of the numerous benefits
and advantages that automation offers, it is not always the best solution and in some cases
it is not even a feasible one (Groover, 2008; Cruz Di Palma and Basaldúa, 2009; Spath et
al., 2009). Actually, the wrong technology, or even the right technology poorly
implemented, can be disastrous (Baines, 2004). Further, previous research shows that the
main problems with automation are not associated with the actual automation level or the
lack of technology, but rather with its implementation and difficulties in choosing and
incorporating it (Sambasivarao and Deshmukh, 1995; Durrani et al., 1998). The key to a
successful use of automation therefore lies in finding, selecting, acquiring and properly
implementing the right type and level of automation in relation to the company’s needs,
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
2
goals and prerequisites (Baines, 2004; Säfsten et al., 2007; Daim and Kocaoglu, 2008;
Ceroni, 2009; Spath et al., 2009). The process of developing automation, which includes
all these steps, is thus a crucial part in determining the success of automation investments
and thus reaping the benefits of automation (Baines, 2004; Spath et al., 2009). However,
while the importance of the automation development process is clear it is in practice often
time consuming, costly and experienced as difficult to manage (Granlund and Jackson,
2013; Granlund, 2014).
The development of complex socio-technical systems, which the development of
automation solutions could be described as, have been the object of study within multiple
fields of research. One field contributing to this subject is the lean product development.
Lean production has in manufacturing industry been recognized as a means for achieving
competitive advantage by focusing on two primary objectives: eliminating waste and
creating value for the customer. Authors such as Morgan and Liker (2006) see that “lean
thinking” can also, with great positive effects, be applied to areas outside the actual
manufacturing operations such as to development processes where lean product
development (LPD) is one example which has received much attention with proved
benefits.
With the overall aim to support the successful use of automation in industry, the
research presented in this paper investigates how the automation development process
can be facilitated and improved by adopting a lean mind-set. The objective is therefore to
investigate how LPD principles can be applied to facilitate and improve the automation
development process and thus support successful use of automation in industry.
Background to Lean Product development
Lean thinking is an improvement philosophy focusing on the creation of value and the
elimination of waste. Lean production is a well-researched area but there has been
comparatively less research done to apply lean thinking to product and process
development (Khan et al., 2013) and there is a clear lack of a consistent theory base for
LPD (Hoppmann et al., 2011).
The roots of LPD, just like lean production, goes back to Toyota. Khan et al. (2013)
identifies five different approaches that researchers and practitioners have taken to LPD.
These are in overview:
1. Rebranding concurrent engineering as LPD.
2. Adopting ideas from Lean production to product development in combination with
other theories.
3. Integrating elements of the Toyota Product Development System (TPDS) with Lean
production principles and methods and applying them to product development.
4. Describing Toyota concepts based on a case study of TPDS.
5. Practitioners attempting to apply Toyota concepts in product development.
Authors from the fourth category have received the most attention trough their careful
studying of the product development practice at Toyota and by capturing the essences of
TPDS which entails more than just lean production principles applied to the product
development process. One description of the TPDS is by Morgan and Liker (2006) who
have distinguished and presents 13 LPD principles divided in three sub-systems based on
the three elements of the socio-technical model: people, process, and technology. These
13 principles are in overview listed in Figure 1. Morgan and Liker (2006) however
emphasizes that these principles do not exist in isolation, insulated from each other and
the outside world. Instead they interact, overlap and are interdependent and work together
to create a coherent whole.
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
3
Figure 1 – The 13 Lean product development principles structured in three subsystems.
After Morgan and Liker (2006)
In line with the first principle Ward (2009) point out that the foundation in a Lean
Development System is understanding what is value in development before you can
design the system that should produce it. When designing the system, focus should with
a lean mindset be to eliminate waste in the process. In product development, there are two
broad categories of waste (Morgan and Liker, 2006):
1. Waste created by poor engineering that results in low levels of product or process
performance.
2. Waste in the product development process itself.
Besides the central value focus, Ward (2009) present four “cornerstones” of LPD:
Entrepreneurial System Designer, Teams of Responsible Experts, Set-Based Concurrent
Engineering (SBCE) and Cadence, Pull and Flow. SBCE (also lifted by Morgan and Liker
(2006) in their second principle) is an important aspect of LPD since paradoxically, as in
the case of Toyota, delaying decisions and following a large number of alternatives for
the same product module contributed to better and faster product development (Ward et
al., 1995).
Another main key to Toyotas success is the high degree of integration (Sobek et al.,
1998) both between product design and manufacturing-process design and between other
business functions. The incorporation of new knowledge into checklist or similar to be
applied to all the company’s products is also identified by Sobek et al. (1998) as a key to
success and thus an important part of LPD.
Method
In order to investigate how the automation development process can be improved, current
practice in industry has been mapped through interviews and participant observations.
The process of developing automation has, during the years 2008-2013 from different
aspects, been investigated at 32 companies through a total of 76 interviews. The
companies were mainly producing companies in various lines of businesses, but to cover
a wider sample were also warehousing and distribution centres as well as hospitals
included, but underrepresented. The sizes of the participating companies ranged from
small to large, but medium and large sized companies dominated the selection. The
interviews performed were of semi-structured character and ranged from 15 to 95
minutes. The primary interviewees were production managers, production engineers and
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
4
project managers responsible for or involved in automation development at their
respective company. These interviews covered the way of working with automation
development and with special focus on mapping and understanding the process and its
underlying structure. Ten factory and/or purchasing managers responsible for automation
investments were also interviewed to cover how the aspects of value and benefit were
considered in the automation development process.
At three of the companies (one small, one medium and one large sized manufacturing
company) the automation development process was followed and studied in real time
through participant observations. The development processes studied ranged from seven
to 14 months, not including the implementation phase which was only covered by follow
up interviews. During the development processes, at least ten workshops and/or project
meetings were attended during each process and complementary interviews were
conducted to get a complete picture of the process. Focus was on mapping and
understanding what was done, how and why, and to identify prerequisites to and
experiences form performing automation development.
All gathered data have been used to create a view of common practice on automation
development in industry. The data was also analysed to identify problems and weaknesses
in the current way of working. The described state-of-practice from the industrial studies
has then been contrasted to the LPD literature to identify differences and improvement
potentials.
Empirical findings
The empirical studies of current automation development practice revealed numerous
successful cases of automation and organisation for automation, contributing to highly
competitive solutions and companies. However, the studies also indicated seven
characteristics in need of further development, elaborated in the following.
• Lack of processes, routines and support documents for automation development
• Reliance on key individuals and automation experts
• Automation development seen as a procurement effort
• Lack of automation strategy
• Non-defined value of automation
• Unclear responsibility of automation
• Dependency of system suppliers or integrators
The empirical studies of current automation development practice made evident that
in the vast majority of the companies studied, the automation development process is
conducted in an ad-hoc manner. Only at a handful of the respondents’ companies did a
process model particularly adjusted for automation development exist. In most companies
were processes including established routines and support documents suitable for
automation development lacking. Several respondents conveyed that they and their
collages respectively, based on their own experiences and know-how, had developed their
own way of working during the automation development process. This also led to unclear
decision points during the automation development process.
The studies also indicated that there, even in the larger companies, often is only a few
individuals that have knowledge and experience in automation. There is both a strong
dependency on these individuals during the development processes and the success of
past automation measures were also often credited to the contribution of these individuals.
Another common practice that emerged was that the resulting automation solution was
decided early in the development process, in some cases to the extreme that a decision
for a particular investment was the trigger for the automation development process. In the
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
5
cases a formal process existed, it was typically used for investment projects and the
project gates were closely related to the gates in the formal purchasing order document
used by the company. In the development process there is thus a strong focus on
technological solution development or procurement and comparatively little time is spent
on the early phases such as mapping and clarifying of needs, goals and prerequisites, apart
from the material that is needed for a formal request for quotation. As a result there is
often a poor base for evaluation and decision making and decisions during the process are
thus often made ad-hoc. Also, as a result of the lack of process models there were often
no or few clear decision points during the automation development process. The
importance of a thorough specification of requirements for a successful outcome the
automation development was understood, but there was poor support for formulating it,
both from the point of view of the content and process.
There was most often a lack of, particularly strategic, motivation and overall view of
the desired way of working with and using automation. This often resulted in miss-fitting,
or one of a kind solutions with limited strategic alignment between them and in relation
the overall operations in which the automation should be part. The findings also indicated
a narrow understanding and definition of the customer value that is expected and desired
from automation measures. Actual customer value was also poorly evaluated.
Another key character is an often common awareness within companies, of the limited
time spent on both defining desired value and on evaluating actual value. Instead,
consistently high value from automation projects is assumed to come as a result of
standardised investment procedures. That is, standardised acquisition, installation and
documentation procedures are assumed to lower investment and operating costs, thereby
increasing the value from automation. However, many of the companies seemed to make
the same mistakes over and over again and this was analysed as a result of poor or lacking
evaluation and follow up both of the investments itself but particularly on the
development process. At a few of the companies studied it was routine to write a white
paper after each automation project. However, the interviews revealed that these papers
were rarely used or considered in future projects. Also, in many of the companies studied
the development process and the decisions made during it were scarcely documented,
making evaluation and thus the generation of lessons learnt difficult. There was also
seldom routines for how to work with reviewing, improving and standardising of the
automation development process.
Further, the responsibilities of different functions during the automation development
process is often unclear and some tasks and activities in the process are often divided or
assigned to be performed by certain departments or functions rather than by the cross
functional project group. In the cases where use of cross-functional project groups were
well developed and applied throughout the process, it was experienced that projects were
more successful in terms of better adjusted solutions. In some of those cases the
respondents also saw a faster and more efficient development process. Also, staff
commitment was raised and the often experienced resistance towards automation was
considered to decrease as a result of the use of cross functional teams.
All case companies studied engaged system suppliers or integrators, at least at some
stages in the automation development process. The stage in the automation development
process when companies were most likely to engage a third party, was when alternative
automation solutions were to be developed. The stage when companies were least likely
to involve a third party, was when problems or possible areas of improvements were to
be identified. This was, however, one of the stages considered most difficult in the
improvement process. Most companies were, to varying degrees, thus dependent on third
parties during the automation development process. It was, however, especially by the
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
6
companies with limited automation knowledge and experience considered difficult to find
an appropriate level of collaboration with system suppliers. Respondents explained that
the third party could take too much control over the project, which in some cases had
resulted in a solution that did not fit into the rest of the production system or in a solution
that the company could not operate after the implementation. A few respondents had also
experienced problems during collaboration regarding who owned or were responsible for
the implemented solution.
Analysis and discussion
One of the most influencing differences between the identified common practice in
automation development and LPD practice is related to the value focus advocated by
Ward (2009) and included in the first principle by Morgan and Liker (2006). The narrow
or insufficient identification and definition of desired value from automation measures
creates poor prerequisites for the establishment of requirements and thus the base for
evaluation and decisions.
A thorough establishment and definition of value would come as a natural part in a
front-loaded automation development process (principle 2), which in common practice is
not the case since focus instead is on solution development. A stronger focus on the early
phases that besides establishment of value also should include identification of the
customers’ needs and requirements and mapping of the organisation’s goals and
prerequisites would create a better base for evaluation and decisions. It was in the current
practice identified that decisions were often taken early in the process and in an ad hoc
manner, something supported in literature (Säfsten et al., 2007; Winroth et al., 2007). The
often poor base for evaluation and decision was in turn identified as one of the main
reasons to miss-fitting solutions or in other ways unsuccessful uses of automation.
A SBCE-practice, advocated as one of the cornerstones of LPD and in focus in the
second LPD principle, would translated to the automation development process entail a
process where several solutions (both several automation based solutions but also
alternative solutions) are explored during the development process and the decisions of
which solution to implement is made later in the process compared with the common
practice. A strategic view of the desired use and way of working with automation and its
development would be a large support and give input to and help develop solutions and
decision making along the process. This strategic view, preferably in the form of an
automation strategy, would be constructed to ensure the adoption of the right technology
for the given prerequisites, corresponding to principle 11.
Another identified main difference between LPD and common automation
development practice with large impact on the process and its outcome is the aspect of
standardisation and particularly the fourth LPD principle. Common practice indicated that
few companies have or use a standardised process suitable for automation development
but there was in the same time a high confidence that consistently high value from
automation projects would come as a result of standardised investment procedures. In
order to achieve this, the automation development process must be standardised and
process support in terms of routines and other support documents suitable for automation
development must be established to facilitate the process and make a standardised
structure possible.
When developing a standardised process for automation development it is important
to identify and involve key individuals in the company with knowledge and experience
in automation development and make use of their expertise. These individuals are
highlighted by Meredith (1987), who addresses “automation champions” and their role in
successful automation projects. The role of these key individuals/automation champions
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
7
can thus be compared to the chief engineers pinpointed in principle 5 and which should
have a prominent role during automation development.
Even though the chief engineer should have a leading role during automation
development it is also of great importance to spread knowledge internally in the company
to avoid the strong dependency of individuals identified in common practice. This is
addressed in principles 6 and 7. Having clear, structured and well supported routines for
the automation development process (a need concluded above) would support especially
inexperienced staff during this process and thus help share responsibilities (principle 6)
and even the workload (principle 3) but also support additional individuals building
experience and knowledge in automation and its development.
Bringing back knowledge into the automation development process is also a key task
in the continuous improvement mind-set representing lean. The empirical studies
however revealed an often insufficient evaluation and follow up and that the companies
seldom made use of lessons learnt, something being an important part of SBCE (Sobek
et al., 1999; Ward, 2009). This was analysed as partly caused by an ad hoc decision
process and poor documentation of the process. As advocated in principle 9 it is important
to build in learning and continuous improvements during the automation development
process and this can be supported and facilitated by a structured and standardised
development process dealt with above. The process should for example include steps and
routines for decision making and evaluation and follow up (of both the process and its
outcomes) as well as the aspects of when and how documentation is to be made during
the process (principle 13). Also Baines (2004) addresses the importance of explicitly
documenting knowledge in his suggested technology acquisition process by creating
databases and portfolios. To enable this built-in learning and continuous learning
improvement, it is important that the tenth principle is in place and that the crucial
commitment is secured which as shown in common practice can partly be achieved
through the use of cross-functional teams throughout the entire process. Commitment can
however seldom be secured without guidance and understanding for the process. It is thus
important to in an accessible way communicate the company’s automation strategy
including the desired way of working with and during the automation development
process which is incorporated in principle 12.
During the empirical studies there were accounts of how the strong reliance on third
parties had caused unsuccessful automation investments that poorly met the companies’
needs and prerequisites. It is however argued that the cause of these unsuccessful
investments is not necessarily in the actual involvement of third parties during the
automation development process but rather in the way that they are involved and how the
responsibility is divided. Involving third parties during automation development is an
excellent way to access state-of-art competence and compensate for and help overcome
lacking knowledge about automation and its possible applications, especially when it
comes to new technology (Daim and Kocaoglu, 2008). However, the identification of
problems and possible areas of improvements was the step in improvement work that the
companies most often chose to do themselves and not involve third parties, i.e. not taking
advantage of them in one of the steps perceived as most difficult and being important
from the front-loading perspective of LPD.
Also, previous unsuccessful investments identified in the studies can also be traced to
the customer’s (the company buying the service from the third party) lack of insight into
and understanding of the automation development process, the limited insight in desired
value and poor base for decisions that leads to inappropriate selection. This is especially
a risk when relying too heavily on the third party and letting them take the decisions
without proper insight into either prerequisites, requirements or goals, something that
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
8
should be provided by the customer for a successful supplier-driven approach (Säfsten,
2002). Principle 8 in combination with principles 1, 2 and 11 is thus of the most decisive
importance in overcoming this particular problem and improving the automation
development process.
Table 1 summarises how the identified 13 LPD principles can be translated to the
automation development context. In the table, the corresponding 13 Lean Automation
Development (LEAD) principles are listed and briefly explained.
Table 1 – The 13 Lean Automation Development (LEAD) principles
LEAD principle Main features/motivation
Process subsystem
1. Establish customer-defined value to
separate value-added from waste.
Understand the customers’ needs and define desired value
from automation measures. Develop an automation strategy
supporting a value adding process and outcome.
2. Front-load the automation
development process to thoroughly
explore alternative solutions.
Focus on early phases to map customer needs, goals and
prerequisites and create a detailed and firmly based
specification of requirements. Explore, develop and evaluate
alternative solutions and push the decisions for actual solution
late in the process.
3. Create a levelled automation
development process flow.
Level the workload throughout the process and divide and
schedule responsibilities across functions/ departments/
individuals. Avoid overloading key individuals creating fragile
systems.
4. Utilise rigorous standardisation to
reduce variation and create flexibility
and predictable outcomes.
Develop a standardised automation development process.
Develop and establish suitable process models, routines and
support documents
People subsystem
5. Develop a chief engineer system to
integrate development from start to
finish.
Appoint a chief engineer representing the voice of the
customer managing integration and decisions making along
the process.
6. Organise to balance functional
expertise and cross-functional
integration.
Identify and acquire key knowledge/expertise necessary for
automation development and distribute over functions.
7. Develop towering technical
competence in all engineers.
Make sure knowledge/expertise is transferred internally to
create a robust system less dependent on individuals.
8. Fully integrate suppliers into the
automation development process.
Involve third parties early in the process and make sure they
have a complete picture of the needs, goals and prerequisites
in order to make appropriate decisions.
9. Build in learning and continuous
improvement.
Make sure there are routines and support for knowledge
transfer, evaluation and follow up as well as continuous
improvement of the process.
10. Build a culture to support excellence
and relentless improvement.
Be open and communicate the automation strategy and
explain how it is structured to create value. Value process and
structure observance and lead by example.
Tools and Technology subsystem
11. Adapt technology to fit your people
and process.
The automation strategy should act to support value adding
automation measures and make sure the right type and level
of automation for the given the prerequisites is developed and
that suitable tools and technology is used during the
development process.
12. Align your organisation through
simple, visual communication.
Communicate the automation strategy and visualise the
development process, both planned and actual outcome.
Make sure it is clear who is responsible for what and avoid
information/communication overload.
13. Use powerful tools for
standardisation and organisational
learning.
Make sure there are standardised routines for all steps in the
development process, that they are followed and continuously
revised.
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
9
Conclusions and areas of future research
The research concludes that lean mind-set and principles can be transferred to the
development of automation. This since the essence of this process is to, in an effective
manner (by eliminating waste) find the automation solution giving the best benefits to the
company (i.e. best correspond to the customer´s needs). The lean development practice
have previously been well elaborated in product and software development contexts, but
more rarely in production system settings, and particularly not concerning automation
development.
The empirical studies indicate that in current automation development practice main
focus is on technological solution development and comparatively little time is spent on
clarifying needs, goals and prerequisites. This is possibly a cause of ad-hoc or
unstructured development processes. Further, while companies are heavily dependent on
third parties such as system suppliers, they are at the same time experiencing difficulties
cooperating with them. The involvement of third parties can support the use of automation
but the successful involvement is dependent on the manufacturing company’s
understanding of the development process and its ability to provide the base for
appropriate evaluation and decisions. Current practices also involve miss-fitting solutions
with limited strategic alignment as well as a narrow understanding and definition of the
value that is expected and desired from automation measures. Actual value is also poorly
evaluated.
By developing a process to better establish, define and evaluate value and by front-
loading the automation development process, it is believed that the requirement setting
can be improved and thereby reducing the risk of miss-fitting solutions. Organising to
balance expertise, integrate suppliers into the development process and to make better use
of cross-functional teams during the process is also relevant for identifying, selecting and
developing an appropriate automation solution. Furthermore, technological development
rapidly changes automation possibilities, challenging the efforts on standardization,
initiated to secure long term value from automation projects. Finally, other areas of lean
automation development, such as a levelled and standardised development process and
built-in learning and continuous improvement processes will improve the process and
increase the successful use of automation.
By adapting a lean mind-set to the process of developing automation, the waste in both
the development process and the resulting solution can be reduced. A lean automation
development process can contribute to sustainable automation solutions which better
correspond to the customer’s needs, requirements and knowledge. Companies would thus
better benefit from the use of automation technology, and together with a resource and
time effective development process based on lean principles, reach less costly automation
equipment and higher return on the investments.
The research presented in this paper contributes to the operations management theory
by elaborating on the concept of lean automation development. By addressing how a lean
mind-set and LPD principles can facilitate and improve the process of developing
automation, the possibility of successful automation measures and industrial
competitiveness increases.
Acknowledgements
The authors gratefully acknowledge the contributions from all the participants in the
contributing companies in the study. The financial support from Vinnova to the Lean
Automation Development project is also greatly acknowledged. The study was
performed in the context of the XPRES framework at Mälardalen University.
Proceedings from the 21st EurOMA Conference. 20-25 June 2014. Palermo, Italy.
10
References
Baines, T. (2004), "An integrated process for forming manufacturing technology acquisition decisions."
International Journal of Operations & Production Management Vol. 24, No. 5, pp. 447-467.
Ceroni, J. A. (2009), "Economic Rationalization of Automation Projects", in Nof, S. Y. (Ed.), Springer
Handbook of Automation. Springer-Verlag, Berlin: 699-714.
Cruz Di Palma, R. J. and Basaldúa, M. S. (2009), "Production, Supply, Logistics and Distribution ", in
Nof, S. Y. (Ed.), Springer Handbook of Automation. Springer-Verlag, Berlin: 947-960.
Daim, T. U. and Kocaoglu, D. F. (2008), "Exploring technology acquisition in Oregon, Turkey and in the
U.S. electronics manufacturing companies." Journal of High Technology Management Research Vol.
19, No. 1, pp. 45-58.
Durrani, T. S., Forbes, S. M., Broadfoot, C. and Carrie, A. S. (1998), "Managing the technology
acquisition process." Technovation Vol. 18, No. 8/9, pp. 523-528.
Granlund, A. (2014), Facilitating automation developmnet in internal logistics systems, Doctoral thesis
no. 150, School of Innovation, Design and Engineering, Mälardalen University, Västerås, Sweden.
Granlund, A. and Jackson, M. (2013), "Managing automation development projects – a comparison of
industrial needs and existing theoretical support". The 23rd International Conference on Flexible
Automation and Intelligent Manufacturing, 26-28 June, 2013, Porto, Portugal.
Groover, M. P. (2008), Automation, Production Systems, and Computer-Integrated Manufacturing,
Prentice Hall, Upper Saddle River, NJ.
Hoppmann, J., Rebentisch, E., Dombrowski, U. and Zahn, T. (2011), "A Framework for Organizing Lean
Product Development." Engineering Management Journal Vol. 23, No. 1, pp. 3-16.
Khan, M. S., Al-Ashaab, A., Shehab, E., Haque, B., Ewers, P., Sorli, M. and Sopelana, A. (2013),
"Towards lean product and process development." International Journal of Computer Integrated
Manufacturing Vol. 26, No. 12, pp. 1105-1116.
Meredith, J. R. (1987), "Managing factory automation projects." Journal of Manufacturing Systems Vol.
6, No. 2, pp. 75-91.
Morgan, J. M. and Liker, J. K. (2006), The Toyota Product Development System, Productivity Press, New
York.
Sambasivarao, K. V. and Deshmukh, S. G. (1995), "Selection and implementation of advanced
manufacturing technologies: classification and literature review of issues." International Journal of
Operations & Production Management Vol. 15, No. 10, pp. 43-62.
Sobek, D. K., Liker, J. K. and Ward, A. C. (1998), "Another Look at How Toyota Integrates Product
Development." Harvard business review Vol. 76, No. 4, pp. 1-12.
Sobek, D. K., Ward, A. C. and Liker, J. K. (1999), "Toyota's principles of set-based concurrent
engineering." Sloan management review Vol. 40, No. 2, pp. 67-83.
Spath, D., Braun, M. and Bauer, W. (2009), "Integrated Human and Automation Systems", in Nof, S. Y.
(Ed.), Springer Handbook of Automation. Springer-Verlag, Berlin: 571-598.
Säfsten, K. (2002), Evaluation of assembly systems: An exploratory study of evaluation situations,
Doctoral thesis No. 756, Linköping University, Linköping, Sweden.
Säfsten, K., Winroth, M. and Stahre, J. (2007), "The content and process of automation strategies."
International Journal of Production Economics Vol. 110, No. 1-2, pp. 25-38.
Ward, A., Liker, J. K., Cristiano, J. J. and Sobek II, D. K. (1995), "The second Toyota paradox: how
delaying decisions can make better cars faster." Sloan Management Review Vol. 36, No. 3, pp. 43-61.
Ward, A. C. (2009), Lean Product and Process Development, Lean Enterprise Institute, Cambridge, MA.
Winroth, M., Säfsten, K. and Stahre, J. (2007), "Automation strategies: existing theory or ad hoc
decisions?" International Journal of Manufacturing Technology and Management Vol. 11, No. 1, pp.
98-114.