Asset management is firmly on the public sector agenda. Whilst some organisations may still only be in the initial planning stages, many have implemented software to support the processes necessary to manage their property assets effectively.

But experience shows that implementation of asset management systems is by no means straightforward within organisations such as local authorities. We have seen numerous situations where systems have been installed but not widely adopted; data has been collected initially but is not kept up to date; the set of data is not what is required for strategic asset management reporting, and so on.

However, all is not lost. It is normally straightforward to highlight why the organisation is not realising the benefits expected at the outset.

Firstly, it is unlikely to be the fault of the chosen asset management software package. There may be issues around the way the supplier has implemented the package but the software itself is not usually to blame. There are a number of leading packages on the market that have been developed to provide asset management functionality. Their software development is usually in response to government initiatives, changing statutory requirements and compliance regulations, i.e. the needs of their customers.

It is much more likely that the problem stems from the approach taken to defining what is needed and the overall implementation project. If that is the case, there is no need to throw away the software. What is required is a re-evaluation of the most important requirements and a revalidation of the software to identify any gaps. This will inform the extent to which re-implementation may be required.

There are some important factors to consider, and these apply equally whether an organisation is first implementing, or re-validating (and potentially re-implementing) asset management software;

1. Whilst there are excellent guidelines publicly available that suggest what data needs to be recorded for asset management purposes, each organisation needs to consider its own requirements in detail.

2. The asset management software package must be considered in the context of the organisation's overall software application architecture.

3. The system implementation is likely to form part of a wider change project. Taking the first point, as with any business database system, the reporting and data requirements and the business processes will be the prime determinants of what is expected of the systems.

Reporting analysis

It is useful to adopt a top down approach to analyse the reporting and data requirements specific to the organisation because property strategy will be driven by the organisation's corporate and service strategies. By considering the objectives and goals of the property strategy with other factors such as, for example, the types of property within the portfolio, the organisation can quickly:
identify the key performance indicators it needs to monitor its actions and report at the highest level,
establish the information it requires for its options analysis processes, and
identify the lower level management reports it needs to manage the assets.

It is also vital to consider the format in which the information should be reported; there are likely to be many different stakeholders to satisfy.

Once specific reporting requirements have been established, they can be incorporated with other more generic reporting such as statutory, compliance, and benchmarking requirements. The combined set can then be analysed to determine what data the organisation actually needs to capture as part of the asset management system.

Business process

At the same time, it is necessary to understand and model the processes undertaken as part of the asset management business. Of course, this will be a significant challenge in an organisation such as a local authority where property is often managed by various decentralised teams in different services, each probably operating in its own informal way. However, the benefits of making the definition of the business processes a mandatory part of this approach to systems are significant. In addition to developing a thorough understanding of the business requirements and priorities, this exercise also provides the base against which to consider the validity of the structure, roles and capabilities within the organisation's asset management team.

The business process definition will identify the system processing requirements and further data requirements, and will be useful to cross-check that the data defined through the top down analysis of reporting is actually collected, recorded, and maintained ongoing in an identified business process. Make sure it is clear who owns and is responsible for each type of data. Of course, you may well ask yourself whether a process that does not contribute to providing data for the identified reporting is really required at all.

Integration

Having established the "functional specification", the challenge is to make sure that the asset management software chosen is properly integrated within the organisations' existing environment. This brings us to our second key factor to consider - that the chosen asset management software and plan for implementation must take account of the application systems already within the organisation.

We would expect the specification stage to have identified a wide range of data that will need to be recorded to provide the asset management reporting. Ideally, all this data would reside in a single system and there would be no need for any links or interfaces.

In reality, this is unlikely to be the case. Whilst the specialist asset management software packages are becoming more functional and may be able to hold a wide range of data, one can envisage a range of operational systems that will not be replaced by an asset management package. These may include;
Corporate finance system
Land & Property Terrier
Energy Management
Project Control
Human Resources

The overall objective is to ensure that data only needs to be entered once, and that it is maintained consistently, and as far as possible automatically, across the various systems where is has to be physically duplicated.

These systems will need to be linked together logically by a common asset coding structure. This may actually be related to the Basic Land & Property Unit (BLPU), the source of which will be the organisation's LLPG gazetteer (therefore another potential system link!) The implementation planning will need to consider where automatic interfaces are required between the various systems. This will almost certainly involve bespoke system work, so do not under-estimate the cost or complexity.

Potentially, additional software will be required to provide the consolidated asset management reports that draw on data from the various systems. Interestingly, there are some products aimed at local authorities designed specifically to facilitate the reporting of Key Performance Indicators.

An overriding constraint may be the organisation's corporate policy for applications, particularly when an Enterprise Resource Planning (ERP) strategy has been adopted. This will probably dictate that as much of the asset management functionality as possible will be shoe-horned into the ERP and the critical bits that it cannot do will need to be developed. However, integration between various modules should be less of a problem.

Implementation

Finally, the asset management system will not be successfully implemented unless the organisation is prepared to commit appropriate resources to the initiative, both during the implementation and thereafter. It is likely the introduction of the system will need to be carefully managed in line with changes to the asset management processes, organisational structure and roles.

Crucial to the project will be the buy-in of those senior stakeholders who will need to allocate resources from their teams and potentially make changes to their mode of operation over time in response to the business process definition work. That means that the benefits and imperatives must be articulated clearly, and the resolve of the senior sponsor must be strong. If this is a project to revitalise an existing system, the work required may look daunting and very similar to starting again from scratch; however, good information systems should significantly ease the day to day burden of the asset management team.

The difference between success and failure in a systems project is to concentrate on these business benefits from the start and keep focused on how the system will help the team improve its work.

by Mark Jones
a Partner in Remit Consulting LLP

 
Copyright Remitconsulting © 2004     Disclaimer     Top of Page