Clean Bill of Financial Health for Telecoms May Cause Serious Illness

Ghost-written article for Cisco Systems EMEA.
Published in TM Forum magazine, UK, October 2003.

Why - because profits without effort will encourage the average network operator to expand the organisation instead of improving it. If the last few years have taught us anything about network operators, it’s that they are not best prepared to cope with adversity. Yes, a global economic downturn has obviously affected all vertical sectors including telecoms, but the temptation is to use this externally as the cause when there are more inherent problems at play. Internally, IT is often the scapegoat. It’s not surprising that management remain reticent when substantial investments in technology fail to deliver the return or savings expected. At the core of all this IT is the organisation’s operational support system, or OSS – it’s heart, lungs and central nervous system combined. Improving the OSS – the way an organisation lives, breathes and does business day-to-day rather than tinkering with peripheral things is the way to reduce costs and improve overall health. However, not all network providers realise this, or are more concerned with the technology they provide than how they provide it. Furthermore, even those that do recognise this fact have yet to learn that organisation-wide ‘surgery’ of this nature should not be taken lightly.

Cure the Cause, Not the Symptom
Two key things are needed – firstly a thoughtful yet practical approach to OSS that deals with the organisation as a whole. A surgeon cannot help a patient by mending a broken leg and a dislocated shoulder, without also considering the circulation that keeps both functioning. The same applies to management trying to improve the organisation by taking each division, management layer or IT ‘limb’ in turn – neither humans nor organisations work that way. Where internal problems are concerned, examining the OSS rather than one part of the business may well reveal that the information all other IT or business systems are reliant on is flawed. Perhaps the way in which information is recorded should be reviewed, the way departments work together, or the way information moves from department to department – maybe all three.

Whatever the case, seeking the quick fix is easier to stomach when the unwelcome prognosis is that there is no such thing, no ‘silver bullet’, or single detail escaping everyone that can be tweaked as a panacea. The quest for the quick fix leads to constant fire fighting, with budget being splintered to attend to many problems occurring one after the other.

Those problems may not be internal flaws but external factors. Difficulties encountered by organisations we advise include: changes in regulatory environment; consolidating, converging or going global; maintaining margins during downturn; and protecting market position against new entrants and new business models. However, the more robust an organisation’s OSS, the better it will cope with unforeseen circumstances. One cannot predict the next bout of flu, but can be physically fit to cope with it when it arrives.

Regardless of the nature of the problem, the second consideration is that tinkering with an organisation’s OSS should not be underestimated. It is the business equivalent of neurosurgery, potentially a fundamental change to the way that every individual in the organisation uses their working time. Samuel Johnson was neither a surgeon nor a telecoms businessman, but he still recognised that, “Change is not made without inconvenience, even from worse to better”. More than a century later, Dr. Bernard Burnes, researcher, lecturer, and head of the Operations Management Group at the University of Manchester Institute of Science & Technology, said of organisational change, “In cases where staff are required to keep up the same level of output during the transition phase, it may require additional resources to achieve this...Nothing is guaranteed to be more demoralising than having to make changes without the necessary resources or support”. When you accept that improving an organisations OSS will deliver improvements throughout the business and decide to do it, then adequate preparation is needed.

Prepare the Surgeon, and the Patient
Before any plans are made let alone implemented, consider that fundamental organisational change needs a budget of its own – not for OSS software, for kit, or anything else – for the change itself. Overtime will be incurred, mistakes or teething problems will be unavoidable, and as a result, resources will be used. The twin necessity to a financial budget is the need to allocate time for the change. You are changing something that has an impact on every employee in the organisation, and doing your best to prevent people outside the organisation feeling any adverse affects, or even noticing. That takes time, and the people implementing the change or being affected by it cannot be expected to cope in addition to fulfilling their usual responsibilities. The other consideration where time is concerned is to plan the change over weeks or months, with realistic deadlines and a way to measure progress. These may need to be adjusted as the organisation encounters problems, but a sure-fire way to ensure something never gets done is to label it ‘ASAP’.

Communicating the importance of the change internally can increase likelihood of success. Appoint an internal change management team, whose sole responsibility for the duration of the project is to ensure that things go smoothly and on time. Use representatives from all parts of the organisation involved and from mixed hierarchical levels, and foster an environment of respect but without bureaucracy, as in Edward de Bono’s theory on brainstorming. Everyone’s experience will be needed, and if concerns or ideas are not aired or overruled then the change will not be embraced.

