<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">

5 Questions to Ask About Your Middleware/ ESB Strategy

Adam Mutton Adam Mutton on November 13, 2017

Reduce_ESB_TCO.png

Do you use an on-premises Enterprise Service Bus (ESB) architecture to integrate applications and services? If so, you’ve probably noticed that cracks are showing up in your IT infrastructure. This will accelerate as more applications migrate to the cloud. Chances are, you’ve invested heavily in these solutions and are reluctant to replace them.

There is a way to extend your investment and achieve a more modern architecturethat can handle the complexity of today’s more demanding data, platforms and business systems. First, it makes sense to review the reasons you may want to begin modernising your on-premises legacy middleware solutions today.

A primary reason is reducing the total cost of ownership (TCO) of your current ESB/ Integration solution.

Answering these 5 questions will give a better understanding of the overall cost you might be incurring now with your aging middleware solutions, as well as future upgrades you might be undertaking or planning to pursue. 

1. Are you factoring in operational expenditure? (OPEX)?

When calculating the costs of integration platforms, companies typically consider only the capital expenditure (CAPEX) angle, but OPEX can be significant. In addition to the hardware and software costs outlined in your budget, take a look at the expenses associated with DIY development.

2. What are your compliance and security costs?

If your data includes personal health or financial information like credit card numbers, you’ll have to invest in certifications to demonstrate that you’re compliant with data privacy and security regulations like PCI and HIPAA.

3. What is the real cost of developer productivity?

Another important consideration is the rising cost of employing and retaining iPaaS developers, which offsets productivity gains.

4. What does it cost to accommodate new data sources and formats?

To calculate the overall costs of ESB ownership, you must factor in the expense of dealing with new data streams and formats. 

5. What does ESB cost in terms of lost opportunities to innovate?

The IT professionals who are engaged in integration don’t have time to focus on more strategic tasks and gaining insights to advance your business and meet your customer needs. This type of expense is almost never factored into the total cost of ESB ownership. It should be.

Sign Up for Our BPM Automation Integration Workshop

Topics: Intergration

7 Key Actions to Drive Process Change

Rene Van Bosch Rene Van Bosch on November 8, 2017

7_Steps_Process_Change.png

Changing a process within a business is not for the fainthearted, as Ronald Reagan once said:

“The future does not belong to the fainthearted; It belongs to the brave.”

Business-process owners must have the courage to embark on the journey to change the future of their business processes. This article aims to guide those organisations in making process change a successful reality.

1. Show the process vision

This is a very crucial first step that helps you set the scene for the future. This will ignite the desire to change, and make the organisation more willing to embrace change.  The most effective manner to communicate your process vision is to articulate it using a picture or a story. Remember: the process vision must help the stakeholders. It should help them:

  • understand what the future will look like
  • understand the benefits for them, their clients, and the business
  • understand the risk if the process stays the same, and
  • recognise how this process change will help the business vision/goals to be realised.

2. Understand the change required and its impact

