Panelists

Jan Vanthienen	Professor in Information Management, K.U. Leuven
Roger Burlton	Founder, BPTrends Associates
James Taylor	CEO, Decision Management Solutions
Ronald Ross	Co-Founder & Principal, Business Rule Solutions, LLC

Moderator

Kristen Seer

Senior Consultant, Business Rule Solutions, LLC

Topics

1. Jan's Observations
2. Roger's Observations
3. James' Observations
4. Ron's Observations
5. Panelist-to-Panelist
6. What does 'KPI' mean in the context of making a GOOD decision?
7. Which comes first?  Decision or Strategy?
8. Do you distinguish between making a decision and the process of making a decision?
9. How do events and processes and decisions interrelate?
10. Will the various techniques we've heard about this week become even more specialized, or do you see a convergence?

.

Welcome & Introductions

KRISTEN:   All right. Good afternoon, everyone.  Welcome to our panel, Decisions from the Business Perspective.  My name is Kristen Seer and I'm going to be your moderator this afternoon.

I am very excited about this panel, both because it's the first time we have actually done this panel on the decision area and because it's from the business perspective as well. 

We have an absolutely illustrious panel here, and I'm delighted to introduce them.  As it happens, I do know all four of these gentlemen, to varying degrees.  I see them every year at the conference, and it's always a pleasure to talk to them.

Our first panelist, on the end, is Jan Vanthienen.  I met Jan several conferences ago when I attended his seminar on decision tables.  It was wonderful!  It completely opened my eyes up to the power of decision tables.  Jan and I have had a number of conversations about decision tables since then and he always tells me, "You know, I do do other things besides decision tables."  <laughter>  And, I'm sorry, Jan, but to me (and with great affection), I will always think of you as The Decision Table Guy.

Our next presenter, James Taylor, I've also known for a number of years.  James has been a stalwart at this conference right from the very beginning when it was the Business Rules Forum.  I used to get such a kick out of it because he would be there every year, but every year he'd be working for a different company.  (JAMES:  Same job — just a different company. <laughter>)  Same job, but somebody would keep buying the company he was in!  James, along with Neil Raden, has written some of the seminal books on the decision area.  He's also one of the very few people I follow on Twitter.  A couple of times he's actually re-tweeted my tweets, and, I can tell you, that just made my day! <laughter>  So, to me, James is The Decision Guy.

Next we have Roger Burlton.  Before we get into Roger, you'll notice we're very focused on 'decision'.  But Roger is a little bit out of the decision space ... because, if you know Roger — if you heard his keynote earlier today, as I'm sure many of you did — he's very much The Process Guy.  That's how I think of Roger.  As it happens, Roger and I were talking last year.  Both of us were getting our homes renovated, and we started talking about the renovation process — how the process worked, and the design process and the construction process — all the things you have to do.  But do you know what really floored the two of us?  The number of decisions you have to make, as you go through the renovation process!!  Every single step of the way there was a decision to make!  So, it was very clear that decisions and process truly are related.  To me, that's how you tie the two together.

And last, but never ever least, we have Ron Ross.  I have the pleasure of working closely with Ron.  I have been working with him for over a dozen years now.  I can remember when I first started working with him … talking about rules.  And in the rules space he would always say, "Well, you know there are different kinds of rules.  There are rules all around behavior and guiding things — what you do.  And then there are these decision rules."  And I kept wondering, "Why is that important?"  Well, it turns out it's important because you treat them very differently.  There's actually a whole different set of techniques you use to elicit your decision rules versus your behavioral rules.  Over the years, Ron has really gotten into this decision space and has developed a lot of great techniques to help you organize and structure your rules — structure them into decision tables. 

So, we're really coming full circle here.  Although our four guys here are eminent in their different spaces, they do have a commonality with the decision space.

Now that we've done our introductions, here's our agenda for today:  each of our panelists is going to do a five-minute presentation.  Some of the panelists have asked me for the opportunity to rebut the others' presentations, so after the initial presentations we'll give them a few minutes to do that.  But then I really want to open up the questions to the audience because this is your chance to ask these wonderful gurus about decisions and handling decisions from the business perspective.

Alright, so let's start off with Jan. 

Jan's Observations

Thank you for this very nice introduction.  I feel flattered, being not the most beautiful of the guys around the table.  (ROGER:  This is no beauty contest. <laughter>)

