Bi-directional adaption is desirable. However, there is a cost to adapt the ERP software.

Who pays for this ? This is often the reason for cost overruns so common in ERP implementations.

users must be cognisant of the inertia to change and resist it. If their practices gives them unique competitive advantage, then it is worth the change the ERP system. However, the current practises may often be the legacy of past practices that must be abandoned for the industry best practices.

Most enlightening.

I have been in this business since the mid 70’s and worked with hundreds of accounts across the globe and in most industries.

Many of the so called best practices are only best practives for a few if any. The people designing and creating these systems many times have very little real workd experience ( 1-2 companies over a few years). they take a system they wrote for someone else , slap some offshore green horns on it and call it best practices.

These systems are recommended because of the huge fees they drive for the partners of the CONsulting companies.

We worked with one 17 billion dollar client that had a best practices system from a large global CONsulting company. Their physical inventory took 8 people 4 days in 1 warehouse with 40 million in materials. We wrote a system that could do the physical with 2 people in 4 hours and then we pumped the data back into the system. This allowed them to do a physical weekly and cut shrink 90% from existing levels. I guarantee you the best practives CONsulting company has no clue on how to move companies in this direction. the savings were tremendous to the bottom line with our approach.

Remember in this industry the vendors set the standards and so called best practices. It’s really funny to see a product with thousands of patches ( HUH code that bad?). So the best practice guys write bad/broken code and in many instances do not use that same software to run their own companies.

We need to move towards a payment for a result business model and not a pay for billable bodies. Billable bodies just gives vendors no incentive to ever finish or do great work. They also tend to bring in lower level people at higher rates to increase the margins. So you want a pool in your back yard and they dig with teaspoons.

Want results hire the top tier, grand master developers and business people to get something done. Get those savings in months and not years. Also look for a bridge solution (like what we did above) that can be a subset solution that can go between existing systems for a quick result at a fraction of the cost.

[…] Why do ERP projects fail so consistently? Many explanations have been put forward through the years, but here’s one that may finally unravel the mystery [Read more] […]

I used to be a BPR consultant. Now I am still in this field but with other engagements.

In my experiences, the most common failure rises from the mis-communication between the ERP vendor’s sale team and the business owner. Sales team normally over promised while companies have various level of “systems readiness”. It is difficult to evaluate how much the implementation actually costs. In order to win the bid, the sales normally competing by prices and the business owners think to get a great deal. No, no way. Cheaper price sometimes comes from the reduce of certain works (such as short period of process adjustment, systems customization, ….).

The pain will come after the adoption when the systems are not modified properly to fit the need of the business customers.

Sometimes the business owner/top management may not even sense tragedy for a while.

One of the most common reasons for failure is the IT Manager responsible for the implementation. Some of these IT guys have got no knowledge of the business and operational requirements. Their arrogant attitude towards implementation by circumventing the opinions or suggestions of the real users, even if valid, results in less than desirable usage of the system and hence less derived benefits.
One more reason is lack of clarity on what is expected from an ERP. This lack of imagination results in ERP systems being implemented and used like any other ordinary accounting package!!!

Dear Fotd,I am a man motivator with my experience that Fault lies with ERP abilities to perform as per my requirements. As Food must be to the taste of customer, same way it is important that ERP must be rich in features to with stand demands of
1 simple not complex to adopt
2 data reliability and accuracy
3 functional connectivity
4 modulation prospects
5 low servicing and maintainability
and then if it is more a problem then help,iwould not be for it-do n’t call it my commitment-ERP features fail to inspire me-please work on them-i am ready to go all out for it. Regards

The problems remain the same with Business Solutions implementations. Over the past 20 years, I have worked with a multitude of ERP implementations from small organizations to $18B multinationals.

My background consists primarily of Industry experience from the ground upwards. This allows me to relate with customers at a business rather than technical level, although I am fully technically certified also.

