Your Business Mentor column "In System Design, Treat Exceptions Like Exceptions" argues that infrequent events, like splitting customer credit card payments, should be treated as exceptions rather than accommodated by software redesign [March 2007 issue]. But the way a company handles credit card information involves two additional and important considerations: security and liability.
Storing a customer's credit card information in a notes section could be a security hazard. Does a credit manager need to have access to the customer's credit card information? If data access isn't restricted on a need-to-know basis, storing data in the notes section could violate the requirements of Visa's Customer Information Security Program.
Now let's address liability. Say someone gets a customer's cardholder data via a breach of your system or from a printed report. Could company liability outweigh the cost of implementing the split-payment feature in the software?
While it makes sense to address exceptions via business rules, companies have to consider data security and liability when making these decisions.
Daniel P. Looby
Lead Systems Analyst
Georgia Institute of Technology
Niel Nickolaisen responds:
As far as security, we created an encrypted field in the notes section (we didn't want sensitive customer information in the free-form notes fields). A call center agent would enter the credit card information into this field. Only certain people, such as credit managers, had access to these encrypted notes.
Second, we didn't retain the customer's credit card information in the encrypted field. Once the credit card transaction was complete, the information was deleted. We handled all credit card information this way. All in all, we think we met security and liability concerns without having an extensive customization on our hands.
We also weren't concerned about our credit manager having access to this information; he had access to the same information in our legacy system.
Projects by the Numbers "From List Maker to Project Manager" was a good piece [February issue]. As a training project manager for the Marine Corps Base at Camp Lejeune, I now teach the principles of managing time and dependencies.
Just as you indicate, it's important to develop the work breakdown structure, then see how the time works out. The benefit is the ability to refigure when the inevitable problems emerge.
One of my projects involved installing a complex training system in several locations in the same building. The lieutenant colonel in charge needed a completion date to promise the general. These two hard-charging types were so used to doing lots with so little that they thought they could do anything. They missed the two contracts that were included, both of which are governed by Federal Acquisition Regulations.
Once I determined the actual timeline of the project, I had to make a very unpleasant phone call to the lieutenant colonel.
Elton C. "Jeff" O'Byrne
My company, Drive Medical, is in the midmarket space and has the perspective that a successful SAP implementation will strengthen the company. So your timing on the article "SAP Comes Down to Size" [September 2006 issue] was perfect. When I read the piece, I was in the process of signing a contract for SAP All-In-One.
VP of Technology
Port Washington, N.Y.
Due to a production error, the photo on page 48 of our April issue did not identify the staff of Arnold Worldwide. Those pictured are as follows, from left to right: Brian Kastelein, director of integrated analytics; Pam Hamlin, president; Greg Folsom, vice president and director of IT; and Evan Shore, creative manager.
We Want to Hear From You:
CIO Decisions welcomes letters to the editor. Write to us at email@example.com, and please include your name, title, company, city/state, and a daytime phone number for verification. We may edit letters for clarity and length.
This was first published in May 2007