Anyone attempting to fly British Airways on 18th June 2003 will have borne witness to the result of failure to consider, prepare and provide time to employees for significant OSS changes. Unfortunately there is a tendency for management to veer from one extreme to another – either the ‘fluffy’, people-oriented style, or intense, task-oriented style where the product or service is all, no matter what your staff turnover rate is. There is no simple way to decide what approach to take except to say that it will be closer to the middle than at either end. Accurate consideration of the participants of OSS change will help diagnose where the organisation is now, and where it needs to be. However, this is not the only reason for preparation before embarking on change. Changes to an organisation’s OSS are both time-critical and fraught with danger. To use the metaphor again, a surgeon will progress both methodically and quickly – and a lack of the necessary care or speed will end the same way. If the organisation were still based on paper, pens and copper wire, change might be approached more carefully. The fact that these have been replaced by IT and fibre optic cable does not necessarily make OSS change easier, only different.

The Recovery Room
‘Perpetual change’ seems to be where everyone is headed – a style of work where nothing is permanent and a dynamic organisation can respond quickly to any external factor. As an organisational state, perpetual change in consulting lingo has its roots almost a decade ago, triggered at the time by academic study of managerial steps taken by Nissan and Volvo in the automotive sector. That is not to say that network providers will be able to learn from their experience without suffering some of the same difficulties. Only this year, AT Kearney surveyed almost 300 European organisations in various sectors that had completed a business change programme. Only 20 per cent of those 300 were found to be successful. Regardless of the outcome and whether or not perpetual change is where you want to be, it is essential that both management and employees be given some time to recover from organisational change where OSS is concerned.

It is human nature to hoard information for coercive power, to build empires, and play politics. No amount of IT spend will change that. However, successful change is possible if it is considered and planned appropriately, and where else can network operators make an operational and cultural change more effectively than with the organisation’s OSS, the system on which the rest of the business depends? Let us hope that a temporary improvement of finances in the telecoms sector does not mean essential surgery is postponed any longer.

Thales e-Security Takes BACS to the Future

Case study written for Thales, UK, July 2003.

The key issue associated with making financial payments electronically is security, whether simple transactions between two parties via debit or credit card, or payment via the internet. ‘Skimming’ of consumers’ credit cards in restaurants and other retail outlets, misdirected payments via the internet, and fraud on a much grander scale are all issues that have hit the headlines this year alone. The responsibility for securing such payments, whatever the size, is a daunting task for any individual or organisation. Imagine then, undertaking to supply the security solution to the Bankers Automated Clearing System (BACS).

BACS is the organisation - owned by all the major UK clearing banks and building societies - that processes the majority of business-related electronic funds transfers in the UK. For example, every month businesses in the UK perform the payroll operations for their personnel, triggering thousands of money transfers as staff salaries are paid directly into their bank accounts. This is just part of what BACS does and by the end of the year, BACS will have processed more than 14,400,000,000 direct debit and direct credit payments on behalf of over 100,000 UK businesses.

With such an important system there is no margin for error, given that any difficulties could potentially affect all UK businesses. It is therefore great testimony to BACS that its payment delivery system, BACSTEL, has been almost 100 per cent reliable since its inception more than two decades ago. However, by early 2002, the BACS board had concluded that the BACSTEL infrastructure should be upgraded as the first stage of a comprehensive technology upgrade plan for all BACS systems. In 2002 BACS migrated BACSTEL’s infrastructure to run on internet protocol (IP), enabling BACS to offer a wider range of services to business users, as well as an improvement in existing services. These services would lead to cost savings for the UK businesses that used BACSTEL-IP, and with the flexibility of IP, would make it much quicker and easier to incorporate new payment services in the future.

However, BACSTEL-IP had to be secure, as the sheer quantity of payments and sums of money on the system made security critical. Further, the security solution had to fulfil a number of criteria in addition to simply authenticating UK businesses as they accessed the system. It had to be able to trace all the transactions made on the system if needed, and secondly for every transaction it needed to produce an audit trail. The size of the project also made it daunting – the solution had to be able to scale to a total of 500,000 users and up to 100 million payment items per day. Perhaps most complex of all, it would have to interoperate with 12 banks, operating seven different public key infrastructure (PKI) systems with five different smart card manufacturers. BACS called on Thales e-Security to help them secure the future of UK business electronic payments.

