I am working for an application service provider who is currently trying to document all of its processes (not only ITIL processes). There have been problems because standard procedures like creating a new user account are not being documented and consequently not being followed.

The problem is: I don't know at which level to stop.
During a brainstorming session we identified processes like
- install program A
- install program B
- install new printer
- create new user account
- delete user account
- Incident Management
- Problem Management
- Release Management
- and so on

We try to create a (high level) process map, but I'm not sure how to structure it and where to put which process.

Did anyone document not only ITIL processes but also processes like "creating a new user account"? There are a lot of those daily operations and we want to document them. Did anyone try to do the same and how did you proceed?

You may want to start by simply ensuring a "sequential/ordered task list" for each process. The first thing that everyone thinks of when documenting processes is taking the time to diagram and document everything. However, over 90% of what is important in any process are the tasks that must be performed, with some level of order to them. Starting with nothing more than such task lists will allow you to create a "check list" of everything that needs to be accomplished, so that those managing the processes can simply check off each task as it's done. Only if the teams managing and using the processes need more than that, should you help to improve those check lists into far more detailed process flows and documentation.

An ordered list of tasks for each process will at least allow you a very quick baseline of your enterprise.

Another approach (which basically does the same thing but reverses what you described) is to take a "Service identification first" approach, where you identify your services and who's responsible for them...

Service List

Service A : Help Desk
Service B : Engineering
Service C : Help Desk
Service D : Purchasing

What I personally like about this approach is that it can then also be broken down further, into Service-specific Tasks and you can even see natural interleaving between services...

When done, you almost have a mini-Project Plan, with a sequential flow of Tasks and accountable Organizations (even Roles and/or People if you want) that helps you get a map of what needs to be done and who's accountable for the work. This now also gives you a high-level check-list that you can stay on top of for getting that work done. It also starts to allow for easy mapping across Processes and/or Services (even Projects).