Thick or thin for heads-down workers

Thick or thin, that is the question. At least for 'heads-down' workers typically involved with processing large amounts of information on screen extremely rapidly, thick client applications have long been considered the only way to go.

Proponents of thick clients used to argue for the richness of UI that could be presented, but I feel that modern browser based apps on the web show that this doesn't have to be the way. I'm sure you have your favorites you use every day.

So it comes back to performance - speed of refreshing the screen and displaying information. Heads-down users need the applications to work fast, update dynamic data rapidly, display document images in sub-second times, so that their boss can benefit from an aggregate of 'per-click' savings. Thick client-server apps claim the gold standard here.

Can dynamic AJAX applications really keep up? After all, the limitation here becomes the latency of the network. Can browser applications compete with the thick client running on an over-inflated PC generating dynamic displays from data cached ahead of time? Unlikely, as the thick client probably wins every time, pulling data behind the scenes in large chunks.

So, can we really say that browser based UIs are suitable for heads down workers, or are they just more convenient for IT in not having to roll out complex installable applications? Or are browser based apps up to the task? After all modern networks are fast, clever data caching can be built in, and new Javascript engines are claiming to get orders of magnitude faster.

Silverlight and Flash are battling for the new rich Internet application space. I question whether they just provide a nice toolset for building highly dynamic application UIs that roll out easily, or can they really provide a higher performance operation? Don't get me wrong, anything that speeds the design and deployment of applications is a good thing, but when they are really a nice skin on Internet technology, can they offer the performance of a true thick app?

When the standard heads-down applications typically are plain, keyboard driven, frankly having little glitz or glamour, is there a place for rich Internet application technologies? Or will software vendors just adopt them as a sales tool, to out-pretty the other guys.

A post from the Improving New Account Opening blog

Do you trust this blog?

As most educated users of the Web know, there is a lot of misinformation, speculation and lies out there. So who better to trust on the future approaches to help users identify trustworthy sources of information than the inventor of the World Wide Web, Sir Tim Berners-Lee. Reported on the BBC News website, Sir Tim discussed a range of issues facing the Web, as he publicized the creation of the World Wide Web Foundation.

Interestingly, the issues faced by consumers outside the firewall should be concerns for organizations deploying web style collaborative and social tools inside the firewall. In a small organization, my job title and personal contacts are usually enough to generate trust that the information I post on a Sharepoint site or blog is authoritative and can be used appropriately. People know me, or at least know of me, and trust that my role in the organization can help answer a question they have accurately.

In a large organization, as with the Web, reputation is harder to ascertain. Toby Bell at Gartner talks about reputation from many angles, often with the view that reputation can only come from the aggregation of everything you write and link to, as well as your closest contacts. This doesn't give me a view of someone new at a glance though, which is one of the issues that Berners-Lee would like to see addressed, since how many of us have time to read enough to really assess a person's authority.

I'm sure that there is no easy answer to this issue. Much as Wikipedia tries hard to separate truth from fiction, organizations need to be sure that formally published policies, procedures and compliance documents are instantly recognizable and clearly segregated from more democratically published information, however authoritative the author may be. For CYA that seems to be a defensible approach.

I strongly believe in the value of collaborative technologies. I don't know that they will change the world, but certainly as more of us try to travel less, their use will grow, and the risks of 'wild wild web' need to be understood to ensure we all realize their value.

A post from the Improving New Account Opening blog

SharePoint for Production Applications?

First, imagine you run a claims department for a large insurance company, or the customer service center for a top-tier bank. Then imagine the many line of business and information systems your employees use every hour of every day to get their jobs done. Finally, consider how much better their productivity and job satisfaction could be if all of the information and resources they needed were presented within a single application environment. No more carpal tunnel syndrome inducing Alt-Tab maneuvers, mornings spent carefully arranging application windows in that early Windows style, or lengthy (dull) training on several very different applications.

I have spoken to many the leaders in many organizations, run by people that you are currently imagining you are, who have recognized the appeal of bringing together all the applications their people use into one place. The approaches that are taken vary, depending on the exact need, and which software industry analyst makes the most compelling pitch. Anything is possible, including enterprise portals, 'roll your own' SOA/EAI applications, consolidation to a single platform in the SAP R/3 style, and presentation with the line of custom applications built on document management and business process management suites. And without naming names, there are many examples of the different approaches becoming extremely successful, or becoming another annoying window on an already overcrowded screen.

SharePoint, accompanied by its enormous marketing budget can't fail to make it into the departments you are imagining you run. Its appeal of being cheap, easy and 'good enough' makes it an important option to be considered. So, ask yourself this:

