Simple Asset Management
When embarking a new ‘Asset Management’ software project, some key areas were looked at from the very start to ensure the end result adhered to three main points.
Ease of Use
All too often, the complexity of systems meant the software designed to solve a problem, became the problem itself. User interfaces became a minefield, the initial data per asset was too in-depth and often not even available.
The time taken to collate and input the initial key data had to be kept to a minimum, too complex and the same old result of missing and unreliable data meant unreliable output.
Much of the data per asset is common data, with each asset type having a set of common parameters that could be applied to many assets. Ensuring as much of the common data is populated for each different asset type ensured the keystrokes required when adding assets were kept to a minimum.
By collating and entering data from the very start of an assets creation or purchase key dates, costs and other data could also be recorded. Ensuring these are correct in the purchase systems meant the share data could also be used for assets. It does not matter what the asset is, it could be a car, an image or a piece of machinery.
It should be remembered we are looking at physical assets, a single item. The single item may be made of many parts, and these parts themselves may need to be recorded. The important part is that we should not lose track of the asset itself. A single entity that is uniquely recorded. It does not matter what location this unique asset is placed, what the asset is used for or who the asset is used by, as all of these are secondary and recorded as such.
If an asset moves, or is resold the asset itself still remains, the unique entity must not change because it is in location B instead of A.
Recording changeable information against an asset is the next important area. The information recorded could be anything from where it is located, a sale or rental price and period, or just that it has been maintained and checked. When developing new systems it should be considered where all key data is going to be recorded and utilise the sharing of common data where possible.
Again ease of use must be considered, the easier and clearer it is made to record data the cleaner and clearer the end result is.
Presenting the data
Ensuring clean and easy presentation of our data is crucial to the system being both accepted and used.
We have our assets and we have our recorded data against these assets. We have to make sure that the data can be found easily, and the results are clear.
Again there are many systems that present user interfaces and data in such a way, that the time it takes to actually find what you want becomes the downfall of the system. The majority of the time most of the data is irrelevant to the person enquiring about an asset, all they want is some small or basic information but instead are present with charts, data, and numbers cluttered onto a screen. Some of this data may be useful, but most will not.
By structuring the output and displaying only key information on initial result screens, it makes it easier for the user to identify the asset they want. Separating further data into key areas ensures that each page displayed is relevant to the users’ request.
It is also important to be able to extract the required data, whether this is required electronically or in printed format, the same applies, key relevant data that the user has requested, if this is the date due for the next MOT, then they do not need the last five years of repair data and similarly if a stock image of a red pepper is required, then those green peppers can be left where they are.
The user is key, they need to get the asset information they want from the system, quickly and easily, they only need relevant information and the need to be able to share, send, record and act on the information, ensuring this will also ensure the system is accepted and used to its full potential.