Alright — I'm the first one, so I'll get all the comments.  Let me open with a few comments of my own.  I could start off with a few lines to spark a fight, but first I'll mention how we agree because maybe that's more important.  (JAMES:  It shouldn't take as long either. <laughter> )

My first observation:  The Business Rules Manifesto was started ten years ago; it emphasized that business rules are First Class Citizens.  And then, a few years ago, Roger did the Business Process Manifesto, about the importance of processes and the work performed by all these resources.  And, more recently, James started the Business Decision Management Manifesto, saying that this is itself a first class object.  So, here we have the three guys doing this.  (By the way, there is no Decision Table Manifesto; we don't need it.) 

But I would like to plead for an integration, calling it "The Business Manifesto" … or the "Business Analyst Manifesto"? … the "Business Modeling Manifesto"?  Three manifestos is enough; let's integrate them now and create the Big Manifesto.

I'm from a university.  That is the research I do (besides being the Decision Table Guy — which is my hobby, actually).  So, partly being in decisions, partly being in rules, partly using them in processes, I feel well-placed to make some observations — not statements of position, but some observations. 

First, there are a lot of decision trees and sometimes you see trees inside processes.  We know this is not good practice.  Ron will agree; Roger will agree; James will agree.  And I, of course, agree.  That's at least something we can agree and perhaps improve upon.

Second observation:  There are indeed a lot of decision activities (processes) and they have to do with rules — decision rules — not all business rules but at least some form of rules (decision rules).  It's nice to identify/isolate the rules and not mix them with the process things.  This will make our processes a little simpler, easier to deal with.  They have different concerns — there is a separation of concerns.

Third:  If we isolate these decision rules, we'd better do it in a good way, which is a reason to create a model of these decisions.  That is the reason behind the Decision Model and Notation work.  We need to model these things — maybe by different people than the ones who do the other things.  These are special capabilities, special things, and (of course) this includes decision tables and includes dependencies between decisions.

Number four:  I don't have to explain this.  Good decision tables (and you know I make a distinction there!) — 'good' decision table methodologies and models are a proven technique, existing for a long time.  It has taken me a few years to convince Ron that this is very important, but now Ron is convinced and does a good job spreading the word.

Number five:  These are on the same level.  Rules, processes, decisions — one is not at a lower level than the other.  Processes do not "contain" decisions, which are somewhere below, in the basement.  We have equally-important separation of concerns.  We should split processes, rules, and decisions, dealing with them at an equal level.  That is also what you will see in the standardization efforts:  the BPMN, the DMN, the vocabulary/the glossary (SBVR), and so on.  Number five is rather obvious, but it is an important observation.

Number six:  Again, Ron will agree.  There are many more business rules than decision rules — many, many more.  Of course, if you only have a hammer, everything looks like a nail, and you try to solve everything with one technique.  But that won't work.  We still need to separate rules and processes; we need to separate different kinds of rules, and decision rules go into these decision things.  (I'm sure James will agree also.)

Number seven:  Here things become a little more tricky.  Sometimes the distinction is not that easy — sometimes the entire process contains many decisions (or is itself a decision), for example, the process of making a decision (the process of deciding if a customer is of this or that quality).  Sometimes the entire process is a decision.  When we have this, things become a little more difficult because … is this James' area, or is it Roger's area, or is it my area, or Ron's area?  How do you separate them?  These are hard issues, I think.  Regardless, we should work together.

Finally:  If you attended Jim Sinur's presentation, you heard that there is a spectrum of processes and flexibility, from very straightforward to intelligent.  There is a Gartner picture for this, but you can draw it in other ways, from rigid processes to intelligent processes.  I would call this a process/rule continuum, and we are somewhere on this continuum.

And for my last slide and my final observation:  We are probably talking about the same thing but from different angles.

Roger's Observations

When I was first asked to be on this panel I wondered why, being that I'm the person who knows the least about formalizing decisions and formalizing rules — and I certainly know very little about the OMG notations coming up.  But I do think I have a little bit of common sense.  And I have to say that I agree with most of the things that Jan said.  Even though he's coming from a different point of view, I think it's a perspective that I really share.

What I'm going to talk about is:  How should we think about decisions?  By that I mean business decisions, of course, because if you don't put the word 'business' in front of it, Ron does ostracize you from anything he's doing.  I actually thank him for that because when we were doing the Business Process Manifesto (our Manifesto was inspired by the Business Rules Manifesto and he was one of the people working on that), he made sure that we paid attention to that.  He was one of our early reviewers and he pointed out, "You have to use 'business' everywhere.  Otherwise people will confuse it with any-old-process."

RON:  And by the way, I'm the Business Rules Guy, not the Rules Guy.  Where are you, Kristen?  You're fired!

KRISTEN:  After I submitted that, I knew you were gonna kill me on that one. <laughter>

ROGER:  Let's talk about how we can think about this.  Can we agree that every business must do the following things?

• Have a reason for its existence.  (It doesn't mean they all do!)
• Satisfy the stakeholders.  (Yes or no)
• Actually do some work.
• Make some decisions. (In the doing of the work)
• Be capable.  (Be able to do all that)

It's a little bit of common sense, but I think the point here is that the work, the decisions, the stakeholders, and the rationale in the first place — they all have to work together.

And so those decisions have to support the strategy of the organization and the mission of the organization and the requirements of the outside world.  Can we all agree with that?  Yes??  Hands up!!  We're all good?!?  Excellent.  (This is the only exercise you're getting today.) <laughter>

So, who cares about decisions?  Who are the stakeholders?  Customers, owners, and staff (especially) care about the decisions. 

The customers:  Their interests are things like approvals.  There are a lot of emotional attachments to the decisions that get made.  Your decision to do things for them — to grant new credit, for example — could be a very emotional thing.  Think about going to a restaurant and every one of your credit cards gets rejected, in front of a group of people that you invited out for dinner.  That's not just a decision — that's a very emotional situation in your life.

Did this happen to you yesterday? [to Jan]  Okay … well. <laughter>  Well, it was not an emotional decision if the whole thing was a ploy to get someone else to pay the bill. <laughter>  So, you have to come back to "What's the motivation behind all of this?"

Also, there are a lot of life-changing decisions that are made.  We heard some of this earlier:  to get married, to have kids, to have a job that puts you on the road, to have a job in another city….  These are very life-changing things.  And, I've talked about this, some decisions are very embarrassing.  I would say, "What was I thinking?"  Except we are in Las Vegas so it's okay.

The owners have a strong interest as well.  They have interests in the decisions:  "Should I spend money on something?"  "Should I assume a risk associated with something?"  "Will it affect my revenue?"  There are decisions around resource allocation — huge decisions around what things to fund and what not to fund in an organization. 

For the staff, there are all sorts of decisions about:  "What should I communicate? … Should I communicate what I'm thinking to my boss?"  "How much decision-making authority do I have?  What are my constraints?"  "What are the criteria by which I do things?"  In my opinion, people are very, very interested in the decisions that get made. 

So, here are some decision insights.

Decisions change the states of relationships.  From a process point of view, one of the main things we look for is a state change.  If there's a state change that means there was a process that made a decision that changed that state.  In other words, one of your kids decided to apply for a university.  Before they were an applicant; if they got accepted, now they're a student.  So, it actually changes the state of a relationship that you have.

Decisions also change the states of products and services — going from a "good idea" to a product or service that might work and be put into the marketplace.  Decisions change the states of business resources, from a technology that's a great idea to one that's implemented. 

And decisions are executed during business processes — this is one of the main points I want to make here.  Decisions are not "outside" — the diamond is not a decision!  The diamond just gives you a path to follow once you've made the decision in the process that precedes the diamond.  Are we clear on that?

In summary, there are a lot of things driving us:  stakeholders, organizational goals, and so on — all affect the decisions we make, and sometimes it's hard to make the right decision because you've got competing criteria to do so.  So, some processes (exactly as Jan said) are pure decision processes, where the decision is the outcome of value:  approved / rejected?  Some have embedded decisions that determine the path you're going to follow in order to get there, and the rule sets guide the decision-making.  So, here again I agree with Jan that processes and rules and decisions should be independent.  And smart processes — Ron's term — externalize rules and reference data, to enable flexible changes, in order to enable process innovation.

Here are some guidelines:

• Do not miss decisions as a key architectural concept.  We need to understand them architecturally.
• Do not miss the role of business processes in decisions.
• Link the rules to the decisions in processes, not directly to capabilities.

I needed to get another plug in for that — sorry! <laughter>  So, James, you're next.

James' Observations

I'll begin with a shameless plug of these two books — because in those books we made a fundamental assertion (Neil and I in the first one, Smart Enough Systems, and myself in the second one, Decision Management Systems) which it is that the way people perceive you —  the way they think you're a good company to do business with, whether they like working with you, what they think of your product — is all dependent on the decisions you make:  What price are you going to offer?  What service are you going to give somebody?  When are you going to cut somebody off?  When do you offer them credit?  Are you going to accept Jan's credit card for dinner?

Those decisions — and how good they are, and how good they are perceived to be, and how targeted they are to customers — all this is what makes people think of you as an organization they want to do business with.  It doesn't matter when you know something; it doesn't matter how much you know.  It's what you do with it — how you act.  It's not enough to know; we have to act.  And when we act, we make decisions.  It's those decisions that determine what people think of us.

What I find is that there is a regrettable tendency of most folks to think of decisions like this:  "Everyone knows what decisions are!  We don't need to talk about them."  Look at BI [business intelligence] projects.  How many of you are doing business intelligence projects? <show of hands>  A few.  Okay.  Most BI projects seem to work on the principle that if enough money is spent on BI, decision-making will improve.  No one is ever really clear which decisions they're going to improve, or how they're going to improve the decisions, or what that means "to improve a decision" — but they're sure that if they spend enough money on business intelligence, decision-making will improve.  Of course, it doesn't.  Because if you don't really understand what your decisions are, you're not going to be able to improve them.

So, we've found — again and again — that by getting people to focus earlier (I'll say "first" to be provocative) on business decisions you get a number of things. 

