Asset information systems often don’t deliver a rate of return for the investment made in them. – here’s how to avoid the problem
In the public sector today, departments and asset portfolio owners display a wide range of approaches to the IT systems that manage their asset information. Although millions of dollars have been invested in asset management registries and information systems, the return on that investment is difficult to measure.
In this article, we look at three problems that prevent asset information systems, from reaching their performance expectations. We also suggest six steps to take in the planning stage that ensures readiness for asset system deployments. Let’s start with the key issues.
The system doesn’t meet the expectations of the users
Stakeholders have particular needs that they expect an asset information system to meet. For the financial controller it may be accurate reporting, for the asset manager it can be accessing accurate planning and performance data to support the asset management lifecycle; for the general manager it can be business performance reporting. Unless these business areas were consulted in the design stage, it’s unlikely that their needs will be met. The consultation stage should capture the needs of the users and produce a specification that is negotiated and approved by the steering group. This seems straightforward, but how well this is done depends on the maturity of the management culture and specifically, the asset management culture. As government organisations have been mandated[1] to have at least the asset registry to be in place early on in the organisation’s existence, basic implementations have been performed by organisations with an expectation that evolution will occur over time
There is no systems roadmap
The systems roadmap is a strategic plan that defines the milestones to reach mature systems implementation. It has usually been based on the discussion between the vendor and the customers about the capabilities of the product.
The roadmap informs the organisations when features will be available and allows departments to prioritise and budget for the features that they will need over time. A systems roadmap should be part of the supplier selection criteria to ensure that the IT platform will meet future needs. However, in many cases, the roadmap is not integrated into the IT platform planning process. This is often the case because there is little or no IT knowledge in the asset engineering department that is responsible for the selection of an IT platform and/or the culture of IT planning is not yet present in the organisation. Today, most asset management on-premise systems are being replaced by SaaS offerings as part of cloud enabled solutions. This ‘pay-as-you-go’ approach is easier for organisations to plan financially as the roadmap is templated, but assumes that the realisation of product value can always be achieved through application configuration, whereas application features may require integration with internal systems to deliver value; organisations should be rigorous about their core requirements, especially when it involves integration with key systems such as finance or service management.
Systems are implemented without adequate knowledge of the business requirements
Very often this stage is not performed to the level of diligence required due to time, cost or quality factors. In the public sector there are drives to improve the quality of project delivery through interventions by state departments[2] but for organisational systems, it’s usually deployed as an in-house project conducted by the IT department and the supplier, guided by a form of business requirement. In organisations where the technology platform is owned by the IT department and the applications and data is owned by engineering, a business analyst and data specialist in asset management is required to develop the needs analysis and align the requirements to the technology. The high cost of preparing a tender and setting up the bid procedures may outweigh the benefits and for many organisations, this activity is performed by engineering teams who substitute formal business analysis with engineering specifications. Where this occurs, other departments’ requirements are captured on a ‘best efforts’ basis and the business requirements are not systematically captured as part of the process. In some cases, the vendor will take on the role of the business analyst, in which case expertise in asset management is required
How could we do this better?
The next part of this article explains six steps that can be taken in the planning stage to avoid these problems occurring by applying the ISO 55000 asset management standard to the business context that surrounds an organisation’s assets. The ISO 55000 asset management standard is based on the principles Plan, Do, Check, Act and requires organisations to plan before acquiring systems and tools that support asset management activities. Here’s what needs to be done to avoid errors and rework.
1. Undertaking a maturity analysis
Treating the incoming IT platform as a tool that provides an output helps to contextualise its part in the asset management ecosystem. Undertaking a maturity analysis is the key activity at this stage to identify the information gaps that the system will address. Performing a maturity analysis allows consultation to take place across the whole stakeholder base to ensure that business needs are captured from all business functions and translated into formal requirements. The figure below shows the type of stakeholders that may be consulted.
Each of these groups will have different expectations of the system and will feed in their requirements throughout its lifecycle.
The stakeholder needs are captured in the Business Requirements Document. The value of this activity is not only that needs have been captured, but that discussions about priority have begun, which will impact the budgeting and planning process that drives the system roadmap.
The gap analysis needs to include a summary of the existing and planned workflows showing how users will interact with the system.
2. Ensure line of sight between objectives
The alignment of the organisational objectives to the asset objectives is one of the most underrated aspects of asset management yet one of the most important business principles. Based on the premise that the ‘translation of strategic goals into tangible results’[3] is a desirable outcome, the principle is applied to assets to ensure transparency between the purpose of the assets and the goals of the organisation. The exercise of aligning organisational, service and asset objectives seems straightforward enough, yet for many organisations presents a significant challenge as it has never been applied as a first principle.
3. Develop a data specification
The other important step is the development of the data specification. This is prepared by the asset management team who specify what data is required from the assets. The data specification is an architectural view of what data needs to be captured across the lifecycle of the organisation’s assets and its development is part of the design specification of the asset management system. The data specification is based on the agreements between stakeholders about what information to collect from the asset classes for asset management and reporting and requires endorsement by the steering group. It is used as the template to define the requirements for existing and new data about the assets and is the go-to specification in all discussions about asset information. The figure below captures its purpose and relationship.
4. Map the specification to the asset classes
This step is often not performed or assumed completed. If missed, there is no logical data structure or organisation of data sources.
An asset class is a logical set of assets grouped around their characteristics and purpose. Each asset class has slightly different information requirements and will require different data points. The data specification captures the information requirements for the whole asset lifecycle. The specification drives suppliers, management, workforce, departments and state operators to clarify their expectations of the system. This enables the organisation to hold users and suppliers accountable to a set of business requirements. As these evolve, a change management team picks up new requirements and puts them through governance for implementation.
5. Identify the process workflows to manage the data throughout its lifecycle
Defining the operating environment for the asset management system[1] involves analysing the process workflows, management systems and skills that the organisation uses to support decision making. This is performed by a systems analyst who designs the “go-to” state that will be required for the system to perform. This should be developed prior to engaging suppliers and become part of the systems requirements specification that suppliers are sent during the bidding process. Systems analysis studies the existing system, identifies problems and interprets facts so that any hurdles that prevent the system reaching its objectives can be eliminated. To do this, adequate research must be done into the existing state of the systems, processes and skills and workflows. Changes identified are expressed as requirements and can be procedural, systems related and skills based. On many occasions, this is not completed by the time suppliers are engaged as the project milestones take centre stage because the deployment sequence has already started. Without this step, there is no traceability of how changes bring value to the organisation and no demonstration of how value will be achieved from the system. This step also provides a baseline record of performance against which a new target can be set, which enables continuous improvement.
The process is captured the figure below.
This approach ensures that the value required from the asset information system is defined prior to supplier engagement and the product selection is based on a jointly agreed set of business requirements.
6. Continuous improvement – set a baseline, set a target, deliver on the target
It’s common to defer continuous improvement activities to the later stages of the asset management system deployment. This compromises the development and operation of the system and the ability of the asset information system to achieve its roadmap objectives. Systems upgrades require uplifts in process and skills and for organisations that understand this, there is an opportunity to start immediately to identify performance shortfalls during the maturity analysis and set a baseline for improvement targets. Continuous improvement targets produce stepped increases in capability; unconstrained discussions about improvements combined with the review of the system roadmap makes sense if the organisation is working to a common set of business requirements.
What are we left with?
Listed below are some common assumptions that organisations make during the planning stages of an asset management system:
● We have the skills to configure the software in-house
● Let’s get the system in and then decide how to configure it
● We have 80% of our requirements documented, that should be enough
● We are already collecting some asset data, let’s just use that as the spec.
● It’s a flexible system that we can change once installed, it’ll be user driven from go live
● IT will provide a set of initial data fields and users will add as we go
● We can get rid of paper records and move to mobility solutions quickly
● We’ll develop the five-year functional roadmap when the system is in and working
● The vendor will support us through business integration
● We will identify technical and business support people when we are up and running
● Budget only covers IT platform implementation; staff will have to learn how to make it work once its up and running.
● Once implementation is completed, we won’t need a core team anymore
These assumptions are about in-house competence, system design, business requirements, data management, roadmap features, vendor capability and internal investment and relate to the three problems we have discussed. Very often organisations burn cash on the project before requirements are properly defined as early results tempt managers to early actions. Executing the planning stage thoroughly is fundamental to successful execution of the project.
[1] The Victorian Financial Management Act states that public agencies must have an asset registry to comply with the Standing Directions [2] VHHSBA has planning, delivery and oversight of state projects
[3] Aligning employees through line of sight – Boswell & Bingham 2006 https://www.researchgate.net/publication/4885335_Aligning_employees_through_line_of_sight/download