Skip to Content
Author's profile photo Former Member

A Process Flow for Introducing and Disseminating A Business Process Change

I have played the role of business-IT liaison and data Modeler/data analyst for 6 years now. I have always been interested in the process flows that can pave way for smoother communication between business and IT. In this blog, I attempt to describe what I think is the baseline (minimum) process flow for introducing, and disseminating a business process change in a given business unit to the end downstream system(s).

A change is always difficult because it involves risk, costs, and requires giving up familiar and comfortable ways. But change is the only way to evolve. It is hence a necessary evil. In today’s world, the IT systems landscape for an organization can be moderately complex to very complex including legacy systems (mainframes), ERP systems, product information hubs, catalog management systems, warehouse management systems, sales planning, finance, etc. Also, depending on the organization, you have 1 to many business units that can initiate a process change. Sometimes the implementation of these changes needs a concerted effort across business units.

Below is a sample process flow that depicts how a business process change could get communicated with end downstream customers, and how the impact analysis can be achieved in collaboration with them to provide a recommendation back to the initiators of the change. In the text below I am going to explain some characteristics of each of the steps involved.

What are some characteristics of a Business Process change?

A process change could arise because a business unit could be recommending a new way to classify their products by adding/modifying some attributes; another business unit may want to streamline their purchase order process, etc. The initiating business unit/organization clarifies the business driver for the change, the benefits (in terms of ROI) to the company from the change, and gives a high-level time line for when they would like to see the change implemented across the company’s value chain.

A business process change could be a brand new business process being put in place or a combination of a new process and some changes to an existing process. In most cases (in all established organizations), it is the latter.

How do you communicate and collaborate with the downstream customers?

What does a business process change involve? It can involve some or all of the following:

  • Process changes
  • Data structure changes (entities, relationships, and attributes including key identifiers).
  • Meta data changes (definitions of business elements across the enterprise, business rules, etc.)
  • Data changes from end user stand point
  • System changes/enhancements in the change initiating systems, and downstream end customers.

Business Process Expert is the role that is called into action to collaborate with the downstream customers, communicate the proposed business process changes, and provide a recommendation back to the business unit initiating the change. The business process expert fits this role for 4 key reasons:(1) extensive business knowledge combined with IT systems knowledge, (2) ability to map and model the business changes to systems, (3) excellent communication skills to facilitate, negotiate, and collaborate, and (4) helicopterability that lets the BPX delve into details of a given process or systems landscape, perform the mapping, and soar up back high to summary level.

How do you approach the impact analysis of business process changes?

