You might want to start by interviewing your in-house users about the software, and find out what kind of information they would want to know.
Much of the documentation I have written about software has had one or many audiences in mind.
Your training department probably would benefit from a skeleton of topics (like a TOC).
So then you could discuss what topics are relevant and what are irrelevant to their training objectives.
Some of the topics could cover:
- Target Audience(s)
- Technical Requirements
- How to Install (if applicable)
- Process (i.e. what business function does the software perform?)
- Featureset (what features does the software have?)
- You could have a task based approach to this, e.g. Add A User or Add a
- You could have an object-based approach, e.g. Users, Roles
- You could have a Menu-based approach, e.g. File menu, View Menu
- Lastly, possibly a Upcoming features and FAQ section might act as a growing knowledge repository of your product.
Try to anticipate how your end users use your software, based on your knowledge of developing it, your knowledge of what it does and also based on (hopefully) your interviews with end users.
Most importantly, try to make documentation that you would want to read, use fun example names to demonstrate, and use lots of annotated screenshots.
Hope this helps