A Business Analyst’s View of Business Processes and Data Anomalies
It has been my experience that most data anomalies can be traced back to an unmanaged, undocumented, or forgotten business process. Oftentimes, business rules are established, programs and processes are implemented and then left to survive on their own. The mindset is, set it and forget it. If only it was that easy.
As Director of Operational Analysis with a multi-million dollar company, one of my specialties was to look for and identify lost opportunities for revenue. Surprisingly, this did not always take the form of new business development. Many times my task was to simply identify “leaks” in business processes. In numerous instances, I was able to identify data anomalies which lead to the recovery of tens of thousands of dollars.
Data anomalies can take many forms but are often found in large data groups. By trending revenues, analyzing declines and working backwards through processes, these anomalies can help businesses identify broken or mismanaged processes. Often business rules are broken because of lack of communication between departments, programmers, management, or all of the above. Having a business analyst watch for anomalies is key to managing processes and keeping your business on an upward trending track.
Managing Data Anomalies
A membership-based company in which I worked has an annual renewal for their membership product. At the time of this example, there were two payment plan options for the membership renewal, Full Payment and Monthly Payment. After running numbers from this annual renewal and comparing the data to previous years revenue, I found that renewals were down year over year. This data anomaly jumped off the page like a bright beacon. Now, the question was, what caused this decline in renewals? Was it the economy? Was it a change in the product or service? Or, was it the result of a broken business process?
The first step was to review the process. In this case, there were many elements involved in driving the automated credit card charging system process through a payment gateway. The membership database, built in Microsoft SQL Server, was manipulated by the business rules, a renewal processing and charging system that was created in C#, which communicated with the processors gateway.
As the business grew and established new business rules, older rules were revised, replaced, omitted and sometimes overlooked. Following the renewal charging procedure through the C# code, I found that a large batch of members were not renewed due to the addition of a new payment plan rule which eliminated existing payment plan members from the dataset. In essence, the new rule overwrote two older, yet still valid rules.
After I isolated the problem in the code, and identified the membership renewals who had been excluded from the first batch, new code was written to incorporate all membership types. The renewal processing and charging system program was run again and I was able to document the procedure to ensure this programming error would not be repeated. Had this anomaly not be recognized, the company would have lost thousands of dollars in lost revenue.
Craig Glenn is a inter-disciplined, experienced professional helping businesses find missed opportunities, analyze data, get more out of the internet and maximize their business opportunities using his programming, critical business analysis and operations experience. How can Craig help your company? 352-989-0966