Beth Gold-Bernstein: Welcome everyone to the BPM and the Bottom Line Virtual Conference.  I’m Beth Gold-Bernstein, Chair of the conference.  We’ve had a great lineup of sessions for you today.  If you missed any of them, or would like to recommend them to a colleague, all of the sessions will be available for archive viewing.  

This conference also includes virtual booths where you can chat with company representatives and download information.  Be sure to visit all the booths for an opportunity to win a new iPhone 3G.  Now, all registrants will receive a copy of BPM for Dummies.  You can click on the files buttons to download your copy now.  This session is a live panel discussion.  You can submit your questions by clicking on the “Ask a Question” button.  

Now, I’d like to introduce our esteemed panel.  We have Mike Lees, Senior Director of BPMS for Software AG. And Software AG is a platinum sponsor for this event and we would like to thank them for helping making this program possible for all of you. Dale , Chairman and CTO of Vitria. Now Dale is the father of distributed pub-sub messaging and one of the true visionaries in this industry.  

One of the first companies to approach the integration market through Business Process Management and Analysis and we’re very happy to have Dale here with us today. We have Derek Miers, a BPM expert and independent industry analyst. Now, Derek wears many hats. At BPM Focus, he provides BPM training and consulting to organization around the world and is co-chairman of the BPMI organization.  

He helped merge the organization with the OMG and he sits on the BPM Steering Committee of the OMG. And last but certainly not least, we have Michael Dortch of the Aberdeen Group and he’s an analyst, and information entrepreneur, and writer for the past 30 years. And Michael is also an ebizQ blogger and we’re happy to him here today.  

You will notice we have two Michaels. Last BPM Conference we had all Phil's and now this year it's Michaels. So for clarity, when we say Mike, we're going to be speaking with Mike Lees and Michael Dortch is definitely Michael. So Mike Lees, I'd like to start the questioning off with you. We recently spoke a BPM study put out by BP Trends, which Derek Miers also contributed to I understand.  

And one of the things you pointed out to me was the number of C-Level executives who responded to this survey. What do you think that means in terms of how BPM is being used in the enterprise?

Michael Lees:    Yeah, so that's a survey that we put out jointly with BP Trends. It actually had a number of different data points in it that talked to what I considered to be the BPM industry in general getting a lot more strategic and moving a part of what may have been more tactical and departmental BPM in the past to more strategic enterprise wide BPM moving forward.

And it's a trend that we saw in our survey and it's a trend that we see elsewhere and certainly in our day-to-day business. So in that survey, about 30% of the respondents were either C-Level or senior business managers. But more interestingly, about 50% of the respondents said that they had a major strategic commitment by their executive management team to BPM or were involved in multiple high-level process projects.  

And that's certainly the highest number in any of the surveys that I've seen that explicitly talk about BPM being that strategic within the organization. Now, interestingly enough, they also as well have a high level of respondents saying they were doing BPM to reduce cost it was about 56%, I think. There were also a pretty high number of people who responded saying that they were doing it to increase management coordination, an organization responsiveness; that was about 51%.  

And also, a high number who were using to improve their products, create new ones, or rapidly enter new lines of business to stay competitive. So all of those things speak to me in terms of the BPM industry maturing somewhat in terms of the goals and the penetration into the strategic side of the business that BPM is having.

I think there's a couple of reasons why that's happened. I think a lot of companies have been successful with BPM tactically. They have been doing BPM for three or four years and got a lot of experience with lower-level projects. And as soon as you start having multiple of those projects, it starts getting the attention of the Board and the C-Suite. I think the other reason is just the role that BPM and SOA are increasingly perceived to have in the sort of move to change the IT operating model that we hear so much from CIO surveys and CIO conferences. The fact that increasingly CIOs are looking to have a conversation with the business not just based on cost and how they can strip cost out of their function but also how they can contribute to and even lead innovation and strategy within the business.

And increasingly I'm hearing BPM and SOA combined being talked of as a way of getting IT out of this mire of purely being sort of driving out cost in the infrastructure of sort of reducing the amount of money they spend on lights on. And only when you're able to attribute IT projects to real business value and only when you're able to empower business users to take on some of the roles and the burden that IT has been suffering over last 20, 30 years can you really sort of see a way out of that mire. I think that's why BPM increasingly is becoming much more strategic and that's what showed up in that survey and others.

