Making Workflow Work and Flow for You

From a business perspective, workflow is a way to make people, information and computers work together consistently and efficiently to produce the results the business needs. In effect, workflow applies the equivalent of systems analysis to the entire process, not just to the part done on a machine.

MORE ON WORKFLOW

Workflow? BPM? I’m So Confused!

Workflow Gone Wrong

From a bottom line perspective, adding workflow to a process saves money, increases customer satisfaction, gets results quicker and largely eliminates things getting lost in the shuffle.

From a manager’s perspective, the most important benefits to workflow are saving cost and saving time.

“With workflow, the process is really in focus,” says Wilhelm Ederyd, a technical project manager at Bonver, a major Scandinavian distributor of home entertainment products, such as films and music. Another benefit, Ederyd says, is “hiding unnecessary complexity from the users.”

As an example of a typical workflow, Ederyd cites building support for individuals and businesses ordering broadband services via the Internet, postal mail and e-mail. “This can be a rather complex process, with the need for the systems and personnel to interact efficiently in order to make the process slim and pleasant to the customer,” Ederyd explains.

You can think of workflow as systems analysis that mixes humans, machines, documents and other information. In Edervd’s case, he designed the process for ordering and installing the broadband connection for the customer. Typically that means—given a whole raft of business requirements generated by others—working out how the process would flow from the customer’s initial contact to the actual installation: who does what, what the IT system does, when decisions were made and who made them. If you were doing this all on a computer, you’d probably call it “systems analysis.”

Ederyd’s example is a classic case: a fairly complex, multi-step process where computers and people have to interact as smoothly and efficiently as possible. It’s also a process that is exposed to the customer, and delays or mistakes can damage customer relationships.

For Defense Health, an Australian insurance company, customer relationships were particularly important. “We needed a system that would let us answer a customer’s question up front rather than saying ‘We’ll call you back,'” says Andrew Guerin, COO of Defense Health. For Guerin, that meant having processes in place to access information as quickly as possible. Using workflow tools from OpenText, the company designed processes that combined IT systems, documents and people to get a handle on customer queries quickly.

Big and Complex vs. Small and Simpler

Workflow tools are highly stratified. At the top are the workflow modules built into ERP applications such as SAP and standalone products like FlowWare from Plexus. Products in this class typically include process modeling, business rules engines and other features to help reengineer processes involving thousands of workers and thousands—or tens of thousands—of steps.

At the bottom or entry-end of the spectrum, applying workflow to the simplest processes requires no special tools at all. “I have pointed out to some users that what they really wanted is Microsoft Office and a little routing slip between users,” says Johannes Scholtes, president of ZyLAB Technologies, a workflow vendor and consultant. “Of course, you can sell these people a $25,000 application to automate this, but they don’t need it.”

Ultimately, what you need depends on the size and complexity of the processes to which you’re trying to apply workflow management.

Features aren’t the only differences between tools. Usually the products aimed at simpler processes focus strongly on ease of use. The designers’ assumption is generally that the users are nonexperts or quasi experts within the company.

For example, Quask, a workflow software vendor built its application around the concept of an intelligent form. Basically, the user develops the workflow by filling in the form, including the business rules. “Everyone understands what a form is,” Freddy May, CEO of Quask, says. “It’s very much a logical way of mapping paper into a piece of software. People can instantly relate to it.”

The products aimed at larger projects are much less concerned about ease of use. For one thing, vendors expect that the products will be used by consultants or in-house experts.

The division between big and complex and small and simple is important, but it is also somewhat misleading. Since almost any process can be broken down into a series of smaller processes, it’s possible to handle even a large, complex process by chopping it into chunks and doing it one chunk at a time.

The limitations of the simpler workflow tools become evident when they’re asked to manage interprocess dependencies, handle complex database integration and handle tasks that are much more important to larger, more complex processes. The complexity cuts both ways. A really big project requires the tools that come with a big, expensive product. But if you don’t need that big, expensive product, product complexity can slow you down. There is a lot of overlap in what these tools can do.

Workflow from the Bottom

Unlike ERP, workflow tends to use a bottom-up approach to reorganizing the enterprise. It essentially works one process at a time, although you can use it on several processes simultaneously.

In a typical organization, workflow implementations are atomic. That is, while a process may be connected to other processes in an elaborate chain or network, each process is, in effect, a separate project. This is in contrast to something like ERP, which tends to deal with the organization as a whole—and the “whole” should be carefully modeled before making changes.

For more on ERP, see ABC: An Introduction to Enterprise Resource Planning

The disadvantage of the workflow approach is that it takes a while to fully reengineer an organization. ERP is like trying to swallow an elephant in one gulp. Applying workflow to an entire organization is like eating an elephant one bite (process) at a time.

In fact, if the organization is large enough, you may want to consider some of the more advanced business process management (BPM) tools.

The difference between workflow tools and BPM is a semantic distinction, but an important one. The bigger, more elaborate standalone BPM vendors loudly insist their software is not a workflow product, and call their stuff BPM or Business Rengineering. But workflow is at the heart of all these tools. While the formal difference between workflow and business process management is anywhere from murky to nonexistent, in most cases vendors who sell applications labeled as BPM are aiming at bigger and more complex projects.

