Archive for July, 2009

The sound of summer…

Monday, July 27th, 2009

Inspired by my colleague’s references to Le Tour (in which I also have a passing interest), I thought I’d take the chance to share some thoughts about one of my particular passions, and how it might relate to the type of technology I work with at Singularity.

What do you picture when I mention cricket? Probably big men in coloured clothes, crashing balls over the roof of the grandstand, music blasting with every big shot or wicket. Stop right there!
I’m talking about the purist form of the game, test cricket. Five days of titanic struggle, the combination of Herculean effort with Sartre-like intellect, brawn versus brain, the batsman’s dilemma of attacking the poor ball but ensuring he’s still out there at tea, the bowler’s challenge of mixing the unplayable ball with the stump-breaker and the tempting half-volley outside the off-stump. The umpires -the last bastions of respect and honour - with the important decisions in their hands alone (or maybe the third umpire if he’s not too sure). In the stands, glasses of Pimms and dainty sandwiches for the toffs, beer and pork pies for the regular folk, with the formality of MCC ties at one end of the ground mixed with the casual shorts at the other. There’s always the telly if you can’t be at the ground, with Hawkeye confirming or questioning the umpire’s view, and sweetest of all, cricket on the radio with the dulcet tones of Aggers and Blowers on Test Match Special. This is what summer is all about….

Anyway, earlier this month England was playing Australia in the Second Ashes Test at Lords, the home of cricket. Andrew Strauss, the England captain was placed in a bit of a predicament. England had batted first and amassed 425 runs, a mildly respectable score. They then bowled Australia out for just 215, a fantastic performance! So, now the predicament. Being more than 200 runs ahead after the first innings, England had the choice of whether to bat again (as would normally happen) or to make Australia ‘follow on’, i.e. make Australia bat again in the hope they would not even reach England’s total in their two innings combined, therefore bringing an early end to the game. Not an easy decision, and one where the pundits had many and varying opinions. The decision is largely based on assessing risks, most of which are unquantifiable. What if I make the Aussies bat again and they get a big score, taking them into the lead and forcing us to bat again? What if that happens and the pitch deteriorates making it easier for their bowlers and harder for us to get the runs we need? What if I decide that we’ll bat and they skittle us for a low score and they then become favourites? What’s the weather looking like? How tired are my bowlers? What’s my gut telling me? What’s Kevin Pietersen telling me?

You may be wondering what this has to do with technology. Well, how much easier would that decision have been for Andrew Strauss if he had a very clear set of assessment criteria which led to a well-structured and justifiable decision? In business, it seems to me that people often base their decisions on the assessment of unquantifiable risks using a combination of gut feel, experience and throwing darts at a board. The Singularity Client Risk Management solution addresses this particular problem within the financial services sector. It enables a structured risk assessment of every client, based on configurable criteria at the point of engagement with the client, and right through the client lifecycle. This ensures that even when circumstances change, the risk associated with that client is always accurately assessed, and decisions clearly justified. Of course, that doesn’t mean they will always be right, but at least they will be consistent.

Luckily for Andrew Strauss, on this occasion he made the right call, England batted again, scored another 300-odd, and bowled the Aussies out with 115 runs to spare. 1-0 and England went on to win. But wouldn’t life have been a little easier with some structure?

Author: Philip Mills, Singularity.

Share This Post

Case Management white paper – Extract No. 2

Thursday, July 23rd, 2009

Part1: Case Management white paper – Extract No. 1

Michael White, 23 July 2009

As promised, here’s the second extract from our white paper “Case Management – combining process with knowledge”.  Case management describes how knowledge-centric processes are coordinated.  In this extract we describe the typical characteristics of Case Management. You can download the full white paper from http://www.singularity.co.uk/case-management-whitepaper.lit.  You can also check out our paper on Case Management on BPTrends at http://www.bptrends.com/resources_publications.cfm?publicationtypeID=DFC61D66-1031-D522-3EBDAB1F65A451AA , and we also have a chapter on Case Management in the Public Sector in this year’s BPM Handbook, available at http://www.futstrat.com/books/handbook09.php.  As always, we’d like your constructive feedback on the article and white paper and we’re happy to take any questions.