Out of the process vision, the changes required to the business (people, process and technology) can be formalised. While formalising the business change requirements, the change impact and its severity on the people, processes, and technology should be determined. The following tools are just some of those that can be considered in helping you to do this.

  • Brown paper: The ‘brown paper technique’ demonstrates a team-building approach that uses the power of the team to develop views on where workload issues might be. It is a visual wall display (usually created on brown wrapping paper, typically 3 ft high and up to 60 ft long). It documents an entire process, or situation, by highlighting all activities, interfaces, decision points, and information sources. The ‘brown paper technique’ involves process analysis and documentation, client involvement and participation, as well as the critique and assessment of opportunities.
  • Day in the life of (DILO): A DILO approach documents the entire set of activities for a member of staff or role holder. It provides a high-touch way of showing the extent of someone’s role, highlighting the major areas of work and where their greatest volumes are created. It can be done for a single member of staff or a group of employees who have the same role or function, and can be a synthesis of all the individuals.
  • Fishbone Analysis: The Fishbone diagram (sometimes called the Ishikawa diagram, or cause-and-effect diagram) is used to identify and list all the possible causes of the problem at hand so as to identify its root causes. This is primarily a group problem-analysis technique, but can be used by individuals as well. The process is called Fishbone Analysis because of the way in which the information gathered is arranged visually—like the skeleton of a fish.
  • Force-field analysis: This helps a team understand the balance of the driving and restraining forces of a particular change. The driving forces push the organisation towards change; the restraining forces push against change. Based on this understanding, the team can identify appropriate restraining forces to remove, or decrease and identify appropriate driving forces to increase.
  • Six Hats thinking: The ‘Six Hat’ method was developed by Edward de Bono. He provided some new labels for thinking that signal the different directions in which thinkers can be invited to look. A ‘hat’ indicates a role, which can be put on or taken off with ease. A hat is also visible for everyone else to see. Although the hats are usually imaginary, a poster showing the different hats can be useful in the room where a group is working. The six directions are:
    • Managing Blue – What is the subject? What are we thinking about? What is the goal? Can look at the big picture.
    • Information White – purely considering what information is available. What are the facts?
    • Emotions Red – intuitive or instinctive gut reactions or statements of emotional feeling (but not any justification).
    • Discernment Black – logic applied to identifying the reasons to be cautious and conservative. Practical, realistic.
    • Optimistic-response Yellow – logic applied to identifying benefits, and seeking harmony. Sees the brighter, sunny side of situations.
    • Creativity Green – statements of provocation and investigation; seeing where a thought goes. Thinks creatively, and outside the box.

The method provides a way for groups to experience the power of parallel thinking.

  • Stakeholder mapping: A powerful stakeholder-alignment tool that allows the team to quickly and visually assess their stakeholders’ impact on the success of a change program. This will help develop strategies that increase stakeholder support. It is a different way of looking at stakeholders, and a means of focusing stakeholder discussions.
  • Risk probability and impact matrix: This is a tool to aid the project team in prioritising risks. It is based on the principle that a risk has two primary dimensions:
    • Probability – A risk is an event that ‘might’ occur. The probability of it occurring can range anywhere from just above 0 percent, to just below 100 percent. (Note: It can’t be exactly 100 percent, because then it would be a certainty, not a risk; and it can't be exactly 0 percent, or it wouldn't be a risk.)
    • Impact – A risk, by its very nature, always has a negative impact. However, the size of the impact varies in terms of cost and effect on health, human life, or some other critical factor.

This matrix allows you to rate potential risks within these two dimensions.

  • Cost-benefit analysis: This is a process by which business decisions are analysed. The benefits of a given situation, or business-related action, are summed—then the costs associated with taking that action are subtracted.This will help build the business case for the process change.

3. Commission a competent implementation team

An implementation team is accountable for making process change happen—therefore, it is important to choose your team wisely. These are the people who will ensure that effective interventions and implementation methods are used to produce the intended outcomes. It is important to understand the skills that are required to implement the change, as this knowledge will help select the right people for the team. A competent team will be able to:

  • develop a clear implementation plan (i.e. who is doing what and when to complete the right things at the right time), by only looking at the impact analysis and business change requirements;
  • think on their feet to adjust an implementation plan (and their actions accordingly) to ensure a fruitful outcome.

4. Foster crystal clear communication

The communication supporting the project (case for change, project status, impacts, etc.) must be clear, concise, concrete, and coherent—with NO jargon. When the change impact is high on the target audience, the communication should come from their direct line report. Therefore, empower the direct line report to deliver the communication. He/she knows the audience the best, and can give feedback to the implementation team on how well the message was received. People must feel that they are listened to regarding their fears and concerns. If any resistance is encountered, corrective actions/communication plans can be put in place. This will help change the behaviour/attitude of the team, and foster a more positive attitude to enabling their embrace of the change. 

The communication plan should be aligned to the implementation plan. The communication packs should be specific—configured according to each type of stakeholder’s information needs. Ensure the most effective channel to deliver the change message is selected.

5. Engage affected stakeholders

When attempting to implement process change, some of your colleagues will be against it and others indifferent. It is part of human nature to feel apprehension when asked to change the way things are done. Therefore, to successfully implement a change, all stakeholders must be engaged in a way that they can accept (but not necessarily be happy with) the proposed change.

