Key Process Areas (Process Groups) are another way of partitioning and highlighting some processes over other.
Some international standards can be used for defining key process areas: The key process areas in the QMS are based on the ISO15504/SPICE process model and the ISO12207 Life Cycle Model standards.
A possible configuration for a QMS might have these definitions:
Primary Life Cycle processesTechnical processes performed by projects such as Software Requirements, Software Design. Software Construction, Software Testing, Maintenance and Support.These comprise Customer (CUS) and Engineering (ENG) processes.Supporting ProcessesPerformed in more than one Life Cycle stage, e.g. Configuration Management.These comprise Support Processes (SUP).Organisational ProcessesTypically management-related processes, e.g. Project Management, Risk Management, Scope Management.These comprise Organisational (ORG) and Management (MAN) processes.
In my company, as of today, there are hundreds of documents in the QMS and of those ~57 are process documents (level 2 documents, excluding the SDP which is by itself a process). So if I am a software engineer, it is for sure useful to know that the core engineering processes are marked as ENG.* (* means "something") and that these should be the first ones to read (and to get to know "back and forth"). SUP and MAN (Support and Management processes come after for sure, if I want to start accumulating a Configuration Management role in some project team or if I want to evolve to a project management career, for instance). In other words: It's easier to do what we should do in life: Which is TO FOCUS (*).
PS. For documentation levels see more info here.