Anatomy of a Process

Map the connections between your knowledge assets for strategic business gain

Over the years, your organization has accumulated a portfolio of information systems (IS) to meet various business needs. These systems are now critical business assets that contain crucial corporate data and information and incorporate programs that implement various business processes. The data, information, and programs in these systems are your knowledge assets.

Organizations are increasingly relying on IS to seek strategic value for the business as a whole. Investing in the IS assets to meet your changing needs, managing to reduce IS operations risks, and above all, harnessing these assets for competitive advantage is the primary function of your IS department. Your IS department must not only exploit these assets to improve business process efficiency, but also to improve IS effectiveness in executing the business strategy.

Understanding Your Assets

To derive the maximum value, you must understand the nature of your IS assets and how they link to your business and to other information assets. In this column, I will show one way of analyzing these information assets.

You can divide current IS portfolios into three categories: institutional systems (including ERPs), groupware systems, and personal productivity systems. This categorization is based on the criteria of usage level, data volume, application complexity, depth and breadth of organizational knowledge about the application, and the overall management support provided for the application. This categorization is important from the knowledge management (KM) perspective as it determines the extent of application knowledge deepening within the organization and correlates it to the resources your organization consumes.

Institutional systems have high transaction and data volumes with a large number of users. These systems typically perform low-order processes, such as accounting or operational processes. A centralized IS department maintains the systems, and the data models and program behavior are widely understood across the organization. From a KM perspective, this centralized maintenance and widespread "know how" make institutional systems well managed.

Groupware systems perform higher order processes than institutional systems, such as project planning or product design management. Groups or teams - not the entire organization - understand the data models and program behavior of these systems, and the central IS department mainly supports the systems' technology and integrity (their availability and reliability). Although some IS departments also build capabilities such as skills and know how in developing groupware applications centrally, they primarily cater to ad hoc application needs and do not use a common framework or methodology. From a KM viewpoint, therefore, groupware systems are not managed as well as institutional systems.

Personal productivity systems perform the highest order processes, such as pricing models, sales models, risks models, benchmarks, and so forth. Typically, one or two individuals highly proficient in a particular process model develop these systems, and only a few individuals understand the data models and program behavior. The IS department's support for these systems is purely confined to "off-the-shelf" technology know how. The IS department is unaware of the existence of these systems, except for generic types such as the spreadsheets. From a KM perspective, these systems are poorly managed.

I did not include a separate category for departmental systems because ERP systems have subsumed the departmental systems of the past. In contrast, groupware systems have proliferated across the organization. In addition, the older departmental systems, confined to departments or business units within organizations, were largely function oriented and based on structured data. Groupware systems are not only function oriented, but can also be project or issue oriented. They also use unstructured data and span across different departments and, in some cases, different organizations.

Repercussions

Does it really matter if personal productivity systems fair poorly from a KM perspective? After all, these systems incorporate higher order processes that need not be widely known. They typically support an organization's decision making and strategy management, which is the domain of senior management. Furthermore, unlike institutional information systems, personal productivity systems do not need to be reusable.

These arguments, although valid, do not provide enough justification to neglect examining these systems from a KM standpoint. First, take a look at the amount of resources used for the support. Organizations typically use the most IT resources on help desk support for personal productivity tools, less on groupware systems, and the least on institutional systems. (See Figure 1.)

But even more important, the higher order processes performed by the groupware systems and personal productivity are necessary for managing competitiveness. An organization's business strategic value lies more in these systems than in the institutional transaction systems. For example, a few years ago, a major European airline wanted to purchase aircraft from a U.S. manufacturer at future delivery dates. They wanted to minimize the risk in exchange rate changes at the delivery time as compared to the purchase agreement date. They therefore bought additional protection (or in other words, hedged future aircraft purchase transactions for exchange rate risk). As it turned out, the corporation did not need to buy the additional protection (hedge the transaction) as the bulk of its airline operations business was already conducted in U.S. dollars. It lost money in the additional protection costs by not knowing its overall risk exposure.

Even today, many corporations do not know their aggregate risk exposure, because many risk models are built in isolation to each another, in separate spreadsheets or specialized analytic tools. Given the state of these models, I wonder if such a correlation across the models could be spotted with existing IS alone.

This example illustrates the link between different systems, such as those designed for risk management and for financial accounting. As mentioned before, the former is typically found in spreadsheet forms, while the latter is part of the ERP system. IS, which spans your business processes, has many such links. If you don't identify and understand these connections, you not only lose opportunities to exploit the value of IS, but also increase your risk exposure.

