What must the system do?

Themes: Processes review; Opportunity analysis; Functional specifications; ITS application potential; Anticipated benefits

The ITS project is an opportunity to transform the business

Having decided strategic requirements and the tactical response, the next step is to describe in detail how this will be implemented. This is more fundamental than just describing what the ITS equipment itself is required to do. It must begin with a thorough understanding and review of the organisational structure, the business processes, and the operational processes within which the ITS system will sit.

ITS systems are very powerful and potentially business-changing tools. However, two of the greatest and repeated failings of ITS deployment are:

a) systems are designed from the outset to replicate much of how things were done previously

b) insufficient attention (if any) is given to changing the organisational structures and processes

The consequences are that on one hand it misses out the real benefits that the ITS can bring, while on the other it constrains the ITS for the future and leaves it with legacy inefficiencies.

What approach should I take?

Good practice is to carry out the following steps:

Carry out a full process review for all of the functional areas within the scope of the ITS analysis
Carry out an Opportunity Analysis to see where and how these processes and their organisational structures could be improved
Define all new and amended processes
Develop the functional specification for the ITS, with clear linkages between the processes and the ITS functions
Define the Operating Procedures

This stage may be part of an iterative process, where the full technical, cost, deployment and use implications only become clear in later stages. It may then be necessary to revisit initial approaches, either to broaden the scope as a better understanding of the ITS emerges, or to become more pragmatic as cost and/or technical limitations become clearer.

Carry out a Process Review

A Process Review should be undertaken as a first step, and should cover all of the functional areas covered by the ITS analysis. The scope would cover:

Map out the host Organisation for the foreseen ITS, in particular the units that host, support and are in any way impacted by the ITS
Identify all relevant business, operational and administrative processes in the foreseen ITS host environment (e.g. vehicle and crew scheduling, dispatching, ...), or potentially impacted by it
Describe how these processes are currently performed, including by whom and what information is generated
Identify linkages, information flows and dependencies between processes
Identify known weaknesses and limitations of current processes

There are three main reasons to carry out this activity at such an early stage:

The processes descriptions will be required at various stages downstream
Adjustments to Processes must be determined in advance of the detailed ITS specification, otherwise it may be difficult and costly to adjust them later
The processes to be supported by the ITS must be correctly described, otherwise the ITS systems are unlikely to be optimally aligned with the processes they should support

Opportunity Analysis - get more from your ITS system

The Opportunity Analysis is the key value-adding phase of the entire process, although it is often missed or poorly performed.

This is the phase where the stakeholders identify what will be done differently when the ITS is in place. This identifies the opportunities for improved costs, revenues, quality, customer perception and organisational capacity. Most significantly, it is not limited to the technology aspects, and considers all aspects of the organisation, operation and business. It may include, for all of the processes covered by the scope of the analysis:

Changes to overall Process structure, and rebalancing among processes
Addition of new Processes
Redesign of Processes
(Partial) automation of processes
New/enhanced internal products, services and applications
New/enhanced customer-facing products, services and applications
New/enhanced interfaces with external entities (e.g. traffic control centre, other transport operators, passenger information agency, fares and ticketing agency)
…

One of the most important aspects here is to properly understand the opportunities for fresh starts. It is essential to avoid “locking in” past weakness and inefficiencies by requiring the new technologies to simply do things the same way as in the pre-technology phase.

Additional Factors to Consider

Consideration should also be given to the following additional factors, both in this step and in subsequent steps in the Design and Implementation phases. Even if they are not current issues at the time of the initial ITS project, it is highly likely that one or more of them will become relevant at a later stage post-deployment.

Harmonisation of ITS systems and services between the urban / metropolitan area and the hinterland. ITS systems and the services they support (e.g. ticketing, passenger information, traffic signal priority) are often first implemented in the core urban or metropolitan area. At a later stage, it may be desired to extend the system or service to the neighbouring areas, to the general hinterland, or to a set of other areas. Alternatively, if the neighbouring areas have their own systems, it may be desired to harmonise the various systems to support interoperability across the wider area. It is important to foresee these possibilities from the outset, as there may be serious cost or technical barriers to interoperability if the systems are designed independently.