Case management scenarios share a lot of common characteristics.  Case workers need to manage a complex set of steps from the start of a case through to its completion, usually involving interaction with others in their organization and with external agencies, and requiring the generation of correspondence, documents and records.  The key characteristics of case management include:

  • Knowledge-intensive: Typically case management processes require the intervention of skilled and knowledgeable personnel.  Staff acquire their knowledge through their experience of working on similar cases and through collaboration with more experienced colleagues, becoming thoroughly familiar with the tacit and explicit rules governing how cases should be managed.  These members of staff have to deal with issues that can be ambiguous and uncertain and that require judgment and creativity.  Managing knowledge so it stays within the organization and is passed quickly to new members of staff is a challenge.
  • Variability: While a particular type of case will share a general structure (e.g. handling benefits applications), it is not possible to predetermine the path that a particular instance of a case will take[see note 1].  A case can change in unpredictable, dynamic and ad-hoc ways as it is progressed through an organization. Certain elements may be fixed (e.g. the end-to-end duration for completing a case may be set to 18 months, or a fixed budget may be allocated to each case) but there can be considerable variation in how steps are executed, based on the particular circumstances of the case.
  • Long running: cases can run for months or years, and are generally much longer running than the shorter interaction cycles handled by standard customer relationship management (CRM) systems.  Because a case is long running, it changes hands over time, different people work on different aspects and no single individual has an accurate view of the case as a whole.  This drives the need for a supporting case management system that can provide a single consolidated picture of the case.
  • Information Complexity:  Case management almost always entails the collection and presentation of a diverse set of documents and records.  Emails, meeting notes, case documents and correspondence related to a case must be easily accessible to the appropriate case worker at the right time.  This is often difficult for case managers to organize and manage efficiently, with the danger that an important record, note or file will be unavailable, lost or overlooked when it is needed.  Retrieving the correct information required at a particular decision point usually depends on the knowledge of the case worker and an adequate physical filing system.
  • Collaboration and coordination: case workers usually need to co-ordinate interviews and meetings among interested parties e.g. scheduling an interview with an applicant, with other staff in the organization, with legal representatives. Many cases require a team-based approach, with different specialists working on different aspects of a case or acting as consultants to their colleagues.  These team members need to be able to access case information and discuss it with each other.  Collaboration is particularly important in knowledge-based case management because workers rely on each other’s advice and experience when making decisions on a case.
  • Multiple Participants, Multiple Roles: There are often a range of involved parties, either directly or indirectly related to a case, who play different roles during the lifetime of the case – e.g. applicant, witness, claimant, injured party, appellant etc.  There can also be a large range of staff roles required to complete a case end-to-end.  And case workers can fulfill different roles in different types of cases.
  • Cases can be interrelated: the outcome of separate cases may have an impact on each other.  For example, an application for citizenship by an individual may be affected by the success or failure of an application by a spouse or immediate relative.   Cases can be explicitly linked or they may be linked by inference and conducted with this inferred link in mind.
  • Critical nature of timescales: while cases may have great variability in how they are completed, very often there are inflexible requirements for end-to-end timescales, driven by legislation or Service Level Agreements.
  • External events affect cases: external, out-of-band events and intervention can change the state of a running case e.g. a phone call from a lawyer or the unscheduled arrival of compliance documentation.
  • Difficulty in Gaining Visibility of Case Progress: this is a common characteristic of case management as it is implemented today, although it is not an inherent characteristic.  While case workers may have a good understanding of how they are progressing individual cases, it is often difficult to monitor progress when work has been passed to colleagues within their own unit or to an external department.  At a higher level, managers usually have poor visibility of how long it takes to progress a case on average, how much a case costs to process, and what the expected completion time is for a particular case.  It may also be difficult to obtain information on which cases are stalled waiting for an external communication and which steps in a case are repeatedly causing bottlenecks. The result is that processing of cases is often serialized, because to run them in parallel, while more efficient, is just too difficult for many organizations to manage.
  • Strong reporting requirements: There is usually a significant requirement to report on and analyze information derived from case handling, both at operational and management levels, for example workload analysis of cases by stage, by individual and by department and case performance versus target.  Managers want gain insight into operational performance and quickly identify exceptions.
  • History: every action performed, every decision taken and every piece of correspondence received has to be tracked, not just for audit purposes, but also to provide guidance for future similar cases.  Case workers need access to this history when making decisions, while auditors need the history to ensure policies are being adhered to.  The case history is the organization’s defense mechanism against any allegations of failure to perform, particularly in cases which have high cost or personal impact.
  • Security:  there is a requirement to provide fine-grained control over who has access to particular information and functionality.  In certain environments, these security requirements assume particular significance e.g. policing, health care and child protection.
  • Isolated pockets of automation: this is a characteristic of case management as it is generally implemented today, rather than an inherent characteristic.  Case management is usually only partly automated and there is disjoint between those pockets of automation.  Legacy systems automate slices of the processes, but the end-to-end management of a case still relies too heavily on paper documentation, physical folders, spreadsheets and email. 