BGB: Okay. Now Dale, while many organizations are citing business agility as a driving factor for implementing BPM, can you tell us how BPM can actually deliver agility and do you see companies currently actually achieving agility with BPM?

Dale Skeen:    Business agility is a great example of using BPM strategically. And yes, we do see companies achieving agility with BPM. For example, we've seen some of our customers who've put order processes into play, be able to change processes, move that change or process timelines down from two months to two weeks so that's an example of business agility empowered by BPM.

Now to achieve this first and foremost, BPM tools are model-driven. And this is probably the defining hallmark of BPM. You can graphically model the business process and then instead of coding that model, you can put that graphical model too directly into execution. That gives you faster time to deployment, critical to agility, and also faster time to change.

The way we really use that though and leverage this is that BPM suites have been maturing to allow business analysts to really do the modeling themselves. So we're starting to see now that in addition to graphical modeling capabilities that we see specific capabilities for business analysts to work with these models and get closer to these models so that, again, reduces your time to production.

Also, we see that these -- as we see these tools maturing, we see the collaboration between business and IT explicitly supported by the tools increasing. And again, that's a critical success factor to any project -- any IT project especially when you start talking about BPM modeling. And then finally, we see that now as the suites mature, they're able to provide the capability to monitor and visualize what's going through these business process.

BGB: Now I do have a question from the audience. Are there any indicators or metrics that suggest any movement of usually siloed interactions among IT and the business toward collaboration?  Are you seeing organizations measure this?

DS: I don't think I've seen organizations explicitly measure this but I think that you're seeing this in the results of what's going on in the organizations. Because again we're seeing now business process projects that cross multiple departments, the time to deployment being reduced from what using traditional tools and methods -- waterfall methods probably being 18 months to two years to being reduced to three to six months.

And that thing's facilitated by, of course, the BPM tools themselves, the support of the collaboration between business IT and explicit tools that support that collaboration. So I don't know the study yet, perhaps one of my other panel members does, but again, I think there are a lot of tangible points -- proof points out there in the customer case studies.

Michael Lees: This is Mike. I think -- no study but a couple of Dale's points just from our experience. A couple of things we're seeing that talk to -- that the blowing of the band will increase collaboration. We're certainly seeing a lot of interesting governance at the moment. And I think that's a sign that as you start to shift some of the control, and of the, certainly, around change management, some of the responsibilities out towards other roles within the business, I think, that's indicative of why people are looking at governance methodologies and tools to help manage that.

And I think the other indication that we're seeing the change in some of the roles and job definitions of people that are involved in BPM projects. We're seeing more job descriptions for business analysts that are more akin to what I would call a process architect or process engineer. So I think some of those changed in roles and responsibilities and some of the need for IT to start looking at governance, mechanisms, talks to the fact that this is actually happening.

BGB: Okay. Now Derek, as Mike and Dale are talking about improving business efficiency, we probably need to bring up other methodologies in the organization that do that including Six Sigma and Lean. What is the relationship between these efforts and BPM?  Are they totally different initiatives and should they be?

Derek Miers: Well in the end, BPM, Six Sigma, they're all focused around process. And we go back and start looking at BPR, and Total Quality, and everything else. I mean the reality is that most companies are doing all of these things. They're doing a bit of Lean, somewhere they're probably doing a bit of Six Sigma somewhere. They're doing a bit of workflow, business rules, Service Oriented Architecture, they're still running Total Quality Management and what have you.

And if you like, BPM is almost like the arrows that draw all this stuff together. It's the strategy of bringing it together. And I think the central part here is there are similarities certainly between BPM as I see and Six Sigma. If you say that BPM really is a management philosophy about organizing your business and about the people that are involved in and about the processes the way they coordinate themselves and the performance objectives of those, then BPM Six Sigma have a pretty strong relationship between them.

I mean but the -- I think it goes a bit deeper than that. There's I think a need for the folks that are involved in BPM initiatives to realize that this is as much about training and building capability and competency in the organization, and building an alignment or the behavior if you like around BPM. Just like Six Sigma was an attempt. Take GE as an example, where it was really mandated as a way  of doing things.

Ina sense, adding the technology component that comes with BPM as a way of saying, listen, we want to drive our processes using models, as Dale was pointing out, and really building processes as a mixture of both practices for knowledge workers. They're roughly repeatable processes that are out there and also the procedures of the transactional world.

