24 March 2010

It's About Quality... End-to-End Process Quality

Posted by David Bressler

Hey everyone! I haven't written in a while because I'm still getting used to my new role and am freshly back from a nice two-week vacation. Why does all the juicy stuff get released while I'm away? Anyway, I'm sure it's not about me (this time). [Apparently I have a lot to say! Sorry for the length of this post in advance. The short version is: 1) It's all about improving "business quality", and 2) Make sure to read the Gartner blog referenced below.]

I wanted to weigh in on this RPM thing... Last week we announced the launch of our Responsive Process Management (RPM) suite. What's it about? I'll leave the "brochure-ware" posts to the marketing folks. I have been talking to many of our customers and field, and while there's some confusion about what it means... RPM's benefits are quite obvious.

It's all about the "quality of the business".

Now marketing may not like how I leave out all sorts of important words/phrases... like real-time business visibility, immediate sense & respond, or continuous process improvement. Those concepts are all very important but they sound very familiar.

What differentiates the Progress solution is that we're enabling, quickly and layered over your existing infrastructure, the ability to react in real-time to your business conditions and exceptions to more tightly control the quality of your business as your customers experience your service/products.

Don't get caught up in the words. Progress' offering is new (and IMO innovative). I know, the jury's out and we have to prove that. But trust me on this one... at least long enough to let me explain.

Let me start by pointing out that all other vendors that "already do that"... well they don't. Don't believe me? Believe Mark McDonald at Gartner. In a blog from February 2010 he points out:

"... in 2010 more than half of CIO's do not feel confident in their ability to achieve results when improving business processes."

If all these other vendors have had a solution for this problem in the market for five years, but 50% of CIO's still don't trust it, something's wrong with the solution.

We can argue this point back and forth for hours, as vendors, because we love our solutions and it's a totally unproductive waste of time. Of course I (usually) believe my stuff is better than others. If not, I should just go get a job with the other guys. Right?

