Before business systems became computerized information traveled through organizations on paper. Where multiple people were involved information was often recorded on forms and then forwarded to the next person or department to be processed and so on. Due to these breaks in the flow controls were developed in order to ensure that transitions took place. The objective of these controls was to prevent breakdowns in work flow but often they manifested as protective measures between employees.
In the auto repair processing cycle a repair order can flow from person to person depending on the size of the environment. In a simplified process, the service advisor identifies the work and services required, the parts manager prices the parts, the service advisor obtains approval from the customer, the work requirements are forwarded to the technician to be done, the technician reports back that the work is complete, the service advisor contacts the customer, the customer arrives to pick up their vehicle, the counter person gets payment and delivers the vehicle. Of course a single person can wear several hats but the idea is that information flows from one person to the next.
In some cases – management desire to control aspects of the business at a very low level can result in inefficient work flow. In some cases – employee efforts to avoid blame can have the same result. The result is that work and information doesn’t flow from one person to the next. All activity is controlled from a central point. So each time an activity in the process is performed – rather than progressing to the next step the process involves reporting back to a central point that the step was complete and the person(s) at the central point initiate the next step. This type of process flow often occurs during a diagnosis situation when there’s a parts person involved. Sometimes the technician identifies work required and reports it back to the service advisor who then asks the parts person to source and price parts for the needed repairs. A more cyclical flow would be to have the technician forward the requirements to the parts person who would determine parts availability and pricing then forward the information to the service advisor. Of course this will not apply in all situations as there’s no set rule for any part of the repair process.
Early computerized systems were developed to support processes that were designed prior to the advent of computers. So they often didn’t take full advantage of automation. Because they were built based on manual forms and the path they travelled through a business they often were document-focused as systems were designed for each person to add information to a once manual form that had become electronic.
Understanding the concepts of document-focus and centralized control of information flow will bring to light the architecture of software systems and business processes employed as both are inter-related. Business processes and support systems that depict a hub and spoke architecture may be appropriate in some cases or they may be the best alternative based on personnel. But often times they’ve evolved that way for other reasons. Additional steps in workflow decrease productivity and the hub-spoke process model should only be employed when necessary.
