BRYCE ON SYSTEMS
- A primer; it's not what tools you use, but rather knowing what you are doing.
There are several interpretations of Business Process Design, which is concerned with devising a cost-effective approach for the various tasks to be performed in a business. Here is mine which has worked effectively for me for several years. It's not a matter of what tools I use, but rather understanding the principles behind the design process itself.
An inherent part of any Information System is the business processes (or as we originally referred to them as "sub-systems"). An Information System consists of two or more of these business processes representing how information is used to support the actions and decisions of a business, be it a commercial enterprise or a not-for-profit institution, such as a government agency. Actually, an information system is a grouping of processes dedicated to a specific purpose, such as to serve the needs of Accounting, Payroll, Manufacturing, Order Processing, Customer Service, etc. These processes are first defined logically as to who they serve, the information requirements they support (thereby defining the purpose of the process), its timing (how often it occurs, when it starts, and the amount of time necessary to complete the task), and the inputs, outputs and logical files associated with each. This simply represents "what" must occur and "when," representing a relatively stable logical model (it will only change if the information requirements change). Consider Payroll for example, something we have been processing in different physical forms for many years, yet the logical model is stable; to illustrate: Employee setup or termination, Reporting of Hours worked (reported either on a daily, weekly or monthly basis), Employee Payment, Government Reporting, etc. These processes do not change as much as you may think. However, the physical implementation of each process does. For example, Payroll used to be implemented manually using ledgers and spreadsheets; then computerized versions implemented the processes on mainframes, minis, and personal computers; and now we hear of "cloud" implementations. Yet, the basic logical processes remain the same.
So, when we discuss "business process design," we are actually discussing its physical implementation. The logical design of the sub-system, of course, should be considered a precursor. Assuming it is in place, the challenge is two-fold: to physically define both the work flow and data flow. In terms of the work flow, the intent is to procedurally define how the business process will be executed from start to end, and by whom. Here, there are three types of procedures used: Administrative (to reflect manual processing), Computer (to represent programming), and Office Automation ("OA"; to represent the use of certain office equipment, such as optical or audio scanning, fax, key entry, etc.). Within a business process, there must be one
or more Administrative of OA procedures, and one or no computer procedures (in other words, a manually implemented business process). The basic processing constructs in the work flow are Sequence (linear), Iteration (repetition), and Choice (selection). These can be combined in a single business process as required.
Data Flow is defined through the various inputs, outputs, and physical files used in the process, each includes records. In terms of inputs, records represent transactions, referring to some sort of action or event, such as a purchase, a return, a back-order, a debit or a credit, etc. Most of what we do in business is process transactions, be it a query, or to update files. This means there are three fundamental actions performed: Create (C), Update (U), and Reference (R). Some would argue there is also a "Delete" to be considered, but this is the opposite function of a "Create." In programming parlance, a "Reference" is considered a "Read," and an "Update," is a "Read/Write."
One of the fundamental considerations for both work flow and data flow is timing, which should be defined for the overall sub-system in terms of "Frequency" (how often the business process is executed, such as "Twelve Times a Day," "Once a Month," or "Upon Request" (whenever desired)). "Offset" represents when the process is to start, such as at the end of the month, first day of the week, etc. As an aside, there is no "Offset" when the "Frequency" is "Upon Request." Finally, "Response Time," represents the total amount of time allowed to execute the business process; for example, ten seconds, one day, etc.
These timing nuances will ultimately influence the processing of transactions. To illustrate, if the "Frequency" is once a month, beginning on the last day of the month, with an hour or more "Response Time," this will likely result in a "Batch" process which is still actively used today. However, a Frequency of "Upon Request" with a five second response time will likely result in an "Interactive" process, where transactions are processed one at a time.
As an aside, when we consider the performance of a business process, we are basically measuring time versus transactions. If the transactions cannot be processed in the allowed time, perhaps it is necessary to devise a new physical implementation.
Through these rules, the Analyst defines the physical implementation of the business process from start-to-end. This can be depicted using common flowcharts drawn from left-to-right, or top-down.
After the business process has been designed, now is the time to write its testing criteria. This will be used after the Administrative and OA procedures have been detailed in terms of steps in execution, and the software engineering for the computer procedure has been written and tested. This ultimately represents a "string" test whereby the whole business process is tested from start-to-end. In addition to basic testing procedures, the criteria should also specify default values for data to assume, invalid values, and the conditions for resulting error/warning/information messages.
Bottom-line, the Analyst's objective in business process design is to devise the most cost effective physical solution to satisfy the logical specifications of the overall sub-system.
Business process design is less about knowing what tools to use to physically design the process, but rather having the analyst know more about the logical specifications and the mechanics of design (the methodology). To me, I look upon such work as more of a science as opposed to an art form. You can only treat it as a science if you are willing to define your terms and principles. When this is done, you can go even further by automating the design process, not just by pretty pictures, but by automatically deducing the design based on specifications (aka, "inference").
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author: Tim Bryce, Managing Director, M&JB Investment Company
Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at [email protected]
For Tim's columns, see: timbryce.com
Copyright © 2015 by Tim Bryce. All rights reserved.