Friday, May 20, 2011
The Case Against Category Management – Implementation of the Cloud
In Exercises 1-4, we talked about how you can copy data into spreadsheets and work out a system to assists you in turning up the heat on your profits. Taking it any further would devalue the purpose of the exercises. Automation is the key to solving these problems.
Now, I would like you to take a look at http://www.cstorepod.com/html/storereport_topography.html.
On March 3, 2000, we created what is now being called a ‘Cloud Computing’ environment that I envisioned back in 1988 when IBM introduced the AS/400. We couldn’t do it then because the cost of telecommunications using computers was entirely too expensive to allow a small to medium-sized retailer to participate. I assumed one day telephone companies would make the use of a tiny strand of copper wire more economical, but we had to wait until 1994 and the invention of the World Wide Web (WWW) before prices started coming in line with what businesses could afford. Still, the ability to network over the Internet was far too slow to be practical.
In 1999, IBM introduced a powerful computer called the AS/400 Web Server and a diskless PC that included Internet Explorer and allowed a person to access the AS/400 over the WWW. The birth of Cloud Computing went through several name changes and technological enhancements before it became what it is today.
The system we built (see the above link) is represented in this pictorial. Notice how we have isolated “Retailer Headquarters’, ‘Stores’, and ‘Grocery Suppliers’ and linked them to a hub labeled ‘StoreReport’ (SRDC). This was done in the interest of security, with custom security levels at each entry point.
For reasons which will become obvious later, the grocery supplier, stores and headquarters do not have access to each other’s data. Any data to be shared is isolated behind the firewalls of the SRDC, comprised of a network of hundreds of large IBM iSeries i5 computers in multistate locations.
SRDC maintains continuous links to the stores and their POS equipment, gathering sales data every few minutes. Price changes and new items are added to each store’s pricebook on the SRDC network from any Internet connection, but activity is closely monitored as to who can make those changes and if necessary, from where those changes can be made.
For example: If headquarters allows a store to modify certain parameters within their own pricebook, the SRDC knows who can make those changes and what changes they’re allowed to make. In fact, selected suppliers can be allowed to make changes in a store’s pricebook, IF that is headquarters’ wish. Normally, headquarters is allowed to modify every store’s pricebook, but even that can be limited by SRDC if management dictates- the arrays of various security options are both powerful and endless.
Being in constant contact with the stores gives the SRDC the ability to detect anomalies. For example, if the SRDC hasn’t been able to contact the store’s POS within five minutes, an emergency alert is issued to all parties on a list. If contact has not been made within ten minutes, the alert is ratcheted up a notch. If within fifteen minutes no contact is made, an emergency situation is declared and someone at the store is going to get a call to see if assistance is required. Web cams in the store could be turned on to observe the situation in progress.