The project should have a mechanism (e.g. a collaboration tool) where questions and concerns from team members can be captured, as well as a database for them to find answers to frequent questions/concerns about the project.

The implementation team must have a platform where they can involve stakeholders in the design phase as much as possible. The buy-in for the to-be process will be higher if the stakeholders feel they had a part in creating their own future way of working.

6. Stay on track

A key element for success is to establish an appropriate management structure (governance) for the process-change project. This structure should include:

  • A project sponsor, or an engaged executive sponsor, who has a vested business interest in the process change from kick-off to close. The sponsor should champion the project at the executive level to secure the buy-in. This can mean the difference between success and failure.
  • An effective steering committee that actively and overtly supports the implementation team by eliminating obstacles, and empowering them to deliver on the agreed outcomes.
  • A project manager who involves the entire implementation team in the development of the implementation and communication plan. He/she will ensure the project is on time, on budget, and within scope.

7. Sustain the change

Creating a group to support the target audience after the implementation is crucial for the change to be sustained. Additionally, it is helpful to implement a buddy system in which individuals are teamed up with a well-trained colleague. This will ensure everyone has a supporting structure and won’t have to call first-line support when they experience problems and need help. This will help to prevent people going back to their old process. People respond better to a face they know, someone who knows their pain, rather than a stranger they don’t know. The people best suited for the buddy role are those who where enthusiastic about the change from the start. Target them as ‘early adopters’, and educate them to fulfil the supporting role post implementation. These people can perform regular audits of the process-change project/status, and will be close to the target audience and able to give feedback to the process owner if some begin to revert to the old way of working. Immediate action can then be taken to ensure the business will still benefit from a successful implementation.

So, to sum up:

  • S – Show the process vision
  • U – Understand the change required and its impact
  • C – Commission competent implementation team
  • C – Crystal clear communication
  • E – Engage affected stakeholders
  • S – Stay on track
  • S – Sustain the change

Hopefully, this approach will be useful when your organsation is implementing a process change. Enjoy your process-change journey, and may it bring your business every success!

New Call-to-action

Topics: BPM - Business Process Management

Robotic Process Automation’s place in Process Improvement

Andre McGuire Andre McGuire on August 24, 2017

Robotic_Process_Automation_and_Process_Improvement.png

Robotic process automation (RPA) has been heralded as the next big thing in process management.  Google Trends reports show that the last 2 years have seen a peak in interest in these technologies (Figure 1).

RPA_Google_Searches_2012-2017.png

Figure 1: Interest in RPA in the form of Google queries (2012-2017)

A recent report from Grandview Research (Oct 2016) projects the global RPA market to reach USD 8.75 billion by 2024, meaning that RPA is not just flavour of the month and is, in fact, here to stay. As the RPA tools evolve in consistency, credibility and applicability, more organisations will be quick to adapt to the emerging technology. According to Forrester Research (Nov 2015), up to 9% of the global workforce will be threatened by RPA software in the near future. The change is coming, and it is up to process improvement professionals to prepare for this disruption by properly educating their corporations on the do’s and don’ts of RPA.

RPA today

RPA is an autonomous digital workforce that is independent of human interaction. A piece of computer software or ‘robot’ captures and interprets existing applications for processing a transaction, manipulating data, triggering responses, and communicating with other digital systems. RPA differs from conventional systemic automation because the bots run through the processes and interact with the applications as a human would, effectively replicating the actions of a human user.

Basic RPAs focus on simple tasks, such as table population, desktop consolidation, cut/copy/paste (CCP), or task scheduling. Advanced RPAs can tap into more unstructured data using techniques found in chatbots or online digital assistants, such as Apple’s Siri or Google Assistant. In the future, cognitive RPAs will be able to effectively navigate complex scenarios initially designed for humans, such as IBM’s Jeopardy winner Watson, or Google Assistant’s robot bartender.

