BRForum 2009 Experts Panel: Emerging Trends and Decisioning
Roger Burlton Process Renewal Group James Taylor Decision Management Solutions Sandy Kemsley Kemsley Design Ltd Ron Ross Business Rule Solutions LLC
Kirsten Seer Business Rule Solutions LLC
- Will we see increasing linkage of process, rules, and analytics?
- How can we empower organizations and individuals to exploit this?
- Are we approaching the stage where the nature of testing changes?
- Will the convergence of products and technologies drive methodologies and standards? ... or vice versa?
- Will we see an increased focus on the business analyst?
- What can we tell the business to be a better business?
- What are the key areas that should be focused on near-term?
|Welcome & Introductions|
I'd like to thank you all for being here. I know it's been a long three days, and I'm sure you're feeling inundated by the tsunami of information available here at the conference. We like to save this panel for last. It's one of my favorite features of the Forum because this is our chance to look forward. Now that you've had a chance to talk to all the vendors, to go around and network, to listen to all the speakers ... now that you have a good picture of what's here today, this is our chance to look forward.
My name is Kristen Seer and I'm going to be your moderator today. We've assembled an illustrious panel of the leading lights in their respective fields. These are the folks whose books you want to buy, whose blogs you want to read, and whose tweets you want to follow. They're really in the know, and they know what's going on out there. And I think they have an innate capability to do what Jim Sinur talked about in our opening keynote, about detecting those patterns and looking at those signals to understand where things are going.
This is a participative session ... your opportunity to grill the panel. I'm going to ask the panelists to introduce themselves and to lead off with some thoughts about what they think is coming in the future. And then I want to hand it over to you, so that you can ask the questions. We've got a good turnout, so I'll be running around with the mic. Just raise your hand if you have a question.
Those of you who were at the practitioners' panel that Gladys moderated know that she gave out some special incentives — she gave out some of our mascots from the 2010 Olympics as incentives for questions. So, whether it was knowingly or not, she has set a precedent that I have to follow, but unfortunately we don't have any of those stuffed animals left. What I do have for you, for the first three questions, is some really deluxe chocolate. Now, anybody who knows me knows that I'm a total chocolate addict, and I only get the very best, so this is the good stuff. It will go to the first three questions.
Starting off with our panel, if you could be good enough to introduce yourselves and just talk about the key points you think are coming in the future.
I'm Roger Burlton. I've met a bunch of you already and hopefully will see more of you tomorrow. I come from the 'process' world and more from the perspective of how process helps hold things together. It's very much an integrated view of how we have integrity across a whole bunch of things, and how process can help.
In terms of some of the key words and key patterns I see, one is evolution rather than revolution. In other words, the ideas are revolutionary but the implementation is still evolutionary because we still have to keep the lights on while we're rewiring the house. I think that's a challenge for all of us. We can't stop while we change things dramatically.
In terms of the major patterns that I'm seeing right now, the first one I see is the treatment of business processes as enterprise assets, as opposed to just "something we do while we're doing a project." Even though it's on no one's balance sheet, they are things that are reusable — they have a cost, a value, a benefit. I am seeing a start to manage the whole lifecycle of processes. And I really do think that this is one area where business processes are little ahead, in terms of maturity, compared with business rules. I see a lot of people now going to the enterprise level of processes. I'd like to see the same thing coming in the area of business rules, where we truly start to see them as something that is defined once and used in many places — across applications, across projects, across implementations.
Also tied into this, I'm seeing a very strong trend towards governance. In fact, this has been the year of governance, in general, and there will be a lot more of it to come. The idea of governance over the performance as well as the change to ensure sustainability of that asset, which is all the things we would do with our buildings and our technologies, we need to do for our softer assets as well.
The last thing I'm starting to see in terms of patterns is the idea that — especially in the process world — we're seeing a very, very strong drive towards frameworks. Those are pre-defined, industry (or lifecycle or asset management) sets of processes that you can pull off the shelf and use as a starting point, for example, for the insurance industry or for the telecommunications industry. There are models out there to start with, and I expect to see much more of those things come forward in the next little while.
All right, I'll go next. I'm James Taylor from Decision Management Solutions. I've met many of you during the week.
Like Roger, I'd like to say that I've seen decisions treated as a corporate asset, but I don't see that very much yet. You see it perhaps only in the credit industry, where they are beginning to start to say, "We've got to get formal about all decisions in a customer lifecycle — how they affect each other, how we sequence them — and we're going to take account of the fact that we have other decisions coming later in the lifecycle when we make the first ones." That sort of systematic assessment of all the decisions in a customer lifecycle I think is something we will see consolidate itself in the credit space. But I think it will be awhile before we see much beyond that. It still seems we are in the early days from an asset management perspective, with respect to decisions.
So, there are two things that I see most obviously changing in the last twelve months. One is the growing acceptance of rules and decisioning in the context of enterprise applications. You see it in vendors who sell marketing solutions or customer relationship management solutions, who are starting to talk about having centralized decisioning capabilities, and managing rules and analytics across all the customer treatment decisions. And you can see it with companies like SAP, now shipping dozens of functions, in their core enterprise applications that have been built in a rules engine. So, you begin to see people whose core business is enterprise applications, of one kind or another, starting to see the potential for shipping decisioning capabilities in those applications built with rules. As someone who follows this industry, I think that's a trend that's much to be desired because I think that creates a core capability for decisioning inside the enterprise backbones of many companies.
I follow the analytics space a lot, and one of the things that's been interesting this last year has been the extent to which rules are seen by analytics people as a way to deploy and make actionable the analytics they have. You hear stats like "half the analytic models developed by companies never make it into production" - because they take too long to implement, or they turn out to be much harder to implement than anyone thought, or the IT guys take one look at the model and say, "There's no way you're getting access to THAT data!" or they say, "We don't have that data yet." All these kinds of things make it hard to deploy these models, and these models are not cheap to build. But they have huge potential value. So, companies are beginning to find that unacceptable — they've got to have a better platform for deploying these analytics, and they see rules as a potential way to do that. I think that's going to drive a growing acceptance of rules in the analytic space.
The last comment I'd add is: I'm not sure how quickly, but I think the ability to decision against streaming data is going to become more and more important. I talked a little bit about it in my keynote — there are a few examples that you see and I think there's potential there. It may turn out to be a trend that we see come faster than we expect. You see more and more streaming technologies out there — streaming analytics, streaming databases (databases that are designed to work in a streaming context). So far, they haven't perhaps had a huge impact, but I think they might. So, that's one of the maybe/maybe not kind of trends that I see.
I'm Sandy Kemsley. I'm an independent consultant and, like Roger, I work on the process side. I do work helping organizations to implement BPM systems.
I do a lot of work at the boundary between process and rules ... and analytics, too, which is very important. As James has said in the analytics space, we're starting to see more and more importance on how analytics is involved in all these things. Really, I'm seeing that linkage between rules and processes and analytics and business intelligence. People are starting to realize that these things have to come together ... because you can't have just one of these types of technology (or management practice) — you have to bring them all together in order to make things work.
One of the big things that I'm seeing in the process space — and I think this has implications from a rules standpoint as well — centers around unstructured (or dynamic) business process management. Both the Forrester and the Gartner analysts have been talking about this lately, and I've been seeing it a lot. We'd probably have a Forrester or a Gartner analyst here talking about this today except that you really can't get them to stay this late in a conference. They all do their keynotes on the first day, doing the hit-and-run thing.
So, what you will see — what they're seeing (and also what I'm seeing in practice) — is that you can't just make a structured process any more. And I think it's the same in the rules space — you can't have just one set of rules (or one set of processes) that fit every single situation. You have to be able to give people goals and allow them to bring whatever resources to bear that they need in order to meet those goals.
This means we have to bring things up to higher-level, goal-oriented businesses and applications, where people can apply things. There's definitely going to be rules and processes involved in there, to give people a little bit more flexibility in how they're solving some of the problems they have.
Hi. Ron Ross, of BRCommunity and Business Rule Solutions and Business Rule Forum.
I wanted to try to think of something that hasn't been said. I was sitting here thinking about the last twelve years. This is the twelfth year of the Business Rules Forum, and there has been significant change over that time. But this is actually a watershed year — I strongly believe that — because up until now our focus has been trying to explain, "What is the message?" ... "What is business rules?" And this year, for the first time, there's a shift in focus. It's not so much on "What is it?" but on "How are we going to do it?"
I think that's partly the result of the consolidation of the vendors and having the big vendors (IBM, Oracle, and so on) jump into the space. And partly it just may take a decade for new messages to take hold. A lot of good work by people has been done.
And, so, looking forward the emphasis, I believe, will be increasingly on how do we do things? ... how can we be effective with this? The tools are getting better, but really the real challenge remains a human challenge ... remains a people challenge and the ability of communication. In my session a little bit earlier I focused on the issue of human communication and the importance that that has to capturing and retaining the know-how of the business.
That leads me to some concerns about the people who will carry forth from this point ... the skills that they need to have to use the emerging technologies and to make a difference in their own business. Generally speaking, those are the business analysts who are right at the crux of what's happening in the space. Unfortunately, at the moment, I think that although we've seen orders of magnitude improvement in business solutions, we have yet to see orders of magnitude improvement in the skill level of business analysts, in the numbers of business analysts, and in the funding for business analysts as a viable and important (in fact, indispensable) corporate concern.
So, what I see as the new, emerging challenge is the challenge of gearing up on the people side, to be effective with the technology.
Thank you very much.
Okay. So now it's time to turn things over to all of you and to get those questions going. Who has a question? Don't be shy. This is your chance to grill these guys.
I guess that falls to me to talk about. Yes, I think that you can look forward to some fusion of different areas of concern. I don't want to make any announcements or predictions, but there's a very high probability that there will be a process conference co-located with us next year because it really makes sense to have the two areas complementing each other and supplementing each other and supporting each other. More and more people on both sides understand the importance of having a good mixture.
In doing that, I can assure you that I won't let anything slip on the business rule and decisioning side. Because frankly that's my first love and first concern — although I know that Roger would disagree with this — the most important thing. (That was to see if he's awake down there.)
I'm just not sure if I should answer that. <laughter>
And I honestly think that we are at the stage in the need for business solutions, where it's not enough to know one part of the solution. You really need a coordinated set of answers to what are a wide variety of business challenges. So, I don't know what else will be involved in the fusion but there will be some interesting things happening, and they're already well under way.
Guys, I think that, very simply, we're all realizing that you cannot use a single-perspective methodology to solve a multi-functional problem. I think that's what we're facing. Our solutions are multi-functional; they're interdisciplinary. Therefore, our methods cannot all stand alone and not touch each other. We've got to bring it all together.
There's a reason why Roger and I are sitting at opposite ends of the panel. <laughter>
They pay me and Sandy 'danger money'.
I got to move the name cards around.
We've had a lot of fun, actually. Roger and I and John Zachman have been doing what we call "Three Amigos Events" around the country and in Europe. We have learned that we needed to fuse, in many respects, in order to fully appreciate the importance of the other perspectives. So, it's been a learning experience. I have to admit, I have learned a few things from Roger. Certainly, I think he said it very well: it's a multi-faceted problem that we face in businesses, and you'd better have all the tools in your tool kit to try solve that problem.
Next question. I saw a hand go up here.
I can start with that because, with my customers, I work with a lot of business analysts. One of the things that I've found is that an organization will move someone into the position of business analyst because they've done well as a business user. They don't necessarily have the skills or the experience to be a business analyst — they're just kind of labeled that. Then they become a little bit stranded because the training programs are not in place in many organizations — some do have training, but others don't.
We need to get to the point where business analysts require the same sort of certification, such as we see these days with project managers. Nobody would think of hiring a serious project manager any more who doesn't have a PMP certification. I know the IABA is working on some certification programs, but I think we need to have some better understanding around the fact that business analysts do need to have those skills and that a certification program is one way to help demonstrate that they have the skills needed. Otherwise, you're trying to get them to do something that they just don't have the capabilities to do.
From an organizational perspective, I'm afraid there isn't an easy answer. I've been thinking about this a lot because, looking at the analytics space, it's very easy to find companies that are headed by someone who's an ex-quant or ex-mathematician that have adopted analytics very broadly. But it's very hard to find companies that have adopted analytics very broadly that aren't headed by a quant. Most banks, for instance, have ex-risk managers. So, you only see this broad use of analytics in companies that are headed by someone who understands the analytics. Clearly, that's not sustainable. You have to find a way to take the VP of Sales, who becomes the CEO, and still get analytics to work in those circumstances.
I think we have the same problem to some extent with a lot of these technologies. I'm not sure that there's an easy way to fix that problem, other than sheer Darwinism — the companies that do get it will outperform the ones that don't, and gradually this will become self-correcting.
I keep hoping I'll find some way to get organizations to realize the potential of this, but at the moment it's hard work to get it to be systematic rather than opportunistic.
To add to that, in Canada, there's an organization called the Canadian Institute of Management Consultants, whereby the actual competency of consulting is recognized as being independent of the specific technical, professional areas within which you do things. That organization has been around for a while, and it is now spending most of its time in advocacy. For example, in British Columbia (where I live), the local chapter is having meetings with the leaders in government to get them to put, in their requests for proposal and requests for information, a requirement to have a designation of CMC in order to do real consulting work. Otherwise, anybody can hang his shingle out there and call himself a management consultant.
I think there are some similar issues in business analysis. Anybody can call himself a 'business analyst', and it's so different from place to place that we need not only the body of knowledge and the certification but also the advocacy with those people. Marketing and awareness — it is as much about that, while we're being successful in what we do.
The most important skill that is needed for business analysts to be successful is simply to relearn how to speak 'business' instead of speaking IT. The most basic thing of all — and this is where I tried to focus this year in a lot of my work — is on basic communication.
You would think that would be easy, but that's actually the hardest problem you could work on because it requires very careful engineering and definition of your concepts; it requires very careful coordination of vocabulary; it requires you to write and speak well; it requires the capacity to think very precisely in language. And that's what we've forgotten — that's what the industry, after forty years of IT implementation and very deep methodologies in IT, has forgotten. We have forgotten how to speak normal language.
So, the most important thing to get back to is the capacity to speak clearly. There's a lot more to that than it sounds.
I'd like Sandy to comment on this, since she is the blogger supreme.
Well, the language is a big part of it, but we also have to look at the changing roles of a business analyst because the way that we develop software isn't the same. When I started in the software industry in 1985 I was writing Fortran code. We did things a little differently back then.
I love it! I did the same thing. Another person knows Fortran!!
That explains a little bit about both of you. <laughter>
The issues that we had then (and we still see this in many organizations) were that we had a very waterfall type of methodology, where there was a strong focus on business analysts going out and gathering information, and then writing huge requirements. We're not going to build agile systems if we're building them like that. We need to really bring in some of the agile methodologies, too.
So, although we need to have better analysts on both sides of the house — both business and systems analysts — we also need to have a better understanding of, and more closely embrace, the agile methodologies that are available. We are dealing with model-driven development here. Both rules and business process management provide us with these great model-driven development tools. And what do we do? We take them and we use waterfall methodologies to implement them and we write a bunch of Java code. What's wrong with that? All we've done is invent a new generation of legacy code; we've just done it on really pretty tools.
Just for the sake of entertainment, I'm going to disagree with that a bit. I'll bring up a point that James mentioned in his keynote (and, James, if I get this wrong, you'll correct me, I'm sure). That is, there was a business manager who had said that, after learning how to write business rules effectively — and help me out if I don't get this quite right — essentially, they eliminated testing in their organization.
Now, I was sort of sleeping through most of James' talk (I was wondering if he was going to spill that drink he was holding in his hand). <laughter> But when he said that, I thought, "James, did you really say that?!" Now, think about that. What that says is that if you write the business rules precisely enough — and it's based on terminology ... vocabulary that is standard and understood — you've eliminated so much of the ambiguity and so much of the conflicts and the problems that testing, in the traditional IT sense, becomes far less of a concern.
Now, eliminate it completely? I don't know, James. But the point is that a lot of what we do today is simply unnecessary because we have forgotten how to be precise about talking about fundamental knowledge, up front.
Ron, I hope you don't mind me jumping in and maybe disagreeing somewhat. If you look at what the Japanese have done with product quality in the physical product space, for the most part they've stopped measuring defects. Quality control is no longer an issue; quality assurance is. What they are doing is that they are doing their testing at design time, rather than doing their testing at implementation or construction time. Therefore, the testing is built into a very agile style of analysis and design, and it moves to the business analyst, as opposed to being with the developer as the tester. So, I think we are still doing testing but we're doing it in a smarter way.
That's true. I was reminded of this as I was watching someone running a use case for a rule and they said, "Well, we never write anything without running a unit test case to make sure it works right." And I thought, "Yeah, but when you look at a rule and you look at the unit test case for the rule, really what you're doing is testing two things." You are testing that you can write the same set of data conditions twice — once in the rule and again in the test case. And, secondly, you are testing that the rule engine does actually work. Providing that it does, and you've written that IF these things are true THEN do this, and then you write a unit test case that says assert these things, what you will see is if you get the answer you put in.
So, there is a sense that the design-time checks and balances and structure that you get out of these tools fundamentally changes the relationship you have with some of these traditional IT processes and methodologies (as Sandy was saying). You can't do this the way you did the old stuff.
That brings up a secondary comment around systems analysts and IT people, in general. I'm always struck, when I talk to IT-heavy audiences, by how little penetration some of these ideas have made into core IT groups — analytics, process management, etc. You ask the people who are IT architects (technical architects), "How many of you have used a business process management tool?" ... "How many of you have used rules or analytics?" A depressingly-high number have not.
I think we have a flip side of the business analyst problem, which is to educate our IT colleagues on what these tools can do and how they can be part of making them work.
For the last set of chocolates, is there another question?
Yes, one of the things I find — when I talk to vendors about functionality and when I talk to people who are new to rules and starting to add rules capability — is that they always ask about it. You'll be under a lot of pressure from your IT department to add unit testing or support for some testing framework, but if you actually want to add more value you would add impact analysis.
That is about a business user, about to make a change, understanding what the business impact of that change will be. That's what business people think about — they think about, "If I change these rules, am I going to end up with ten times as many applications in the manual approval queue?" or "Will I suddenly acquire a bunch of risky customers?"
That is what business people mean by "testing a rule change" — it's not what we've traditionally built testing infrastructure for. So, yes, I agree with you. "Testing" is a word that we have over-loaded with multiple uses, and these tools force us to separate those uses again so that we can really manage those two things separately.
In our process methodology we don't call that stuff at the business level 'testing'; we call it 'validation'. We validate that we understand the business requirement. Obviously, if we don't get that right, we're in big trouble.
One of the most important take-aways you can take with you from the conference is that the life cycle of business rules (or decisions, if you prefer) is fundamentally distinct from the software release life cycle. They are two distinct things. They have to be separated, first of all, because they have their own speed. Second of all, they have their own requirements. And, thirdly, because you need to manage your decisions (business rule sets for decisions) as a distinct business proposition. And software is not a business proposition per se.
So, I agree with you 110%. It's kind of amusing ... if you look at methodologies, there's always been the traditional talk of "functional requirements" in software development and then "non-functional requirements" which really, I guess, are business rules? We've got to stop thinking of business rules as "non-functional requirements." No, no, no — business rules are the thing that the business needs, and functional requirements for software are something entirely distinct.
I think that's a really good question. For instance, some of the business process standards don't really talk about rules and decisioning very much.
I think we're all going to agree to that one, and we're not going to name those four initials that we're thinking about.
I think as you get more and more of the BPM vendors, who are out there implementing these things for people, having that capability, it's very hard to see how that won't be reflected in the standard. I do think that good standards bodies do recognize that mostly what they try to do is take 'best practice' and write the standard that describes it — rather than try to create from raw cloth some new piece of intellectual property.
So, this will come as people do these things for real — and certainly, from the last few shows I've attended, there's been a lot more talks from people who are doing projects with rules and decisioning. I think that will start to drive best practices and it will start to drive an awareness in the standards community that these things need to be done.
So, I think that the convergence of the platforms and the vendors — and the increasing use of the pieces by real projects — will cause a feedback loop back into the standards. Then, you will start to see the standards reflect more of this unified perspective.
I think that's a very optimistic view, though.
I'm always optimistic.
For example, if I look at the concept of model-driven architecture (which the Object Management Group has been pushing very, very hard), I don't really see it yet in the disparate standards that are coming out, each of which is coming from a particular perspective. They aren't really coming together nearly as well as I'd like. Maybe it's just really a slow go at it.
And to be just a little bit cynical (even though I am hopeful), some of those standards are being done by vendors who can afford to put full-time people on those committees (or close enough to it), as opposed to the practitioners who have real work to do somewhere and don't have input back into the standards. I'm not seeing the practitioners' perspective coming in nearly strong enough in some of these standards. But maybe it's going to be a longer cycle for that.
Man, I hate to agree with Roger. <laughter>
I agree with that 110%, having been involved with the standards. People are not in touch.
Without going into any great detail about the question itself, I would recommend that you not wait for standards and that you understand your business problem and move forward on that problem, irrespective of what standards are there or not there. Because the standards, right now, are not what they need to be to help along the industry.
And they become unnecessarily complex, too. In BPM we're dealing with the BPMN standard, which is just coming out in its second version. There are parts of it that have become so complex that the typical business analyst, that it might be targeted at, is not going to use a good big chunk of the standard because they're not going to understand how to use it. As a former developer, even I don't understand how to use it. They've turned it into a graphical development language where we have ... how many different types of events, Roger?
There are now forty-seven types of events in 2.0 and there were twenty-one in 1.something. The people working on the committee have admitted that they had to add in all these extra events so they could take a specification and actually generate code. So, it has become a new programming language, as opposed to a business-modeling tool for business analysts.
So, what we tend to do is to use what we call "BPMN-lite" — we only use three of the symbols and you are banned from using all the different differences. That way, what we hopefully try to do is to have traceability from the very general model, at the business level, down to the specification level, so that you can point to where some piece came from.
I don't want my business analysts getting into worrying about whether something has to be a dotted circle inside the circle with an "X" in the middle, or a plus or something else. My business users just don't care.
I remember, many years ago, working in PeopleSoft's R&D group, there was a guy there who had a great comment: "Sometimes the best way to specify it is to write a piece of code." <laughter> It's the clearest.
He was very into model-driven stuff so it's not like he said there should be a lot of code. But he said that there's a point where making the diagram do it is harder than just writing a piece of code.
I do want to add to my answer that there is the SBVR standard — Semantics of Business Vocabulary and Business Rules. But the timeline on that in terms of technology is a five- to ten-year timeline. Eventually, that style of computing will almost be automatic, but it's not close to that today.
So, from a practitioner point of view, you simply need to pick up the best of vocabulary and concept-engineering practices from SBVR. They can be extremely useful. In fact, this is what they are about — to assist you in that business communication problem that I cited earlier.
I can't believe that I'm going to say this, but I have to congratulate Ron and the Business Rules Group on an incredibly great job on the Business Motivation Model, which is all about the ends, means, strategy, strategic intent, etc. It's outstanding, and I think we can all use that at the highest level for our communication.
Well, thank you, Roger.
And let me just mention that the Business Motivation Model (which is about structured strategy) is a fact model ... a business vocabulary. What we did when we created that — and this goes back more than ten years — we sat down and engineered those concepts and vocabulary, and structured it. It turns out to be a very readable, useful exercise.
That is how you develop and communicate know-how. It's very simple. It's just good communication practice.
Are we good there? Do we have another question?
I think we've seen the same thing happen with BPM conferences in the past few years. That will likely happen with this conference and other things that start out very IT focused. It used to be, when you'd go to a BPM conference, it would be 90% men, which was great for me because there was never a line up at the women's restroom. <laughter> But it made for an environment where you felt like this was a bunch of technical guys, hanging out and talking about Java code, which was not all that interesting at the end of the day, because it didn't deal with the business problems ... it didn't deal with getting to some of those higher-level representations of processes (or, in this case, rules) and looking at those issues and business impacts, and so on, as opposed to thinking about the implementation side.
I think we'll see the same sort of evolution. If you go to BPM conferences now, you'll see many more people from the business side, and there tends to be a stronger representation from the female gender. That's how I measure it a little bit because I sit on the technical side, so I am the outlier. When I look out in the audience I can usually tell what kind of mix of IT and business it is, based on the gender mix in the room. It sounds weird, but think about it.
Actually, Sandy, we appreciate it, too.
We will see that same thing here. As this moves up, and as we move into things like model-driven architecture/model-driven design, the business people do have to be involved at this level. It isn't just that they're going to write down a few of their requirements and throw them over the wall. The business people are going to have to come to conferences like this and learn more about how these things actually happen. The business people are becoming much closer to the implementation now.
My philosophy in the conference, for all these twelve years, is that the exact same message needs to go to the business side, to the IT side, and to anybody in between (which, increasingly, is business analysts). So, I think that, given the range of problems and needs out there, you'll continue to see a good mix of the two. And I hope that the message remains consistent that we are all in this together and that we have a common problem to solve. IT can't solve it on its own, and business people can't solve it on their own. There's a great need for some catalyst and for people to help out with the solution.
Also, there's something that companies need to think about. It has been my experience with a lot of customers I work with that it's pretty standard to send IT people to conferences to learn about new technologies and new skills. It's very rare to send business people to a conference that isn't just about your vertical. If you're a manufacturing company, you can send someone to a manufacturing conference; that's okay. But the idea that you would send a business person — or a business analyst, even — to a "technology" centric conference (a conference about how a technology works) is something that a lot of companies have a hard time with. They've gotten used to the idea that the only people who have to understand a technology are IT people.
I think we really have to challenge that as organizations and say, "No, our business is our systems." We can't run our business for a nanosecond without the systems that support it, and our customers increasingly interact with us through these systems.
So, if the people who understand the business cannot be involved in how the systems behave, then we're never going to make any forward motion. We have to be willing to invest in sending less-technical people to events where they can learn about these technologies. That's a fundamental shift in how companies think about who goes to which conferences. That has to change.
I think we have to do what some of the people in the Six-Sigma and Lean space have done. A lot of business people go to those events because it is emphasized that these are not only not technical but "technical people need not apply." We've seen Lean projects done which are massively-big projects where the people who are running the project said, "IT, you're not even allowed to come to the meetings." Later on, they figure out that they do need some technology, but they've done a great job of branding Lean and Six-Sigma as being a set of business tools. We haven't done that yet, I don't think.
So, let me turn it back to you guys. Any and all suggestions about how to address this problem are more than welcome, and they will be considered. We have that challenge, and we want to be the focal point ... we want to help facilitate the focal point for solving real business problems. So, help us out.
I think that getting more speakers from the business side really helps. If a business person can point to a conference agenda and go to their manager and say, "Look — there are six people there who do the same job that I do and they're going to be talking about their experiences with business rules." That's going to make a difference. That's going to bring in more of the business side.
Sandy, my experience with that has been that when that happens it's because somebody from the business side is talking about something that is in their vertical. In other words, someone speaking about business rules in insurance or in manufacturing. So, maybe that's the first step.
Well, you do have to do that. The business people will talk about things in the context of their business. We see the same thing on the BPM side. For the most part, if you have someone talking insurance or manufacturing, most of us know enough about those businesses that we can understand what they are saying and we can relate those same topics to our own business. So, having it in a vertical isn't necessarily a bad thing; it's a good way to actually show how the rubber meets the road with this.
It's my belief — very, very strongly — that any dialog with the business has to be performance-centric. In other words, you have to show the business value in things that they are measured on — without that, you are noise. So, you need to align the motivation of the individuals with what you are trying to do. We always have to connect with what's in it for people and how that affects business performance.
I also think one of the things we can do is encourage people not to be too focused on their own vertical. Because one of the things I've noticed, when I tell the story about the thirty government permit processes going to one, is that I get responses from people (like insurance companies) that go, "Gosh! Do we really have thirty forms-issuance processes, or do we just have one, with a decision at the beginning?"
So, I think the one thing we have to do when we have the kind of capabilities we're looking at here is to encourage people to learn from other industries and to identify what Jim was calling the patterns that we see. The kinds of uses of these things in combination can be described as "business patterns" in the same way that IT people have started describing technology patterns. I think we need to help people find those patterns and say, "Gosh, that's the kind of pattern I have. Even though the person speaking is a manufacturing person, I should apply it to my business."
I think you've seen this in the lean Six-Sigma when you see people learning from industries that aren't their own, by coming up with some standard ways of talking about, and improving on, the problem. I think that is something we do have to do — we have to help businesses find that expertise elsewhere, not just inside their own industry.
I'd like to support that with an example. If you look at Wyndham Hotel chain, Wyndham Hotel Group is the largest hotel group in the world. They own about seven thousand properties, or franchises. They are Best Western, Quality Inn, Howard Johnson — those are some of their brands. One of the things they did — actually led by the IT group originally — is to decide that they needed to replace everything associated with how they were managing their franchises. So, they went into a process project and supported it with a whole new technology platform ... with a whole lot of rules sitting in there as well.
By the way, they capitalized that project because then they saw it as an asset. And at the end of it they were granted a patent on the process and the supporting capabilities. Now they are selling this to real estate companies (and others) who have franchises. This is basically an approach to franchise management.
This is the best example I've seen of the type of things that James just mentioned. You don't have to say, "Oh, we're not in the hotel business." There is a general approach to doing this kind of stuff.
In my session, I prefaced the discussion by saying that I'm very concerned about what companies are outsourcing to India, or what they are about to lose as baby-boomers retire, and so on. Who's to blame? Why is that happening?
Part of the problem is that the know-how of the business is not tangible enough to business people in order to know what's actually being risked when they outsource. So, part of the theme (which I would think is common in process models as well as business rules) is "Make it real!" Put it in words; put it in a model. Make it real so that what it is that you need to manage (and not outsource) becomes much clearer. I think that's a very important step forward.
Okay. I think we have time for one last question.
Before we do the last question, I wanted to say this one difference between rules people and process people. Ron and I both doodle, and Sandy and Roger don't. So, clearly, rules people doodle and process people don't.
The process people google, not doodle. <laughter>
I think it's because they get to draw enough pictures with their tools.
I'll give you the standard consulting answer ... but you know what that is already. "It depends." It depends a lot on your maturity already. If you're starting down at the bottom, I wouldn't be trying to train a lot of people ... rather, make them aware. Gradually raise awareness; pull down articles from BRCommunity and BPTrends, places like that, and (by stealth) get things out there. Get people thinking about it, until they believe that they thought of it before you did, which is always an interesting challenge.
If that was my starting place I'd be making sure that they understand the terminology, that they understand the challenge. Just show them example, example, example of what other people have done to get it all going.
After that, you get permission to train in the methods. It's the 'what' before the 'how'.
By the way, along those lines, James' book, Smart (enough) Systems, is really good in that it has several hundred examples — small case studies — of what companies did ... what problems they solved. This was one of the really good things that that book did. And the book that I just wrote, the third edition of Business Rule Concepts, was meant to be really, really easy to read. That was the idea — here's a little, thin book: look at it on a plane ride; just get people thinking about it. That is the first step, and Roger is very correct about that.
Beyond that, what we recommend for the fundamentals is a combination of process modeling and training — because there's a lot more to it than you think — with business rule training and fact modeling training. These are, hopefully, coordinated in a way that gives people an initial set of skills, with some hands-on to get started.
Now, when initiatives are begun in companies, I listen very carefully to try to find what their particular pain point is. I learned a long time ago that you don't get any credit for solving problems that other people don't perceive. (You have to think about that a second.) And, so, look for the pain-point that your company is feeling — even if it's not the enterprise-level solution that you'd like ... even if it isn't the beautiful rules set that you might wish to produce. Focus on a problem that the company perceives and show what the techniques can do. I think that you'll find that goes a long way in raising profile awareness ... encouraging dialog and all the things that need to happen in order to make a big difference in the company.
|Kristen: Well, thank you all so much. Thank you to our panelists. <applause>|
# # #