Archive by Author

Framework for Evaluating IS Success

22 Feb

Group 2 Members:

Christine Coughlan, Clifton Moore, Dermot Lucid, Niamh O’ Farrell &
Ronan Murphy

Introduction

We have created a framework which allows an organisation to evaluate the success of an information system unit. In order to develop our framework, we researched a number of IS success models developed by key authors in the IS field, for example, DeLone & McLean, Sedera, Gable, Seddon and Nelson. In researching these models we have identified both value and flaws within these models and have developed our own framework based on what we think are the most important IS dimensions to evaluate when measuring the success of an IS unit for any organisation today.

Our framework identifies key dimensions which must be measured to evaluate the overall success if an IS unit. Any firm, large or small, can use our success framework to measure the success of their IS unit by choosing suitable metrics to measure each dimension contained in the framework. We have created a framework that we believe to be both flexible and customisable. In our framework we have identified possible metrics used to measure each dimension but it is up to an organisation to decide on the most appropriate metrics to suit their organisational context and IS strategy. It is imperative to choose appropriate and agreed measures or this framework will fail to deliver its potential value.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Framework for Evaluating the Success of an IS Unit

IS success framework

Click on the image for a better view

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Explanation of Dimensions

[1] Context

Seddon et al (1999) presented the Cameron and Whetten 1983 (Fig 1, Below) framework for contextualising and evaluating Organisational Performance, adapted in Seddon et al (1999) to IT Effectiveness. [1] We have adopted the same seven-point framework to contextualise IS Success, as endorsed by Petter, DeLone, and McLean (2008) and outlined in the earlier post ‘Relatively Successful IS’.

Though all seven points are important, we suggest, in line with Seddon et al, that
1. Stakeholder Perspective? 2. Type of Information System, and 7. Against which referent is Success to be judged? are central to contextualising Success. The Context dimension of our Success framework is designed to establish, and justify, what is to be deemed ‘Successful’ from the standpoint of the stakeholder concerned, regarding the relevant IS system, and in the particular situation/organisation. To this end the Context aspect should be regarded as a Canvas to identify and outline the perspective or varying perspectives from which the analysis is based.

Stakeholder

“A stakeholder is a person or group in whose interest the evaluation of IS success is being performed” (Seddon et al, 1999). Seddon believes that due to a range of different individuals within an organisation they are going to evaluate IT success in different ways and perspectives. The inclusion of the “stakeholder” section in the framework is aimed to provide an organisation with the tool to adapt and understand the view of a projects success from all stakeholders’ views. Each stakeholder may use their own dedicated canvas, or if deemed useful, multiple stakeholders may outline their perspectives/concerns on a shared canvas. As is the case with Osterwalder’s Business Model Canvas, participants might post their views into the various categories using ‘stickies’, perhaps colour-coded to their individual stakeholder perspectives etc, to build up a visual representation of where their various priorities lie. In either case, this approach allows for comparison of stakeholders various perspectives, priorities and concerns, and will lead various parties to a more complete understanding of the success/weaknesses of the system in question. For example, a user might acknowledge a manager’s concerns for cost and the IT department’s concerns over reliability, versus their own concerns regarding usability, and vice-versa.

The elements ‘Timeframe’, ‘Type of Data’, and ‘Purpose of Evaluation’, are important for clarity, while acknowledging whether the system is for ‘Voluntary or Mandatory Use’ is a key factor to keep in mind within the backdrop to the evaluation. In the operational canvas these four elements (shaded) might be replaced by more relevant concerns, and so, should be regarded as suggestions. Once the vision of success is established stakeholders can turn their attention to the Quality & Impact sections and prioritise and even assign weighting to the various underlying dimensions. The relevant, prioritised/weighted dimensions can be measured using a Likert Scale against Sedera et al’s 27 corresponding measures Figure 3 (Below) as mentioned in the earlier post ‘ IS Success Canvas’.

