Tag: erp acronym

Hugger-Mugger fixes goofed open source ERP implementation

Although this article is a year old, it shows how an IT centric approach to ERP will lead to problems. ERP should be a process centric approach with the software being an enabler to good processes:

Hugger-Mugger fixes goofed open source ERP implementation
By Jan Stafford, Editor
05 Jul 2005 | SearchOpenSource.com

The low cost and easy accessibility associated with open source applications make them very attractive to some companies. But, as yoga and exercise products manufacturer Hugger-Mugger discovered, love at first sight led to a hastily implemented and ultimately botched implementation of Compiere’s open source ERP.

Read Article…

How ERP Systems Must Meet the Challenges of Automotive Suppliers

Browsing around the web we often come across gems of information. Here is an article that although a little dated shows how ERP must answer key functions in the automotive industry:

“Being competitive in the automotive industry requires adopting new management methodologies, such as just-in-time, electronic data communications, and work order-less scheduling and billing. Packaged ERP systems are now incorporating functionality to support these new methodologies. Read more here….”

ERP Selections – Making Friends or Making Enemies

by Chris Shaul

When searching for a new ERP (Enterprise Resource Planning) system, there is the right way and the wrong way. If you were to follow all the presumably right things to do, you can still make some awful mistakes. One of the most dreadful things that you can do is to choose the software and then choose the implementation partner.

Let’s illustrate a typical scenario. A company is looking for new business software. They decide that they will do the best practice way of selecting software. They define their requirements, they then send out these requirements to the VAR (Value Added Reseller) of the ERP solutions. For the sake of argument, they choose four software providers and send the RFI (Request for Information) to four different VARs, one from each of the software solutions. They get back the RFI’s and then start to eliminate the candidates. They drive it to two solutions.

The next step is for them to have the VARs provide demos. If they do it correctly, they have the VARs demonstrate the software according to their business process with their actual data. The demonstrations go well and they now have the decision of which software to go with. They choose X. Then someone on the team says ‘Yes, X is great software, but I am not sure about the VAR. What if we look at some other VARs or implementation partners?’

At this point the problems begin. The company wants to interview and get references on three other VARs. They begin doing the due diligence on these other implementers. You might be asking, “So what have they done wrong? It makes sense to check out all the implementation options. Yes that is true, but what about the VAR that spent days and weeks preparing, demonstrating and learning about the company and their business? They have invested a lot of time and resources.

Some would argue that that is just the nature of competition. True, but, what if you find that there is not a better VAR than the one you began with. Now all you have done is made them feel distrusted and alienated. This is not the way to start an implementation. It could have dire consequences down the road.

You want an implementation partner who is your trusted advisor. Going into an implementation should be a partnership working towards a similar goal. Bringing in other candidates at the end of the selection is not the way to bring a trusted relationship to the table.

If you are dealing with a software company that has various VARs, the ideal situation is to ask the software developer, which VAR they would recommend for your business type and industry. This must be done early in the selection when you have just come to the first list of candidate software providers. They may give you a couple of names. You can then screen these two or three VARs early to choose an implementer who you want to do business with, should you choose their software. Then if they are not selected, they understand that it is your choice in software, and if they are selected along with the software, you have already vetted them and you can now begin an implementation with a truly trusted advisor.

Many people forget that the VARs put a lot of time and money into chasing you the lead. If you choose them early and then choose the ERP software, then you move together in unity. If you choose the ERP system and then choose the VAR, the VAR will hold resentment at having spent the time and money only to be possibly tossed out at the end, when another VAR, who has done nothing, gets the implementation. Should the chosen VAR not work out and you have to go back to the first VAR, there will be little chance of working with them as a trusted advisor. So choose the people early and before the choice of software is made. Doing so will only aid in a successful implementation.

Open Source ERP – the list

We have discussed open source ERP here a few times. Finally, someone has put together a list (although we do not know if it is an exhaustive list) of the main open source ERP Packages.

You can see for yourself here:

Line56.com3A20Free20ERP

Causes of ERP Failures

Here is an article that zooms right into the reasons for why ERP implementations fail:

Causes of ERP Failures
by: Bruce Zhang

ERP is the acronym of Enterprise Resource Planning. Multi-module ERP software integrates business activities across various functional departments, from product planning, parts purchasing, inventory control, product distribution, to order tracking. ERP has transformed the way multi-billion dollar corporations conduct their businesses. Successful implementation of ERP systems could save tens of millions of dollars and increase employee satisfactions, customer satisfactions and sustain competitive advantages in every-changing marketplace. Corporate executives are often perplexed by the stories that how reputable corporations (Hershey Foods) have failed miserably and lost ten of millions of dollars in their ERP endures.

The failures of ERP projects are preventable if we can identify the common causes of the failures regardless the companies and industries that implement them.

An ERP system is the combination of ERP software, the business processes that the ERP transforms, the users of the ERP system, and the computer systems that run the ERP applications. The failures of a ERP project is often the result of the failures in one or more of those four components. The failures in computer systems (hardware and operating systems) are much easier to identify and to fix, so we’ll examine the failures in software implementation, business process and user acceptance.

Failure of ERP Software Implementation

Module-based ERP software is the core of ERP systems. Most ERP projects involve significant amount of customizations. Packaged ERP software modules have built-in functionality that work in a standard and simplified enterprise environment. However, every organization is unique in data requirements and business processes. It is the customizations that transform packaged ERP software into ERP software that meets organizations’ individual business processes and operations. Long and expensive customization efforts often result the pass of release deadline and budget overrun. Customizations may make the software more fragile and harder to maintain when it finally goes to production. Major changes may be required in the later stage of the implementation as a result of incomplete requirements and power struggles within organizations

