The Complete Expert's Workshop includes:
Business Process Analysis
BPA Expert's Workshop
Approx. 6 hour online streaming video with 2 Hours of exercises in the video
Online BPA Video Workshop
and Workshop Excercises
"How to Analyze a Business"
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
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
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”
Definition and Partitioning of an Event Reaction
The Six Important Components of an Event Reaction
Definition of the Six Components of an Event Reaction
Separating Events to Avoid Complexity
Seamless Event Reaction Partitioning
Benefits of Partitioning by Event Reactions
Workshop Exercise 3 – From the case study produce an Event partitioned Process Model of the Accounts department.
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 – From the case-study produce a Process Model of the Sales department.
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 – From the case-study produce a Data Dictionary definition from an Order Form.
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 – From the case-study produce a business policy Process Specification for a major process.
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 – From the case-study produce a Process Model of a computer system.
Workshop Exercise 9 – From the case-study bring together a complete Process Analysis Specification.
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 – From the case-study identify the Project Objectives for a new Analysis Process Model.
Workshop Exercise 11 –From the case-study use the Analysis Process Model to Design an Automation Boundary.
Un-fragmenting Event Reactions from the Old Design
Workshop Exercise 1 – From the case-study produce a Process Model of the Maintain Inventory department.
Workshop Exercise 2 – From the case-study Identify external Event Types and produce a Context Diagram
Leveling/Subdividing Process Models
Defining the Data via a Data Dictionary
Modeling Stored Data – Data-at-rest
This workshop tutorial teaches you how to analyze the Business Processing aspects of an organization.
The subject matter is also known in the technical world as Business Process Analysis, which is an essential part of what’s known as Business Process Improvement and Business Process Management.
Analysis is the most important technical task in business improvement and done correctly will provide the most benefits and insights for any business.
This workshop teaches you a mastery of Business Process Analysis using Customer-Focused concepts and its result, which is a Business Process Analysis Specification. That specification captures the Essential Business Processing and Workflow in an organization or business area.
At the end of the workshop you should be able to use your skills to analyze a business and recommend a new, efficient, implementation structure for the business that no competing organization can beat.
Throughout this material you will learn Process Analysis concepts via the tutorial sections and then try out those concepts on a real world, small organization using the workshop exercises. When you have finished an exercise a result will be presented and an explanation of that result given.
The methodology presented in this tutorial can be used to analyze any sized organization.
There are no prerequisites for this material (except an open mind for innovative ideas).
Watch, Learn, Practice and Apply.
Contact Logical Conclusions Inc.:
Link to our other video website:
Logical Conclusions Inc.
Specifying and Partitioning Event Reactions
Logical Conclusions Inc.
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.