Thales e-Security’s implementation of the project was a true team effort. The Thales e-Security project team worked closely with the other vendors involved, as well as the BACS technical design and implementation teams, throughout the development cycle. This minimised the project risk, and ensured successful on-time delivery of the complete solution. BACS’ project security team had already recommended using smart cards to enable the solution. Once approved by the member banks and BACS senior management, the project was trialed with Royal Bank of Scotland for four months before being rolled out to all other member banks in the UK. Hardware and Thales software was installed around the UK by BACS approved solution suppliers.

In order to support the simultaneous connection to 12 banks required by BACSTEL-IP, Thales e-Security worked closely with BACS to develop the fourth generation of its digital signature messaging system, AssureTransaction. UK businesses wishing to organise payments via BACSTEL-IP from their office are issued the cryptographic smart card by their bank. That smart card is then used to digitally authenticate all payment instructions, tying them to the signer and ensuring that they cannot be accidentally or deliberately altered. Each bank was given the flexibility to select its own public key infrastructure (PKI) for the issuing of the digital certificates used on this card.

AssureTransaction ensures compatibility with all relevant PKI standards by verifying each transaction against the set of rules defined by the bank that issued the smart card being used to sign the transaction. It authenticates the smart card holder by generating a random number. The cardholder responds by signing the logon challenge using the smart card together with his or her secret PIN, a so-called two-factor authentication. AssureTransaction then cryptographically confirms the identity against the cardholder’s public key certificate, and validates this in real time with the issuing bank. Similarly, all payment requests and other transactions submitted to BACS are digitally signed by the user with his smart card and PIN, and verified in real time. AssureTransaction also digitally signs the reports sent by BACS to users, so that the user knows he or she can rely on the contents of the report.

Since all digital certificates used are verified in real time against the issuing bank, lost or stolen cards cannot be used to sign transactions, and changes in employee status are reflected in the system as soon as the bank is made aware of them. This substantially reduces the risk of fraud compared to the old system. Varying levels of security access are supported for different personnel working in the banks or businesses using the system.

After the system had been rolled out, BACS surveyed its member banks for their opinion on the new technology and its impact on their business. The results were very promising. Over 75 per cent of users expressed the intention to migrate to the new solution as soon as it was available to them. In the same survey, users rated the enhanced security of the new system the number one benefit to their business. Users particularly valued the ability to tightly define payment permissions for individuals in the business, allowing delegation of signing responsibility to specific cardholders within subsidiaries or departments whilst retaining full control at a corporate level. All in all, the feedback was so positive that BACS now intends to work again with Thales e-Security to develop and implement further service enhancements in the future.

Salmon Helps PRI Swim Upstream

PR case study written for Salmon, July 2003.

The founders of PRI, one of the latest start-up companies to enter the UK and European insurance market, needed to achieve the impossible. Not only did they need to secure £130 million in funding from investors before a tangible company even existed, they also planned to use a new insurance underwriting application that was more advanced than any other available in the market, and would shake up the way that underwriting business was conducted.

This underwriting application would allow PRI to gain a significant competitive advantage, and also underpin the business model PRI wrote to engender a favourable impression from two key audiences. The first audience would be the potential investors in the company, and the second the Financial Services Authority (FSA), who had the power to offer or decline PRI’s accreditation and thus would decide whether or not PRI could legally trade once it was up-and-running. Within one year of trading PRI was so successful that it was snapped up by Brit, one of the UK’s largest insurance organisations, giving all PRI shareholders a healthy profit and demonstrating that such a complex application could be written from scratch, installed, and used to deliver return on investment within eight months.

In Spring 2002, founders Andreas Loucaides (now CEO) and Peter Matson (now Chief Underwriting Director) developed a radical new business case for a new insurance company. They intended to outsource absolutely everything possible, leaving only the specialised skill sets of professional underwriters untouched. While on paper this was recognised as being the ideal model, it relied upon back office operation, which was an integral part of the infrastructure that contributed to the stability and credibility of the company. This would be critical when Loucaides et al presented to the various financial institutions to secure investment, and later had to apply to the FSA for accreditation. It also had an impact on which organisation PRI would choose to outsource to, because its reputation and brand values would be considered crucial factors in determining PRI’s likelihood of success.