Why New Systems Fail: An Insider’s Guide to Successful IT Projects

The integration of ERP systems (http://www.sysoptima.com/erp/erp_integration.php) with the IT infrastructures also challenges ERP project teams. The use of appropriate implementation methodologies can often make or break a ERP project. (http://www.sysoptima.com/erp/implementation_methodologies.php)

Failure of Accommodating Evolution of Business Processes

According to Anthony, R. A, business processes fall into three levels – strategic planning, management control and operational control. Organizations continuously realign their business processes of all levels in response to the ever-changing market environment. Many ERP systems aren’t flexible enough to accommodate evolution of business processes. many ERP system need a major overhaul in every a couple of years.

Failure of User Acceptance

The users of ERP systems are employees of the organizations at all levels. ERP projects usually modify the company’s business processes which create extra workload for employees who use them initially. They may not think that the workflow embedded in the software are better than the ones they currently use. Ongoing end-user involvement and training may ease the difficult in organization’s adaptation of new systems and new business processes.

About The Author

Bruce Zhang has over 10 years experiences in developing and implementing ecommerce and ebusiness systems in various industries.

He operates a website http://www.sysoptima.com that automatically aggregates the news and new articles in e-business (ERP, CRM,

Supply Chain Management and Knowledge Management) from over 50 sources daily (http://www.sysoptima.com/newsbot/) to help corporate executives, professionals and consultants to keep up with the latest development in enterprise software market. The website offers a knowledge base for understanding business software from a systems perspective.

ERP Forums

We are pleased to announce our new ERP forums!

We will be adding forums as we go, but for now, there are forums dedicated to ERP, PLM, and CRM.

Please feel free to post your questions, answers, topics of concern, or other related topics. Please keep the discussions professional! We hope that these will become a valuable resource to you. We welcome your contributions to this knowledge base of ERP, CRM, and PLM information.

You can view them by going to Our ERP Forums

Blackberry goes ERP

Now that everyone is breathing a sigh of relief after RIM’s legal settlement:
Blackberry goes ERP
by Cliff Saran
Tuesday 7 March 2006

Research in Motion has given its Blackberry Enterprise Server (BES) support for web services to enable wireless access to enterprise systems such as SAP.

The company’s aim with the 4.1 release of BES is to move Blackberry beyond push e-mail. It has introduced a development tool called MDS 4.1 to help businesses create links…Blackberry goes ERP

Corporate ERP of the Next decade: Microsoft/Unix/Java – Coexistence & Harmony?

Andrew Karasev

While in 1990th we saw very fierce fighting between Microsoft Windows and Apple Computer PowerMac for the workstations market, when two systems were practically not compatible and didn’t have plans to understand each other, plus all the blends of Unix/Linux were trying to step in and take workstation market over, the next decade in our opinion will be the decade of coexistence, integration, cross-platform heterogeneous data distribution and querying. Good example would be this – imagine you are freight forwarder and your company has Microsoft Business Solutions Great Plains implemented as accounting and partly distribution application and on the other hand you have Oracle based cargo delivery / tracking system. You do not have to phase out one or the other – you make them coexist: if you need Great Plains user to lookup shipment status – you use heterogeneous query from MS SQL Server (Great Plains) to Oracle via linked server and have instant result set on the screen. Similar heterogeneous query you can have from Oracle side to MS SQL Server. Let’s look at the trends:

• XML – is platform independent way to communicate: transfer inbound/outbound streams of data. This is the sign of future coexistence and it is very simple in reading and understanding by human being

• IT Budget. Evolution versus Revolution: the old days of restructuring your company business operation around new computer system are probably over. Nowadays IT budget is pretty limited and corporate management considers IT as regular (not elite) internal services department. So – you, as IT manager or director has limited resources to revolutionize the company, so you follow the step-by-step evolution

• The sunset of proprietary languages. Good example is Great Plains Dexterity – this is the core of recent Microsoft Great Plains, former Great Plains Dynamics. Dexterity had the history of evolution, and now it is using SQL Stored procs to do the majority of database querying and updating, Microsoft plans to phase it slowly out and replace with the future .Net language of choice (not sure which one will win: C# or VB.Net – but this is not important at this moment). In the close future SQL with XML inbound/outbound will be the language of integrations

• The end of heavy custom programming. At least in the US – majority of the project will be outsourced. In the USA we will be mostly dealing with project management and specifications writing, plus physical hardware support. Even if you are dealing with, say Microsoft Business Solutions partner in San Francisco – partner itself will be using either overseas facility or simply contractors over there. When the majority of us will become project managers, thinking about business logic, not the way of realizing it in the code – we will stop heating the opposite platform –no more Microsoft VB.Net programmer hatred toward Java/EJB/J2EE programmer

We are already doing cross platform integrations from Microsoft Business Solutions products: Microsoft CRM, Great Plains to Oracle, DB2, Lotus and other databases, plus Microsoft CRM email messaging through Lotus Domino to begin realize the strategy

Andrew Karasev is Chief Technology Officer in Alba Spectrum Technologies – USA nationwide Great Plains, Microsoft CRM customization company, serving clients in Chicago, California, Texas, Florida, New York, Georgia, Arizona, Minnesota, UK, Australia and having locations in multiple states and internationally ( http://www.albaspectrum.com ), he is CMA, Great Plains Certified Master, Dexterity, SQL, C#.Net, Crystal Reports and Microsoft CRM SDK developer.