How to Avoid Customizing an ERP
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Requests to customize an enterprise resource planning (ERP) system are essentially inevitable, especially during the system's initial roll-out and implementation. In my earlier InformIT article "Customizing an ERP During Implementation? Just Say No," I presented a rationale for avoiding customization of an ERP system, especially during the early stages of its implementation and adoption. But following such a rationale will usually require more than just a "no customization" policy. Organizations need a well-defined mechanism that will actively develop at least temporary workarounds for customization requests, allowing the organization to postpone making a decision on customizing the software system for at least the initial business cycle. This article demonstrates this process as a case study.
Case Study
Let's consider the example of an integrated library system (ILS), which is much like the library community's equivalent of an enterprise resource planning system. An ILS is a large enterprise software that drives a lot of the library's business operations. In this example, a public library system was migrating to a new ILS from its previous administrative system, which combined a vendor-supported and customized system with the library's original homegrown system.
The library's acquisitions staff was responsible for purchasing and acquiring books, movies, periodicals, and other items that constituted the collections, as well as entering all of that information into the ILS and establishing a unique barcode for each item. Under the old system, the staff members would barcode all copies of a single item, such as all copies of a particular book, at the same time, with each copy receiving a sequentially numbered barcode. For example, 12 copies of the Harper Lee novel To Kill a Mockingbird might be numbered 101–112.
During implementation of its brand-new ILS, the library discovered a significant and show-stopping difference in how the ILS handled the process for barcoding multiple copies of the same item. The Acquisitions module of the new ILS required the information for each unique item to be entered individually—meaning that the information for the library's collection of To Kill a Mockingbird would have to be entered 12 times—once for each copy of the book. If the library staff had to enter all the information for each acquisition one at a time, coding all of the countless newly acquired items per year would simply be unachievable.
According to the ILS vendor, reworking the Acquisitions module to allow multiple items to be barcoded collectively—similar to the way that the library's old system worked—would necessitate customizing the module.