Embed Size (px)
Citation preview
Customization Of (ERP) Enterprise Resource Planning SystemsBy cloudtweaks September 11, 2013 1:05 pm
10inShare
Customization Of (ERP) Enterprise Resource Planning SystemsBased on statistics, more advisors believe that customization features are no longer found in modern Enterprise Resource Planning systems. Thus, a number of users ponder the functions and benefits that customization offers. After all, customization was merely changes in format designed with several configuration tools that you can find in the latest ERP solutions available at present. These essential tools are intended to improve the functions of an ERP system by allowing it to meet specific needs of every type and size of business. Nevertheless, modern ERP solutions include relevant features and tools that provide businesses the ease in managing key information such as text, date and number files. Users have an access to these pertinent details, so that figures can be calculated and evaluated quickly.
Customizations are attained upon integrating a series of systems, although recent features allow you to move an application easily form one field or value to another. If you wish to transfer your warehouse management system from a vendor to another, you may do so instantly without any hassles. Hence, customizations may no longer be an important feature.
Today, there are much changes made to Enterprise Resource Planning solutions, which cater to the needs of every business owner. In fact, you will be impressed by the number of ERP solutions that are designed for a number of industries, which further eliminates the need for ERP customization features. Since it is effortless to locate and application that suits your business needs, there is no need to adapt each tool to your company profile. While this feature is still found in some ERP systems, it is likely to become obsolete considering its lack of relevance at present.
It is worth noting that ERP customization hardly played a key role in the system since earlier versions were APICS-based. This means business owners may still utilize these standard features of their ERP system without the need for customization. As a result, more people decide against customizing their ERP software right from the start. They give the system some time to determine whether it can keep up with the current performance of their business, and they choose to customize eventually whenever it is necessary to do so. In fact, it was rare for business owners to rely on their ERP software as it is without performing any personalization task that is intended to match the system with their industry or business profile.
Modern Enterprise Resource Planning systems include programs and tools that are suitable to the needs of most businesses, which reduces the need for customization. Because of these tailored features, it is hassle-free for business owners to utilize these tools for the growth and development of their company. Furthermore, it is less intricate to become versed in incorporating the ERP system since it is not necessary to alter or modify it to match your requirements. You can use the software as it is, thus minimizing the difficulty in becoming accustomed to a new tool that supports and enhances your business operations.
By Tom Johnson,
Tom is a former sales engineer for a prominent ERP vendor who is a Tech columnist in his spare time. He is currently retired in Jacksonville, Florida. For more, visit his blog at www.enterpriseresourceplanning.info.
ERP Failure Avoidance Guide: Part 2 – Managing ChangePosted on 02/03/12 by Phil Marshall
ERP implementations succeed because end users are sufficiently competent at go-live to operate the system and conduct business. The condition of “end user competence” requires more than just sitting through two hours of ERP training. It is having a variety of people participating in blueprinting and testing, and who develop rudimentary problem solving skills. Competence is having the collective confidence to make the massive change to a totally new system that, if poorly executed, could bring the organization to its knees with an ERP failure. Competence is staying calm and focused, and knowing how to work through unexpected problems without panicking.
The level of competence your end users have at go-live will be in direct proportion to the investment you make in change management. “Change management” can be a team, a process, a communications strategy, or any combination of the three. If a choice must be made, focus on process. By process, we mean a verifiable way to make certain that all end users affected by the ERP implementation have been identified by name and job function; that they are scheduled for routine progress updates and communications meetings throughout the project; that appropriate training material is created , scheduled, and effectively delivered to each one prior to ERP go-live; and that all possible steps are taken to minimize free floating anxiety and uninformed speculation.
Beware of Nodding Heads
If your change management effort is not consistent and energetic, you will be outflanked and defeated by passive resistance and a full-blown ERP failure will be a distinct possibility. End users inevitably believe that if they can avoid engagement during the building phase, and that they will somehow be exempt from involvement after go-live. There will not be open confrontation about anything you are doing. In fact, you will see nothing but smiles and nodding, and feel pretty certain that everything is on course until you realize that with four weeks until go-live, your attendance at end user training is around 30%, and you are not getting any management support. And the world is not fair: the end user community will not step forward to say “We take responsibility for this poor implementation; we didn’t take it seriously, even though the ERP implementation team tried their best.” No, they will simply point at you and say, “We weren’t trained properly.”
Put Your Users at the Heart of the Process
It is a good idea to begin having weekly readiness meetings with the functional leaders of the end user community about eight weeks before go-live. As you march towards go-live, they – not you – should present an updated weekly assessment of their area’s readiness status. The assessment can be a “remaining issues” list, it can be a numerical score, or it can be a simple color-coded
readiness chart. Readiness meetings are not a cure-all, but they at least build a forum at which leadership must acknowledge awareness of the change that is coming, and their area’s responsibility to make it work.
ERP is not a field of dreams. “If you build it, they will come,” does not apply to an ERP implementation. Work hard on change management and you’ll be some of the way to avoiding the spectre of an ERP failure.
ERP Failure Avoidance Guide: Part 3 – Data CleansingPosted on 08/03/12 by Richard Barker
Data cleansing is a unique combination of high risk and low contingencies, which is what makes it a top reason for ERP failure. It is high risk because one consistent error or one missing field can cause a transaction to fail, and you don’t need many transactions to fail before you have chaos. Another contributor to high risk is that it is not generally possible to test all of the master data prior to ERP implementation; the best you can do is test the biggest random sample you can manage. The reason data cleansing has few mitigating contingencies is because the responsibility of data cleansing is normally restricted to a very few people in the ERP team. This has the intended benefit of greater consistency and accountability, but it also means that it is very difficult to add short-term resources in the event of problems.
When you first start an ERP implementation, it is easy to assume that data cleansing means reformatting and rearranging all of your existing legacy data. It does encompass that, but it is much, much more, and it is difficult to grasp that until you start building out the ERP system.
The “legacy cleansing” work is understandable. Zip codes don’t match cities in customer addresses; the same customer is listed four different times with four different spellings; an sku is listed as obsolete in the manufacturing system and available to promise in order entry. These are just mistakes that need correcting.
Old Sins Revisited
The truly complicating aspects of data cleansing occur when no legacy data ever existed. This is where both sins of omission and data inaccuracies can trip you up. Sins of omission will generally prevent business from occurring, while data inaccuracies result in execution problems. Suppose that in your new ERP system, specifics about how a material is shipped is part of the material master data record, and that product ships in boxes stacked on a pallet. ERP wants to
know how much product per box, how many boxes per pallet, what the dimensions of the pallet are, what the weight of the product is, and what the weight of the boxes and pallets are. In legacy, someone in the warehouse mysteriously dealt with all that stuff. If you do not enter the information at all (a sin of omission) the material cannot be activated and orders taken. If the data is incorrect, you will generate bad business information relating to transportation requirements, transportation costs, packing costs, and packing material needs. And you won’t discover any errors until there is either a financial variance, or a crisis at the shipping dock. Hey presto – ERP failure.
Don't Miss: Free Download "Four Common Mistakes of ERP Implementation"
Be relentless when it comes to data cleansing. In the example above, the wrong number of pallets is a hassle, but what if the error was an incorrect process recipe and a large amount of product was no good? To avoid an ERP failure, put really good people on data cleansing, and think constantly about ways that you might find potential errors.
4 Steps to Achieving a Successful ERP Testing PhasePosted on 02/12/13 by Tom Miller
Implementing an ERP system is a long, expensive, and complex series of tasks. Testing is one of the more important tasks, but is probably the least fun to carry out and is, almost certainly, under appreciated.
What is the goal of ERP testing? Try to break the entire system – hardware, software, and processes. If nothing breaks, that only means you didn’t test hard enough. You know something you do will not be easy to integrate into the ERP system. Isn’t it a lot better to find out about it now in a test mode rather than later when real money is in play?
Simple ERP Testing
Start out with simple ERP testing on single-process tests. Add a new customer record. Create and open a new production job. Record some production time toward a job. Receive a payment from a customer. One of the subtle side goals of testing is training and the key users you have lined up for testing need to start with baby steps. Set up an issue log. Document in that log anything, however small or large, that might interfere with go-live. There will be issues logged even with these baby steps. Some will be resolved by remedial training and running the test again. Others will point toward real issues.
Record Every Step
Record every step during ERP testing. Write down the ID numbers, order numbers, part numbers and anything related to the test. Note what the system settings were when the test was run. To be
certain any issues are resolved, you need to run the test again with exactly the same setup. You might also find on a later test that there is a problem with the customer payment that worked this time. Having a record of the test that worked will be an important benchmark.
Complex ERP Testing
Move toward more complex ERP testing on single-process steps. Instead of a customer shipment, try to test a customer return with and without a credit issued. Try another test where you correct the time against a production job and change that time to another operation.
Order to Cash Testing
Final testing is often called “Order to cash” tests. Enter a new customer order. Buy materials for the job. Open a production job, record time and charge materials to the job. Ship the order out, print a packing list and all necessary certifications for the shipment. Bill the customer and process their payment. Pay the suppliers whom you bought materials from. Record all the results in the books and complete a month-end accounting cycle and see your profit for this one order.
ERP testing may not be a laugh-per-minute task, but you can take solace in the fact that when you do break the system, you can watch your IT people pull their hair out trying to fix it.