The outsourcing brief was won by the Ins-sure Services operating company, part of Xchanging, a business process outsourcing (BPO) organisation. Ins-sure accepted that everything including PRI’s office premises, furniture, fittings, and IT infrastructure would be outsourced to them. In turn, Xchanging put out to competitive tender the building of the underwriting application that was to be a crucial element in the overall integrated insurance system that Xchanging was offering to PRI. With its proven track record of delivering complex projects on time and to budget, Xchanging chose Salmon, a systems integration organisation, to build the underwriting application. Louciades explains, “By this time the investors also had a say in which organisation was chosen. They agreed that Salmon would be the right company to go with in addition to being more cost-effective than a previous company we had approached, but which was unable to deliver the required guarantees for service. The pressure was on, because PRI still had to be operational and trading no later than 1st September 2002, so we chose to use a temporary solution until January 2003 to allow Salmon enough time to deliver exactly what we needed. From the outset Salmon was very honest and transparent about delivering on time and to budget, which was important for us.”

Salmon’s work was to be the cornerstone to Xchanging’s outsourcing deal with PRI. Every insurance company has to have an insurance underwriting operational system that is relevant to all markets the company operates in, and compatible with the other applications. “It was critical that the application Salmon designed would enable us to deliver services to the standard we intended, given our revenue projections in the business case,” explains Louciades. “For example, without Salmon, debit notes and broker notes would have to be produced in another way, which adds time and administration into the underwriters’ day-to-day processes. The underwriting application would have an impact on every part of our business. This is why our investors had also expressed concerns that in the past, other insurance companies had underestimated the importance of this part of the business to the extent that it developed into a serious weakness over time.”

Within just nine months, Salmon delivered the underwriting application on time and to budget. Among the most significant hurdles that Salmon had to overcome was defining the application brief. Simon Ball, Salmon’s commercial director, explains: “Louciades is a visionary who intended PRI’s way of working to have beneficial long-term impact on underwriting in the UK. However, because the underwriting status quo hadn’t been challenged in years, PRI was more able to describe the shortcomings of the current system than the ideal new system. As a result, the application brief was defined over a longer period and almost by a process of elimination, during which we realised the work we were doing was going to be perceived as controversial by the insurance industry. Underwriters would be held more accountable for the work they did, and our application would record all the complex detail of every underwriting contract, to prevent issues caused by claims made by PRI’s clients in the future.”

This was also to be part of the challenge for Louciades. “The brief we gave Salmon meant they would come up with an application unlike any other,” he says. “Furthermore, it required slightly more of the individual underwriter’s time to use it, because it encouraged the recording of as much data as possible. We wanted to be able to maintain business continuity over decades regardless of which underwriters dealt with a particular contract in the future. Additionally we could see that the FSA and issues such as corporate social responsibility were going to play a role in shaping the insurance industry sooner rather than later. That said, user buy-in of the application was essential because the data inputted would later be cross-referenced alone and with other business applications. This would end up as part of the overall information management that would help deliver PRI’s competitive advantage. The fact that all information was stored in soft copy was also going to save PRI thousands of pounds in physical storage space. The application just had to work, or the business case put to both the investors and the FSA would unravel.”

Salmon had to bear all this in mind while writing the application that broke the mould for underwriting systems. However, Salmon’s multi-sector experience gave it an objective stance that perfectly complemented PRI’s visionary aims. A prime example of this was Salmon’s ability to deliver a web-based architecture as opposed to the standard client server based applications that are prevalent throughout the insurance sector. While some insurance firms might have a GUI front end, Salmon was able to deliver an advanced Java based architecture which few SIs in the insurance sector have experience of implementing.

It was paramount that Salmon delivered on all its promises at the soonest opportunity. This included breaking insurance sector history by devising a way to link the application directly to PRI’s document repository i.e. document management system, delivered by Xchanging. This was part of the automation Salmon built into the business processes required by the application, to compensate for the fact that underwriters charged by time and could afford to spend fewer hours with smaller underwriting projects. At the same time it would make PRI as a business more accurate, more accountable and more dynamic by enabling appropriate levels of information recording and sharing.

Weekly liaison between Salmon, Xchanging and PRI enabled a better understanding of the needs of the business, and the delivery of a complex yet user-friendly application. Underwriters populated the system the first time they logged on with a unique user ID and password, ensuring that initial access of the system was staggered, thereby avoiding any potential bottlenecks in data retrieval. They have freedom to customise the style and format of their individual GUI, but are governed by rules set in the system that dictate which information each individual has access to. Each underwriter is allocated an ‘identifier’ that associates them with a particular client company or companies, enabling free navigation of all necessary information for that company but simultaneously prohibiting access into other client company information. The system also automatically enforces varying levels of security access, so that authority for particular actions or documents is escalated to the appropriate level of management hierarchy. Similarly, each underwriter can customise document production and automated quotations, but only within parameters set at company level to ensure all necessary rules and regulations are adhered to. The system either displays an appropriate error message, or automatically logs out any user attempting to exceed their authority.

