Category: outsourcing

Crowdsourcing And Microwork With DST

In the afternoon, after my BPM COE presentation, I moved over to the AWD ADVANCE technical track to hear Roy Brackett and Mike Hudgins talk about crowdsourcing and microwork. DST and some of their partners/siblings/subsidiaries are business process outsourcers, and always looking at ways to make that outsourcing more efficient. They use the term crowdsourcing to mean the use of a global, elastic workforce, such as Amazon Mechanical Turk; the concept of microwork is breaking work down into small tasks that can be done with little or no training.

There are some basic requirements for allocating microwork, especially in a financial services environment:

  • Quality, which is typically managed by dual entry (assigning the same piece of work to different workers, then comparing the results) or by validating against another data source (e.g., comparing the values entered independently for name and account number against a customer database).
  • Security, which is typically managed by feeding the tasks in such small tasks that there are few privacy issues since the workers rarely see more than a one or two pieces of data related to any given transaction, and have no way to link the data.
  • Priority, which is typically managed by serving up the tasks to workers only at the point that they are prepared to do the work so that the highest priority task is executed first; also, since the work is divided into tasks, many of those tasks may be executed in parallel.

Looking at common work activities, they typically break down to transcribe (e.g., data entry from scanned form), remediate (e.g., data entry from unstructured content where information may need to be looked up in other systems based on the content), business knowledge, and system knowledge, only the first two of which are appropriate for microwork.

DST is doing some research into microwork, so what they talked about does not represent a product or even, necessarily, a product direction. They started with transcription tasks – not that they want to compete with OCR/ICR vendors, but those tools are not perfect especially on images with subpar capture quality – using dual entry, with a remediation step if the two entries disagreed. This could be used for post-OCR repair, or for older scanned documents where the quality would not support adequate OCR rates. DST did a test using CrowdFlower for transcribing 1,000 dummy forms containing both machine-printed and handwritten content on a structured form: single entry gave 99% accuracy, while dual entry increased that to 99.6%.

They then did a pilot using one of their own business processes and real-world data from an outsourcing customer, transcribing fund and account information from inbound paper correspondence. Since only 25% of the documents were forms, they used fingerprinting and other recognition technologies to identify where these two fields might be on the page, then provide image slices for data entry. With the automated fingerprinting that they have developed, they were getting 98% classification, with zero misclassifications (the remainder were rejected as unclassified rather that being misclassified). For the microwork participants, they used new offshore hires and US-based part-time employees, so still used DST employees but with almost no training and relatively low skill levels; using single entry, they reduced data entry errors by 50% from their old-style “one-and-done” data entry technique (and presumably reduced the costs). They then rolled this out to handle all transaction types for that customer in a production environment.

They’re piloting other data entry processes for other customers now based on that success, starting with one that is driven purely by standard forms and has highly variable volumes, which is a perfect match for crowdsourced microwork because of the ease of segmenting forms for data entry and the elasticy of the workforce. There are optimizations on the basic methods, such as sending one person only (for example) tax ID fields to transcribe, since it’s faster to do data entry on a single field type due to no context switching.

The result: quality is improved, with more errors caught earlier; and better productivity (and hence cost) using less-skilled workers and a workforce that can increase and decrease in size to match the volume. There was a great question from the audience about what employees feel about this; the responses included both “we’re using this on the training path for higher-skilled workers” and “this separates out transcription and remediation as services (presumably done by someone whose careers are not of concern to the organization, either outsourced or offshore employees) and leaves the high-value knowledge work”: it’s fair to say that most companies don’t expect to be doing low level data entry in a very few number of years, but will have their customers do it for them on the web.

Gartner warns against shelfware-as-a-service

