Dutch Lab Manages Millions of Processes with BPM Software
Because BPM software can automate repetitive processes and can allow business people – not developers – to control changes to computer processes, it was a good solution for the Dutch company, which was increasingly faced with tight deadlines to create new tests when fast-moving threats like blue tongue disease surfaced.
The Background of this BPM Case Study
Animal Health Service, known as GD, is the execution arm of the Dutch agriculture cabinet. A 500-person private agency that was formerly part of the Dutch government but has been privatized, its large labs specialize in developing animal health programs to test for disease in various livestock animals. By developing and implementing certification programs for Holland's 60,000 farmers, GD helps both government and industry monitor – and quickly react to – animal disease like avian flu and foot-and-mouth disease.
The testing process begins at GD when a customer, often a Dutch farmer, elects (or is required) to participate in a particular testing or certification program. In response, GD might conduct a first round of lab tests on a blood sample from a farm animal, and then react in various ways according to the test results – ordering more treatment, for example, or more tests, or a waiting period. The numerous test series the lab conducts over and over "are very process-oriented," according to Andries Bosma, GD's application manager. "We have lots of projects, and they all differ just a little bit."
With about 150 administrative workers at GD serving some 60,000 Dutch farmers, computer automation of processes was critical even before a BPM product was selected and installed. The firm conducts close to 4 million lab tests a year, Bosma estimates; a truck leaves the lab each day with forms and information mailed to farmers.
"Everything must be automated, because the volumes are so large," according to Bosma. But the company's earlier approach – working with outside software firms to program new processes as needed – became increasingly difficult because of the complexity of new processes, tighter deadlines, and the difficulty of explaining processes to outside developers. As critical issues like blue tongue disease hit the headlines, delays in waiting for a program to be built around a new test became less and less acceptable. GD needed to be able to react more quickly, with faster time to market in releasing new eradication and prevention programs.
The business process management system GD selected is from Intalio, a BPM company based in Redwood City, CA. Intalio|BPMS is a BPM solution that espouses a "zero-code" development model that allows ordinary business users to make substantial changes to a system by altering drawings that represent business processes. Before, correcting a problem in a software process could take months. With Intalio, the change can be ready by the next morning, Bosma says: "You change the process drawing [in Intalio], you test it, and it can be in production."
As early as 1993, the company had put in place a BPM system of sorts for managing its certification system. But as GD needed more capabilities, including the ability to make changes quicker, "that system was getting more complicated to maintain," Bosma explains, "and the maintenance was getting more expensive・We knew we needed a better process management [system]."
Build vs. Buy
GD first considered building a custom system by working with programmers, as they had with the then-current system. But when they examined the market, they discovered that ready-built business process management software was emerging, including Intalio's solution. In 2003, Bosma says, when GD selected the product, "Intalio was one of the first companies that actually had a working solution that also [could] scale for our volume of processes." Because the company runs so many processes at once, the ability to scale up without a performance hit was critical. "It had to be very fast," Bosma says flatly.
Also, with some 6,000 processes running at once, it was important that Intalio allows a process to be changed, tested, and seamlessly re-introduced into the process flow, something the previous system didn't support. "That's a real technical highlight of the system," Bosma explains. That sort of flexibility is also useful if product conditions change while a process is running – if the price for a test increases on a given date, for example, or if new tests are suddenly required. Those sorts of changes can now be made by business users mid-stream.
The architecture was also important, because the new BPM system would have to integrate with GD's existing systems. "We try to do as much on Oracle as we can," Bosma says, "so the integration with Oracle was very important."
They also wanted a solution that would allow business people to create powerful processes "without any hard programming." Typical BPM system users at GD are computer-savvy business people such as project and certification managers, not developers.
GD has set up the Intalio system to work as a message generator of sorts, in which all processes are triggered by messages. "Everything that happens anywhere in the company is transformed into a message," Bosma says. "The messages are stored in the queue system; Intalio reads the messages and starts the [appropriate] processes" based on messages; results are stored back in the Oracle databases.
That architecture allows access to a stable backend database, along with user-friendly front ends. "We can have lots of user interfaces into the base data, for instance," Bosma says, while remaining flexible in what processes are included in the system and what they can trigger.
As the system is set up, it runs almost entirely automatically, and people are flagged only when high-level approval is needed or if something goes wrong. A very small fraction of messages require human intervention. On a typical day in December, for example, 350,000 messages had moved through GD's system by late in the business day; just 40 of those had required any sort of manual intervention.
Setting Up BPM System Proves Tough
Setting up the new system and testing it adequately has proved to be a lengthy and arduous process, Bosma admits. Performance problems with the software were an issue at one point, but far more effort has gone into simply transferring processes from the existing system into Intalio. After three years, GD is about 30 percent of the way through moving the lab testing and certification processes into Intalio; the remaining implementation will probably take another two years, Bosma estimates. "It's quite complicated," Bosma says. "There are a large number of processes." The process is speeding up as workers begin to establish a base of test processes, he says, allowing new processes to be built on existing, similar ones – such as tests for a new animal disease that is similar to existing ones.
Besides code migration, the product definition also must be changed in many cases, depending on how old the test is. The product definition is issued to a customer, describing testing rules, prices and procedures. Because some tests in the previous system were as much as 10 years old, in many cases developers must read through the old code, understand it, and then transfer the process into Intalio. Oracle developers are needed for changes such as new user interfaces, Bosma says, but simple queries and changes to existing processes can be handled by business users. Most users "are smart people, and they're used to working with computers; but they're not Oracle developers."
Intalio provided some initial training, as did the Intalio-certified systems integrator that GD chose to work with on the implementation. "We can train someone [internally] with previous computer experience in 14 [working] days," Bosma says. Depending on the point in the rollout, from two to 10 consultants were working on the implementation at a time, though the integrator's role has diminished as the product has stabilized.
Any concrete, measurable savings to be realized from the new system are well in the future. For now, Bosma says, the payback is in streamlined processes that free users to spend time on other tasks. "You can see the change already," he says, in terms of greater efficiencies in how users' time is spent.
In hindsight, Bosma says the most challenging part of the project has been integrating all the smaller parts into an entire working system. "We had a lot of loose instruments; it didn't sound like a symphony for a long time," he says. Integrating management processes with the specific demands of product managers on the lab floor, for example, was challenging "and something we underestimated."
Bosma's advice: To solve some of the biggest issues of integrating a new and complex business process management system, divide and conquer. "You can solve huge problems if you first make your problems smaller・there are sometimes several worlds that have to be joined."