The table borrowed from Seddon et al (1999), Fig 2 (below) contains examples of various stakeholders and information systems, and this table can be employed to inform the context dimension of the framework. The table column and row headings are useful as prompts but are not exhaustive of potential perspectives. However, the strength of the canvas approach is that it is blank and can therefore accommodate all stakeholder/perspectives and various information systems. Also, though informative as regards Stakeholder and IS type, we favour Sedera’s refined four-dimensional model and its tested measures (Fig 3, below) over the measures contained in Seddon’s table (Fig 2, below)
In a nutshell, the left side of the framework is a canvas to establish and outline what is to be deemed IS success. The right side of our framework is concerned with evaluating the IS against this established vision of success.

[2] Quality and Impact

The DeLone and McLean original IS success model classified measures of success into six constructs; System-Quality, Information-Quality, Organisational-Impact, Individual-Impact, Satisfaction, and Use.
Gable et al (2008) later proposed that information quality and system quality as identified by McLean and DeLone should be elements of a greater construct – IS Quality, while individual and organisational impact should be sub elements of an IS Impact construct.
Furthermore, Gable et al proposed that the ‘Satisfaction’ and ‘Use’ concepts as identified by DeLone and McLean should only be used as a metric to measure IS Impact and IS Quality and should not be treated as dependent constructs.
Thus, in our framework we considered both models and have confined the 6 constructs identified by DeLone and McLean into 2 key constructs as put forth by Gable et al; IS Impact and IS Quality. These constructs can be seen on the top level of the diagram.

The Impact construct is concerned with the eventual outputs delivered by an IS. The reason organisations invest heavily in information systems is because they expect the IS to have positive impacts on individual users and the organisation as a whole. Individual-Impact looks at how the IS has influenced the productivity and capabilities of individual users. Possible measures which can be used include individual productivity, learning and decision effectiveness.
Organisational-Impact is concerned with how the IS contributes to overall organisational results and capabilities. Business process change, cost reductions and overall productivity can be used to measure organisational impact.

The Quality construct is used to measure the IT-Artefact or technology element of IS.
Information-Quality is concerned with the quality of the information produced by the system, for example in reports and on-screen. Some measures which have been developed and successfully measured according to gable et al (2008) include importance, relevance and accuracy.
System-Quality measures the success of IS from a technical and design perspective. Tried and tested measures of system quality include reliability, flexibility, and potential for customisation.

Underneath Quality and Impact in the diagram we have the structure of the IS unit and Net Benefits.

[3] Structure of IS Unit

The structure or make-up of an IS unit can greatly impact its success, for example the level of commitment and support from top management, the quality of communication, culture and the skills of the employees. We will explain each of these to give a greater view of how the structure of an IS unit can influence IS success.

Top Management Support

It is extremely important that top management do not forget about a project after the planning stage but instead are commitment at the time of system implementation. By being directly involved in a project, top management guides the implementation team, allocating resources for projects, and stepping in to solve critical issues likely to affect implementation.

Communication

Management of an IS unit also affects communication within an organization and ultimately the productivity of users. Communication in an enterprise is vital in managing a company more efficiently, keep close monitor on strategies, strong relationships with employees and to have strong relations with partners/clients.

Culture

Culture within an organisation is also critical in determining success as it can impact how innovation affects IT practices and overall performance. Culture can impact organisations in the following three ways
1) Culture within an organisation can provide unwritten guidelines for employees in how to create a good workplace and strengthen relationships in order to improve the social system in the organisation.
2) Culture in an organisation can also affect the ability to deal successfully with issues from both internal and external integration.
3) It can also determine the differentiating between in-group and out-group people.

Employee Skills and Training

Employee skills being one of the most important factors within an organisation are critical in achieving success. If the employee does not meet the requirements/skills needed to carry out the required tasks, it can affect productivity and efficiency. It is also important that a business has a well-established training program for new employees in order to gain the appropriate skills that may be required specific to the company.