Individual underwriting documents are developed from a PDF or Microsoft Word template that automatically specifies field content and business actions the underwriter needs to complete. Paragraphs of copy are saved in a central repository that can be accessed by underwriters from different parts of the business, preventing unnecessary duplication of information that, if left unchecked, would use a disproportionately large quantity of storage space. The copy is stored in rich-text format to make it as flexible as possible and, because it is held centrally, can be updated in line with changes in legislation that affect the UK insurance market.

Perhaps the part of the application delivered by Salmon that had the most impact is the quotation rules engine. This helps underwriters develop project quotations almost automatically, by inviting as many details as possible to be inputted by the underwriter, before applying XML-based rules to any given situation to form the quotation.

The application’s computer architecture is based on J2EE standards for web applications written in Java, and both the data and application run on Sun Solaris central application servers using Oracle web server software. The modular application framework means that PRI can have system components added or removed without the need for reworking, and new software can be deployed easily. Again, this ensures rapid reaction to new legislation. In all, Salmon delivered a revolutionary application within nine months from a standing start.

Airport Integration – Mission Impossible?

Ghost-written for John Jarrell, vice president and general manager, SITA Airport Services.
Published in Airports International magazine, July 2002.

When you talk to most people about airport integration their eyes quickly glaze over and attention wanders to the game on TV last night or their next appointment. Ask for a concise definition and you are likely to get a different answer depending on whom you ask. The result is that for many across our industry airport integration remains a distant dream.

Over several years of working with all levels of airport management I developed a presentation that explains the main principles by transposing the issues faced in an airport with those of a film director aiming to deliver the next Hollywood blockbuster. A highly edited version is given below.

How many times have airport operators had all their labour saving IT systems running, but wondered why the special effects they are expecting resemble South Park rather than Jurassic Park? While the individual applications appear to work well enough, something is lacking.

In terms of time, integration feels like the Ben Hur of tasks, and in terms of cost it makes a biblical epic seem like a home video. It may not be a case of your CUTE not being quite cute enough, or your BRS being irreconcilable, but that many airport operators are letting their primadonna applications run the show as independently as Liz Taylor and Richard Burton during a tantrum. However, at least five of the main applications can be integrated to work in harmony for the benefit of all parties.

Airport Systems Integration is a classic in development worth paying attention to. The benefits are not just “Pulp Fiction”, as the increased efficiency of airports, increased staff motivation, and subsequent increased revenues it can create have airport operators on the edge of their seats.

The Plot
Similar to a Hitchcock thriller the integration plot is full of suspense.

For many years airlines have benefited from having interdependent functions such as fleet scheduling, yield management, reservations and departure control systems (DCS) brought together on a mainframe system to operate in perfect synchronisation. If this philosophy were transferred to airports it would make for an easier life. So, why aren’t common use terminal equipment (CUTE), baggage reconciliation systems (BRS), resource management systems (RMS), flight information display systems (FIDS) and airport operational databases (AODB) set up in this way? By taking this co-ordinated approach and bringing in an AODB, each system can communicate with each other, making the entire system more effective and more efficient.

Unfortunately many airport operators are still experiencing the shortcomings of using old applications, or using new applications independently. The biggest challenge is then attempting to make forward-thinking commercial and operational decisions based on information that isn’t sufficiently up to date. Even where information is up to date, it may be in an unwieldy format, or simply too difficult to extract from its source application to be of practical use. Therefore, to guarantee the ‘feelgood factor’ we must discover how airports can get accurate information in real time in order for them to do their job. This is the next step in the evolution of integration.

The Action
There is already plenty of action at airports. Ramps, gates, and check-in counters can become congested, and flight information displays may not always display the same information. Today there are numerous applications designed to support airport operations: passenger processing, finance, maintenance, ramp, cargo, safety and security, air traffic control and many more functions. Whilst many of these applications produce individual customised reports, unfortunately those reports do not always match. A single source of data would resolve many management problems.

