How to accept software for support?

Question

Documentation

Good afternoon.
I work in the support of a company that for its own needs contains several programmers who write software for the requirements of the organization. Plus, various software is purchased from time to time, quite often without any documentation.
There was a need to put things in order in the field of receiving/transferring software for support. It is necessary to draw up a document regulating the transfer of software for support (by whom, with what, who accepts, points of agreement, etc.).
Anyone with experience with this, please share. Nowhere can I find a single hint of the correctness of this kind of documentation.
Thanks in advance.

Answer 1

It's not entirely clear what you mean.
If you buy software from a third-party manufacturer, he must provide you not only with an invoice for payment, but also with an act of acceptance and transfer of non-exclusive rights, plus a license agreement is concluded between the office and the seller. All this is signed by the head - either the company as a whole, or the head of the department that deals with procurement. Everywhere is different.

Answer 2

Perhaps I expressed my thoughts not quite correctly. Let's omit the purchase of software and its development. Interested in the adoption of software for support. Transfer from the developers of those documentation, manuals, specifications, determination of the order of support, those responsible from the development side, etc. To describe these actions, it is necessary to develop an acceptance / transfer procedure.
Now it looks something like this:
developer: from today we have transferred program X to users, you support it.
support: ???? where is the documentation for support, for users, etc.?
or even better:
user: program X is not working for me here, fix it.
support: what kind of program is this? 0.O

Answer 3

Try first to read GOST 24.208-80 Requirements for the content of documents of the "Commissioning" stage. Just be careful!
I think that after reading a certain picture will form in my head.

Answer 4

More recently, an information system was put into operation. The software is not self-written. What we managed to get: a description of the architecture, documentation of some features of operation: we got their Wiki (in my opinion it would be a good trend if this were the rule). In self-written software, in my opinion, there is one big problem, writing documentation about new features lags behind the real system, because. As a rule, there is always not enough resources for its design. Unfortunately, even in large companies where more than 2 developers work on software, you have to state the fact that if you put a new version of the installation features in the documentation, you will not find it.