With apologies to George Carlin…

So, how might we design a workbasket system – regardless of whether or not our system actually looks like workbaskets, or just uses things like database queries to display logical subsets of the screening matches? Even if we have a entity-centric model (see that earlier post), there is usually significant utility in being able to segment the screened records.

Of course, this list of possible match segmentation is very much firm-dependent… but let’s just say these are possible ways to look at our data:

1. Probably the most generally useful segmentation (and the most frequently implemented) is by processing stage – like New Match, Pending Approval, False Positive Matches, True Matches
2. It is not uncommon to segment by the general data source type – employees, vendors, customers, transactions – and/or the screening method – real-time, batch file processing
3. If multiple business lines are screening and their data is screened separately, these results are not infrequently kept separately within the workflow
4. If multiple geographic regions or records in different languages are screened in the same system, they may be kept separately

From a design standpoint, workbaskets are not the only tool that can be used – and, if not well thought-out, they can lead to operational headaches. 

When one’s screening needs cover a significant number of varied data (e.g. geographies, data types, business lines), keeping them separate can lead to complex naming and organizational challenges. In theory, this apparent complexity can be better managed by alternate means; one could run multiple instances of screening systems for segments of the business that do not or should not be commingled with other segments or staff. For example, even if a screening system can keep employee screening results out of the view of staff who are not supposed to view it by other means, a firm might choose to run that screening physically separate as a business decision and/or to reduce the complexity of workflow functionality.

On the other hand, relying exclusively on capturing every variation in screening results with a large population of workbaskets brings different design challenges. The easier challenge is that many workbaskets can, at any point of time, have no results in them. That complicates the job of reviewing operational dashboards and reports. However, suppressing empty workbaskets – or even reporting them separately largely mitigates that problem 

The harder issue is that, just like empty workbaskets, sparse data (e.g. lots of workbaskets with screening records, but many of them with very few results) complicates reporting and MIS – as well as managing operations. One of my former clients, for example, had 3 business units, each of which had its own instance of workflow – and each of those, despite my firm’s advice otherwise, had over 100 workbaskets each.

Where’s the sweet spot here? My inclination is to minimize the number of workbaskets for the purpose of getting work done, but provide sufficient detail so that staff can prioritize their work  as day-to-day needs dictate, that there is proper separation of duties and visibility control, and that management conducting oversight can retrieve sufficient operational detail for reporting and control needs.