While this list of characteristics is not exhaustive, it captures the essential aspects of managing cases.  But what are the practical implications?  Why should people care about the characteristics of cases or the issues raised when trying to automate them? 

Note 1

“Unlike workflow management, which uses predefined process control structures to determine what should be done during a workflow process, case handling focuses on what can be done to achieve a business goal. In case handling, the knowledge worker in charge of a particular case actively decides on how the goal of that case is reached, and the role of a case handling system is assisting rather than guiding her in doing so

Van der Aalst , Wil M.P., Weske, M., Gr?nbauer, D., “Case Handling: a new paradigm for business process support “, Eindhoven , 2004, p1

In the next extract, we’re going to look at why Case Management is so important to so many organizations today and why it’s going to become more important to more of us in future.

Share This Post

Le Tour

Wednesday, July 22nd, 2009

It’s Tour de France season – which is an exciting time of the year for a man with calves and varicose veins like mine.  Road cycling remains a minority interest in the British Isles but, perhaps stimulated by the UK’s stunning success in track cycling in Beijing, I’m seeing unusually high levels of awareness and enthusiasm for the TdF this year.  This is good – it means I may not have to move to Belgium (although their beer is a compelling proposition).

What has this to do with BPM?  Bear with me…  one of the unusual aspects of this year’s tour is that the Astana team (banned last year because of a historical association with performance enhancing substances) is back, and with at least three cyclists capable of winning the Tour.  Lance Armstrong has won seven times, and looks sharp enough to make it eight. Alberto Contador was the 2007 winner, and, but for the ban, might be shooting for 3 titles, and Levi Leipheimer has been a top flight rider for several years with a wicked time-trial performance. Most teams would be happy to have any one of them, but here they all are simultaneously trying to win the tournament themselves, ensure that someone from the Astana team wins the individual event, and ensure that Astana wins the team trophy.

The press are falling over themselves trying to stoke up the internal rivalry and generate as much excitement, controversy and debate as they can.  But, hang on, isn’t this just another day at the office? In any organisation today people are balancing their own personal craving for success, their desire to be a team player, and their (enlightened self-interested) wish to see the team/dept/company succeed. It’s not an odd thing – it’s the norm, or at least it should be unless you’ve been crazy enough to hire one good guy and a bunch of lazy and indifferent people.

How far should the business enable or encourage this complicated dynamic? Is it actually a really positive thing rather than a problem? Every business should want the strongest team they can afford; but this only makes sense if they can actually unleash the full potential of those people, and reward them accordingly,  and that requires certain criteria to be fulfilled:

            1. Each player’s overall contribution is fully recognised and rewarded
            2. Each player’s particular strengths are identified, exploited and celebrated
            3. If there a single outstanding performer, it should be possible to identify them quickly and align
                the whole team behind them

Ok, I asked for your forbearance… for many of you, this team dynamic is perhaps not an issue – you work in small fluid teams and you have the chance to shine, or support,  with visibility. But this is not so for the vast majority of people in work today. Their issue closure rate, their customer satisfaction rating, their low defect rates, their creativity, are all invisible, uncelebrated, unsupported.  Not only are we not encouraging healthy competition between them to be the best individual and/or team performers, we may well be encouraging them to coast.  So this is a plea for Business Activity Monitoring – knowing enough about your teams and who is delivering value and in what ways so that you can do what Astana need to do today.   Establishing and enabling processes is good – but make sure as you do it, that you’re getting the data back out of the processes , not just about the overall result, but also about the Contadors, Armstrongs and Leipheimers, to drive up the performance of the entire team… er business.

About the Author: Paul Moorhead is the Product Manager at Singularity.

Share This Post