ERP IMPLEMENTATION - WEAKNESSES

Issue & Consequences Recommendation

Req

uire

men

ts

Lack of stakeholder analysis- Potential scope creep due to requirements previously not identified- System unable to address operational problems

1. Under NIBCO case study, CFO parker recruited 8 other director level managers as well as representatives from various functional areas to seek their overall opinion in requirements needed for new ERP system2. In Omega case study, they considered a comprehensive list of stakeholders which includes shareholders, employees, the management as well as customers.★ Thorough stakeholder analysis that includes people with technical interest, people with manpower and materials as well as end users should be carried out.

Research on requirements for the package is unclear. Requirements were not classified into mandatory, optional and desirable.Consequence:- Potential scope creep due to requirements previously not identified- System unable to address operational problems

Similar to NIBCO which had a a TIGER team including 3 business process teams, a technical team, and change management team, company X should also have an acquisition team of people from different departments to gather the requirements of various departments and classify them as mandatory, optional and desirable. E.g. Senior Manager, Business Unit Manager, End users, Sales/Marketing team

Gathering information about potential packages is done via limited/ unreliable source of information./ Other potential packages was biasedly/ negligently evaluated.Consequence:Limited choices of packages to choose from and potentially choosing a package that does not suit business process and operating requirements from all stakeholders

1. As suggested in the OMEGA case, PM should do more extensive research on the potential packages using many different sources such as vendor literature, magazines, Internet and research services such as Gartner Group.2. Moreover, PM could learn from NIBCO case and sending representatives from various functional areas participated in walkthroughs of specific modules.

Pack

age

sele

ctio

n

Evaluation of package functionality was incomprehensive and unclear- Sean only evaluated functionality of package based on their user-

friendliness and extent of customisability- Failed to compare Pharm Corp’s requirements with

functionalities to ensure good match (due to lack of proper requirements gathering)

- Absence of demonstration by vendors and try-outs provided for Pharm Corp

Consequences:Selection of package that is not the most desired in terms of meeting user’s requirementsIncompatibility with current business processes (possibility of having to bear inconveniences and cost of having to alter business process to suit the system)

1. NIBCO evaluated seven ERP packages in depth. The strengths and weaknesses of each package functionality were considered and mapped into an evaluation matrix. Similarly, PM can evaluate more aspects of functionality different packages such as:

• Match of package with business-processes, functions and transactions supported• Scope and content of database and information generated• Reporting, enquiry, and online facilities and  capabilities• Performance (speed, accuracy, reliability)• User-friendliness, documentation, flexibility, maintainability• Nature of system supported - Integrated system? Modular approach?• Other issues – e.g., account number structure, support for international commerce,

support for e-commerce…. and extent of customisation needed2. NIBCO Representatives from the various functional areas participated in walkthroughs of specific modules. Hence, PM can invite potential vendors to provide demonstrations and trials. This creates opportunities for potential system users to explore various functions of the modules and give constructive feedback to ensure objective and meaningful evaluation.

Vendor characteristic not sufficiently evaluated: Vendor characteristic only evaluated based on reputation of the vendors of packages A and BConsequence:Selecting an inappropriate vendor which may not be able to meet the Pharm Corp’s expectation in term of requirements and service level. Pharm Corp possesses a very small IT department with minimal experience, and will rely heavily on the Vendor. Hence, selection of vendor needs to be stringent.

Fox Meyer were convinced to choose SAP software package only, instead from a selection of vendor and software packages. They realised that SAP was not enough to handle 500,000 items a day from its orders, it is only able to handle a few thousand items a day.Select Vendor based on a list of characteristics•Experience •Competence •Warranty•Reputation •Services •Commitment•Reliability •Support

Technical Considerations- Selection of packages did not consider technical factors- Especially important because currently, their old system cannot

integrate with the system used by the finance department for tracking invoices and payments

- Selection of package did not take into account the ability to take advantage of emerging technologies e.g. RFID to settle their current inventory problem

Consequence:If systems do not fit, will cause complication in integrating the whole system

FoxMeyer did not consider technological factors when choosing their ERP package. As a result, the installation of their SAP together with another warehouse-automation system from another vendor increased the complexity of their project★ Package must fit with the current IT infrastructure and cover everything--hardware, software, networks, telecoms, database, security, etc.★ While Sean considered the costs of these parts, he did not consider their fit with the current system

