Panelists

Ronald G. Ross, Business Rule Solutions LLC

Mike Rodeman, RS Medical

Mike Harty, Harrah's Entertainment

Peter Schoenrock, Equifax

Anton (Tony) Plasil, STW Fixed Income Management

Moderator

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

.

Welcome

Gladys S.W. Lam   Good afternoon.  We've come to the final session of the Executive Forum.  I like to make this portion of the program as interactive as possible.  I've facilitated this Executive Forum Panel (and also the Practitioners' Panel) for many years now.  And I like to lead off with some questions ... but at any time, if you have questions and you'd like to jump in, feel free to do that.

Today, with all of you having been in the room, I'm sure we don't need any more introductions.  All of our panelists have shared their experiences and we know they have lots of knowledge and lots of good insight on what they've done with their business rules in their organizations.  So I'm going to start off with a question for each of them.

If you had to start all over again, what would be the one thing you would do differently?

What do you know now, that you didn't know then, that you think would have made things different for you? I will give you a minute to think about that, because it is hard ... when you think about it.  You know, each person has been down a journey, as I've heard it called.  And now that you've taken that journey, what would be the one thing that would have made a difference?

Mike Harty

To me it would be that this has really changed our business / IT interactive dynamic.  In the past, whenever the business wanted something  -- when they had something change, or something new -- they had to come to IT and pony up the dollars, and ask for the time and the money to get it done.  Now, with this rules engine, they really have the power to make a lot of the changes themselves, which has created challenges both for them and for IT.  I don't think we really were prepared for that change in dynamic.  So if I had to do it all over again I would have figured that out on the front end and would have spent more time on that.

Gladys S.W. Lam

That's good.  Anyone else on the panel who can think of something that you have learned? 

Peter Schoenrock

I think I would say that, starting again, I would have invested a little bit more in the training up front, across the organization.  In our business we have our core development team and our customer fulfillment teams who get involved with the customers.  I'm not sure that we were adequately prepared across the organization with the knowledge and the experience and expertise to hit the ground running immediately.  As we bring new people in, it would be good to focus a little bit more on the onboarding of our resources ... on their experience and education.

Gladys S.W. Lam

Good.

[audience]

Peter, is that the training on the IT side, or on the business side, or the rules side?

Peter Schoenrock

Yes.  <laughter> 

Really, it is all of the above.  We certainly have people on the technology side who need an understanding of the base products and the technologies.  But then on the business side, where we have what we call a business solutions consultant, there needs to be an understanding of how the process and the rules interact, and how to effectively write rules.  There's an art rather than a science to writing the rules.  To write them in the most streamlined manner for performance, or for just ease of understanding and ease of use, there's a skill set involved ... and also an education that comes only with some experience.

Gladys S.W. Lam

Tony?

Tony Plasil

My point might be something more of a nit....  I would say that the first business user that we had using our system didn't have enough training in the business itself.  This did not have too much to do with actually working with the rules but really just not understanding the business (compliance) part.  She was doing compliance and she didn't really understand compliance well.  But, you know, that's really a small thing because we were pretty pleased with the way the whole thing went.

Ron Ross

The first thing I would have done, to start off with, is to figure out how I could describe what I do for a living to my mother, who still doesn't know.  <laughter>  Because it is sort of hard to explain what it is that we do.  You say, "Oh, well, I do 'rules' for a living."  Huh? 

There's a serious side to that, obviously.  I would have started sooner trying to identify what you need to say in order to explain to people within the organization -- management, other people (business people) -- what this means to them ... how they need to be involved and engaged.

I also think that business rule statements (and I heard this echoed down the panel) require a special kind of person or skill to express well.  And I'm not sure even yet that we have the right skill set quite nailed down, in terms of who makes a really good business rule person -- a person who expresses business rules well.  I think there's a combination of facility with language and analytical capability and communication skills that is somewhat difficult to find in the circles that we typically live in and work in.  I do think these people are out there.  It's just that we haven't figured out quite where to find them.

---

Gladys S.W. Lam

Good.  All right.  And on the thinking about roles and responsibility ... I'd like to pick up on that.

Now that you've gone down this path, has your organization changed in terms of roles and responsibility ... on the business side?  ... on the IT side?

Has there been any official change in organization structure, or roles, or new people that you find you need for a business rule approach?  Do you have new roles that weren't needed before, or have you had to shift skill sets?  What has been your experience?

Mike Harty

In listening to the other panelists, I think maybe we should have had more change inside of IT than we have had.  But we haven't really changed our basic structure.  We've had to do some retraining to address the new technology and capability (that kind of thing), but our basic roles are still the same. 

There has been, again, a bit more change on the business side.  They've had to create some new roles in the way our business deals with these rules, as far as rule management, interacting with the end user who is, for us, a property marketer.  The change has come in how they do that in a way that has the right combination of control and flexibility, which is a different thing for them. 

So it's been more change for the business folks than for the IT folks, I think.

Gladys S.W. Lam

Is that a shock for the business, do you think, having to change?

Mike Harty

I think they were shocked.  At first they hear "flexibility" and that the control moves to the business, and they're thinking, "Oh, this is nothing but good."  And it is good ... that's what it's for.  But with that comes the responsibility that they have to put some controls in place.  You can't let just any body do any thing, right?

Gladys S.W. Lam

And, Tony, you mentioned that, as well.  In the first experience, the business person wasn't perhaps as informed in the business.  Have things changed subsequent to that -- say, for other projects?

Tony Plasil

Yes.  What I'm finding is that it's not so much that we have changed people or even the roles.  There's a different attitude.  It's a very positive attitude.  Rather than say, "Oh, I'll just knock this off in a spreadsheet," now they'll come to me and ask, "Is there something we can do with the technology, with the rules engine -- something like that, that can solve this problem?  It takes us days to do this in a spreadsheet and we'd like to be able to stop doing it that way.  We don't have time to do it that way and still respond to our clients."  We're seeing that kind of an attitudinal change.

Gladys S.W. Lam

And awareness? 

Tony Plasil

Yes.  They now recognize that there's a tool that can really help them.

.

When posed with that question from the business who then takes charge ... who takes ownership of project?

We're trying to set up an enterprise capability to do the business process redesign ... to drive out the ruleset, implement the rules engine.  We're driving it out of our central change model that comes out of our IT shop, and I'm not so sure that the people who made their marketing decision (like Ron said) are comfortable with that because we've not yet demonstrated anything of value to them.  I'm just curious how you had your organizational model of your IT and your business talking to each other ... who took ownership when you first implemented these useful, new business concepts?

Tony Plasil

You might as well start with me.  We're a small enough shop that I played a lead analyst role working with the senior portfolio managers, which I really enjoyed.  That's my background; that's my technical skill set.  So I worked with the portfolio managers, starting with the head portfolio manager, and ran the project from there.  Then as I needed to get the business information from an individual portfolio manager (or wherever) on the business side, I could get it and translated that into rules.  So I'm the one to do a lot of the work in that area.  Of course, we test it with them, and they have to okay the results. 

But it's not a business-run project.  They don't have the time.  In our industry, a portfolio manager is a transaction-oriented person; they don't think in that long-term way.  They're always thinking 'transaction' ... all day long.  Actually, it would be the worst kind of project manager you could imagine.  It's just not the nature of the person.

Gladys S.W. Lam

So you'd still have to couple the IT staff with the business staff ... to guide them along in the first steps, even though the iteration.  I know Mike has talked about the iterations, doing things through smaller chunks.  Mike, does that help in pulling the business in?

Mike Rodeman

It does.  We've gotten our IT department out of the driver's seat, but they are very much a partner. 

In the past, they used to tell us, "Don't worry how we're going to do it; you just tell us what you want."  The problem with the 'just tell us what you want' approach is that if you don't know something of the how-to-do-it, you just recreate the same thing that you had before ... because that's all you know. 

So, what we've tried to do is this:  we've got very good business analysts who actually have development and IT background, database design, and so forth.  Those people can ride the fence because they have been forced to learn a lot of the business processes.  They have become key in moving back and forth between what the business is asking for and what IT is willing to deliver.   And in that mode it's no longer "don't tell me what you want"; I do need to know something of the how.  Our business analysts really are a key component.

We're also fortunate because we have a very small company.  I'm the VP of Operations so if I want to change a business process I can change the business process.  I can tell IT people, "That's what we want."  And then I put on my IT hat and figure out how we're gong to do it.  I'm in a very unique position, and it's a tremendous amount of fun.

[audience]

It works like that in the IRS, too.  <laughter>

.

Did any of you attempt to 'normalize' your language?

A couple of you mentioned the importance of language.  Did you have any kind of tools, a playbook ... something to normalize your language? ... anything like xBML?  For example, for the financial industry sector, IBM has IFW.  Did you use anything like that to help facilitate your way through that process?

Mike Harty

We didn't.

Tony Plasil

We just used regular XML.

Mike Rodeman

For most of our business users, they don't care whether they're using HTML or XML or any of that stuff.  What we've done is simply call it "enterprise business object" -- here's an object; it's an order ... and here's what is contained in an order.  That you can hand to the database people, and they're going to figure out how to map it to however many tables they need, and build the relational database. 

But for the business users, I'm always dealing with "an object" -- is it a patient object, documents object? ... that's how we've done it.  For example, we have a definition of what constitutes "an order."  The biggest problem is that, previously, what constituted an order was varied, depending on who you were talking to.  I'll give you an example.  In the IT part of the business, we get what is called a "work order" that we process through the billing department.  A work order starts out its life as a lead.  If it's all complete then it becomes a work order.  The work order goes to the billing person to either deny it (which means that they have killed it) or it's confirmed.  Eventually it runs the life of the prescription and then a renewal order is generated. 

However, for the person in the field, they simply consider that they got an order ("I submitted an order.").  All they know to say is, "You've denied my order."  But the terminology is more specific than that -- you cancel leads, you deny order, and you early-term renewals.  So in talking to someone in the field there can be a big conflict in "what are you talking about?"  Is it denied?  Is it early-termed?  ...  there is substantially different terminology for meanings for the billing people and the operations people, as opposed to the language used externally. 

So there is a need to come up with some common language.  We still haven't gotten there yet; we're still working on it.

Ron Ross

I'd like to respond to that.  This issue of language is extremely important.  For many years, I have been espousing the need for business-level language and notation, in order to express business rules accurately and succinctly, yet in a way that business people can directly interact with.  I think that's absolutely essential.  That's one of the reasons why we've developed RuleSpeak and have applied that for many years.  

The good news is that just emerging in the OMG is a new standard that has been adopted for finalization, called the "Semantics of Business Vocabulary and Business Rules" (SBVR).  This is a standard that is the result of a good three to four years of effort by some of the world's leading experts in logic, in linguistics, and practice, as well.  It has been iterated for a long time, and now provides the semantic underpinnings that we need for that level of language.  It's a very exciting, very important innovation, and it will gradually reach people's consciousness.  And it is setting the stage for moving the language up to where it needs to be, which is a level of business language.  

If you're interested in that, by the way, in the Exhibition area -- if you go by the Business Rules Group's booth (BRG) -- there is some information about the Standard.  There are also some presentations that will be made on SBVR on Wednesday afternoon and Thursday ... worth looking into ... not worth reading the Standard, though.  It's 300 pages of stuff that you don't want to read, start to finish.  But certainly the business-facing concepts are very straightforward and they will prove to be very powerful.  I'll be talking about the business rule part of that in my Keynote, tomorrow morning.

.

How did you overcome resistance from the maintenance staff?

I heard a recurring theme this morning from Tony and Peter and Krishnan, about the difficulty of maintenance type programmers developing new applications.  And I want to know, how do you get their knowledge and at the same time let them know they're not going to be in the future picture?  That seems a huge obstacle to me.  How do you overcome that?  Can you elaborate any more on that issue?

Tony Plasil

That's a good question.  Just like most things, there is no quick formula.  You need to deal with each individual, and it's hard when their skill sets are limited.  They are knowledge workers, basically, and know the existing system.  But chances are you'll be moving to a different technology (something we've always done, by the way), and they may not be equipped to do that.  So what I've found in other organizations, they've usually just been phased out if they couldn't get retrained.