Gartner’s had a good webinar series lately, including one last month with Alexa Bona on software licensing and pricing (link to “roll your own webinar” download of slides in PDF and audio in mp3 separately), as part of their series on IT and the economy. As enterprises look to tighten their belts, software licenses are one place to do that, both on-premise and software-as-a-service, but you need to have flexible terms and conditions in your software contract in order to be able to negotiate a reduction in fees, particularly if there are high switching costs to move to another platform.

For on-premise enterprise software, keep in mind that you don’t own the software, you just have a license to use it. There’s no secondary market for enterprise software: you can’t sell off your Oracle or SAP licenses if you don’t need them any more. Even worse, in many cases, maintenance is from a single source: the original vendor. It’s not that easy to walk away from enterprise software, however, even if you do find a suitable replacement: you’ve probably spent 3-7 times the cost of the licenses on non-reusable external services (customization, training, ongoing services, maintenance), plus the time spent by internal resources and the commitment to build mindshare within the company to support the product. In many cases, changing vendors is not an option and, unfortunately, the vendors know that.

There are a lot of factors in software licensing that can come under dispute:

  • Oracle’s (and many other vendors’) definition of “named user” includes non-human processes that interact with the database, not just the people who are running applications. This became a huge issue a few years back when enterprise systems started being connected in some way to the internet: is the internet gateway process a single user, or do all potential users have to have individual licenses?
  • Virtualization and multi-core issues need to be addressed; in many cases, these hardware partitioning is often not adequately covered in license contracts, and you need to ensure that you’re not paying for the maximum potential capacity of the underlying hardware, not what you’re actually using.
  • Make sure that you have the right to change the platform (including hardware or underlying database) without onerous fees.
  • Watch out for license minimums embedded within the contract, or cases where upgrading to a larger server will cost you more even if you don’t have any more users. Minimums are for small organizations that barely meet discounting thresholds, not large enterprises. Vendors should not be actively promoting shelfware by enforcing minimums.

Maintenance fees are also on the increase, since vendors are very reliant on the revenue generated from that in the face of decreasing software sales. Customers who have older, stable versions of a product and don’t generate a lot of support issues feel that costs should be decreasing, especially since many vendors are offshoring support so that it is cheaper for vendor to supply it. Of course, it’s not about what the maintenance actually costs, it’s about what the market will bear. Gartner suggests negotiating maintenance caps, the ability to reduce your maintenance if you use less licenses, and the right to switch to a cheaper maintenance offering. Document what you’re entitled to as part of your maintenance, rather than relying on a link to the vendor’s “current maintenance offering”, to ensure that they can’t decrease your benefits. Watch out for what is covered by maintenance upgrades: sometimes the vendor will release what they call a new product but what the customer sees as just a functional upgrade on their existing product. To get around that, you can try licensing the generic functionality rather than the specific products by name (e.g., stating “word processing functionality” rather than “Microsoft Word”).

When polled, 64% of the audience said that they have been approached by a vendor to do a software audit in the past 12 months. In some cases, vendors may be doing this in order to recover license fees if they have lost a sale to the customer and feel that they might find them out of compliance. Be sure to negotiate how the audit is conducted, who pays for it, and what price that you pay for additional licenses if you are found to be out of compliance. Many software vendors are finding it a convenient time to conduct license audits in order to bolster revenues, and for the first time ever, I’ve heard radio advertisements urging people to blow the whistle on their employer if they are aware of pirated or misused software licenses, which is a sort of crowd-sourced software audit.

Software as a service licensing has its pitfalls as well, and they’re quite different from on-premise pricing issues. Many SaaS contracts have minimums or do not allow for reductions in volumes, leading to shelfware-as-a-service – consider it a new business model for wasting your money on software license fees. There is aggressive discounting going on right now – Gartner is seeing some deals at $70/user/month for enterprise-class software – but there may be much higher fees on renewal (when you’re hooked). There are also some unrecognized fees in SaaS contracts: storage (if beyond some minimum that they provide as part of the service, which is often charged at a rate far above cloud storage on the open market), additional costs for a development and test sandbox, premium maintenance that is more aligned with typical on-premise enterprise software support, non-corporate use (e.g., customers/partners accessing the system), integration, and termination fees including the right to get your data out of their system. Make sure that you know what the SaaS provider’s privacy/security policies are, especially related to the location of the data storage. Most of the Canadian financial services firms that I deal with, for example, will not allow their data to be stored in the United States, and many will not allow it to be stored outside Canada.