1. Does SharePoint offer enough value as a pretty configurable presentation mechanism / portal to make up for the fact that (in my experience) its just painfully slow to use?
2. Does it provide the integrations you need with the many core systems and information systems you have in place to plug and play (how many BizTalk skills do you have in house)?
3. Do the Web 2.0 style, collaborative team space capabilities of SharePoint provide application components that truly benefit your workers?
4. Does your organization need another application layer of 'can do lots of stuff' that pays little attention to the value it offers to the business?

In some cases, the business leaders I have met could answer 'yes' to all of the above, and are starting to try out SharePoint in their environments. In other cases, other business leaders actually have a vision to address the root cause of the mosaic of applications their employees endure. They have asked themselves a different set of questions:

1. Is there a way to show users just the information they need within the context of a single business application, not a series of segregated application portlets or panels?
2. Is there a solution that can deliver work and guide users to complete the tasks I know need to be done, rather than having to train them to always remember what must be done next?
3. Can the skilled knowledge workers have the flexibility to do what they need to do, without being limited by a production line workflow?
4. Is there a solution that can provide the best of both worlds - a targeted business solution and a flexible platform which allows me to adapt to a changing business environment?

I personally don't think that there is any one answer. As the imagined business leader, you'll be balancing an operations/IT budget against a need to deliver business value in the shortest amount of time. Some organizations will make use of SharePoint where it fits their needs best. Others will try and force fit it into applications it doesn't do well.

As the business leader, I think you have an easy question to ask yourself. Does a software solution help you meet the objectives of the business (increase revenue, reduce expenditure, etc) with the better working practices that it offers, or alternatively just provide an attractive UI and collaboration functionality around your current working practices?

A post from the Improving New Account Opening blog

Privacy or personal responsibility?

Privacy of your personal information seems to be almost as hot a topic in Europe as the price of gas is in the States. Much like tax on petrol in Europe seems to be the cost of doing business, anything less than identity theft seems to be acceptable here in the US.

The fact that there has been yet another lost PC, USB drive, backup tape, or whatever, with tens of thousands of records of personal information on it is worrying. Cloak and dagger stories aside, the fact that these are routinely linked to the security services or the company contracted to provide secure ID cards for every UK citizen, big brother is failing (or not, depending on who picks up that information, says the cynic in me).

I work with government agencies and financial services companies who routinely are subject to their own internal security audits and ethical hacker test scenarios. And like anything with a moving target, sometimes they miss. Fortunately I will say, I work for a company that takes this very seriously - in line maybe to preventing production data loss from a software 'glitch'.

The problem is that individuals aren't held equally responsible. Catching up on a few days of many weeks of missed blogs, I ran across this one, A true, global Big Brother case. The story here is how trackable you become when you use a Bluetooth headset, and you don't take the responsibility to understand that it being in range of some other device that can 'discover' it, means that you can effectively be tracked as you move from place to place.

Should you have to care? Probably not. But I'd hate to see another mandatory warning having to be put in the oversized headset box, when perhaps the software that helps you set this thing up could warn you of the risks that naming the device with your phone number or name makes you identifiable - your risk, choose to be stupid if you want to. Of course, the phone you are carrying with it, with the SIM card, GPS, and so on leave you pretty open anyway, just more anonymously.

Privacy, or having your movements tracked anonymously at least, could be nothing to be feared, as long as you don't put yourself in a position where the use of the tracked device could incriminate you. Being concerned about big brother is reasonable, but worrying about it may only be for those with a guilty concience.

Am I concerned about having big brother track my movements? Of course, but Google does so virtually with every online step. There is, it seems, no escape!

A post from the Improving New Account Opening blog

Relaunch?!!

I've considered getting back into blogging more frequently. The last post was end of last year, so it shouldn't be hard to do just a little better. I considered starting a whole new blog, with a new name, new style and so on, though that represents a large barrier to (re)entry, so I'll just jump right in. The biggest change will be that I'm going to try and write short, sharp and maybe

Over the next few weeks, you can expect me to write about my opinions on the trends in technology, business solutions, social networking, ECM, BPM, SOA and maybe the occasional unrelated rant as well. As ever, the thoughts, expressions and opinions are mine and mine only, so no blame should be aimed at my employer. And if you work for competitor, you are welcome to read this blog, but don't expect to find any insight into the intellectual property of Global 360!

I'm looking forward to posting and hearing your comments too!

-- Phil

A post from the Improving New Account Opening blog

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