The clear majority of commercially available applications are included in the first two types: basic RPA, or advanced RPA. These types of RPA promise a quick fix, with reduced financial investment. It is these qualities that make RPA exceptional in cases where automation is applied for the first time, and where a more sophisticated IT solution would not be feasible. By licensing robots on a per-year basis, similar to business process outsourcing (BPO) solutions, RPA provides a flexible workforce that is easily scalable to project needs. This can potentially reduce error and cycle times, enabling standardisation and, ultimately, reducing operational costs. These are similar objectives to those found in process improvement.

RPA’s Impact on Process Improvement

Process improvement aims for faster, cheaper, less risky, higher quality, and compliant ways to deliver process outcomes. RPA aims to be the enabler of such process objectives by reducing human involvement. Given that not all processes are created equal, RPA benefits from focused implementation instead of a general Band-Aid to existing process problems.

RPA delivers maximum benefits to improved processes that exhibit certain characteristics. Two variables help to determine the level of RPA required to achieve maximum benefits: data (structured or unstructured); and tasks (complex or simple). 

Structured data and simple tasks

The application of RPA is primarily suited for processes where there is ongoing human involvement in large volumes of structured data entry, and straightforward processes with simple business rules that require switching between various applications. Typically, these processes are found in financial services and banking, telecommunications, and healthcare. These industries often execute processes that are great candidates for RPA, such as patient or client data migration, customer account management, or insurance claims processing.

Unstructured data and simple tasks

Processes that require complex and unstructured data management, such as document validation or signature verification, may not be suitable candidates for basic RPA. Although some technologies have started to emerge that enable handling unstructured data, the added costs associated with guaranteeing data quality and integrity may render an RPA solution unviable. Realistically, implementing RPA in this type of process will likely only be viable if there is a high volume of tasks being performed.

Structured data and complex tasks

Processes with a high number of possible outcomes and complex business decisions, such as workflow escalations, require highly complex automation. These include ‘human-in-the-loop’ processes, where the overall output depends on the judgment of a human operator, or only a specific person has the required accreditations to approve workflow. Examples would include issuing certifications, such as a driving licence, or approving a home loan—though it is possible to implement RPA to gather all the required information to enable faster completion of the process. However, there may be an unavoidable bottleneck where the human operator must ultimately make the decision to approve the certification/loan. If the process depends on regulatory changes, or on applications that are frequently updated or modified, any RPA solution would have to be re-configured each time the activity changes. This must be carefully factored to reduce the risk of costs outweighing the benefits.

Unstructured Data and Complex Tasks

Some processes are so dependent on intangible or ambiguous data, and flexible decision-making, that implementing an RPA solution would be highly ineffective. Case-by-case scenarios, such as managing an immigration visa application, or child adoption processes, require a level of cognitive reasoning to extract, process and act on the information that basic RPA does not currently provide. Eventually, cognitive RPA solutions will be developed that can handle complex business rules with multiple escalation pathways, and use learning algorithms to continuously adapt to different inputs. However, the technology to implement this is not currently available commercially—so, ultimately, this type of process is still best handled by humans.

The diagram below shows the culmination of the above variables (structured or unstructured data, against complex or simple tasks) highlighting the ideal combination of process characteristics for today’s RPA technology implementation.

Process_RPA.png

Figure 2: Process characteristics for today’s RPA technology implementation.

Thinking RPA

The quadrant developed in this paper presents an attempt to establish a framework for implementation of RPA. Process improvement practitioners can use this framework for communication, assessment, and prioritisation.

RPA is not just a trend—it is well on the way to become one of the essential solutions to process improvement, especially those with human involvement. At the time of writing, RPA solutions tend to benefit human-involved processes with simple tasks and structured data at a high volume.  As RPA technology continues to evolve, it is anticipated that RPA solutions will effectively cover more of the quadrant—that is, able to handle unstructured data and complex tasks at a higher volume than humans. Time to start thinking RPA.

Sign Up for Our BPM Automation Integration Workshop

Topics: RPA, Automation

The Big BPM Project

Roger Tregear Roger Tregear on June 7, 2017

Big_BPM_Project.png

Many articles have described the essential tools of achieving and sustaining process-based management. The Tregear Circles define the management meta-model that focuses on genuine, targeted, and evidence-based performance improvement. The 7Enablers of BPM describes how process-based management, via the circles, is enabled and embedded.

