Beth Gold-Bernstein: Welcome, everyone to the ebizQ BPM in Action Virtual Conference. I'm Beth Gold-Bernstein, chair of the conference. Now, it's my great pleasure to introduce today's keynote speaker, Ken Vollmer, principal analyst in Forrester Application, Development and Infrastructure Research Group. Today, Ken is going to be talking about the lessons learned in real world BPM. We would like to thank Global 360 for sponsoring this keynote presentation. Also with us today is Steve McDonald, director of product marketing for Global 360. Please be sure to visit the Global 360 booth after the presentation.

And now, I'd like to turn the program over to Ken. Welcome, Ken!

Ken Vollmer: Welcome, everyone. My name is Ken Vollmer and I'm with Forrester Research and I cover business process management and several other integration technologies. Today, it is my pleasure to be able to talk with you about business process management. What have we learned in the last couple years' worth of implementations? So we'll be walking through those with you today.

We're going to look first at critical success factors. And then we'll look at some BPM best practices. And finally, I want to finish with some basic BPM issues and trends that will be important to you going forward.

Today's businesses are facing massive rates of change, which are causing a tremendous amount of problems inside of organizations. You have the changing nature of business itself due to factors of globalization, outsourcing, faster cycle times, shared services, compliance and governance. You have a changing workforce Š primarily in the area of aging workers and knowledge leaving when they leave, skill shortages, next-generation workers, telecommuting and job sharing.

We also have changes in technology itself with such things as Web 2.0, service-oriented architecture, business process management, information as a service, dynamic applications, the information workplace, open source issues, mobility and unified communications. And then finally -- if that weren't enough -- we have another category of geopolitical and economic issues that are also being thrown into the mix -- such issues as immigration, democratization from social networking, shifts in the center of power, the devolution and evolution of governments. All of these are coming together at the same time to force businesses with very complex environments, where they need to be able to support rapid change in their business functionality.

The key point I want to drive home today is that service-oriented architecture and business process management are converging to provide organizations with the tools that will enable them to respond more effectively and more quickly to these changing environments.

Let's take a look now at some BPM critical success factors. The first one is processes themselves. And these are a series of questions that are not really the end answers but they are things that you should consider as you're beginning your efforts in the area of BPM. Are the processes you've targeted for improvement linked to the organization's overall strategy? In many ways, it doesn't make sense to work on BPM efforts that aren't directly linked to the core strategy and the reasons will become obvious as we go through this.

Will they significantly enhance the ability to achieve the targeted goals of the organization? And will anybody notice, or care, if the process improvement effort that you're working on is successful? BPM efforts should be targeted to core business processes that the company or organization is involved with if they are going to have a meaningful impact. It does not make sense that the limited-skilled resources working on improvement efforts, that can't provide the minimum bang for the buck. It's also easier to obtain funding for BPM projects if they have the potential for improving core business processes.

The next critical success factor is people-oriented. Are the right people involved with the BPM effort? Are all of the key areas represented? And here we're talking about with cross-functional business processes. Are all of the individual departments or domains within the organization involved that need to be involved? And the final question in this area is: are the right skills, including project management, on the project team?

This is especially important for core business processes that span multiple departments, divisions or even companies. Having process experts in each of these impacted areas assigned to the project team will ensure that those with the most experience will be able to provide input early in the improvement efforts. And these people can also be very helpful in evangelizing the change, and the process changes required, once the effort goes in.

The next factor is culture. And this is more significant than many organization perceive it at the beginning. Such issues as has the organizational culture been considered? Is the predominant mode one of openness and willingness to try new things or is it closed and somewhat resistant to change? This is important. If the system or the organization does have a very closed structure, it makes breaking down those functional silos and cross-functional business processes very difficult.

An example of the type of support that you need in that case is what Jack Welch did when he was at General Electric. He individually spearheaded the digitalization of GE as a major product. They had to improve their processes. He understood that the resistance and the functional silos with the multiple levels of management that was there would be a significant barrier to improving the processes unless everybody understood this was supported very strongly from the top. And he made sure that that happened by conducting weekly meetings with his senior VPs where they had to report to him on the process they were making with the digitization in GE. This level of senior level management support would not be required in all cases but it is very important in those cases where the organization has already demonstrated significant resistance to change.

