How to Analyze a Business

Copyrights and Trademarks

Second Edition Copyright © 2015, Logical Conclusions, Inc.

All rights reserved worldwide.

Use of one individual page or diagram in this book is allowed with acknowledgement to Logical Conclusions Inc. and the author, Brian Dickinson. Please contact Logical Conclusions, Inc. for use of extracts of more than one page.

Published by LCI Press a wholly owned subsidiary of Logical Conclusions, Inc.

Cover Design: Brian Dickinson

ISBN Number: 978-0-9629276-5-2

First Edition Produced and Printed in 2012 in the United States of America.

This book is extracted and updated from Creating Customer Focused Organizations by the same author.

This e-book is licensed for your personal enjoyment only and may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each recipient. If you’re reading this book and did not purchase it, or it was not purchased for your use only, then please purchase your own copy. Thank you for respecting the hard work of this author.

The publisher offers a discount when you order this book in bulk quantities or for educational establishments.

For information on Logical Conclusions’ Seminars and Consulting Services in the subjects of:

Business Process Improvement/Management

Creating a Customer Focused Organization

Business Process Analysis and Business Information Analysis,

Strategic Planning and Project Management

And Reengineering

please contact us at:

Email: Talk2Us@LogicalConclusionsInc.com

Web: www.LogicalConclusionsInc.com

About the author

For those people who actually read the about the author section here’s a little about my background.

I was born in a small town in England where the nearest computer was 20 miles away at the largest employer in the area. The computers that were around in those days were large, costly mainframes that required constant care – on site hardware engineers and climate controlled rooms etc.

I was lucky to get a job in the computer department there and over several years I worked my way up through the computer department’s ranks; Computer Operator, Programmer, Systems Analyst, Project Analyst etc.

Then with those skills I contracted myself out as a Consultant in England and in Europe

After working in the computer systems industry for some years I realized that we did not have a true profession yet and ‘bugs’ in system program code were an accepted industry quirk. Bugs were classed as a ‘natural’ by-product of programming, which you were supposed to test out after first putting them in during the coding stage.

As a Programmer Analyst, it was common for me to fix bugs before or after a production run. I must admit at first it was a novelty to test my skills at debugging a system while under the pressure of a development or production deadline but the novelty wore off.

A help wanted ad for a position in the United States caught my eye, and I saw my chance to get away from all of those software bugs. I thought the USA is where they must build systems right; after all, it’s the home of large computer companies and the new ‘software engineering’ ideas. So, I figured, I’ll go to the States, home of zero-defect systems. (Okay, I was naive!)

Over the next few years I worked for a New York contracting house that sent me out around the States as a consultant to large organizations. After a half dozen major contracts, I realized that everybody was messed up. The attitude of systems folk of, What’s a few bugs between friends appeared to be pandemic. Even major software companies put out beta test versions of production systems to their customers. (What would be your reaction to getting on a plane and the pilot announcing, We are trying out a beta test version of the air traffic control system today?)

After a number of contracts where arbitrary deadlines, as opposed to quality, drove the project, I was lucky enough to actually get some onsite training in and use new Software Engineering ideas. It was on a large project on which I was one of many consultants.

Then, I saw an advertisement to join a young training organization interested in putting out ideas on quality Software/Systems Engineering concepts – the ones I had already been using on my last project. So I started teaching and consulting on those new concepts. At that organization I got to associate with some very bright people such as Ed Yourdon and Tom DeMarco.

In the early 1980s I formed my own business, Logical Conclusions Inc., with the intention of focusing on the management aspects of systems engineering but it turned out that for many years I was asked to teach and consult more on analysis, design and programming technical subjects.

Over the years I did make time to conduct talks and keynote presentations at many conferences around the world and to be a participant in the Citizen Ambassador Program representing the United States in China and Russia.

In between conducting seminars (as well as nights, weekends and in airport waiting areas) I also wrote books on quality systems development and Project Methodologies. Here are some of my published books:

Developing Structured Systems: A Methodology Using Structured Techniques

Strategic Business Engineering: A Synergy of Software Engineering and Information Engineering

Creating Customer Focused Organizations

Strategic Business Planning

and this book on How to Analyze a Business.