How can you better identify and understand the connections among IS systems? Currently, many companies are creating an organization data model or data dictionary as part of their information architecture. This task is necessary and requires meticulous attention as it creates a holistic view of your information and data, similar to Gray's anatomy of the human body or a geographical survey of a region.

But creating the data models is not enough to understand the connections. You also need to understand your business processes, including those implemented with groupware or personal productivity tools.

Along with the creation of the data models and dictionary, you must take a comprehensive inventory of all the different types of processes within your organization. Keep in mind that this process inventory does not mean that you can also easily create an inventory of all processes implemented in the personal productivity and groupware systems. Although to a certain degree you can use automated discovery tools like Web crawlers to build your application inventory, these tools lack standards or conventions and are far from comprehensive.

Effective Processes

After your process inventory is complete, you must analyze the processes. This exercise is somewhat different from the business process reengineering (BPR) exercise carried out during the process efficiency exercises of the late 1990s. The BPR primarily mapped the workflow of low-order processes to increase their efficiency. The BPR did not focus on the high order processes. The purpose of high order processes is to improve your business strategy effectiveness, not efficiency.

In this next exercise, you must analyze the effectiveness of each process. Unfortunately, process effectiveness is more difficult to measure than process efficiency. Traditional systems analysis and modeling tools are inadequate.

One way to understand the effectiveness of your processes is to understand the connections or linkages among processes. The type of linkages will shed some light on the nature of the process and its place in the mosaic of organization processes. Keep in mind that the processes with the largest number of links are not necessarily the most effective. Only after analyzing the nature of each process, along with its linkage to other processes and its relevance to organization strategy and goals, can you determine the most effective processes.

Unfortunately, computer science has not advanced enough to extract relevant knowledge from existing IS. You cannot determine, in an automated way, a software program's purpose and how well it has performed its intended function. The closest solutions commercially available only determine if programs are Year 2000 compliant or if they have well-known security exposures or virus infections. Although some additional laboratory experiments are available, they do not scale easily to a commercial environment because of the high costs. You must manually determine most of this task, and currently, this task is admittedly subjective.

Building the Framework

Once you have the inventory of process types and analyze the processes and connections, you can create a framework environment for each process type. Application developers can use the framework environment as a guide for implementing new applications within a preidentified process or for modifying an existing application. These application developers include those groupware and productivity system end users that want to implement their own processes and models.

The framework comprises application templates that you can use as a starting point for a new application. The framework should also contain the process topologies and connections you identified earlier. These topologies are useful for pointing out correlated processes that may affect or be impacted by a new process. These topologies also identify predetermined data and information interfaces that you can use to connect various systems and underlying processes.

Benefits of Knowledge

Common standard interfaces increase the application's reusability, which helps developer productivity. Developers can also access your company's data models. These data models interlink with your process maps, which lets developers navigate between the two and fully comprehend the connections. Finally, the developer can peruse the previously cataloged system implementations of the process for possible reuse.

This framework supports both the highly decentralized IS development environment and the centralized custodial management of the IS portfolio. This framework retains the flexibility and creativity needed for local problem solving, but also allows consistent and centralized policies that otherwise create an undue burden on developers.

This methodology and discipline substantially reduces development effort and the costly mistakes made as a result of a lack of knowledge about your company's process maps. Having a knowledge base of your IS applications portfolio as a framework is crucial for creating and maintaining your new and existing IS applications.

You must maintain your IS portfolio knowledge base just like any other knowledge base. You must screen it periodically to ensure logical consistency across the knowledge base. You must also periodically scan the actual IS programs to automatically detect new links, identify violations or exceptions in preidentified links, or detect other intelligence. Over time, you can enhance this process with newly discovered techniques and further augment your knowledge base.

I've painted a very ambitious method for managing your IS assets in this column. Many of the technologies or products for the tasks I've described are not currently available. However, managing your IS portfolio from a KM perspective is a strategic direction rather than a tactical product implementation issue.

Such a framework or IS portfolio knowledge base is more an evolutionary exercise than a revolutionary one. You need to set the direction so that you can implement components that will lead toward a more comprehensive framework. Current intranet technologies such as Web crawlers, intelligent agents, data mining techniques, and multimedia conversion products have made substantial strides in this area, but much more remains to be done.

Raju Kocharekar (rkocharekar@worldbank.org) is business manager of the enterprise computing unit in The World Bank's information solutions group. He has 19 years of professional experience in IT infrastructure management and support.