Why not to use Local System for your core SCOM accounts
Stay with me here, this is for the SCOM management group installation
So first, let's research and figure out what the experts are doing, and what the install guides exist.
Researching expert published documentation helps us understand the options, and we can dive into some of the reasons why.
SCOM Security
(KH blog )
SQLRights and roles
(KH blog here to download the XLS (applies for 2012,2016 as well)
Experts separate out the various functions into dedicated ID's
The reason for multiple ID's is to lower the risk (less vulnerability if one ID is locked out, expired, disabled)
-- If you use one ID for all SCOM functions, and something happens to the ID, your SCOM environment stops working.
-- There's always some associated risk with either scenario for LocalSystem or ID's (decrypt RunAs ID's UK blog )
If that is a concern, here is some great advice from Kevin Holman
- Control who has access to SCOM
- Control who has access to the servers using RunAs accounts, that are monitored by SCOM.
If you have lost control of local admin on a server, you are compromised, and I am not sure how gaining access to a RunAs account is no worse in some sense.
By the way – this is the entire reason “more secure” was introduced in SCOM 2007R2, to limit distribution of credentials only to servers that required it, to limit the potential for a local attack.
Another option (not recommended) is using Local System
-- Cannot login to system to verify access concerns (quite honestly is why someone might sanction this approach)
-- Scripts run as local system can be terminated, allowing a command window with Local System access
-- Depending on which services LocalSystem is used, this could grant elevated privileges (like a Domain Controller DC)
-- If 'Local System' was used for the core SCOM environment, a change made to the Local Security Policy, or group policy can break the environment.
Local Security Policy snapshot 
Security Options 
Group Policy
Locking down protocol blog here 
Hope this helps you decide the 'how to' set up your environment
Related documentation 2016 Kevin Holman Deployment Guide 2012 R2 Kevin Holman Deployment Guide 2016 Technet Deployment Guide 2012 Technet Deployment Guide 2007R2 Technet Deployment Guide