First, you get a dramatic reduction in the complexity of your processes.  This is what Jan was saying:  that if you avoid embedding decision-making in your processes, you can increase the rate at which your processes run straight through (or "do it right the first time") because you have more control over the decision-making that's going on in your processes.  And they're more agile because you can change the decisions independently of changing the process.  If you look at a lot of large organizations, they have big stable business processes that don't change very often — your order-to-cash process may be very, very stable but your discounting strategy is not stable.  The decision about the discount changes all the time, even if the order-to-cash process doesn't.

Secondly, we find — again and again — that people try to capture their rules, and they don't understand the decision rules enough (and I'm focused very much on the decision rules here).  Because they captured the rules first, they don't have as good a handle on how done they are, how many rules they have, where they can put them.  By understanding the decisions at the beginning — by being explicit about that decision-making — it's much easier to say, "How many rules do I have?" or "Am I done yet?"  Am I 80% complete … 90% complete?  Do I have all the rules I need?  And to say:  What kinds of rules do I need?  If I'm going to make this kind of decision — if I'm going to make a yes/no decision — I had better have rules that are going to help me make a yes/no decision.  It does me no good to have rules that know how to 'count', or return a string that's not "yes" or "no" because I can't use those in that context.

Thirdly, 'agile' is out there.  More and more companies are abandoning 'waterfall' approaches.  They're trying to be more agile; they're trying to be iterative.  I come across far too many projects that think they have to get 100% of their rules, or 100% of their analytics, finished before they can deliver anything.  That's a waterfall approach — let's get all the analysis done and only when I'm done with every single piece of analysis am I going to code anything.  Waterfall doesn't work; we have to be more responsive.  And that means we have a mechanism for defining what our iterations are going to be.  The great thing about decisions is that they break down into smaller decisions, more granular decisions.  And so you can build iterations; you can deliver this part of the decision-making, then this part, and then that part.  And then use that to drive successful business outcomes.

