To truly arrive at a flexible information technology (IT) infrastructure, you need a technical evolution of your organization's processes and, often, the skills to leverage existing technology investments. One way to get there is to implement the concept of process monitoring throughout your business.
Process monitoring -- tracking individual processes for optimum performance and ROI -- can impact businesses in different ways. How and when you perform process monitoring depends in large part on your organization's needs. For example, one organization may want to evaluate and analyze its supply chain using real-time statistics while another may prefer to focus on a complete transformation of its enterprise resource planning processes.
Seasoned architects know that process monitoring is -- or should be -- a key element in any design. In fact, in the ideal business environment process monitoring occurs before, during, and after design implementation. It is critical to ensuring that complex system landscapes deploy and then continue to work as planned. And, if they don't, it allows you to quickly identify and proactively handle critical problems before any major damage occurs. This article looks at the three primary categories involved in process monitoring: cycle time, defect rate, and productivity. As you read through the categories discussed in this article, consider the current focus in your organization and how each category can be applied to that focus.
When you think about it, business process management is really a combination of business management and information technology skills. Ideally, every process has a purpose, and the majority of processes are handled with some form of technical assistance. Whether it's the sales process or the loading dock returns process, technology is typically hovering in the background gathering information that is used in all parts of the business. These kinds of major processes are basically organized activities that use smaller processes (steps) to arrive at an outcome. Regardless of the process, all process steps can be lumped into one of the following categories:
- Added value -- Adds form, function, and value to the ultimate end result
- No added value -- Does not add form, function, or value to the ultimate end result
- Essential with no added value -- A necessary step that doesn't add form, function, or value to the ultimate end result
As you monitor the processes in your design, keep these three categories in mind. Value is seen in different ways by different clients, so it's important that you clearly understand how your clients see various aspects of the processes you're monitoring. For example, you might see a particular portion of a process as one with no added value and, therefore, a step that can be eliminated, but your client might disagree. Rather than guess, go ahead and ask lots of questions as early in the design process as possible to clarify your client's view of the steps involved in the targeted process.
Every process has a cycle time -- the total amount of time required for a process to occur. By some technical definitions, it's the total elapsed time needed to move a unit of work from the beginning to the end of a physical process. The actual cycle time should be clearly understood by both you and your client, by the way. Just because you think a process takes a certain amount of time doesn't mean that's how the client sees it, so double-check to be certain you are both on the same wavelength.
As part of your design, you already should have mapped out the major processes. To start determining cycle time efficiency for a given process, you need to map out the more detailed steps in the process as well. This can be time-consuming, of course, but without a clear understanding of all the steps involved in a process it's very difficult to determine the efficiency of a process cycle. For example, if you're monitoring the returns process for your company, you need to know every single step in the process from the time the truck arrives with the returned product to the time the product is repaired and returned to the customer, refurbished and sent to the store for resale, or discarded.
After the steps are mapped, you can determine how much of the process is an added value and how much falls into one of the other two categories. Figure 1 demonstrates one way to categorize the process steps for the returns process.
Figure 1. Returns process categorization
Now, you may or may not agree with the categorization shown here, but that's okay. In fact, it's immediate cause for discussion with your client when you see any steps that appear to add no value (whether necessary or not). Perhaps you can find a way to eliminate a step that the client thought was absolutely necessary, for instance. Maybe you discover that information gathered during a seemingly unnecessary step of no value can actually be used in another part of the organization to improve productivity. Whatever you discover, it's probably going to help you identify cycle time issues such as overproduction, wait times, and so on. When you can identify those, you've begun to monitor the process for efficiency.
One way to determine whether the cycle time in a process is efficient or not is to determine the actual times involved in the various portions of the process categories. So, in the example above, the added value steps might take a total of 300 seconds and the steps with no added value might take a total of 600 seconds. You can see at a glance that the added value steps take half the time of the other steps. To determine how much of the overall cycle time is efficient, divide the added value time by the entire cycle time for the process, like this:
300/900=.33 (33 percent).
So, in this sample process, just one-third of it adds quantifiable value to the organization.
Clients almost always want to improve efficiency, especially when it saves money or produces more revenue. When you can explain the cycle time efficiency of a process to them in simple terms that they understand, you have their attention: "This process adds value to the organization about 33 percent of the time. I think that by making changes to the process you can improve that to 50 percent of the time." It's always easier to gain acceptance for your process change recommendations when you can quantify how those processes can be improved.
There are bound to be some defects in any process. The more complex the process, the more likely it is that defect rates will be high because of the high risk for error. The question, then, isn't "How do you get rid of defects?" but instead, "What's a normal defect rate for this type of process and where can you improve the process to reduce as many defects as possible?" The only way to know the answers to those questions is to monitor the process over time.
As you do that, you begin to see where the cracks in the process are located. For example, you see how a process holds up during stressful times, such as during prime retail seasons. Do defect rates rise when the process is pushed to its limits? If you begin to see the process failing under pressure, it's time to isolate each piece of the process to determine where the failure is actually occurring. It might be in the human elements of the process; it might be in the software.
After you determine where and how defects occur, you can improve upon your designs to reduce the defect rate as much as possible. Sometimes an incremental approach to changing the process works, but there will be occasions when you must overhaul the entire process. By working with your client to determine which factors in the process are fixed, which ones are variable, and which ones can be eliminated, you can create a new design that adds more value to the bottom line and potentially increases the organization's return on its investment.
Here's what I call the P word: productivity. I hate it, but almost everyone else loves to toss that word around, don't they? It's typically touted as one of the most effective ways to improve the bottom line for a company. Yet, because productivity most often revolves around individual employees with human variables, it's typically difficult to accurately monitor unless you delve deeply into the processes those employees are performing. Still, organizations consider it to be one of the most important accomplishments in business. They are always searching for ways to use information to respond to changing business environments and, according to AMR Research, the single most important driver of IT investment in recent years has been the better use of data throughout entire organizations.
The best way to help your client improve productivity is to monitor processes for inefficient workflows and inaccessible islands of information. If you discover, for example, that employees are keying duplicate information into multiple nonintegrated systems, then you can easily determine the amount of time wasted by such duplication and create a design to eliminate the redundancies. In fact, more and more companies are turning toward enterprise resource planning (ERP) to help them integrate activities, employees, and other business aspects into manageable business processes and increase productivity numbers.
It is more difficult to resolve productivity issues through process monitoring when you work with a client who is unwilling to invest in an ERP system. On the other hand, if multiple vendor and customer systems that don't integrate well with an ERP system are involved, it can be difficult to sell management on the need to move to such a system. Inability to collaborate with others outside an organization, after all, can be costly and potentially dangerous for an organization. Still, there are often ways to address productivity issues through process monitoring. Here are some ideas for you:
- Identify both manual and automated redundancies by overlaying the process steps on the architecture design.
- Determine where you can integrate previously autonomous business processes, leveraging investments wherever possible.
- Track the metrics that reflect both the operational and business performance of the process, and then use that information to create a design that optimizes those metrics.
- Create new processes to complement the newly integrated processes and reduce as much manual interaction as possible.
By proactively identifying bottlenecks or situations where exceptions might occur in a process, you can help optimize a process. The ultimate goal is to create a solution out of parts, really. Link, create, and modify the parts wherever necessary to develop the business benefits that process productivity can bring.
A tight connection between IT and business processes can go a long way toward improving performance and return on investment for an organization. When you focus technology on business processes rather than infrastructure, it can make a huge impact on how a business transforms itself for the current business environment. Finding a balance between agility, efficiency, and control is not easy, but it can be done. Just look to the processes first.
Learn
-
From IBM Redbooks®: Read "Improving business
performance insight with business intelligence and business process management" to learn about techniques, architectures, and processes used to define and implement a proactive business environment.
-
Check out "Ground rules for managing business process integration projects" (developerWorks, July 2005) to learn techniques for managing complex business process integration projects.
-
Review "Developing business processes that use IBM WebSphere Portal and WebSphere Process Server" (developerWorks, July 2006) to learn the basics of building a business process using IBM WebSphere Portal.
-
Read "Exploring business
process management systems and the impact of BPM on developers" (developerWorks,
August 2006) to learn how business process management (BPM) systems are changing
the development process and the roles of the architect and developer.
-
Stay current with developerWorks technical events and webcasts.
-
View IBM
on demand demos to find out more about IBM middleware and technologies.
Get products and technologies
-
Download IBM
product evaluation versions and get your hands on application development tools
and middleware products from DB2®, Lotus®, Rational®, Tivoli®,
and WebSphere®.
Discuss
- Participate in the discussion forum.
-
Check out developerWorks blogs
and get involved in the developerWorks
community.
S. E. Slack is a Studio B writer and author with more than 16 years of experience in business writing. She has also been an executive and business transformation communications consultant to IBM, Lenovo International, and State Farm Insurance Company. She is currently writing CNET Do-It-Yourself Digital Home Office Projects: 24 Cool Things You Didn't Know You Could Do (McGraw-Hill) and is the author of five other books.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
