Most organizations have an IT support facility consisting of a help desk and possibly some back-office staff who try to resolve operational issues on behalf of users. It is important in a new project to involve these people early. If they understand how and why a system has been constructed, they are in a much better position to fix it when it breaks. More importantly still, if they don't know about it, then when things go wrong, they will simply pass the support issue on to the nearest developer. The developer is probably in the middle of working on the next release or the next project.
Taking time out from one job to sweep up the mess from a previous one is one of the most common causes of schedule slip. So if you don't want developers spending their time answering phones and rushing off to sort out operational issues, involve the support team early.
Of course, it helps if the support team members have some tools to assist them. For example, can configuration settings be viewed and changed remotely? If the system communicates with another system, can the support team turn on logging of the messages to see where the problem lies? Building simple, system-level tools like these can save a lot of grief later on. Finally, why not release the source code to the support staff? In the old days of mainframes and COBOL, it was common for applications to come with source, and the support staff could often spot where the problems lay by reading it. Nowadays that rarely happens, but if it is an in-house development, why not share the source code with the support team?