As application manager, you'll join the Application Management Team, consisting of yourself and two direct colleagues. As a team you're part of the
Digitalisation & Information Services (RDIS) team at RSM, one of Europe’s most international and innovative business schools.
Job description Being an application manager means supporting academic and professional staff to navigate the software applications offered by RSM. The application manager is the first point of contact for software related questions and issues. This means that you'll be in frequent contact with business and end users, and need to know about the application portfolio or be able to learn it quickly.
As application manager you'll organise frequent knowledge sessions during which you go through system updates and educate end users on the inner workings of the software. End users are encouraged to be active participants in giving substance to these meetings, and you'll do this together with the other application managers.
To allow end users to be self-sufficient, we provide access to our knowledge-bases where users can find information via FAQs.
When new technology is introduced to the organisation, the Application Management Team is often involved in setting up requirements and aiding in the implementation. While projects related to new technologies are often led by the consultancy team, the input and assistance of the application managers is vitally important. This requires knowledge of what the business or operation needs, as well as the restrictions associated with that technology.
Being an application manager means working with academic and professional staff. While we support hybrid working, the Application Management Team tries to have someone on site and accessible every weekday to assist or intervene when necessary.
Day-to-dayThe day starts with a daily scrum meeting, when you'll discuss what you did yesterday, the impediments you've encountered, how the team can help you, and what you're going to do today. Next, you'll go through the Jira ticket board as a team to discuss the status of unassigned or pending tickets.
Following this meeting you'll be working on an issue reported by an educator. They are unable to adjust the configurations of their course in one of our custom applications. After searching the back-end you notice that this is due to a previously unidentified software bug. You walk over to the Product Owner of the Operations Software Engineering team, right across from your office, and discuss the impact and severity of the bug. The bug will be handled in the next development iteration, during which you'll be asked to join the development cycle to test and/or accept the issue. The outcome is reported to the educator, and via the back-end you manually adjust the configuration, solving the issue.
During lunch you and several of your colleagues visit the foodcourt, which has a wide array of establishments to choose from. You're surrounded by students and colleagues from other departments; it's a great place to connect with people outside of your own department.
After returning from lunch, there's a knowledge session planned, which you and your direct colleagues are hosting. One of your colleagues is absent, due to an overlapping meeting they they need to attend about the implementation of Microsoft 365. During the knowledge session you inform the business about new features which are available in OSIRIS, and how they can use these features in their workings. The business has already prepared some questions, some of which are easily answered and overlap with one another. You take this as input to update the knowledge base because you realise multiple users were experiencing the same difficulty. The day is nearly at an end, and you're deciding whether you're going home, or if you want to visit the Paviljoen restaurant or the Smitse campus café, but before you leave, you write yourself a quick note describing your day, so you're well prepared for tomorrow's daily scrum.