The Bank of Hawaii depends on its ATM network to provide cash to tourists, serve the customers of the credit unions that have service agreements with the banks, and to support local businesses by providing currency and rolls of coins through its Super ATMs. The $10.2 billion bank, which operates 500 ATMs throughout Hawaii, Guam, American Samoa, Palau and Saipan, processes about three million transactions a month.

So when the bank’s ATM software contract with ACI was coming up for renewal, it began looking for alternatives to the Tandem – now HP Nonstop – system that was at the core of its ATM operations.

The bank had already moved its wire service off Tandem to Bankserv, so maintaining the legacy system just for its ATM network was costly.

“The ATM network was the only thing left running on the Tandem,” said Bob Makahilahila, manager and senior vice president of self-service delivery channels. “It was running great, but it was expensive, highly customized, and it required unique skills to support it.”

The situation only worsened when the bank’s only certified Tandem expert moved back to the mainland.

“There was limited support for the applications, and if we ran into trouble we would have to pay consultant-level fees, so we wanted to go to applications that we could support with the skills we have in-house,” Makahilahila said. “We have so many Windows-based applications that we have 15 to 20 staff members who can support them.”

The bank moved to a Windows-based ATM application that ACI acquired when it bought S2, and decided to run it on a Stratus Nonstop FtServer 5600. Key reasons for the choice included reducing infrastructure and application cost, aligning with the corporate IT strategy of Windows and Unix, and eliminating the dependency on highly-customized application code without requiring the bank to run clustered servers.

Once the decision was made, the work began.

“We started in November 2004 and hoped to convert by April 2005,” recalled Makahilahila somewhat ruefully. “We didn’t convert until January 2006.”

The bank was targeted to convert to the new ATM system in October, but it placed a freeze on projects for November and December. One of the bank’s key resources was out ill for about six months during the conversion effort, which had a significant impact on progress. And S2, the software of choice, was being acquired by ACI. It took ACI a few months to decide which resources to keep on board. At the same time, the bank was converting its back-end settlement system, upgrading its ATMs to IP and changing out hardware and software, including new hardware that would be triple-DES compliant.

“We had to change our security equipment at locations because it wasn’t compatible with the new IP protocol,” said Makahilahila.

The bank was using the same people resources for all of these efforts.

To avoid disruptions to its credit union clients, the bank rewrote and tested 30 external interfaces so they wouldn’t have to make any changes to their systems. Extensive planning and careful documentation of requirements contributed to the conversion’s ultimate success.

In 20 years of using the ACI system on Tandem, the bank had developed an extensive array of custom code, and recreating that functionality in a new system had the potential to drive up costs.

“Once you get into the project,” explained Makahilahila, “there are going to be little nuances about things where the vendors come back and say, ‘This isn’t a regular cash withdrawal or checking, because you guys do it this way.’ But because we had identified it in the original documentation, they couldn’t come back and say, ‘this is the way we do it so you have to accept our way.’”

The bank had some frustration in keeping production, testing, and disaster recovery systems in synch. The setup was done on the future production system, which would occasionally be frozen for testing, slowing down production. At the same time, the disaster recovery system was under development.

Despite the occasional glitch, the team held together through the project. A long-term approach helps, said Makahilahila.

“Instead of trying to run through a project plan that has everything from soup to nuts and you could never see that you were making positive progress, we started to create milestones that allowed us to have little victories,” he explained. “That is important from a morale standpoint. The staffs from the line-of-business side and from the technical side are going to have to look at things, remember things, and test things on a continuing basis. Once they get over one hurdle there’s another hurdle and another. All you are dealing with are issues and you never see that you have made progress. Milestones show the team they are making progress.”

Moving from the Tandem Base 24 to the new open architecture meant that a team might fix three of five problems and still not have it solved. Now the Bank of Hawaii has a highly functional ATM network that can meet the needs of visitors, credit union members and business operators who need cash and coins through a fault-tolerant Windows-based system running on relatively inexpensive hardware. When new functionality is required, the bank can draw on its existing staff skilled in Microsoft technology.

www.boh.com

Lessons Learned:

• Insure that all specifications/requirements, especially those requiring customization, are clearly identified upfront.
• Create and review a highly detailed SOW and Critical Requirements Document.
• Determine the migration/cutover plan early in project.
• Start plan for certification testing early and set up test cards in anticipation of transaction testing.
• Anticipate that the project will take longer than expected, including possible impacts to key personnel.
• Include planning for system monitoring upfront.
• Do not try to configure and test at the same time.
• Create milestones that focus on tasks in two-week increments so the team sees the next project goal.
• Constantly set priorities because tasks and issue resolution may seem overwhelming.
• Insure code movement between the development, certification and production systems is monitored.
• Keep a log of all changes and exactly when they were made, especially during the critical first hours/days after conversion.
• Understand and monitor vendor change-control procedures.