But I think the key point perhaps you're getting at Beth, is that training is a central discipline. And it is a discipline in the sense of making sure that your people are starting to grow the capability, the competence to be able to handle that stuff.

BGB: All right.

DM: I mean clearly about building -- getting a bit of focus and driving a sort of long-term transformation rather a bit of saneness that you would get from just employing technology. And that requires training just like in Six Sigma.

BGB: Okay. Anyone else want to add to that on Six Sigma?  Okay. So Michael Dortch, I know that Aberdeen frequently surveys users on a variety of IT related topics. What does your current research identify as the top business drivers for BPM and other IT investments?

Michael Dortch: Well, as this conversation has been proceeding, Beth, I've been perceiving us as sort moving further up towards the mountaintops as we speak. The Zen Buddhist say there are many paths but only one mountain, right. And our surveys tell us we're not allowed to have any opinions that aren't backed by user surveys at Aberdeen.

And we recently surveyed some 4,600 people, business and IT decisions makers about what's driving them. And when we asked them, what are the top drivers behind your IT initiatives?  Four of the five of those top drivers were all about growth, organic growth, revenue growth, growth through mergers and acquisitions.

Only one of those top five drivers was cost reduction and I think it ranked number five out of five. And what that tells me is that these efforts around BPM and more granular efforts around Business Process Modeling and Six Sigma, they're all many paths up the same mountain. The business people want to grow the business, that's sort of hardwired into their DNA. And growth trumps cost and business growth trumps anything IT says it cares about.

And so what we find, for example, is that of 4,600 people we surveyed, 35% of them are already using BPM, another 32% of them are planning to adopt it. This says they see BPM however they define it as a path towards that growth they're trying to achieve. And when we interview users and talk with them about -- in detail about what they're trying to do, increasingly we hear business people perceiving some kind of disconnect between them and the IT departments.

But that disconnect may be more perceptual than real. In organizations, we classify as best in class, they're using -- they're trying to come up with what you might think of as elements of a common vocabulary or taxonomy to overcome that disconnect so you're seeing an increasing emphasis, not just on methodologies like Six Sigma, but on tools like service level agreements.

They're using these kinds of things to simultaneously marry and weed out the irrelevant differentiations between what the businesses says it wants and needs, which is growth and agility and all of that, and what IT thinks its job is, which no matter what IT says, what their job really is, is to enable those things.

And so instead of arguing over whether Business Process Management is, in fact, a set of disciplines and practices or a set of technologies wed to a Service Oriented Architecture. We're seeing the companies that we consider to be best in class are sidestepping those questions entirely, stepping back a bit, looking at what it is the business wants and needs to do, and then trying to come up with ways to translate those goals into things both business people and IT people can at least collaborate on effectively, if not agree upon totally.

BGB: Now, I'd like to go to some audience questions. I'd like to remind those who came in later, you can ask a question by pressing the “Ask a Question” button. Now Michael Dortch, I'd like to first ask you what -- you spoke about companies focusing on business needs. Now, how do they know looking at their business needs that they need to employ BPM?  Are there any events or indicators that points to the fact that this a BPM solution?

MD: Having been an analyst for 30 years I think I know this better than a lot of people. The analyst favorite answer to every question is well, that depends. So Beth, well, that depends. At a lot of companies, there is often a particular pain point or challenge that someone figures out that BPM in some way, shape, or form can help them to address.

At other companies, it's part of a larger strategic transformational initiative where they're trying to figure out opportunities to make the company, in general, run better or that sort of thing, or to increase agility as was discussed earlier, or some kind of driver like that. But one of the things we have found in our surveys and interviews with users is that at some point, someone takes a leadership role and decides we're going to do this thing.

Either we've invested in multiple BPM solutions and now it's time to integrate, or consolidate, or federate those in some way, or we've looked at a number pilot deployments, now it's time to pick a platform and move forward, or we've got this strategic agenda in place now it's time to get IT and the line of business people -- lead the line of business leaders around the table to figure out how best to go after these in a meaningful way.

But again, in some way, shape or form, there is usually some internal leadership in the company that decides BPM or some variant on BPM is now going to be a priority. And then often a next step that we see is companies will look around themselves to find where processes are already working. And if they find places where process management is already working, and they're already effective processes in place, they often look for way to adapt, replicate, and scale those.

And one of the interesting we're finding is that in a lot of organizations, in some arenas, some of the well defined, well enforced, and well supported processes and policies although they're not strictly speaking business processes exist in the IT department itself. And so we're finding that some organizations the IT teams are becoming ambassadors to the rest of the organization about how to bring rigor and consistency to the various processes those other elements of the company use.

