Centralization of information systems is a common strategy to reduce overheads by allowing shared services to be reused across disparate business units and projects. But this presents a challenge in these services in terms of meeting the diverse needs of all projects in a large organization. While there may be efficiencies in centralization, what is the true cost? Asset inspection activities can highlight some of the issues of information system centralization and how they can be managed.

The nature of standardization on central systems is that blanket policies are defined based on the minimum inspection requirements of all systems, the example being the inspection points and activities for an asset to manage its performance. In effect, these “minimum requirements” are the most stringent requirements of all projects applied across all projects. This creates overhead as staff on these projects either comply with these additional requirements or invent ways to work around them. Project staff will use IT systems according to their requirements rather than the intended use of other projects. Shoehorning systems into processes that don’t fit has a significant impact on auditability as data entry fields are not used for consistent purposes. This removes the ability to compare performance metrics across projects and systems.

While some may say disparate systems have the same restrictions, it is at least accepted that data migration is required for analysis as opposed to the false sense of security a single system used for different purposes provides.

This is the source of the true cost of centralization—systems designed to improve onsite efficiency and compliance see their expected returns eroded through a poor match to the site requirements. Rather than facilitating the work being completed, the system requires additional effort from site staff in its daily use. These costs are experienced throughout the project life cycle.

Requirements analysis

Initial requirements analysis can be challenging as gaps emerge between the system and the realities of the site. Process standardization is one thing, but people do not respond constructively to the need to change the way they work because “that’s how the new system functions.” This part of the project often sets the stage for the implementation and rollout of the system. The level of user engagement or resistance will be determined by stakeholder engagement and buy-in at the initial requirements stage.

On completion of the requirements analysis there are often gaps that require further work. These are closed individually, either through customization or through change management; the system is made to match the process and the process is made to match the system. Unfortunately, the latter is more common when adhering to central IT decisions. This also tends to include substantial compromises in system capability and technology.

Centralized strategies are slow-moving since there is a great deal of inertia in larger systems. System needs are reviewed and defined, often as part of a six-month project. A set of vendors is engaged and one selected, taking another three months. An initial implementation is completed for a single project, including detailed requirements review and site rollout. This often takes up to two years. The results are then reviewed to determine the return on investment of the project and the implementation success, completed up to one year after go-live. If they are favorable, the solution becomes the corporate standard and is either retro-fitted to existing projects or put on the shelf as corporate standard methodology. At this point, the technology is three years old, and the requirements match is nearing four. With that level of investment, reviews may not come for 10 years. The net of this is that as the implementation commences on a new project, the technology is obsolete before go-live for systems with an expected life of up to 10 years.

Cost of overhead

Training and change management require a greater effort as it isn’t simply the extension and improvement of the existing site process. It can also be a vast change implementing constraints of the central system not relevant to the project or, in some instances, the organization itself. Initial rollout of the system often takes longer as the change management requirements increase. This erodes the initial returns of the system as only a portion of the users are rolled out during the initial phases. There is also an increase in the upfront costs as project staff need to be retained for the duration of the implementation cycle and, in many cases, all licenses, software and infrastructure for the system have been paid for up front.

While the impact of compromises and technology mismatches are seen to diminish at full deployment, the cost overheads remain. As with any system used outside its original design, there is often additional technology and process overhead in its use. This creates additional maintenance requirements and impedes process efficiency, eroding the returns expected from the business case.

Local decisions

Localized IT decision-making allows for a far more agile approach to technology and system selection. Assessments can be made comparing current technology to current requirements and ensuring a greater functional match and reduced limitations. Since the local project team makes the decisions, there is a far greater sense of ownership of the new system, driving a higher level of user acceptance.

Centralized decisions are made due to the need for adherence to standards around security and manageability. These goals can also be achieved through localized decisions and don’t require centralization of all systems. Adequate guidance on standards can ensure consistency and policy adherence; however, this needs to be pragmatic and not impact the ability to implement the required business functions. Collaboration with local decision-makers on IT standards can ensure that these standards are met rather than subverted. This is not distinct to distributed IT decision-making but rather a requirement for all IT endeavors. In addition to this, security requirements can be facilitated by the separation of responsibilities of business applications from IT infrastructure. All infrastructure architectures and projects can be managed as a central service, with business applications implemented on standardized infrastructure. This can include private networking, local and remote, fixed and wireless, and standardized hosting options meeting all availability and disaster recovery requirements.

Returning to the asset inspection example, we can see how this can be implemented. Local project requirements can be reviewed and vendors engaged. Systems can then be designed according to requirements of the project, including accounting for a high level of process variability across a range of sites. An example of this is the large number of wells common in unconventional energy projects. Hardware technology can be chosen based on current capabilities, and corporate standards can guide the choice of these technologies based on security and manageability requirements. The project is then implemented on standardized infrastructure.

While core infrastructure and security standards are (and should be) defined centrally, the nature of business systems dictates a higher level of end-user engagement. This is not always possible with central IT decisions, and as the complexity of the business process increases, so does the need for decisions on these systems to be left in the hands of those responsible for the processes themselves. Centralization may seem to reduce costs, but this is achieved at the expense of process efficiencies justifying the implementation of these systems.

Comments