Finally, analytics, Big Data — these are becoming hot topics in the world.  How we make decisions is no longer driven only by what we have written down in our policy manuals or what we have in our heads.  We're trying, increasingly, to use data to drive our decision-making.  And, again, if we don't have a way to formalize what those decisions are, to model them, to understand them, then it's very hard to see how we're going to apply Big Data.

I was just giving a presentation and I told this story.  There's a guy I met once, years ago, at a paper goods company, and we were trying to sell him a CASE tool.  He said, "We're a paper goods company; we turn trees into toilet paper.  So tell me how your tool is going to help me turn trees into toilet paper more effectively.  Because if you can't do that I'm not going to buy it." 

There's a tendency with Big Data to have a bunch of people who say, "Oh, do Big Data and find out how your company can become the next Google!"  Well, I have bad news for you.  Your company is not going to be the next Google.  If your company is a paper goods manufacturer today, it's going to be a paper goods manufacturer tomorrow.  So, what you really need to do is see how you can use Big Data and analytics to improve the decisions that (as Roger pointed out) map to the goals that manage your business.  You have to focus on decisions if you're going to apply Big Data effectively.

So, for all these reasons it's really helpful to build and understand a solid model of your decision-making.  And what you'll find, when you try to do this, is that existing techniques don't work as well as they might. 

• It's hard for business people to use existing techniques to deliver an effective model of their decisions.  If they're not careful, they do rules and they end up with (what I snarkily call) the "big bucket o' rules" problem:  I've got lots of rules — they may be good or bad rules, they may or may not be well written.  But they're just a big bucket of rules.  This happens because business users sometimes get very excited about rules and how great they are and say, "If managing some rules is good, managing all my rules must be better!"  And so they go off and try to capture all their rules in a very, very undirected way, which just creates this big bucket o' rules.
  
  
• Process models:  If you try to model decisions in processes you get horribly complex processes.  And if you don't model them in the process then you get a 'black box' — you get a task that says:  "Decide X."  But you don't have it written down anywhere how you decide X. 
  
  
• Requirements:  Again, they tell you that you need to make a decision.  They don't really tell you how you're going to make a decision.  It's very hard to describe the 'how'.
  
  
• Lastly, if you just focus on your technical architecture you might identify that you've got a decision service in your architecture.  But, again, it doesn't really say how, from a business perspective, we are going to make that decision.

So, you need a set of techniques that will let you document what information you need to make a decision.  Because that's important.  That will let you identify the know-how — the knowledge that you need to apply, whether that's analytic know-how or procedural, policies, regulations, expertise.  That will let you define very precisely how you make these decisions so you can document them, have business people understand how these decisions get made, but not get sucked into too much technical detail.  And, lastly, that you can use them to say, "I'm going to automate this part of the decision, but I'm going to let Jan do that part of the decision."  "I'm going to automate this whole decision 80% of the time, but 20% are exceptions — then I'll make this other decision to handle those exceptions."  You've got to be able to draw those boundaries, and that requires an understanding of the decisions.

Like Jan, I'm part of the submissions team for the Decision Model and Notation standard.  This is an example.

You can see where you're getting your rules from; you can see what groups of rules you're going to have; you can see who owns these things and how they're going to change and how often they're going to change.  All that is clear because you sat down and said, "These are my decisions and here's how I want to make them."

And I'm out.  Ron, of course, is going to go last and contradict us all. <laughter>

Ron's Observations

I'm going to talk about three major myths of the business decision space.  And before I launch into that, I want to be very, very clear that I'm only talking about operational business decisions.  I'm not talking about strategic business decisions; I'm not talking about software design decisions.  I'm not talking about process decisions.  There's a lot of confusion out there.

As I said this morning in my keynote, there's a lot of valuable stuff coming out of the decision space, the thinking that launched about five years or so ago.  James, is that right?  James had a big part in making that launch happen.  So, that's good.

We have really identified additional techniques that are very effective.  I won't go into my Chinese store issue, but I bought a ton of Empress Tea that cannot be imported into the U.S.  So if anybody would like some Empress Tea I have a supply.

Secondly, decision tables are great.  Jan didn't teach me everything I know about it but certainly has been instrumental in making that happen.  There's no question about it; everybody, every business analyst, should know about decision tables.  But don't let anybody fool you.  They are not as easy as you think.  They require a lot of knowledge about scoping and about what questions you're asking and about how to define the vocabulary and the semantics and which format works best for a particular problem — which things business people find most friendly.  There are a lot of things to know about that.

