Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Conclusion
This situation is a classic example of users requesting customization before gaining sufficient real-world experience with a new system. Without putting the system through the paces, an organization simply cannot know the extent of the system's capabilities and what it can/cannot support.
Organizations must avoid a "rush to customize." New systems will have shortcomings—both real and perceived, as in the library case study. Workarounds and alternatives should be explored before making a commitment to changing a system that isn't fully implemented. Customizing an enterprise system doesn't mean "fixing" it. Once a system is customized, there simply is no guarantee that it will do precisely what was requested—or intended.
It's important to remember that these complex systems are highly integrated, and they almost always include alternative ways to accomplish a given task. Also, organizations should not be so tightly tied to how they have performed activities in the past. (File that advice under "Easier Said Than Done.") Implementing a new software system means taking the opportunity to examine and adjust business practices. Every change may be difficult. Even something as seemingly straightforward as giving individuals in one area (Acquisitions, in this case) access and privileges in another area (such as the Cataloging module) can become a point of contention.