I’ve aimed this book at a broad audience; the ideas being applicable to any sized business and to a general business audience as well as to Information System professionals.

Acknowledgments

There are many events that shape a person’s knowledge. For me these events included my world travels, a number of thought-provoking books, a group of special individuals and the physical relocation and restructuring of my own organization.

My travels took me to many countries and into their cities and villages around the world and gave me the opportunity to see and compare their diverse cultures and political systems.

Many influential books seemed to be presented to me at appropriate times along these travels (such as metaphysical books while in India and scientific and sociological books while in the United States).

In addition, certain individuals had a profound influence such as school teachers who made learning a pleasure and brilliant business colleagues with whom I had the good fortune to work.

A few years ago I decided to change the structure of my own organization from a formal office in San Francisco with desks, equipment, an 8-to-5 staff, etc. to a virtual office in rural area away from the city. This new structure and location allowed me to step back and see business systems differently from what I saw when I was immersed in the day-to-day operations under the old structure. I realized the business world was following an outdated paradigm. This reminds me of a quote that stuck with me from one of the books I mentioned above "You have to know you’re in prison before you want to get out."

All of these contributed in some way to the contents of this book. However, perhaps the greatest factor influencing my business concepts was my being at the right place at the right time. In the late 1970s I joined a New York systems training company headed by a person called Ed Yourdon; he and many of the consultants there such as Tom DeMarco and Steve McMenamin had a great influence on my way of thinking about systems.

In the early 1980s I formed Logical Conclusions, Inc. and attracted some great employees with whom I had long and fruitful debates. These people included III (yes, that’s his name), Colt Rymer, and Doug Brown. Those debates enriched my thinking.

I have been teaching the ideas in this book for many years and I have had the advantage of running them past thousands of students. Fortunately, they have been remarkably well received, and so, here I would like to thank all my students who helped me shape my ideas, with special thanks to the select few who believe in grasping these ideas and championing them in their workplace, invariably against all kinds of resistance to change.

And of course, I must, I mean, I want to thank my intelligent, beautiful wife, Dawana, who keeps me humble and stayed with me while I hibernated in my home office to write this book.

Brian Dickinson

From my home office

(Please note: this book addresses the technical aspect of analyzing a business; the managerial aspect of Strategic Planning and Project Management are covered in the companion book Strategic Business Planning using a Customer-Focused, Event-Driven Model.)

Table of Contents

Introduction

Everything you See is a Design

When should we Analyze our Business?

Removing Technical/Systemic Obstacles

Familiarity Gets in Our Way

A Rose by Any Other Name

Growth through Customer Satisfaction

Objectives of this Book

How this Book is Organized

Chapter 1

Dis-Covering the Essential Business

What Obscures the Essential Business?

What Obscures the Essential Processing?

What is Functional Partitioning?

An Archaeological Dig through old Designs

Wrong Turn #1 - People partitioning in Manual Systems

Wrong Turn #2 - System partitioning in Computer Systems

Wrong Turn #3 - Program partitioning in Computer Systems

Wrong Turn #4 - File partitioning in Computer Systems

Wrong Turn #5 - File partitioning in Manual Systems

Wrong Turn #6 - After-the-fact Quality Control

Summary

Chapter 2

Events and the Fundamental Characteristic of all Systems

The Stimulus-Response Nature of Systems

The Process-Memory Nature of Systems

Summary

Chapter 3

The Model IS the Business

Effective System Modeling

The Characteristics of an Effective Model

Models for Analysis

Process Oriented Models

Flow Charts

Functional Decomposition Diagrams

Process Hierarchy Diagrams

Information/Data Oriented Models

Entity Relationship Diagrams

Process and Information/Data Oriented Models

Data Flow Diagrams

Object Oriented Models

Control Oriented Models

State Transition Diagrams

Control Flow Diagrams

Choosing the Right Model

Example of Business/Analysis and System/Design Models

Summary

Chapter 4

Our Event Horizon - The Boundary of Our Organization

The Foundation of the Event-Driven Methodology

The Types of Organizational Events

Summary

Chapter 5

Distinguishing the Five Types of Events

Definition of a Business Event

Recognizing a Business Event

Business Event Identifier/Naming

Definition of a Dependent Event

Recognizing a Dependent Event