Furthermore, SaaS vendor SLAs will only cover their uptime, not your connectivity to them, so there are different points of failure than you would have for on-premise software. You can hardly blame the vendor if your internet connectivity fails, but you need to consider all of the points of failure and establishing appropriate SLAs for them.

Bona finished up with some very funny (but true) reinterpretations of clauses in vendor contracts, for example:

  • What the vendor means: “We are going to send you software that you are not licensed to use. If you use this software in error, you will be out of compliance with this contract, and woe to you if we audit.”
  • What they actually wrote: “Licensee shall not access or use any portion of the software not expressly licensed and paid for by the licensee.”
  • What you probably want to change it to: “Licensor shall not ship any software to licensee that licensee is not authorized to use.”

The summary of all this is that it’s not a task for amateurs. Unless you want to just let the vendor have their way with you on a large contract, you should consider engaging professionals to help out with this. Gartner provides this type of service, of course, but there are also high-quality independents (mostly former analysts) such as Vinnie Mirchandani.

Planning for Disaster

I just bought a new pair of winter boots, guaranteed waterproof and warm to -20C; I stood in the store and swore to the sales clerk that I was not going to have cold, wet feet this year (I probably sounded a bit melodramatic, like Scarlett O’Hara declaring that she’d never be hungry again). For those of you who have never been to Toronto, you may not realize that some people make it through the winter without proper boots, just by avoiding the great outdoors on the few days when it is really cold or snowy. We only have a few weeks each winter as cold as -20; we only get a few big snowstorms; most of the snow usually melts within a day or two; and many days hover around the freezing mark so the bigger danger is cold slush leaking into your boots rather than the frigid air. However, every few years we have a colder-than-usual winter, or mounds of snow — like a few years back when a metre of the white stuff fell in two days, closing the city and causing sightings of cross-country skiers in the downtown financial district — and many people (including myself) aren’t properly prepared for it.

In my case, business still has to go on: being self-employed, I can’t just stay inside when the weather is foul, but have to get out there and continue with my day-to-day business of seeing clients and whatever other activities are on my schedule. In other words, the “weather event” occurs, and my business continues, although in a somewhat uncomfortable and restricted manner. There are many natural disasters that are a much greater challenge to business continuity, like the tsunamis, hurricanes and earthquakes that we’ve seen all over the world in the past year, in addition to manmade disasters and even biological events like a flu pandemic: a recent article in the Economist (subscription required) states that Gartner has advised their clients to consider the effect of 30% of their staff not showing up for work due to the flu, which would certainly fall into the “disaster” category for many businesses.

I spoke briefly about business continuity and BPM at a conference last week, and am doing a more comprehensive analysis for a client in the upcoming months. For me, it comes back to thinking about one of Tom Davenport’s nine steps to process innovation: geographical, or more specifically, location independence. BPM is one of the key technologies that may allow a process, or part of a process, to be located anywhere in the world, as long as the communications infrastructure and trained local staff exist. This has been a large driver behind the move to business process outsourcing, a controversial trend that is rejected outright by many organizations, but many people miss the fact that outsourcing also provides some level of business continuity: if you can move some of your business processes to a remote location, then you can just as easily have them at two locations so that there’s a fallback plan in the event of unforeseen events. I’m not talking about replicating systems here — that part’s relatively straightforward, although expensive — I’m talking about what is often forgotten by the IT disaster recovery team: people. If you have a single site where your human-facing business processes take place and something happens at that site, what’s your plan? Where do your people work in the advent of a physical site disaster? How do you reach them to coordinate them? Can you easily reroute client communications (phone, email, postal mail) to the new location? Are people trained at all locations to handle all processes? Can you reroute only part of the process if you have a partial failure at your main site?