Another critical success factor is project management. Process management efforts can be some of the most complex efforts undertaken by organizations and should have the best available project management expertise assigned to the team. In the real world, we understand that that can't always happen, but you should be aware that this is very critical in any case. Having a project manager with a combination of skills, business acumen, human relation skills, technology expertise and project control are crucial to business improvement efforts.

The final critical success factor is the technology piece. And while technology should not be the primary focus of these types of efforts, it is extremely important. The project team must ensure that the right technology is in case, or the project will be much more difficult. It can be summed up in the following sentence: Technology cannot guarantee success, but the wrong technology can guarantee failure. So this is a key step that needs to be addressed as organizations move through the business process management effort.

Now here's an example of what we're talking about. BPM suites can address the entire process lifecycle. These are what we would call a complete or a robust solution for supporting process improvements. And then the process definition phase, it includes such things as standards, base, graphical modeling tools, process simulation capability and the ability to bring business rules into the definition of the process as well.

The graphical notations that are developed in this phase can be passed to the next phase where they actually result in generated code, which reduces the amount of manual coding required in these efforts quite significantly in the excess of 50 percent. The code that has been created in this manner is the code that gets executed. It is also the code that gets monitored in the monitoring phase through business activity monitoring and end-user dashboards. And it is the same code that is used to optimize as the process is running through the adjustment of business rules. Dynamic adjustment, if you will.

So for the first time, we have these complete suites that address each phase of the process lifecycle and they're basically a closed loop that makes the implementation of these processes much more effective. And this is the type of technology that we're talking about that is critical for BPM efforts.

I'd like to take some time now to discuss some BPM best practices that we have come up with as we've talked to a number of organizations who have implemented their BPM technology. You need to consider a business process management suite when you need to support cross-functional business processes. We'll talk a little bit more about that in a second. Another use case would be when you need to automate or monitor processes across the value chain. These are very good tools for eliminating manual steps and speeding up processes. You need to consider a BPM when your processes change frequently because the technology that's used here supports rapid change and processes in a very productive way.

Business process management suites can also improve accuracy and reduce inconsistency in manual work activities. They're also very good for extending the life of legacy applications. So instead of ripping out an old system, you can use business process management tools to wrap a legacy application, and pull pieces of information out of it to extend the life of the application significantly beyond what you might have thought.

Business process management suites are also good for allowing business users to monitor status, and also to capture process knowledge. So business process management suites involve higher levels of collaboration with the business community in both the process definition phase, where tools are provided to give the business analyst or business user more direct input to the definition of the process and also in the monitoring of the process as it executes in real time. So these are significant enhancements for the business user community.

This is an example of a cross-functional process that we mentioned a minute ago. And there are -- in this case -- six individual departmental silos where process could be impacted. The order to cash process for example would touch all six. The customer relationship management, sales and marketing, production planning, manufacturing, inventory and logistics, and finally, finance and HR. Processes in the past have traditionally been attacked within the departmental functions, but that's only a piecemeal approach to the real problem.

Approaching these from a complete cross-functional business process has generated much more significant results. And they are more complicated to work on, but today's BPM tools do support cross-functional process improvements.

We need to choose the first business process carefully. Start with a major process that is causing pain in the organization. Picking low-hanging fruit that, if you are successful in making the process change, and yet it doesn't provide any meaningful payback to the organization, might not be your best approach and probably will not be your best approach, because you have not really significantly improved the department's operation.

If you start with a major process that is causing pain, granted it might be more difficult. But resistance to the effort would tend to go away because you would be more likely to get senior management support to successfully address that major problem. You would get more support in completing of the effort and it would also be easier to obtain project funding if you can show that you will fix a major system problems.

Characteristics of processes that cause pain are those that have multiple steps and multiple hand-offs, maybe a high level of manual processing. High volume activity and typically, they would have some impact on the customer via the far end. So those are the types of projects you want to work for, or look for, to address.

Now we look at this in another perspective here. In this chart that you have on the left-hand side, the impact of the process, going from low to high on the left-hand side, and across the bottom, you have complexity from low to high, going from left to right.

