by Michael Tardif, Assoc. AIA
Contributing Editor

Summary: Business processes in the building industry have developed over many years, and though many processes and workflows are often regarded as “standard” practices or procedures, very few of our business processes have actually been documented. Though the workflow of activities, such as requests for information (RFIs) and change orders, may be consistent enough from one organization to another to be recognizable as distinct business processes, individual practices vary considerably. These variations in practice may be slight, but they are significant enough to stymie automation of workflow and information sharing across the industry and even among individual project teams. The lack of standardization of workflow undermines efficiency and productivity in hidden ways. The building industry is working to document these individual day-to-day exchanges of information in the context of the overall business process. Once the “big picture” is defined, we will have a much better idea of how these individual tasks and activities fit together. Then we will be in a better position to manage the transformation of the entire building lifecycle.

Information delivery manuals
If our business processes are to be automated, the required content of information exchanges must be defined. Although the Industry Foundation Classes (IFCs) of buildingSMART International provide a common exchange standard for electronic building information, the IFC data format does not describe individual business processes within the building lifecycle or the information needed to complete them. In recognition of this gap, Statsbygg, the government agency that manages the real estate portfolio of the government of Norway (the Norwegian counterpart to the U.S. General Services Administration) launched a buildingSMART project to develop an Information Delivery Manual (IDM) in 2005. For industry professionals, IDMs will provide a plain-language description of business processes, the information requirements for each process to be carried out successfully, a description of additional information that the person executing the process may need to provide, and the expected outcome of each process. For software developers, IDMs will identify and describe the detailed functional breakdown of each process and the information-exchange requirements for each process.

Figure 1 shows the role of IDMs in the information exchange process. To begin, end users define the content of information exchanges in plain English. This provides software companies with a clear definition of the information exchange requirements that their software applications need to support. Software developers then use an electronic information exchange mechanism—preferably, an open-standard data format such as the IFCs—to support the reliable and accurate exchange of information among software applications. Because the data set is defined and documented, end users are assured that the information they need will be included in the information exchange.

Figure 2 depicts a simple information exchange in the early stages of the building lifecycle, in this case the information exchange that takes place between a contractor and a supplier to purchase and install doors. Although the transaction is simple, all three components of information exchange depicted in Figure 1 are needed to execute the transaction electronically and capture the information generated by the transaction for the remainder of the building lifecycle. The transaction begins when the contractor extracts specification information (e.g., size, material, quantity, or fire rating) contained in the building information model to place an order with a supplier or manufacturer. (The actual order process is likely preceded by a request for pricing process—yet another workflow process and set of information exchange requirements would have to be defined.)

These prescriptive specifications, the “data input” needed for the transaction, are based on a set of programmatic or project requirements and constraints, such as the desired level of LEED certification, and the required data format to ensure the reliability of the information exchange. Together, these define the boundaries, limits, or “controls” for the information to be exchanged.

The delivery of the doors is typically accompanied by a packing list that details the actual items delivered and their cost along with additional information provided by the manufacturer, such as handling and installation instructions, operating instructions, and warranties. Ideally, this information, the “data output” of the transaction, is captured at the time of delivery and incorporated into the model, which is continually enriched by the output of individual business processes.

Simple workflow diagrams such as these can be developed for every business process in the lifecycle of a building. In current practice, these activities and the content of the related information exchanges are continually and often poorly redefined. Small variations in practice become constant sources of miscommunication and enormous impediments to increased efficiency, productivity, and effectiveness. IDMs are intended to define “best practice” business processes and the scope of information generated from those processes that should be captured in a building information model.

Building relationships
Each piece of software that a building industry professional deploys has a relationship to a certain set of activities in a business process and has embedded within it associated information flows. The information that the software needs to perform its function as well as the information that the software generates is of value in supporting that group of activities. The problem is that in a merely operable world there is no relationship between the input/output of one software application with other software tools.

This level of functionality, while it produces useful results, is also extremely wasteful as it causes information to be manually re-entered into one software application after another. The non-value-added effort is significant—most of the inefficiency and waste in the building industry today can be attributed directly to it, and it often leads to information not being entered into “downstream” software applications. Subsequent business processes are literally starved for accurate and complete information, eroding the efficiency of those processes before they even begin. This has become an accepted norm in our operable environment because it is simply too costly to do anything else. Hence, rules of thumb and other shortcuts are used to simulate or summarize information instead of exhaustively re-gathering complete and accurate information. Figure 3 graphically illustrates the information losses that occur throughout the building lifecycle. The continuous line represents the “to be” condition in which all data are preserved for the next phase of the lifecycle, and for which only additional information—the “output” of each business process—needs to be added.

It depends on your point of view
If a software application has a good “awareness” of how information will come to it, then it can minimize the effort needed to import that information. There is no business process in the building lifecycle for which this critical need does not exist. Though information flows within individual business processes are challenging enough, when the flow of information from one business process to another in the building lifecycle is considered, the challenge extends beyond the ability of software applications to talk to one another. Every group of stakeholders has its own jargon and views information from a different perspective. The units of measurement alone may be an obstacle to accurate and reliable information exchange. One stakeholder may measure building area in square feet while another thinks in terms of the number of beds. An architect or engineer may think of a concrete slab in terms of its length, width, and thickness, and how it connects or relates to other permanent structural elements. A construction cost estimator thinks in terms of cubic yards of concrete, how much temporary formwork is needed to support it, and how the formwork can be erected and dismantled.

The underlying data remain the same; it is how each stakeholder views the information that is different. Software applications designed to support the business processes of each stakeholder cannot rely on the equivalent of “cut and paste” for information exchange. That is why building industry organizations worldwide are engaged in defining “best-case” business processes that will allow information to flow—reliably, seamlessly, and accurately—across these boundaries.

Copyright 2008 Michael Tardif. Reprinted with permission.