DM But Michael it's also about people starting off really -- if you're talking about indicators that they need to do BPM, already you just go to start thinking about low maturity organizations where there are key personnel are the key ones that are there, there's lots of spreadsheets lying about to coordinate.

MD: Oh, yeah.

DM: They're reactive, they do things very manually, they're very internally focused, they're very static, they're uncoordinated isolated projects. And really in a sense, that's the sort of thing that they're starting to get into. The question is much about, I think, if you're talking about why BPM is a good idea, then it's really a question of what are the business objections that you're trying to get into.

I mean I found myself this week talking with people ---I've been running training courses here in London and BPMN last week and again, we come up with these. Time and time again, you find people that got 40 spreadsheets for 50 people involved in coordinating a process. And of course, I ran into something three or four weeks ago. One company owned up to having 1,400 access databases and only 900 people in the company.

MD: Um-hum. Yeah.

DM: And there's a pretty good indication that there's in a mess.

MD: I couldn't agree more.

DS: I would tend to agree with that. And I think that one we should we caution when looking at these indicators is not just to look strategically and wait for a vision from top down to say we need to look at business processes strategically and re-optimize them but instead to look at BPM more tactically. In fact, this is where companies probably get starting, get started fastest, they probably have the best initial results.

And as was pointed out, anytime you have an interaction that involve multiple people, or involves the multiple departments, or you have even a customer, or partner interaction, that's multistepped , if you want to improve those, BPM is probably the one of the technologies you should look toward improving them.

Once you've broken down your business functions into business services using an SOA architecture, the next step is usually to look at how you improve some of the services that you're delivering out to your customers -- coarse-grained services. Again, those are excellent candidates for getting started in BPM. That's services orchestration, that's one of, perhaps a simple straightforward application of BPM.

So I would caution the audience to not only look at BPM strategically, which is a good thing but also to get started to look at it more tactically because typically there will be these problems long running processes , multiple interactions, vibration between people, they can be good candidates to begin within.

ML: Dale, I definitely agree with that. Just to give a perspective from where we find, as a company where Software AG finds a lot of the early indicators coming from customers. Yeah, I would say a majority of our BPM projects are initiated by a couple of things. One, is where there's a perception of customer service issues. That's often where BPM projects for us come to the fork because customers are the ones that feel the pain on sort of wide space management and process management first. So if you finding that you got a lot of customer service issues and they're driving a lot of projects, then it's probably time to look at BPM. The other is where IT departments are getting a lot of interest from executive management on dashboarding, and realtime visibility, and transparency-type requirements.

And again, that's indicative of -- that management not really having visibility into the process. Its not as much about the information but it's about how that information is delivered through the process. So I would say look out for those sorts of dashboarding transparency requirements and look out for sort of gravitational pull towards customer service issues.

What processes will this -- will going after solution to this problem affect?  And how can we leverage the experience of solving this problem to inform and refine our incumbent processes?  I think that's ties directly to what was just said about executives wanting greater visibility into process. I think everyone who -- everyone in the value chain an almost every enterprise needs greater visibility into the processes that are in play.

And lots of times, people do things without giving any thought at all to the larger processes in place and whether or not their actions conform with those. And lots of times that alone represents an initial opportunity to sort of use BPM, either BPM technologies, or BPM as a set of concepts and practices to impose some additional rigor on things.

DM: I think that more than that too. You can -- we could talk about all this discussion in the context of the transactional stuff that happens in the back office and in the heart of the machine of the company but there's also a whole range of processes that are, I think, poorly addressed but have been poorly addressed in the past where there really aren't applications.

It's all about knowledge work and the stuff that really happens between people at the sort of edges of companies, the up and down the value chain where partners need to collaborate. The sort of things where they have evolving practices and sort of roughly repeatable processes rather than really tied down procedures.

And today, I think, BPM technology is very close -- well, very quickly coming on to being able to support that sort of thing, especially, this sort of behavior that you see of people starting to collaborate in the cloud and BPM and sort of Software-as-a-Service. I think, most interestingly, it's starting to open up those sort of areas with some well known players, some small ones also entering the game.

BGB: I'd like to continue with audience questions. How do you see the interaction between architectures and concepts like SOA, business intelligence, and BPM?  Where do they intersect and how are they different?  Who would like to take a first stab at this one?

