Adapting and Customizing Information Systems

Understanding the Options

No matter how small the change may seem, changing a system always involves some effort and risk. There are four types of changes you can make to a system, and each has its own level of effort and risk.

Start at the top of Table 1 and move down only if the need cannot be satisfied at the higher level. (W.Noyes, 2003) states that modern systems contain many institution-specific rules and values that are stored in tables that can be updated by authorized personnel. These tables remain intact when the system is updated. In contrast, custom-written code must be updated by technical personnel.

(W.Noyes, 2003) also identifies a dilemma. A study Noyes references concluded that the less customization in a project, the more likely it is to be completed on time and within budget. However, heavier customization generally results in greater user satisfaction with the outcome of the project. Noyes adds that many requests for customization ultimately prove to be unnecessary because there is already a method of completing the requested task within the system that the user was unaware of. Therefore, before requesting customization, institutions must assess whether the current system can accomplish the desired objective.

Why the Institution Needs to Adapt its Systems

• Different users need different information. The scenario identifies three user groups: academic managers, administrators and IT staff. Each group requires a different perspective of the same data; however, rarely does a default configuration provide this.
• Sector-specific requirements. All private higher education institutions must be registered with the Department of Higher Education and Training (DHET). All programmes offered by private institutions must be accredited by the Higher Education Quality Committee of the Council on Higher Education and registered on the National Qualification Framework by SAQA (South African Government, 2014). Consequently, all systems used by private institutions must accurately record programme, qualification and NQF level information. Furthermore, private institutions are required to submit annual reports to DHET, and failure to do so has prompted DHET to initiate proceedings to revoke the registrations of private institutions (SAnews, 2025). Accuracy and ease of extracting student and programme data are critical components of these reporting requirements.
• Institution-specific processes. Registration periods, supplementary assessments, payment plans and credit transfers vary among institutions. A study conducted across six higher education institutions indicated that all six institutions utilized either customizations or third-party software after implementing a student administration system because the out-of-the-box functionality of the system alone failed to meet the operational needs of the institutions (Sullivan, 2009).
• Legal duties. The Protection of Personal Information Act (POPIA) mandates that systems used by institutions must protect student information, maintain its accuracy and enable students to request modifications to their information (South African Government, 2014). Therefore, all systems utilized by institutions must be modified to facilitate compliance with POPIA.
• Poor fitness leads to workarounds. When a system fails to facilitate a particular task, staff members resort to creating their own spreadsheets and records. This is likely one reason for the duplication and inconsistency of student records mentioned in the scenario.

Adapting Each System

Each of the three systems can be adapted in ways consistent with its function. The table below presents realistic examples. These examples serve as illustrations and would be modified according to the specific products utilized by the institution.

Adapting Through Integration, Not Only Code Changes

Many of the issues presented in scenario 3 can be resolved by integrating the systems appropriately rather than rewriting them. Many LMS platforms offer authorized methods for exchanging data. For instance, Moodle includes a web services interface and a plug-in system, which a university could leverage to automatically enroll students in courses using registration data from another system (Majumber, 2025). As these integrations utilize authorized tools provided by the vendor, they generally require less maintenance than alterations made directly to the core code. Integration principles help ensure reliable integration:

• One system of record per data type. The SMS maintains personal and registration details, the finance system maintains fees and payments, and the LMS maintains learning activities. Other systems receive copies rather than maintaining their own versions.
• A common identifier. A unique student identification number that links records across systems and prevents duplication.
• Monitoring. Data transfers should occur at predetermined intervals and capture any failures so that IT personnel can resolve them prior to personnel or students becoming aware.

Wider enterprise system integration challenges are addressed in the enterprise systems section of this website.

Tailoring Information to Each Role

One of the most practical forms of adaptation is customizing what each person views. Dashboards and reports can be configured for each group identified in the scenario.

Each role should only view the information it requires. Role-based access safeguards student privacy and supports POPIA requirements regarding the protection of personal information.

Risks of Customization

While customizing code may provide a better fit, the risks are substantial and frequently arise only after project completion.