Of course, it’s not enough to just define the ideal state of two circles and seven enablers. To get to that target state requires a significant transformation project—the Big BPM Project.

Such an undertaking may appear quite daunting at first. It is complex to change the way an organization, its people, and their teams think about who they are, what they do, and how they do it. Thoughtful preparation and careful execution of well-defined work packages make a successful Big BPM transformation project eminently achievable.

17_Big_BPM_1.png

This paper describes a very practical approach to the Big BPM Project. It may be used as a reference model on which to base a specific project design. Figure 1 shows a high-level view, showing how the 7Enablers shape the required set of work packages ‘get the circles turning’, along with the establishment and preparation elements necessary to enable transformation to a mature process-based management operation.

Emphasis is placed on the establishment and preparation phases, since they provide the necessary foundation for other project activities, and are a prerequisite for successful transformation.

This is not a detailed project-management treatment of the Big BPM Project, since that material is readily available from many other sources. Rather, this paper provides commentary on those aspects that are unique or particularly important to the Big BPM Project.

To maximize project efficiency and keep all key stakeholders continually informed about progress and design decisions, having two project teams is recommended.

The development team is the core project team comprised of the people who will work on the Big BPM Project to deliver the work packages and related activities. Additional people, acting as subject matter experts, will be involved from time to time, participating in workshops and other discussions and reviews.

The reference group is comprised of senior managers and executives, the people who will ultimately make decisions regarding the project deliverables. This group is formed are to boost experienced management input, and to facilitate later decision-making and implementation of changes by keeping decision-makers continually briefed and engaged.

How long does it take to complete the Big BPM Project? Assuming the establishment phase to be complete, the rest of the project might take between three and six months. Note that this brings the project to the point where each of the enablers has been activated and related activity is ongoing and becoming commonplace.

Establishment phase[1]

An understandable desire is for immersion in project detail as soon as possible—to start building the architecture, assigning measures, running workshops, and doing the many other activities in the plan. However, to do this too quickly will bring failure. Without shared understanding and commitment at all levels, confusion, division, and apathy are inevitable.

The establishment phase is a vital preliminary step intended to create throughout the stakeholder group, especially at executive levels, a shared understanding of why the Big BPM Project is important, based on compelling reasons reflecting the realities of the organization.

A secondary, yet very important, objective is to assess the organization’s appetites and aptitudes for the prospective operational and cultural changes. Is the organization ready?

The foundational outcomes required for success in the establishment phase are:

  • organizational strategy clearly articulated and widely agreed
  • compelling reasons agreed and documented
  • comprehensive stakeholder analysis completed
  • communications plan, reflecting stakeholder analysis, agreed
  • documentation of decision-making guidelines complete
  • assessment of BPM culture completed and discussed
  • assessment of BPM maturity a completed and discussed
  • agreement to proceed supported by all key stakeholders.

Preparation phase

The preparation phase, possibly taking one to two weeks, is about arranging project logistics, and starting the project. The minutiae of project management are put in place in this phase: scheduling workshops and interviews, booking spaces, creating project libraries etc. Other sessions, workshops, and meetings may also be useful in properly starting the project.

Project work packages

Once the establishment and preparation stages are complete, it’s time to get into details of the work packages that will be the core of the Big BPM Project. The work packages for each of the enablers are discussed below.

For the purposes of description, the work packages are presented in separate and seemingly linear form, but in operation, they are put into effect largely in parallel as shown in Figure 1.

Work package #1: process architecture

Project objectives (WP1 architecture)

In the Big BPM Project, the objectives for the architecture work package are as follows:

  • Create and publish the first levels of the architecture.
  • Develop common understanding of a process architecture.
  • Begin development of maturity in the management and use of process architecture.

Project deliverables (WP1 architecture)

The key deliverables from this work package are:

  • an initial process architecture modeled to three levels of core processes and one level of management and supporting processes
  • short (fifty words maximum) description of each process identified in the architecture to provide information about its intent
  • presentation and communication material for informing and educating stakeholders about the importance and use of the process architecture.

Work package #2: process measurement

Project objectives (WP2 measurement)

