Abstract:

Digital transformation in Higher Education and science is a mission-critical demand to prepare educational institutions for their future competition on the international market. The consequences of a wrong choice regarding exchangeable standard software, like a communication tool or a time recording software mostly is limited to the costs for the substitution of the software (and maybe hardware), working time and charges for additional staff training. Differently, if the software planned for acquisition, is meant as a long-term investment, requires a lot of technological adjustments and is to be applied within a business- and security-critical environment, wrong decisions during the software acquisition period might lead to hardly calculable damage. Besides having to overcome the “make-or-buy dilemma”, questions arising are how to decide for a particular solution and how much time to invest for the related decisions and the acquisition process.

In order to increase our university’s level of data security, ease the interaction between stakeholders, eliminate media discontinuities, improve the process management and transparency, reduce execution time and keep the maintenance time within a limit, we planned to apply a commercial Business Support System. Digital transformation in our institution, is understood as a holistic approach. Thus, our agenda stipulated the introduction of the electronic case file as well as the digitization (and automation) of administrative university processes, including large parts of the student self-service and the administrative student life cycle.

As a public institution within Europe, we are forced to open a competitive bidding as soon, as the overall volume exceeds certain limits. This process is very time consuming and if not properly prepared, bears the risk to end up with a product that appears less cost-intensive than others but does not fit the actual needs. Thus, we, first of all, analysed related requirements from the perspectives of our different user groups and systems and then, the market. For us, it was clear that no commercial solution would cover 100 % of our – partly, very particular – requirements but we had to ensure that the system eventually acquired, would be open enough that we can implement missing features ourselves.

For the software acquisition process, which is focused in this paper, the literature recommends certain methods and tools. In our case, and we think that in such complex scenarios this might rather be the rule than an exception, usual tools and practices, commonly applied to (simple) software acquisition processes, simply failed to lead to meaningful results.

After an introduction of the theoretical background and our software acquisition process, we analyse where theory and practice collided, report about the measures we took to overcome the gap and the lessons we eventually learned for future software projects.

Keywords:

Business Support System, Process Automation, Student Life Cycle, Student Self-Service, Student Administration, Software Acquisition.