When we started our search to replace a cumbersome and unreliable Tlog retrieval system, we weren't necessarily looking for the delivery of sales transactions within seconds from far away stores, that came as a bonus. Our previous method of collecting sales consisted of the following:

1. Store did a nightly close which created  a Tlog file for the day

2. We retrieved files with a home-grown FTP process

3. We processed files with the existing Loss Prevention System

4. We summarize the processed files anddelivered to the IBM i5 with yet another time consuming process

Did I mention that #1 doesn't always happen? It used to take over five hours to process a day's sales and that's if we actually got all the data. If not, we would frequently have to retrieve the Tlogs manually. It was especially a burden if any one of the four steps did not complete because different people were knowledgeable about each step in the process.   It was not unusual to have up to four people in a room, including a manager, trying to figure out how to retrieve sales. Now, with RIO Grande, we just need to ensure that the communications line is working and the sales will come through. Our effort to retrieve sales has been reduced to monitoring the VPN which is something we are already doing. The reduction in tech support time alone is enough to justify this project.

We have really been amazed at the performance of the system. It is easy to add new stores and they come up with no noticeable degradation of overall i5 system performance. As we were rolling it out to all stores, we were expecting so see some effect as we went from 10 stores to 20, from 20 to 30 and so on, but, really, getting the data to the i5 has not been a burden.   At the store the same is true. We have Rio running on some 10-year-old 4690 controllers without a hitch. However, we did plan for and are experiencing  an increase in utilization of the i5 when we process the detail Tlog info into summary files for reports and queries. 

If you are a retailer considering a project like this, there are several things to keep in mind. The first thing to consider is the cost in terms of system performance to move the transaction data delivered by Rio Grande into various summary files for use by other applications. This is likely to be a CPU and disk I/O intensive application, or, in our case, a series of applications. So if your system is already stressed, it will likely push it beyond its limits. 

Another thing to consider is that this is a big project and will require some backing at high levels to dedicate the people necessary. The biggest part of the project will not be retrieving the data, but integrating it into your existing applications and building new ones to take advantage of all the new data readily available. A third aspect of the project is to keep everyone involved.   The group that supports POS in the stores is different than the application developers, so these two will need to work together. Finally, set realistic time frames. Even after you develop all your systems, you will want to roll it out in a controlled manner. For instance, as we got better at looking at the detailed transactions, we actually found bugs in our POS that cost some time that wasn't forecasted. Also, if you are an AS/400 shop with no Java experience, then there will be some learning to do. You won't have to understand any Java code, but you will have to know how Java apps work on the AS/400.

All in all, as I mentioned before, this is a state of the art system for retrieving sales. Support from 4690world has been excellent and is a first class business partner.