Topic 5: Adapting and customising information systems
A small retailer should configure first, add bolt-ons next, connect systems after that and change code last. A settings change costs nothing when the vendor upgrades. Custom code and new workflows are different. Someone has to check them after every new version, and often rebuild them (Light, 2001).
Why off-the-shelf software never fits perfectly
Vendors design packaged software around a typical shop. No real store trades exactly like that, and the gap between the two is called a misfit (Soh, Kien and Tay-Yap, 2000). Misfit isn’t the whole story, though. Light (2005) found that staff who miss the old screens, and managers attached to familiar processes, also push for changes. Before approving any change, the owner should ask a blunt question. Is the software wrong, or do people just miss the old way? For a South African retailer, the real misfits tend to be lay-by sales, split cash-and-card payments, loyalty points and VAT reports laid out the way the accountant wants them.
The spectrum of tailoring choices
Brehm, Heinzl and Markus (2001) list nine ways to tailor a packaged system, from light settings changes to rewriting the vendor’s code. The upgrade-risk ratings are our own judgement for a small retailer.
The first four rarely need a programmer. The rest usually do, and most small shops don’t have one.
Why customisation costs more later
Every customisation adds maintenance work. After each vendor upgrade, someone has to re-test it and sometimes rewrite it (Light, 2001). Luo and Strong (2004) frame the decision as a choice between changing the system and changing the business process. For a shop with no IT staff, changing the process is usually cheaper.
Cloud POS, sold as software as a service or SaaS, narrows the options. The vendor runs one copy of the software for every customer, so nobody can touch its code. Custom programs can only use what the vendor’s API exposes. That sounds limiting, but it protects the owner. Updates arrive on their own, and little breaks when changes stay within configuration, bolt-ons and API links. Little is not nothing. Vendors retire old API versions, and a link built on one can stop working overnight.
| Tailoring option | What it means | Retail example | Upgrade risk |
|---|---|---|---|
| Configuration | Use the built-in settings | Turn on lay-by, set the VAT rate, create product categories | None |
| Bolt-on | Add a third-party product that runs alongside | A loyalty app from the POS vendor's app store | Low |
| Screen masks | Change how screens look | Hide unused fields on the till screen | Low |
| Extended reporting | Build new reports from existing data | A weekly slow-movers report | Low |
| Workflow programming | Add new approval or process steps | Manager approval for refunds above R500 | Medium |
| User exits | Plug custom code into hooks the vendor provides | Run a check before a discount is applied | Medium |
| ERP programming | Write new programs that use the system's data | A custom stock-take tool | High |
| Interface development | Build links to other systems | Send POS sales to the accounting package | Medium, lower with a published API |
| Code modification | Change the vendor's source code | Rewrite how the till deducts stock | Very high, and impossible on SaaS |
APIs: customising without touching the code
An application programming interface, or API, is a published set of rules that lets one program request data from another or send data to it. Ofoeda, Boateng and Effah (2019) describe APIs as a main route for systems to share data and services. Khanyi et al. (2024) found that APIs make SMEs more efficient by linking systems that used to run separately. In a store, the cloud POS can send daily sales to the accounting package, push stock levels to the online shop and pull loyalty balances into the till. Nobody changes the POS to do it. If the store switches accounting packages later, only the link changes.
Using the SDLC to manage the change
We use six phases of the systems development life cycle, or SDLC, to keep the change under control.
1. Planning. State the problem in business terms, such as “stock counts never match the till”. Set a budget and a go-live date.
2. Analysis. Run a fit-gap check. Mark each current process as a fit, a gap that settings can close, or a gap that needs more. Kruger (2012) treats this as aligning the package with the business.
3. Design. Close each gap with the lightest option on the spectrum. Configuration comes first, then bolt-ons, then API links.
4. Testing. Ring up test sales, a refund, a lay-by and an offline sale during load-shedding. Check that stock levels and accounting totals match. Fix what doesn’t and test again.
5. Implementation. Import clean product and customer data and train staff. Then run the old and new systems side by side for one to two weeks, and have the manager compare totals every day. We prefer this to a pilot or a direct cut-over. A shop with two or three tills learns little from a pilot, and a cut-over leaves nothing to fall back on if the totals go wrong. A short spell of double capturing is cheaper than untangling a failed changeover.
6. Maintenance. Read the vendor’s update notes, check each API link after every update and cancel add-ons nobody uses. With no IT staff, the owner should choose the vendor’s support as carefully as the software.
The South African picture
Faasen, Seymour and Schuler (2013) found that South African SMEs weigh the low upfront cost of SaaS ERP against depending on the vendor and the internet. Jacobs and Kabaso (2025) found that SMEs use only part of the ERP features they pay for, and that firms using more of them report a stronger competitive advantage. Our retailer should get full use out of the standard features before paying for anything custom. Akerejola et al. (2019) linked POS adoption among Nigerian SMEs to reliable power and network access. Load-shedding gives South African shops the same problem. That is why Topic 2 calls for a POS that trades offline and syncs later.
Design and Pedagogy of Reasoning
It is quite common for small businesses to fall into the trap of over-customizing an existing but inflexible software package or trying to develop a completely customized software solution on their own. To make the process of adapting their systems easier for the owners, this topic was organized according to the System Development Life Cycle (SDLC). Through the discussion of an API-based checklist, retail managers are shown how they can customize the existing POS and ecommerce platforms to match their own processes.