Critical success factors for ERP implementations

2009 from International Journal of Operations and Production Management – “This paper explores the Critical Success Factors (CSFs) of Enterprise Resource Planning (ERP) system implementation at Small and Medium sized Enterprises (SMEs)…

Operational process discipline. The concept of process discipline has been formalized by Collins and Schmenner (1993) and Collins et al. (1998). In our study, companies were asked about documentation and consistency in executing operational processes (i.e. information flows) prior to the implementation. Companies having greater consistency prior to implementation appeared to achieve more successful implementations regardless of the level of documentation. The two unsuccessful cases had good documentation, but low discipline in adhering to standards set in documents. For example, Company 4 cited ISO audits that revealed non-conformance in sales and engineering. Company 3’s poor record led to problems such as excess procurement to buffer for inaccurate inventory data; as the Accounting Manager indicated, “We were a custom job shop with “craftsmen‟ who would each do things a little differently. The BOMs [bills of materials] were “loose‟ and standard routings were non-existent… it was very dysfunctional.” Consequently, both companies had difficulty adhering to processes that were newly developed by the ERP.

Overall, it seems that having inconsistent operational processes conflicts with the procedural rigidity of ERPs. Where such inconsistency exists, it may be necessary to carry out some process benchmarking and improvement prior to enforcing standardized procedures brought in by the ERP. This finding looks consistent with Schniederjans and Kim‟s (2003) conclusion (from a large company survey) that best implementations involve reengineering processes before rather than after the ERP introduction. Ross and Vitale (2000) similarly stated that ERP implementations posed challenges as they “... were instilling discipline into relatively undisciplined organizations.” (p. 240).

Thus, it appears that operational process discipline should be identified as a major CSF for ERP introduction at SMEs, especially given their frequently informal type of environment..."

180 View – Thanks go to Bluelink for alerting us to this article. For a quick summary of the CSF’s by Bluelink, click here.

I have only copied the first CSF above as it discusses a number of very interesting points. There is an assumption that ERP systems impose standardization. I disagree in that ERP systems have flexibility to accommodate different business processes. However, the implementation team may decide for different reasons that standardization is a good idea.

It seems that undisciplined organizations run into problems with standardization of business processes. This can also happen for many reasons. It may because there are different business units that do things differently to maximize their profitability and don’t want corporate to impose standards.

Another point raised is “that best implementations involve reengineering processes before rather than after the ERP introduction”. I disagree. Reengineering should take place during the implementation. Why not leverage existing business processes embedded in an ERP system than try to reinvent processes or create processes that are too expensive to implement.

In any event, the red flag needs to go up early for an implementation where there is a lack of standardization. When there are strategic reasons for non-standardization, the implementation should accommodate it. When the reasons for non-standardization have more to do with personal preferences or power, the implementation team needs to have the full backing of senior management to enforce standardization.

Magic Quadrant for Midmarket and Tier 2-Oriented ERP for Product-Centric Companies

June 4, 2009 from Gartner via Epicor – “Despite the mergers and acquisitions, there are many ERP offerings for midmarket companies and firms deploying Tier 2 ERP systems. This Magic Quadrant evaluates products that have a global presence and are specifically tailored for product-centric midmarket companies with roughly 100 to 1,000 employees…”

180 View – The Gartner Magic Quadrant has been around for many years and I suspect was and still is a big factor in which systems have been selected especially by larger organizations. There is a lot of useful information in the article. You will also find Gartner acts as a judge in assessing strengths and weaknesses of the various systems including getting feedback from “reference” clients. However, we question whether the feedback from clients can be relied upon. Gartner would need a large sample of clients to draw any conclusions. I did a scan through the report looking for information on how many customers were interviewed and how the customers were obtained – I did not find anything.

The report also discusses a number of trends including packaging of industry-specific functionality, technology modernization using service-oriented architecture (SOA) and the need for global deployments. I agree with the first one about industry-specific functionality. Some vendors have done this by partnering with industry specific developers. The vendor provides tools and marketing, the industry specific developers provide the extensions to the system. I have also heard vendors touting SOA as the road to salvation. Any problem with integrating multiple systems can be handled using SOA… The cynics out there including myself are not swept away by technology hype. Global deployments can be a problem with respect to language, taxation and statutory requirements. However, I don’t agree that the vendor needs a presence in countries all over the world. The preferred approach is to Train the Trainer and let internal resources roll out the system. With the use of low cost communications and remote access over the internet, a physical presence is not always required.