Definition of a Regulatory Event

Recognizing a Regulatory Event

Definition of a System Event

Recognizing a System Event

Definition of a Strategic Event

Recognizing a Strategic Event

The Business Model Event List

Summary

Chapter 6

Partitioning by Business Events

A Business Event Reaction

The Six Important Components of a Business Event Reaction

Detailed Description of the Six Components

The Business Event Stimulus

Data-oriented Stimuli

Material-oriented Stimuli

Control-oriented Stimuli

The Business Event Processing

The Business Event Memory

Why We Need Stored Data

The Business Event Response

The Business Event Recipient

The Beginnings of the Organization’s Business Library

Summary

Chapter 7

Detailed Business Modeling

Historical Event Reaction Fragmentation

Historical Batch Processing and Transaction Codes

Historical Data Processing Grouping

Historical Events

Historical Data Groupings

The Progression of Analysis Models and their Levels

The Detailed Business Event Specification

Sub-partitioning of Processing

Valid Business Processes

The important levels on a Business Process Model

Sub-partitioning Data at Rest (Memory)

The resultant Seamless Business Reactions

Using Business Events to drive associated Events

The Business Library (so far)

Summary

Chapter 8

Achieving Organizational Data and Process Integrity

Determining the Potential for Reusability

Reusability Incentives

Obtaining Data Integrity (Data Conservation)

Using the Event/Data Element Matrix

Data Reusability Is All in the Name

Obtaining Process Integrity (Reusability of Business Policy and Rules)

Using an Event/Reusable Process Matrix

Process Reusability Is All in the Name

Other Helpful Integrity Matrices

The Event/Data Entity Matrix

The Event/Relationship Matrix

The Event/Object and Method Matrix

Summary

Chapter 9

Designing and Implementing Event-Driven Systems

Identifying Functional Design Boundaries

System Support Issues

Event-Driven Systems Design

Sample Event-Driven Designs

The Complete Business Event Specification

Sample Business Process Model

Sample Business Data Model

The Beginnings of Design – using the Process Model

The Beginnings of Design – using the Data Model

A sample Business Event Specification

Summary

Chapter 10

Strategic Planning and Management Issues of an Event Driven Organization

Strategic Planning using Business Event Reactions

The Key Strategic Planning Questions

What is our Purpose and Mission?

What is the Set of Business Events we respond to today?

Do our Current Systems support these Business Events Seamlessly?

What New Business Events do we want to Support?

How do we become an Efficient, Customer Focused Organization from where we are today?

Project management using Business Event Reactions

Summary

Chapter 11

A Logical Conclusion

A revisit of this book’s Objectives and their Conclusions

A final note

Introduction

Everything you See is a Design (either human or nature’s)

In the business world everything you see is a design because every human-based or computer-based system is designed and then implemented using whatever human and computer technology was available at the time the existing system was invented – this design encapsulates the business.

In every organization everything you see is a design and its implementation -

not the actual business.

The problem is, you never see the business, just the implementation of the business. You can’t see the business because it’s intangible, therefore you can’t see an analysis. Even that sentence structure sounds strange see an analysis. You can see a design, but you can’t see an analysis. It’s like trying to see the reason behind an action.

However, to create a new design for the organization that is not warped by the old design, you have to be able to obtain a true business view that comes from conducting an analysis of your business. So to see the analysis of our business we need to use a model, just as any engineering profession does.

We need to be cautious when we create a model of the business because it’s easy to fall into the trap of modeling aspects of the old or even a new design rather than modeling the underlying essential business itself.

Based on over three decades of observing typical organizations I have found that the majority of them have simply evolved to where they are today. This evolution was often without any conscious strategic engineering method applied to past growth and, as new systems were developed, it was typically without performing an analysis of the business issues required to satisfy the customer. I’ll explain why this happens later.

(I just used the word Customer; I want you to realize that when I use that word in this book it always refers to the external person, place or thing that we are in business to satisfy. The customer isn’t always a human being. I conducted seminars at many government agencies where their customer was the environment, such as a fire agency responding to a forest fire or an agency protecting a national park.)

So, the vast majority of organizations run with a disjointed collection of human and computer systems in place based on historical factors. The older and larger an organization seems to determine the systemic limitations in place, take for