[audience]

So did any of you attempt retraining?  <no>

Mike Rodeman

We are; we are attempting that.  We haven't hired any legacy programmers and when one leaves we don't replace them.  We're down to, I believe, four.  What we're doing ... we're spending the time and energy to retrain some of them on the newer tools.  But most of them are VB6 programmers and that's ancient technology.

Peter Schoenrock

But, I also think you can look at it another way ... that the new applications of today will eventually go into that maintenance mode.  There was a lot of talk about how maintenance programmers don't necessarily make new application development -- don't have that skill set -- but it goes the other way around as well.  Someone who is basically very skilled at new application development won't necessarily fare well when you put them into a maintenance role where, potentially, they have to read someone else's code and fish through and try to figure out the troubleshooting and the problem solving.  That probably is not their skill set. 

So as long as the constructs are similar and they have the programming background, I think you can retrain some of the 'maintenance' people.  Because it is a skill set to say, "Here is a bug that we found; go find what the issue is."  That kind of investigative nature will still be needed -- not necessarily being the "master of it all" ... it's kind of a "jack of all trades; master of none" -- being able to go back to the frontline programmer, to ask questions and better understand what the problem is. 

The problem comes when you have too much attrition and you don't have anyone who is familiar with the original structure and programming.  Then there is no last line of defense.