Ok — Major myth number 1:  All business rules lead you to a decision.

That's just fundamentally false.  It is just not the case.  And the reason is because there are two fundamental kinds of business rules.  I'm not just making this up; this is the work of standards — SBVR (Semantics of Business Vocabulary and Business Rules) from world-class logicians and linguists and software engineers, working over many years' time and basing it in solid logic.  There are just fundamentally two different kinds of business rules.  And they have very different characteristics.

There are decision rules — and those are the type that really fit in effectively with decision models, decision structures.  They are about creating knowledge, choosing between alternatives, making business determinations. 

But then, as I said in the keynote, there are behavioral rules, which are fundamentally about the behavior of people and compliance, and the fact that people and organizations can violate rules.  That is a very different matter.  When you start talking about the fact that people can violate rules, that makes all the difference in the world.

Second Myth:  A violation of a behavioral rule corresponds to a business decision.

That's just wrong.  That's false. 

Let me give you an example.  "A customer who has ordered a product must have an assigned agent." 

All right, now think about that behavioral rule very closely.  Obviously, it has to be enforced upon the event when a customer orders a product.  There has to be an assigned agent.  But suppose that one of our agents decides to retire to Las Vegas.  That's his personal decision — it is not a business decision that he retired.  (Well, sometimes we 'retire' people and it's a business decision but that's not what I meant.)  Let's suppose that the agent decides, of his own volition, to retire.  Hey, that is just an event.  It just happened.

And the rule says:  If we have any customers who have ordered products that that agent is assigned to, we have a violation.  We have an event that has produced a violation … a situation of state of affairs that is incorrect for our business.  And we need to respond to that.  There's no decision in that; there just needs to be a response, a planned response.

Third Myth:  The business rule space and the decision space are exactly the same.

This is just not true.  It is fundamentally different.  I wish the world were this neat and clean.  I wish it worked out more nicely.  But it is just not the case. 

Let me finish off by explaining why.  Here's how I view the business rule space — again, based on the standardization work and a whole body of knowledge that goes back to the Business Rules Manifesto and long before that.  It's very clear that there are two fundamental kinds of rules. 

There are behavioral rules, which are about governance, and people can violate them.  And there are these rules about the production of knowledge, and those are derivation, computation rules, and those are the kind of rules you find in decision tables.  That is the business rule space.

Now, characteristic of the business rule space is that you always need to express these rules in words.  One way or another, there needs to be vocabulary.  And you need to know what those words mean.  Why?  Because you need to communicate it, and you need to have traceability when they're violated.  That's just the nature of the beast.  People are going to regulate you; they're going to test your compliance.  They need words.  You need words to go by.

Business rules are never probabilistic.  It's never a "maybe"; it's never "on a scale of 1 to 10, it's .7 that this might be true."  It's just not like that.  Business Rules are definitive; they give you definite (or correct, or best) answers. 

Thirdly, business rules (even decision rules) are about, ultimately, rules that people can violate.  Organizations are made up of people; people can violate rules. 

Now, the decision space looks like this.  

This is just a very rough cut, and, frankly, I don't think we know enough about the decision space to fully map it out yet.  I think we're still learning about it.  But I'll divide it into three major parts: 

There are deterministic decisions where there's a "right" answer.  And for that, consistency, compliance, and traceability is the key. 

There are inferential decisions where there is a "best" answer.  Now, most of the products on the market today that play in the rules space — rule engine space — come from expert systems, and that's why I'm using the term 'inferential'. 

And then there's a whole other class of decision problems which is huge, which are probabilistic in nature.  We don't even know if there is a "right" answer, or even a "best" answer; we'll be happy if you can just find an answer.  And we don't really care how you get there.  Here you're going to find your math whizzes and your data scientists and so on.

Do these spaces overlap?  They do; but they don't overlay neatly.  That's the business rule space; the overlay, the decision space, and it looks something like this. 

Now, what is the "great divide"?  What is the big difference there? 

Well, on the left the reason why the rules have been violated (or why the answer is what it is) always matters.  You need to trace why you get the results that you do.  Words matter.  The rules have to ultimately be based on words, even if they're in a decision table. 

On the right, you don't really care why.  They could be algorithmic; it could be anything. 

So, there's a great divide there.  It all depends on whether you need to know why you get the results that you do.  These are two very different spaces.  We think why is important.  That's why we focus on business rules.

Panelist-to-Panelist

[KRISTEN]   Alright.  Well, you all seem to be very much in agreement on a lot of things.  But, do any of you have a particular rebuttal to anything you heard?  I'll give you just a minute or two.

ROGER:  I have one.  When James said that decisions are first — I think we all say that whatever we do is 'first' and a good question then is:  How do we find out what those decisions are unless we have some framework to sort it out, to avoid the "big bucket o' rules"?  How do you know you have all the rules unless you have some other thing — which I might suggest is 'process'.

JAMES:  Yes, I would say, in response to that and also in response to Ron, that there are two distinct patterns for decisions that we find come up.  There's a process that has a decision within it, and then there's an emerging event-decision-action pattern.  In this latter case an event happens; a change of state happens; I have to decide what action I'm going to take.  Maybe it's completely mechanical — whenever someone retires, we always do this — but probably I have to decide which of my agents I'm going to assign in place of the person who's retiring, so there's an event-decision-action pattern.  There's no process, but there's an event.  In either case, the point is that there is a context.  I would agree with you on that.  But it's not necessarily a process.

