Time Metrics in Lean November 2, 2008
Posted by rettema in Uncategorized.add a comment
Lead Time = the average time it takes for one unit to go through the entire process – from start to finish – including time waiting between sub-processes.
Calculation = Cycle Time x units of WIP x number of operations + time delays between processes (planned and unplanned)
Example 1: Cycle Time of 120 seconds x 1 unit of WIP x 1 operation + 0 time delays = Lead Time of 2 minutes
Example 2: Cycle Time of 120 seconds x 100 units of WIP x 2 operations + 0 time delays = Lead Time of 400 minutes
Notice how the number of units of Work In Process (WIP) radically increases lead time. This is one of several reasons that Lean is so obsessed with small batch sizes. “Time delays between processes” is often by far the greatest contributor to Lead Time – and often presents the greatest opportunities for quickly eliminating waste. (”Low hanging fruit”).
Processing Time = The time a product is being worked on by an Operator.
Processing time is observed with a stopwatch or video camera – following one unit being processed by one operator – all the way through the process (or sub-process).
Processing Time = Manual Work + Walking + Waiting
Notice that Machine Time is NOT included in Processing Time. If the Operator has nothing better to do than stand around to wait for the machine to finish doing its thing, then that is called “Wait time”, and Wait Time is included within Processing Time. Processing Time is all about the Operator (not the machine).
Machine Time = The time that a machine is working on a product.
Machine time is the total time that the machine is working on the product. Whether or not the Operator has something better to do than to stand around waiting for the machine to finish has no influence on Machine Time.
For example – If an automatic machine is running for 60 seconds, and the Operator has something valuable to do for 20 seconds, and then has 40 seconds of “Wait time”, the Machine Time is still 60 seconds.
Process Lead Time = The time that a product is “being worked on”. (with or without an Operator)
Process Lead Time is measured in the same unit of measure as Lead Time – (usually days) – while Processing Time is measured in the same unit of measure as Takt Time and Cycle Time (usually seconds).
If the Operator is involved in every moment of the process, then Process Lead Time is simply Processing Time calculated into a tiny decimal fraction of a day.
Cycle Time = The average time between completed units “coming out the end of the pipe”
Example: the cycle time of motors assembled at the rate of 120 per hour would be 30 seconds per unit
Machine Cycle Time = The average time between completed units coming out of a machine
Example: A machine might have Machine Time of 60 seconds, but if the machine makes batches of 6, then Machine Cycle Time is 10 seconds.
Effective Cycle Time = Cycle Time adjusted for all the factors that reduce Working Time Available. (Also known as Output Pace)
Takt Time = Planning drumbeat. How often completed units NEED to come out the end of the pipe – as established by customer demand (also known as “Rate of customer demand”)
Calculation = Working Time Available / Target Units to Produce (usually calculated per week or per shift)
Example: 420 working minutes per shift / 210 Target Units to Produce during that shift = Takt Time of 2 minutes per unit. But Takt Time and Cycle Time are always measured in seconds – so Takt Time would be 120 seconds.
Value Add Time = Time of those work elements that actually transform the product in a way that the customer is willing to pay for. (also known as Value Creating Time)
Value Add Time < Cycle Time < Lead Time
Non Value Add Time = Cycle Time minus Value Add Time
Adjusting Cycle Time to Takt Time
Takt Time and Target Cycle Time are determined by customer demand, for which we usually have little control. So we adjust Cycle Time to meet Takt Time, by adjusting:
1) Available production time (the number and length of shifts)
2) The number of work cells making the same item (thereby increasing the Takt Time for each)
3) The number of end items produced in a cell (thereby increasing or decreasing demand for that cell)
4) The number of operators in the work cell
Target Cycle Time = Operational Takt Time adjusted for other factors
Target Cycle Time must be less than or equal to (and is usually equal to) Operational Takt Time.
(In many environments, Takt Time, Operational Takt Time, and Target Cycle Time are all the same, and the single term “Takt Time” can be used. In other environments, the differences can become important.)
An introductionary text snippet of my research September 30, 2008
Posted by rettema in Free Thoughts.Tags: DEMO, Enterprise Ontology, Lean Six Sigma
add a comment
This text snippet is an introduction of my plan to invest in a research into the theories of DEMO and Lean Six Sigma. Both have my interests which is rooted in my interpretation of a career in business consultancy. My beliefs in a synergy of both disciplines has motivated me to study many related publications. This interest was mainly driven by one clear question: “How can I use both as an integrated methodology to improve my customers organizations ?”.
During studying, both showed very strong individual capabilities. Enterprise Engineering offers with DEMO a unique capability to express the essence of an organization. The DEMO language is formally grounded in an enterprise ontology. This ontology is grounded from the results of years of study in the language action perspective (LAP). Within LAP there was a particular interest in the interactions that led to action and agreements between human actors. A pattern named transaction was recognized which is up till today the dominant concept in the enterprise ontology from which the enterprise architecture is constructed..
Six Sigma on the other hand is built upon principles, methods and tools that have shown their value in the last decades. Six Sigma incorporates the most effective of them and integrated them in a full programme for business improvement. Lean thinking was only recently incorporated. The principles of lean increased Six Sigma’s value for business process improvement significantly. Lean Six Sigma has become a standard for business improvement which is practiced worldwide. A scientific grounding for Lean Six Sigma , was delivered in 2007 as result of a PhD research and publications of the UVA IBIS institute.
Overseeing leans principles, six sigma’s evidence based way of working and the capabilities of enterprise engineering a suspect of complementariness manifested when researching related papers. I could give this suspect a meaning when I started to position elements of LSS and EE in the framework of a methodology (Seligman, Wijers, & Sol, 1989). Based upon this framework I could represent my thoughts more graphically. See the first version in the next figure.
Figure 1 LSS and DEMO Synergy plotted on Seligman’s framework for methodologies
Overseeing this model, a merge of Lean Six Sigma and Enterprise Engineering seem to release a potential methodology for enterprise improvement that regards IT in its approach. (More information in section 2.2). Beside this knowledge Mulder delivers in Rapid Enterprise Design (RED) (Mulder, 2006) a legitimate reason to research in this direction. His advice which we quote below, was also based upon the framework of a methodology and therefore fits seamless in my thoughts about this research.
Quote: (Mulder, 2006, p. 132)
Research Question 2:
What improvements or additions are necessarily for Enterprise Engineering to achieve a complete methodology for organization design in conformity with the five way model?
……The results show the capability of DEMO to redesign business processes, the data systems and the ICT-infrastructure……
…. from the five way perspective DEMO cannot be considered as a integral methodology for enterprise design….. On one hand not integral because redefining business services and business function is not scientifically validated on the other hand the way of working and project approach is not incorporated in the methodology
The conclusion incorporates a firm capability statement for “the way of thinking” and “the way of modeling” for Enterprise Engineering. However, the research answers show also the need to facilitate in a better way the process to support management. In Seligman’s terms, Enterprise Engineering misses a “way of working”. Mulder recommends therefore to start a research on this point if we like to increase the value of Enterprise Engineering on this point.
Combining Mulder’s conclusion and overseeing “Figure 1 LSS and DEMO Synergy plotted on Seligman framework.”, I think a research with the emphasis on the way of communicating between both theories can deliver a contribution for the architecture as the LSS community. In this kind of communication I envision an added value for Lean Six Sigma improvement programmes in the way that DEMO fulfills the missing aspects that the information age requires. The added value for DEMO is that LSS provides a way of improving.
DEMO and Value Stream Mapping September 23, 2008
Posted by rettema in Free Thoughts, Research Strategy, Uncategorized.Tags: enterprise architecture, Enterprise Ontology, Lean, Lean Six Sigma
add a comment
Value stream mapping is specifying value creation and information flow. See this illustration video on Youtube:
This is close to the way of modeling with DEMO (’Design & Engineering Methodology for Organizations). Modeling value and information flow concern is in DEMO incorporated in the Organizational Theorem. The organization theorem states that the organization of an enterprise is a heterogeneous system that is constituted as the layered integration of three homogeneous systems: the B-organization, the I-organization, and the D-organization. The D-organization supports the I-organization, and the I-organization supports the B-organization. The integration is established through the cohesive unification of the human being.
If we see the transactional results (P-C Facts) of the business as value. Then the value stream concern of Information handling can be positioned in the Intellectual- and Data-Organization. Is waste the delta between the ‘normal’ process map and the enterprises ontology or has waste an ontological presence ?
Mapping both way’s of modelling (Value Stream Mapping and DEMO-3) is a step foreward into my research for enterprise improvement.
Speaker @ Opengroup in Munnich, Germany, October 22 2008 September 22, 2008
Posted by rettema in Publications.Tags: Archimate, enterprise architecture, Opengroup, Togaf
add a comment
I
In Munich the ArchiMate Forum will host its inaugural meeting as a new forum within The Open Group. At this meeting I will present experiences, best practices and examples of: “ArchiMate modeling and analysis of Enterprise Architecture at a major Insurance Firm”.
Identify and measure VALUE in Transactions September 8, 2008
Posted by rettema in Free Thoughts, Research Problem.Tags: Enterprise Ontology, Lean and Six Sigma, Lean Six Sigma
add a comment
Value must be understood in two rather different contexts—the value of the process output to the larger enterprise, and the creation of that value during the carrying out of the individual tasks that make up the process. Measuring progress towards this goal requires metrics.
A Task can be measured by
- Cycle time (CT): clock or calendar time it takes to do an instance of the task
- In Process time (IPT): hours of continuous work it take to do the task. Sometimes referred to as Touch Time (TT)
- Core Process time (CPT): hours (or other time units) of continuous work spent on core task, excluding set up, trouble shooting, information gathering, etc. Sometimes called Value Added time (VAT)
- Efficiencies such as IPT/CT, CPT/CT or CPT/IPT
- Lead time: time from known need for task until task completion. Sometimes defined as time from known need until start of active work on task. Use either (but not both!) of these definitions
- Set up or Changeover time: time needed to prepare resources to do or resume task
- Fixed or non-recurring costs (what resources must exist for the task to take place, even if they are not used continuously)
- Cost/job or recurring costs (what resources are expended to do a job)
- Capacity: how many jobs can be done by a given process or sub-process, with available resources, in a given time.
- Utilization: at the current workload, how much of the Capacity is actually needed/used.
- Availability: percentage of time resources are actually available when needed
- Variation in any of the above (how predictable is the process)
- Failure rate: percentage chance a task output will be defective, or that a review is failed, resulting in rework
- Repeat or rework rate: number of times a task needs to be performed in an iterative or rework prone process
- Downstream task satisfaction (how good is the task output)
Waiting and Inventories can be measured by:
- Inventory part count: number of jobs in queue (usual factory metric)
- Delay time: average time a single job waits in queue (typically more useful in PD)
- Delay time statistics: mean and deviation, or distribution, of wait times (best)
Data can also be collected on the information flows, e.g.:
- Form: report, computer file (what system?), email, phone call, etc.
- Format: standard form? Software specific computer file?
- Size (of file or document)
- Transmission times and/or costs
Metrics does not identify a value adding step. Chase (1) proposed a list of aspects of value that a task could contribute. Those who add direct value are categorised as “direct value added”:
| V1. Definition of End Product with desired Functional Performance |
| The task affects the definition and/or functionality of the end product delivered to the customer. It contributes directly to either the function or the form that affects the function. For example, requirements specification, design decisions, material/part/subsystem specification, geometry specification, etc. |
| V2. Definition of Processes to Deliver Product |
| The task directly affects the processes necessary to deliver the end product to the customer. It includes the design or procurement of the tools and processes necessary for manufacturing, testing, certification and/or other downstream processes, such as the creation of manufacturing and assembly procedures |
| V3. Reduction of Risks and Uncertainties |
| The task contributes to eliminating uncertainties in performance, cost, and/or schedule. Typically, tasks include the analysis, prototyping, and testing of the product; the testing of tools/production processes, risk analysis, and cost/schedule management. |
Those who still add value referred as “necessary value-added” are:
| V4. Forming Final Output |
| The task directly contributes to the final documentation given to the customer or manufacturer. This typically includes the documentation of the materials, parts, subsystems, and systems, and documentation to meet legal and contractual constraints. |
| V6. Enabling Other Tasks |
| The task is necessary for other tasks to proceed, although it does not directly contribute to the design, production, or testing of the product |
| V10. Other |
| The task performs a necessary or valuable function not covered in the above categories. Examples may include contributions to work environment, environmental impact reduction, satisfying of regulatory or contractual requirements, the following of mandated processes, or the satisfaction other constraints. |
The last category of activities, “necessary non-value-added”
| V5. Facilitating Communication |
| The task aids necessary communication. Typically includes reviews, meetings, and discussions with other company or industry personnel. |
| V7. Meeting or Reducing Cost and/or Schedule |
| The task emphasizes maintaining or improving cost and/or schedule, e.g., many management and process improvement tasks. |
| V8. Learning or Resource Improvement |
| The task contributes to the skill base necessary to do future work. This definition includes developing greater knowledge, improving tools or processes, creating new technologies, and communicating this knowledge throughout the team. |
| V9. Enhancing Employee Job Satisfaction |
| The task is a positive experience that increases the desire of the employee to do similar tasks; it enhances the professional development or skill base of the employee. |
These Metrics (measuring progress in value creation) and Value identifying aspects should be mapped to DEMO aspect models.
Source: Product Development Value Stream Mapping (PDVSM) Manual
(1) Chase, James P., “Value Creation in the Product Development Process,” Masters thesis in Aeronautics and Astronautics, Massachusetts Institute of Technology, December 2001.
Enterprise Engineering and Enterprise Modeling I September 4, 2008
Posted by rettema in Free Thoughts, Research Problem.Tags: enterprise architecture, enterprise engineering, enterprise modeling, Enterprise Ontology
add a comment
Enterprise Engineering is the body of knowledge, principles, and practices having to do with the analysis, design, implementation and operation of an enterprise. In a continually changing and unpredictable competitive environment, the Enterprise Engineer addresses a fundamental question: “how to design and improve all elements associated with the total enterprise through the use of engineering and analysis methods and tools to more effectively achieve its goals and objectives”. In the Enterprise Engineering paradigm, the enterprise is viewed as a complex system of processes that can be engineered to accomplish specific organizational objectives. Enterprise Engineering recognizes the everchanging organic nature of the enterprise, and therefore has a valid world view or paradigm [Liles&Presley,1996].
These assumptions have implications in enterprise modeling. Models are abstractions of real life systems. Models are created to assist an analyst extract requisite details of the system in order to gain a better understanding of the complex system. An enterprise model is a symbolic representation of the enterprise and the things that it deals with. An enterprise model contains representations of individual facts, objects, and relationships that occur within the enterprise. Enterprise models can assist the goal of Enterprise Engineering by helping to represent and analyze the structure of activities and their interactions [Liles&Presley,1996].
EAM 2007 Contribution September 3, 2008
Posted by rettema in Uncategorized.Tags: Archimate, enterprise architecture, Enterprise Management, Togaf
add a comment
My contribution to EAM 2007, the Netherlands.
SAC 2009 Paper Submitted August 26, 2008
Posted by rettema in Publications.Tags: enterprise architecture, Enterprise Ontology, Lean Six Sigma, Six Sigma
add a comment
SAC 2009, ACM Symposium on Applied Computing – March 8 – 12, 2009
Title: Lean Six Sigma and DEMO, a comparison of enterprise improvement strategies
Abstract : Lean Six Sigma’s primary theory is that focusing on ‘reduction of variation’ and ‘removing waste’ in business processes will lead to business improvement. The approach is operationalized with statistics methodologies to analyze the fluctuations of a business processes. This focus on behavior is in contrast with enterprise architecture. Believers of this approach apply a constructional perspective on the enterprise and improve from this point on. DEMO, an acronym for Design and Engineering Methodology for Organizations, is a methodology in this category. The goal of this paper is to compare Lean Six Sigma and DEMO from an enterprise improvement perspective. This is relevant because enterprise improvement requires a methodology with a balanced focus on the structure and behavior of the enterprise. Based upon the results of this compare, we position research questions for further research in the assimilation of Lean Six Sigma and DEMO.
The meaning of Enterprise Architecture for other April 18, 2008
Posted by rettema in Free Thoughts.Tags: enterprise architecture, Lean and Six Sigma, Lean Six Sigma, Soa
2 comments
SOA is a huge paradigm shift for organizations. We have learned that it does not only impact the IT department , but also the business. They are confronted with a situation where technology links departments and functions within a formal business process flow. The SOA paradigm forces us to rethink how we ‘reorder’ the information handling in the SOA organization. This recognition has led to increasing interest to another concept: Enterprise Architecture.
Enterprise Architecture is a formal process of analyzing and articulating a company’s multi layered structure (business processes, applications, infrastructure). Consultancy firms, customer organizations and universities have already embraced Enterprise Architecture. Now a new era begins wherin we start to explore the added value of the Enterprise Architecture perspective for other paradigms and methodologies.
For example the exciting idea that Enterprise Architecture could enhance the ‘holistic’ approach of Lean Six Sigma. Another idea is to study the role of Enterprise Architecture during the change to SOA. I like to point on two ongoing initiatives on both fields of play:
- EA and Lean Six Sigma : MIT LAI – Lean Advancement Initiative
- EA and SOA: JISC a pilot of four initiatives
Cross-Dock are there parallels with Service Oriented Architecture ? April 10, 2008
Posted by rettema in Free Thoughts.Tags: Add new tag, enterprise architecture, Lean Six Sigma, Soa
add a comment
During my research I found an logistic ‘pattern’ called cross-dock. In my first encounter with cross-dock my conscious triggered my mind to recognize the cross-dock structure as a service oriented architecture. Interesting became my experience when I kept the SOA perspective in my mind during the reading of cross dock articles. In some articles I read abouth the application of lean principles on bad performing cross docks (SOA). Let me confront you with my ‘strange’ observations as result of my conscious.
Conscious, what Thomas Nagel calles the existence of “something that it is like” to be something.
What is cross-dock ?
Cross Dock is a process where goods are received at a distribution center and it flows in & out of the facility without being held in inventory. This duration of this activity ranges from minutes to hours, however it is usually completed within 24 hours. The next figure illustrates the pattern of cross-docking, click on the figure to watch a movie abouth cross-docking.
Archetypes in structure ?
The structure is close to a service oriented architecture (SOA) concept called enterprise service bus (ESB). The ESB routes information packages from clients (applications) to warehouses (databases) or other consumers (users). The miracle starts when you use this perspective and watch the movie. See the goods handled in the cross dock as information packages which are routed in an ESB. This post does not want to defend a thesis whether both are comparable but more interesting is to understand it as an archetype which found in two complete separated worlds. So If one world (in this case logistics) deals for a long time with this archetype, the other world can learn from it. I like to inspire you to read the next article How to be a lean, mean cross-docking machine with the SOA understanding in you’re mind and be astonished like me how easy it is to draw parallels.
A conclusion ?
Both phenomena’s incorporate the same archetype exposed in behaviour and structure. I think we can draw parallels and start to understanding SOA if we study the world of cross-dock.