So what we're recommending is with your initial efforts, stay in the upper left-hand corner, where you have high process impact with low business complexity. That is the ultimate place to get started and help to ensure a level of success for your efforts. Eventually, you would want to move towards the upper right-hand box, where the high reward but higher risk, but get some experience under your belt first with the high-reward, low-complexity projects before you take on the bigger ones.

We realize that this is not always possible, but in general, if you could follow this step, it would make your life a lot easier. You need to be pragmatic when you're looking for your projects to work out. Look for quick hits. You do want to avoid the big band and analysis-paralysis phase. You don't want to take on a project that's too big. You need to look for some sort of incremental deliverables. You don't want to get hung up with looking at such things as modeling all of your processes before you start improving any, because the value is not coming back into the organization.

And if you take the approach of modeling the whole process before you fix any, the information will be out-of-date before you can actually use it. So if you use an incremental approach, integrate both the process modeling and execution implementations, and we found that it takes about four iterations to get an implementation correct, and these would be four short-term iterations, so maybe having a couple of week period in between. And we also found it takes about seven iterations to wring out all the process inefficiencies -- that might be a little high, but that would be the worst case scenario.

So they're iterative, and they're easy to do. It's like a rapid integration or a rapid application development effort and intended to be more successful. You need to focus on the return on investment. If you can, link the projects to line of business activity instead of infrastructure, and this will have a much more significant impact on the senior management team when they're looking at your request for funding.

Another issue is don't burden the first project with the infrastructure costs. So if it's an effort that will provide reusable results in many cases, you need to avoid assigning all of the capital infrastructure costs to the first project. Because that will have a tendency to make it somewhat difficult to get approved. So you need to ensure that your management team understands that this is only the first project and this will be reusable technology and it should not be, all the costs should not be put to the first effort.

Make sure you measure the before results. This is critical. Many times companies are very good at showing after they made some change, "well, here's what we can do today," but they really don't have the foundation for how bad it was before. So you need to try and capture that before you go too far down the line. This will make it easier to justify ongoing investments in future projects. And assess and upgrade the underlying infrastructure before you try and get started. This deals directly with making sure you have the right technology in place.

You need to build a strong project team. Combining IT and business teams into a cross-functional project team is a proven critical success factor. You need to look for business analysts with strong skills of requirements and analysis and a good technical background. You need to develop a true partnership with a vendor and we recommend that you implement a competency center where you have experts on the technology available to assist the project teams.

Now this is not as critical with the first effort as it would be down the road when you're working on many several efforts at the same time. You need a core of people with good expertise and the tools that you're using and they would be in the competency center and farmed out to the individual project teams as needed. And using the integrator to supplement your skills but to choose the integrator carefully.

You don't want an integrator coming in who will take on everything and not transfer any knowledge to your own team because that will create a dependency on the integrator going forward. You need to make sure that your own staff gets trained as you go along so that you can gradually become more independent in your efforts to address process improvements in the future. And select the vendor carefully. This deals with the technology primarily. Start with the business need, not a preordained list of vendors. And this is very important. A lot of time different entities making the decision will come to the table with a short list of vendors already in their head and without considering, #1 that they might not have the most up-to-date information and they might be missing a lot of important criteria, it should be used to select the vendors. So we recommend that you use a methodology, like the Forrester Waves for example to guide vendor selection.

These are comprehensive lists of criteria that can be used to select a vendor in several different areas of technology, including BPM. Lean towards a more comprehensive solution, even if you don't plan on implementing all of the features at the beginning. Having a vendor that can provide a comprehensive list will help as you go forward, as the other components will be integrated more easily with what you already have in place. And make sure that you conduct a proof of concept on site to get a feel for each vendor's ability to serve your needs effectively.

Now the vendor landscape for BPM is very confusing, as this slide indicates. You've got vendors from several different categories that can provide BPM solutions. You got Pure-Play or what we now call human-centric BPM providers such as Savvion, Lombardi and Ultimus. These are very good with in-depth human interactions that are sometimes required and might not have any interaction at all with underlying application systems inside the organization. They may or may not.

