Answer
Mapping the current process usually surfaces problems a new tool cannot fix on its own, such as issues that get reported directly to a favorite developer instead of through any formal channel, or escalation that depends entirely on one person's judgment rather than a documented rule. Writing that map down, even informally, forces the team to agree on what should happen before anyone starts comparing software features.
Once the process is defined, the software evaluation gets much simpler, because buyers can test specific platforms against specific requirements instead of generic feature checklists. Ask whether the tool can enforce the intake and escalation rules you just defined, or whether it only supports a generic open-track-close workflow that leaves enforcement back in people's hands. It is also worth testing the tool with a deliberately messy scenario, such as an issue that spans both an IBM i application problem and a business process question, since that is where a tool built around clean, single-category tickets tends to show its limits.