Loyalty for financial products

The festive season has given me a little time to start reading some blogs again and spend a little time thinking and writing. A couple of the interesting posts I came across relate closely to some of the research I have recently been doing around financial services and the value of financial products and their associated customer services.

To start with there were several discussions around something that many of us have contact with around this time of year - the loyalty program. Love 'em or hate 'em, the loyalty program has introduced itself into every type of company that depends on repeat business. One of the longest running types, the frequent flyer programs run by airlines (e.g. BA, United) and alliances (e.g. Airmiles, Star Alliance) have traditionally been placed to encourage frequent travelers to always fly with the same airline. In the past the benefit to the customer of this was twofold: firstly to collect enough 'miles' to redeem for a free flight for pleasure; second, to gain status to receive upgrades and enhanced customer service. The cost of these programs could be assessed by the airlines and shown to provide the return of constant repeat business from customers.

As the post The declining value of loyalty plans on The Bankwatch blog highlights, the loyalty program experienced by many travelers is being perceived as much lower value than in the past. In the post, Colin states:

So stepping up a level, loyalty points and plans are only of value if the customer feels value.  Fewer are feeling that value nowadays, and those Banks who pay for those plans, should think about that.  I think the loyalty plan model is broken.

The implication is that airline loyalty programs are failing to meet customer expectations and therefore may not lead to the repeat business that is built into the business model. The question is whether there are things that financial services institutions do for their customers that actually reduce repeat business.

Colin's post was actually in reaction to Customer Experience Matters More Than Points In Building Loyalty on Forrester's Marketing Blog, which relays the experience of Shar Van Boskirk in traveling recently:

Except!  That I am really bothered by Linda's mantra "I don't care who you are or how much you travel."  Now the idea of a loyalty program is that you DEFINITELY care how much I travel and I've found that my fundamental weakness as a traveler is that I really want people to care who I am.

The loyalty program has degenerated from the ability to build status as a traveler to achieve enhanced customer service and rewards, to the one thing that may get you home on the same day you started traveling when the overbooked airline starts prioritizing the handout of the last remaining seats on the only flight that hasn't been canceled. This means that use of frequent flier benefits only reinforces in my mind how poorly an airline is operating since I'm only using the benefits to negate a failure on the airline's part. This is more of an 'anti-loyalty' program...

Does this relate to banking and financial services in general? As banks and other institutions realize that customer service is core to retaining gaining more market share, understand customer loyalty and attracting new customers is key, while avoiding reinforcing negative perceptions should not be overlooked.

An oversimplification is that much of the whole model of retail banking is built on repeat business and that banks can just assume it will happen: a bank account ties you to doing business with the bank. If I want the bank to hold my cash, I have to pay for their transactions to make a transfer. At least with my bank there is no explicit loyalty program, beyond them offering a reasonably competitive online banking service that doesn't annoy me every time I use it (i.e. being marginally better than other banks). As a standard customer if I want the equivalent of premium service I basically have to pay for it through additional charges, and traditionally its been hard to move bank accounts, so I'll not do it too often.

To a bank this may appear to make a lot of sense. In everyday operation there is little to differentiate me as a customer from almost every other customer that maintains a relationship with the bank; my salary is deposited into the account and sits there until I pay some bills and maybe move a little cash to a savings account - pretty much the same as every other professional person. Attempting to segment me based on this limited information does not help the bank offer me better services or do something that will help stop me moving to a new bank.

The best many institutions do is offer a basic form of loyalty bonus such as offering better rates of interest on a new savings account to current customers. Brokerage accounts can offer a sliding scale for charges based on volume or offering cheaper trades to buy into their investment products also offers a loyalty incentive.

Customer service remains the new frontier of financial services as it becomes easier for customers to find and move their money to new institutions. For financial services loyalty and repeat business still have some major stumbling blocks:

• No aggregated view of a customer is available that the bank can use for managing my relationship and offering reasonable customer service when I call a branch or call center
• Information is not shared between business units, preventing me easily signing up for new products online
• A single / complete view of me as a customer is not available so that the bank can see whether I am actually a great customer owning multiple of their products (and therefore worth working harder to retain) or just a mediocre customer with a savings account
• Based on limited information, segmenting customers for marketing new services and products is impossible
• Credit agencies are often seen as the primary source of aggregated information about me. Does a FICO score really offer appropriate metrics for offering me appropriate products and strong customer service?