Earthquakes are going to happen on the Pacific Rim; hurricanes are going to happen in the southern US, and it’s going to snow in Toronto. I’ve got my boots, are you ready?

Davenport article in HBR

If you missed Tom Davenport’s excellent article “The Coming Commoditization of Processes” in last month’s Harvard Business Review, they’ve published an excerpt to entice you to buy the full reprint. Mr. Davenport, as always, has brilliant insights:

“Despite the trend toward outsourcing, however, most companies have remained in do-it-yourself mode for most processes… Because of a paucity of process standards, it would be risky to do otherwise…

However, a new world is coming, and it will lead to dramatic changes in the shape and structure of corporations. A broad set of process standards will soon make it easy to determine whether a business capability can be improved by outsourcing it. Such standards will also make it easier to compare service providers and evaluate the costs versus the benefits of outsourcing. Eventually these costs and benefits will be so visible to buyers that outsourced processes will become a commodity, and prices will fall dramatically. The low costs and low risk of outsourcing will accelerate the flow of jobs offshore, force companies to look differently at their strategies, and change the basis of competition. These changes are already happening in some process domains, and there are many indications that they will spread across virtually all commonly performed processes.”

The full article contains a lot more detail than the excerpt, including using CMM as a great example of a standardized process that has enabled software development outsourcing. Less technical business processes are quickly following.

I’ve been mulling over thoughts about business process outsourcing (BPO) for some time, collecting ideas for an article (or even just a blog post), and this has really started me thinking about outsourcing. One of my recent customers provides BPO services for financial transaction processing (as do several other less-recent customers), so Mr. Davenport’s final words apply directly to them:

If your organization provides process services, you may have mixed feelings about the development of process standards. Standards will lead to commoditization, more competitors, and lower prices for the services you offer. However, the move to process standards makes so much economic sense that it is probably inexorable — whether or not your company gets involved. It’s better to help shape a standard than to be put out of business by it.

Legacy attitudes

I work mostly with large financial services clients, which means that there’s a lot of legacy software around. They seem to be pretty good at updating the hardware to avoid the threat of an unsupported system outage, but most of the custom software just keeps getting older and older. In many cases, large portions of the software aren’t even used any more, but have been superceded by functionality of newer systems or processes; however, no one has the time or budget to go in and prune all that unused code out of the production systems. Very much of an “if it’s not broke, don’t fix it” attitude, but unfortunately that results in a lot of unmaintainable garbage that still, somehow, has to be maintained.

As big of a problem as legacy code is, the bigger problem in some organizations is their legacy attitudes.

One example of a legacy attitude is that regarding corporate software standards. There have been huge benefits for companies that standardize on a small number of software vendors, such as licensing deals (at first) and IT training costs, but somewhere along the line, the practice of barring all vendors except those on a rigid corporate standards list is going to come back and bite these companies where they least expect it. Not only are they potentially blocking best-of-breed vendors from coming to the table with business solutions, they’re potentially blocking new delivery mechanisms such as software as a service. As Chris Lindquist, CIO Magazine’s technology editor, recently wrote:

The big problem for these [software as a service] providers until recently has been mindset — software as a service just sounds dangerous to a lot of companies that have built themselves on foundations of millions of lines of customized code wrapped around software from a handful of vendors.

There’s a lot of other legacy attitudes out there, from IT career paths (why would a company force a brilliant technical mind to become a mediocre project manager in order to advance?) to the use of IM (if someone is responsible in their communications and corporate safeguards are in place, why does the medium matter?).

Challenge legacy attitudes at your own risk, however; in many cases, the people who put them in place are now in management positions, so tread lightly when you call their baby ugly.