Ron Ross

I think another point here is that, with business rules, you get a much cleaner separation between what is the business logic and what is the platforming logic specification ... the underpinning specifications (and so on).  So you can do a kind of triage (although that's only two parts, isn't it), in order to decide, "Okay, would you rather be a platforming person, or would you rather be a business logic person?"  I think there's some sort of self-selection that occurs because of having that choice.

.

What metrics have you used?

I think the examples today clearly demonstrate the value of implementing business rule technology.  But I'm curious.  What metrics (or data) have you used to really measure the value and be able to communicate that up through the leaders of the organization?

Mike Harty

You're probably asking the value of doing it with business rules versus trying to do it some other way? 

[audience]

Yes, or not doing it at all.

Mike Harty

I don't know that we've gone there, actually.  We are very carefully about measuring the rules that we deploy.  We measure whether or not we are getting 'bang for the buck' on a rule that's been deployed.  Is it driving revenue?  (Or whatever it's supposed to be doing, is it doing it?)  We have control over that kind of thing. 

I don't know, though, that we've actually tried to measure speed to market (those kinds of metrics).  It's intuitive to us that some of the capabilities we've deployed, to do them custom would have been tremendously more expensive if we wanted the same level of flexibility.  But we've not tried to give it a hard measurement behind that.

Tony Plasil