Also take a look at more criticism of Gartner's report by The Enterprise System Spectator by clicking here.

Business Processes and the Weather!

June 26, 2009 from Business Finance – “Will Rogers once said, “Everyone talks about the weather, but nobody ever does anything about it.” Sometimes I feel like that about business processes. I like to complain about them but don’t do enough to change them.

Think about some of your own experiences. Have you ever wondered who came up with the process being used to “service” you? I have had some recent experiences with major retail and service companies that were mind boggling at best – complicated package deals, pricing terms, and rebate requirements. Not only was I confused, but the customer service employees were struggling, too! It always makes me wonder how organizations establish and maintain effective internal controls around all this complication…

In a recent conversation with an assurance partner at a national CPA firm, he told me he sees lots of situations where an organization’s ERP system isn’t implemented in its entirety or management doesn’t seem to trust it. Instead, they use procedures outside the system (i.e., spreadsheets) to verify what’s going on inside the system or to “do the consolidation.” He surmised that this may be caused by people at the functional level not wanting to be overly reliant on the ERP system or on IT people. Sounds like a matter of trust to me.”

180 View - This short article raises 2 big problems although it does not get into any detail or solutions. The first big problem is complexity of business process. When the complex process was introduced, it likely made sense. The question is whether it still does. A design principle in improving business process is to reduce complexity. So challenge the reason for the complex business process and try to keep it simple.

The second is reliance on spreadsheets. The article points out two reasons – lack of trust in the system and not wanting to rely on IT people. Lack of trust in the system is a huge problem and the answer is not more spreadsheets but the implementation of strong internal controls. Not wanting to rely on IT people is understandable as it may require a long wait time, but the solution should not be more spreadsheets. The solution should be using reporting tools that leverage the data in the system. The reporting tools likely exist, they just need to be implemented, which requires an investment in training and support.

How About Those Leading Indicators? Do You Have an Early Warning System?

June 22, 2009 from Business Finance – “How well have you advised your organization on developing leading indicators to provide an early warning system for your board and executive and management teams? Are you still managing off the financials or lagging indicators? By the time the books close 10, 15, 20, 25 days after month’s end, the impacts of yesterday’s decisions are already being felt. Wouldn’t you want to get ahead of the curve to know with some degree of certainty what is coming? Of course, we all do.

180 View – The article does not get into any detail but reminds us of the importance of leading indicators. When developing Key Performance Indicators, make sure you have a mix of both leading and lagging indicators.

IT's Role In The Recession

June 1, 2009 from Forbes – “Information technology experts didn't cause the current economic downturn, but they certainly made it worse. The creation of incredibly complex risk models on Wall Street by pedigreed quantitative analysts, or quants, and the almost total reliance by trading houses on those models turned what could have been just another housing bubble into a global disaster…

Some people realized those equations had serious flaws from the beginning. But when things are going well people ignore those risks and make money while they can. These computers had a role in convincing people everything was OK. And obviously the top management in firms can't understand these equations. They're very complex. There are lots of variables, lots of equations, and they assumed they were OK. In the end, it gave them a very false sense of confidence...”

180 View – I think the bigger problem with the “models on Wall Street” was not the complex equations but in the underlying assumptions. There is also the greed factor that will find a way to make the models and statistics work in a favourable way. The same lessons should be applied to any organization’s forecast or ROI calculation. You need to validate the assumptions. You also need to be wary if the person who did the forecast or ROI had something to gain by it.

Managing Scope for Project Success

June 24, 2009 from Project Times – “Ever start a project without a stable foundation for scope? How did it go? To ensure project success, it is essential that scope be unambiguous and carefully managed. This can be accomplished with the Scope Management Process, which provides a formal set of procedures for planning, executing, monitoring and controlling scope…

Basic functions in the Scope Management Process include reviewing the project charter and other documents such as the contract, statement of work and request for proposal…”

180 View – Anyone familiar with project management methodology will already know most of what’s in the article. The main reason for including it is the discussion of where scope is defined. The article suggests the contract and statement of work as a source. It is extremely unlikely that scope will be defined well enough in either of these documents. The article also suggests the request for proposal. I agree with that but it needs to be part of the contract, which it is usually not. If using the RFP as scope, the requirements in the RFP need to be defined specifically enough to avoid misunderstanding later. The requirements should also be prioritized to ensure focus on the most important requirements.

Why Debate? Let Formality and Agility Coexist

