Panelists

Aaron Gary, Systems Development Manager, People Magazine

Arne Herenstein, Vice President Application Services, OneBeacon Insurance

Bill White, Senior Subject Matter Expert, Department of Treasury

Charlie Thacker, Sr. Manager, Customer Data Solutions, IBM

Ernie Eichenbaum, VP Industry Solutions, SSA Global

Mark Myers, Manager of Compliance Systems, California Independent System Operator

Ron Ambuter Vice President -- Customer Service Technology, JPMorgan Chase Bank

Steve Lindstrom, Project Director-- CRM Business Rules, Allstate Insurance Company

Moderator

Gladys S.W. Lam, Principal, Business Rule Solutions, LLC

.

Introductions

Gladys S.W. Lam   I'm going to get started because we really have an exciting program this afternoon.  Welcome to the Practitioners' Panel discussion.  This is the audience participation part of the Forum.  In this session, we always have a lot of fun and learn a lot. This year I am especially excited because we have put together a great group of panelists.  I have talked with each one of them.  Together they have lots of experience with different tools, different methods, and difference factors on their projects.  So I don't want to spend too much time in the introductions, other than telling you how we are going to run this session. What I would like to do is ask each of the panelists to introduce himself.  Then what I'm going to do is start off with a few questions.  These are questions that I have heard in the past; these are questions that I get asked all the time and I would like to direct them to the panelists.  But this is YOUR panel discussion.  So feel free to jump in any time with your hands raised, and I will come with the microphone so you can ask your question.  We have a vast wealth of experience here to answer it. What I would like to ask each panelist to give:  your name and company you work for, something about your business rule project, and what tools you have or methods you use.  Then, also give a couple of your own "DOs and DON'Ts" based on your own business rules experiences. Charlie, how about if we start with you?

Charlie Thacker

My name is Charlie Thacker, and I work for the IBM Corporation.  I have been in the IT world for about 30 years, and I've been with IBM for 26 of those 30 years.  In the last 7 or 8 years I've been involved with the CIO's office of IBM, dealing with data architecture, data management applications, and integration projects.  So I've had quite a bit of experience.  For the last 4 to 5 years we've been using various rules engines.  About 3 years ago, we started moving to a more formalized methodology for the specification of the business model.

For my DOs and DON'Ts:  One of the key things you DO want to do with business rules -- this is the thing I mentioned to Gladys earlier as a good way to 'get started' -- is to use the business method approach.  Business model your own organization so you can understand the why -- why you are doing your business rules in the first place.  In other words, ask "what's the real purpose for that?"

We learned this by accident.  We brought in a company -- Business Rule Solutions -- to help us develop our methodology for business modeling and we used, as an example of a business model, our own organization.  The policy charter we developed out of that exercise was a great thing for us.  We understood what we, as a transformation IT organization, had as our own business rules.  Because we did this, we are can better position ourselves in terms of understanding why business rules are important to us and why the method itself is very important.

The DON'T:  Make sure you have business sponsorship.  I know that sounds like a DO!  But if you don't have business sponsorship you are leaving yourself open to a lot of problems because this is fundamentally a business approach -- you are changing the business.

Arne Herenstein

I'm Arne Herenstein.  I'm with OneBeacon Insurance, with the business application software development group.  Insurance is a set of rules -- you are eligible to have insurance, you are priced, you are rated, you are credit-scored, you are quoted, you are determined to be fraudulently claiming (or not).  And every one of these is some a set of rules.  We've been doing that now for some time.

Our most recent business rule project was to build a fairly comprehensive web version of our distribution system ... not to the general consumer but using that tool to deliver our insurance products to the agents so they can do underwriting and evaluation without a lot of interference by people slowing down the process.

For my DON'Ts -- DON'T lose sight of what the customers want.  If you make too many rules, they will go someplace where things are easier.

The DO -- what you really do want is to build what's appropriate.  Rules are business driven.  Generally our best rules come from the source that understands why they create the rules.  For example, OneBeacon has been fairly active in rule-based business fraud detection because that has become such a serious problem (rapidly replacing drugs and prostitution as organized crime's most profitable industry).  We are, unfortunately, the defacto police.  In our special investigations units, we frequently hire ex police officers, and they are our greatest source for development of rules for rules-based engines that help us identify fraud patterns before they become extensive.

So the DO is, do let somebody who understands the rules define the rules.  It's the technicians who are going to make the rules happen, but the technicians are not the ones who should driving 'how' or 'why' the rules occur.