So, let me share some personal thoughts on process quality, what it really means (from a consumer's perspective, my own experience with a bank on a recent transaction), and it's importance will be obvious. I'll not attempt to prove that the Progress® RPM suite is better than the others here... but I hope you'll leave with an understanding of our intent and some of the less obvious challenges companies face when trying to solve problems with their business process quality.

I recently used a government program to refinance a home through Wells Fargo Bank. It's a very paper heavy process. I had the original mortgage with Wells Fargo and since it was a government program, there wasn't any variability to the process. It's a coastal property, so they need to verify up-to-date flood insurance. Of course, since they held the original note on the property -- they had up-to-date flood insurance proof on file.

A few things struck me right away:

  1. Even my mortgage broker had no idea what the process was like because it was a government program. He told me that he'd submit the information, and eventually something would happen.
  2. The person who eventually called (couple weeks later) and asked for my insurance certificate (which, remember, they had on file -- and, yes I could have canceled the insurance, but I sent them the same proof they had on file, so my point stands.) didn't leave a phone number. Or an application tracking number. Or an email address. Just a fax number and a first name. It took me a few days to get to a fax machine, on which I left my phone number and email asking for a confirmation of receipt because I wanted to make sure we completed this step.
  3. I got another call (from another person) to discuss the process and confirm the final information. The inbound caller ID didn't show my bank's name, so it went to voicemail. It took me a couple of days to return the call during which she called again. When we finally spoke, she handed me off to yet another number/person who I'd have to call if I had any questions when I received the closing package.
  4. The closing package asked for the insurance certificate again. And, the loan amount was higher than my current balance. The HUD-1 I got had the same numbers, but they weren't explained anywhere. Having all the dysfunctional experiences above, I had very little confidence in the process and almost decided to scrap it. I had to call the call-center again. When I did they quickly and clearly answered my question and confirmed that they had the insurance info so didn't need it again.

Why did these things stick on my mind? In large part because they're unnecessary and affected my experience with the bank. Do I really want a company this sloppy and disorganized in charge of my money?

The process worked. But, the quality of the process left a lot to be desired. In left me feeling uncertain (as I mentioned, I almost didn't proceed) and it was inefficient for them. Multiple calls to the data center, answering questions that everyone would have and where the answers were readily available. And, before you think it's sloppy human process (the part about not leaving a return phone number with questions, etc.)... there are tells that can be used to recognize poor human process too (like tracking how many calls to the call-center occur per mortgage, and how long the average response time is to each time they ask me for information... and whether there is a correlation, etc.).

Process Visibility

Somewhere, someone in the bank knew the process. They had to. But that information wasn't shared-with or accessible-to my broker. He submitted the paperwork and told me I'd hear from someone.

If you worked with two banks... one said "we'll call you soon" and the other said "you'll hear from us by Tuesday, after that you'll get a package in the mail that you'll have to get notarized and return, the whole thing should take about 6 weeks, so by March, you'll be on the new rate" which would leave you with more confidence? Which is the better experience?

Companies need to be able to track the end-to-end business process. And, as Mark McDonald points out, they need to do that regardless of whether the process is embedded in their legacy systems, formally orchestrated in a BPM engine, or ad-hoc across distributed services (or all of the above!).

Frankly, it must be really hard to do, or more companies would do it. Was this process hard to track because it was part of a government program? Was it handled by different "systems" or teams for compliance reasons? Was there an external government processor that the bank integrated with and left the bank without a clear understanding of the SLA? Was the technology just not agile enough to meet the speed of the business? Said differently, the government was able to roll-out a refinance program faster than Wells Fargo's IT team could react, leaving Wells Fargo hanging with both the government and their frustrated customers. We all know the government is slow... is Wells Fargo's IT really slower?

Flood Insurance

This one baffles me. Aside from the fact that they already had the information they needed, it took me a few days because they wanted it via fax. I was uncertain because I thought maybe they needed something different than what they had, and was frustrated because I had no way to communicate with the person requesting the information.

I'm pretty organized. All my paperwork is scanned and searchable on my computer (and backed up!). Had I received an email request for information they would have had it in 5 minutes. Instead it took 5 days. That sounds like a compelling optimization. Someone has to care how quickly these things get processed (besides me and President Obama). Wasn't one of the early criticisms of these programs that they weren't being implemented quickly enough? After reading this story, do you wonder why?

Loan Amount

I was told it was a no-fee process, but the loan amount was way too high. I figured the bank didn't know what they were doing. A reasonable assumption based on my prior experience with the process. My call to the call center cost the bank money, and took more time. In truth, it was two calls. The first time I called they were too busy, and I waited then had to hang up. Why not just explain it clearly up front? Do they even know how many customers call with questions once receiving the paperwork? Do they know the length of the calls? Perhaps they can see the length, realize it's a quick question, and see if they can improve... again, it's not about the people or thought that goes into things. It's about sensing current business activities, and responding to patterns to improve the quality of the business.

Summary

Finally, I'm actually annoyed that I had to call the bank to see what the rates were. In fact, the bank should be scared of that as well. Imagine if I had called a competitor instead? Apparently the federal program I qualified for had been available for a while. Why wouldn't the bank have reached out to me? It would have impressed me, but also ensured I didn't call that competitor. In fact, this is a use case I worked on recently with an insurance company (different process, same idea).

Imagine being able to sense your customers' behavior and respond to their needs before they have a chance to look at a competitor?

Understanding the quality of the end-to-end business process and having the ability to take action based on events in real-time... that's Operational Responsiveness. It elevates the game and creates a barrier to entry against competitors. That's what the Progress® Responsive Process Management (RPM) suite is meant to deliver for our customers.

15 March 2010

PRGS Announces the RPM Suite - A Convergence of BTA, BEP, and BPM

Posted by Pam Gazley

It’s been raining here in Massachusetts for 3 days straight, but today I got to add a NEW acronym to my arsenal...

Introducing RPM - Responsive Process Management

In case you missed it, a Progress Software press release went out this morning that announced the launch of our NEW Progress Responsive Process Management (RPM) suite. The Progress RPM suite brings together our best-in-class solutions for Business Process Management (BPM), Business Transaction Assurance (BTA), and Business Event Processing (BEP) (most commonly referred to as Complex Event Processing (CEP)). The Progress RPM suite will enable enterprises to achieve a higher level of business performance than previously possible. It is scheduled to launch in late April, and the market opportunity for this type of solution is expected to be greater than $10 billion [based on IDC Research*]. The release includes a quote from Maureen Fleming, program director of IDC's business process management and middleware research service:

“Over the past two years, one of the fastest-growing areas of software investment by enterprises has been to improve their situational awareness. Logically, the next step is broadening the focus to not only gain visibility into problems or opportunities but to rapidly respond. Enterprises will increasingly look for vendors that offer a knowledgeable and comprehensive approach to building this next generation of critical business applications."

It may sound like a pretty complicated implementation but core to the Progress Responsive Process Management suite is the Progress Control Tower™, a unified product dashboard, or GUI, that displays real-time alerts, interactive interfaces and tools. The Control Tower will provide users with the ability to view what is happening within their business and to improve it from a single source - thereby gaining greater ROI. It’s fully configurable, feature-rich, interactive framework delivers a wealth of relevant, KPIs and business information. What’s more, a powerful modeling environment enables new business processes to be rapidly created, modeled, monitored, controlled and improved dynamically.

Rpm_resources
To learn more, read our 7 page brochure and visit our website. We've also written the white paper Achieving Operational Responsiveness Through Responsive Process Management that you can register for.

Over the coming months, we’ll introduce more collateral, white papers, and webinars so stay tuned.

TTYL!

08 March 2010

Rumblings in the Cloud

Posted by The Progress Guys


Cloud computing... it's on everyone's mind these days. Personally I think it's a term that has attained such aggrandized acclaim that vendors, analysts, bloggers and anyone with marketing muscle has pulled and stretched its definition to such and extent that it could mean just about anything hosted. Cloud Computing Journal polled twenty-one experts to define Cloud Computing.  Just the fact they had to ask the question of twenty-one experts is rather telling in itself.  Well I read what the experts had to say.

So armed with my newly minted (yet fully stretched, but not of my own making) Cloud definition I happened upon this commentary about CEP in the Cloud or the lack thereof.  There's a great quote in the article: "I don’t care where a message is coming from and I don’t care where it’s going”. Correctly indicated, this in a sense defines a key aspect of CEP. Event-based applications should be transparent to messages (or events to which messages transform) origin and destination (sans a logical or virtual name).  However, unlike the author Colin Clark, I do believe the current crop of vendor products, most notably Progress Apama maintain this separation of the physical from the virtual.

The rationale behind the lack of CEP-based applications in the Cloud (ok, there's that word again) are found in other factors. To explain my reasoning I'll start by dividing CEP-based applications into two categories. Of course there are many ways to categorize CEP-based applications, but for the sake of this discussion, I'll use these two:

CEP-based Application Categories
  1. Those that do things
  2. Those that observe other applications doing things
Not sure I could make a simpler layman-like description, but needless to say it warrants further explanation (or definition in sticking with our theme)

CEP-based applications that do things
This category is best explained by example. Typical of event processing applications that do things are those in Capital Markets like algorthmic trading, pricing and market making. These applications perform some business function, often critcal in nature in their own right. Save connectivity to data sources and destinations, they are the key ingredient or the only ingredient to a business process.  In the algo world CEP systems tap into the firehose of data, and the data rates in these markets (Equities, Futures & Options, etc.) is increasing at a dizzying pace. CEP-based trading systems are focused on achieiving the lowest latency possible. Investment banks, hedge funds, and others in the arms race demand the very best in hardware and software platforms to shave microseconds off each trade. Anything that gets in the (latency) way is quickly shed.

In other verticals, an up and coming usage of CEP is location-based services. This is one that leveraging smart mobile devices (i.e "don't care where the message is going") to provide promotions and offers.  
    • Algo Trading, Pricing, Market Aggregation
    • Location Based Services (providing promotional offers and alerts)
CEP-based applications that observe other applications doing things
Conversely, event-based applications that observe other applications doing things are classified as providing visibility or greater insight into some existing business function. These event-based applications overlay business processes to take measures to improve their effectiveness. As is often the case critical business applications provide little visibility or the information is silo’ed. There is a need to provide a broader operational semantic across a heterogeneous mix of business applications and processes.  Here are a few typical examples of event-based visibility applications observing other business systems.
    • Telco Revenue Assurance
    • Click Stream Analysis
    • Fraud Detection
    • Surveillance
Of  course the demarcation line between these two classifications is not clear cut. Providing greater visibility is just a starting point, monitoring for opportunities to take action is just as important such as kicking-off a fraud watch if a suspected wash-trade occurred  (so in a sense they are doing things).

Where for art thou oh CEP
When considering the Cloud, an important point to consider is dependency. Specifically, there is a dependency that the underlying applications and business processes exist in the Cloud for (observing) CEP to overlay them.  I would offer that Enterprise business has not yet migrated their key business processes to the Cloud on a widespread scale just yet. Why not? What are the barriers? Security, regulatory compliance, DR, investment costs, limited skill sets are just a few of the challenges mentioned in this ITProPortal article.  I suspect these barriers are far reaching, keeping the pace of Cloud deployment in check to the point where it's not as yet strategic to many.
 
One of key things that makes the Cloud a reality is virtualization, it has clearly revolutionized PaaS as the Cloud. Virtualization does come at a cost, there is a latency penality for the conveinence, no matter how small for some use-cases that cost is too great.

Make no mistake, I am certain the Cloud with all it's twenty-one definitions is the future of computing. It's an imperative that will knock down the barriers and change the face of the Enterprise and when it reaches critical mass CEP will be there.

Once again thanks for reading, you can follow me at twitter, here.
Louie




Enter your email address
to get alerted when new
entries are posted:


AddThis Social Bookmark Button

 

Powered by TypePad