Another category would be application integration vendors like TIBCO, webMethods and Vitria, who are very strong in the system to system, but also provide significant functionality in interacting with human beings and different situations. So, again, which would be the best case? It would depend on a whole range of criteria that you should go through to come to the right answer. And to make matters even more complicated, there are many categories of vendors beneath these two that are also providing BPM functionality such as enterprise application vendors like SAP, Oracle, PeopleSoft and Siebel, traditional B2B vendors including Sterling Commerce, Innovus and GXS. Platform vendors: IBM, BEA, Microsoft, Sybase and Sun, as well as Enterprise content management vendors like EMC, Open Text and IBM.

There are probably, without exaggeration, at least 200 vendors available that could provide BPM functionality of one type or another that could be applicable to your needs. So you need to do a good job of preparing an RFP to support your vendor selection process. And again using a strong methodology is certainly a recommended tactic for that.

When selecting a vendor, the flexibility features matter the most. For example, does the vendor support model-driven design capability -- do they support process discovery? Do they have a repository for storing a lot of the features that will be captured as you go through the process such as process model information, semantic data links and things of that nature? Can it support effective change management? Can it handle long-running processes? And is it based on a standards-based architecture, which will limit your liability of being able to move to other solutions in the future.

Another recommendation is to design for real world processes. You need to recognize that managers do not know how the processes really work and the documentation that exists is usually out of date. So, in effect, when you start the design phase, you should not take something that has been sitting on a shelf for a couple of years, because you'll find that that will not be anything close to being accurate to what you really have going on. You need to focus on process discovery, or what's really going on at the moment. You don't want to get too much granularity in the early steps because you could quickly get bogged down so try and maintain a high-level perspective in the initial effort, and then dive deeper as you need to.

Using business process modeling tools for designing complex processes, which is relatively easy these days, because most of the BPM tools have these modeling tools built right into their environment or they integrate directly with the leading business process modeling tool vendors. And you need to develop reusable subprocess such as open account, transfer funds. These will be business services that you will use over and over again in the future and they will be stored in that repository that we talked about earlier.

I'd like to talk for a minute about some basic BPM concepts that would increase the level of understanding here. BPS tools are scheduled to grow at more than 20 percent a year and will continue to do so for at least the next five years. And we believe at this point this is a very conservative estimate. I have another chart that shows this graphically. And this shows that in 2005 to 2009, it's been projected to be a 20 percent plus growth rate, evenly split between integration- centric and human-centric BPM providers. And we'll talk about that difference a little bit more in a second, but the overall thing is strong growth in both categories at a minimal of 20 percent per year.

Now, that indicates that there is a high level of interest in this technology in the business community. And that has been verified by surveys we have taken. Business process management is a very hot subject now especially on the business side.

So here's where we talk about the two major different types of BPM. Integration-centric BPM solutions evolve from the enterprise application integration space. And over the years, they built up additional functionality in the area of business process integration and today, represent a major part of the category of business process management suites that are available.

The other major group came from the document imaging and workflow space, also moving up into the process management area, resulting in two major categories of BPM tools at this point in time. Integration-centric BPM and human-centric BPM. And again, we have had some convergence between these two but we believe that there will still be significant reasons to keep these separate categories for some time because, for example, human-centric BPM providers to have capabilities for providing very strong in-depth support for human-to-human interactions and at the same time, the integration-centric areas are very strong in providing a SOA foundation in system-to-system interactions in an SOA environment.

There are several drivers for business process management suite and I'd just like to review them quickly. From the business perspective, business process management suites provide operational efficiency and effectiveness that results in improved productivity. They also support compliance mandates like Sarbanes-Oxley, Basel II, and in the United States, HIPAA. They reduce cycle times which results in less work in process inventory, especially in manufacturing situations. They improve customer service. The customer tends to be primary beneficiary of almost all BPM efforts. They support new product development by improved collaboration between planning, engineering and manufacturing and they focus on process ownerships. This is important because it's breaking away from the functional silo approach to a cross-functional business process approach to improvements.

There are also several drivers from the IT perspective. Business process management suites lower IT maintenance, cost and time primarily through less coding. By using the model-driven approach that generates a lot of code and the reuse of components that it supports as well through SOA, you end up with significant enhancements in your application development. It actually supports rapid application development, which enables quicker response to new business requirements.

