Logical Conclusions Inc.
Course Outline:
The Goals and Context of Business Process Analysis
 Why Perform Analysis
 Degrees of Analysis
 Ways to View an Organization
 Goal of Business Process Analysis (BPA)
 The Context of Analysis
 Definitions of Key Terms in Process Analysis
 The Analysts Role
 Helpful Skills for the Process Analyst
 Starting an Analysis effort off right
 The Concept of Events
 What is an Event in the Business World?
 Discerning an Organization’s Core Business
 Discerning the Business Policy Layer
 Discerning the Technology/Customer Interface Layer
 Summary of an Event’s reaction as a 3 tiered structure
Events - the Core of Every Organization
Dis-Covering the Organization’s Real Business
 Everything We See Is a Design
 How we Perpetuate Old Designs
 Finding the Essential Business
 Historical Event Reaction Fragmentation
 Business Processing Overgrowth
 Business Data Overgrowth
 Organizational Structure Overgrowth
The Nature of Systems
A Fundamental Characteristic of All Systems
Example of an Environmental Stimulus-Response System
Example of a Biological Stimulus-Response System
Example of an Organizational Stimulus-Response System
Separating Stimulus-Response Structures
The Need for Organizational Models
 Why we use Models
 Models for Analysis
 What Analysis Models Capture
 Sample of Two Established Analysis Models
Overview of Business Process Analysis
 Definition of Business Process Analysis
 Sample Process Analysis Model
 Sample Analysis Data Definition
 Sample Analysis Process Definition
 A Complete Business Process Analysis Specification
 The Process Analysis Methodology
Detailed Business Process Modeling
 Typical Symbols used for Process Modeling
 Modeling External Interfaces
 Modeling Data and Control Flows
 Modeling Stimulus and Non-Stimulus Flows
Modeling Diverging and Converging Data Flows
 Modeling Processes
 The Three Allowable Process Types on an Analysis Model
 Modeling Stored Data
 An Additional Helpful Modeling Symbol
 Summary of the Rules for Process Model Symbols
 A Sample Event-Driven Process Model
 The Best Way to Produce an Event Driven Process Model
Specifying Business Policy - Process Specifications
Completing Analysis and Beginning Design
A Logical Conclusion for the Organization
 Assessing the Evolutionary Development Stage of the Organization
 Essential Components of the Organization’s Documentation
 Data and Process Integrity across the Organization
 Process and Data Reusability – Development Efficiency
 Benefits of Business Engineering
 Benefits of Implementing an Event-Driven Compartment
 Ultimate Benefits to a Customer Event-Driven Organization
Event-Driven Implementation Strategies
 Process Analysis Event-Driven Implementation - Strategy 1
 Process Analysis Event-Driven Implementation - Strategy 2
 Examples of Progressive Event-Driven Implementations
Event Types and Event Modeling
 Identifying our Event Context
 The Different “Flavors” of Events
 Definition of a Business Event
 Definition of a Dependent Event
 Definition of a Regulatory Event
 Definition of a System Event
 Definition of a Strategic Event
 Summary of Event Types
 The Organization’s “Event Horizon”
 Identifying our Event Context
 The Different “Flavors” of Events
 Definition of a Business Event
 Definition of a Dependent Event
 Definition of a Regulatory Event
 Definition of a System Event
 Definition of a Strategic Event
 Summary of Event Types
 The Organization’s “Event Horizon”
Workshop Exercise 3 – Produce an Event partitioned model of Accounts Department of case study organization
 Handling Complexity with Leveled Models
 Naming of Data and Processes at Different Levels
 The Lowest Level Process Model
 Unnecessary Process Leveling and Subdividing
 Finding Reusable Processes
 An Example of a Leveled Event Reaction Model
 Applying Data Conservation to Detailed Models
 The Important Levels of an Analysis Process Model
Workshop Exercise 4 – Produce a Process Model of Sales Department of case-study organization
 Why We Need Stored Data
 Problems with Old Data Files
 Essential versus Non-Essential Stored Data
 Seeing through the Design of Existing Files
 Gathering Information Requirements from Existing Files
 A Model for Stored Data
 The Need for Two Analysis Models
 The Link between Process Models and Data Models