[4] Net Benefits

As a group we felt that Net Benefits is needed within an IS framework to support management teams in determining the success of their IS unit. The Net benefit dimension was also used in the DeLone and McLean model (2003) for organising IS success measurements. [ ] Net benefits are the extent to which IS are adding to the success of individuals, organisations and groups. The support management team needs to identify what their net benefits are. Examples of organisational net benefits may include: improved decision making, productivity, increased sales, reductions in cost, profits, economic development and creation of jobs, (DeLone & McLean, 2008).

Conclusion

Our framework is a synthesis of the key dimensions evident in the IS Success model research, and we feel that the framework is applicable or adaptable to all IS evaluations. The framework is intentionally open in nature with regard to its dimensions and measures making it ideal for quickly establishing and explaining across various stakeholders the success or less successful aspects of a system, while if necessary, thorough quantitative methods may be applied to the various dimensions, depending on the nature of the evaluation.

References:

• Seddon, P. B., Staples, S., Patnayakuni, R., & Bowtell, M. (1999). Dimensions of information systems success. Communications of the AIS, 2(3es)
• Petter,S., DeLone,W. & McLean,E. (2008). Measuring information systems success: models dimensions, measures, and interrelationships.
• Gable, Guy G. and Sedera, Darshana and Chan, Taizan (2008) Re-conceptualizing information system success: the IS-Impact Measurement Model. Journal of the Association for Information Systems.
• DeLone, W. and McLean, E. (2003). The DeLone and McLean Model of Information Systems Success: A Ten-Year Update.

Figure 1: Seven Questions to Answer when Measuring Organisational Performance – Cameron and Whetten (1983)

Figure 1: Seven Questions to Answer when Measuring Organisational Performance – Cameron and Whetten (1983)

Figure 2: IS Effectiveness Measures used for different combinations of Stakeholder and System – Seddon et al, (1999)

Figure 2: IS Effectiveness Measures used for different combinations of Stakeholder and System - Seddon et al, (1999)

Figure 3: Gable et al (2008) Impact Measures

Figure 3: Gable et al (2008) Impact Measures

IS Success – It’s Not Just About The Technology!

7 Feb

While we have looked at various IS success frameworks in the past number of weeks, for example the McLean and DeLone IS success model , we have identified many of the IT dimensions that need to be considered when determining how successful an IS unit is. These include information and service quality, user involvement, perceived ease of use and system functionality. While such IT dimensions are very important for measuring the success of an IS unit, we must not forget the soft elements that can impact it also. Some examples of soft elements include culture, IT leadership and skills within the unit.

Culture – is there a culture that allows the interaction and sharing of ideas? Are mistakes viewed as experiences and lessons learned for the future or are those responsible for the mistakes punished? A successful IS unit demands an atmosphere that allows innovation and creativity. The world of IT changes so much that IS workers need to be able to experiment with new technologies. Are there core values shared and extended across the firm, including business functions and IS units? Shared core values will keep IS projects aligned with business processes and objectives.

IT Leadership – A successful IS unit needs excellent IT leadership. Does the IS unit as a whole have the right blend of IT and business skills to lead the IS unit to success? Does the CIO and senior IS executives have the appropriate communication skills to ensure employees can understand the needs of the business in terms of its technologies?

Up-to date skills – I believe training would also play a part in leading an IS unit to success. As IT is constantly changing, IS and IT employees need to continuously update their skills and partake in regular training.
When measuring the success of an IS unit it is important to consider soft elements as well as the technology dimensions.

(All ideas are my own)

IS Strategy leading IS unit to Success

5 Feb

In the article “Predictors of Effective IS Strategy Implementation”, Kannabiran et al (2009) talk about the implementation stage of an IS strategy and how it determines the success or failure of information systems in an organisation. The authors identify 5 factors that can aid the success of the IS unit. [1]

