Rejuvenate Your POS With Java

There was a time when the mere thought of a POS software change caused Robin Lynas to frown and slump a little deeper into his chair. Lynas is the CIO at Mark's Work Wearhouse (Calgary, Alberta), a $550 million subsidiary of $6 billion retail monster Canadian Tire. With more than 300 stores operating local POS servers across the country, Lynas and his IT staff were forced to maintain each local server using a hands-on approach that included expensive outsourced maintenance contracts. And while Lynas lauds the system's reliability, he laments its inefficiency and the fact that he's running out of human resources to support it. "With an IT budget of only about 1.8% of revenue, our cost of owning and maintaining IT systems is a big concern," he says.

A Shaky First Step Toward Java
Mark's was caught in a situation where it had a cumbersome and expensive POS system and the technology that supported it was going away. Each Mark's location ran its own processor, an AS/400 that emulated to the store's 5250-based terminals. In an attempt to cut costs by eradicating these in-store processors, Mark's decided to implement thin client Java-based POS software that would allow the company to run a centralized server at its headquarters. After the system was rolled out to approximately 20 stores, the company realized an average of 20% savings in POS IT maintenance costs per store. Sound too easy? Well, it is. Read on.

Mark's allowed the POS vendor it was working with to manage the implementation. As the project got off the ground, Mark's realized its new POS wasn't what it had hoped for. "The solution wasn't as flexible as we had hoped. It was a rocky rollout," says Lynas. In a successful software installation, the vendor understands the enterprise's business practices and pain points, and the enterprise has a thorough understanding of the software it is going to use. By giving up the reins to the vendor, Mark's didn't get involved enough in the early part of the installation to see the red flags that would indicate the system wasn't quite what the company needed.

The implementation was approaching completion in 60 Mark's stores when Lynas checked in with Chelsea Market Systems (which was purchased by Retek in early 2002). Chelsea was in the process of rolling out its own Java POS solution to The Men's Wearhouse (Houston), a 650-store, $1.3 billion men's clothier.

A Solid Foothold On Thin Client
Lynas learned from his previous mistakes, so when he went to Houston to visit Chelsea, he knew what to look for and how to approach his vendor relationship. "We needed software that could be customized to fit our business. Specifically, we needed a product that could accommodate our B2B effort and that would alleviate our Canadian tax and payment processing interface headaches," he says. Canadian retailers that partner with American retail software vendors (at least, those vendors who aren't accustomed to doing business with Canadians) must be prepared to make heavy modifications to accommodate the payment processing, tax, and credit authorization differences between U.S. and Canadian banks. "We've had a payment processing integration issue for seven years," he says. "I've had to certify our banking system with our bank on four occasions now, and on the first three occasions it was never done in less than six months. After writing a Java interface from our POS to our payment processing vendor [Tender Retail Systems, Toronto], we were able to get it up and running in less than three months." These are but a few of the issues Mark's initial foray into Java POS fell short on.

Following a five-month incremental software development and infrastructure modification process, Mark's rolled out the new and improved Java POS system to five stores in July 2002. Every two weeks during the development and modification stage, the team in charge of preparing the software met to review its progress and slate goals for the next meeting. "The architecture of the core product is solid, but we wanted to make sure we had all the customization and modification in place prior to the rollout, so we took our time and did it right," says Lynas. This calculated approach also allowed the IT staff to get used to a completely new system gradually.

"The major difference between the last attempt and this implementation is we're following the teaching model this time," says Lynas. "I apply this model to all of my dealings with vendors now." This model simply refers to the company's approach to the vendor's involvement in technology integration. Mark's prefers to minimize its long-term service and support contracts, opting for up front vendor training instead. "I want to pay our vendors a fair price, but I don't want to be dependent on them for the rest of my life," says Lynas. It's therefore Mark's goal to equip its IT staff with intimate knowledge of the retailer's business practices and keen knowledge of the software products it runs. This is an increasingly popular approach among retailers with the IT resources to do it. Otherwise, it's solely the vendor who must gain the knowledge of the retailer's business practices to integrate a new software program. This "hands-off" approach is a sloppy way for an IT department to implement new technologies it inevitably will have to run itself. Again, in an ideal situation, balance is achieved between the vendor's software expertise and the retailer's business expertise.

Good Java Wins Back Store Management
The POS rollout at Mark's is best described as calculated, cautious, and controlled. In addition to the inherent challenges a large-scale technology rollout presents, Mark's was sensitive to the fact that many store managers had been bitten by an inadequate Java rollout. Lynas found that once the new, improved system was up and running in a few stores, word of its success got out to other managers. This was all it took to put store management's fears to rest. Still, Mark's continues the project in a regulated fashion. "We can't move too fast," Lynas cautions. "We're going to monitor the system carefully through the holiday season to see what kind of a load we bear." Currently, the Java stores are running on two central application servers with no performance issues whatsoever. As a matter of fact, Lynas and his team are confident that the holiday rush won't tax the system, because the servers are not performing under duress right now. "We'll have a much better idea how we'll need to scale our server configuration going forward, after the servers get hammered hard through the holidays," he says.

Thanks in part to thin client architecture, the population of retail IT staffs who need to grapple with 12-year-old plus legacy POS scenarios is dwindling. But as these numbers dwindle, so do retail POS operation costs. Mark's reports a 30% reduction in the total cost of operating its Java-enabled stores, with maintenance costs down 50%. It plans on having 80 stores complete by year's end, and the whole chain running Java POS by the end of 2003. Now, instead of slumping a little deeper into his chair, Robin Lynas is rarely in it. He's too busy getting his stores ready to save money with Java.