Lecture- Reengineering 1

Analysis and Design of Information Systems Reengineering Version 1.0 In 1990s the usual methods for improving performance (e.g. process rationalization and automation) did not yield dramatic improvements that companies desired. Huge investments on IT also could not bring the desired output. The reason behind this is the companies were trying to do old fashioned works with new generation technologies. So, instead of working with computers to solve outdated processes we need to reengineer the processes. Old processes may include some strict rules like “departments should only focus on their own department”, “Forms should be filled in completely and in order”, etc. Reengineering involves in reorganization or rejection of some of these ideas. From the redesigned process, new rules will emerge that will satisfy the demand of time. Reengineering cannot take place for small and cautious steps. It may contain uncertain results as well.

$ $

In Ford automobile company, the accounts payable department was as follows. $

No. of Purchases No. of Goods Received

Receiving Department

Purchase Department

Accounts Payable Department

If Everything Matched then Payment is Done Bill

Suppliers

Figure: Ford Company’s Problem with A/C Payable Department

Rushdi Shams, Dept of CSE, KUET

The problem occurs when there is a mismatch among 3 documents. A/C payable department then needed to generate report, hold up payment, check what actually happened, etc.

$ $

The solution for the problem was very simple. It is provided below. $

No. of Purchases

No. of Goods Received Receiving Department

Purchase Department

Looks in Database only when a bill arrived

Accounts Payable Department If Everything Matched then Payment is Done Bill

Suppliers

Figure: Solution for A/ C Payable Department Mutual Benefit Life Insurance (MBL) realized that computer networks and shared database are very helpful to make information available to every person and expert systems could help to make sound decisions. MBL omits the boundary among departments and created case managers whose job was autonomous. Case managers handled application forms with expert systems. He might need help from higher or senior officials but these officials’ roles will be only consultant. They will not control his works/ decisions. The trend of running towards cost, growth and control which evolved after WWII is obsolete now. The main concern was to grow fast and without getting broken. At that time low level employees were abundant and all educated people tended to go to the top maintaining strict hierarchy. But today’s concern is quality, innovation and service. Large number of people are now educated. Conventional processes as they go through hierarchy and step by step it is difficult to integrate them. Person to person, unit to unit delays are inevitable. As all the departmental employees are confined within their department only, they cannot see the whole functionality of the organization. During reengineering, it is recommended to create two teams- one that will go through reengineering process and the other that depends on the first team. It is necessary to know what are the tasks and what they are trying to accomplish. It is Rushdi Shams, Dept of CSE, KUET

recommended to know “why it happens” rather than “what happens”. Rather than improving the process, it is better to determine which steps really add value to the system and search new ways to achieve the result. It should be cross functional. Means, if you reengineer one process, other processes should get benefit of it too. Principles of Reengineering 1. Organize around outcomes, not around tasks. If a person involves in a department, then organize his duties around what that department produces. It should not only “that person does that and this person does this” concept. MBL case managers deal with entire application form, not only checking certain fields. Have a customer service representative who oversees- taking orders, translate that order to product code, getting components, assemble the product and see delivering the product rather than having only one or two for each of these processes. Customers will now have one point of contact as well. 2. Have those who use the output of a process, perform the process. If any department thinks that it needs a database then it can go to some software firm and urge them to make one for them. They should not go to GM or DGM of them to finalize the purchase of a database. They should be autonomous as they are only to use the database. 3. Subsume information processing tasks into real work that produces the information. This principle asks to move work from one department to another. An organization that produces information should process the information as well. 4. Treat geographically dispersed resources as centralized. Decentralized resources are very useful to those who use it. But it creates delay because of the presence of bureaucracy. 5. Link parallel activities instead of integrating them. It omits the possibility of having errors in the end. 6. Put the decision point where the work is performed and build control to the process. It suggests that people who do the work should make the decisions as well and the work should have some built in controls. It actually happens now-a-days because of presence of computers and expert systems in organizations. 7. Capture information once and at source. Once upon a time information was difficult to be conveyed between departments. But now it is easier. Today we can collect information in the very beginning and store that on a database. This reduces the conveying complexities. Reading Materials Reengineering Work: Don’t Automate, Obliterate by Michael Hammer: Read it with care and thoroughly. Understand the principles. Find out any mismatch between the principles and real life organizational structures.

Rushdi Shams, Dept of CSE, KUET