DS: I'd be happy to start with this. And I think, again, excellent question. SOA is really about making your business functions accessible. It's the best architectural paradigm there is out there that allows you to connect your systems together and allows you to enable -- provide a universal platform for accessing for your business functions whether it's to submit an order, for example, to pay a bill, to receive an invoice, etc. Okay. That's sort of the granular level and that becomes the foundation.

Above that, to achieve businesses objectives whether it's to enable a business transaction as we just talked about, to enable a new type of customer service or customer interaction, that's going to require the coordination of multiple services. And as long as you're talking at the coordination of multiple services, or the coordinator of multiple people, that's where BPM plays.

BPM is sort of the layer on top, which adds the business -- intelligence business objectives. They allow these services to be orchestrated in a way that provides some business value to it. Now, intelligence is sort of the flip side of that, which is instrumenting what you do, and providing ways of giving visibility into what you do. SOA helps because now the functions that you used to be buried inside systems are now encapsulated as a service, and you can instrument that and you can now see what services are running.

But more importantly, I think as some of the other speakers pointed out, you want to know not how service is performing but how am I delivering my services to my customer, or my business transactions are performing, or my partner interactions are performing. Again, at that level, you want to not the service but you want to see the interaction and that's where BPM and instrumentation of that can provide insight to that.

It can provide -- and if you add operational and business intelligence with that, not only insight, measuring at granular level but at a higher level as well. Are my processes meeting my service level agreements, or my agreements with my partners, or with my customers?  Am I provisioning a cell phone within three minutes?

Am I making sure that customer when they come onto the website is able to submit -- compile a shopping basket and submit that in a seamless fashion all within a minute, for example. This type of instrumentation can be enabled through the BPM tools itself and this is why BPM is so important to providing that insight into what's happening, not on a granular level in your business but more at the transaction level and the interaction level.

BGB: Anyone else?  That was excellent. Thank you, Dale. Anyone else have anything to add to that?

UML: I would say that just a really simple answer the intersection is actually process. Yet, one of the things that business intelligence has lacked in the past is sort of context for how the information has been delivered, and that's provided by process. The other thing is having the tools to allow people to close the loop when they got information about what to change, how to go and change and that's what BPM provides. And clearly SOA need the ability as Dale said to orchestrate. So I would say the process is what's bringing a lot of these tools that were previously seen as being disparate together.

BGB: And what's providing the real value as well. Right.

DS: Absolutely.

BGB: People have visibility into the process have control over the process, can change it easily as well. I have another question from the audience. Some processes are very structured and can be handled with workflow of straight through processing. Some are more complex and require case management, but what can BPM currently do for complex, concurrent, collaborative, intensive processes, say, product development solutions or sales, or medical care?

DM: That's exactly the point I was starting to talk to before, Beth, about business uses really doing things other than the highly repeatable transactional procedures. And I think there is a real need for case handling type capabilities, which is the ability to able to bind process fragments together on the fly to allow suitably authorized users to build out their own processes, to be able to provide far more flexible mechanisms to the end user to be able to say, no, actually, I need to port this case and take an entirely different direction because I need to.

If you're an architect building a hotel and the customer says, no, I want a swimming pool on the tenth floor, suddenly, you can't say, oh, we can't do that because we can't throw out the process model and start again. You want to be able to add a fragment of process to that case to be able to say, yes, let's go and research and have a look at the implications for the structure, etc. And the same thing goes on in medical research, same thing goes on in literally every government department you can think of.

Its full of case handling type scenarios. And I think many of the vendors are pushing the -- what's the word?  Are pushing the envelope a bit to try and start developing applications in that area. And again, there are one or two players who've got really strong capabilities there.

ML: Yeah, I agree completely, Derek, and I think it actually goes beyond case manager and I think it goes beyond too talking about intersections between different technologies  yeah, it goes on to the intersection of BPM and for the Web 2.0 and collaboration technologies. How do I step outside of my unstructured environment with all of the stakeholders that are involved.

UDM: Well, why be in an unstructured environment in the first place?

ML:    Exactly.

DM:    Why not have a totally unstructured environment that you can add structure when you need to. It's that --

ML: So the value is always being able to add it back into the structured environment at some point in the future and having some sort of auditability and traceability so that if someone faces this problem again in the future, you can go back and say, hey, this is a similar problem we faced in the past around this similar process. The is how it was resolved.