Mark Myers

My name is Mark Myers, and I am the manager of Compliance Systems and Compliance Operations for the California Independent System Operator, which manages the electrical grid in the State of California.  We've been doing rule projects for about 3 years.  'Compliance' is really a lot of rules about managing whether people have kept their contracts or not.  (And, no, Enron did not keep all their contracts, and we've picked up some of those problems in our rules.)  We use the Blaze rules engine to implement a lot of our rules.

Our biggest DO:  do get a rule methodology before you buy a rules engine.  (I hope I made that point in my presentation earlier.)  This is a very important point.  It is about the business.

The DON'T:  don't be impatient.  It takes time to learn some of these things.  The implementation, while painful, is worth it at the end.

Bill White

My name is Bill White.  I work for the Internal Revenue Service, and I've been there about 26 years.  The first 11 years I worked in the IT organization, and for the last 13-14 years I've been on the business side.

I'm working on a modernization project called CADE -- Corporate Account Data Engine.  We've been in the development stage for about 3 years now.  We're looking forward to having this be a rules-based system.  So far we still don't have an engine, and we don’t have a tool yet that we can use.

I would have to say for the DOs:  what we found out right away was that we DO have to have common terms.  Boy, have we had some arguments over that!

For the DON'Ts:  I would say, DON'T start without a tool.

[audience] laughter

Ron Ambuter

Well, now that I know who's sitting next to me, I can't use my real name.  <laughter>  I'm Ron Ambuter, Division Vice President for J.P. Morgan Chase & Company, Chase Manhattan Bank.  I've been with them for half a dozen years, managing the customer service technology group out of the Dallas Metroplex area, on an enterprise basis.  I came to them from managing the business process practice for Cap Gemini (which is now Cap Gemini Ernst & Young), so I've been playing in this space for a good bit of time.  We're using a tool I 'inherited'; it is from a company named Pegasystems.  We've been using it in the Bank for the past 17 years or so, and since I've been there I've seen some dramatic evolution of their products.

Currently, in our group, we have a suite of applications running in Pega, with approximately 20,000 users throughout the Bank.  In our original application, I think we've calculated that there are some 130,000 decision points where a rule will make a decision about how a process should be affected.  We have 16 ongoing projects to leverage these applications out to different users, in various lines of business throughout the Bank.

DOs:  I think it's necessary that you DO look at your rules base as a corporate asset, every bit as much as some of your large datasets.

DON'T:  DON'T get started on a tool that can't take you to your end game.

Steve Lindstrom

I'm Steve Lindstrom; I work for Allstate Insurance Company.  I'm a project director for our business rules program, which is focused on event-based marketing.  Ours is a bit different from some of the work I typically see represented at these conferences, where there is a great deal of rule 'harvesting.'  In marketing we pretty much had a green-field process to begin with.  When people ask, 'where did you get the rules?' -- frankly, we made a lot of them up.

I always feel at home in the Business Rules Forum.  I would like to see the hands of all the English majors out there?  Okay, there's a few of them ... there are two.

I tried to get an MIS many years ago and I gave up because I spent too many weekends looking for missing semicolons in my programs.  But before I quit, I talked to a Dean at the school and I said, "You know, I have a different idea.  We shouldn't be teaching me how to program.  I think of all the money that gets wasted in this 'translation' process from the business people to the technical people.  THAT's the problem!  It's not how good the code is.  I've had this revolutionary idea -- what if we just 'write down' what we want?"

The Dean almost blasted out of his chair -- he said, "Yes! That's it."  He'd apparently been working on a theory about that for many years.

So, the Forum is the place.  I spent two hours yesterday in a presentation about semantics -- absolutely fascinating.  Computers are pushing into language.  They don't really 'compute' so much any more -- they 'talk.'  That's why I think this is a fascinating place to be, and that's why I'm working on that project at Allstate.

Ill have more on my DOs and DON'Ts a little bit later.

Ernie Eichenbaum

Hello, everyone.  My name is Ernie Eichenbaum, and I'm with SSA Global, which is an enterprise application supplier -- the 4th largest in the world.  We have 2 generations of rule-based applications in our heritage.

We started in 1997 when we embedded rule-based engines inside some of the software that we sell -- primarily, in order to optimize complex processes with automated or semi-automated decision points in the world of transportation and logistics, and in the world of advanced planning and scheduling.  That has been going on ever since, with increasing impact on the market.  We like to associate the words 'best of breed' with the result.  I think it would be fair to do so.

