In life, there are some good surprises (birthdays, hearing a great new song, meeting that special someone), but in enterprise software, not so much. This sixth example in our stories from the field is about a major enterprise software firm.
This firm decided to move much of the sales of their software upgrades and maintenance contracts to a web portal, where clients could just buy and download the updates they needed. Previously the sales force would not have to get involved with contacting each client and conducting manual orders on routine stuff, which wasted time for both parties. Many clients had open POs so they could just add on these incremental purchases. This was to be a win for both sides.
To set this up, they needed to access the customer data and their software inventory. They could then make suggestions about what additions might be needed, offer the ability to instantly purchase, and download. They did manual testing of the system UI, and thorough unit testing of the software. Everything seemed okay for rollout.
However, as they discovered three months after the launch, there was a problem with the all-important middle step. The system was supposed to push the order into the enterprise invoicing system, SAP in this case. Then the client would be billed.
Ninety days after launch, the guy responsible for the SAP transaction system asked if they had started this new system since no orders had entered into the system of record. To their embarrassment, the clients were getting their software downloads, but their invoices were not getting recorded.
It seems another group implemented a policy so that each account had a password change every 90 days. These changes occurred between the application test time and the launch time. So fulfilled upgrade orders were getting logged as bad data, and then flushed on a regular basis. The clients were not complaining because they were getting the software, and likely did not mind that the invoicing appeared slow.
The firm brought us in to do end-to-end business process testing to make sure that all steps in the process worked on sample cases. We tested not just at the web ordering UI layer, but followed that transaction through the app server, ESBs, CORBA and all the way to confirming that it made it into the system of record. We call this practice “invoke and verify.”
After software was downloaded, LISA made sure the invoice was processed for that specific download, and the team quickly rooted out the “changed password” culprit that was causing orders to get routed incorrectly from within the ESB layer. This validation was also done on a continuous basis to make sure any new changes did not disrupt the flow. Now all steps in the process work, and the original goals of better customer service at lower cost -- without the unwelcome surprises -- were achieved.
You can find the complete case details here.
Comments