And over time, maybe some of these ad hoc processes or ad hoc decisions actually become a little bit more structured and a little bit more repeatable. So I think it's about how you take the structure that BPM and the backplane that BPM can provide and facilitate this ad hoc unstructured collaboration in the background.

DM: And if you think about it Mike, if you and I started a company tomorrow, we'd start collaborating for a process called mutual adjustment. But as we understood those processes more and more, we'd become more procedural about how we do things, let's say how we take on work, or how we exercise on a project, or how we complete on a project. But I, -- for instance, I'm at the point of taking the framework that my colleague, John Jeston has developed, which is how to run a BPM program and put inside a BPM suite.

In this case, again, I mentioned Itensil before but that's exactly what I'm talking to is those sort of evolving, adapting processes that you can never predict beforehand they're going to be. You can only really interpret them on the fly and run with the bull. And those sort of things you just can't do with a production-ready, lets tie everything to the floor, procedural view of the world.

MD: From my perspective, this harkens back to the early days of information management where structured data was really easy to manage and unstructured data was fundamentally ignored because no one knew what to do with it until they figured out that you could sort of tag unstructured data, and manipulated those tags, and use that to capture what you've done with it before. And over time like you just said, build up policy and process based on experience and use the technology to hep you remember what you did and capture information about how well it worked and what didn't work.

And it seems like BPM is evolving in similar directions, that the goal isn't in fact to turn every environment into a highly structured procedure bound environment but to acknowledge the fact that a lot of what goes on in business process is ad hoc, and is unstructured, and still needs to be captured and managed in a way that makes the good stuff repeatable and the bad stuff avoidable. And that is to me where both user policies, and user experiences are evolving and the technologies we're talking about on the vendor side are also evolving to take that into account more and more.

DS: And I think as part of that evolution, I really see the convergence of Web 2.0 and BPM building some very exciting capabilities here. As someone remarked, BPM is evolving to not only being able to model whole hog processes, but process components that you can dynamically assemble as needed and also supporting ad hoc workflows and ad hoc routing of information.

Now, if you bring into that Web 2.0, which provides really a lot of collaboration and social networking technology, you start having really a powerful platform to work together. With Web 2.0 as part of BPM, you can have team-based messaging. So for those things that you want to take out processes, you want to confer on you can do that very easily.

You have Wikis for knowledge sharing, blogs to let people know what's going on, and if you can link your blogs and your wikis back to, again, process components and then bring them up to help orchestrate where possible, the more structured part of what you need to do. As this point and time, we want to approve something, for example, so we've talked, we chatted with this, we've blogged on this, we've done wikis on this. Now let's pull up the associated approval process.

Now we can all login and agree to that and check the box and now it becomes part of an established either, for example, if you're working on a document, it becomes part of the work product itself. So I think what we're doing is we're seeing the convergence of these technologies, Web 2.0 and BPM is really changing the user experience and the capabilities of what BPM can deliver to these structured and unstructured workflows.

DM: I mean what's happened at the moment is most of the vendors have started off with a highly structured environment and then they've layered on a collaboration space. Maybe they branch out to SharePoint or some other collaboration environment. The point is I supposed you can turn that around the other way. If you start off with an unstructured environment and layer on structure when you need it, then you have a different ballgame altogether.

ML: Yeah, just one final point for me. I think -- don't want to give too much away at this point but one of the ways that we're approaching this sort of required is to accept that for a lot of these ad hoc collaborations the existing environment that we provide to your customers isn't the right one. And a lot of the people that are involved in these ad hoc decisions and ad hoc collaborations are the sort of people you want to put Eclipse in front of.

So what mechanism can we provide to these people that ultimately deliver something that the people who are using these Eclipse-based environments can utilize but put something maybe in a Web-based environment that allows them to get this collaboration and decision-making done. So I think it requires a changing for the sort of the approach, the tooling as well as just sort of accessing some of these other mechanisms through the existing tooling.

DM: Exactly, but it's also if you think about it, the more that you can put control and change in the hands of the users who are in the problem, the lower your cost ownership over time. And in a sense, you know the discussion before about case handling is exactly that, being able to dynamically drop in bits of process because you need to at the time. You might have a whole library of fragments that are made available.

That's going to lower the cost of ownership as again, having to always refer back to IT. I mean in the course today, I mean it was quite incredible to hear the cost associated. For instance, in the UK, maybe I shouldn't talk to too loudly here but it's only a 100 people on the phone... In one particular outsourcing deal in the UK government, it cost 750 pounds to have your password reset.