Composite applications or dynamic applications created in the BPM environment have been shown to result in savings of 60 percent or more when compared to traditional application development approaches. It supports business and IT agility through higher levels of collaboration that are supported between the end user and the IT department. Business process management suites also support the new model-driven development paradigm that we discussed above and they also support service-oriented architecture.

In fact, integration-centric business process management tools have SOA baked in. And it's a core part of the technology. Human-centric BPM vendors would normally require to work in conjunction with an Enterprise application, integration vendor or possibly an ESB to get that same level of functionality. This is just a slide that talks about the evolution of business process management technology and again, primarily this would be integration-centric business process management technology. It started out ten to fifteen years ago with basic application integration technology, such things as data transformation and routing capability, then triggering capability, process automation and adaptors.

In the last five years, that capability moved to the right and was combined with things like embedded EDI, trading partner management, B2B conductivity and vertical industry templates. Today, all of those capabilities shown on the left-hand side have all come to the right and included with the other features shown under the BPM suites, such as workflow, sophisticated process modeling, business activity monitoring, business rules, lifecycle management, ESB features, portals and simulation. Along with two of the newer features of business-event management and complex event processing, which are event-based tools used to optimize business processes.

So today's BPM suites can include all of these functions and are very complex comprehensive solutions that are all included in the service-oriented architecture framework. And here I just want to talk a little bit about the dual nature of these suites, represented by the blue square rectangle in the middle with the multiple individual capabilities. And this is just a partial listing of the things that were on the previous page. The key point is that all of these features are now wrapped in a service-oriented architecture framework and while they were originally designed for supporting integration and process improvement efforts, we're finding today that they also represent a new development paradigm as I've already alluded to.

Now you can implement business process management without SOA, but there's really no reason to do that. Implementations of BPM and SOA together -- I'm sorry, implementations without SOA foundations being available do take longer and they also result in maintenance and support calls being higher than they would have been otherwise, resulting in a return delayed ROI. So we believe that an SOA foundation provides a standard-based approach for implementing BPM and since the, several of the BPM tools provide the BPM, or the SOA capability baked in, it makes perfectly good sense to use that approach in most cases.

So! I'd like to finish now with some high level recommendations and then we'll be available for a brief period of Q&A. When you're picking a BPMS solution, obtain one that has good SOA support. That means that it either has to have a core EAI server that supports SOA at its foundation or at its core, or the tool can support the creation and consumption of Web services without the EAI server being present. So then it would just interface with another product that had that capability.

But at a minimum, the BPM solution must be able to create and consume Web services related to process improvements. You need to also start capturing business meta data in repositories. Such things as process models, security policies, interfaces with other applications, semantic data links are all great things that makes good sense to store in a process or an SOA registry repository to support reuse and rapid change.

You need to evaluate the potential of the BPMS tools to support model-driven application development. We believe that this will become more of the major ways that organizations develop applications in the future. It's not going to totally replace the traditional methods. But it will certainly become one of the key alternatives that results in faster time delivery for new application functionality. And along those lines, you need to prepare your organization for the coming IT paradigm shift.

As the model-driven application development paradigm becomes more common, that will mean that there will be less need for people, actually, programming and Java, C++, Visual Basic or Cobol or anything else. And you will have more a need for people who understand the business and are able to translate that into an effective process model. This will be a huge change for many IT organizations that have had a heavy dependence on manual coding in the past.

So with that now, we'd like to turn it back to the moderator for Q&A.

BGB: Thank you, Ken! And now I'd like to introduce Steve McDonald of Global 360. Please stay tuned for the live Q&A, which will begin in a few moments. Welcome, Steve.

Steve McDonald: Thank you, Beth. And thank you, Ken. Thanks to everyone for joining today. Global 360 focuses on business optimization. For those of you not familiar with our company, we are one of the world's leading BPM vendors. Our focus is on complex process issues and we accompany our software with world-class customer care. We have nearly 2000 customers with over 5000 applications. Those are running in 134 countries represented in ten languages. We're vastly stable and growing as a company with more than 420 employees, 57 patents and 50 key business partners. Our headquarters are in Dallas, Texas as well as around the world.

