This is how i see it:
1- Documentation:
Why: you want to document everything from day 1, you can always come back to in case of Audit, report the progress of your work, and make the life of the personal / team who will inherit your work much easier etc.
2- Clearly determine the asset in scope
Why: you have been told to manage hardware assets, you need to know which assets you are targeting,
In some scenarios, you will be asked to manage only part of the assets in your repository, in some cases, you might be asked to manage asset that doesn’t exist yet in the repository yet.
The last thing you want to do is to spend time and effort on tracking assets. for someone to come and tell you “oh, we don’t need to track these assets)
3- The completeness and accuracy of the asset repository
(Depend on the size of your organization and your objectives, you might need several KPIs to accurately evaluate the health status of your repository)
Why: you need to know what assets you have, how trustworthy the data of your repository is
4- Governance
Why: you can’t do it on your own, therefore you need to know “who” does “what”
5- Processes (you don’t have to start form 0, improve what already build only what it doesn’t)
Why: you need to know “how” each phase of the program is handled, you will start seeing the fruits of your work the more you get better at this