• Upgrades become costly. The study cited by (W.Noyes, 2003) demonstrated that for every dollar invested in customization during implementation, approximately three dollars would be incurred each time the modification is reinstalled in subsequent upgrades. Although this study was conducted in 2002, the principle remains relevant: customized code must be revalidated every time the system is upgraded.
• Increased cost and diminished vendor support. Customization can improve fitness but is associated with higher costs, complexities with upgrades, and reduced vendor support; consequently, consultants typically recommend treating it as a last resort (Panorama Consulting Group , 2025). Customizing higher education ERP systems elevates implementation costs and complicates upgrades.
• Long-term maintenance and scope creep. Even extensive configuration can impede maintenance and upgrades of a system if it is not managed effectively (BerryDunn, 2023) Small requests accumulate over time.
• Transitioning to cloud-based systems. Cloud-based systems are less amenable to deep customization; therefore, institutions with heavily customized systems may encounter difficulties when transitioning later (ERP Today, 2025).
• Security and privacy vulnerabilities. An inadequately tested modification could expose student data or circumvent access controls.
• Dependence on individuals. If a developer creates a customization and subsequently departs, no one may comprehend how to maintain it.

A Practical Approach to Adapting Systems

A practical approach to adapting systems. The institution can employ the following steps whenever personnel request a change. These steps adhere to the logic described by (W.Noyes, 2003) Evaluate what the system can already accomplish before modifying it.

1. Identify the actual need. Relate the request to a problem. For example: "Academic personnel cannot determine which students owe outstanding fees."
2. Assess the process. Occasionally, simplifying the process is preferable to altering the software.
3. Initially attempt configuration. Inquire with the vendor or an experienced consultant whether a setting, table, or report presently fulfils the requirement.
4. Consider integration or an approved add-on. Utilize supported tools before writing custom code.
5. Only customize with a demonstrable advantage. Compare the cost, risk, and impact on future upgrades.
6. Conduct testing securely. Employ a separate testing environment with fictitious data, not actual student records.
7. Document the change. Record what was altered, why, who approved it, and how to undo it.
8. Provide training and conduct reviews. Train the personnel who will utilize the change and review it after a few months.

Example: sharing fee status between systems

Problem: Academic personnel cannot ascertain whether a student’s account is suspended by finance; therefore, students with overdue fees may continue to access courses and the LMS.

Solution: The finance system is configured to generate a daily fee status. Only a simple “cleared” or “not cleared” indicator is transmitted to the Student Management System; the comprehensive financial record is not included. The Student Management System is configured so that only registration administrators can view the indicator.

Result: The need is satisfied through the configuration and integration; no custom code is required. Less personal information is shared, which complies with POPIA (South African Government, 2014).

Governance and Change Management

Technology represents only a portion of the solution. Higher education institutions often possess established procedures and cultures that resist change (BerryDunn, 2023), thus adaptation must be managed prudently.

• Assign a system owner for each system who is responsible for decisions concerning changes.
• Implement a change request procedure. A small committee comprising academic, finance, and IT representatives should approve requests so that one department's preferences do not adversely affect another's.
• Maintain a registry of customizations indicating what exists, who developed it, and when it was last tested.
• Engage users early in the process. Personnel who participate in designing a change are more likely to implement it correctly.
• Review periodically. Eliminate customizations that are no longer in use and retest the remaining customizations after each upgrade.

POPIA, Security and Customization

Each adaptation must be evaluated against the institution's responsibilities under POPIA (South African Government, 2014).

• Share only what is necessary. Information should be shared for a specific purpose, and only the pertinent details required, as exemplified in the fee status example above.
• Preserve existing security measures. New integrations create additional entry points into the data. Access controls, encryption, and monitoring must encompass these entry points.
• Manage external developers. If a vendor or consultant creates or maintains a change, they may process student information on behalf of the institution. The institution retains accountability; therefore, responsibilities should be delineated in a formal agreement.
• Protect students’ rights. Following any change, students must still be able to request their information and have inaccuracies rectified.
• Test with fictitious data. Do not duplicate real students' records into testing environments without protection.

Conclusion

Adapting information systems is essential because no standard product perfectly suits an institution. In scenario 3, modifying the Student Management System, LMS, and finance system can aid in diminishing duplicate records, providing personnel with the requisite information, and supporting DHET reporting.

Optimal outcomes result from moderation. Configuration and authorized integration should precede custom code; custom code should be considered a last resort due to elevated costs, complications with upgrades, and potential security and privacy vulnerabilities. With explicit ownership, a controlled change process, and awareness of POPIA, the institution can tailor its systems to meet its requirements while preserving reliability and security.