New technologies, the rapid pace of change and customer-centric commerce are driving the need for process management...
to readdress its competencies. In fact, my organization, APQC, found in its annual priorities survey that 88% of organizations feel their process management teams need to evolve to stay relevant.
But what exactly has to change? In addition to the adoption of new skills and technology, 48% of the organizations surveyed feel that their process teams need better integration with IT.
One way organizations realize this integration is by employing their process management teams as the bridge between IT and the business. Process management's background in facilitation, scoping and managing improvement projects makes it a valued asset in ensuring the business does not go rogue with self-serve automation applications and that it can properly scope and get the "right" projects it needs in the IT pipeline effectively.
Let's explore the role of the three main entities -- IT, business and process management -- why collaboration can be beneficial and what steps help to solidify the partnership.
How do the pieces fit together?
Typically, IT and process management are both tasked with identifying and implementing the right solutions for the organization's improvement efforts -- whether it's improving workflow, managing robotic process automation (RPA) or developing new systems, features or add-ons for applications such as ERP.
The interconnected nature of these teams' efforts requires understanding how their responsibilities interact. How organizations accomplish work can be categorized as a pyramid comprised of three levels:
- Operations (top level): procedures and policies.
- Processes (mid-level): processes and workflows.
- Technology (bottom level): core systems and technology.
The complexity, cost and time of enacting changes decrease the further up the pyramid you go. Also, changes in one layer directly cause changes in the layer above it. Consequently, effective solution development -- particularly at the bottom two levels (process and technology) -- requires balanced collaboration between the three key stakeholders:
- IT provides the technical skills and systems know-how to ensure that software and other technological solutions are the best fit for the organization's needs. Typically, IT's responsibilities in the partnership include vendor assessments; coding; system development, maintenance and integration; and security management.
- Process management provides process development and re-engineering expertise, change management methodologies, and facilitation and scoping skills. Typically, this team's responsibilities in the partnership include managing the improvement opportunity pipeline, developing project scopes with the business side, and process documentation and re-engineering.
- The business provides subject matter expertise and change champions. Typically, the business is the source of the problem, which means its role is to provide expertise on the problem and the needs of the business, and, ultimately, ownership and adoption of the solution.
What happens if there is an imbalance?
In APQC's recent research on RPA, we found three common scenarios for process automation in organizations: It is either owned by IT, owned by process management or there is a center of excellence that incorporates both entities as key partners. However, when the collaboration between IT and process management becomes unbalanced, organizations are unable to realize the benefits expected from this automation work.
For example, when automation is the sole province of IT, participating organizations struggle to gain a critical and thorough understanding of the processes being automated, particularly when it comes to process variations and exceptions. Even areas that are well mapped don't always have processes that are optimal for execution by a bot, and the team faces ongoing change requests for bots. On the other hand, when automation is the sole province of the process management team, organizations struggle with systems integration, risk management, territorial disputes and access rights for bots.
How can organizations make it stick?
One solution to such imbalances is to clearly delineate ownership of the different solutions in your current and future technology stack. The technical changes can be as simple as modifying existing ERP software or as complex as adopting multiple automation systems including RPA, intelligent process automation with machine learning and natural language processing capabilities, or AI with built-in diagnostic or predictive models.
Best-practice organizations take this a step further and strive for equilibrium through regular check-ins between IT and the process management team and governance for every aspect of the process, from identifying and approving opportunities to development and implementation. For example, Engie, a French energy provider, formalized the relationship between the process management and IT teams for its RPA work. Early on, it created a charter that documents the roles and responsibilities between the groups.
Typically, in these best-practice organizations, process management teams are responsible for:
- managing the improvement opportunity portfolio;
- working with the business to build out business cases; and
- scoping the needs and requirements of projects.
In some organizations, the process management team is also responsible for assessing system requirements, IT manages development of any technical solutions, and the process team steps back in during implementation to provide training and, on the back end of system projects, to support adoption in the business.
Though this approach initially seems bureaucratic, over time it speeds up the process and ensures that organizations use the right tool for their problems, regardless of where the tool fits on the pyramid. The key point is that IT and process management teams formalize their partnership and work together to assess the pipeline of opportunities and determine the best-fit solution -- and which team will take the lead.