The ability for ERP implementers to implement business solutions and not technical solutions is paramount and closely correlated with the success and adaptation of their new systems. Having the knowledge and working experience in several roles within various business’ is essential in understanding customer discussions and concerns. Only then can an implementer design processes and configure the ERP to align old processes, recognize new procedural requirements and provide the basic level of change management to win the trust of the clients at every level of the organization that is affected by their new ERP.

Too often, I have had to be called upon to perform “Fly doctor” cleanups of ERP systems that have all the earmarks of “technical” implementations. The original implementers did not fully understand the client’s business, their processes, the foreground knowledge of personnel roles, business best practices, professional best practices (GAAP, IFRS, MAPICs etc.) and the ability to relate to change management pyschology in the workplace.

To maximize the probability of success, the implementer must have practical business experience gained through years of working from the bottom up. Otherwise the client will only receive a technical implementation and a maximum success rate well below the customer’s expectations. Managing customer expectations is also a critical exercise throughout the implementation cycle.

Compatability is reached when the implementer has walked in the shoes of the client and has the technical prowess to configure their ERP to reach the client business goals through the properly introduced processes performed by the employees of the client.

Best regards.

Gabrielle Ford’s work seems on track to prove one of the six principles for good governance of IT expressed in ISO/IEC 38500:2008 - the International Standard for Governance of Information Technology. The Human Behaviour principle exhorts organisaiton leaders to recognise and respect the human behaviour implications of any investment in IT as an enabler of change.

Infonomics experience of assessing organisations for alignment to ISO 38500 is that most organisaiotsn pay relatively little attention to this critical aspect of implementing change. Too many seem to still view IT as the silver arrow that obviates the need for them to pay equal attention to the other dimensions of change.

ISO 38500 defines five additional principles - Responsibility, Strategy, Acquisition, Performance and Conformance. The six provide a comprehensive framework in which organisaiotns can ensure that their current and future use of IT is efficient, effective and acceptable.

If Ms Ford would care to make contact, I will be happy to share more informaiton about ISO 38500 and assessments that have been undertaken.

Is not best practices, primarily the process improvements to ease the work of the employees? I define best practices as a process to implement functionality requested by the employee, to make the employee’s job easier.

The side effect of this improvement is that once the employee can do his job well, he will look to adapt company operations to match supply chain interface (vendor/client) requirements to provide product and paperwork handling to generate cost savings to all­.

Best practices are also a mindset in an organization. Rarely can it be imposed by top-down force. I believe it works best by bottom-up peculation. It should also provide rewards to employees who contribute to process improvement.

The best article about ERP implmentation.

erp is too much complicated and makes things more difficult than easy. debugging is cumbersome and not readily available

I’ve been implementing ERP systems of over 25 years and the problem is that you are putting in a “Whole Enterprise” system. You are bringing together key functional areas of a business, that often have been operating (sometimes adversarially) with a “silo mentality” (we don’t care what these other folks are doing because we can’t control them…let’s just control our own patch) and you are asking all of these key functional areas, that often have a long history of mistrust, to arrive at a consensus and “play nice” together and share inputs/outputs to each others processes.

ERP implementations are emphatically not IT projects. They are 90% about People, Process, Culture, Politics and Leadership. They are 10% about IT. Treat an ERP implementation as an IT project and I guarantee that you’ll be screwed straight out of the blocks.

Richard sums it up nicely.
I’d like to add that the cost benefits dont come from headcount reduction which seem to be such a common thought process by management who should know better, the cost benefits come about from the ability to effectively Plan.

In a well conceived solution this can often be a problem, resentment and lack of adoption can come from the visibility that occurs in an ERP exposing dinosaur practices (Reactive rather than Proper Planning).