Achieving business optimization involves the ability to automate and optimize the whole business process. BPMS software alone provides vital infrastructure for that automation but most large business processes are supported and powered by other existing technologies as well in addition to BPMS. To that end, Global 360 provides industry-leading BPMS as well as process intelligence technology. Automation is powered through Global 360's BPM infrastructure layer. This is our standard based next-generation technology for accelerating process, reducing costs, improving operations, etc.

It is the engine that powers the processes and integrates with other systems in your Enterprise in order to support end-to-end process execution. Process intelligence is a separate, yet fully integrated layer that provides detailed process, analytics based on metrics and data gathered not only from the Global 360 process engines but from any process powering technology as well.

Process intelligence can be thought of as a very specialized business intelligence that can understand and analyzed process activities, event data, participant utilization and so on. Global 360's process intelligence suite is based on this and provides historical real time as well as predictive intelligence. As companies mature in their use of process technology, many are finding that process intelligence is often a more important next step in automation.

As you might have experienced yourselves, it is difficult to manage, let alone optimize processes we cannot see. Companies are using our end-to-end process analytics as a way to see exactly where the opportunities for process improvement are. Global 360's simulation module allows organizations to model and test-drive process improvements in order to accurately predict the scope, cost and benefits of process change before implementing new process infrastructure.

Thus, consider a life cycle that is designed to provide continuous process optimization. This slide represents a summary of the complete process value chain that Global 360 provides. Global 360 powers IT and business communities to work together to design, execute, monitor in real time, and adapt also in real time processes. This is continuous improvement.

Additionally, process intelligence supports the analysis of detailed and concept process event data to understand how and what to re-engineer and then can model and simulate those improvements, which can subsequently be implemented into the run time design of the process automation layer. Even more than improvement, this is continuous optimization.

If you have thoughts on business optimization, BPM in action, please feel free to stop by our booth or contact us at the address provided. It's been our pleasure to sponsor the work of Ken Vollmer and ebizQ. Thank you all for attending today's presentation.

BGB: And thank you, Steve! I'd like to remind everyone now it's time for your questions and you could submit your questions by pressing the "Ask a Question" button. And we have a question for you. Which would you consider to be more important as a next step for your organization's use of process technology? Is it implementing a BPMS solution in order to have a standardized process? Or getting detailed analytics about the performance of your existing processes? Please take a moment to answer this poll while we go to your first question.

Ken, to begin, can you please explain more about the competency center?

KV: Yes. Competency center is a concept that we have working with over the past several years. It can come in different flavors depending upon the issue that's being pursued. I think probably some of the earliest competency centers revolved around other subject areas such as general integration. But when we're talking about BPM competency center, we're talking about a collection of experts or personnel who are very much tuned into the inner workings of the product that you're using to do the BPM with. And they could be considered in larger organizations more of a corporate resource that could be available to be farmed out to individual BPM projects within different divisions or geographic locations. So it just makes more sense to have a centralized, small, centralized group of experts that can serve the entire organization and not have the expertise scattered throughout the organization in a less productive way.

BGB: Okay. Can you give some characteristics or warning signs of a non-mature or an incomplete BPMS offering?

KV: Well, I'm not sure that that's looking at it the right way. I would say that the better way to go at this is for the organization to determine what they need to meet their BPM requirements. And then once you have those needs identified, then you evaluate the various vendors involved to provide you with a list that can, you know, do what you're trying to do.

Looking at it the other way, I mean, there's always features that a particular vendor won't have. Is that a warning sign? Not necessarily. If it's not something that the organization doesn't need, that's some irrelevant.

BGB: Okay. Now would you say the current state of the art BPMS systems are scalable to support tens of thousands of users over to the Web, over the Web, or is this generally an in-house solution?

KV: Well, they can be both. What you have to do is make sure that you do, when you're selecting the vendor, of course, you want to make that one of your criteria upfront is that the solution has high throughput. Generally speaking, human-centric BPM tools are specifically designed for less high-volume situations but there's no technical reason that they couldn't be scaled up. Integration-centric BPM solutions on the other hand, would have more scalability built in due to the nature of where they came from in the integration space. But I think it's something that, #1 something you need to evaluate early on in your vendor selection process. And there's no inherent reason that I'm aware of that would say that either category could not provide the scalability you're talking about.

