Your SlideShare is downloading. ×
Total Cost of Ownership of Enterprise Resource Planning ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Total Cost of Ownership of Enterprise Resource Planning ...

245
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
245
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • http://en.wikipedia.org/wiki/Enterprise_resource_planning (10/2/2008)
  • Several different computer systems that need information from one another. Information is not real-time. A new student is added to the system and then goes to the parking management office to get a parking sticker but the nightly interface has not brought them over yet so they are unable to get parking sticker. Go to parking management to pay parking ticket then to Registrar’s Office but nightly job hasn’t run so you can register for courses.
  • Each department no longer has its own database. When you update a student’s address every office has the same data at the same time. NO INTERFACING. – Real time data No data redundancy however, if the parking management office makes a change to the student’s record every office is affected. This can be good and bad. Security becomes a HUGE issue.
  • Phased implementation
  • It’s important to understand why you are choosing to implement an ERP system. Is the customer benefited? Is there buy-in by the individuals at the top and not just the IT department. To get the benefits or an ERP system you MUST change the way you do business and the ways people do their jobs. This kind of change is painful. If the ways you do business work extremely well and don’t need to change (high productivity – low errors – high customer satisfaction) then you DO NOT need and ERP system. If you simply install the software without this change you may not see any value at all. It is likely that the users of the system will be resistant to the change. In fact, the new system will likely make their jobs more difficult and/or drastically different. Before purchasing an ERP system understand why you need it and how you will use it to improve your business. Companies need to figure out how their business will fit into an ERP system before purchasing. The most common reason ERP implementations fail is because the company discovers the software does not meet their needs. They can then change their business to fit the software or change the software to fit the business. Most people frown at the idea of changing the way they do business for a computer system and rightfully so. However, the customization of ERP software is a very slippery slope. Not only do customizations slow down the initial implementation but they cause greater maintenance costs since the customization must be reapplied each time the software is upgraded. Understand that they system will continue to evolve after “go-live”. It is unrealistic to thing that it will meet every need of every user in every department on day one. If this were required, the implementation would never go live. Frequently, the legacy systems you are replacing evolved over years. This system will as well.
  • The ERP Implementation model was developed based on personal experience with ERP implementations, SD project models and the DeLone and McLean IS Success models.
  • Barely 10% of an iceberg is above water, with the rest hidden from view. Organizations fail to recognize the true Total Cost of Ownership (TCO) of ERP systems and often make policy decisions early in the implementation plan that likely have long-term impacts on the TCO; such as customizing the product to meet existing business processes . Although experts strongly encourage Business Process Reengineering (BPR) in order to take full advantage of the product and reduce long-term maintenance costs, this is often difficult to accomplish in practice because it requires significant enterprise-wide change management (Hammer 1990).
  • Source ECAR Research bulleting We’re somewhere in Stage 3 – implementing new suggestions from the users as well as doing the upgrade. The upgrade goes beyond merely staying on a supported level of the software. The new features in the s/w allow us to extend the capabilities. BEST – created a dedicated team representing the main functional offices (Registrar, SAO, FAO, Admissions, HR) – necessary to extend the capabilities.
  • It’s like an iceberg – You can see only a small portion of it but there’s so much more hidden from view.
  • Possible interviewees: Chris Haile, Wayne Locust, Sheila Mahan
  • The result of the influences on the productivity of resources in development of new work processes is a declining s-shaped pattern of growth in traditional work processes, a rising and falling pattern in new work processes in place, and an s-shaped growth pattern in mature new work processes. The number of work processes was arbitrarily selected initially to be 1000 traditional, 1 new work process in place, and 0 mature new work processes in place.
  • The result of the influences on the productivity of resources in development of new work processes is a declining s-shaped pattern of growth in traditional work processes, a rising and falling pattern in new work processes in place, and an s-shaped growth pattern in mature new work processes. The number of work processes was arbitrarily selected initially to be 1000 traditional, 1 new work process in place, and 0 mature new work processes in place.
  • (Abdel-Hamid and Madnick 1990 p177)
  • Transcript

    • 1. Total Cost of Ownership of Enterprise Resource Planning Software: Simulating a Dynamic Feedback Perspective in the Higher Education Environment Meg Fryling, Ph.D. Candidate Informatics Department University at Albany
    • 2. Agenda
      • Enterprise Resource Planning (ERP)
      • Case Study Environment
      • Problem Statement
      • Research Questions
      • Research Process
      • Questions
    • 3. Enterprise Resource Planning (ERP)
      • Based on a common database and a modular software design.
        • Student Records, Student Accounts, Financial Aid, Human Resources, Financials
        • Common database allows every department of a business to store and retrieve information in real-time.
      • Information more reliable, accessible, and easily shared.
      • Data for the various business functions are integrated.
        • Financial aid awarded => rebate check issued
        • Bill paid => hold removed
        • Deposit paid => eligible to register, advisor assigned, userid created, email account created
    • 4. Pre-ERP Disparate Computer Systems (Data Silos) Student Records Student FinAid Student Accts Parking Mgmt Human Resources Financials
    • 5. ERP Integration Student Records Student FinAid Student Accts Parking Mgmt
      • Shared database
      • No Interfaces
      • All data is “real time”
      • No data redundancy
      • Standardized technology
        • Database
        • Software
        • Hardware
    • 6. ERP at UAlbany Full Student Financials version 8.0 Upgrade to 9.0 May 2005 August 2008 Financial Aid, version 8.0 January 2004 Orientation and SPC, version 7.6 March 2001 SR & SF for UHS, ver. 7.6 February 2002 Upgrade to 8.0 September 2002 Student Records, version 8.0 June 2003 Admissions, version 7.6 November 2000 HR, version 7.6 June 2000 Purchase ERP (RFI, RFP, etc.) Prospects, version 7.6 1995-1997 March 1999
    • 7. ERP Lifecycle
      • Planning
        • Most important part
        • Fit-gap
        • Functional and technical parties must be involved and work hand-in-hand
      • Execution
        • KISS – Avoid customizations
        • Who makes decisions (Customize vs. BPR)?
      • Post-Implementation
        • The system will NOT be 100% when you “go-live”
        • Maintenance, upgrades and extension of capabilities
      • UPGRADE
        • ERP implementations average between 1 and 3 years
          • - Source – Enterprise Resource Planning Research Center, www.cio.com
    • 8. SD and ERP
      • ERP projects are dynamic problems arising from complex social, managerial and economic systems.
      • ERP projects are dynamic system characterized by interdependence, mutual interaction, information feedback, and circular causality
      • Need for improved policy analysis and design
    • 9. Feedback Loops Patches/Upgrades (Y) Rework/Recustomization (Z) Time to Implement ERP (X)
    • 10. 1. The Problem
      • The time and resources required to implement and maintain ERP systems far exceed original expectations
      • The purchase price for ERP software is the most visible expense, but implementation and maintenance contains many hidden costs
      • Organizations fail to recognize the true Total Cost of Ownership (TCO) of ERP systems and often make policy decisions early in the implementation plan that likely have long-term impacts on the TCO
    • 11. 1. The Problem
      • Tend to make decisions with little solid information. This happens simply because we are running out of time!
      • Sometimes our decisions come back to haunt us in the long-term.
      • Have not fully extended the ERP capabilities (Stage 3) let alone create new capabilities (Stage 4).
      • The inability to move forward in the ERP lifecycle prevents realization of the full potential benefit of ERP (West and Daigle 2004).
      • Unable to get the decision makers to see the big (long-term) picture.
    • 12. Lifecycle of ERP Benefits Source: ECAR Research Bulletin “Total Cost of Ownership: A Strategic Tool for ERP Planning and Implementation” We are here
    • 13. Functional vision What they don’t see What can we do to make them see the entire picture?
    • 14. 2. Hypothesis
      • Adding time and resources can complicate the issue
      • The major problem is scope related
      • The scope creep problem is significantly larger than anyone realizes with long-term recurring implications (feedback loops)
      • The dynamics over time are not known to the key decision makers – If this could be communicated more effectively earlier in the process different decisions would be made
    • 15. Relationship between Time, Resources and Scope Scope Time Resources Diagram taken from IBM literature
    • 16. Scope Time Resources Relationship between Time, Resources and Scope
    • 17. Research Questions
      • Why after all these years are organizations still doing a poor job at estimating the time, cost and workforce resources required when implementing and maintaining ERP systems?
        • What cost drivers are we missing when estimating ERP cost?
        • What are the dynamic relationships between these cost drivers?
        • How can we better predict long-term total cost of ownership to implement and maintain ERP systems?
        • How do policy decisions upstream influence cost outcomes downstream? (e.g. deployment strategies, fit gap analysis, corporate governance changes, level of customization versus business process reengineering)
    • 18. Study Purpose
      • To develop a framework using system dynamics that will…
        • Enable organizations to better predict the long-term cost of ERP implementations
        • Identify key cost drivers
        • Reveal the impact of and justification for significant organizational changes in such a way as it can be easily communicated to key stakeholders
        • Improve IT and Functional communications
        • Improve decision making
    • 19. Research Process
      • Phase 1 – Literature Review
      • Conduct literature review of the following domains:
        • Information Systems/Technology
        • TCO methods and components
        • ERP implementation case studies
        • Business Process modeling
        • Organizational Behavior and Management
        • Project Management
        • System Dynamics (as it relates to the domains above)
    • 20. Research Process
      • Phase 2 – Model Prototype
      • Develop model prototype based on existing system dynamics project models. Model will specifically address pre-packaged software implementations; tying model constructs to literature.
        • Includes extending model/research that was developed as part of Ph.D. coursework and presented at the 2007 System Dynamics Conference in Boston, MA.
    • 21. Research Process
      • Phase 3 – Case Study Data Collection
      • Qualitative
        • Observe decision making behavior in Steering Committee Meetings
        • Interview key decision makers (e.g. CIO, VP of Enrollment Management)
      • Quantitative
        • Survey project participants (technical, functional, steering committee)
        • Collect UAlbany ERP upgrade task tracking data from existing data source
    • 22. Interview, Survey and Observation
      • What factors drive/influence decisions?
      • Who do different parties see as the primary stakeholders?
      • Functional vs. technical perceptions
        • Resources required (long-term) vs. ROI
    • 23. Task Tracking Data
      • Number of total tasks
        • Open, In-progress, resolved, closed
      • Number of customizations
        • Number of times customization reapplied
      • Expected effort
      • Actual effort
      • Rework (tickets reopened)
    • 24. Research Process
      • Phase 4
      • Calibrate model with UAlbany case study data
      • Validate model structure and behavior by interviewing UAlbany key players in original ERP implementation and/or upgrade
    • 25. Research Process
      • Phase 5
      • Re-interview key decision makers with model demonstrations
        • Anything surprising?
        • Would they make a different decision?
    • 26. Dynamic Behavior to Consider
      • Customizations must be reapplied if that part of the software product is redelivered
      • TCO of a customization will increase indefinitely. Only way to stop growth is to eliminate customization.
      • Once a customization exists there is a customer expectation that it will remain
      • Once you customize one component it is difficult to justify not customizing another (political slippery slope)
    • 27. Dynamic Behavior to Consider
      • Customizations can break other delivered components of the software (domino customization effect)
        • Vendors don’t support customizations
      • When preparing for an upgrade, tasks completed in the old environment must be completed twice
      • Resources tied up on upgrade work are unavailable for new projects (task backlog)
    • 28. 3. Computer Simulation Model
    • 29.  
    • 30.  
    • 31.  
    • 32.  
    • 33.  
    • 34. 5. Test Policies Increase Work Hours Policy (40 to 65 per week)
    • 35. 5. Test Policies No Customizations Policy
    • 36. Importance
      • Do more with less
      • Allocate resources more wisely
      • Biggest bang for the buck - Low hanging fruit
      • Make better decisions - aligned with organizational goals
    • 37. Issues with Existing Cost Estimation Models
      • Accuracy and Portability
      • Need to take into consideration managerial and organizational characteristics of the environment - not just technical aspects (Abdel-Hamid and Madnick 1990)
    • 38. Research Goals
      • Improve communication between IT and functional decision makes
      • Develop model that will provide policy insights
      • Help institutions make better IT implementation decisions!
        • …leading to more effective resource allocation/utilization
    • 39. Thank you! Questions?
    • 40. Sources
      • Abdel-Hamid, T. and S. E. Madnick (1990). Software Project Dynamics: An Integrated Approach . Upper Saddle River, Prentice Hall.
      • Dodds, T. and R. Spencer (2007). "Next-Generation Administrative Systems: Philosophy, Principles, and Technology." ECAR 2007 (19).
      • West, R. and Daigle, S. L (2004). “ Total Cost of Ownership: A Strategic Tool for ERP Planning and Implementation ” . ECAR 2004 (1).
      • Hammer, Michael (1990). Reengineering Work: Don’t Automate, Obliterate. Harvard Business Review . July-August .
      • Martin, M. H. (1998). An ERP Strategy. Fortune . February: 95-97.
      • Peterson, S. (2003). Lost Signals: How Poor Communication and Other Nontechnical Issues Hampered Arkansas’ Innovative Statewide ERP Implementation. Government Technology . February .
      • Richardson, George P. (2001). “ System Dynamics”. Encyclopedia of Operations Research and Management Science . 807-810.
      • Tapp, R. M., J. Hesseldenz, et al. (2003). The Role of Project Acceptance in the Successful PeopleSoft Human Resources Management System Implementation for the Kentucky Community an Technical College System . Ninth Americas Conference on Information Systems.