Anthropology - Part 3: Uncovering the Semantics in Work Flow

Anthropology—Part 3: Uncovering the Semantics in Work Flow

Business process, or work flow, is another rich vein for semantic investigation. Initially it is useful for discovering semantics that may not have come up in the more data-oriented review described previously. As the project progresses, we can use semantics to better understand what options are available and how routing should progress at each stage along the way.

Classic work flow starts by interviewing a large number of people to document the current flow of information. In any large company, this rapidly becomes extremely complex. This is because users, and often the people interviewing them, are more comfortable with specifics and not abstractions. They are likely to remember, discuss, and go on at great length about each minor variation or exception in the process. This is their job, and they typically have many years of experience working through special cases.

Unfortunately, this isn't very helpful. Work flow proponents believe that by documenting the "as is," you can cross out a lot of the boxes, achieve a more streamlined flow, and save the company lots of money. The reality is that the level of detail obscures rather than reveals what is essential.

You may be tempted to integrate the process I'm about to describe with the semantic modeling sessions described previously; many of the same participants will be there and many of the same topics will come up. We have found, though, that having a separate meeting is more productive. People come with an expectation of talking about process, and they will be armed with forms, examples, and exceptions.

The biggest trick is to avoid descending into the detail of the "as is," while still capturing the richness of the current problem (and the economics, because many projects are still justified by savings defined and denominated by work flow simplification).

Essential Long Duration Business Transactions

A long duration business transaction (LDBT) is an interchange between an organization and another party (usually, but not always, external) that takes a long time (hours, days, months, or in some cases years) to complete. A traditional short duration business transaction, such as a retail sale, is processed in its entirety. The transaction is posted to the database and it is complete.

With an LDBT you enter into a relationship, centered around a transaction, and over the life of the transaction much information is added and changed. The transaction goes through many states. It occasionally branches into multiple transactions.

A canonical example is a purchase order. It may start as a request for a quote, become converted to a purchase order, and involves the shipment of goods, acceptance, and invoicing. When all the goods have been received and paid for, we declare the LDBT "complete."

Many LDBTs have longer lives than the organization that deals with them, and in those cases we have found it useful to examine the entire life cycle of the LDBT and then note where, currently, the organization that is dealing with it picks it up and drops it. Mortgages, for example, start with a home owner desiring a loan, and run until the loan is completely paid off. It is rare that the company that originates the loan is the same one that services it, and nowadays this is not the organization that owns the underlying contract.

The Essential LDBTs

Most organizations have a few essential LDBTs. One of the first places to check is the taxonomy of business processes we introduced in Chapter 2, and determine which of these generic processes are conducted by the enterprise:

• Extraction (mining, agriculture, forestry, oil, and gas)

• Conversion (manufacturing, generation)

• Transportation (planes, boats, trains, conveyors, pipelines)

• Facility service (janitorial, construction, maintenance)

• Personal service (health care, haircutting, entertainment)

• Business process (legal, accounting, information service)

Each will have a few LDBTs that define what business the organization is in. "Sales" may be an LDBT, or it may be the front end for a longer-term LDBT of delivering a product or service. In any event it may imply and be nested within another, longer-term LDBT, "customer acquisition and maintenance." If you are in a business where you do not deal with the same customers repeatedly, you may have customer setup as part of the sales process. But most businesses expect to have repeat business and therefore have a customer relationship management process that lasts much longer than any sales transactions.

So you define a few essential LDBTs and schedule your work flow meetings around them.

The Predominant Flow

There is some default or most frequently occurring process flow. You need to start with this. You will need to annotate this with transaction volumes and financial value to the enterprise. Say the LDBT is loan origination through to resale to the servicing organization. You will document how often this is currently occurring, how much it costs, and what it is worth to the organization. Study all the semantic entities that are related to it, in the most common or default case. There will be some things that are essential even at the default level. In the loan example, there will have to be some process to value the pledged property, some process to establish the creditworthiness of the borrower, some process to ensure that the borrower has title to the property, and some process to select and configure the particular loan instrument (term, rate, points, etc.).

Variations

Each variation is based on some subcategory of one of the semantic types in the primary flow that at some time was deemed worth handling differently. This is the time to investigate whether these variations are still worth treating differently. With the loan, one of the first variations is "new purchaser" versus "refinance." On the first category you may find differences between "new home" and "existing home." You have a series of categories based on credit ratings. At each point you want to document what is different, why the difference is worth treating differently, and what the work flow "rules" are related to the difference.

This process will smoke out most of the work flow variations. It will sort between those worth distinguishing and those not worth distinguishing. It will also keep you out of the detail of the existing work flow.