Start with a question, not an inventory
A CMDB should help people make operational decisions. Identify the questions it must answer: which services depend on a component, who owns it, what changes could affect it, and who must respond when it fails. Use those questions to define the scope.
Model what you manage
For SaaS, consider the subscribed service, tenant, business owner, supplier and relevant integrations. For PaaS, consider the managed platform services and the applications that depend on them. For IaaS, consider the resources and relationships your team needs to operate. These are design suggestions, not a universal mandatory CI list.
Relationships make the model useful
Connect customer-facing services to supporting applications, platforms and providers. Record only relationships that have an owner, a maintenance mechanism and a clear operational use. A large unmaintained dependency map can reduce trust rather than improve it.
Define ownership before collecting data
For each data field, agree the authoritative source, update trigger, responsible team and validation rule. Separate discovered technical facts from business context that requires human ownership. Decide how stale or disputed information will be handled.
Pilot one service
Choose an important service, build its minimum useful model and test it during an incident or change review. Expand when the data helps people make better decisions. Measure usefulness and freshness alongside coverage.