I have had to handle this exact kind of situation (in a different context) as a managing consultant.
These other departments are not coming to you on a whim. They are coming to get a technical solution to a legit business problem.
Over time, your department has become the "outsourcing partner" to build the tooling for other departments to use. These departments need said tools to optimise their functioning. This activity - tooling for other departments is now eating into a significant chunk of your department's resources. This is the problem.
The immediate solution is not to cut off these other departments from their tool-makers. That'd just be hampering the larger organization. At some point you will cut off something important (because to you it is all "requests" and to them some of it can be critical) and things will get escalated way over your head. And you and whoever gave you this remit will have to answer for it.
Departments do not exist in isolation to be self-serving. They are there to serve the company. The right thing to do is look beyond your precise remit and try and figure out with a collaborative approach what the right solution needs to be. In most cases, this will require the involvement of the top execs of the company to get all the parties on board.
Often this kind of problem happens in companies with outdated systems, which necessitate a lot of manual workarounds.
A long term solution will be to get a more advanced system (ERP, accounting or whatever else it is) that addresses the needs of the different groups. This is a long process. Your company will need to study a number of systems, and go through the pain of adopting to a new one and do a bunch of migrations. 2-3 years work at a large company, involving lots of consultants.
Another approach is to split the tech BAU (business as usual) processes from the "special" requests. Have a separate team handling these requests and ensure to get the documentation in order. This can be the best short-mid term solution. Understand that with this approach, you are in a way writing parts of the "operating system" of the organization - which in the long term is suboptimal compared to the previous bullet point.
Yet another (potentially highly suboptimal) approach is to work out an arrangement where each department has its own tiny little engineering outfit. Depending on the scope and scale of the problems this can be a good idea (if the tools are simple to build and maintain). Depending on the need for interoperability and the level of interdependencies, this can be a terrible idea (tools from different departments need to talk to each other).
TL;DR - think at the level of the company - what is the best way for the work to get done. Departments can be reorganized, roles can be reassigned.
I see this answer getting many upvotes. So here is what I think the first step should be in very practical terms.
Start documenting all of the different new requests you get. For each request, write down why it is needed (1 liner), who needs it (which function in which department), how often will it be used, what is the cost of not having it, how are they currently handling it, and a subjective rating of its relative importance. It will be really ideal if your department already has this for the recent past.
This is like the opposite of what a big ticket salesperson does to "discover customer needs". Let your boss know that you are starting this process and will share the results with him within 1-2 months.
Over a period of 1-2 months, after you have built a detailed record of what kind of problems you are actually solving for other people, it will become a lot easier for departmental managers and execs to wrap their head around and think of holistic solutions.
The departmental managers might even conclude that some of these requests should be solved internally instead of overloading your people. And doing this exercise will also discourage the other departments from coming with trivial requests. The other departments may even set up an internal procedure where a request to your department will have to go through an internal chain of command first. It is after all quite possible that because there's a free tool-builder department available, staff from other departments come to you to request tooling that may only be rarely used. And you will also figure out what resources you need to handle the situation.