One observation, as someone who spent years in the financial services industry, is that there's a whole raft of probabilistic decisions like (for example) credit risk that are utterly regulated and you'd better be able to say why you turned down this person for credit, even though the reason you turned them down for credit is that they, probably, are a bad credit risk.  You still have to explain why you think they are probably a bad credit risk.  And so the why thing doesn't necessarily go away just because you're into the probability arena.  I understand what Ron was getting at.  Sure, nobody cares why they turned Jan's card down — they just turned it down.  (ROGER:  except Jan <laughter>)  Jan cares, but no regulator is ever going to ask why.  But if they turned him down for credit, then a regulator would want to know:  "How come you turned Jan down for credit?"  That's something you have to be able to defend.

So, probabilistic decisions vary on the why-factor.

RON:  Okay.  With respect to Jan, I think that even highly-structured processes always have business rules and decisions — I don't know if you were suggesting that they don't.  (JAN:  They do.)  For Roger, a lot of times that process isn't modeled.  There is a process, but it isn't modeled.  (ROGER:  Absolutely!)  So, that's just something you have to keep in mind.  To James:  Strategy comes first.  It should come first.  You have to know what your goals are; you have to know what the risks are; you have to set your policies.  If you want to win, strategy comes first.  Not decisions — strategy.

And then I would say, for all of us, is that none of us spent any time defining what 'decision' is.  So, we got away with a lot here.  I think if we really dug into it you would find that there are some very big differences in opinion on what a decision is — or at least the range of things that can cover.  We're getting away with something, probably.

ROGER:  Is that not defined yet in the Manifesto you have?  I would assume that a definition of the term 'decision' would be in there.  Is that true?

RON:  The Manifesto should define what the word is.

KRISTEN:  Can someone look that up?

JAMES:  Does the Agile Manifesto define the word 'agile'?

RON:  Well, the agile people are on their own.

KRISTEN:  Okay.  So are we ready to open it to the floor?

JAN:  Can I just have a minute to explain why my credit card was refused? <laughter>  It's a process thing.  (ROGER:  So you're going to blame the process people for your credit card problems?)  No.  It was the credit card people.

KRISTEN:  I don't have a roving microphone so if you can please state your question as loudly as you can.  And I'll begin with this gentleman here.

What does 'KPI' mean in the context of making a GOOD decision?

[from the audience]   I understand that I have processes requiring decisions that may use rules and that may use decision tables for these rules.  But the question that I have is about the concept of making a good decision, by which I mean that I have to look at the KPIs and the impact.  I've been in sessions with each of you, and I see a lot of difference in how each of you approaches KPIs.      When I went to Ron's session, you talked about KPIs in the context of a policy charter and asking:  "Are my rules advancing the KPIs the policy charter has?"  When I went to Roger's session, it's KPIs in the context of stakeholder needs and process outcomes.  And in James' session it was about the concept of mapping decisions to KPIs and how the decisions impact the KPIs.  (And I'm sorry — Jan, I didn't get to any of your sessions.).      This seems to me to be a lot of different approaches to KPI.  What do each of you think about the other person's view?

ROGER:  I'll start.  First of all, I think KPIs are something that everybody thinks are going to be easy.  It's probably one of the hardest things to do.  It's just a proxy for what you're looking for — always — some indicator associated with that. 

I'm an outside-in person and I would always say that you need to understand what's important to your stakeholders and how you're going to then measure that.  One of those stakeholders is the owners.  And one of the things the owners have is a strategy.  And so, in that strategy, there should be overall Key Performance Indicators.  When we make a decision, inside a process, I would put it this way:  If you have a good decision-making capability then your process should actually perform better; if you have a bad decision-making capability your process will not perform as well as it should. 

So, I think that if you're dealing with rules or process or so on that you have to look at where they're used and see if a better one should give you a better result that you're looking for.  This comes right back around to strategy, which Ron was saying.

JAMES:  First of all, there's a point Jan made at the very beginning:  that the value of some processes is very much in their decision-making capability.  For other processes there's a lot of process value that's independent of the decisions.  And sometimes there's a mix.

So I think that you can clearly make a good case for saying that it's worth understanding the impact of both process and decisions on KPIs.  The reason I like to focus on decisions and key performance indicators — and not just key performance indicators but performance indicators (more individual ones) — is that if you think about a good performance indicator, it is designed to motivate behavior.  That means you must (or the system must — somebody must) be able to change it.  Because if you can't change it, it's not a valid measure for your behavior, right?  If you work in an oil company, sure I could hold you accountable for the price of oil, but there's nothing you can do about the price of oil.  So, that's not really very reasonable.  But I can hold you responsible for on-time delivery, and such things. 

The idea is to motivate your behavior —  motivate people's behavior — to improve.  In other words, they must be able to make choices, that could be good or bad, relative to that key performance indicator.  It must be possible to identify the decisions that get made and say, "Good decisions will move these performance indicators in a positive direction and bad ones will tend not to." 

