Global terminal management systems:
key vendor requirementsValue Paper Author: Swarandeep Singh
Global terminal management systems:
key vendor requirements
The global deployment of solutions is required whenever a distribution enterprise is setting up a standardized, common Terminal Management System (TMS) in operations located in more than one country. Few TMS suppliers have the
experience, resources and commitment to support TMS located anywhere in the world with their products.
More and more oil companies are standardizing on a single ERP supplier and moving all ERP implementations across the enterprise to that vendor’s solutions. This standardization, driven by the corporate IT, is percolating down the loading rack promising cost reduction in several areas, including, integration/ interfaces, training and support. There are also intangible benefits associated with single-vendor relationship, such as ease of negotiation and clear accountability if system problem occurs. Here we analyze issues involved in global TMS deployment projects.
This requirement is driven by the need for extended characters in some languages that require more than one byte to store each unique character code. A code page is the complete set of all characters in that character set. The languages affected are mainly Asian – Chinese (traditional and simplified), Japanese, Korean and Vietnamese – and Eastern European (e.g., Croatian,
Czech, Hungarian, Polish, Romanian and Slovakian). Arabic and Hebrew have the double-byte requirement and they also require a special type of bidirectional character. Sorting becomes a major issue, and a further complication is that the TMS application will usually use different code pages to the front-end devices. Microsoft uses its own code pages for Windows. Once a vendor has properly architected for double-byte characters (increasingly using Unicode), it must then set about the language translation. This is country- and sometimes region-specific. Enterprises must be ready to provide such translations to TMS vendor.
Business may be global, but to succeed globally, enterprises must fully embrace the local conditions in each country in which they operate. Embracing all local requirements means fully complying with legal, metrological, taxation, and accounting rules and procedures. Enterprises doing business in other countries cannot assume that their reporting requirements are the same as their home operations. There are differences in the format of even the most basic gain-and-loss reports, not to mention the differences in customs and excise paperwork that normally follow a delivery. Statutory compliance may be the single most difficult area of globalization for TMS vendors to maintain.
Implementing a TMS is a complicated matter, and
implementations that cover significant geographies face even more complex challenges. Typically, users will contract with a TMS supplier that has capability in the region where the buying decision is taking place. This may not be the most prudent strategy, particularly if other remote locations are not geographically covered, as significant travel costs will be encountered. Users deploying TMS into many regions should assemble a team of consultants with focus on the required regions so coverage approaches 100 percent. These groups of consultants should then be teamed with users from the same region and gathered centrally during the initial design phases
The true capability of a Terminal
Management System vendor to support
a distribution enterprise’s global projects
depends on a surprisingly large number of
technical as well as service-related issues.
Note 1: The Unicode Advantage. Unicode is an international standard (ISO/IEC 10646) character set. The Unicode Standard v.3 contains codes for 49,195 characters for all current international alphabets, symbols, etc. Data can be transmitted in eight-, 16- or 32-bit format. All data transmitted over the Internet is already coded in Unicode. Unicode has widespread endorsement among the leading IT vendors. For more information on the Unicode Standard and the Unicode Consortium, refer to www.unicode.org.
of the project and then sent back to their regions to manage execution of the project. This allows for common design decisions and representation of all regional requirements. Product Support
Enterprises deploying a global or multinational TMS will need to evaluate a local support office vs. “follow the sun” telephone support offerings. Although these can be used in combination, an enterprise should look carefully at the internal support processes of the supplier. Most problematic is where a regional support location is delivered by an agent, third party or channel. It is rare that these organizations have direct access to the development environments or staff, with the result that regional locations are not qualified or permitted to carry out code changes. Or if they do, the code changes are not condoned or endorsed by the head office. There may be a danger of code changes not being carried forward in future releases.
Enterprises must overcome people optimization issues, otherwise, TMS implementation will fail. (see Figure 1).
In many TMS implementations, enterprises have under-executed when addressing the people aspects. Offering training on subjects that are typically left out of the original implementation effort — such as less used processes, and error conditions/ troubleshooting — can increase end-user acceptance and system use, not to mention lower end-user frustration levels. In addition, training on business processes and basic business functions is almost never considered during implementation, although increased user understanding of both areas is critical to make effective use of the increased amounts of information available in the TMS system.
Adjusting the enterprise from an organizational standpoint can also yield substantial results. Overhauling business processes to operate horizontally across the enterprise will not be effective without changing reporting hierarchies, performance measurement criteria and job descriptions. The enterprise must realign these to support the cross-functional processes that are the essence of TMS.
Importance of Program Management
To improve return on investment (ROI) and limit total cost of ownership (TCO) in global TMS initiatives, enterprises must adopt a program management approach to project oversight, providing coordination and consistency across associated projects rather than managing individual projects as discrete, unrelated efforts.
Compared to a project focus, a program management focus yields up to 30 percent less TCO and up to 30 percent more ROI.
Improving ROI: TMS deployments will comprise numerous projects that share objectives, risks, end users and IT
resources. Progress and decisions on one project may depend on or impact others. If projects operate independently, the likely outcome will be decisions that misalign with other projects. Costs will rise when work efforts that could be leveraged across projects are duplicated in individual ones, or as decisions affecting the total TMS solution are made at the project level. Coordination across projects during key activities such as design and testing will improve the overall solution, yielding higher end-user acceptance and more-effective enterprise-level processes.
Reducing TCO: Although the application life cycle includes retirement, enterprises often fail to consider it. As TMS vendors expand their footprints, enterprises must be prepared to revisit previous best-of-breed decisions. Those that implemented best-of-breed tank inventory management solutions, for example, will incur the costs of integration. In a few years, the TMS vendors may reach functional parity for enterprise tank inventory requirements. To reduce TCO, it may be more economical to replace the best-of-breed application with a pre-integrated application from the TMS vendor. Enterprises should regularly evaluate their TMS vendor’s capability against installed best-of-breed packages. Optimization opportunities TMS Implementation failures TMS Implementation risks
Product Training Meeting the needs of the expanded user base and demand for complex transactions
Number of users expand, and transactions extend beyond the enterprise Process Training Preparing users
for upstream and downstream impacts at each step within the business process
Multi-process dependencies increase and process failure impacts multiple enterprises Organizational
Preparing users for new roles and using reward systems that did not motivate change
Traditional attitudes concerning information ownership and empowerment threaten enterprise success, not just project success Figure 1 TMS missed opportunities and risks
Figure 3 Instance strategies
Single vendor-centric strategy: – Lower TCO – dependent BOB integration strategy: – Higher TCO – dependent Custom/ component strategy: – Higher TCO – dependent
Single vendor Many vendors
Number of vendors involved A few vendors
Number of enterprises deploying TMS
Figure 2 More vendors bring higher costs
Distributed multiple instances Consolidated single instance – Standard nomenclature – Easy reporting – Upgrade once – Centrally supportable – Ease acquisitions Single instance – Nonstandard nomenclature – Manual consolidation – Local upgrades – Local support – Implement another for acquisition Local instance
– Use to meet local requirements Local variants – 80/20 rule – Best practices – Shared services Common process
– Works one way – One set of docs. – Ease of training – One-user experience Comon config. – 10% local – Local practices – Autonomy Local process
– Works local way – Local docs. – Local training – Local experience Local
Best-of-Breed vs. Integrated Approach
The choice of deploying best-of-breed (BOB) vs. integrated solutions is no longer purely an either/or proposition. The real question is the degree of native integration that can be achieved.
Each best-of-breed component will increase ownership costs, and as more components are introduced, the number of custom connections can multiply rapidly (see Figure 2). For instance, buying a separate tank inventory package rather than an integrated one within the TMS. Consequently, many enterprises will forgo functional supremacy to simplify the overall application architecture.
This choice, however, can also negatively impact ownership costs. Where an application is functionally deficient, enterprises
may choose to customize. Customizing packaged applications can become a habit-forming exercise that, if not tightly managed, will significantly impair an enterprise’s ability to migrate to later versions without heavy manual intervention. This balance between integration costs and development costs becomes paramount for managing TCO on an ongoing basis. Enterprises should carefully weigh integration costs (associated with best-of-breed oriented strategies) and
custom-development costs (associated with single-vendor-centric strategies) to assess the potential impact on TCO. Change Management
As part of TMS deployment initiatives, enterprises must adopt a robust change management program to ensure that users are prepared for new processes, responsibilities and metrics. Multiple TMS initiatives will frequently impact the same end users or introduce change to enterprise-wide processes, making it difficult to control the amount of change and how often end users must modify their knowledge, skills, abilities or work activities. It will also be crucial to present a united front to the end-user community when asking them to make changes. Providing a total picture of the change — including expected results, and a “road map” from the legacy processes to the new ones — will be necessary to eliminate contradictory or confusing advice. In many cases, increasing end users’ understanding of basic business practices will be critical to harnessing the real value of the new system. Organizational changes, such as job redefinitions or departmental realignments that are complex to execute, should be combined and deployed at the program level (where possible) to minimize time, cost and frustration.
Enterprises should combine organizational-change requirements from individual TMS projects and formulate an organization-wide change management plan that accommodates individual project needs, yet minimizes the volume and intensity of change that end users must absorb from multiple directions. Be cautious of end-user sensory overload, and introduce changes in increments that users can easily absorb.
Controlling Number of Instances
One the main drivers of TMS TCO are the number of instances that are deployed and how they are managed for a distributed enterprise.
Most enterprises that have pursued multiple-instance
deployments have experienced higher TCO than expected. This is partly due to diverging configurations across locations that require specialized local support. However, a larger cost factor is simply the amount of time and effort necessary to maintain and upgrade the numerous instances.
Deploying a single instance reduces support requirements, increases consistency in processes and data, and allows for an integrated view into the enterprise’s data (see Figure 3).
Upgrade Timing and Availability
Enterprises need to determine whether the regional version deployed will be fully supported, or they need to negotiate contracts such that it is supported as a customized variant. The key question to ask is whether the vendor will upgrade it as part of maintenance fees or if the buyer will need to relicense? Also, what will be the delay before the required language and version is actually available after the new version is released in the home market? If you have single instance of code (build) installed, this needs to be catered for differently than if many instances are installed, because the updates in a multiple-install situation need to be coordinated with training and data migration.
The following points need to be addressed when deploying a global TMS solution:
− Ensure that full user documentation for all future releases is available for all languages required in a TMS deployment project and that there is a commitment to the countries being considered
− Understand that the geographical upgrade strategy from the vendor is key and must match the enterprise’s geographical strategy
− Ensure that the vendor is capable of making rapid changes to the application code to meet regulatory compliance for specific countries where it is often a prerequisite.
− Evaluate the availability of local product support for each TMS site’s geography