User Involvement:
Although the IS unit can develop new technologies, it is what you do with the IT that creates value for a firm. It is not surprising therefore that business functions have started taking part in core IS functions. The end user needs to be involved in the implementation of the system to ensure the system will meet its necessary functions.

Role of the IS Function:
Although it is the business units that ultimately use the IT, the onus is on the IS function to help users appreciate the full value of IT. “The IS function has to establish good relationships with the users of the system while the CIO’s credibility, commitment to targets, consultation with key stakeholders, and knowledge of IT facilitates the overall implementation.” [1]

Technological Environment:
Uncertainty can arise in an organization when new IS technologies are implemented. Organisations need to ensure the emerging technologies are designed, implemented and aligned with current processes and technologies.

IS Plan Characteristics:
Successful strategy implementation is predicted by the implementation plan that evolved as part of the IS strategy. An implementation plan contains ‘details such as the identification and prioritization of projects and the schedule for completion of specific projects within the plan period.’ [1] If an IS plan is not carefully developed strategic misalignment may occur and lead to mismatches between the IS plan and desired benefits of an information system.

Top Management Commitment:
It is extremely important that ‘top management do not forget about a project after the planning stage but instead are commitment at the time of system implementation. By being directly involved in a project, “top management guides the implementation team, allocating resources for projects, and stepping in to solve critical issues likely to affect implementation.”[1]

Reference
[1] Kannabiran, G., Sharda, R., Gupta, A., Wilson., R. (2009) Predictors of Effective IS Strategy Implementation: A longitudinal Study of Indian organizations. Asia-Pacific Business Review. Vol. V, No. 2, p. 3-27.
Available at: http://abr.sagepub.com/content/5/2/3.full.pdf+html

Process-Based and Outcome-Based Project Success Criteria

24 Jan

In an article titled “Project Retrospectives”, author Nelson provides a ‘comprehensive retrospective’ which considers a mix of process-based and outcome-based measures of project success. [1]

Project Success Criteria

Project Success Criteria

I believe this model is very applicable to Information Systems and I will briefly outline each criterion according to how I would use each one to measure the success of an information system.

According to the article, the process-based criteria include:

1. Time – Whether the information system project commenced and was completed on time and whether it was carried out according to the planned schedule.

2. Cost – This involves looking at whether the information system was completed within budget. If not, did it exceed the budget by a small or large amount? A project can often be deemed successful if it exceeds budget provided it met other measurable criteria.

3. Product – This involves looking at the actual system produced and deciding if it was of acceptable quality and met expected “requirements, usability, ease of use, modifiability, and maintainability”. An information system can be completed on time and according to budget and may satisfy basic functions but if the product does not satisfy user and other requirements it may be deemed a failure.

The three outcome-related criteria include:

4. Use – Whether the information system is actually being used by its target users and is fulfilling its intended purpose.

5. Learning – This looks at whether the information system “increased stakeholder knowledge and helped prepare the organisation for future challenges”.

6. Value – This looks at whether the information system resulted directly in improved efficiency and/or effectiveness for the intended organisation. Measuring the value can include methods such as Net Present Value, Internal Rate of Return and the balanced scorecard.

Using all 6 of the above criteria can help an organisation to measure the success of an information system. However, for the criteria to be of use, stakeholder goals or expectations need to be agreed and clearly defined before the information system is developed and/or implemented. In my previous blog I talked about how different stakeholders will have different expectations regarding a project and different views on success. Nelson also notes that “success is in the eye of the beholder” and notes how “a project may be subject to review by a host of stakeholder groups, including the project sponsor, system users, project team, maintenance and support personnel, internal and external auditors, and top management.” Thus, a project may receive an entirely different opinion on success depending on who’s measuring it so it’s imperative to agree on goals at the outset.

[1] Nelson, R. (2005) Project Retrospectives: Evaluating Project Success, Failure, and Everything in Between. MIS Quarterly Executive Vol. 4 (3) 361 – 372