Lack of Marketplace Analysis- Failure to identify the major players providing IS packages in the

marketplace- Shortlisted to only two packages and did not consider other

potential vendorsConsequencePotentially missed out on vendors that offer better service and packages that suit the needs of Pharm Corp

In Omega case study, Omega held an information session and invited potential vendors to attend and the benefits of the session are:

– opportunity to gather more information on each of the vendors– better prices and solutions as each of the vendor know who they are

competing againsteg. Under the NIBCO case study, a cross-sectional team was formed and 7 ERP packages were evaluated in depth and several different vendors’ customers were also visited★ Need to focus on the vendors providing packages for this specific market segment i.e. pharmaceuticals★ Need to keep their choices more open and evaluate a larger number of vendors available in the market to not miss out any potential suitable vendors.

Lack of intensive Cost Considerations- Lack of information for proper cost evaluation such as

- cost per module- initial costs- annual costs (licence, maintenance/support)- upgrades- and most importantly the package customisation costs

- Lack of cost consideration in package selection (customisation such as source code modification

ConsequenceIf Pharm Corp did not properly evaluate the cost factors, the total costs might escalate out of Pharm Corp’s financial capability. This might land them in debts and contribute to their downfall.

• FoxMeyer did not consider cost factors when choosing their ERP package. They were overoptimistic about deals being profitable and spent millions of dollars on hardware, software and consultation without prior cost planning. As a result, the shortfalls between the expected and actual profits were too overwhelming.

★ Sean failed to take into account the costs of the package against the financial capability of Pharm Corp.★ A thorough evaluation have to be done to analyse all the different costs involved and to come out with the closest estimates. Then compare it against Pharm Corp’s financial capability to determine if the company is able to afford the package. A contingency plan is best to be proposed in the event the cost exceeds the estimates.This is especially important where one of the reasons for the selection of ERP package is the allowance for customisation and yet the customisation cost was not mentioned.

Cus

tom

isat

ion

Excessive customization and configuration to look like the old legacy systemConsequenceUnable to fully utilize the function and best practice processes accompanied by the new systemUnable to address inefficiency and control issues that are prevalent in the old legacy system since there is little change in business processes.

Under the NIBCO case study, the R/3 package was to be implemented in a “vanilla” form with essentially no customization. The intent was not to try to reconfigure R/3 to look like the old legacy systems. Rather, the company would adapt to the R/3 “best practice” processes. This is especially important because ERP implementation does not only refer to a change in software or database but also a process of reengineering and adopting of “best business practices”.

Test

ing

Del

iver

y

Phase-by-phase approach:NIBCO: The fear was that the company would just get to the pointwhere it would say “enough is enough” without executing the whole plan. Team members had also observed that some of the companies that had used a phased, "go-slow" approach were not among the most successful. At the same time business initiatives were demanding a quicker implementation.

PROJECT MANAGEMENT STRUCTURE

Strength/ weakness and example from case study Implication of strength[Strength] Top management support with involvement of CEONIBCO: CEO Martin was the executive sponsor of the implementation team

The CEO has the authority and will be able to allocate and provide resources (e.g. views,manpower) needed by the project managerAble to use strong negotiation skills to negotiate good deals and lower the cost Project will be given great support and recognition in the company

[Strength] Presence of a Business Process Reengineering TeamDCH Safety: BPR team that seek to radically re-engineer current processes by challenging existing ways of doing thingsNIBCO: Business review roles were taken on by a business leader that could make high level business process redesign decisions based on theirexpertise and experience

Having a BPR team will enhance control of the processes, so that the implemented new system will not be just an automation of old processesCan adapt to best practice processes ( NIBCO implemented ‘vanilla’) → With a BPR team, there can be better integration of the existing practices of the company with the best practices outside. Moreover, they can also ensure that these changes to be implemented remain suitable for the company

[Strength] The person who lead and facilitate the project implementation team’s discussion was experienced and objectiveNIBCO: Because of his facilitation experience, Jim Davis was asked to facilitate that meeting.

There would be an objective person who had no particular interest or bias to help lead the discussion. Moreover, with facilitation experience and domain knowledge, facilitators can have a clear agenda and direction to achieve a meaningful knowledge sharing and interaction.

[Weakness] Lack of involvement of Project, Business and Procurement managersNIBCO: In total, only 7 out of 28 directors of the company is committed to the project

Managers:1. The implemented ERP system may not include the changes needed by the Business and Procurement managers necessarily for improvement2. Project Manager not fully committed to ERP project → Project manager unable to provide timely approval to the IT consultants.3. No sense of ownership for the project: they will not actively uptake the ERP system and encourage the whole company to adapt to it, resulting in future resistance to the ERP system.

1. Procurement and Business manager should be more involved with the IT consultants → Tie part of their incentives with the success (time, scope) of the ERP implementation2. Assign a new Project Supervisor who dedicate full time commitment to the implementation, rather than having the Finance manager commit 50% of his time.

[Weakness] Lack of Change Management Team to facilitate change towards the implemented ERP systemNIBCO: Presence of change management team to facilitateadaptation to the new ERP system. → “one of the things we kept hearing over and over was that the change management was a killer”, “if we don’t get people to play the new instrument here, it could be a great coronet—but it’s never gonna blow a note”

Without the cooperation and willingness ofemployees to adopt the change, it would beuseless even with a good ERP system put in place → the company will not know how to use the system, thus affecting the future operation of the business when the ERP system is finally in place

1. Create a Change Management Team which ensures that teams members and users receive the training they need to use the adopted ERP system → understand thechange implications and how it impacts them → be part of the change2. Constantly update and communicate with all employees3. Monitor each of the employees using a change adoption curve

GO-LIVE APPROACH: BIG BANG VS PHASED APPROACH

Big Bang Phased approachDefinition Big bang is a “one-and-done” deal: the system goes live across all departments on a

predetermined date. Prior to deployment, management must determine any organizational changes necessary to make the system viable, employees must receive adequate training on the new system, data stewards must convert and import information from the old system to the new system, and the technical staff must conduct trial runs to verify the validity of the software.

In contrast, a phased rollout implements the new system in a series of steps. An organization may deploy individual modules one at a time, starting with its core processes, or it may introduce the new system to a particular business unit or site before deploying the software to its other departments or locations.

Pros Low Cost. Operating expenses are much lower than in a phase rollout, as the organization need only incur the maintenance costs of a single system.Faster Return on Investment (ROI). The changeover occurs site-wide for all users on a given date, resulting in an immediate change to processes across affected departments.

Low Risk. Because there’s no hard-and-fast deadline, the organization can make adjustments as needed during the transition.Steady Performance. The organization has more time to train employees, and employees have more time to adjust to the new system.

Cons High Risk.  This is because the integrated nature of ERP systems means that a failure in one part of the system can have knock-on effects elsewhere. The scope of a big bang implementation can also mean that full end-to-end system testing is difficult to achieve, and it’s only when the system goes live that all of the interdependencies are fully tested.Disruption to Operations. The organization may experience a “catch-up” period in which productivity temporarily decreases as users adapt to the new system.

Lack of Focus. Deployment occurs over an extended period, and staff must concentrate on a single module or department at a time rather than on the system as a whole.High Cost. The organization must devote resources to maintaining the old system and the new system as well as any temporary interfaces used to link the two systems. Phased implementations typically take longer to fully complete; this generally means more time from both the ERP vendor and the project team and therefore increased costs. Temporary interfaces between the new system and legacy systems can also increase the cost of a phased approach

Many factors need to be considered when deciding on a go-live strategy. For example:

Factor Big Bang Phased approachImplementation cover a single site or multiple sites Single site

Multiple sites with strong interdependencies between sitesMultiple sites, with little or no interdependencies between sites

Implementation cover single business or multiple businesses

Single business Multiple businesses => Make sense to phase the implementation by trading company or business unit

Integration between new system and legacy system during the interim period

Little issues since all modules are to be introduced at once Potential issues: Need to create interfaces, user documentation and Standard Operating Procedures (SOPs) that cover how business processes operate in the interim period

Other competing business activities that need to be taken into account

Factors such as regulatory compliance, acquisitions, new product introductions and other capital expenditure programs can influence the required timescale for an ERP implementation.

Risk appetite (what level of risk is acceptable?) inherently higher level of risk. Lower riskCost/ Budget available Low cost High costBoth approaches have their advantages and disadvantages. However it’s important to point out that an implementation strategy doesn’t have to be limited to these two options. Sometimes a big bang approach can be used to implement ‘must have’ functionality within the core ERP modules, followed up with a phased implementation of ‘nice to have’ functionality and the implementation of non-core modules such as document management, business intelligence and maintenance management. All of the implementation options should be explored in detail as part of an ERP strategy definition exercise.

SOFTWARE DEVELOPMENT APPROACHS: WATERFALL VS AGILE (PROTOTYPE)

Waterfall Agile (Prototype)

Def

initi

on

Waterfall is a linear approach to software development. In this methodology, the sequence of events is something like: Requirement – Design – Construction – Testing – DeliveryIn a true Waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin.

Agile is an iterative, team-based approach to development. Rather than creating tasks and schedules, all time is “time-boxed” into phases called “sprints.” As work is completed during each sprint, it is continuously reviewed and evaluated by the customer, who may be considered the most critical member of the Agile team. As a result, Agile relies on a very high level of customer involvement throughout the project.

Pros

Developers and customers agree on what will be delivered early in the development lifecycle. This makes planning and designing more straightforward.

Progress is more easily measured , as the full scope of the work is known in advance.

Throughout the development effort, it’s possible for various members of the team to be involved or to continue with other work, depending on the active phase of the project. For example, business analysts can learn about and document what needs to be done, while the developers are working on other projects. Testers can prepare test scripts from requirements documentation while coding is underway.

Except for reviews, approvals, status meetings, etc., a customer presence is not strictly required after the requirements phase.

Because design is completed early in the development lifecycle, this approach lends itself to projects where multiple software components must be designed (sometimes in parallel) for integration with external systems.

Finally, the software can be designed completely and more carefully, based upon a more complete understanding of   all   software deliverables. This provides a better software design with less likelihood of the “piecemeal effect,” a development phenomenon that can occur as pieces of code are defined and subsequently added to an application where they may or may not fit well.

By involving the client in every step of the project, there is a high degree of collaboration between the client and project team, providing more opportunities for the team to truly understand the client’s vision.

By delivering working software early and frequently using fixed-duration time boxes, stakeholder engagement is increased by the motivation of seeing a working product. Stakeholders gain trust in the team’s ability to deliver high-quality working software when they have the opportunity to see tangible results.

While the team needs to stay focused on delivering an agreed-to subset of the product’s features during each iteration, there is an opportunity to constantly refine and reprioritize the overall product backlog. New or changed backlog items can be planned for the next iteration, providing the opportunity to introduce changes within a few weeks.

By allowing the client to determine the priority of features, the team understands what's most important to the client’s business, and can deliver features in the most valuable order.

By focusing features on the needs of real customers, each feature incrementally delivers value, not just an IT component. This also provides the opportunity to beta test software after each iteration, gaining valuable feedback early in the project and providing the ability to make changes as needed.

By producing frequent builds and conducting testing and reviews during each iteration, quality is improved by finding and fixing defects quickly and identifying expectation mismatches early.

Waterfall Agile (Prototype)C

ons

One area which almost always falls short is the effectiveness of   requirements . Customers are sometimes intimidated by details, and specific details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document.  This potentially results in scope creep.

Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.

The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.

Agile works best when members of the development team are completely dedicated to the project.

Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints (beyond those initially planned) may be needed, adding to the project cost.

In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.

The iterative nature of Agile development may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.

Factor Agile Water FallProject size and complexity Small, less complex Large or more complexCustomer availability/ Willingness to be involved Available frequently throughout the project and willing to be

involvedCustomers cannot commit to extensive involvement

Level of integration with external system Simple or not needed Numerous, unknown, complexCustomer tolerance to scope or cost changes Flexibility in budget and schedule is possible and welcome Budget or schedule is fixed and difficult to modifyTime to market Rapid deployment needed, can have limited feature set Full featured application must be delivered within a

determined timelineCustomer preference or requirement Customer has stated methodology requirement: generally as requested, assuming other factors do not strongly suggest otherwiseDirection/ Vision of what the final product should be Unclear ClearSpeed of change in the industry Slow/ Steady changing standards Rapid changing standards

NIBCO’S BIG BANG – INTEGRATION MANAGEMENT

DetailScope Management

Timeline of events were pre-planned Work breakdown structure. The project was conducted in four large phases: Preparation, analysis, design, implementation. Project team was clear of their corresponding major

activities with respect to each large phasesProject Management Tools used: In-house Tools: The IS team built a number of tools to help with process scripting as well as project management. For example, Project Office was a

NIBCO-developed tool for project management as project tracking that used an Access database Off-the-shelf Tools: e.g MS AccessScope failed to account for 3 things: Technology infrastructure costs for the R/3 software Team costs Education of NIBCO AssociatesScope changed due to strategic changes Decided to exclude operations outside North America from the Big Bang implementation Wanted to consolidate their distribution centers

Quality Management

Strong adherence to Standards: IBM consultants were assigned to project teams to provide technical knowledge and experiences from R/3 implementations at other companies that

could be used to help NIBCO avoid similar pitfalls. IBM was their current hardware supplier IBM never had a successful prior Big Bang implementationEstablished ERP systems implemented (SAP) with no customisation

Risk Management

Big Bang approach: high risk as the project was very rushed for such a large scale => experts and top management roped inChange Management: high risk of resistance from employees Employed IBM as change management partners Extended Team Members would be called on to help with documenting the gaps between the old and new business processes and helping with master

data loads and testing. After the cutover, many would serve in “local expert” roles for knowledge transferIntegration problems: high risk of resistance from management. The integration had to work, because otherwise any one part of the organization could claim that they were no better off, or even less well off, than before the project The team was built with the awareness that they have to make decisions focused on the integration goals, which would result in killing some “sacred

cows” along the way Business Review roles were filled by business leaders who could make the high-level business process redesign decisions based in their own

knowledge and experience, without having to “ask for permission”Hindrance to Daily Operations: the company would be significantly harmed during the project because most other company initiatives would basically be put “on hold” => Strict adherence to deadlines + encourage participation of employees in ERP implementation processImplementation issues: some departments may face difficulties of different nature => formation of tactical teams for risky areas + each team has its share of experts

HR Management

Careful selection of 70 strong team members Personality profiling, including personal ability to lead, and adapt to, change and emotional fit The remaining Business Review roles were filled with managers who had deep enough business knowledge to identifies issues as well as strong enough

organisational credibility to settle conflicts as they arose. Technical skillsConsultants were hired in advance to meet gaps: Sufficient time to prepare beforehandStaff training of team & end users: Ensure they are properly equipped for the projectOpen office layout: Encourage bonding and promotes easy facilitation

Procurement Management

Lead time & delivery time: Not expressedly stated but assumed to be properly managedInstallation time: Consolidated in advance: 17 smaller distribution centers to 4 large ones to handle the high technology installation and complexityTransition time Legacy system were fully operational till “go-live” data Enabled operations to continue till cutover date

Communication Management

Within the team Formal team-building exercises and discussions were conducted to sensitize the entire team to potential sources of resistance and the need for early

communication efforts. Open office layout i.e no closed doors and no private offices The entire project team (including directors) was housed in a single physical location called TIGER Den. The Den had a large open space called the “war room”, “concentration room” and soft couches to facilitate brainstorming sessions, formal and informal

meetingsBetween the team & NIBCO associates Regular feedback & update sessions for all employees (TIGER talks at corporate headquarters) by Jim Davis and selected TIGER team members with

flexible timing Most “connected” individuals serving as “hubs” for bidirectional feedback to the team and to those with whom they were connected in the workplace Team members also conducted two or three rounds of on-site visits to each NIBCO plan and distribution center, thus allowing all associates to have an

opportunity for a physical face-to-face meeting with team members regularly.Time Management

Project tools: Customised in-house project management tools used: Project OfficeMotivate employees: Remuneration incentives tied to deadlinesConservative approach: Time was given for buffer purposes

Cost Management

Cost cutting measures: Big Bang approach Cutting loose consultantsMotivate employee: remuneration incentives tied to budget targetWise spending: Infrastructure improvement such as designing and building new client/server infrastructure as well as providing ABAP programming support for the

new system; invest in new technical capabilities required for the product bar-code scanning and labeling functions that were to be implemented as part of the warehouse management changes

TIGER Den: open concept office