Having these airport systems operate on a shared local area network (LAN) immediately solves the problems of proprietary, dedicated and sometimes redundant cabling worming its way around the airport. The LAN is a high speed, high capacity, voice-data-video backbone, accessible to all that need it. Along with the latest internet protocol (IP) and web applications this network also supports all passenger processing systems such as CUTE, local departure control systems and boarding applications. Resource management applications are equally important. These real-time tools for facility usage planning can help an airport to run more efficiently and effectively. When the facilities are full, the revenue for both owners and concessionaires is assured.

Building management systems can be arranged in the same way. Power, Geographic Information Systems (GIS) to track tenant lease space, and finance systems to automatically track utilisation and invoice tenants are all possible. The network is also self-maintaining in that it runs self-diagnostic programs, and will alert users at the first sign of failure, recommend solutions, and provide call-out information at the same time.

Each of these systems is an important component of the overall airport operation. However, each one is still isolated, and there is a risk that information entered in one application (e.g. flight times) may not match another. Systems integration can achieve the goal of secured, shared information, in turn enabling the airport operator to make customised queries to the database. In the same way, getting all of the scriptwriters and editors to talk together ensures that the final dialogue, costumes, props and sets are all agreed.

The Cast
Each of the individual airport applications such as CUTE and FIDS plays its part - like Beatty and Bening taking the lead roles in the integration flick. CUTE is one of the stars, speeding up the process of passenger check-in and reducing the number of manual errors at the same time. CUTE also maximises airport check-in resources, enabling up to 25% more passengers to be processed. The other lead role is taken by BRS, the seasoned performer which reduces the quantity of mishandled baggage, and makes it easier for airlines and airports to track baggage in general. In the event of a last minute baggage offload BRS has cut the time required to locate and remove the bag from more than 30 minutes to less than ten. In turn this reduces flight delays, helps to maximise airport capacity, and enhances the security process.

Other stars FIDS and RMS add to the cast of supporting applications. A centralised, multi-user FIDS can ensure that all of the flight data is standardised across the airport. RMS offers everything from planning the usage of gates, check-in counters, baggage carousels and ramp equipment to real-time day-to-day operations of the same. Flights running off-schedule can be reallocated a parking resource with minimum impact to overall operations. Inside the building, the limited space available for check-in, gate hold, and transit lounges can be maximised at the same time. Additionally the system will ensure baggage assignments are allocated evenly across all available carousels.

The Crew
As the camera is to the final footage, so the AODB is to ensuring each separate application is pulled together to one whole. AODB captures what is pertinent from each airport application, or ‘zooms out’ to take in information from more than one application at once. This is then disseminated over a secure network whenever and wherever required. It is also flexible enough to adapt to any airport, and to any range of airport applications. Imagine a camera that comes with its own editing suite, and automatically cuts the out-takes from the film to help make a better movie.

However, cast and crew alone do not make a blockbuster film. The Master Systems Integrator (MSI) is the ‘Spielberg’ of airport integration, and provides the final stage of human/computer interface. The MSI “Director” ensures that the actors are in place, the script is memorised, and the cameras are in position, so that together they produce an automated stream of information, or an Oscar winning film. In other words, an airport operator pans across all of the applications through AODB, or zooms in to a particular application to suit any circumstance. It makes all of the applications interact in real time, regardless of what platform or protocol they are using, while following the script already provided. Furthermore, preferences can be customised to each individual using it, making it suitable for any airport manager.

Recipe for a Blockbuster – Mission Possible
Why should the airport strain to cajole the most out of its stars when it can settle back calmly as the producer, and let the director do that? With the MSI “Director” the airport operator will be able to maximise the value for money of CUTE, FIDS and all other systems, by using all of the functions of those applications to the fullest extent, and as a matter of course. Meanwhile the studio is running at its fullest capacity, and highest efficiency. Instead of wasting time with manual operations and re-entering of information into disparate systems, management can concentrate on using the information available to improve customer service, increase security and generate new revenues. Whether reviewing finances, expansion plans, marketing or staffing, the IT-integrated airport can provide the information necessary for the airport operators to remain informed and stay ahead of the growing competition.

At the same time the tenants are happy because they receive value-added programs from the airport. Perhaps most importantly, the audience i.e. passengers can see and experience the benefits these systems bring, and may rush back for the sequel a few months later. Again, instead of spending time on the administration of reports or paperwork, airport and airline staff are able to concentrate on customer-focused activities.

You should expect IT integration to arrive soon at an airport near you, and now it even has a name – in some cases it is already there. Those who haven’t yet experienced it can rest assured - it isn’t Mission Impossible.