June 2009 from Project Times – “From PMI Network to blogs all over the web there is a continuing debate over Agile project management. I find it interesting, if not distressing, that the debate still rages. While there are distinct attributes of Agile methods, overall the basic tenets of formal PM are certainly there. Planning exists, there is a clear point of responsibility and accountability, there is monitoring and control (often a lot tighter and more useful than in more traditionally managed projects) as well as a closing. The predominant differences are in the way these are accomplished and the "weight" of the PM activities. The Agile Manifesto values some things over others, for example "individuals and interactions over processes and tools". This does not mean it seeks to eliminate processes and tools. Valuing the ability of "responding to change over following a plan" does not mean never following a plan…”

180 View – The article is biased to agile project management that includes formal project management as well as being able to not follow it if there are compelling reasons. When I was a bit younger, I was responsible for a multi-million dollar software development project. I was the project manager but I was also responsible for detail design along with a number of other things. I was told by some people that I should be allocating 100% of my time to project management but I never did. It was more like 30%. I was able to reduce the amount if time I spent on project management because of tools that I developed and acquired, and because I was intimately familiar with all aspects of the software. It would be very difficult for anyone on the project team to mislead me. I knew exactly where we stood in terms of quality, scope, timing and budget. So I think project management should adjust to the situation and especially the people involved.

Telepresence shatters communication barriers

June 10, 2009 from InfoWorld – “Well before the current world financial crisis struck, organizations have sought inventive ways to engage in face-to-face meetings without the need to travel. Companies have turned to services such as Adobe Acrobat Connect Pro, Cisco WebEx, Citrix GoToMeeting, and Microsoft Live Meeting as a means for workers in multiple locations to share presentations and otherwise collaborate.

No question, these tools greatly reduce costly, productivity-sapping travel, with the added benefit of lowering a company's carbon footprint. Yet scratchy audio quality, out-of-sync slides, and tiny, Webcam-quality video often diminish these solutions' usefulness. Similarly, more traditional videoconferencing systems (which have been around for decades) suffer from low utilization rates -- partially because of complicated, unreliable technology.

The door has now opened for telepresence solutions: a conferencing environment that seeks to mimic the in-person experience as much as possible. Several technologies make telepresence possible. High-definition video cameras and large, flat-panel monitors clearly display participants in life size. Optimized networks -- making use of QoS and even application-aware protocol acceleration -- help eliminate audio and video delay over long-distance and high-latency WANs. As such, participants can make eye contact with colleagues and immediately pick up on all-important visual cues -- such as how someone reacts to an offer. Moreover, operating the systems can be as simple as using a television remote control or telephone…”

180 View – Telepresence is going to get better and cheaper until it’s the best way to travel – at least for business purposes.

Lessons From Supply Chain Disasters

June 25, 2009 from Supply Chain Digest – “…it is striking that all of our most recent disasters on the list had little or nothing to do with technology problems. They were all problems resulting from failures of strategy or execution. Technology meltdowns are simply much less likely today…”

180 View (written by Lawrence Young) – In this follow up to an article published on May 7, 2009 in Supply Chain Digest entitled The Top Supply Chain Disasters of All Time, Dan Gilmore writes about the following eight key lessons that can be learned:

1. “Big Bang” go lives are risky business
2. Being a pioneer often leads to arrows in the back
3. Do not ignore early warning signs
4. Avoid hard cut-offs/transitions
5. Get some outside perspective
6. Beware of the ROI trap
7. Be brutally honest about your skill sets
8. Limit the number of moving parts

While the companies mentioned in the May 7, 2009 article are all large enterprises, the eight mistakes listed above are often relevant to companies of all sizes that are embarking on the implementation of new supply chain software.

Dan’s message is that many of the top supply chain disasters could have been avoided, or at least minimized through damage control, by applying the above eight lessons in a timely fashion.
Our decades of experience has taught us that implementing business software is indeed tricky business-lots of unknowns and certainly some issues that are substantially out of one’s control. However, the same experience has proven time and time again that most implementation problems are substantially if not totally avoidable if one simply develops and monitors a well-conceived implementation plan that takes into consideration, among other things, the above eight lessons.

Costly and painful problems can often be avoided by simply asking the chosen vendor the right questions at the right time. For example, extreme caution is well advised for any company who is considering being the ‘guinea pig’. And as the article states:

Step one is first understanding whether or not you are that guinea pig, which sometimes, in software at least, isn’t always so easy. A long time software executive once told me: “Every new version of software has a “beta” customer [the first company to implement the software]. The question is whether they know it or not.”

Test