Many decisions have to be made in the light of multiple performance indicators, and I would like to know what those trade-offs are before I make my decision.  I can't just retain every customer because I want to retain profitable customers more aggressively than unprofitable customers.

ROGER:  So, James, how would you deal then with automated decisions?  Where's the motivation?

JAMES:  Because you're trying to write the rules, or build the analytics, such that you get an outcome that's more positive.  So, if I'm an analytics team and I'm building a predictive model to predict whether a shipment's going to be late or not — because on-time deliveries are important to us and I'm trying to pick a shipper that's more likely to be on time, in part by predicting which shippers are likely to be late.  So, what I'm doing is:  I know what my motivation is, now, for my predictive analytic (or my rules) — it's to make a decision that's going to have a positive impact on the KPI.

So, yes, the system is not motivated by the KPI but the organization is.  At least, Watson might be, but none of the others are. <laughter>

RON:  Can I have a say?  There's a big misconception about strategy.  Strategy is always important, no matter what the scope you apply it to.  Strategy just means you know what the goals are that you're trying to achieve, you know what the constraints are that will prevent you from achieving those goals, and you know where your thresholds of pain are, so you know how to balance between the goals and constraints and so on.

That's what strategy is.  And it applies at any level.  A lot of times people, when you say 'strategy', they're thinking "strategic planning" of the whole business.  We never use it that way, just because that's not what we do for a living.  Instead, we are generally trying to create the strategy, optimize the strategy, for one business area that we are re-engineering, whether it's one process or whether it's one capability … or, it could be, one decision.  You need to know what is the strategy that that decision has to conform to.

So, there again, what are you back to?  You're back to:  What are your goals?  What are the constraints?  Where are your balance points?  And then how do you measure where you are in that context?

There are some very sophisticated tools out there, by the way, that do optimization around explicit goals and so on.  We're just beginning to scratch the surface.  But the notion of strategy — it's strategy.  Strategy applies in all those areas.

KRISTEN:  Next question?

Which comes first?  Decision or Strategy?

[from the audience]   Both Ron and Roger mentioned strategy a couple of times, and both have fallen into a trap.  Ron said that strategy comes first and, actually, strategy follows several decisions.  And that leads to the trap that Roger fell into, when he said all we have is strategy.  Unfortunately, that's not always the case.  Often all one has is a dream.  And there are some decisions that need to be made to decide how to go about approaching that dream, to turn it into reality, that leads to those strategies.  So, I'm not sure how that resolves.

ROGER:  I would agree with what you said.  I think there's a big difference between strategic intent and strategy.  In other words, defining goals and objectives are not strategy, but the question is how are we going to go about doing it.  Strategy is the 'how' against the dream.

RON:  With respect to decisions, here we see how part of the problem is that we didn't define the word 'decision'.  When I use the word 'decision' I'm only talking about operational business decisions because I'm interested in how work can be conducted more intelligently, in a more correct manner — repeatable —  and the know-how is not lost when someone leaves the company.  Those things that you said are decisions that precede strategy?  Okay, yeah, see — that's the problem.  Decisions are everywhere.  If you just say "decisions" that's too easy.  You really have to say what kinds of decisions you're talking about, in order for us to talk intelligently.

AUDIENCE:  I'll agree with that.  Strategy is a prerequisite for operational decisions.

RON:  Yes, absolutely.  So, you have to know what kind of decisions you're talking about. 

KRISTEN:  Okay.  Next question?

Do you distinguish between making a decision and the process of making a decision?

[from the audience]   Is the process of making a decision the same concept as making a decision?

JAMES:  I think this relates to Ron's point.  When you're talking, as we all are, of repeatable decisions — when we talk about how we make a repeatable decision, we're talking about, essentially, the definition of how we're going to go about that:  our decision-making approach, not a specific instance of that approach.  It's not why or how did they decide to turn down Jan, but how do we decide which credit cards we're going to accept.  So we're using it as shorthand for the class of decisions known as 'credit card approvals' rather than the decision about Jan as a credit card approval. 