The second, more recent, project started about two years ago.  That one had to do with improving the technical and operational quality of our customers' performance through automated scans of their datasets, infrastructure setups, and their own business performance KPIs, resulting in virtually -- with the press of a button -- a fairly hefty (phone book thick) recommendation set for how they want to retool their business and reset their configurations in order to attain better competitive advantage and/or better throughput of their systems.  That project is on-going, and to-date just slightly over 800 of our customers have taken advantage of that free offering from our company.

I have a very short DO and DON'T list -- one each.

The DO is:  be sure to have clear business justification for launching such a project.  The competition today -- on the project board or for money for business cases -- is such that, unless there is a small project with very clear returns and a very short time, it is very doubtful you will be able to launch a new initiative in that area.

The DON'T is somewhat similar, only on the flip side.  DON'T assume for a minute that anyone else other than you and your company 'gets it' ... that anyone understands anything about the value of business rules or engines or automating any of these processes.  I remain with my old time belief that it is a select few people (in this country or around the world) that actually 'get' this topic.  DO NOT assume that others do.  That will help you with your business case.

Aaron Gary

Hi, my name is Aaron Gary.  I work for People Magazine -- People Magazine Group -- and I am the systems development manager there.  I am the 'new guy' on this panel as far as business rules go.  About 3 years ago I had never heard of business rules.  I was talking with a friend of mine who worked at a bank about a project that I was spec'ing out, intending to do it myself.  He basically said, "You're going to spend about a year and half building a rules engine that is already out there."  So I sat down at my computer, typed 'rules engine' into GOOGLE, and discovered there was a whole community out there.

So, we did our project using Blaze Advisor.  We built a calculator for our sales people to use for pricings so that they can quickly get information off to their advertisers.  That has been live for about a year now, and it has been very successful for us.  Now we are looking at other opportunities for our rules engine.

As far as our DOs and DON'Ts ...

DO definitely get sponsorship on your project, but DON'T just get someone who is willing to say, "Yes, this is the right way."  Make sure they understand what it is they are saying 'yes' to.  Make sure that they become a champion for what you are doing -- because IT can't be the ones who are always saying, "This is the right direction for us to go."  Someone else should be agreeing with us (most of the time).

As far as a DON'T:  this applies to those of you just getting into this like we did.  Don't try and go about this all alone.  Use the vendors that are out there for help.  We thought about going it alone.  We started to spec out what we wanted to do and then we had a vendor come in who basically told us we were going about it completely wrong.  We redid the way we were approaching it and discovered that definitely was the right way.  We would have probably gone down the wrong track ourselves and would have increased our time to delivery by many, many months.

---

Gladys S.W. Lam

Thank you all.  <applause>

Wow!  For the first time, after the DOs and DON'Ts, we've learned so much we can all go home now, right?

.

What is the ROI of Business Rules?

Gladys S.W. Lam I have some questions that I have prepared -- questions that I get asked all the time.  I will direct these to the panel.  Audience, feel free to raise your hand if you want to add to it or if you have questions of your own. The number one question that I always get (in fact, I got it in the hallway while walking over here):  "What is your ROI?"  So, panelists, do you have any 'Return On Investment' type studies -- any collections of data -- that we can use to prove that the business rule approach works? Since I have talked with the panelists, and they all seem to have experience with this, I'm going to start with from one end and ask each panelist to give his experience with ROI. But first, I see I have an audience question already...

[Audience]

This is a question for the IRS:  Why don't you have a rules engine yet?

Bill White

You know, I've asked that question many times, too!

Originally, when we started out, there were some acquisition problems.  Because of that delay, it has taken a while to get something lined up.  Right now it looks like we have an engine that we will be using, just as soon as they give us the 'go ahead.'

[Audience]

Which engine is it that you are considering?

Bill White

Sapiens

Gladys S.W. Lam

Are there any other questions for the IRS about 'rule engines'?  Do you really want them to have a rules engine? <laughter>  All right -- back to my ROI question.  Aaron, can you please start.

Aaron Gary

We don't have a lot of information on ROI.  We've only had our product out for about a year.  What we have been able to determine is that it has reduced the workload of certain people by about 30%.  Our business office people are spending 30% less of their time doing standard, monotonous pricings for our advertisers.  And instead, they are now able to do some of the more complex analysis to help drive our business.

Gladys S.W. Lam

30% -- that's pretty good ROI, if you ask me!

Ernie Eichenbaum

Seeing how in SSA we have two kinds of projects, I will start with the general comment.