The process measurement work package has the following objectives:

  • Assign performance targets to key processes defined in the process architecture.
  • Define how performance data will be collected and reported.
  • Create systems to make evidence-based decisions prioritizing process improvement.
  • Continue to embed process-based management by ensuring that all stakeholders understand the importance of process performance measurement.

Project deliverables (WP2 measurement)

The key deliverables from this work package are:

  • measures and targets assigned to the top two levels of core processes
  • measures and targets assigned to first level of shared management processes
  • measures and targets assigned to first level of shared supporting processes
  • measurement methods identified for all targets
  • where useful, explanatory notes to show reasons for selecting process measures
  • presentation and communication material to inform stakeholders about the importance and use of process measurement.

Work package #3: process governance

Project objectives (WP3 governance)

For the process governance work package, the following are the key objectives:

  • Ensure that active management of cross-functional process performance is based on evidence and assigned roles.
  • Ensure that process improvement deals with both performance anomalies and idea discovery for process change.
  • Take an important step toward enhanced process-based management maturity by bringing together the theory and practice of process architecture and measurement to form a practical management framework.

Project deliverables (WP3 governance)

The key deliverables from this process governance work package are as follows:

  • agreed role descriptions for the process owner
  • process owners appointed to Level 0 core processes, and possibly also to Level 1
  • process owners appointed to the key Level 1 shared management processes
  • process owners appointed to the key Level 1 shared support processes
  • support plans to assist process owners meet their role accountabilities
  • communication material to inform process owners and other stakeholders about the importance and operation of process-governance arrangements.

Work package #4: process change

Project objectives (WP4 change)

The change enabler objectives for the Big BPM Project are as follows:

  • Create an environment where continuous improvement, using a standard methodology, is common practice.
  • Ensure all staff are willing and able to participate in process improvement activities.
  • Create a consistent mechanism for prioritizing processes for analysis.
  • Establish of a way to track the realization of promised benefits.

Project deliverables (WP4 change)

The key deliverables from this work package are:

  • agreed, fully documented process improvement methodology
  • improved project selection prioritization scheme
  • process improvement curriculum and development plans
  • initial process improvement projects
  • communication material, to inform stakeholders about the importance and execution of process change.

Work package #5: process mindset

Project objectives (WP5 mindset)

The mindset work package has these objectives:

  • Embed process thinking in all stakeholders so they understand, and seek to optimize, their roles in process execution.
  • Develop a culture that values process measurement and continually seeks opportunities for improvement and innovation.
  • Engage the organization, its people, and their teams in new ways of thinking about customer service delivery.
  • Enhance widespread understanding of the cross-functional nature of value creation, accumulation, and delivery.
  • Involve all staff in the definition and execution of process improvement aspirations and initiatives.

Project deliverables (WP5 mindset)

The key deliverables from this work package in the Big BPM Project are:

  • comprehensive process change management plan to define and guide communications with all stakeholders
  • an appropriate ‘community of practice’ to support and nurture the process mindset
  • well-defined communication channels with plans for development and maintenance
  • effective system to stimulate and manage process improvement suggestions.

Work package #6: process capability

Project objectives (WP6 capability)

The Big BPM Project has the following objectives for the capability enabler:

  • Ensure all staff can participate in process improvement and management activities.
  • Enhance staff capabilities to deal with change and cross-functional working.
  • Support staff with access to process-based management information and systems.
  • Develop and maintain an accessible body of process knowledge.

Project deliverables (WP6 capability)

The key deliverables from this work package are:

  • documented learning pathways to define and deliver capability development
  • curriculum tailored to match different stakeholder requirements
  • accessible documentation about process methodologies, tools, and techniques
  • knowledge base related to process-based management theory and practice.

Work package #7: process support

Project objectives (WP7 support)

This project work package has the following objectives, to:

  • Improve process-based management capabilities by providing effective support.
  • Support staff in the analysis, improvement, and management of business processes.
  • Ensure compliance with standards and conventions.
  • Support process owners and the process council.
  • Monitor and improve the ‘process of process management’.
  • Enable efficiency and effectiveness in all aspects of process-based management.