We're all talking about it this way; just like when we talk about "a process" we're not talking about some instance of a process.  (ROGER:  It's the design of the process.)  Yes, we're talking about designing the decision-making approach — to document or describe in rules the decision-making approach.  We're not trying to document a single decision.

It's interesting when you meet people from the society of decision professionals who are focused on "How do you do tradeoff metrics for a singleton decision — today's decision?" — it's interesting how different their perspective is on some of these things.

JAN:  Even the word 'process' is not always well-defined.  What you are referring to is the steps of making a decision.  But a process — the business process — is much more than just the steps of doing.

RON:  Can I ask the panel a question?  (KRISTEN:  Sure!)  I think this question will shed some light on some differences of thinking.

Those of you (especially) who are on the Decision Model and Notation standards team:  When you say 'decision' do you mean the act of making the decision, or do you mean the result of the act?  Which is "the decision"?

JAMES:  We mean the first — the other is an outcome.

RON:  You know, there's a really important question.  Ask yourself, from a business perspective, would the business person (business people, stakeholders) think of the decision as the act, or do they think of it as the end determination that is made from the act?  Frankly, I think the standard has it wrong.  (ROGER:  That's why you're sitting in the middle, by the way. <laughter>)

JAMES:  I have business users who go both ways.  It depends on the decision, to some extent.  If the decision is a yes/no one then they very often are not clear about the distinction.  And if the decision is more nuanced then typically they are more clear about the act of making the decision being different from the choice they make.

RON:  So, sure — if you take every yes/no question in the world as a decision, yes, I can see how you could come up with that.  But, you know where you're going to be if you do that?  Remember your "bucket of rules"?  You're going to have a "bucket of decisions"!  And it's going to be worse. <laughter>

KRISTEN:  Oh, I think we've got fightin' words going on here!

JAN:  Anyway, we have a subject for tomorrow morning at 8 a.m., which is about the standard.  So everyone who is awake at 8 (I'm not awake then but…)

JAMES:  I've just tweeted that tomorrow it's not decisions first, it's coffee first.

ROGER:  When we were pulling this conference together and we had these discussions, I said, "Are we kidding ourselves?  Who's going to show up at 8:00 in the morning in Vegas? (unless they just stayed up all night)"

KRISTEN:  Okay.  I see another hand up over there.

How do events and processes and decisions interrelate?

[from the audience]   This is the general picture I think I'm hearing:  We have events occur, and then you utilize the business rules to decide who is responsible.  The processes should incorporate your KPIs, and these processes themselves should make the decisions — having a process that can deliver the decision, based on the events that occur.  I'd like to hear the panelists' feedback on that understanding.

RON:  I'll give you feedback.  The fundamental word in understanding  process is always the word 'transform' — transformation.  If there is a transform, there is a process, whether it's modeled or not.  So, the way I would look at the decision logic is:  It doesn't do anything.  (JAMES:  Right.)  Business rules actually don't do anything.  They are not about what you should do; they are guidelines to follow.  The Ten Commandments just says, "Thou shalt not kill."  It doesn't tell you what to do as a result. 

The process is making the decision, but the idea is to separate the logic so that you can evaluate the logic separately.  Then, at the time you invoke it, it is evaluated and it gives you the determination.

JAMES:  I'd say the same thing but a little bit differently.  I would say that decisions don't do anything; I agree with Ron on that critical point.  They just tell you what you should do (what you can do, what you might do).  It's the process' job (or the event processing system's or the legacy system's job) to say, "Okay, now I'm going to go do whatever it was that I was told to do." 

RON:  So why does the standard call it "the act of making a decision"?  That sounds like a transform to me — "the act" — how can you act without making a transform.

JAMES:  The decision logic has no ability to change things; it just returns a value. 

RON:  …"returns a value"?

JAMES:  It answers a question.

ROGER:  I think what the process does is this:  Based upon those decision criteria, the process will change a state of something.  And so it's that state change … Ron talks about transformation.  One of the transformations in the process is actually to accomplish (or realize) a state change — or not, if you fail on the decision.

KRISTEN:  I think we have time for one more question.

Will the various techniques we've heard about this week become even more specialized, or do you see a convergence?

[from the audience]   I understand different business problems require different approaches.   Will the best of these approaches continue  to define (refine) individual areas of specialty, or are we working toward a convergence?  Do you see these conversations moving us toward convergence?

KRISTEN:  Did everybody hear that?  Are we still continuing to be very divided — because each of these charming gentlemen are very specialized.  Or do we need to converge these things and make them all work together?

RON:  The first thing is:  We have to decide whether we're talking business or whether we're talking systems and platforms.  And the new standard doesn't do that.  That's a fundamental step in the wrong direction.  For all the other things that it might do that are good, it does not help us from a business perspective — if you focus on operational business decisions, it doesn't help convergence.

ROGER:  So, I think we all know now that Ron has some suggestions for improvement in the standard. <laughter>  But I would actually say:  When we put this conference together for this year, we decided that all these things need to come together and converge and be used as intelligently — make the right combination and be used with one another.  So, I would think that if you're an analyst or designer or architect, we've got to use the set of tools, working together, in some integrated, common sense way.  I've always felt that you cannot have a functional solution to a cross-functional problem.

JAMES:  Right.  I would agree with that.  I think there's value in the different approaches.  They have different characteristics.  Some problems require you to be really, really good at understanding and modeling and business processes; lots of other problems require you to be able to do some business process modeling.  So, I think there's value in understanding how these pieces fit together.  That doesn't mean that everyone has to be an expert at everything.  But it does mean it's worth knowing something.

RON:  I'm all for synergy … when the time is right.  The time is not right yet.

JAN:  But we don't have to solve everything this year — because next year we have another conference. <laughter>

KRISTEN:  Okay.  One last comment.  We are running out of time.

JAN:  I use tables in rules and processes and in decisions.  So I'm already integrated. <laughter>

JAMES:  And I would just add that, contrary to what Ron said, I've already used the Decision Model and Notation modeling notation to successfully build models of human, manual decision-making that they had abjectly failed to describe using rules.  So, you can use it to describe manual decision-making; you can use it to describe system decision-making.  It's simply not true that you can only use it for systems stuff.

RON:  That's not what I said; I never said that. 

JAMES:  Well, that's what I heard.

ROGER:  Please take it outside.

KRISTEN:  Yes, I think that's it.  We'd better take this outside. 

I want to thank our illustrious panel for all their comments. <applause>  And thank you all for your attendance.

# # #