"Where Information Technology Is Purely Business & Engineering"

      Home Employment Contents                              Stamford, CT (203) 329-7013

Reengineering 
Up Reengineering DB Comparisons Project Pitfalls Special Studies Web/Client/Host IT Effectiveness

 

 

 

Professor Rino Nori's Fairfield University School of Engineering graduate school home page

 COST SAVING TIPS: Reengineering

Beginning with the decade of "IT Strategy", proceeding through the decade of "IT Driven Change", and now entering the "e-Commerce and Collaboration" decade, Business Process Reengineering (BPR) along with its recent extension of X-Engineering (X-Treme Business Reengineering or XBR) has made some authors, software houses, and consultants quite rich, however, will it improve your bottom line?  The concept of reviewing your operations and alliances, with the intent of focusing upon and enhancing your competitive advantage, is not foreign to businessmen. What is new, is the assumption by some companies that major process related changes, significantly different from current methods, can be quickly implemented and will most likely result in the desired benefits once a brief transition period has concluded.  Even if performed by the most experienced personnel with pure objectivity, one should note that not all change is necessarily good and piloting any significant change is always a prudent step.

In undertaking BPR or XBR, unless senior management is THE driving force, unless the "best" people are assigned to the effort, unless the scope and the authority of the effort is clearly defined, and unless budgetary resources are allocated for implementing the recommendations, it is highly unlikely that any significant changes (improvements or otherwise) will ever be achieved.  As BPR focuses upon improving the internal company processes, XBR uses technology to redesign work processes between a company and its customers, suppliers, and partners to improve efficiency, lower costs, and enhance value for all.   Clearly, the latter is more difficult to achieve.   Additionally, even if the best and most objective resources are assigned, one must recognize that errors can occur.  Prototyping new processes and alliances, and then then evolving into them poses significantly less risk and allows for the refinements to be made.  The iterative software engineering approach, as put forth in many contemporary Object Oriented software development methodologies, is a good guide for the conduct of the BPR and XBR program effort.  Changing many processes at once primarily benefits the consulting firm who is preaching that any delayed implementation of changes will result in deferred cost saving and revenue improvement opportunities.  This is somewhat similar to the financial advisors of recent years who preached that not investing the bulk of one's portfolio in equities and mutual funds would not allow one's principal to keep up with inflation.  Well, those that have followed that advice have certainly not kept up with inflation, they haven't even kept their principal.

It is far better to be cautious, and to evolve into new business processes and alliances.  New systems, functionally different than the existing systems, will most often result as the required vehicles for implementing the changes outlined in the BPR and XBR.  Many of these new systems will probably encompass workflow techniques, web services capabilities, wireless communications, technology services which are rapidly evolving and gaining major attention in business.  Such software, with costs ranging from several hundreds to several thousands of dollars per user, is an enabler of BPR and XBR as it allows a company to use a shrink wrapped flexible toolset for automating information based tasks and integrating a company with its suppliers and customers via the internet through XML, eMail EDI, and industry specific B2B portals.

To achieve those new systems, companies can rely upon full application software suites from major suppliers, commonly known as ERP (Enterprise Resource Planning) systems.  Those products, along with Web Services providers, Application Service Providers (ASP), and B2B portal providers, can assist a company in implementing the desired new business framework.  Whether a company implements an ERP solution or chooses custom development along with "best of breed" for certain applications is dependant upon the organization and its needs.  Similarly, hosting the application in-house or relying upon an ASP is another decision that should be evaluated on an application by application basis as well as on an enterprise basis. 

It should be noted that in the past some companies assumed that implementing an ERP system meant that a BPR had to be performed, -or- performing a BPR meant that an ERP system had to be implemented.  Performing the study and then deciding on which recommendations to implement, and how to implement them and when, are all different decisions which should not be tightly coupled.  Similarly, deciding to implement an ERP system is based upon the assessment that the current applications suite cannot support the business requirement and needs to be replaced.  Clearly, the ERP system can be partially implemented (i.e. only select applications) and it can be implemented to support existing business processes, not necessarily new ones.  Accordingly, it is far better to divorce the two efforts.

If both efforts are to be performed, we believe that a portion of the BPR should be performed first, and then once the first iteration has been completed the corresponding aspect of the ERP system should next be implemented to reflect that iteration and those processes.  The full set of ERP software need not and should not be implemented all at once.  After a couple of quarters, or a full seasonal cycle, a second BPR iteration should be performed and the affected systems should be correspondingly addressed.  This iterative approach should be continued until the organization will have gradually and smoothly migrated into the new business processes and systems.  If necessary, at the end the systems may have to be re-implemented to reflect the final configuration, as the iterative  evolution may have resulted in built in disparities and inefficiencies.  The risk of incurring this final effort is manageable and its cost accurately quantifiable, as at this time the ERP systems are a known entity and the final business configuration is a known entity; all that is required will be the smoothing out of the work-arounds and self imposed limitations that were built during the iterative approach. This last step and added cost is a very small price to pay for the reduction of overall risk and the prevention of costly disasters.

BPR and X-Engineering is not for the faint of heart or for the budget conscious, it is for those who are willing to make a major investment in the future of their business and are objective and honest enough to make the necessary changes.


For general information, inquiries and comments Email to:                                                                            Copyright 1999-2009 Nori & Associates
Last modified: March 02, 2009