Foreword: I have written various posts in the past that discuss the typical problems that can be solved for the business by using a BPMS and process automation. I thought it was about time to consider the challenges IT have to manage when not using a process centric approach.
Organisations need to change their focus from being functionally driven to being process driven to be really successful in their adoption of BPM. This is not always as hard as it first sounds.
Most of the organisational and technical building blocks almost surely already exist within the organisation in some form or other. The challenge is to align them together in a consistent and continuous way i.e. using business processes, a BPMS and ensuring that cultural and human behavioural changes are well managed.
Paraphrasing Gartner, the typical characteristics of functional driven organisations include the following:
- Organisational roles and responsibilities are functionaly aligned
- Managers have visibility that is limited to their functional areas
- Business is very dependant on IT to schedule application changes
- Functional tasks and process hand offs are implied causing fragmentation
- Costs are managed by functional area
- Risk management is done using gut feel and relies greatly on experience with limited numeric evidenece due to lack of integrated and trusted reporting information
The organisational characteristics for a process centric organisation typically include:
- Roles and responsibilities are aligned to process acitivities
- Management visibility is based on an end to end business process understanding
- Business is less dependant on IT for small changes to business rules and process tasks
- Functional tasks and process hand offs are explicit, therefore reducing the occuraence if inefficient and broken processes
- Risk management is done using operational metrics and simulation ensusing a proactive approach rather than reactive
So what’s the problem? Traditional development works, doesn’t it?
IT always has the undesirable position where it has to be responsive to business needs but not negatively impact Business as Usual operations or exceed its operational and development budgets.
In most organisations IT infrastructure largely consists of a plethora of silo applications on various types of technologies. They form islands of information and functionality which in many cases are duplicated. These types of applications are required to solve specific departmental and functional requirements but not flexible and easy to integrate with each other in a consistent and repeatable way.
Integration on this scale is an expensive and complicated issue due to the fact that information is duplicated in systems, and the points of integration and maintenance increase exponentially for any new application added. In addition, doing integration in this ‘point to point’ way means changes to one interface can impact other applications and the wider business in unforeseen ways. This directly increases business risk, delivery risks, costs and the need for ongoing expert skills for any new or existing IT projects.
Traditional application software development practices and the integration of silo applications are generally a challenging and costly exercise for the following reasons:
- Requirements’ gathering is a long and intense process and can be very labour intensive due to the complexity and variety of application impacted for any single project.
- Many times a detailed design has been completed, a project started but the business may have already moved on and therefore has different priorities requiring changes to the original design.
- Armies of developers are the norm for traditional development scenarios due to the fact that various application specific skills are required to develop and maintain the plethora of diverse applications and technologies.
- Integration of silo applications are typically application specific i.e. proprietary rather than open standards based. This makes reuse a problem and long term maintenance/enhancements difficult due to the ongoing need for specialist external/internal skills.
- Integration is point to point and is devoid of the business process context i.e. it is done based on a very low level technical view of the capabilities of the product(s) rather than using the business processes to define the final solution.
- Silo application enhancement projects typically have no end. The solutions delivered have very little potential for reuse as they are inflexible, brittle, restricted to the features and functions that are part of a specific release and inherently create islands of data that is not easily accessible by other systems or users.
- Data can’t be normalised due to it being held in the individual applications data repository. This has a huge impact on being able to reduce data duplication and data availability for consistent reporting purposes.
- Data errors are more common as data can’t be categorised to identify what is master data and what is not. This means that inconsistencies are all too common and leads to people not trusting corporate systems and the well known Excel spreadsheet database becomes the norm.
So what the answer?
Process automation and more specifically a Business Process Management System (BPMS) is the solution that will help alleviate and solve many of the business and technical problems described thus far.
Long and short term benefits can be gained by using business process automation as the common way to understand the business, solve tactical business problems and integrate departments, divisions and core systems in such a way to deliver realisable and measurable business value.
Using a BPMS will give an organisation the ability to build and deploy sustainable and targeted solutions in very short timeframes, using less development resources than traditional development projects. It has the ability to integrate into existing silo applications, data bases using open standards and various other integration capabilities.
This approach is based on the premise of starting small by identifying a key business pain, understanding the value it will deliver and solving it using a project based delivery technique. Longer term, as each new individual projects delivers value, a natural momentum is created and therefore this low risk and high value approach can be used as a vehicle for organisational and behavioural transformation.
Where to start?
Many opportunities exist in an organisation to start delivering business process related benefits. Some of the more obvious processes are those that relate to:
- Finance – Purchasing, Time Sheets, Expenses Claims
- Sales – Bid Management, Sales Pipeline Management
- Customer Relationship Management – Customer Help Desk
- Human Resources – Starter, Movers, Leavers, Self Service processes
- Project Management – Project start up, document approvals, time tracking etc.
- IT Operations – ITIL processes, IT Help Desk
The benefit of choosing any one of these processes is that it will create the ability for the business to become more in control of their ability to drive business change rather than be reactive to changes placed upon it. IT will have more flexibility to integrate existing systems that deliver solutions in line with business needs and end user expectations.
As new iterations of the same process or new processes are brought onboard, a momentum is created and what started out as a tactical solution becomes a strategic and dynamic process platform. In addition, the various systems that are currently used to deliver a silo capability to the various functions inside each of the organisations divisions can be exposed to other divisions (if appropriate) and therefore improve IT reuse and drive consistent working practices across the wider business.
Taking an incremental and iterative approach ensures that value is delivered while recovering any cost that may have been made in terms of an Enterprise BPMS Platform.
Additional Research & Reading: Aberdeen Group – BPM and Beyond, The Human Factor of BPM (Nov 2008)
This work is licenced under a Creative Commons Licence.