Besides the entity-relationship diagram that I described in Part One of my article, the other major component of information engineering is the functional decomposition diagramming technique. In this practice, an organization is modeled in terms of the functions for which it is responsible. This follows a strict top-down approach. The enterprise is modeled as one box, which is then decomposed to the next level. This continues until the decomposition reaches a process level. It is at this point, that the diagram ceases being a functional decomposition and instead becomes a process decompostion. It is important at this time to differentiate between a function and a process.
A function is a set of business activities that does not have a finite start and end point. The function is generally an ongoing effort within in a company.
A process is a business activity which does have a finite start and end point. Processes are generally a lower level of abstraction than a process.
Some examples are:
- Class Registration is a function and Register for a Class is a process.
- Accounts Payable is a function and Create a Check is a process.
- Flight Reservations is a function and Reserve a Seat is a process.
A functional decomposition diagram was useful in an information engineering environment. The functions were decomposed to processes. The processes were converted to program specifications. The program specifications were converted to program code. This was a logical progression (This describes the theory of the decomposition. The actual practice and validity of the use of this practice is a subject of contention, and will not be addressed in this work.)
If done properly, a functional decomposition diagram should represent the entire organization. This representation should categorize functional needs. As data warehousing has shown, the design is user centric and is based on the needs of a particular set of users. By examining the functional decomposition diagram at the leaf (lowest) level, an inquiry should be made as to the measurements of that function. This measurement, usually a fact in a data warehouse, should represent how this function analyzes or measures their function. One should guard against analyzing what data is captured by that function, but instead focus on the measurement of fact.
By organizing at a fact to function level an organization has a high level understanding of the measurements across the organization. This is done by function also, as compared with by organizational unit.
Suppose an organization has the following functional decomposition (greatly simplified for discussion purposes).
COMPANY
/
/
SALES MANUFACTURING
/ /
/ /
SALES SALES PRODUCTION QA
MANAGEMENT FORE- SCHEDULING
CASTING
Upon interviewing the respective employees in the functional areas, it is determined that:
- Sales Management measures Revenue per Week per Sales Representative
- Sales Forecasting measures Revenue per Month per Region
- Production Scheduling measures Units Produced per Hour per Plant
- Quality Assurance measures Defective Units Percentage per Lot per Plant
By arranging the captured information in a matrix format where the functions are rows and the measurements are columns, one for each measure and one for each dimension, a concise graphical representation of enterprise high-level reporting needs can be demonstrated.
|
Measurement |
Time |
Dimensions |
| Sales Management |
Revenue |
Week |
Sales Representative |
| Sales Forecasting |
Revenue |
Month |
Region |
| Production Scheduling |
Units |
Hour |
Plant |
| Quality Assurance |
Defective Percentage |
N/A |
Lot, Plant |
It must be acknowledged that each functional area will most likely utilize multiple measures and the dimensions should be more exhaustive than the above example.
Once this analysis is complete and the matrix is validated, it should be examined and analyzed for commonalties. These commonalties can be exploited in system design and scoping as well as having impact on organizational and business process refinement.
About the Author
Anthony Politano is CEO of the US division of MIS AG. He has over 14 years experience in the IT industry, specializing in business intelligence, data warehousing, large-scale application development and systems development methodologies. Mr. Politano was previously a Director at American Home Products, where he was responsible for building an enterprise data warehouse and multiple data marts. Prior to AHP, he was Practice Manager for data warehouse solutions with Oracle Consulting and was a Managing Consultant for James Martin & Co.
For More Information