Any ERP implementation requires total executive management support whether you agree or disagree,(Need i say true leadership should be apparent)
These implementations can sink companies,
Fault to some degree can be laid at the doomsayers feet (Normaly wanting to save his/her empire, always the first to say i am behind you 1000%(I geuse they didnt stipulate that they are there pushing you under the bus), this is where the real trickle down effect starts.

The development and consulting team should be effectively managed by the business with experienced INDUSTRY implementors.
Fixed pricing is not good for either party,

PGL Development is a must, Going Live to a turn key state is like moving into a new house, i still need to furnish the house, except in this case i cant use the old furniture.

I am in table thumping agreement with Carl. And Carl, you are spot-on with the statement “resentment and lack of adoption can come from the visibility that occurs in an ERP exposing dinosaur practices”. With properly implemented ERP there is nowhere to hide! Everything is exposed. Transparency is a significant point of the whole exercise!

ERP implementations fail because of lack of understanding, lack of proper engagement, and lack of leadership from the highest levels of management. End of story.

enjoy

I thought about this more over night so I apologise for this long missive…

Doing ERP is an “Enterprise transforming” implementation and businesses doing ERP have to recognise this. If they don’t really want to change anything then shouldn’t start ERP in the first place.

Let’s take the Finance Functional Area as one example. Fully integrated Financials where the Financial Reports are a dollars-and-cents reflection of what is happening in the transactional layers of the ERP is a cornerstone of ERP. ERP without integrated Financials cannot be considered to be an ERP system.

In non-ERP environments, Finance will build a fortress around the G/L and will filter, interpret and adjust (via journals) everthing that hits it. If somebody in purchasing with 10 thumbs types in the wrong price on a PO and generates $1m worth of Purchase Price Variance, finance can journal the problem away. In an ERP environment however, the correct way to fix this is to reverse the offending transaction and re-apply it correctly. The accountability for the problem is sheeted home to the person that made the mistake in the first place (so they can learn something from the experience) and the referential integrity and transparency of the ERP system is maintained. If Purchasing are alerted to their mistake (via out-of-tolerance exception reporting) they should have fixed the problem before Finance even spots it.

This requires departments to work together on identifying issues and identifying how to solve them. It also means that functions like Finance have to demolish the walls of the fortress and change their focus from “filtering, interpreting and adjusting” to working with the other functional areas of the business to ensure that the feeds to the G/L that they are generating through integrated ERP are producing the correct accounting (GAAP) entries. Finance has to sign off on every process in the system that results in a G/L journal being generated (which will probably be 90+% of the transactions in the system). This can be a total change of focus and operation in the Finance department. It could require a complete change of roles and responsibilities and staffing levels. It could indicate that more people are required in the Purchasing Department and less are required in Finance. You can see how this sort of thing can get bogged down in cultural and political issues very rapidly! Actually, in my experience, Finance is often the biggest potential area for headcount reduction as a result of ERP!

Senior leadership have to be solidly engaged to understand scenarios like these and to appreciate that the implementation of ERP will turn over every rock in the organisation and expose every snake lying underneath. Senior leadership have to have the understanding, the resolve, and the guts to address the issues that get unearthed and be prepared to change things…and these things could include headcounts, accountabilities, roles and resposibilities, and even the ongoing suitability of particular individuals in the organisation. I have also seen ERP deployments suddenly highlight the non-viability of whole product lines and channels. Unfortunately, this “transparency” can also expose past decisions made by the leadership team! I saw one ERP implementation reveal (through the ability to do thorough activity based analysis without “smoke and mirrors” for the first time), that a CEO’s high profile “pet project” was completely wrong-footed. No prizes for guessing the levels of leadership support that ERP project subsequently got!

You can’t make an omlette without breaking eggs and ERP is an “Enterprise transforming” implementation. If senior leadership abrogate their responsibility to make the tough but necessary calls, I guarantee you that they will be sitting around in a year or two wondering why they blew $millions on an ERP implementation that achieved very little. And they’ll probably also be sitting around at the club with other CEO’s, cognac in hand, telling them what a crock ERP is and how they got burned by those b*****ds at SAP, Oracle, Microsoft, Lawson, QAD et al…

I think I may have been in this game for too long!

[…] risk assessments is high within enterprises. Nearly 70 percent of companies in an educational survey by the U.K.’s Open University report that enterprise resource planning (ERP) systems have fallen […]

At first I was concerned that Richard Houlton was making a case against my research theories, but on second reading I think he is in support of the research, His comments appear to relate his experience and put forward an example in support of the following statement in the blog:

“In fact, it’s your commitment to your OCoPs—a commitment generally considered a desirable quality in an employee—that sways real-world work practices, and quite possibly presents barriers to the effective transfer of knowledge required for the ERP system to succeed.”

Richard seems to be saying that OCoPs (like Finance and Accounting) have never learned how to interoperate with other OCoPs although this is a prerequisite for ERP success. Richard, in your experience is this something that is generally overlooked with ERP implementations?

Gabrielle I think I am actually agreeing with you. As I said in an earlier post, ERP is 90% about People, Process, Culture, Politics and Leadership and 10% about IT. Every ERP deployment that I’ve seen that failed to recognise this has wound up being a sub-optimal one.

I guess if I was to try to summarize my ERP experience then I would say the following…

ERP is 90% about People, Process, Culture, Politics and Leadership - ERP is an enterprise tranformational project. Recognise that!!! All manner of new concensus may need to be reached. Functional Areas of the business that have never played well with other Functional Areas in the past will need to learn to do so for ERP to be a success. The greater good of the business needs to be considered…not the viability of individuals empires as some may need to be dismantled or realigned. Not everybody is going to be happy. Some people may behave badly. This is sometimes going to need the highest levels of the business (and I mean up to CEO level) to rule with knowledge and wisdom. They can’t do their usual trick and “delegate” away stuff they can’t get their heads around. With an Enterprise Transformation project like ERP, the buck stops with them.

ERP is 10% about IT - Do not under any circumstances allow the implementation to become an IT technical project. I’ve been implementing ERP for nearly 25 years into a variety of businesses (FMCG, Food & Beverage, Automotive, Aerospace, Construction and Mining) and I have never seen any business requirement that really required invasive modification of a good ERP system. Some reporting/data extract functionality, some peripheral”bolt-on” bespoke modules, but never invasive modification. Avoid the temptation to try and “software engineer” your way around every roadblock. Also, don’t think you have to use every piece of functionality in the ERP suite. You don’t. Sometimes there is as much of an art in understanding what bits not to use and why and when, as knowing which bits to apply. You have to have a pragmatic ERP functional expert on your team…but not one with a vested interest in selling you as many modules as possible (You can see the implied warning here!).

So back to your original statement Gabrielle “Almost 75% of companies report that their ERP systems have fallen short of their expectations”. Well? What were their expectations? Were they ever reasonable? In my experience, businesses are on the constant quest for a “magic silver bullet”. They expect that ERP will be that. They often think (and maybe you can blame the ERP vendors for not wanting to correct this in the pre-sales process) that ERP is a box that you wheel into the corner of the room and plug in and it delivers $$$’s worth of benefits to your business. We all know it’s not quite that simple.

And yes, I think OCoPs themselves have failed to some extent. Where is the even most basic core mandatory “ERP101″ in every business oriented tertiary course?

Hear Hear for Richard Houlton. He is right on the button. In my work, explaining governance of IT (preferably to business leaders), I try to bring life to the now frequently used but often ignored adage: “There is no such thing as an IT project - just business projects that use IT”. I also say: “No amount of IT can change a business that doesn’t want to change, but a business that wants to change can derive extraordinary benefit from IT”.

Richard’s comments reinforce my earlier post - the ISO 38500 principle on human behaviour is so often honoured in the breach that improving performance in that one area would make a huge difference. Perhaps unsurprisingly, the network of six principles in ISO 38500 is interconnected and attending to the human behaviour principle will soon lead to improvement effort in the other five as well.

So along with ERP101, I’d also like to see governance of IT 101.

Gabrielle, the offer of further information and explanation remains open.

Gabrielle, as with Mark, I’m happy to respond to any further questions/queries you have. I hope my responses haven’t come across too much like the rantings of a grumpy middle-aged man (which I undoubtedly can be), but it is a subject that I am passionate about after watching the majority of my working lifes outputs under-deliver! Out of about 30 odd ERP implementations that I have been associated with, I am (sadly) only really proud of about 3-4 of them. Not the sort of stats you’d want to see for a dam builder or an aeronautical engineer!

I really appreciate all of you that have taken the time to contribute to this blog. Richard’s mention of the “magic silver bullet” recalls to mind that wonderful article by Fred Brooks Jnr ”No Silver Bullet”, wherein he discusses the four inherent difficulties of systems development: Complexity, Changeability, Invisibility and Conformity. Although the article was written while Noah was herding the animals into the ark (in terms of IT time at least), it still holds true today, and based on the issues that many of you have raised in your responses above, these difficulties hold equally true for this Pandora’s box that we call ERP systems.

Complexity: Richard’s point about the complex and myriad functionality that an ERP system offers most certainly makes the system complex. In addition, the integrated database and need to play nice with other departments also makes the system more complex – whereas before, a user could happily work within the safety and security of his or her individual empire, the introduction of an ERP system often requires more interaction between users, departments or functions.

Invisibility: When lecturing this particular piece of literature, I used to ask my 3rd year students to draw 4 objects. First I asked them to draw a book. Then I asked them to draw a car (you wouldn’t believe the amount of Ferraris that were drawn!). Then I asked them to draw a mobile phone. Finally I asked them to draw an information system. At this point they would all look at me blankly and then the class would generally erupt into fits of giggles. An ERP system, like any piece of software, is invisible and unvisualisable, until it is implemented. For end users and management alike, it’s a concept, a black box, you can try to model it with data flow diagrams, object diagrams, entity relationship diagrams, you can draw up user requirements documentation, you can even demo it, but it remains invisible and its complexity enhances this invisibility. It only becomes visible when the user actually uses it to perform actual daily tasks in their real world domains. It’s only at this point that the true requirements, the omitted requirements, and the wrong functionality, are exposed.

Changeability: well, as a transformational artefact, an ERP system will change the way in which the company does things, it will change jobs, tasks, it could even change the structure of the organisation, reassigning people to different departments, and as mentioned by Richard, dismantling or realigning existing individual empires. More importantly for my research purposes, changeability means changing the existing business practices and hence the working practices of the end users. Of course, the initial invisibility of the system enhances its changeability too – after go-live when users really begin to understand what this box is really all about and how it’s making them do their jobs, this is when changes are being requested.

Conformity: Fred Brooks referred to conformity as the ability of a new technology to interoperate with other existing systems, both internal and external to the organisation. This may still hold true for ERP systems, in terms of legacy systems, bolt-ons and additional modules. However, in support of Mark Toomey’s comments on the need for organisational leaders to recognise and respect the human behaviour implications of any investment in IT as an enabler of change, I believe that conformity should also encompass the human aspect of the technology in terms of compatibility. Compatibility is defined by Rogers (1983, 1995) as “the degree to which using an innovation (technology) is perceived as consistent with the existing socio-cultural values and beliefs, past and present experiences, and needs of potential adopters” (Rogers, 1983; p. 223).

It is this changeability and conformity / compatibility that has led me to speculate on the potential effects of occupational communities of practice strength of commitment on the overall success of ERP deployments.

In combination with the inherent difficulties of invisibility and complexity, it seems inevitable that the system will force changes and reshape the way in which users perform their tasks, interact with others and view their roles and relative importance within the organisation. This in itself is scary enough to warrant extensive fear which often manifests itself as user resistance during the implementation phase, resulting in users being uncooperative to the point of not communicating their requirements to the implementation team, leading to the implementation of a system that does not meet their needs. Now imagine a situation where a group of users belong to an occupational community of practice, for example, a group of accountants, or marketing professionals, or production machinists, whose working practices have been shaped and informed by the formal training that they have undertaken in order to become members of that occupation.

Now imagine further that the implementation of the ERP system requires that these working practices are substantially changed to accommodate the best practices that are embedded within the system. Conformity, or compatibility, is lost. These end users are now facing an inconsistency between their occupational communities of practice beliefs and the new practices required by organisational management. The system is forcing them to work against their beliefs, in new and different ways, and depending on the strength of their commitment to their community of practice, this could cause users to make even more errors, become even more dissatisfied with their jobs, and reduce even further their overall job performance, which at a company level results in even more losses of profits than would normally be expected during the initial go-live stage.

There is no doubt as to the importance of the critical success factors of ERP implementation success which many of you have mentioned in your comments. To summarise, these factors include a clear understanding of strategic goals, commitment by top management, organisational change management, requirements analysis and selection of appropriate ERP solution, gap analysis, benefits expectation management, communication and visibility, excellent project management, user involvement, education and training, etc, and the development of performance metrics.

What appears to be missing from the list is the possible influence of occupational communities of practice strength of commitment. This is as yet a factor that remains unexplored. It is by no means the magic silver bullet, but with so many companies continuing to report significant implementation problems or even failures, it may identify another factor that could help to increase the chances for future implementation successes.

Although I have an extensive literature review supporting this theory, an approved research model, a piloted survey instrument, and judging from the comments in this blog, a great deal of support from highly experienced and knowledgeable ERP professionals, everything that I have written so far is still just a theory. Having chosen (foolishly perhaps) to focus this study on end user perceptions, I need to obtain responses to the survey from actual end users of ERP systems. I am really struggling to get sufficient responses to be able to perform the hypotheses testing that will allow acceptance or rejection the theories outlined above.

Many of you who have responded to this blog have indicated involvement in ERP implementations: if any of you would be willing to pass on the survey link to the end-users at companies that you have helped with implementing an ERP system I would be immensely grateful.

One of the biggest headaches in America is if you want to make people and process changes is the UNIONS.

We all failed to mention that if you change jobs, duties and more the union has to be at the table. This is a huge down time as you can’t improve your process without money, concessions and/or more.

I actually had a person screaming at me in a county hospital up north because we were eliminating about 60% of data entry and moving to scanning. She was yelling that is not my job description and you can’t make me do this. I threw her out of the room and then the union got involved and what a mess.

I feel sorry for executives trying to make companies produce and compete when we have to deal with people and rules like that. We were not eliminating her job

Hi Wayne, thanks so much for sharing this with us. I hadnt considered this issue of the unions getting involved, but once again this seems to lend some support for my theory about occupational communities of practice and their effects on implementation success.

I also think this epitomises the difficulty of user resistance to changes to existing work practices, and the fear that it invokes. I understand what you are saying about not actually eliminating her job, but rather changing the way that she was doing her job. I’m assuming that all she was hearing was that her job was changing and she was terrified of being able to learn how to use this new technology and how it would affect her job security in the long term.

You have made some excellent points Gabrielle.

ERP may be complex to implement, but conceptually it’s not that difficult to explain and rationalise. No OCoP, no matter how bloody minded, can argue that an enterprise isn’t better off operating with a single united view that everybody is committed to maintaining (and which is constantly subjected to peer-based review and feedback) than each Key Functional Area of the business maintaining their own “data islands”, none of which agree with each other and may never be aligned at any one point in time. Which view is right? Which is most up to date? Based on which one does the business make any decisions?

A well implemented ERP system should be a “real-time representation of what is happening in the business right now”. It should allow me to give an Available-to-Promise date on a Customer Sales Order without having to ring 3 different people to check (for which I’d probably get 3 different answers from 3 different systems anyway). It should allow me to run an MRP at end of shift every day knowing that the Physical v Theoretical Inventory will be in-sync and will be 99.9% accurate. It should allow me to run a meaningful daily P&L so I know how the business is performing right now at the midpoint of the month instead of getting to the end of the month and finding out, when it is too late to do anything about it, that we lost our way in Week 2.

The benefits of doing ERP well are very pervasive. But how many ERP implementations start by assuming that everybody “gets” this? This is where the “education” piece (ERP101) is so necessary.

Ultimately however, ERP will never happen without the most senior levels of management completely engaged. They are only people with the requisite power to effect change in the business. They are the only ones that can speak for the whole enterprise. They are the only ones with the power to direct and align all functional areas structures and behaviours. They are the only people who can direct Finance to play nice with Purchasing. They are the only people who can smack heads together. The only people that can “performance manage” the passive aggresives and the downright destructives. Without their vision, understanding, engagement and leadership, no ERP implementation stands a chance.

Wayne…I feel your pain. Institutionally supported workforce inflexibility is a real issue.

I’ve just read a very interesting presenting on how to close the Human-Tech gap in ERP implementations. I think that most of you that have commented on this blog would find it of interest. The presentation is available at http://www.slideshare.net/areyoufrank/erp-transformation
Kind regards
Gabrielle

It is an interesting presentation. The very few “really good” ERP implementations that I have been associated have had good levels of HR engagement and this can be extremely helpful. It is a sad fact unfortunately, that the focus of HR in so many organisations IR and compliance and generally firing mangement bullets or acting as a management buffer to labor organisations with a bit of recruitment thrown in. It seems all too rare that their primary focus is that of aligning the Human Resource to the requirements of the business. Which is, of course, what it really should be.

IHMO, one factor I think you may want to look more at with regards best practices is that 95% of companies all work the same .. it is the 5% that make them different that’s important. This 5% is where the ERP system starts to have problems and the project starts to shoe horn the company into the ’standard’ product, but this 5% is what differentiates the company from their competition. It is therefore the most critical part of the company which influences many aspects including the culture, service levels, staff attitude, etc.

You would be doing exceedingly well if any ERP system was a 95%+ fit for any business. There will always be some functional gaps. It’s all in how you deal with them.

It’s not that employees are not committed to their work.It is the company’s responsibility to give adequate knowledge about ERP when switching over to a new system.

Hi there and thanks for your comment. I absolutely agree that companies need to ensure that users are provided with adequate knowledge about the new system.
In terms of employee commitment, I’m not referring to commitment to their jobs, but rather to employees’ strength of identification with their chosen occupation, in other words, a high level of occupational communities of practice identity. What I am exploring is the potential effect that strong commitment to occupational communities of practice could have on users’ acceptance of new systems. This is based on the premise that users who identify strongly with their chosen occupation will want to maintain their existing work practices and ways of working, rather than be forced to adapt to the new ways of working that a new technology brings with its implementation.
The survey is still open for end user participation at https://www.surveymonkey.com/s/ERPWPC
If you are an end-user of ERP systems, please help me to finalise this research by completing the survey. If you are an IT manager or ERP consultant, please forward this link to your clients and end-users for completion.

Its best to adjust with the ERP system that you’ve got after your implementation period.

Great article and great comments! Appreciate you sharing knowledge. In my humble opinion I believe that a root cause for many ERP failures has to do with the implementation approach. Most traditional implementation methods uses a requirements-driven, “build from scratch” approach that fails to maximize the advantages of ERP while addressing the associated challenges. I have developed 10 key strategies that I would like to share with you and your readers. Appreciate your feedback -> http://gbeaubouef.wordpress.com/erp-business-solution-manifesto/

Brett. Your list of principles are excellent. Some very good advice is there.

I’ve just finished reading “Waltzing with the Elephant”. Written by Mark Toomey, a world authority in ISO 38500, the book explains in detail and simple language the concept and principles of Governance of IT.

I highly recommend this book to anyone who is responsible for the success of their organisation’s use of information technology, including those in an external consulting capacity.

More information and online ordering are available at http://www.infonomics.com.au/Publications.htm

For those of you that dont like to read, the good news is that Mr Toomey will be presenting workshops on Governance of IT in four major cities in Europe during September 2011.

You can book your place in London, Dublin, Amsterdam or Madrid at http://www.pmoworks.com/events/BOG2011.htm

For more than 30years, I have been in IT industry,
as a business consultant supporting mfg companies.
I always say to users, ERP is one of tools with that companies create value, in terms of money.
And ideal processes are there in every company.Success or Fail,, that is depend on level of knowledge of ideal process users have.Sales div should maximise the sales numbers(N) that create companies top revenue. Mfg div should realize full value of products(V) that are created in Dev div. Dev div should design products which are expected to create maximum N in Sales and V in Mfg.
When users look at their daily operation with view of N and V maximize, they will see that there are a lot of work which do not create or contribute to create Value.
These are waste of time and energy.
Through these discussions, eliminate waste and make process more smart, then ERP will be useful for them and companies top.

No doubt Gabrielle will touch on many if not all of the potential root causes of ||Why ERP systems disappoint. Without doubt the sales hype, tired products being reworked / re-branded as “out of the box” solutions will still pervade.

In reality some of the best, most efficient manufacturing organisations need little or no software. I have for example visited some sites using highly effective Lean Processes e.g. The Toyota Production System - which do not necessarily need complex software solutions.

The real question if we are Honest is ” Actually for whose benefit are we doing this project ?
and IF there are savings to be made, which silo volunteers to take the hit

Having worked for a large manufacturing company who are, like most other companies, on the quest for that “magic silver bullet” I’ve been through the TPS as the “flavour of the month” (actually it was more like 5 years) before we slowly started realise that we actually weren’t Toyota.

Now I’m not saying that we didn’t cherry pick some useful components from the TPS, but as for running our end-to-end supply chain as an end-to-end pull system? Well it simply doesn’t work as well when you have a huge product range, long customer tail, high mix, high volatility, low individual SKU volumes and long lead times, and 35% of your market is MTO anyway. And the thing that most companies completely overlook when they seize the TPS as their “magic silver bullet”, is that Toyota “push” (yes…it actually operates one of the corporate world’s biggest “push systems”) into a huge pool of finished goods inventory (last estimates I saw run between USD$10 billion and USD$15billion worth) in order to stabilise their demand. They then push this FG inventory into a captive dealer network to get if off their balance sheet. My company certainly can’t do that. So whilst I agree that opportunities exist in many businesses to use less complex more visual planning systems (and we do), most have to use some sort of MRP/Lean convergence.

With respect to the answer to the question “for whose benefit are we doing this project?”, the answer needs to be “the enterprise as a whole”. To my earlier point, ERP is about People, Process, Culture and POLITICS.

Failing of ERP after implementation can be attributed to many complex reasons.I mention below some:
1. Technical requirements do not match with what customers want. Many times frequent changes in hard ware and software makes it difficult for the companies to use it smoothly and ERP fails to deliver what it promised.Frequent changes also requires intensive training to the staff.
2. Staff turnover causes problem.Every company is different even though the software package may be same.
Dr Aloke Chakravartty
00919230527596

I agree pretty much with all of the comments made re ERP, but there seems to be a missing element. When all of these things are going wrong, where is the so called implementing experts who are being paid mega bucks to project manage the implementation. Most of the research to date is from people with vested interests somehow connected to ERP services or software. The quest for taking fees seems to override the responsibility for getting to grips with the inexperienced client and getting the projects on track. Good project managers in any other industry raise the red flags when something goes wrong and does something about it. All we seem to get from ERP project managers from implementing organisations is finger pointing to blame someone else..in this case the hapless client who has footed the bill. The blame also seems to happen in hindsight..reflecting maybe the project manager couldn’t even identify the issues at the time and project the outcome from the signals..hence no corrective action. The great complaints from the customers is The implementers claimed they had the experience, The implementers put inexperienced people on the project, The project managers didn’t flag or raise issues to the crisis level until the mess was evident, The software company misled the client on the capability of the software. Whilst clearly all three parties, the client, the software seller and the implementing team all share some degree of responsibility the onus of alerting the client to major issues and escalating them in the most vigorous way rests with the people who are taking the money to guide the project and ensure the successful outcome of the system. Stand by for an avalanche of lawsuites as companies wake up and realise that they have been shortchanged and overcharged for an expertise the sellers simply didn’t have.

#13…

ERP Fail: When Best Practices Meet Real Life » The TEC Blog…