Logical Conclusions Inc.

Our Customer-Centric Business Methodology

By Brian Dickinson
President Logical Conclusion Inc.
What is Quality in the Business world?
AKA "You can’ t add a pound of quality to a process."
logicalconclusionsinc004009.jpg logicalconclusionsinc004008.jpg
What is a "Business Event"?
Click to read full article...
Click to read full article...
Click Here to get access
In the business world a Methodology can be defined as:
 “A System to Build Systems”, be they Manual or Computer systems.

The overall premise of our Methodology:

Satisfying the customer’s need should be the central "reason for being" of any organization. This should be reflected in its organizational structures and its human and computer systems. (Note that a “Customer” isn’t always a human, for example a point in time such as the End of the Year or a Fire can be the “Customer” triggering a response in an organization.)

In other words every structure and supporting system in the organization should be designed and operated so that it is part of a customer-centric solution and not a high tech version of old system configurations. Ideally, the workflow paths of customer-satisfying processes and their needed data will be the shortest distances between the two points of the customer's initial request and the meeting of their need.

Knowing how to design and run these systems and structures derives from understanding an organization's essential business and the Stimulus/Response nature of meeting its customers' demands.

The Stimulus/Response Events “out there”.

I’ll pick on three basic Stimulus/Response Event systems, one from nature, one from our own biology and one from business.

• An example of an Environmental Stimulus/Response system:
The Event - A storm, produces the Stimulus rain, and the Response, over time, can be something as significant as the Grand Canyon in Arizona.

• An example of a Biological Stimulus/Response system:
The Event - A Hammer blow to the body produces the Stimulus Pain and the body’s Response being to remove the body part (and maybe some verbal response also).

• An example of an Organizational Stimulus/Response system:
The Event - A customer wanting to buy our product or service produces the Stimulus an Order and the Response is an invoice and product to the customer. In the business world this is obviously the one in which we are most interested.

The important thing to acknowledge here is each Stimulus arises from an EXTERNAL Event, in other words from a business point of view we are most interested in satisfying the needs of our external customer.
Note that the organization has no control over the occurrence of their selected EXTERNAL Customer Events; it simply responds to the arrival of the stimuli from the Events, for example, a Customer Order. If we do have control over the Event we’re probably not looking at the edge of our business; we’re looking at an internal fragment of an Events response. Or we may be looking at an Internal System Event and not a Business Event.

Examples of External Events in the Business World.

Each external customer need to which an organization responds is called a “Business Event.” From an organization’s point of view the first thing it sees is the stimulus, not the event – that’s external. For example here’s a person thinking,

• I need to fly to San Francisco…Which makes them contact an airline.

• I need some cash…Which makes them go to the bank or ATM.

• Its tax time…Which makes them send their tax documentation to the Government.

• I need to buy a briefcase…Which makes them purchase a product.

These are all external Business Events to the organizations that are going to respond to them. If we focus in on the last event we may see more detail of the Order processing stimulated by the incoming Order to the organization. The Order stimulus may traverse through a whole bunch of departments, computer systems, and databases before it comes out as a Response.

If we take a disciplined approach to specifying the various aspects of an organization we need to capture and define many components. For example: Functional Processes/Procedures, Data Groupings with Relationships, States and their Transitions, Controls etc. In our methodology we recommend using Business Events as a means to group/partition that documentation into Business Event Compartments.

Here’s a definition:
A “Business Event Compartment” consists of a set of business components required to completely satisfy one need of a Customer.”

Orienting an organization's structures and systems around Business Event Compartments (rather than around exiting departments/bureaus or systems/processes) provides a truly rational basis for creating a customer-centric organization.

How a Typical Organization Fragments a Business Event’s Implementation.

Let’s talk about an all-too-typical fragmentation of the implementation of a Business Event’s characteristics. Unfortunately, the typical organization has allowed old departmental structures, haphazard systems development efforts and purchased software packages to fragment the “cohesiveness” of a Business Event’s characteristics. (Author’s note: After my extensive career in information systems I don’t believe there are many functional systems out there – there are a lot of dysfunctional ones though.)

In fact the predominant design and implementation structure seems to be based on human implementation reasons rather than customer focused reasons, with the resultant structure looking more like a military hierarchy with jig-sawed, batched-up, similar tasks grouped together.
We solve this problem by using a Business Event Methodology when producing a manual or computer system and within that methodology focusing on the important aspect of Business Analysis to model and implement a Business Event Compartment.

Doing this produces a functional, agile, unbeatable business. It’s that important and a business that follows this methodology will be:

• The most responsive to the customer (it’s the shortest distance between two points – their request and your response),

• Easier to maintain (because manual procedures and computer code are specific to one Business Event and not bundled with other unnecessary and unexecuted processes and data),

• Easiest to Modify (because business rules/policy changes and new lines of business (new Business Events) are easier to make for the same reason above),

• Even easier to build (as business rules/policies are specific to one Business Event and therefore there are less design documents and record “codes” and so less testing required).

This article is just an introduction to our total methodology. If you think these concepts make sense and you would like to know more please look at our video courses and books on this website.
Contact Us:
Link to our other video website:
Email: BusinessAnalysis4U@gmail.com
Logical Conclusions Inc.
About Us