Wednesday, May 16, 2007

More on business process-change is good

At the SAP Community Network, this blog post describes the basics of handling changes to how a particular process works. The author describes drivers of change as follows:

"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."

This seems fairly obvious, perhaps this just needs to be laid out on paper for companies to get the ball rolling when figuring out how they are going to handle changes in how their systems work. The author also lists what such changes may involve:

  • 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.

Again, fairly straightforward but good to have in black and white. The key to success in changing a process is making sure that every step in the process is identified, and understanding what effects changing a particular step will result in. Failures in ERP implementations frequently occur, I believe, because companies didn't take the time to understand what the effects of making particular changes would be. For example, low level employees using a system that is to be replaced typically have developed poorly documented short cuts and workarounds that help them be more productive. When a new system is put in place, all that disappears and the time to complete tasks under the new system will typically take longer initially due to the learning curve that the workers need to become proficient with the new system. If a company didn't factor in the need for time to become proficient with the new system, the target date for "going live" frequently is missed.

No comments: