BPM and the Benenden Healthcare Society
Health sector case study
Benenden Healthcare Society is a mutual not-for-profit healthcare provider run solely for the benefit of its members. It offers discretionary, non-acute clinical care and tertiary healthcare services primarily to people who work in the public sector. The multi-award winning Benenden Hospital in Kent is an independent hospital with charitable status and is a subsidiary of the Society. It is supplemented by a number of regional contracted treatment centres across the UK, giving members local access to clinical and specialist treatment.
A number of challenges face the Society that have driven changes that are enabled by technology and systems. The improving NHS waiting times could reduce the marketing potential of a discretionary health service that has traditionally been seen as a “top-up” to the NHS. At the same time it is widely accepted that government funding through taxation of Health Services in the UK cannot keep up with demand and at some point we may all need additional health services from other organisations outside of the NHS.
There has been a lack of investment at the Society over a number of years which has resulted in a range of disparate systems that are not joined up and do not share commonality. This is compounded by the two sites in York and Kent having separate IT departments and strategies.
In 2006 the Society engaged external consultants to help review and develop the IS Strategy, investment and business fit. The IS strategy was ratified by the management board in 2007 and identified a number of investments needed over the following 3 years. The strategy is governed by an IS Programme Steering Board (ISPSB) which is made up of key stakeholders including from the elected Committee, Executive Board and other Senior Managers.
The Strategy has a number of basic principles and standards that investment, development and acquisition projects need to adhere to:
- To enable an “enterprise mindset”; that data and systems are a corporate resource irrespective of location
- Enable a fully “joined up organisation”
- Reduce overhead of disparate systems
- To focus on front end service provision rather than back office systems
- Enable business growth through system agility
- Systems requirements are to be future based
- Minimise duplication
To realise these standards and goals BPM and Service Orientation were seen as fundamental building blocks.
A system targeted for early replacement was the case management system. The proposed replacement for this system would be known as the “Service Management System” (SMS) and be developed through a mix of a BPM tool configured over an Oracle database. SMS would deliver management of all service provision to our members, including the authorisation and provision of clinical services across the network of providers.
During the development of the IS Strategy the use of BPM as a business logic layer was identified as an effective way of achieving our goals.
The use of a BPM tool that creates a user environment based on mapped processes offers developers greater opportunity to achieve that elusive quality; system agility. It also provides a rapid development and deployment environment, which in turn delivers responsive solutions that can be prototyped and rolled-out quicker than in traditional ‘waterfall’ systems development.
Using BPM to build new applications forces an organisation to review the processes involved. This means that current processes that have evolved due to current systems and/or functionality can be replaced, streamlined or discarded. The business can focus on what it needs from its technology to achieve its goals. Let the new system bend to the needs of the business instead of the business bending to the system.
We undertook a review of all processes involved with the delivery of our service to members. We took a decision early to be strict about the scope of the Business Process Review; we did not review any existing processes.
We knew that a lot of the processes had grown around the existing system which was based on functional requirements now 10 years old. A fresh look at what we needed and how we wanted to work was easier to achieve by forgetting what our users currently had to do.
A series of Process Mapping workshops took place, organised around groupings of related or similar activities and using a variety of staff. Some 30% of Service staff were ultimately involved in Process Mapping. The biggest challenge to overcome was ‘unlearning’ up to 10 years of process knowledge. However, after 6 months of iterative mapping we had all Business Processes mapped and signed
During this time we went to market to find a suitable BMP tool that would deliver our requirements. Through desktop research, including Gartner Quadrant reports, a short list of 10 possible providers was drawn up. This was further reduced to 3 through a formal quotation and reference site process. The final decision was made using scenario demonstrations. These demonstrations were based upon a selection of Business Processes with a strict development time limit. On the day of the demonstrations we presented each supplier with a revision to one of the scenarios and gave them an hour to affect the change.
This allowed us to gauge the fast deployment potential of each BPM tool. The selection panel consisted of a mix of people from all levels of the organisation and from different business functional areas. The panel selected Appian Corporation as the preferred partner/supplier and their Appian Enterprise BPM tool as the solution. Contract negotiations commenced resulting in Appian Corporation becoming our selected Partner.
SMS was delivered through Rapid Development and iterative prototyping. The development activity was guided by Functional Specifications, agreed and signed off by the business and based on the agreed process maps. It was undertaken collaboratively between the Society’s IS staff and Appian developers and commenced in October of 2008.
The development was broken into 6 major components; The Oracle Database design and build, and 5 functional prototypes of related or dependant processes.
Appian Enterprise (AE) is a very good BMP tool and provides significant “out of the box” functionality. However we wanted to build an intuitive interface that was simple to use, that would guide our staff through the complexities of our service offering and allow them to focus on the members needs. These very specific requirements needed very specific solutions; AE can be customised and tailored to suit and we took advantage of this fact.
During the development I heard: “That can’t be done”, or “There isn’t really a way of doing that” a few times from the Appian development team we had here on site. But we knew what we wanted to be able to deliver to our users so “no” was never an option.
Between the technical staff on site and those based back in the US, Appian took their product beyond these restrictions, engineering new smart nodes, customised controls and Oracle specific components that have allowed us to engineer an innovative and agile solution that has even impressed our partners at Appian. We have been told that some of the innovations we have introduced have never been attempted before and that Benenden Healthcare is a “hot topic” with the development team back in the US.
At the time of writing this article we have gone through prototyping and testing of the entire system and have commenced End User, End-to-End Testing; 10 months after the start of the development phase. The system is due to Go-live later this year and although it is not operational yet the feedback from those staff involved in Prototyping, Testing and Training is unanimous; this system is so easy to use, and it looks amazing.
(ITadviser, Issue 60, Winter 2009)