Workshop Exercise 5 – Produce a Data Dictionary definition from an Order Form in case-study organization
 Capturing Essential Business Data
 What Data Need to be Defined
 Analysis versus Design Data Definitions
 The Importance of Consistent Data Element Naming
 Sample Standard Naming Convention
 A Sample Concise Data Dictionary Notation
 Example of a Complete Data Dictionary Entry
 Additional Notations for Data Clarification
 Data Aggregates versus Data Elements
 Identifying Reusable Data Element Groups
 A Comprehensive Data Element Specification
 Drilling-down to Detail using the Process Model
 Specifying Detailed Processing
 Methods of Specification
 Capturing Business Processing/Policy
 Overcoming Complex Processing
 Using Decision Tables to Obtain Accurate Policy
 Sample Decision Table
 Capturing Precise Policy using Structured English
 Example of a Formal and Informal Process Specification
Workshop Exercise 6 – Produce an analysis Process Specification of a major process in case-study organization
 Un-Fragmenting an Event Reaction
 Beware of False Time and Date Stimuli (Design Trap #1)
 Beware of Fragmented Data Processes (Design Trap #2)
 Beware of Bundled Event Stimuli (Design Trap #3)
 Beware of Historical Events (Design Trap # 4)
 Data Problems with Fragmented Event Reactions
 Result of Un-Fragmenting Event Reactions
 Using Business Events to Drive Associated Events
Workshop Exercise 7 – Produce a Process Model of a computer system in case-study organization
Workshop Exercise 8 – Un-fragment one complete Event Reaction through case-study organization
Workshop Exercise 9 – Bring together a total Process Analysis Specification of case-study organization
 The Complete Business Process Analysis Specification
 Completing the Analysis Specification
 Identifying Functional Design Boundaries
 Identifying the Automation Boundary
 Using the Analysis Flows to Identify Interfaces in Design
 Supporting the New Design
 Forming Event-Driven Compartments
 Implementing Event–Driven Compartment Teams
 Implementing Event Reactions in a Restrictive Environment
Workshop Exercise 10 – Identify Project Objectives for new Analysis Process Model of case-study organization
Workshop Exercise 11 – Use Analysis Process Model for Design Automation boundary of case-study organization
Un-fragmenting Event Reactions from the Old Design
Workshop Exercise 1 – Produce a Process Modeling for existing Maintain Inventory area of case-study organization
Workshop Exercise 2 – Identify Event Types and Context Diagram for case-study organization
Leveling/Subdividing Process Models
Defining the Data via a Data Dictionary
Modeling Stored Data – Data-at-rest

This seminar is for Systems Analysts, Business Analysts, Enterprise Architecture team members and Project and Program managers. As well as Users/Owners of business policy/rules and others having responsibilities to purchase, build or implement systems.

Business Process Analysis is the most important task when moving an organization from average to excellent. At least within an organization there should be the equivalent of the house blueprint – a model of the essential business, backed up with definitions of its data. The models and support specifications that result from analysis are crucial to the success of an organization.

We conduct analysis whenever we want to build or buy something. For example, if we want to buy a car we have in our minds, even though it may be informally, a set of requirements. The car is already designed and implemented and sitting in a show room but it must still fulfill our requirements.

We will always do analysis even if it's combined with a solution or passed off to a vendor and assumed to have been performed as part of a purchased package. For a solution to match your requirements you must document your requirements. And the more detailed your requirements the better you will be able to match them to a solution. So when we want to build or purchase an information system the more detailed we get in our requirements the better our implemented systems will be.

The inability to specify and communicate the correct Business Requirements can lead to a canceled development project or the wrong purchased system. This is regardless of good system design or implementation methods.

Business Process Analysis draws heavily on graphical models to capture business requirements/rules. Now how these models are documented (their structure and partitioning) is important as the design of future systems will probably be based on this structure. That's why this seminar uses Events and Event Driven concepts as the best way to structure the resultant analysis documentation.

The seminar's content is presented in an unambiguous, non-technical, jargon free manner. It also uses a detailed workshop on-going case study to show the importance of deriving a business, non-solution view of an organization. This business view will assist in defining the best design characteristics for future systems as an Event Driven model will flow naturally into systems design for development or a packaged system selection.

Onsite Business Process Analysis Workshop
 Corporate BPA Seminar (4 days)

This onsite course is available as a Video Workshop Course.
Contact Logical Conclusions Inc.:
Link to our other video website:
Email: talk2us@LogicalConclusionsInc.com
808 450-2849
Logical Conclusions Inc.
About Us