I haven't needed a matrix because the improvement is orders of magnitude.  For example, I got a request two weeks ago to do a forecast of amortized income for the next year.  That would have taken months to develop; we did it in a matter of just days.  And this is true of almost everything we do that way.  The leverage is so high that ... I don't know what metrics we could use.  It's almost a waste of time doing metrics on it. 

Ron Ross

That's not a great answer for people who haven't had the experience. <laughter>  But ... I have to vouch for it.  That's what we hear repeatedly. 

Now, the one thing that I've often suggested that might work in some organizations (and we've tried it with success) is to take an existing business process.  And typically downstream in the business process you can find that there are a lot of people who are devoted to problem resolution, and settlement, and complaint handling ... just a whole lot of untangling after the fact of problems that accrued essentially because the business rules weren't applied upstream in the business process such that the problems could have been avoided ... not snowball and become much larger. 

So you can begin (it will be sort of hypothetical) to get a handle on "how much is that labor costing us?"  And, also, the people generally don't enjoy doing that kind of work.  So consider ... if we could reposition that labor, if we could redeploy it to more proactive, more creative work, and free up those people because we are avoiding the upstream problems, how much would the company save?  ... and how much would the morale improve?  ... and how much happier would our customers be? 

Depending on the business and the circumstances, I think that if you find you can take some sort of overall business process view, these can make some pretty compelling arguments ... that there's something wrong and provide a rationale for beginning to look into alternatives.