ROI ... there are only three dimensions, of course:  time, quality, and money.  Relative to the first type of project we did, which was to embed capabilities into software, I have to say that that's a type of 'quality.'  I say that because now this software can do something that a thousand clerks, sitting for a month in a room, could not have done as successfully.

That in itself would not be very difficult to translate into ROI -- a thousand salaries per month, forever, is actually a very easy justification for projects of that nature.  Really, the bottom line is, it is very possible -- and in our case it is a fact -- that, using the technology that's under discussion here, you can do things that could never have been done before.  Period.

This gives a tremendous competitive edge.  And if anyone wants to translate to ROI, that becomes an exercise you would do during the break.  That's the easy one.

The second type of project, which is ongoing and has to do with customer service and support, has all three dimensions coming to bear.  Number one -- to date we have been able to provide a higher level of support to our customers than ever before.  So that would be a dimension of quality.  We are able to do so with fewer people than before -- on a larger base -- that would be the dimension of cost.  And we are doing it really in a fraction of time to resolve what we call 'customer cases,' which has to do with time.

Quantifying that is not so difficult.  And, again, back to the story of the business case from before -- if you remember the three dimensions, it may be possible to dig them out and to visualize them.

Steve Lindstrom

I'm going to do my DOs and DON'T now (that's why I saved them).

The thing that we're working on is an event-based marketing program.  Basically we did a pilot test before we implemented rules technology, and it showed significant lifts of event-based contacts over our traditional direct mail and targeting criteria.  I'll go further to say that significant lifts showed when our distribution partners (our agencies) picked up on the opportunities that we delivered to them and worked them.  And we did not get the big lifts when those opportunities were not attended to.  This has led us to our new understanding of the problem that we have set out to solve.

So this is my DO for you:  Before you embark on a project like this, think about the BIGGEST problem that you can solve.  What is it that you are really trying to do?

Our conception was that we were going to deliver event-based marketing opportunities to our agents, and we turned ourselves to the work of doing that.  (We used the Pega tool, by the way.)  We recently went into production delivering this.  But we are now looking at the next horizon, which is, "How do we evolve our agency force -- our distribution channel -- in this entire process?"  In other words, how do they get involved in choosing the kinds of opportunities they want, the volume of opportunities they want, the frequency of delivery, all of that sort of thing?  We're now certain that, when we give the agents the tool that allow them to tell the machine what to deliver to them, we're going to start solving the bigger problem that we have, which is connecting our sales group to our marketing intelligence.

So, the ROI story is, for us, is still yet to be told.  But we are very confident it is going to be a good one.

Ron Ambuter

I'm going to try to try to answer this question and give you a quick story at the same time.

For all those people who came out with an MBA at one time or another, we know that return on investment, return on equity -- or any of the different ways you can look at business case -- doing this it is a necessary thing.  Our Bank has adopted a process called Six-Sigma which we've inherited from our friend Jack Welch over at GE.  It allows us to look at everything from a very, very detailed, statistical point of view.  So, not only do we look for our return on the initial project, we look for continuing return and we measure that return year over year over year to see that we are continuing to get our value or to see if we are able to drive additional value.

When I first came into the business world (shortly after the Civil War) it was perfectly acceptable -- in fact, it was quite good -- if you could drive an 8-year return on investment.  That was justifiable to do a project.  Over lunch I was sharing with Gladys that I'm not sure '8 minutes' is acceptable any more.  The return on investment is quite the challenge, and the competition for investment dollars is very significant.

If I can share a quick story, perhaps it will help.  My side of the world provides the costs and the cost estimates, and the other side of the world takes those numbers and moves them into their business model to try to look for a business case that's acceptable.  I should mention that, in addition to our 20,000 internal users, we also provide the Chase Home Banking customers online access to images of their checks and statements and such.  And we do the same thing for our ATM customers.  So if you are ever standing in line at an ATM machine behind 12 angry people waiting to get their twenty dollars out and the guy at the front of the line is getting half a dozen check images printed, it's probably a Chase ATM.

Both projects came to us in parallel.  We did an estimate in a very exact estimating process, and both projects came in at an estimate of, give or take, a quarter of a million dollars (let's use that arbitrary figure).  One project -- the home banking project -- went forward; the ATM project was put on hold.  We then built the home banking project, and it came in on budget and on target.  It went into production, and I'm proud to say that it was quite successful.

The ATM project then came alive.  It was to deliver similar functionality to our customers -- copies of checks, copies of statements, copies of 1099 forms and so on.  By leveraging the rules of the first project, we were able to deliver the second project for $12,000, instead of the original estimate of a quarter of a million.

So that shows where the leveraging of the rules can go into helping with the business case.  Does that help shed some light on that, Gladys?

[Audience]

You said earlier, make sure your tool will take you all the way through.  Could you please tell me what's behind that?

Ron Ambuter

Yes. I mentioned that rules should be looked at as a corporate asset.  Our company is a relatively good size.  We've grown up in a number of businesses, with a number of business silos.  And it was quite normal to look for silo-driven solutions.  Yet when you go up and look across the organization you can see, for example, that in one business you might have a set of rules that say, "These are the processes/the rules I have to follow to be able to do an outgoing email to a customer."  And from that one business, this rule can be leveraged across all of the businesses once it's in place.  I don't have to rebuild it and rebuild it and rebuild it, like we always used to do.

In order to be able to serve the dimension of the business community that we have -- with the complexity that we have -- we have to be on a tool that can handle that volume and that complexity.  If we were a quite differently-constituted organization, we could use a different tool.  We're writing one right now that, so far, has been able to take us, scalability-wise, all the way that we want to go and handle the complexity at the same time.

That's what I meant.  If you start with one that's the wrong size for where you want to go, and later you have to get off it and move to another tool -- that is a chore.

Bill White

We had a business case for the project as a whole, and it dealt with more than just the rules engine.  To understand a little bit about where we are and where we want to go -- currently our processing is done on a weekly cycle.  It's flat file processing; it reads in 200 million accounts; it looks at every one of those 200 million accounts.  That's our current processing.  What we were looking at was moving to daily processing using a database, and having updates and refunds go out on a daily basis.

So there is more built into our business case than just the rules engine.  At the time we did the project I think it was showing a 3-to-1 ratio but, like I said, that included more than just the rules engine.

Gladys S.W. Lam

Good, that's what we want to hear -- a bit more than just the rules engine itself (with all due respect to all the vendors here).

Mark Myers

Our organization is a non-profit organization and so we typically look at ROI or net present value and internal rate of return a little bit differently than a profit organization.  Let me present how we look at things from a couple of different perspectives.

A lot of you might be involved in Sarbanes-Oxley and SAS70 type2 reporting ... going through those kinds of audits.  Our business rule process has allowed us to approach that, and meet that audit standard, much more easily than had we not been involved in that.

Also, all the projects that we have applied the business rule approach to have come online on time and on budget.  And we can't say that for other projects … those that do not use that approach (unfortunately).

So we have seen that change in the way we do business.  We have been able to see a lot of projects being managed a little bit differently -- more effectively.

Arne Herenstein

I will use an umbrella statement over how significant the change has been at OneBeacon.  Two years ago, OneBeacon (which is the successor company to a merger of older insurance companies) was losing about $50 million a month.  Today, we are probably in the top 5% of performance of insurance companies, with returns on equity being somewhere in the neighborhood of 14-18%, which is extraordinary for an insurance company.

That is attributed to a lot of reasons, but three keys ones that I would look to are some of the rules projects that have we put in:

1. Our claims rules systems have resulted, on an audited basis, in a 3-point reduction in losses paid, by sending the right claim to the right person to handle it quickly and effectively and fairly.

2. Our underwriting rules have reduced the loss ratios by 40% in the commercial lines that we just implemented about a year ago.

3. Finally, the productivity in our offices has dramatically improved because, as you can imagine, we've removed tons of pieces of paper that people shuffle around just to send a renewal out ... on something you didn't really need to look at because your insured has been with you for ten years and they haven't moved house and they haven't changed much -- just a little older, maybe with a different car -- but still the same. In those locations where we can look at these things and move them around, we've reduced our staff between 30 and 40%, depending on line-of business.

So you can translate that -- how those contribute up -- obviously to that fairly substantial improvement performance.

Charlie Thacker

The basic guidance I would have is that the initial project is about the same, if you compare it to a non-rules kind of project.  There is still a substantial learning curve, there is some investment in new tools, and that costs money.  But, over time, once you've established the basic infrastructure and the environment and have a mature team to address projects, we've seen anywhere from four to ten times productivity improvement -- and a 10 times improvement in the people.  So a project is 25% to 10% of what it would be.

We have examples as well in terms of the rules engine:  running in the environment where it would take (in one case) nearly 30 application servers (I won't give the size of them), running on a rules engine it is 3.  So we've had a fairly substantial reduction in some of our infrastructure as well.

---

Gladys S.W. Lam

That's great.  Now I know where to point people when they have questions about ROI.  Next time I get that question I can refer people to this panel discussion!

.

Does the Rules Engine 'own' the rules data?

[Audience] I have a question that was prompted by one of the earlier statements:  Migration from one business rule engine to another seems to be a scary prospect.  It seems that most of the business rule technology out there is contrary to the separation that the business rule approach is calling for, which is to separate your data, from your process, from your rules.  By contrast, here are the rules engines -- they 'own' the data; they 'own' the rules (and the meta-rules).  And if you want to migrate from one engine to another, you are doomed.

Ron Ambuter

I would question that the rules engines 'own' the data.  The data goes out into a number of different repositories that we access.  And some of the data is generated from data that is generated by other applications.  So I'm not so sure we 'own' the data in the applications that we're doing.

[Audience]

I'm talking about the 'rules data.'

Ron Ambuter

Oh, the rules data.  Yes.  There the issue is, when you go from one to the other or if you have multiple products, the commonality of the description of the rules.  And that's also the chore when you go from multiple environments to a single environment.  In any case, you'll want to come up with your 'rules dictionary,' in effect.

.

Does the introduction of rules technology result in job loss?

[Audience -- Ron Ross] I have a very short question.  This is a concern that is often addressed to us, particularly by IT professionals.  I wonder if any of you on the panel has, as a result of your rule engine experience (your business rules project experience), ever seen any IT people lose their jobs.

[Panelist]

Not as long as they are willing to move to India.

[audience] laughter

Gladys S.W. Lam

I see a lot of heads shaking, so I want to say that, for the record.

[Audience]

Ron, a clarification -- are you asking about job loss due of the success or due to the failure of the projects?

[Ron Ross]

We've seen a lot of resistance from the IT department to a business rule methodology (and technology) applied to projects because, when you get right down to it, it's all about jobs, jobs, jobs.  So, what I was really trying to ask is, are we likely, by the introduction of rules technology, to put IT people out of a job?  And I think the outsourcing to India was, by the way, a very relevant point.

Steve Lindstrom

Can I take a swing at this?

I don't know if anybody has lost a job or not; I don't keep track of that sort of thing.  What I do think is interesting about the flippant response (it was meant jokingly, right?) is:  if we think of our business logic as an asset, I scratch my head getting into this space.  Why would we be shipping off-shore two-thirds of what we're supposed to know about our business?

I think the bigger picture (the big story) is being able to make 'transparent' the logic that runs your business (that makes you money):  make it available, make it something that you are measuring, make it so that whoever is doing it and whatever piece of it they're doing you're having essentially the same kind of conversation.

I really think that the business rules space is relevant to this whole notion of 'off-shore' development.  I haven't made a big speech about that yet in our company but, conceptually, the notion of really having, at your fingertips, the things that are running your business, I can't see how that doesn't benefit you.

Mark Myers

I think that, as far as the IT people go, the business rule engines, the technologies, the methodologies all drive you to have to do an enterprise-type approach.  When you are looking at terms, if you are not looking at terms from an enterprise perspective -- if you're not doing enterprise modeling -- this will not work.  You have to do your logical data models.  It forces you to do the process that you've probably always wanted to do.  Now you have the business people driving and saying, "We really want this now.  We want to define all our terms.  We want to database our rules." -- the business people are now saying all those things.  You need to have good technologies and good processes and procedures in place.

I don't see jobs going away, but I certainly see a shift in skill sets.  And I certainly see a shift in job responsibilities -- things that IS might have traditionally done, maybe the business will be doing.  But there will be new things for the IS people to do as they get to their enterprise architectures, putting those in place so they can support that solution.

Arne Herenstein

I have a slightly different view of the question and a slightly different answer.  In a well-run company these days, I don't think that we should be seeing a division between IT and business.  And I think that what you are talking about is a reflection of poorly-managed projects -- poorly-designed ones -- rather than the engine, the tool, the people.

It's the same as it was in the old days -- you might have had that 'order-taking' mentality where someone said, "Hey, you guys, you are just techies so do this."  You know, that doesn't work any more.  It doesn't work here any better than my best Java programmer telling somebody how they're going to have a web experience for the customer.

So in this kind of question, I would prefer to remove the rules engine from the issue.  The actual issue is management and teamwork, not technology vs. business.  I think that's really what it is.

Gladys S.W. Lam

Very good point.

Ron Ambuter

When we first started getting involved with business rules, we had a very large group.  If you added together all the people doing the jobs from all the different banks we've merged with in the timeframe I've been there, there were about 1700 people; now that job is being done by about 400 people.  This is because of automation that we've been able to implement using business rules.  So there were a lot of jobs that were transitioned to other places in the operations side.  During that process the IT staff actually grew because we found that for every IT person we added we could impact the operations department.

Where we started to decrease the number of IT folks was when the business tool became easier and easier to use.  I mentioned that the tool we use has gone through a number of evolutions and the amount of time it now takes to deliver to market is substantially less, and it takes substantially different set of knowledge than it did when we first started this project in 1994-95.  So that's the impact for us.

And, for the sake of the earlier conversation, one third of my staff is currently housed in Calcutta.

Aaron Gary

This is not a concern on the IT side; we've actually had concerns come from the other side.  Now that we've had a successful rules engine implementation we've started looking for other ways to use this.  And we've discovered that one rules engine with one person sitting and maintaining it can almost do the same work as one complete department that we have now.

So when I've been out there talking to departments and saying, "Look ... I can help you do your job better" -- they have been reading between the lines and hearing not "do my job better" but, really, "do my job."  So they are not giving these types of project such a warm reception.  The best we can do is just mention these things to upper management -- tell them that we can do this -- and then let management decide what they want to do.

Charlie Thacker

I'd like to say a couple of things.  My former organization (I just left it about a month ago) had a strategy to move some more of our work 'off-shore' ... whether that's Canada, Mexico, or India, wherever it may be, but to move it off-shore.  Part of that strategy was to reinforce the building of business models and systems models because that's really the key knowledge that we typically have in the brains of the programmers and when they leave the business they take a lot of that knowledge with them.

We therefore wanted to institute that in the models we create so it would make it much easier to move the work off-shore and then let them focus on the technology and the delivery and running of the system, and we would focus on the knowledge -- what the system was really to be performing.  That was a very key part of our strategy in terms of starting to move our work off-shore.

Gladys S.W. Lam

Excellent answers.  I have a question from the audience.

[Audience]

When you say 'off-shore' do you mean off-shore temporarily?  In other words, when the project is done is the off-shore relationship then severed?

Ron Ambuter

No

[Audience]

... because I have a second question.  So you are saying, no, it continues on?

Ron Ambuter

I do both.  I do fixed price, one shot, expand my bandwidth -- because I have a lot of projects on the table right now.  But also, one third of my permanent staff is over there.

Charlie had a good point.  The fact that now we've now built some of the expertise and knowledge into the form of a rules base, this has made it easier to do that ... to move it over there, but also to move it back if we want to.

.

Does the 'business rules approach' require a different skill set?

[Audience] My other question then is:  as a result of the business rules transformation that obviously all the panelists have gone through, did you find that you've had to acquire a different type of new resource?  Because I'm seeing that your business-as-usual process has to be supported while you are going through the transition.  Are you using those same resources while you are trying to transition to the business rules?

Arne Herenstein

There has been a significant change, particularly on the business side.  Many of the tasks that were previously done in the IT department are now handled by the business units themselves.  Historically, in the insurance company, the people in the actuarial department did the statistical analysis to determine the rates and generally did the work to move them across; they were the forerunners of this.  But now we have our underwriting department deciding what rules they are going to use -- what eligibility, what credit scores, and how that will work.  As a result there was a transition, there was an upgrading of some the skills sets in the business unit.

And some people did like it, and others did not -- and new people came to replace those who did not. So there is definitely impact ... significant impact.

Recently, we've had some people come back to us and say, "Gee, I wish we'd never taken this from you. It's a lot harder than it looked when you were doing it."

Ernie Eichenbaum

I'd like to address the last two questions at a very fundamental level.  I'll start with an example.

On the second project that we implemented, we used a toolset from a company called ESI (who is represented here).  We took a few days of training and then, without any involvement of IT staff, developed a solution in a few months and deployed it.  (That was, by the way, also without the support involvement of ESI.)

My point here is that, at the fundamental level, the business rules were 'externalized.'  (By the way, when we say the word 'externalize' -- I'm not sure that everyone actually believes that.)  'Externalize' in one sense means, take it out of the hands of IT and put it into the hands of the departments.  The tools need to be simple enough that this can occur.

And therefore when I heard the question I was scratching my head for a minute -- what does IT have to do with this?  A project in this area fundamentally is not an IT project; it is a line-of-business project.  At least, that is my own experience.  (I understand that there are different experiences.)

So the typical situation would be closer to what we have heard here from People magazine where, by automating processes -- by simplifying the processes -- it’s the people who are actually in the line-of-business who may find their jobs in danger.

Tying everything together now -- back to my point about management -- it is management's responsibility to figure this out ahead of the project, such that the business grows and/or jobs are enriched accordingly and so that you actually maintain those people who contributed all this knowledge into the system.  Employees should not, under any circumstance, be penalized by getting fired once they have done the 'brain dump.' That's a tragic management situation, but I'm afraid that it happens quite often.

Arne Herenstein

You have to be careful how you classify the employees that are involved here.  Productivity changes tend to occur at the process level.  They don't occur, either in the business units or in the IT department, with those people who 'do' the rules.

We do outsourcing ourselves on a very limited basis.  We do not -- and will never -- outsource the people who do the business analytical service.  That is the part that has to stay here.  We outsource the things that we presume anybody could do if they had the time and energy to do it.

Gladys S.W. Lam

Excellent point!

[Audience]

I was going to pick up on a point that, to a degree, Arne has made it for me.  The whole notion of outsourcing our IT department to off-shore is really an outmoded notion.  It is a legacy of procedural code, if you like.  When procedural code goes away, theoretically all of that should become obsolete because really, in a rules-based environment, there should be no outsourcing because the business should be making their rules.  The challenge for us as vendors, and the challenge for us as users, is to ensure that that model can be implemented and that we proceed forward.

Ron Ambuter

I'm anxious to join this fight.

When I was younger and dealing at a different level, I think that I would have easily taken Ernie's position.  As I'm older now and have had a lot more battle scars I'm not sure I would take it in all cases.  For example, within our organization:

• We have very strict control policies over who can touch what.  Having users be able to make changes in the rules that affect financial or privacy aspects of the business is forbidden.  There's a check and balance there, so there's a role for IT.

• A tremendous amount of the stuff that we do provides interfaces from our rules-based engine out to other legacy systems or systems inside or outside the bank.  That takes traditional IT people.

• All of the rigorous testing that's done falls within some IT-controlled discipline.

• Finally, the last piece is that we've got -- within the same engine, within the same installation -- thousands and thousands of users and tens of different business units.  And you can't permit somebody 'over there' to make a change that fits his system well without evaluating how that change would affect all the other user communities.  For example, if the folks who are doing research into our repository of 52 billion checks were to say, "Give me a copy of every check written in the last seven years under a hundred dollars," the volume that that would create would bring the rest of the user community to their knees.

So I'm not sure that the IT department is no longer a valid place to do this work.

---

Gladys S.W. Lam

I have time for one last question.

.

How does a 'business rules approach' alter the business / IT roles?

[Audience] I have a question related to this topic.  We've heard a lot about empowerment of business users, and I think that's interesting because I've also heard people say that it takes a certain skill to do analysis.  So do you imagine that, as business rules become more popular (more widely adopted), the skill set for business people will need to adapt to meet these needs? A second, somewhat related question:  I hear a lot of talk about the ability to make quick changes.  In a production environment how quickly do you actually need to make changes?  This relates to what this gentleman just said -- that certain checks and balances still do need to be in place.

Steve Lindstrom

Can I respond?

The president of our Property & Casualty Company, Tom Wilson, has declared that everybody on the IT side of the organization needs to become more business-oriented, and everybody on the business-side needs to become more technically educated and aware.  And I think he's absolutely right.  I've worked in marketing for a long time and worked with people who go, "Oh, you know -- technology just gets in the way!  It costs money."

That's simply a fantasy.  We live in a technological world.  Businesses run on technology.  So this joining together and movement toward the middle -- which I think the business rules approach helps to facilitate -- is just something that is necessary for businesses to thrive.

To answer the second part of your question:  That was the one other DO I wanted to get to.  DO think very hard about how you want to delegate control of rules.  You need to give that particular subject matter a lot of attention and to think about it in terms of how decisions get made within your organization and to try to solve that problem.  One thing that we've found in doing this work is that we constantly rehearse our decision making process for every decision we make.

---

Gladys S.W. Lam

I hate to break up the party.  Every year I ask for more time for the panel because we have such a really great discussion.  I thought this year's panel was exceptionally good -- both the quality of the answers and the discussions.  Do you all agree with that? <applause>

A special, special thank you to all the panel members.  And thank you to everyone for coming.  See you next year!

# # #