Project deliverables (WP7 support)

The key deliverables from this work package are:

  • operational office of BPM providing initial services to the satisfaction of stakeholders
  • documentation describing the services available and how they are accessed
  • performance measures and targets for the operation of key office of BPM processes.

Business better than usual

At the end of the Big BPM Project, a process architecture has been defined and documented, process performance measurement has been established along with related governance mechanisms, and continuous improvement (change) methodologies have been implemented. In so doing, the process mindset and capability of the organization, its people, and their teams have been enhanced, and support facilities have been put in place.

The stage is set for successful ongoing process-based management. Completion of the Big BPM Project marks the start of effective, sustained process-based management.

 New Call-to-action

[1] This paper provides a high-level overview of the project phases and work packages. For a more detailed treatment see chapter 10 of the book Reimagining Management.

Topics: BPM - Business Process Management

Make Process Ownership Happen in Financial Institutions

Clement Hurpin on May 31, 2017

Making_Process_Ownership_Happen.png

Process owners, process steward, process custodians—many words you may have heard thrown around over the past few years. As the concept of process ownership is slowly getting traction across the board, organisations are appointing process owners more frequently than ever, and process ownership is starting to get included in role descriptions.

Why is that? Why do you even need someone to manage a process when it is intrinsically the objective of a company to perform as best it can? Because each individual trying their best to make a company succeed is not sufficient anymore: there is a clear need to layout, measure, and improve processes systematically—and, for that, someone needs to be responsible for those processes.

A wide array of definitions

Let’s start with the necessary step of defining process ownership. Perusing the interwebs provides many definitions of the concept, some with important differences. Let’s take, as a starting point, 6 sigma’s definition, the broadest one identified: “Process owners are responsible for the management of processes within the organisation.”[1]

Process Owners (POs) are responsible to manage processes. What does manage mean? This definition does not say.

Then follows two definitions with conflicting elements, illustrating well the potentially confusing nature of the process owner. On the one hand, the business dictionary defines it as “[a] person who has the ultimate responsibility for the performance of a process in realising its objectives measured by key process indicators, and has the authority and ability to make necessary changes.”[2] On the other hand, we, at Leonardo, think of the role as more of a facilitator, where the process owner is accountable for responding when process performance is outside of the accepted range (or trending in that direction), and when a change of target is appropriate. A seemingly small difference at first, it is a crucial matter when it comes to practical applicability.

Toothless tigers?

As my colleague Roger Tregear wrote in his paper Thoughts on the Conflicted Use of Process Language,[3] “differences in the definition of basic concepts in and around BPM are not just of pedantic or pedagogic interest, they cause a lot of wasted time and create confusion, which handicaps development”. There is a fundamental difference between having ultimate responsibility for a process, and being accountable to respond when your process does not perform as expected.

It boils down to the following: for a PO to be responsible for the performance of the process, he/she would need to:

  • be responsible for the performance of something over which they don’t have complete control of (i.e. in the case of cross-functional processes, one specific person would be responsible for the performance across departments);
  • have ultimate design authority (e.g. change whatever they like), which can be impractical and conceptually hard to sustain at lower levels.

Most companies are not ready to let their POs have such power within the organisation. This is why many choose to define the role as an addition to influence (in this way becoming less of a process owner, but more of a process custodian or steward), not an additional responsibility managers need to be worried about. But such POs can be perceived as ‘toothless tigers’, unable to truly effect change—which is why some organisations can give full responsibility and accountability for process performance to their process owners, the tooth-y tigers, if you will.

Process_Ownership_Financial_Institution.png

‘Owning’ processes in financial institutions

With banks expecting more mergers and acquisitions around the world, and in Australia,[4] we are starting to see the emergence of many organisations with standardised processes under the leadership of a single-point owner. One of the keys to such an operating model is having process ownership for end-to-end global standard processes, with variations only determined by tax and legal requirements.