Between four and eight K pounds, that's ten -- eight-- $16,000 to get a file restore done. When you start thinking about the cost ownership when you have to always go back to the IT department, through an outsource vendor to do those sorts of things, its absolutely massive when you start looking at the implications of that but how you run your business over time.

BGB: Okay. One of the things I would like to interject here is I think that there are different types of processes. I think we've come in and some of the questions from the audience have been around collaborative processes and how these come in. On July 23rd, we are having a conference on Web 2.0 and we're seeing -- a convergence of these different types of processes.

So in some -- and one of the sessions in there is going to be the tension between allowing innovation which is Web 2.0 is all about and what Dale was talking about allowing collaborative new processes. What Derek's been saying, start with the unstructured process but also have control over that and that's also required in organizations.

So they are probably many different types of processes that organizations need to get their arms around and maybe we're even talking about different types of tools, different types of models, and to understand where to put them, or what to do where. So I'd like to -- we have run out of time, and we only have a few moments left and I'd really like to ask this last question from the audience.

If you are just starting out at looking at implementing BPM, what are the activities that you would recommend as the first steps and what information are groups need to be involved?  And Mike, I'm going to start off with you. We'll just go down the line and we can just say a few words of what you see going forward and Derek an add on question for you is do you think there's going to a certification requirement for BPM or modeling?  Okay. So Mike, lets starts with you please.

ML: So I think absolutely 100% first thing is to ensure that your business cases is rock solid. And ensure you scope the project in such a way that if this is your first BPM project, you scope it in such as way you get clear business results but you don't take on so much that you sort of step outside your bounds of maturity. You recognize that you're probably in the earlier stages of maturity with all of this.

You want to do a project that gives you results, but allows you to do some learning by doing without failing too much. So scope it well, make sure there's a clear business case, make sure the stakeholders within that business case are onboard in the early stages. Make sure that their expectation around the project are clearly defined from Day One, and that everyone onboard is aligned with those different expectations because there are so many different stakeholders involved in BPM, and therefore different expectations as to the outcome will be.

It's easy to assume that your view of the world is the one that will win through at the end. So make sure you document those expectations as well. But I think scoping the right project and having a clear business case is probably the first priority.

BGB: Okay, Dale.

DS: To just add what Mike said, absolutely scoping is critical. Its probably the most important success factor. The second is defining the success metrics up front and agreeing on what success is. The third is building a cross functional team between business and IT and starting to define those roles. And there will be some overlapping roles and these roles can change over time.

But I think the fourth thing to put in place is really put in place a collaborative environment. Whether it's one group in a single location or it's a distributed group to choose the tools that help support collaboration in this effort because that will be key. And finally if you -- as you think about delivery of your business process development, establish the phased approach. Make sure you have  a deliverable. Hopefully, a production deliverable or at least a pilot deliverable every two to three months to establish, first of all, experience and well defined success targets.

BGB: Okay.

DM Quickly then, the other thing, yes, to all of that that has gone before but most crucially the first thing you really got to do is make sure your project is rooted in the organization properly, that you've actually got the blessing and involvement of the steering group that really make all the big decisions. I think we only got about ten seconds left, Beth, but certification is happening it's just wandering all over the place. Everyone you talk to, every consultant, every training group has come up with its own -- even the OMG is trying to come up one as well. So we'll wait and see what comes out of that.

BGB:Okay. Michael.

MD: You got to ensure that whatever IT infrastructure you have in place provides adequate availability, reliability, scalability, manageability, and security so that whatever type of collaboration you're supporting, and whatever type of process you're trying to manage, you don't put any of the organization's critical information or resources at risk. And if you do that and all the other things that everyone said, you can succeed with BPM.

BGB: Okay. Even as we enable the collaboration, we still have to get the basics right as well. So I would really like to thank Mike, and Dale, and Michael, and Derek for joining us today. I'd like to thank our audience for all your great questions. Please visit the booths. If you visit all the booths, you'll have a chance to win the iPhone 3G. Also, you can download a copy of BPM for Dummies here we will send you a link later on after the conference.

All the sessions are available for archived viewing. Please recommend them for your colleagues. And now, there are many unanswered questions here,  I'd like to invite you all to join me now in the networking lounge to continue this discussion. Thanks a lot.