Integration or interfacing with other systems. The ITS system or services will need to interact with other ITS systems, within the organisation, at other organisations in the same area (e.g. of other operators, the traffic system), and in other areas (see previous point). In some cases, it may be necessary to have full integration in which the technical systems need to work closely with each other and must be designed in a similar way. In other cases, the systems simply need to exchange information in as common way (to "interface"), but otherwise can be completely independent of each other. Integration is more technically demanding than interfacing, and is far more difficult and expensive to do retrospectively after deployment. While this is a technical issue to be resolved in the Design stage, it is important to identify the current and future requirements during the Planning stage.

Alternative business models. Traditionally all ITS for urban public transport has been installed and operated in-house by the trandprot authorities and transport operators. There is an increasing trend towards alternative business models. These include outsourcing the operation, management and maintenance of the ITS systems or services. In some cases, there are various forms of public-private partnership (PPP) in which a private firm or consortium finances and provides the ITS system or service. The private sector provider is then either paid for the service by the authority or operator, or recovers the investment cost through a portion of the system income (e.g. for ticketing systems) or through user charges (e.g. for passenger information systems). Even if there are no immediate plans to use such alternative business models, it may become government policy to do so (e.g. in case of reformed public procurement policy). It is prudent to make provision for these potential opportunities and to at least ensure that unintended barriers are avoided.

Develop the Functional Specifications

When there is a clear understanding and sufficient consensus on what the organisation needs to do, and the processes through which the organisation will achieve its mission, then the Functional Specifications for the ITS can be developed.

Functional Specifications are a detailed description of the processes and what the system and its components are expected to do. Principles for developing Functional Specifications include:

Functional Specifications describe in detail how the processes work (or should work), and should cover all options and eventualities. This is the fundamental reference framework for the technology suppliers and designers.
Full consideration must be given to the organisational and operational context and procedures. If these do not form an explicit part of the Functional Specification, then they should be described in parallel documentation.
Incompleteness, inconsistency or ambiguity must be avoided. They will cause problems downstream, either requiring ad-hoc responses, or the suppliers/designers may resolve things their own way, leading to unexpected and insufficient functionality
The end-users of the various systems and applications must be deeply involved in the process – ideally as authors, otherwise as reviewers.
The focus is on what the system must do and not on how the system does it
Unless absolutely necessary and firm decisions have been taken and thought through, the Functional Specification should not specify the technology approach, and should not limit the technical options.
If Functional Specifications for similar systems in other locations are being used as good practice reference models, care must be taken to avoid a “cut and paste” approach

Three linked layers of documentation would normally be developed, which progressively operationalize the ITS system from an initial concept through to a usable system:

Statement of User Requirements
Functional Specification(s)
Operating Procedures

The potential for ITS to meet and support the User Requirements and the Functional Specification would be done in a parallel and iterative process. The ITS should respond rather than lead, but a clear understanding of the opportunities and limitations of ITS technologies and applications is required, and the Functional Specifications cannot be detailed without at least a conceptual description of the ITS.

Estimate the Anticipated Benefits of the ITS project

The Anticipated Benefits of the ITS systems and applications should be identified at this stage, even if they are not quantified until a later stage. Such benefits may include:

Improved service quality
Reduced penalties for failure to achieve quality targets; or, increased bonuses and service payments
Savings in Operating Cost
Reduced requirements for supervisory staff
Reduced fleet requirement (capital cost)
Reduced requirements for reserve fleet/crews
Improved route and sectional journey times for scheduling
Faster response time to emergencies, accidents and incidents
Reduced service disruption due to breakdowns with the help of vehicle and engine condition sensors
Real-time travel information for passengers
Cost savings and error elimination due to automated generation and analysis of data, and transfer to other ITS and support systems