The approach you take is a function of the nature of the change being proposed. In general, the impact analysis may be conducted in 2 phases:

  • A high level impact analysis to get a ball-park estimate of feasibility, extent of disruption this change may cause to mission critical systems, the breadth of system changes required (high level #s of applications and interfaces this change would impact), and the depth of training required. This would give cost and risk estimates that can be compared with (original) expected numbers from BU. Based on the facts and numbers from high-level analysis, a decision can be made on whether to continue with detailed analysis or stop.
  • A detailed impact analysis may then be conducted to identify the scope of changes required by application, and interface, projected time lines, detailed cost estimates, resource estimates, approach, etc.

Depending on the nature of the business process change, the impact analysis could follow one or more of the following methods:

  • DATA focused approach
  • Data Modeling focused approach
  • Enterprise Architecture focused approach.

A business unit could aim at adding and changing a number of business elements that define multiple views of their item classification. An enterprise architecture focused approach may be well suited for such a scenario enabling a look across various business units, standardizing the business element definitions, removing redundancy, minimizing duplication, and providing consistent item classification across the organization.

A data modeling approach may be more suitable if the business process change involves redefinition of key fields, and comparison/ mapping of old view data structures to new view data structures. An example may be redefining the hierarchy of location subject area in the enterprise.

A data focused approach is used along with the above approaches in most cases simply because showing the actual data is the easiest way to communicate the change to a business audience. A data focused approach alone would be appropriate if the proposed business process change involves redefinition of values of a given business element, and remapping.

How do you recommend back and close the process flow?

Depending on whether the impact analysis proceeded to the detailed analysis phase or concluded after the high-level analysis, the BPX, in collaboration with end downstream partners, prepares a report that describes the reasons and method for the implementation of a given business process change.

For instance, if the business process change were too disruptive, and hence not acceptable, the recommendation to change initiating business unit would include sections on:

  • Process Change description
  • Downstream system Name
  • System modification details
  • System modification risks
  • System modification costs
  • Recommendation Contingency Plan for BU

The BPX may, in certain cases, want to identify the contingency plan in collaboration with the change initiating BU before taking the changes to downstream customers. Currently, organizations follow a very rigorous process in the analysis of change proposals, and one of the first questions the steering committee of downstream customers may ask is “What happens if the change is not acceptable? What is the plan B for the business unit?”

When the proposed changes are acceptable to downstream customers, additional sections such as projected timelines for implementing the change, options/alternative solutions for each of the change items, etc. need to be added in addition to the aforementioned ones.


The entire role of BPX is evolving rapidly. This blog represents the fundamental elements for Change Management and Process Flow, and the involvement of BPX in facilitating the flow. In practice, business process changes that are incremental and do not endanger the status quo (status of people, expertise, the investment, etc.) are accepted relatively easily. Changes that are disruptive, replace old technology, and render old expertise obsolete, encounter greater resistance. Acceptabilityof changes also depends on the pain to learn the new process/technology relative to the pain that we have with the old process/technology.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Your process is very well described from a human process standpoint and fits very much with what's happening today in most organizations operating under traditional system architecture. The output of that is development projects.

      What I see in organizations that started on their SOA journey, the challenge with Business Process Change is that they're struggling for many reasons (ability to embrace and digest innovation, complacency with known technologies and comfort zones, ...) to even do Business Process Modelling, Design and Execution.

      For them, Business Process Change is one of the many benefits is their SOA efforts which means Business Process Recomposition instead development projects. At least that's what all of us, believers of SAP eSOA and Netweaver as Composition and Business Process Platform, hope. At least I do. And I know a few ISVs, System Integrators and Customers who do too. The question is how long or how fast before it reaches the general market.

      Author's profile photo Former Member
      Former Member
      Hi Andre,

      Very interesting comments.  Here is how I look at it: as more organizations move towards SOA, you will see innovation in execution of a business process change. 

      There are organizations that have multiple upstream and downstream systems, and sometimes an additional central data management or consolidation system.  In such cases, a business process change, say, a BOM process change for a couple of business units, does need a clear communication and collaboration with all dependent systems.  The methods and tools you use certainly would differ drastically as we move towards SOA.  It would not result in a separate development project but would be implemented at the same time the process is recomposed.

      In the interim period, before more and more organizations move towards SOA, we still need this process...


      Author's profile photo Marilyn Pratt
      Marilyn Pratt
      I would agree that a move toward an ESOA context is an evolution and in any evolution there are intermediary steps.  I liked the way Savitri described "interim" process.
      I think that also includes the way the community is evolving. Functional consultants are gradually moving out of an application specific silo-think to a more horizontal process-think and there are
      some that see that as the role of a BPX, bridging not only IT and business but also bridging to a more cross-functional horizontal way of thinking (process across applications and functions).

      As with any organism that evolves, even if there is a "mutation" that causes a disruptive innovative) change, there still is some link that allows us to see the progress or change from one form to another.  If one buys into an organic evolutionary concept, a species doesn't instantly turn into another species overnight, even if there are mutations or evolutions , these are steps, some more drastic and radical
      than others 🙂

      Embracing SOA doesn't mean total abandoning of any previously held development concepts.  Development gets absorbed into very sophisticated models and modeling tools that generate or automate development.

      That's my very simplistic think.

      According to Mattern and Woods, in their recent book: Enterprise SOA:
      "Architecture must be model driven.  It must enable knowledge workers to create new scenarios or business processes that can be manipulated with
      graphical tools linked to enterprise services....the idea is to liberate enterprise services from monolithic applications.... ESA isn't a silver bullet, it's not "best of breed" repackaged under a different name with a new set of marketing materials.  It's a complete
      architecture composed of a bpm, standards, services, and infrastructure. Modeling tools actually expand the pool of developers to include
      appropriate business analysts"

      So under the service there IS development, whether it is automated or

      By the way, the authors will be at the SDN Clubhouse in TechEd Amsterdam.  The community can also converse with them there.


      Author's profile photo Former Member
      Former Member
      I agree that the biggest challenge in advancing the adoption of ESOA is that the baseline business processes are undefined and unmanaged in a process-oriented way.  Most technology organizations take their cues from the upstream businesses that they support.  To the extent that the businesses aren't process-oriented, the IS organizations that support the businesses aren't process-oriented either and thus are less able to truly leverage the power of an ESOA approach.

      The promise of ESOA for the whole enterprise can only be realized when a company's processes are clearly defined.  Once defined fine-tuning or disruptive change can occur with respect to the baseline.  IS activities are then focused on continuous improvement of the existing process steps and on innovation around the baseline.

      To me, without process orientation in the larger organization, ESOA will never be anything more than an efficiency for IS.  IS may deliver projects faster through reuse and open standards, but real innovation and creation of competitive advantage will be limited. 

      The "project" mindset is a powerful force in most companies and is a significant detriment to business process evolution, continuous improvement, and the adoption of ESOA. 

      Author's profile photo Former Member
      Former Member
      Is the above flow diagram available? I am interested in anything around change management methodologies.