Combined with mergers and acquisitions, technological changes have been an important driver of change in Australian banking. The different software solutions used to manage any bank are already being pressured for more agility and reduced costs. However, with an expectation for financial institutions to always deliver more to their clients (in the form of phone apps, and online credit cards or loan applications) legacy systems may have to be radically transformed to provide the expected customer experience. We are not talking about just reducing the cycle time of an application to X weeks, we are talking about reducing it to X clicks. Another big change in the Australian banking technology landscape is, at the time of this writing, the upcoming release of the New Payments Platform (NPP), which is due in the second half of 2017. The new infrastructure will provide Australian businesses and consumers with a fast, versatile, data-rich payments system for making their everyday payments. Payments will be made quickly between financial institutions and their customers’ accounts. The system will enable funds to be accessible almost as soon as payment is received—even when the payer and payee have accounts at different financial institutions.[5] Managing processes just became more complex!

This is why the process ownership concept is becoming very important, as many of main processes of financial institutions are inherently cross-functional. Let’s look at one of the main revenue source for a bank: loans. Loans (be they commercial, personal, home mortgage, or even a small credit card advance) involve all, or almost all, of the organisation. The creation of a new loan type is a strategic decision made with the analysis of the finance department; the promotion of that product is done by marketing, while operations would process applications—and so on. Loans, though, are just one example, as many other core financial sector processes could benefit from process owners: transactions (deposits, withdrawals), financial advisory, foreign exchange, or investments (trading, superannuation).

The separate contributions of those various departments to eventually provide a loan to a customer requires cross-functional oversight. Why? Because localised (meaning inner silo) management and improvement could be done at the expense of the global loans process: marketing will be driven by sales; operations might be driven by cycle time to fulfil a loan request needed to deliver; while finance would aim at cost reductions. To orchestrate such complex process, a process owner is required.

This is becoming more crucial as banking regulators take a lot more interest in end-to-end process views: with different business lines, departments, countries, etc. Providing the right level of transparency to comply with regulations has been getting harder, but managing the risks (and related controls) of such processes has become increasingly complex.

‘Owners’ of intangible processes

It is particularly important, and beneficial, for the financial sector to appoint process owners, as the sector is quite prone (due to a lot of immaterial/intellectual work) to outsource people and non-strategic processes (reconciliation, basic accounting) in functional areas to drive costs lower. This can go beyond the sole operating structure that banks now must manage on top of their subsidiaries. Some products can be designed at the ‘main’ company, but are then packaged and sold through a subsidiary. Who then owns that process? Who ensures that it runs smoothly? Someone needs to be responsible to ensure all the connection points—between departments, physical locations, etc.—are looked after. Through process ownership, appointed key individuals (often C-level executives) are held accountable for building, standardising, and maintaining processes throughout that business’ operating structure.

So how do you make process ownership happen? This is no trivial task, but it does not have to be complex. Here are some tips to make PO happen at high level in banks and other financial institutions:

  1. Establish an infrastructure to ensure top-down support—with an executive sponsor, a cross-functional steering committee, and process owners.
  2. Start by appointing process owners for the first two or three levels of your process architecture, so they can manage the process and respond to the process’ KPIs. You can (and probably should) start small, but always top-down.
  3. After a few cycles and readjustments, propagate the concept to lower levels of the organisation as required. We found that meetings of process owners contributing to same value chain from different departments to be very useful in making process ownership pervasive in any organisation.

Conclusion

Banks are now primed more than ever to undergo a global transformation of governance infrastructure to align processes, people, and technology. They can enable optimisation by eliminating ineffective methods across their business units’ operating models.

With processes—and their governance through process owners—banks and other financial organisations can manage critical processes across departments, service centres, entities, or physical locations—ensuring connections points, and overall performance, are managed and improved.


[1] https://www.isixsigma.com/implementation/change-management-implementation/process-ownership-vital-role-six-sigma-success/
[2] http://www.businessdictionary.com/definition/process-owner.html
[3] http://blog.leonardo.com.au/thoughts-on-the-conflicted-use-of-process-language
[4] https://www2.deloitte.com/au/en/pages/financial-services/articles/financial-services-ma-predictions-2017.html
[5] http://www.apca.com.au/about-payments/future-of-payments/new-payments-platform-phases-1-2

 New Call-to-action

 

 

 

Topics: BPM - Business Process Management