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.
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].
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.
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.
Has a composite act implemented in either “mass production” or “one piece flow” the same ontology ? March 15, 2008
Posted by rettema in Free Thoughts.2 comments
Enterprise ontology is about capturing those elements of an enterprise that determines the existence of the enterprise as a whole. In the theory of Enterprise Engineering the set of business acts including rules and information defines the enterprises structure and therefore its architecture. A representation of this information in for example DEMO, reflects an enterprises ontology and is completely disconnected from its implementation. However if we like to optimize enterprises for example with Lean Six Sigma we need to know how the business acts within behave.
Take for example the behavior of an composite act “creation of a bicycle”. In ontology we speak of a composite act because other ‘nested’ business acts are necessary to realize its creation. However the behavior ‘performance’ of the composite differs when these sub acts are conducted as a sequence or as parallel. Is the behavioral dimension then part of the enterprises ontology ? When not can it be considered as a dimension between ontology and implementation ?. In the next video of Ron Pereira we observe a simple experiment of two implementations of a business act (P-Fact). As result we will see a performance difference between the traditional “mass production” manufacturing technique against the lean “one piece flow” approach.
From an ontological perspective the business act (including P-Fact) is the same. From the composite axiom for both situations the business act has the same composition.
Question: Is the ontology of both the same or is it necessary to introduce a behavioral dimension as part of the ontology ?
The Things (Arnaldo Antunes, 1993) : The things have weight, mass, volume, size, time, shape, color, position, texture, duration, density, smell, value, consistency, depth, boundaries, temperature, function, appearance, price, fate, age, significance. The things have no peace.
Can Enterprise Architecture be Expressed as a Set of Partial Differential Equations ? March 11, 2008
Posted by rettema in Free Thoughts.add a comment
All complexities can be studied by applying simple Axioms, such that the laws of nature governing the system as a whole explains the EA behavior.
EnterpriseArchitecture = f (Process Architecture) +f (Performance) + f(Cost) +f(Architecture decisions) + f (Degree of Problem Complexity)+ f ( Process ofCreation) + f (Operations) + f (Market) …..etc
Change in any of the variable impacts the EA behavior, the concern is in understanding that a change happens and how this can be aligned with the desired objective. Remember, increasing ‘Degree of Complexity’ reduces the ‘Degree of Freedom’, from Goldratt’s Theory Of Constraint ; i.e, ‘Complexity’ and ‘Freedom of Operation’ are inversely proportional.
ProcessArch = f(Business Arch) +f(Information Arch) + f(Solution Arch) + f (TechnologyArch) + f (Degree of Solution Complexity) + …etc
Processes= f (Function) +f (Business Ontology) + f (Degree of Business Abstraction) + f(Aggregated Cost)
Function=f (Activities) + f (physical resources) + f (information) + f (abstraction –businessrules) + f (actual cost) + ……etc
Source: ingine