Mike Rodeman

We have some metrics.  Our VB application has eliminated in excess of 60,000 pieces of paper that were hand-written.  And those are all forwarded; we had to have clerical people take those to the scanning department; the scanning department would scan them, attach 60,000 pieces of paper to individual files.  So, what we've managed to do is eliminate 60,000 pieces of paper.  It's not necessarily that the application itself is quicker but what it did do is eliminate the fact that, after they've done the checklist, they don't create the paper. 

Plus it's all self-validating.  We also did in excess of 10,000 audits per month on our people.  Now we don't have to do these audits on the employees because the checklist can't be completed if it's in error.  We don't have people scanning them ... we're not paying for the people to scan it, nor the wear-and-tear on the scanners, copy paper, and so forth.

Finally, some of the processes simply never existed before.  We have one application that does the Certificate of Medical Necessity for a Medicare patient.  We didn't have the capability to do that.  Now we have a process that generates the form, decides whether it is new or a renewal, walks through all the rules, and generates something that can't be wrong (since there are only certain limited answers that are acceptable for Medicare).  And then it creates a file that is electronically transmitted to Medicare.  Those are things that have all been done in some manual process before. 

We don't have dollars and cents on some of them because some of them didn't exist.  And on some, we do.

Ron Ross

If you had been asked, beforehand, if you could visualize that before you actually did it, could have predicted that you would have saved the 60,000 pieces of paper (or some ballpark figure) and the related resources?  Could you have been able to visualize that?

Mike Rodeman

Oh, yes, we could have visualized it.  The problem is it's one of those things that is hard to take from vision to reality ... Jules Verne could figure out how to get to the moon in his dreams, but how do you actually build a spaceship to get there?  That's the problem we had.  We have all kinds of visualization.  We've got really big dreams.  The thing is that without the ability to generate the business rules and some of the things we've learned (especially two years ago when we came to the conference) ... that gave us the technology to build our own spaceship.

Peter Schoenrock

I think you also need to understand what your goal is so that you can measure the downstream performance.  Is it to increase the cross-sell and grow revenues, and then how are you going to measure that?  Is it to streamline the process and drive throughput?  Is it to just enable better decisions -- more consistency in the decision making? 

Understanding what the primary driver is allows you to set up the performance metrics in order to measure.  Not everyone is going to look at this as an efficiency gain.  Yes, there might be some in there, but it may just be more of leveling the playing field across a decentralized organization, where there are some manual steps involved and there is still paper.  And that part is not going to be solved.  Or maybe your goal is to cross-sell from the marketing perspective and drive revenue.  Then, with control groups (and other things), you're able to adequately measure the downstream performance to see if you actually got the gains that you are looking for.

.

Do you really need a rules engine?

I want to ask the question somewhat differently because I hear people say, "I can change my processes.  I can pull out my rules and put them in a repository and manage them.  But I don't need a rule engine; I don't need rule technology.  I can go build it in Java, or Cobol (or whatever)."  To what degree was the rule engine a contributor to your success?  Could you have done what you did without it?

Mike Rodeman

The VB application that we built ... we only had one programmer working on it and I think it was probably under a month, one person doing it.  And I asked him, "So what would it have taken to have done that in any other application or any other technology?"  It would have taken him thousands of lines of code because it is a very complex ruleset.  Basically we converted it into a typing exercise:  here's the ruleset.  You need to replicate each one of these rulesets -- all 300-600 of them.  We bundled that up, sent it off to India, and asked them, "Here do us a favor.  Build these rulesets and send them back."  It would have been very difficult to do it in another tool.

Tony Plasil