Alignment of Goals and IS Success

22 Jan

In their latest blog, Zonic89 talks about Leavitt’s Diamond Shaped Organisational Model in which structure, tasks, technology and people are classified as factors that affect the success of an information system. [1] From carrying out some research on these factors I have learned that people may be the factor that influences the IS above all.

In my understanding, the ‘People’ element is made up of all the different stakeholders that an Information System affects, for example the financial executives, the IS professionals, consumers and end users. All these different stakeholders can have different views and expectations as to what success means in relation to IS.

Linberg (1999) notes that in the past, projects called failures by organisations have in fact been deemed successful by IS professionals. [2] Linberg talks about one such project that cost 4 times its initial budgeted figure and took twice as long to be completed as expected yet it was treated as the most successful project of all by the IS professionals. The IS professionals judged the project according to the “knowledge gained through the innovative nature of the project and the working relationships built among the team” whereas the financial professionals deemed it a failure owing to the simple fact it exceeded budgeted costs.

In a 2001 article, Klein and Jiang propose that IS project failure “is due to a difference in expectations prior to the start of a new system development.” [3] The authors believe that in order to improve the success rate of Information Systems, consonance needs to be achieved. In the article consonance is described as “a collective understanding and agreement of the metrics used to evaluate an information system.” The authors tell us that there needs to be agreement among stakeholders in terms of expectations or goals and associated measures and deliverables. According to the paper “a process involving all stakeholders can be built to utilize agreed upon goals, allows for control of the system development, and serves as valuable feedback for subsequent projects.

Information systems are multi-dimensional and so measures of success cannot be built around individual stakeholders but instead must meet a wide array of criteria. Different groups of stakeholders have different needs and expectations and so they judge the success or failure of a system based on different sets of criteria. Thus, the alignment of goals across the different stakeholders is crucial to ensuring the system is a success.

[1] Zonic89, Alternative frameworks for measuring IS Success. Available at:  https://sopinion8ed.wordpress.com/author/zonic89/

[2] Linberg, K.(1999) “Software developer perceptions about software project failure: a case study.” The Journal of Systems and Software (49) 177-192

[3] Klein, G., Jiang, J.(2001) “Seeking Consonance in Information Systems. Journal of Systems and Software.” Vol 56(2) 195 – 202

Is there a ‘one for all’ approach to measuring IS success?

17 Jan

An Information System (IS) can be defined as “a set of interrelated and interacted elements or components that collect, store, process, and report data and information that can be used to enhance the process of decision making”. [1]

In this modern, technological era, the competitiveness of an organisation depends greatly on how it adopts and uses information systems. An IS can achieve valuable benefits for an organisation including but not limited to “gaining competitive advantage, increasing productivity, shorter product cycle, automation of operational decisions and supporting of strategic and tactical decisions.” [2] However, the achievement of such valuable benefits depends on the success of the IS.

It is well known that IS initiatives are very expensive investments and thus failure of an Information System is considered a very expensive mistake. It is imperative that organisations are aware of the success factors and also the risks involved in IS. According to a 1994 CHAOS report, an IS project is considered as successful if “it is completed on time and according to budget, with all features and functions as specified. It can be deemed a failure if the project was completed but exceeded budged costs or time and/or lacked all of the features and functions that were originally specified.” [2]

A blog posted by Zonic89 explains the DeLone and McLean IS success framework which mentions some key factors that determine the success or of IS including information quality, system use, user satisfaction, system quality, organisational impact, and individual impact. [3]

According to an article by Vaughan (2001), commitment and resistance are other factors which can impact on IS success. In terms of resistance, “people can resist technically inadequate systems, systems of poor ergonomic design, or user-unfriendly systems.” [4] As for commitment it is vital that “the organisation is willing to make changes to behavior, procedures, structure and any other factors that are necessary for the system to work.”[4] Commitment to IS must exist throughout the organisation starting with top management. Lack of commitment from management can result in IS failure.

