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].
An introduction in Quality March 25, 2008
Posted by rettema in Research Problem.add a comment
LSS = Lean Six Sigma ; EE = Enterprise Engineering
In the line of reasoning of the business problem we noted that the professionals in both disciplines work isolated from each other. Combine this with the fact that both have their own fundamental theories we find ourselves in a situation of segregated concepts. So an useful concept within LSS does not necessarily lead to a meaningful concept for EE. So if we strive towards a merger of Lean Six Sigma and Enterprise Engineering we need a fundamental research to explore the conceptual areas of segregation.
Overseeing fundamental research we observed a research pattern. Researchers explore in many cases the meaning of a concept by placing them in a meta-model. This creates a situation and opportunity to reason its meaning from the meta model perspective and its position within. For example if a concept is positioned in an upper ontology we are capable to reason its meaning in the realm of the philosophical existence. As enterprise ontology is the cornerstone for enterprise engineering the concepts within are scientifically well defined.
Lean Six Sigma is different. Recently in 2007, Henk de Koning a researcher of IBIS UVA (section 2.1) delivered a scientifically grounding for LSS based upon a rational reconstruction (Koning, 2007). In this report Six Sigma is seen as quality improvement strategy (Koning, 2007 p. 21) which is in line with our introduction of LSS in section 2.2.3. The statement implicit expresses the importance of quality for LSS therefore a definition of Quality was reconstructed from publications of thought leaders.
Definitions: (Koning, 2007 p. 22)
Product Quality: product quality refers to product characteristics and the extent to which they meet customer (meaning: end-user) demands. Product characteristics that together make up product quality are: performance, features, reliability, conformance, durability, serviceability, aesthetics and perceived quality.
Process Quality: process quality reflects the demands of internal customers, and comes down to effectiveness (the extent to which a process provides required features) and efficiency (being effective at low cost). Dimensions of process quality include defect rates, but as well cycle time, yield and production costs not related to defects.
Understanding these definitions from a semiotic triangle perspective (Dietz, 2006 pp. 36, fig 4.1) these definitions are concepts, reconstructed from the mental pictures of LSS publicists. Within these definitions we can identify process and product characteristics which are other concepts from which the six sigma level of quality is reasoned. For reasoning purpose we marked them red in the next figure.
Figure 11 Rational reconstruction of Six Sigma’s business context.
These process characteristics are important concepts because they bind the LSS concerns with the business transaction oriented way of modeling of DEMO. If we strive towards an integrated methodology we need to understand their ontology and their relationship with the enterprise ontology. In practical terms, concepts like ‘Yield’, ‘cycle times’, ‘defects rates’ need to be studied in the context of the ontological parallelogram (Dietz, 2006 pp. 39, fig 4.2).
Currently there is a lack of knowledge how these process characteristics fit into the enterprise ontology . As result of this, it is not only difficult to strive further to one integrated methodology but what is more severe is our missing understanding of quality (incl process characteristics) in the realm of enterprise ontology.
Dietz, Jan. 2006. Enterprise Ontology, ISBN: 3540291695. Delft : Springer Verlag, 2006.
Koning, Henk de. 2007. Scientific Grounding of Lean Six Sigma’s Methodology. Amsterdam : UVA, 2007. 978-90-6464-176-3.
The ontological notion of behaviour March 20, 2008
Posted by rettema in Free Thoughts, Research Problem.Tags: ontology
add a comment
In the last post I presented the “Mass Production” (MP) and “One Piece Flow” (OPF) video. My statement that both have the same ontology was made from the DEMO perspective. Independent if a composite business act is implemented in either OPF or MP the representation of the situation with DEMO is the same. My statement doesn’t mean there is no notion of behavior in ontology.
In the publication The behavior of a technical Artifact researchers delivered an ontological definition of behavior for an artifact. The added value for my research is that behavior is reasoned from the Upper Ontology
DOLCE. This ‘Upper Ontology’ is , part of the wonderweb project that finished in 2004.
Idea: A future publication for my research is to define performance, waste and variation from the upper ontology to create a viable introduction of these concepts as an interoperability bridge between DEMO and Lean Six Sigma.
