- Case Study
- Why You Should Avoid Customizing New Software
- Seeking an Alternative to Customization
- Case Findings
- The Revised Business Process
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Seeking an Alternative to Customization
Our first step in investigating the requested software change and developing a workaround was to document the business process as performed on the legacy system; we interviewed the staff and observed the process itself from start to completion. Knowing the user's process is essential, as even a slight change to the business process itself may remedy the situation.
We also examined how the process was currently being attempted on the new system. Then we performed a comprehensive search through the vendor's support documentation, extranet, user forums, listservs, and on the web, attempting to determine whether other organizations had experienced a similar issue and how it was addressed.
We spent a great deal of time investigating the new ILS process for barcoding individual items as well as multiple items (called batch barcoding). We needed to understand how the new ILS handled those tasks, in order to decide how to move forward. The ILS may have had features—not yet implemented, or simply unknown to end users—that would effectively meet their needs.
Our research into the new ILS resulted in identifying a means of performing a batch barcode (discussed in the next section) that would meet the library's needs. This process was presented to the library's project-management staff as information they could use in choosing which option would be best as the next step:
- Following the identified batch barcoding approach
- Adapting the new ILS business for batch barcoding
- Customizing the ILS to meet the business processes from the previous system