IDEF Methods for BPR to Support CALS
Comprehensive Solutions for a Complex World IDEF and CALS
• CALS technologies enable paperless environments or the electronic flow of information. •The implementation of CALS technologies require a re-engineering of enterprises. IDEF and BPR
• Business Process Reengineering (BPR) assists in re-engineering the enterprises and the successful implementation of CALS. • IDEF Methods support BPR activities (e.g., knowledge acquisition, As-Is analysis, To -Be design, project planning, and implementation). What are Methods?
Methods: A structured approach to capturing knowledge that maximizes accuracy but is also flexible enough to capture the real-world characteristics of that knowledge. What are IDEF Methods?
Integration DEFinition methods
Knowledge Acquisition, Analysis, and Design tools
Languages that include both graphics (diagrams) and text
Formal procedures for constructing models or ditifdescriptions of a parti tilcular aspect tf of an organization Why IDEF?
IDEF: The IDEF Family of Methods was co- developed by industry and government. Their pppurpose is to p rovide a comp rehensive y et flexible framework for describing, analyzing, and evaluatinggp business practices. The y are not proprietary and are supported by international standards. Characteristics of an IDEF Method
Designed to address specific aspects of a problem, or provide different perspectives of the same problem
Provide an explicit mechanism for integrating the results of the application of one IDEF with another
Embody the knowledge of good practice for the targeted fact collection, analysis, design, or fabrication activity
Desidigned to raihise the perf ormance ofif a novice practi iitioner to that of a more experienced practitioner
Enforce formal techniques to ensure understandable communication Continuing Evolution of IDEF
IDEFØ Function Modeling IDEF1 Information Modeling
IDEF1X Data Modeling
IDEF3 Process Modeling IDEF4 Object-oriented Design/Analysis IDEF5 Ontology Description IDEF9 Bus iness Cons tra in t Discovery Original IDEF Methods
Origgpinal plan was for the creation of several Integrated IDEFs from the ICAM Project
The initial step was the development of the first 3 methods: Function/Activity Modeling (IDEFØ) In formati on M od eli ng (IDEF1) Dynamic Modeling (IDEF2) Where to use IDEF
CALS Implementations--transitioning from paper to electronic systems
Business Process Reengineering / Improvement
BiBusiness /Mfti/ Manufacturing S Stystem Documentation/ISO 9000 Compliance
Software/Information System Development
Manufacturing Systems Analysis and Design In The Beginning. . .
IDEF0 - Activity Modeling IDEF1 - Information Modeling IDEF1X - Logical Data Modeling The Next Generation
IDEF3 - Process Modeling IDEF4 - Object-Oriented Design and Analysis IDEF5 - Ontology Descrip tion IDEF9 - Business Constraint Description Support for Systems Development
IDEFØ is used to document what the enterprise does.
IDEF3 models how the enterprise does what it does.
IDEF1/1X capture how information is used to support what the enterprise does and how it does it. With IDEF, systems development is based on real-world knowledge, not unrealistic goals. Support for BPR Efforts
Capture Activities and Their Relationships; Identify Core Activities; Identify Activities for Reengineering
Describe Business Processes; Redesign Processes for Improvement; Use Process Descriptions for Simulation
Capture How Data and Information Are Used to Support Business Processes Next Generation of IDEF Methods
Currently Envisioned Methods IDEF6 - Design Rationale Capture IDEF7 - Information System Audit Method IDEF8 - Human-System Interaction Modeling IDEF9 - Business-Constraint Discovery Method IDEF10 - Implementation Architecture Modeling IDEF11 - Information Artifact Modeling IDEF12 - Organizational Design Method IDEF13 - 3-Schema Architecture Design Method IDEF14 - Network / Distribution Design Method IDEFØ Captures What an Enterprise Does Why Develop An IDEFØ Activity Model?
To identify, document , and communicate an enterprise’s core activities.
To understand how activities relate to one another.
To identify value-added and non-value-added activities.
To identify activities that need to be improved . Benefits of Activity Modeling
Documents current activities. Reduces the learning curve for new activity users. Cappytures and analyzes As-Is activities.
Facilitates the design/redesign of activities for To-Be scenarios. An IDEFØ Activity Box
Controls (constraints on an activity, e.g., procedures, budgets, etc.)
Inputs Function or Outputs (what is required AiiActivity (what is produced by an before an activity can (Verb Phase) activity, e.g., reports, occur, e .g ., purchase products, etc.) order, supervisor’s signature, etc.) Mechanisms (what enables an activity, e .g ., equipment , personnel assignments, etc.) Context, Purpose, and Viewpoint:
The context defines the boundaries of Personnel Regulations your model —iei.e., Department Policy what will be included Supervisor Instructions in the model. Manning Conditions Applicant Data Perform Personnel Action For example, Customer Request Personnel Actions Reports Employee/Position Employee/Position Data Data comes from outidthtside the mod dlel. Supplies & Equipment Personnel Office Staff Information System Context, Purpose, and Viewpoint:
We define purpose as the reason to develop Personnel Regulations this particular activity Department Policy Supervisor Instructions model. Manning Conditions
AliDApplicant Data Perform Personnel Action Purpose: To document Customer Request Personnel Actions Reports the activities Employee/Position Data associtdiated with managing Personnel Supplies & Equipment Actions and identify Personnel Office Staff non-value-added Information System activities that might be eliminated. Context, Purpose, and Viewpoint:
Viewpoint can be Personnel Regulations thought of as th e Department Policy Supervisor Instructions perspective of the Manning Conditions Applicant Data Perform person/group Personnel Action Customer Request Personnel Actions Reports developpging the Employee/Position model. Data
Supplies & Equipment Personnel Office Staff Viewpoint: Information System Personnel Officer Decomposition: An Example
Company guidelines Budget guidelines
Maintain Correct ledger Purchase request Accounts Payment Payable Invoice A0 Order
Accounting staff Decomposition: An Example
Company guidelines Process guidelines Purchase Process Order request requestrequest A1 Invoice guidelines
Process Invoice invoice PPtayment A2 Ledger guidelines
Apply purchase Correct ledger to books A3
Accounting staff IDEFØ As a Standard
Federal Information Processing Standards Publication (FIPS PUB) 183-Integrated Definition for Function Modelingg( (IDEFØ) Published December 1993
DoD 8020.1-M established that “IDEFØ is the DoD standard methodology used for activity modeling”
Currently, ANSI Standard Being Developed IDEF3 Captures How an Enterprise Does What It Does Why Develop An IDEF3 Process Model?
To describe the process view of a process.
To describe the OSTN view of a process.
To capture timing and decision logic of processes.
To support descriptions at any desired level of detail through Decompositions. To employ the concepts of Scenarios to simplify the structure of complex process flow descriptions.
To support the capture of multiple viewpoints. Benefits of Process Modeling
Document current processes for standardization.
Provide guidelines for new process members to redhliduce the learning curve.
Capture and analyze As -Is processes.
Design/redesign process for To-Be scenarios.
Test the design of a new process before embarking on an expensive development project . Precedence Link Process 1 will need to be finished before you can do Process 2.
Process 1 Process 2
1 2 Referents . . . simply point the reader to some other aspect o f the mo de l tha t nee ds to be considered. Object: Pur. Req. Identify Negotiate Supplier price with vendor 2 3 Receive Prepare and request for & & dispatch purchase purchase order 1 J1 J2 5 Receive request for purchase 4
Scenario / Ordering Contracted Object / parts Contracted Parts Establish Scenario Objectives: (Viewpoint, Purpose, and Context)
Viewpoint Determines what can be seen and from what perspective. Purpose Establishes the goal of the communication intended by the description. Defines why the description is being developed, and specifies how it will be used. Context Establishes the subject of a description. Establishes the subject as a part of a larger whole. Creates a boundary within the environment. Decompositions: PhPurchase O OdErder Examp le
Customer Supplier Del. Svc. Customer Places Processes Transports Rec./Dis. Order Order Materials Materials 1.1 2.1 3.1 4.1
Top-level Scenario: As-Is Order Process Decompositions: PhPurchase O OdErder Examp le
Customer Supplier Del. Svc. Customer Places Processes Transports Rec./Dis. Order Order Materials Materials 1.1 2.1 3.1 4.1
Decomposition: Customer Places Order
Operator Sys. Cross System Open Enters Item Ref. Part # Generates Channel/Send Description w/Order Pick Ticket File to Target Details File Printer 5.1 6.1 7.1 8.1 OSTN Referent OST N
Scenario Object Referent State II Diagram
Object UOB SSeVtate IV Object Referent State I Object State III
Allows constructi on of an obj ect-centeredid view. Summarizes allowable transitions of an object in the domain. Document data life cycles. Cuts across the process flow diagrams. Characterizes dynamic behavior of objects. Paint Shop OSTN: FObjPiFocus Object: Paint
Scenario Paint Referent covered by new layer 1
Liquid Solid UOB/Test paint in paint on coverage machine part 3 UOB Dry part 2 Paint UOB/Test covered by coverage polish 3 Comparing IDEFØ and IDEF3
IDEFØ Models IDEF3 Models
What do I do? How do I do it? Single Viewpoint Multiple viewpoints No timing or logic iddintended Both time and cause-and-effect Target activities that logic require Improve specific improvement processes IDEF1X
Data Modeling What is an IDEF1X Data Model
Graphical/Textual Depiction of the Data RltiRelationshi ps and
Business Rules for an E4/Account
Acct-#
Acct-Start-Date ADP System Acct-type
is a A Design of Logical Acct-type Data Structures to be
E5/Chk-Acct E6/Save-Acct E7/Loan-Acct Implemented in a Acct-# Acct-# Acct-# Loan-Balance Save-Balance Chk-Balance Relational Database Interest-Rate Per-Chk-rate Loan-Amount What IDEF1X Is and Isn’t
IDEF1X is: IDEF1X isn’t: Data modeling For modeling real world things For designing reltilational ldtb databases For designing Object-Oriented and systems databases and For As-Is and To-Be systems data system analysis and modeling Categorization Migration Example
Account Item/3 po_number(FK) vendor_number (FK) due_date invoice_ number invoice_date status
status
Billed/8 Overdue/7 Paid/6 po_number (FK) po_number (FK) po_number (FK) vendor_ number (FK) vendor_ number (FK) vendor_ number (FK) overcharge_due date_received check_number IDEF1X As a Standard
Federal Information Processing Standards Publication (FIPS PUB) 184-Integrated Definition for Data Modelingg( (IDEF1X ) Published December 1994
DoD 8020.1-M established that “IDEF1X is the DoD standard methodology used for data modeling”
Currently, ANSI standard is being developed Method Comparisons (IDEFØ, 1X, and IDEF3)
IDEFØ IDEF1x IDEF3
What you do What you need to How you do it Functional know Precedence and dependencies Information Cause-&-Effect Used to “target” Management or Reduce Cycle activities that DtbDatabase Des ign Time need Information or A description improvement Data metho d A modeling Requirements method Analysis method (1) /Design method (1X) Continuing the Development
IDEF4 Object-Oriented Design IDEF5 Ontology Description IDEF9 Business Constraint Description IDEF4
Object-Oriented Design and Analysis IDEF4: ObjectObject--OrientedOriented Design Method
What Does “Object-Oriented” Mean?
By viewing a program from an object-oriented (OO) perspective, the developer can understand how the program behaves based on how its objects interact. Why is IDEF4 Necessary?
Reuse of legacy systems
Improve the quality of OO code produced by novice OO programmers
Structured design and relation design methdhods are not ad equate f or th e d esi gn of object-oriented (()yOO) systems Motivation for IDEF4
The need for a design tool that allows the use of commercial-off-the-shelf software and the reuse of existing systems The need for a design tool for those who will develop object-oriented databases and software To allow for the expression of domain knowledge in a more natural way (the object- oriented paradigm) Features of IDEF4
Views object-oriented design as part of a larger system development framework Emphasizes object-oriented design process over the graphical syntax, using graphical syntax and diagrams to communicate important design issues Provides support for “least commitment” strategies for assessing the design impact of the interaction between class inheritance, object composition, functional decomposition , and polymorphism Benefits of IDEF 4
The intuitive nature of object- oriented programming makes it easier to produce code.
Unfortunately, the ease with which software is produced also makes it easier to create software of poor design, resulting in systems lacking re - usability, modularity, and maintainability. The IDEF4 method is designed to assist in the correct application of this technology. IDEF5
Ontology Capture IDEF5: Ontology Description Capture Method
The IDEF5 method was developed by KBSI to provide a method to assist in creating, modifying, and maintaining ontologies—a domain vocablbulary compl ete wi ihth a set of precise definitions to enable consistent interpretation. Motivation for IDEF5
First step in CALS/CE/TQM is knowing what the othflliher fellow is talki lkibng about.
Lack of enabling technology for knowledge capture and sharing (the need for capturing alternative levels of abstractions)
Lack of enabling technology for integrated systems (process as well as data integration services)
Need to support collaborative decision making The Need for Ontologies
The nature of any domain is revealed through three aspects:
the vocabulary used to discuss the characteristic objects and processes comprised in the domain
rigorous definitions of the basic terms in that vocabulary
chtitifthharacterization of the lillogical connecti ons between those terms. The Need for Ontologies
The IDEF5 method allows domain experts to construct ontologies that address these elements by capturing assertions about real- world obj ect s, th ei r properties, and their interrelationships. IDEF5 Concepts: Schematic Language IDEF5 Complex Schematic
RadioOption-of Car
Part-of
Transmission
Automatic Manual Transmission Transmission IDEF9: Business Constraint Discovery Method PliiPolicies, rul es, conventi ons, proced ures, cont ract s, agreements, regulations, and societal and physical laws dfidefine an ent erpri se. Th ese mech ani sms f orge relationships between people, information, material, and machines to ma ke a sys tem. W e call th ese BiBusiness Constraints. IDEF: The Next Generation
Released methods (published method rep orts) IDEF3 - Process Description Capture IDEF4 - Object-Oriented (OO) Design IDEF4C++ - OO Design using the C++ Language IDEF5 - OlOntology D escr iiCiption Capture IDEF6 - Design Rationale Capture IDEF8 - Human Systems Interaction Design IDEF9 - Business-Constraint Discovery IDEF14 - Network Design