SM: This is Steve and I would add to that. I agree with Ken. And from a vendor's perspective, we've tested our solution actually in production supporting a client who has over 230,000 user transactions per hour. So, that's on the high side, of course, of again the amount you're doing, but 10,000 users from a vendor's standpoint should be fairly typical.

BGB: Okay.

SM: Or supportable.

BGB: Now, they're still, still asking about product features. What features do you consider to be important if you're going to call it a mature product? What are the key features to look for, Ken?

KV: Well, okay. One of the slides that we talked about earlier had a listing of the features -- probably can't back up to it, but -- for reference --

BGB: Well, you can --

KV: -- Oh, we can? Okay. I'm sorry, it's not in this deck. I'm thinking -- yes, we do! Slide 32. For a mature BPM product, again, this -- we have to give a caveat here -- a mature human-centric BPM product will have very strong features supporting human interactions. A mature integration-centric BPM product will have an integration server at its core and also imbedded workforce process modeling, business activity monitoring. And I think one common element or a couple of common elements that span all types of business process management tools. #1, you have to have modeling capability. If you can't model the process, then you're pretty much dead in the water. You then need some ability to generate code. You need the ability to monitor the code as it gets executed and give the business users dashboards for visibility. And you need to be able to optimize the process through manipulation of business rules or other things of that type.

So those are some of the key things that are absolutely core, bedrock features of a BPM solution. Beyond that, it's open to a lot of interpretation and depending upon the specific requirements.

BGB: I just want to share with our audience, the results of the polls. It's about half and half, a little more that they are looking for the infrastructure, a little less than they're looking for analytics and about the existing processes, but it's almost a half and half split there. So that's kind of interesting. And we have many more questions than we could answer during that time, so we'll have to take some of your questions off the air. We just have time for one or two more.

Ken, could you tell us what some active standards in the BPMS space that our listeners should be aware of or should pay attention to when they're looking at tools.

KV: Sure. I would say some of the key standards that they should be looking at, that would be business process management notation to assist the power users or business analysts with their graphical modeling needs. Business process execution language and XPDL are the two that actually result in the code that gets executed. So those three are the big ones. BPMM, BPEL, and XPDL.

BGB: Okay. And lastly, again, I apologize we can't possibly get to all of your questions and there are many more on the tool, so I would like to say tomorrow's keynote presentation will also be about tools. Log on at 11 o'clock tomorrow. Janelle Hill is going to be talking a lot about technologies. We'll have a lot more time in the panel discussion later today to take more questions. So I apologize if we don't get to your question. So, one last thing, to sort of sum up a lot of the questions around here. You did talk about model-driven development and there are a number of questions about it. Ken, you talk about a process modeler system, what are the key components that you're looking for to assist in a model-driven development effort?

KV: Well, the key feature is you need to be able to translate whatever is being graphically noted into executable code. That's where the standards some into play that we just mentioned. In the past, there's been a lot of activity in the modeling area done with Visio tools that, in most cases, without some third party intervention, that information could not be automatically transferred into the system and translated into code. It required interpretation by a developer as to what the meaning of the graphics were and whoever developed the picture, and try to interpret that into something that would work.

So, we're coming a long way beyond that with the BPMM notation and its ability to allow people to graphically notate things that can be easily imported into BPEL or XPDL servers where the code is then executed. So, that's the big thing, the ability to transfer that knowledge graphically and have it mean something is a new capability. And it's really what makes a model-driven development in the BPM space possible.

BGB: Excellent. And I apologize to everyone whose question we did not get to but we are out of time now. I would like to invite all the attendees to visit the show floor and the booths and look at the Global 360 booth. I would like to thank Global 360 again for sponsoring this Webinar today. Ken, thank you very much.

KV: You're welcome.

BGB: And I would like to thank all of our attendees. Please stay turned. We have a good line-up today. Coming up next, you can hear a case study on how Johnson & Johnson used BAM as a starting point for optimizing their business processes. That's a very interesting case study. And then, the last presentation today at 1 o'clock, Sandy Kemsley is doing a bare-naked panel presentation as only she can do it! So tune in for that. Hope to see you all again soon, and thank you.