In my understanding, primary function of a bounded context is to encapsulate a common language used by a group of users. This is the main tool that enables reflecting already used terminology in software abstractions instead of creating unnatural abstractions to satisfy all users.
IMO primary guideline for drawing context boundaries would be to not think about it too much. It's all about already used terminology, so you have to work with the users, listen to their language, ask them for meaning, and draw a boundary when it's needed (or just natural).
As far as specific guidelines go, I can think of the following:
- Two entities should definitely be separated by a context boundary if they have the same name but different meaning,
- A set of terms (let's call it A) known by a group of users should probably be separated from its anti-set (whole domain minus A).
- Keeping bounded contexts self-sufficient (able to provide functionality on their own) enables moving them to different processes, (micro-)services, or even separate systems.
After the domain is created, you could compare it with company's departments (or anything else) as a part of a post-mortem analysis.