From my own knowledge of IS, another factor which can contribute to the success or failure of an IS is alignment within the organisation. For example, does the system work well in the organisation and complement the existing processes? Does the IS share the same objectives as the organisation?

It is clear from my initial research that measuring the success of an Information System is not an easy task and it seems extremely unlikely that a ‘one for all’ approach to measuring IS success exists.

References

  • [1] Laudon & Laudon, 2010. Management Information Systems. 11th Edition. Pearson/Education
  • [2] Al-adaileh, R. (2009) An Evaluation of Information Systems Success: A User Perspective – the Case of Jordan Telecom Group. European Journal of Scientific Research. Vol.37 No.2 p.226-239
  • [3] Zonic89, IS Success. Available at: https://sopinion8ed.wordpress.com/2013/01/11/is-success/
  • [4] Vaughan, P. (2001) System Implementation Success Factors; It’s not just the Technology. University of Colorado.

Recap of BPM and Re-engineering

14 Nov

Hi everyone,

I’ve been looking over my past blogs today and other blogs within the BPM and Re-engineering category and decided to recap on the definitions of both concepts having now carried out much more research on the topic. While doing so I came across a brief but very concise video clip (approx 7 minutes) which covers the relationship between BPM and Re-engineering, two practices which have a lot in common but ‘start in different places and differ in their execution.’ (Steve Wiseman, Principal Consultant at Holly Group)

Wiseman defines in very clear terms what each activity is and more importantly how they differ. This video may be particularly useful for people who have not studied the concepts of BPM and Re-engineering before.

To recap on the concepts, both BPM and Re-engineering are process oriented practices which aim to improve efficiency and effectiveness within an organisation. Re-engineering is about ‘big one time changes in how work gets done and decisions are made, while BPM is about making more smaller changes over time’. (Steve Wiseman). As Wiseman put it, ‘Reengineering is ‘an intensive, top down vision driven effort that requires non-stop senior management attention and support’ while in contrast BPM can be driven from the bottom or the middle levels of the organisation.

Both BPM and Re-engineering focus on how users do their work and in what way changes can be made to make it better. BPR goes one step further than BPM though, and has the potential to reorganise the organisation itself. (Steve Wiseman)

What does BPM offer its adopters?

12 Nov

In one of their blogs, roisg mentions that Palmer, 2011 views the impact of BPM as significant and quantifiable. From the research I have carried out I agree with Palmer and I will outline some of the benefits that BPM has to offer its adopters, namely decreased costs, increased revenues and agility and adaptability.

According to the website ‘BPM Basics’ which you can access here, in the short run, BPM helps companies to improve profitability by decreasing costs and increasing revenues.

Decreased Costs

The ‘BPM Basics’ website notes that Process management helps to optimize workflows and it reduces errors and minimises waste while in a 2009 paper titled “The BPM Buzz”, author Keith Inouye,  notes that Business IT costs are reduced on the development and maintenance of processes and systems.

Increased Revenue

BPM helps companies to increase their output, accelerate cycle time and increase speed to market for goods and services. (BPM Basics) Furthermore, according to Jim Sinur at Gartner Research, “Processes that help differentiate organizations in the way that they ‘treat their customers, result in more revenue gains.’ (His blog can be accessed here)

Agility & Adaptability

According to BM Basics, ’the real value BPM delivers is intangible’

The website further writes that BPM helps create competitive advantage by improving organizational agility and adaptability; “Intelligent rules ensure that processes adapt automatically to changes in the business environment while collaborative tools bridge department boundaries while improving and speeding decision making.” (BPM Basics)

BPM can help companies become more flexible in responding to emerging business trends and thus will be better able to adapt quickly to changing market conditions. (BPM Basics).  Jim Sinur at Gartner also notes that organisations are quickly developing and adapting processes to out manoeuvre their rivals.