As I mentioned when I spoke earlier, the guideline checker that we built (which is a compliance piece) was attempted by another manager with a Big-6 team that cost millions of dollars a year.  And after a couple of years that project was cancelled, and they ended up buying a vendor package, which was very limited.  (It is one I actually had at my prior employer.)  So I think that just that one application ... without a rules engine it would have been impossible.  It would have taken so long ... I just don't think it would be successful to do it.  I'd be better off buying a package.

The other application we did was to replace our accounting system.  People thought we were crazy for doing it.  But with a rules engine and a math library it was very doable.  I highly recommend to anybody in our industry to go ahead and take that approach.  But if they were planning to build an accounting system from scratch, I'd say, "You're crazy," given what the likelihood of failure is; it's so high.  But this approach reduces risk in the development cycle dramatically.

.

Did you consider JSR-94 compliance?

There's a big thing in Java circles called JSR-94.  All the vendors are coming out with the statement, "Yes, we're JSR-94 compliant."  My question is:  did you actually look at that and if you did, did it impress you, or did you find out that it worked?  Or do you even know about JSR-94 and what it's supposed to do?  That's been one of my big bug-a-boos for the last three years.

Mike Harty

If we looked at it, I don't know about it.  Someone else would have done it; not me.  So, I don't know; I'm not familiar with it.

[audience]

So it doesn't mean anything to you?  Anybody else?  So, the vendors are doing all this and it really doesn't mean much to the customer.

Mike Harty

That's a generalization off of my ignorance so I don't want to go there.

[audience]

But I find it interesting that you don't even recognize what it is.

Tony Plasil

Well, you found one more.  I don't know about it either.

.

Did IT manage your rules project?

I wanted to know if you could comment on project management for implementing a rules engine.  Did you have IT manage the project?  Did you have the business manage the project?  Did you bring in a consultant?  How did you handle that?

Tony Plasil

We managed the project internally, which was IT taking the leadership, with business people on the team.  

Mike Harty

At Harrah's, the business is responsible for the results that any new project is supposed to deliver, not IT.  So, IT is very much in partnership with the business because it is the business guys who are going to get measured.  "Is this thing delivering what it's supposed to deliver?"  Our rules project is no different in that respect.  It is the very same question:  Is this thing delivering what it's supposed to deliver?  

So, the business is very involved all the way through.  But we're pretty traditional in that IT does most of the heavy lifting on the project management side ... does most of the heavy lifting technically.  Obviously; we have business people involved all along the way, doing things like requirements definition and testing and all that kind of fun stuff, right?  And they are ultimately responsible for making sure that we build what they said they wanted built and that it is doing what it's supposed to do.

Mike Rodeman

We managed our own project.  And since I have both the business side and the IT side, I got the project. 

Also, I'm an accountant by trade, so I'm really picky about our projects.  What we did was break everything down into very small segments.  When we built our plan, everything was estimated in 2-4 hour increments, with what was dependent on what.  We knew within four hours (or so) what was supposed to be accomplished ... we could know who was holding up what process.  We have, I believe, ten people offshore that were programming, and we have our own development staff in-house.  And we were managing all those people and knowing pretty much where everything was on a daily basis because they logged their time, in hours, daily.

.

How did you select the rules vendor you would be partnering with?

I have a question about the vendors you chose to partner with for your projects.  What kind of process did you go through to choose the vendor that you did?

Mike Rodeman

We did RFPs, and we also gave them a pilot application and asked them to build the pilot application.

Mike Harty

We did something similar -- a traditional bake-off.  We did not do a pilot application, however; we went through a pretty traditional vendor selection process.  

Now this selection predates my time at Harrah's; I think that it started in 2001 or 2002.  We selected ILOG then and have not gone through another evaluation since then.  But we did go through a pretty traditional process at that time.

Tony Plasil

When I was at Western Asset (which was in 1998-1999) there were three or four products that I looked at in depth:  ILOG, Blaze, one I can't remember the name of (they actually did a pilot).  Then we did a proof-of-concept with Blaze, and it was somewhat unsuccessful because of performance.  After that I left the company, just as Corticon was starting up.  One of the people that was on the project and helping me do the evaluation became the architect.  So he knew exactly what I was looking for.  When Corticon came along I thought, "This would be a good partnership."  And it has been very successful.  For the last five years I've been working with Corticon.  

