How to Analyze a Business System

In connection with strategy execution, IT modernization and business process reengineering client work I am frequently asked the question: “how do I analyze a business system?” The first thing I do is unpack the question a bit to ensure that I am answering the correct question. And, typically, what people mean by that question is “how do I identify, analyze and specify business system requirements for a business system?" Once I validate that that is indeed the question the person is asking, I then make the distinction between a business requirement and a business system requirement.

Business Requirements vs. Business System Requirements

A business requirement is something a business needs to do, typically in connection with a business process, or something that a business needs to know in connection with decision making. A business requirement may or may not be supported/enabled by a business system.

An example that I like to use in Inteq’s Business Systems Analysis training program is to take a look at performing business analysis at two restaurants – restaurant A and restaurant B. Both restaurants are what is known in the restaurant industry as tablecloth restaurants – restaurants where customers are seated by a host, interact with a server, order from a menu etc. - as opposed to a fast-food restaurant.

Restaurant A is part of a large organization with over 300 restaurant locations across North America. Restaurant B, located just down the street from one of the locations of Restaurant A, is a small Italian restaurant - perhaps 20 tables and owned by the chef.

If we do some business analysis at Restaurant A and at Restaurant B, we would probably find that both restaurants have similar business requirements. In other words, both restaurants want to be able to book a customer reservation, check-in customers when they arrive, assign a table to the customer party, enable the server to take the customer’s orders, prepare the orders, serve the orders, calculate the check when a customer requests the check, and process customer payments. These are all business requirements – what the business needs to do.

However, we find that how Restaurant A wants to support many of the business requirements is different than how Restaurant B wants to support the business requirements.

For example, Restaurant B, the small Italian restaurant, wants to be able to book a customer reservation, but may not have a compelling need or budget to invest in sophisticated business system functionality to book a customer reservation. Accordingly, the appropriate business solution for Restaurant B’s business requirement “book customer reservation,” is low-tech/no-tech. In other words, the appropriate solution for Restaurant B for “book customer reservation” is, when a customer calls the restaurant, the host checks the reservation book/calendar to see if, for example, a party of 4 can be accommodated in the main dining room at 7:30p Saturday evening. If the request can be accommodated, the host writes, into a reservation book, the reservation contact name, number of people in the reservation, the requested location (i.e. main dining room) and captures the contact’s cell phone number.

On the other hand, Restaurant A, which is part of a large 300 location organization, and as part of developing a new enterprise restaurant management system (eRMS), wants eRMS to enable reservations to be captured in multiple ways – if a customer is a member of the organization’s frequent dining program, the member can sign-in and create a reservation on-line via the organization’s website, or if a customer is a member of OpenTable, the customer can book the reservation via OpenTable, or if a customer chooses to call the location, the host can check availability and create a reservation via eRMS.

The key take away is that all requirements start out as business requirements – what the organization needs to do or needs to know – and if the business requirement is designated to be supported by application software functionality, the business requirement is further classified as a business system requirement. In the example above, the business requirement “Book Customer Reservation” is designated to be supported by eRMS functionality and the three types of customer reservations (web-based booking, OpenTable booking or Host Booking) are further analyzed as business systems requirements. And, therefore, Book Customer Reservation needs to be analyzed and specified from a detailed business systems requirements perspective.

Analyzing Business Systems Requirements

There are three components of business systems requirements analysis – identifying, analyzing and specifying business systems requirements. Each is essential to successful business systems and each has various best practice techniques and methods that are used. The focus of this blog is on analyzing business systems requirements. Identifying and specifying business systems requirements are equally important, but are the subject of several of my other blogs and whitepapers.

There are two key components of analyzing business systems requirements: the underlying rules regarding how the business wants the system to support the requirement (transactional rules and requirements); and the underlying rules regarding what the systems needs to know to support the requirement (data oriented business rules and requirements).

In analyzing business systems requirements, it’s absolutely essential go deep vs. superficial in your analysis. And it’s absolutely essential to deeply vs. superficially engage your subject matter experts (SMEs) and other stakeholders in your analysis. Accordingly, I am an advocate for using visual business oriented models/diagrams for analyzing both transactional rules and requirements and for data oriented rules and requirements. In my experience, asking SMEs and other stakeholders superficial questions such as “what do you want the system to do” and then taking superficial notes simply does not cut it.

What works is using visual business oriented models/diagrams such as process maps, activity diagrams, entity-relationship diagrams and state transition diagrams to deeply engage SMEs and other stakeholders; using the diagrams to capture the rules and requirements; and then using the diagrams to engage the SMEs and stakeholders in scenario analysis. You are now shifting to highly professional analysis – digital vs. analog analysis (diagrams vs. text) and deep vs. superficial analysis. For a more detailed discussion regarding deep engagement and analysis using visual diagrams take a look at my whitepaper: The 5 Essential Business Analysis Questions.

Subscribe to my blog | Visit our Knowledge Hub

Visit my YouTube channel | Connect with me on LinkedIn

Check out our Business Analysis Training Courses and Consulting Services