Although there are numerous benefits to BPM as outlined in this blog, it must be borne in mind that BPM will not improve your processes overnight – it requires a major commitment from management in order to be successful; ‘companies should expect to face a multi-year timeline and investment to successfully introduce BPM in their organisation’. (www.propertycasualty360.com)

Re-engineering – what NOT to do…!

7 Nov

In their latest blog, ismisetusa identifies some useful steps for  implementing process design. In contrast, I  will  identify some of the common mistakes made by companies in attempting to re-engineer their processes.

In their book “ Re-engineering the Corporation”,  Hammer and Champy 1993 note that many of those companies which begin the process of re-engineering do not succeed at it, ‘ending their efforts precisely where they began, making no significant changes, achieving no major performance improvement.’

The authors claim that 50% to 70% of firms that undertake re-engineering do not achieve the results they intended. When it comes to re-engineering the same mistakes are made over and over again by different companies. Thus, the authors suggest the first step to succeeding at re-engineering is to recognise these common failures and try to avoid them. I will outline 3 of these common errors and mention a number of others as put forth by Hammer and Champy.

1)    Ignoring everything except Process Design 

Everything associated with the process must be re-engineered – this includes job design, organisational structure, management systems etc. At IBM Credit, people who previously knew only how to check credit are now evaluating and pricing entire financing deals. They had to not only learn new jobs but also acquire new attitudes about their jobs.

2)    Quitting too Early

Often companies abandon re-engineering attempts as the first sight of trouble or a problem. Other companies quit the re-engineering process as soon as they experience some success. In either case, these companies are foregoing the huge potential payoffs by failing to continue the re-engineering process.

3)    Burying Re-engineering in the middle of the Corporate Agenda

“If they don’t put re-engineering at the top of their agenda, they should leave it off entirely.” (Hammer & Champy 1993)

Re-engineering requires a huge amount of focus and regular, close attention. If the attention of management is spread too thinly across an array of other projects at the same time, re-engineering will not get the focus it need and will most likely end in failure.

Other common failures identified in the book include but are not limited to:

  • Neglecting peoples values and beliefs
  • Trying to make re-engineering happen from the bottom up
  • Skimping on the resources devoted to re-engineering
  • Failing to distinguish re-engineering from other  business improvement programs

Despite the many opportunities for failure in re-engineering, the authors believe that organisations which approach re-engineering with ‘understanding, commitment and a strong executive leadership’ will success at it. (Hammer & Champy, 1993)

Why engage in BPM or Re-engineering?

1 Nov

In her blog, ismisetusa  mentions some of the reasons a company may engage in Business Process Management (BPM) and Business Process Re-engineering (BPR) for example:

  • To gain a competitive edge
  • To weed out any errors or behavioural problems within a system
  • To maintain an edge in ever changing customer base, and
  • To expand into new markets and/or other industries.

In another blog aplusk22 mentions how Barclaycard Germany was able to cut the processing time from three days to just 18 minutes by engaging in BPR.

In a 2001 article by Ranganathan and Dhaliwal addressing the topic of BPR, the authors identify some other cases where Re-engineering has been undertaken and has had a positive impact on the organisation.

When Motorola was faced with higher product defect percentages and longer cycle times, it redesigned its product parts and processes, while simultaneously upgrading its manufacturing equipment. As a result of BPR, Motorola experienced a decrease in the total production cost by $1 billion per year and cut its cycle time by half.

By adopting a BPR approach, Bell Atlantic reduced the time to install new telecommunications circuits from 15 to 3 days and cut labour costs from $88 to 6 million.

Hallmark decreased its product introduction time on new cards by over 75% by replacing its sequential product development with cross-functional teams while Ford Motors reduced its accounts payable staff by 75%.

(These examples are all taken from the 2001 article by Ranganathan and Dhaliwal)

It is clear that BPM and Reengineering can have very positive results for a company wishing to change one or more of its current processes.

%d bloggers like this: