I wouldn't get hung up on what you call it/them but make sure you know/understand/manage all the "bits" where they need to be known/understood/managed.
(one of the) first steps in Configuration Management is "Configuration Identification".
ie Defining what "bits" you have and (as important) how you are going to manage them.
This may be spread across a variety of tools etc and wil (almost certainly) have layers of "granularity"/context*
*granularity/context - A sinlge package/tool/COTS/widgit/System may be percieved in very different ways for example
a) Widget1 from a "Production" perspective might be a single entity
b) Widget1 from a "deployment" perspective might be made up of several "components" (all owned by different teams)
c) Widget1 from a "development" perspective might be 100s or 1000s of individual files (or settings).
So as a simple model for your "COTS" or "MOTS" I normally visualise (at least) 4 contexts.
1) The Vanilla "COTS" - The actual out iof the box unchanged Stuff (at a unitary level ie one entity/CI)
2) The Site/Company specific "config" - The stuff that does what you want it to do (different from vanilla)**
3) The environment specific "config" - The stuff that supports your SDLC eg TEST Server/DBase/WebSite settings differ from the Prod**
4) The delivered "entity" - The thing that the end user knows (possibly the entity in Service Now)
** layers 2&3 may be may config files, pdfs, templates etc that are managed in your Version Control tool or possibly "just" a document that details various settings
1 may ony be a component of 4 etc etc
