Hi Patrick,
The first part sounds easy. Create structural profiles for these qualification groups and assign only those to the admins. I guess today everybody has structural access to all qualifications, but are testricted through the employees they can access, the transactiins they use and authorisation object PLOG. So, re qualifications, the structural all needs to be taken away from those users and be replaced by one or more structural profiles for the required Qgroups. Double check that the relationships to "forbidden" Qs are nit giving it away.
The difficulty definitely starts, when you combine it with the manager role. Even if you grant "targetted" structural access only to those Q objects through the relationships from the employees, this would still allow them access to all Qs their own people have, even for other people (you can try, but I think I tried before).
Not sure I had exactly this situation already, but definitely similar ones, and I always ended up using one of the authorisation BAdIs (the one for structural authorisations should do, unless you use the buffering of struct. auth per batch: the system needs to decide access to a Q on a case by case basis).
You'll realise there are a few "not sure"s in here. That's because I found that there is no 100% consustent logic how the auth check works for various object types and context, when looking at the relationship between structural data and the employees. You always need to try in exactly your context. That's why I held back with my answer, to see whether someone with exactly the same situation right in the system in front of them might offer a solution.
I hope these ideaa do help a bit anyway.
Kind regards
Sven