Also, BPM vendors are likely to offer elaborate software supporting even more elaborate methodologies, modeling, collaboration methods, process definition modules, and on and on and on. The distinction isn’t hard and fast by a long shot, but it is useful.

For more on BPM, see ABC: An Introduction to Business Process Management.

The advantage of the workflow approach, compared with ERP, is that you’re not as locked in as you implement. You can make changes to a workflow process quickly. “Once the system is in place, it’s not the be-all and end-all,” says Craig Cameron of Web and Flo, a Melbourne, Australia workflow consultant and maker of workflow software. “Things will change in the future and you need to have a system that is easy to change.”

The process is going to change. That’s the whole point. You want to improve your processes over time.

Another advantage of a well-designed workflow process is that it can serve as a template that can be applied quickly to similar processes. “Once you’re comfortable with workflow in your organization, it will allow you to implement new business models much faster than [do] your competitors,” says Bonver’s Ederyd. “The cost and complexity of doing so is now manageable.”

Cameron cites the example of a customer, a major Australian bank, that wanted to apply workflow to the process that some of its divisions used to order large amounts of hardware. “They needed to go through all these checks and make sure that the right people had signed off on it,” Cameron says. “So we implemented a system to do that.”

Which was fine until the other divisions of the bank found out about the new process. “We found out later we’d only created a system for three or so of their teams and suddenly another 15 or so teams wanted to be involved,” Cameron says. “Instead of having to do a complete restart, we’re extracting what we’ve already done and cutting and pasting it into a new system. Then we hit a button to create the end user interface.”

Where Do You Start?

Since workflow is a process-at-a-time process, there are two schools of thought in picking your first workflow project. One school is that you start with the largest “”safe”” project that will give you the best ROI. The other suggests starting with the simplest project and taking the others in order of complexity.

NOTE: In this context, “safe” means a process with a high probability of success.

“The process with the biggest ROI is the one it is most important to get right,” says Quask’s May. “If you’re doing it in-house, do the simplest thing first. You’ll probably get a better ROI and get it quicker if you do it the right way.”

May points out that the advice is less applicable if you’re using a consultant or vendor to implement the process. Since the highest ROI project is the one you most want to get right, May thinks you should tackle it after you get experience on smaller projects. Obviously, if you’re hiring the expertise in the form of a consultant, this doesn’t apply as forcefully.

Beyond that, there are several important things common to all successful workflow implementations.

• Start right.

“A workflow implementation should be as simple and robust as possible,” says Ederyd. “A complex solution often indicates you are trying to support goals other than those defined, and this will add risk to the project.”

Identify an individual who is capable of analyzing what needs to be done. Someone within the organization has to analyze the process.

• Talk to all the people involved to make sure all aspects of the process are fully understood.

Ederyd adds, “Active user involvement is a key to success. You really need to sit down with the users and watch and question how they perform their tasks in order to identify the scope for the solutions.”

ZyLAB Technologies’s Scholtes, whose company includes a workflow consulting practice, recommends getting use cases from users. “The only way we’ve been successful is to talk to the end users and try to get some use cases on paper,” he says. ZyLAB typically starts with standard use cases from its library, and then asks users to point out how their way of doing things differs.

“Once we’ve got that, we make a flow chart or a UML diagram and try to find agreement with the end users,” Scholtes says.

• Define the process.

“The biggest problem is knowing what you want,” says Scholtes. “People often do work differently from how they think they work. With workflow, you’re going to really pin people down.”

• Draw pictures.

In the world of workflow, these are known as “visual process models.” They represent the process and the roles of the various affected groups in a simple, easy-to-understand format.

“Diagrams are critical,” says May, even if the process is trivial. “What a diagram does is basically prove you’ve thought about what you’re doing. The temptation is always to say ‘I know how this works.’ More often than not you don’t, because you haven’t taken the time to analyze the process.”

Don’t be afraid of the white board. “Users, especially management types, find it a lot easier if they’re given a graphical representation,” says Web and Flo’s Cameron.

According to Scholtes, UML diagrams and flow charts produced in the early definition phase are useful for outlining the process. But, he cautions, they’re not ideal for communicating the process to others. “Only a few people can read a flow chart,” he notes.

“We show diagrams to the end user but we also show implemented workflow,” Scholtes says. “We show them how the process works and we show them the diagram.” ZyLAB supplements the graphics with screen shots of the process in operation.

“As systems become more complicated,” says Cameron, “and workflows start flowing into each other, it’s a lot easier just to click through the maps.”

• Pay attention to exceptions.

It is in the nature of processes that users judge them more by what goes wrong thant what goes right. In workflow, the term is “exceptions.;” Yyou need to make sure that the inevitable exceptions are handled smoothly.

“A lot of customer dissatisfaction is based on how clumsily exceptions are handled,” says Ederyd.

• Pilot and test.

Make sure the process works before you rely on it. Some organizations run the old and new methods in parallel until they are satisfied with the workflow implementation.

Workflow isn’t rocket science, but it isn’t magic either. While workflow can make major improvements in the way an organization runs, it can only do so if the principles are applied correctly. Fundamentally making workflow work for you comes down to understanding the processes that make your business work.