Many of the issues relate back to opening a new account with an institution. Only with an accurate view of a customer from that point of 'on-boarding' through the customer lifecycle can a true relationship be effectively managed. In my opinion many financial services institutions have a lot of work to do to get an accurate and unified view of their customers, let alone measure and use the metrics that really identify the customers worth concentrating on.

What makes IT better: ITIL, COBIT, or people?

The last time I thought about IT 'governance' in-depth was a while back. Of course everyone claims its top of mind when thinking about SOA, since that same 'everyone' is trying to convince the business guy with the cash that the business and IT have converged, and he should spend his money on more tech stuff. And its true that if you really design meaningful services they can reflect the what the business does, which in turn enables a business leader to ensure he or she will meet the business objectives that demand a big fat bonus.

The last time I thought about IT 'governance' in-depth was prior to working on how SOA makes IT better, or beating business goals with process optimization. This was back when I concentrated on 'compliance'. In the good old days when SOX was new(-ish) and still hyped (although according to Google Trends, it never compared to the Red Sox or White Sox that dominated the sporting public's attention), I paid a lot of attention to the details of how organizations really became and remained compliant with the mass of legislation and regulation out there.

From a business standpoint it was easy - COSO was recommended by the SEC as a fine framework for documenting and testing your internal controls to ensure compliance, even though any sort of framework for defining how effectively you did business was considered radical and expensive.

IT, probably because it was always a left-brain discipline, had many frameworks that were favored and used extensively. Especially when IT was expensive and often owned only by governments or the military, minimal risk of failure (or at least the bureaucracy around CYA) was considered essential and led to the use of frameworks such as ITIL. This was intended to ensure that every phase of telecoms and technology usage, from acquisition to deployment, to eventual failure and fix was defined (if not by the framework itself, by the poor team attempting to implement and run a system).

COBIT on the other hand offered an apparently focused approach to IT governance, since it limited its scope to IT controls - the automated bits of business worried about maintaining systems to perform consistent decisions. The problem with all this was that most organizations already had some form of adopted framework. SOX compliance for IT often became a 600 page bound work of photocopies from other frameworks, printed screenshots, and a little summary of the true processes that the IT organization followed in putting new systems into production.

In reality, what IT framework do most organizations use? And how well does this tie back to the emerging governance requirements of SOA? What does the outside world do? And how does this vary between financial services organizations, government, software or others? People are core and their consistent and effective communication is as important as any framework. Without good people, most frameworks will fail.

Jim Sinur - blogging at last

A very quick post to introduce readers interested in BPM, business problems and technology, to Jim Sinur's new blog. Up until earlier this year Jim was the lead BPM analyst for Gartner (and had some extremely fancy title to go with it), so he has huge insight into the BPM industry, its customers and its technology.

Jim now is Chief Strategy Officer for Global 360, but as you'll see from his blog he still retains strong independent views on everything related to business process, which should make for some interesting reading. Let me encourage you to subscribe to Jim's blog now.

BPM or ERP - Stand out from the crowd

There are many times I've heard about BPM being described as the panacea to almost every type of business problem. Much in the same way that SAP (or Oracle) would describe ERP as being the true way of implementing solutions to your organization's specific problems. Unfortunately to me this seems like an "all or everything" situation. All business problems that SAP has ever bothered to consider valuable are covered in its ERP. Everything that ever needed process automation that you couldn't justify using SAP for can be implemented using BPM.

It seems to me that there is a whole lot of business problems that are best solved by ERP just because everyone else does. Any business process that requires industry best-practices to be replicated across the board, or application that offer your organization little differentiation are just these. ERP has these coded straight out of the box, so why bother reworking them using BPM for your organization? If these represent good learning processes to achieving BPM excellence, or you have BPM expertise and technology in house already, perfect! Otherwise, BPM is far better for processes you want to differentiate.

Now imagine that you run a business unit of an insurance company. Does your claims process really differentiate from the competition, or is it really the speed in which you pay, or the customer services that support the process that are really different? This is where BPM wins, even though ERP or boxed software could run the same process. Process optimization provided by the best BPM suites provides the analysis of process information and opportunity to improve performance based on real-time business metrics that a restrictive ERP concentrated purely on business data can not. Case management based BPM provides the contextual view of data across many systems that can make customer services really differentiate your service.

ERP and BPM both offer good solutions, often for the same problems. Pick the right solution for the right application - and when it matters, stand out from the crowd and do something different using a BPM based enterprise application platform.

Technorati tags: Financial Services Technology New Account Opening BPM ERP

A post from the Improving New Account Opening blog

Facilitate or Automate?

Keith Swenson has been writing some great posts on the differences in modeling what he calls "Automator" and "Facilitator" processes. Automators aim to model and control every interaction between systems and potentially also human users. Facilitators on the other hand model at a much higher level, showing the key participants in a process, and the overall flow, but do not need to delve down much beyond this, relying on the underlying system's abilities to assist users.

Keith's post from a week or two back, Human "Facilitator" Processes really lays this concept out well. He shows how a Facilitator process models the interactions between a writer and an editor in the process of preparing an article for publication. Its a two step process that I don't even need a graphical modeling tool to represent:

O ----> Writer: Write Article ----> Editor: Review Article ----> X

All in a single line we have represented the key participants and interaction between the writer and editor. According to Keith:

In order to explain this process to a person who was to participate in this, the two nodes would be enough: Betty will write the document, and when completed, George with review the document. Both Betty and George understand their role in the process, and can go about their work.

This only makes sense because most of us (especially Betty and George) understand the process this model is trying to represent. At this level, we don't upset the knowledge workers in the process by limiting their creativity with unnecessary administrative tasks or presuming that we know how to do their jobs better than them. This is the classic 'paving the cowpath' approach to process improvement that really centers on the delivery of work between users (remember the document management workflow world?).

The Automator that Keith talks about focuses on the 'server' and what it does. It deals with the automate-able pieces of the process and just presents work to Betty and George when it can no longer automate. It basically represents the system as an execution / delivery model that saves a developer writing automation code, and relies little on the capabilities of the executing system. If you BPM tool wants to execute at this granular a level, great, but don't expect to benefit from new features it may release in version 6.x without explicitly building them into a process. Do expect to be so restrictive that your users reject the system.

In his most recent post BPMN & Methodology Agnosticism Keith talks about how a modeling standard like BPMN, which is supposed to provide common understanding of process models still implicitly represents much of the underlying capabilities of the system that executes it. This is something that is encoded by the underlying and potentially unwritten methodology of the analysts that designed the process, a methodology that is rightly (I believe) biased towards the available capabilities of the target system.

I like this. It feels like there is a place for me and 'my BPM'. It feels like I don't need to have two steps or 50 steps to represent a business process. If 'my BPM' handles assignments, deadlining, escalation and event handling in a meaningful and flexible way, I don't have to draw this stuff on a model. If some things actually don't fit well in a process but are better represented by other capabilities of my system, even better. As I talked about yesterday in Don't forget the real end-users of BPM, process models shouldn't have to be the center of the world.

With a mixture of Facilitator and Automator plus a whole lot more, my process model really represents the valuable work my people and my systems actually do. A process model drawn in a modeling tool at this level would be understandable to someone outside the organization (think of all the SOX documentation you have describing processes in your organization that an auditor must examine). At the same time I can ensure it is not restricting the knowledge worker but 'facilitating' his or her everyday tasks, while automating the dull meaningless stuff. I suppose that 'my BPM' is an Automacilitator...

Technorati tags: Financial Services Technology New Account Opening BPM

A post from the Improving New Account Opening blog

Don't forget about the real end-users of BPM

BPM is obviously very much about process, but I feel that obsessive focus on the process model reinforces an abstract view of the business that misses a large part of the story. BPM software vendors are guilty of producing BPM suites that reinforce this view. They present their systems from how pretty and easy to use their process modeling tools are, and how multiple process analysts can work on a process simultaneously - treating the analyst as the primary end-user.

The reality is that the handful of process analysts are not the most important end-users of BPM software - the primary end-user is the business user that participates in the process to do his or her job and contributes to the success of the organization's critical operations day in, day out. Why do BPM vendors rarely focus on the hundreds of 'true' end-users?

BPM software often sells exclusively to business analysts. Analysts rightly need tools that facilitate the design of effective processes. And building pretty design tools is a sure way of selling software. After all, just like buying a car, most business analysts should be expected to go for tools that appear powerful and have a nice shine.

A true business application design platform concentrates on the business end-users first: what will they see, what documents do they use and create, what other sources of information do they access and what tasks do they perform? Process is obviously core, and often represents an orderly structure that many of these other things hang off of. With a platform that only focuses on process, rather than providing a framework for actually running all components of critical business applications (including business process) an organization is left to build a whole lot of technical infrastructure from scratch. This leaves the business users depending on applications that are limited by the skill of an organization's masses of software developers.

Now don't get me wrong, clean and accurate process design is an essential component of effective business applications. But failing to provide the equivalent focus on the sharp end, the actual execution of the newly perfected processes inside a meaningful business application can leave an organization trusting its critical operations to software that is more worried about 10 process analysts than 1000 concurrent users.

Technorati tags: Financial Services Technology BPM

A post from the Improving New Account Opening blog

You can't manage what you can't measure

Last week was fun and informative with a great Global 360 customer conference. With so many new releases timed for announcement, some would believe that the organization was just putting out new versions to conveniently appeal to the customers at the event. I know from being part of the release planning process that this was not the case - the new releases for BPM and process intelligence are incredibly strong and compelling and offer a level of integration with the business on one side, and the users desktops on the other, that is unrivaled.

My colleague and relatively new blogger, Mike Letulle, talks about the importance of process intelligence in his post You can't manage what you can't measure. His discussion lays out a little of why the new Insight360 release is so important.

I'm going to let you enjoy his discussion, while I get back to work on planning some more product releases to help organizations deliver valuable solutions that differentiate their offerings with improved accuracy, faster response and having customer information at their fingertips: the type of customer service that is more compelling than a smile and a 'have a nice day'.

Technorati tags: Financial Services Technology New Account Opening

A post from the Improving New Account Opening blog

Online security - fix the source of the problem

Randy Janinda responded to my post from a while back, Citibank Hardware Tokens Defeated... at the exact time that Bank Systems & Technology talks about how Bank of America is attacking the weakest link in online security - user's desktops:

Recognizing that defenses are only as strong as the weakest link, Bank of America has moved to shore up an area that largely is beyond its control: customers' desktops. In a move experts say is a step in the right direction toward improving online banking security, the Charlotte, N.C.-based bank announced a partnership with Symantec (Cupertino, Calif.) in which the bank will offer the security solutions provider's software to online banking customers.

This is certainly a step forward, although it cynically just looks like a great marketing ploy by Symantec at this point (just another channel for promoting a 90-day free trial). And to Randy's point it does not address the hardest point to protect against - phishing - and fooling people into handing over their authentication. How can banks help customers protect themselves so that they don't have to jump through hoops to detect scamming websites? In an environment where software can be installed on a customer's PC, like BoA is trying to do with Norton, there must be software that can reinforce the browser against phishing attacks. This may have to be the next thing that BoA offers.

Technorati tags: Financial Services Technology phishing

A post from the Improving New Account Opening blog

Component stack - a simplified architecture for applications

Its been too long, with lots of work, travel and vacation, apparently leaving me with no time to blog. I'm back, but a little rusty and jetlagged, so bear with me!

James Taylor posted today on Enterprise Decision Management Blog about a post by Roeland Loggen on his blog - BPM Suite as a component in a logical architecture. Roeland proposes a BPM-centric architecture that plugs into a range of other components to handle administrative type processes.

James suggests some enhancements to the architecture, largely to ensure that the Decision Platform can interact with the Complex Event Processing (CEP) and Business Activity Monitoring (BAM) components. I agree with his rationale, and would even take it a step further - every component in an architecture (that isn't pure technology) should be able to interact with every other, ensuring that really advanced business requirements can be considered, offering more and more business value.

As ever we should avoid point to point integration of every component in the architecture, instead components should offer services that can be consumed by one other, both for rigid (generic) use cases and to meet application specific requirements. Having SOA technology and a strong integration platform underlying the architecture seems like an essential requirement. SOA technology also provides the ability to host the final application as business services that can be reused in other applications across an organization or by business partners.

A benefit of taking a services approach is that generic architectures like Roeland's are simplified - they are effectively flattened; every component can benefit from every other and the architecture doesn't need a hundred lines showing the explicit connections between all of them since the connections are handled by the SOA / integration backbone. This backbone may utilize a range of technologies, and may be effectively hidden from view. Without fancy drawings, the generic architecture becomes a simple list of available components that have been plugged into the backbone, for example:

• Business Process Management (BPM) - incorporating BAM and process analytics
• Decision Management
  
• Case Management
• Content Management
• Customer Database / Information System
• Document Capture
• E-Forms Management
• All plugged into a SOA/integration backbone
  

Taking this stack approach allows business analysts to concentrate on using the components providing higher level business value in the most effective way - not the forced integration of monolithic products. Any particular business application can reuse the same architecture and technical backbone, and will benefit from platforms that are more interconnected out of the box. Specific connections (drawn on an 'architecture' diagram) now represent business use scenarios, and the value of each interaction can be easily seen, especially where new integrations may need to be built. Here is a simple example:

The application here is a fairly generic application processing solution, which shows an architecture that highlights the interactions between the components, already relying on the implicit (and invisible) technology backbone and any available services that are already in place. A different application could show very different connections, allowing the 'architecture' diagram and implementation to closely reflect the business value of the application. The technical architecture would be no different from before - a plain old stack implemented once and used over and over.

Picking a stack that can handle the high level business requirements, while being architecturally strong enough to hide much of the technology complexity, and still allowing the flexibility to meet specific application requirements across many different applications is hard work. Organizations looking to get the best value from their technology investments should look beyond simplistic 'drag and drop' and developer toolkits to ensure that new technology really can deliver complex applications fast, while allowing constant enhancement and new applications to be based on a common platform that can perform as needs grow.

Technorati tags: Financial Services Technology solutions-architecture BPM EDM

A post from the Improving New Account Opening blog

Decoupled services need BPM

One of the key advantages touted by using SOA is the way that integrated systems are 'decoupled'. When I was chatting with a colleague last week about this I realized that the meaning of 'decoupled systems' is less obvious than I originally thought.

When I was reading Roeland Loggen's Process transformation - perspectives on "BPM" blog this morning something he says around the use of process really helped me put my thoughts about 'decoupled systems' into some sort of order.

The post was From interface spaghetti to process coordination layer. Roeland gives a little of the history we are used to hearing around integration: in the olden-days we thought about integration purely as a technical and data-driven problem; technically how do we connect to each system and then join the operations and data elements of this system, to get another system to store, retrieve, update, delete or whatever some related but otherwise completely separate entity in its world? Through proprietary technical protocols and translating the requirements of one system and coding them directly to the data requirements of another. It works, but do this enough times and you have point to point spaghetti.

Its not a new story. What comes next though clearly pushes back on the enterprise application integration (EAI) and enterprise service bus (ESB) approaches to integration. Again, suggests Roeland, these approaches lead to integration spaghetti, just now this spaghetti is standards based (guaranteed pure Durham wheat, made in Italy). Although I would suggest the ESB approach does remove point to point hassles, by at least handling the technical integration layer with each system once only. So rather than needing all the technical integration between each system, the problem is reduced to requiring a transformation of data to be handled for each system to system connection. Doing this we swapped the proprietary protocols with web services (unless you live in the real world of web service interoperability) and made integration more an effort of converting one format of XML document to another.

What Roeland argues nicely is that it is BPM and the management of a process in general, not pure EAI/ESB technology alone, that solves much of the integration problem, especially decoupling systems.

So, what is 'decoupling'? We use SOA principles to access information systems through meaningful business services, rather than system specific APIs; which hides the complexities of the systems themselves. But rather than connecting the output of one service or system directly to the next service request, we decouple them, only making requests to services in the context of the business process - the business process becomes the orchestrator of all activity.

What are the advantages of doing this?

• Process that was originally embedded inside the coding of business systems and services is extracted to a BPM and therefore becomes more manageable and can be updated as needed.
• Integration code does not need to concentrate on a specific process or activity context, since the new business services only rely on the state of the business process to ensure correct operation, not on the hard to maintain state information held inside another proprietary application being in-sync with itself.
• Complex dependencies between applications are broken, making maintenance easier, and the ability to reused services (and their underlying systems) far more likely.
• Process that was previously embedded, that mixed coding specific requirements, integration activities and true business process can focus on the specifics of each in the most appropriate tool: the business process in BPM; integration in code or an ESB; application specific state in the application code.
  

So I think I can finally communicate what 'decoupling' is, and why its so important...

Business level interactions with other services should not be coded within the systems themselves, since this makes it impossible to use them in a different context or even variation of the same process. Decoupling of systems is about removing representation of business process state or cross service interactions from underlying applications, so they generally only interact as part of the business process managed by BPM.

Maybe someone out there has an even better description of decoupling. Let me know.

So after all that, we come back to the convergence of BPM and SOA. It seems that you can not in fact decouple systems and services without BPM - true SOA can not really truly exist without some form of business process orchestration. So why not use the strongest business process management technology, which enables the use and hosting of services straight out of the box? SOA and BPM need each other, and decoupling is just one example of this.

Technorati tags: Financial Services Technology SOA BPM decoupling

A post from the Improving New Account Opening blog