Peter Schoenrock

We did a lot of industry research ... spoke to the industry analysts.  Our situation is a little bit different in that we are packaging the ILOG software in our product and going to market.  So we were looking for a true partnership and needed someone that was active in the industries that we were in ... someone we could partner with and look at from a long term partnership perspective.  I think this is similar to the concept of the end customers not looking for a just vendor but looking for a partner.  So our focus was not only around the capabilities and the technologies but also the relationships.

Gladys S.W. Lam

For Mike and Mike, who've gone through the RFP process with some prototyping or a proof-of-concept, how long did it take?  ... a month?  ... weeks?  ... years?  

Mike Rodeman

We took about three months.

Mike Harty

I wasn't there so I can't say for sure, but I doubt we took that long.  We typically will get it down to two or three ourselves and then do a quicker turn-around.  

Gladys S.W. Lam

And would you say you are happy with your selection through that process?  ... both of you?  <yes>  Okay, all of you seem to be happy.  Ron, did you want to add something?

Ron Ross

I was going to second the idea of a proof-of concept, if you can swing it ... especially using something live ...  if you have some real live project that's happening.  Again, it's a great way to showcase to skeptical management and also a way to really test drive the capabilities to make sure that they are going to work.  See what kind of deal you can work out with the vendors, or freebies (or whatever) in order to have them show what they can do for you.

.

Are you satisfied with the vendor you selected?

My question is the same as yours, Gladys.  As a follow-on, are you satisfied with the vendor that you selected?  Are there other capabilities that you are now looking for from those vendors and, if there are, how's their response to that?

Mike Rodeman

There are always new capabilities.  We always ask them, "So, what's next?" because we have high aspirations.  Ours is to figure out how few people can we actually have internally to process our business ... how far out in the field can we process our business?  If I can put it on a PDA where they have direct online access all the time, I can virtually eliminate our order entry department, and eliminate almost entirely my scanning department.  So that's the goal.  We're always asking them for those kinds of things.

Mike Harty

Two things (one I've not yet mentioned):  Just to reiterate the first ... the way we're using this -- the concept of workflow and managing the rules through the life cycle of a rule -- is a place where we could use more capability.  And we're continuing to work with our partner on that. 

The other one that we found, from a capability standpoint that could be moved along in the market, is the integration points.  I've talked about how we integrated this product with our EAI vendor and how we have other legacy applications and other technologies that this integrates with ... take our database, for example, DB2.  There are improvements that could be made to allow us to hook our rules engine more readily into either other things we already have or other things we'd like to build without having to do a lot of custom work, which is what most of our work in these applications has been ... building those hooks.

Tony Plasil

I'd like to second what Mike has laid out, even though it's a different application.  When we started using Corticon it didn't talk to a database directly, nor did it talk to other libraries (like the math library).  So we built that and actually, to end up with our architecture (that Service Oriented Architecture), we had to have some kind of distributed manager that would handle this.  Now Corticon 4.0 actually does that, but it's a couple of years after I needed it.  However, that's just the nature of the way things go.

Gladys S.W. Lam

Perhaps how responsive the vendors are to your requests is an indication of this:  Are your vendors still doing research and development?  Are these companies still striving and growing?  And what I'm hearing from the panel is, "Yes, they are working on it."  Sometimes it's a little later than you need it but ...

Tony Plasil

Yes, but that's the way it goes .. that simply timing.  It's to be expected sometimes.

---

Gladys S.W. Lam

All right.  Speaking of time, it is 4 o'clock and we're right on time.  Does anyone have a question to wrap this up?  No?  If not, do our panelists have anything to add?

Well, then, thank you so much.  I've really enjoyed this; I've learned a lot.  Thank you to the panel members -- I think they've been great.  Thank you to you all.  Excellent questions.

# # #