BPM Blog Series Introduction by Steve Steinheimer, President & CEO, SSG, Ltd.
SSG welcomes back Mark Peterson to the SSG Team. Mark is an experienced Business Process Management (BPM) consultant who spent the last 10 years with Oracle, Fuego and SSG. Having designed and implemented complex systems and processes and served as an Instructor of BEA ALBPM, Mark is now applying his breadth and depth of knowledge to lead SSG’s BPM practice.
Prior to his experience as a Software System Architect for Oracle Corporation/BEA, Mark held positions at M/A-Com as a Software and RF Engineer, at Raytheon as a Systems Engineer, and at Vector SGI as a Software System Architect. Mark earned his Bachelor of Electrical Engineering from The University of Lowell and his M.S. in Electrical Engineering from Tufts University.
This week begins an eight part series about BPM, including POA - Process Oriented Architecture. We think you'll find it compelling and informative.
BPM and POA: An Overview
Implementing a Process Oriented Architecture (POA) for
Business Process Management (BPM) initiatives provides organizations with the agility needed to incrementally build out business processes. Companies can make improvements over time as the business is able to digest change. Yet the organization can leverage every process automation investment because the architectural structure binds them together to work as a whole.
I like to think of POA as being to business processes what Service Oriented Architecture (SOA) is for business services. It allows businesses to realize immediate gains from BPM while putting the company in a position to evolve and expand these processes consistently and continuously within and across an organization.
BPM often starts within a department – such as Procurement or Legal where human error can cause critical delays. As organizations dive into any single process to automate it, they find that it spans across departments or communities. It is important to approach BPM in a way that ensures later process automation projects will be compatible with the first project. That’s where POA comes in – to tie together multiple processes into a larger whole for a fully orchestrated, transparent, business-centered, and automated business process.
Without the right architecture, an organization would have BPM in silos; separate, vertical divisions with no connection. This actually works fine for many applications because indeed, many people in a company do not need to worry about what's happening in other areas. However, C-level management always needs to cut across the entire organization to see where the bottlenecks are, where inefficiencies exist and what the cost drivers might be.
Next week: The Background of BPM