Data Transformation—Where to Begin?
What once took tax professionals months now takes moments—but challenges remain

print this article

With the advent of digitization tools comes the potential to transform and index massive data sources without the current dependency on IT and coding. We are approaching as significant a cultural shift in the tax profession as Facebook and the iPhone were in our day-to-day lives. What comes is a generation that will grow accustomed to the possibility that anything can be automated by anyone. Tasks that once took a tax professional months to perform can now take moments. The potential for material error can be better measured and controlled. This is the beginning of a significant evolution in how tax planning, provisioning, and preparation are done—an evolution accompanied by questions of how this change will be controlled, defined, and audited. With technology, tools, and app solutions developing as quickly as Amazon Web Services can power them, the speed of change can seem overwhelming.

Of course, change also comes with skepticism and resistance. How can deep institutional knowledge be fully valued for the decades of experience it took to be developed? How do we balance experience with the speed of the novel and ever-changing landscape that comes with it? But in the same way that the advent of Microsoft Excel empowered us all with spreadsheet functionality, so we collectively find ourselves on the verge of having to evolve quickly. In a tax practice with a uniquely conservative culture, a need for accurate reporting, and deep institutional knowledge that fills gaps otherwise left exposed, chief tax officers must confront a great dilemma: where to begin?

In this article we’ll explore the grassroots elements of an organizational shift to a DevOps culture, which foregrounds the combination of software development and information technology to further business objectives. We will explore how to cultivate substantial advancements using focused cross-functional teams, as well as how to balance institutional knowledge with the unique contributions of millennial and gig economy skill sets. All this should begin with the recognition that the job functions in demand today didn’t exist yesterday, the jobs of tomorrow are still being created, and the reality is that we all must continually learn.

Step 1: Tools to Create the Grassroots Movement

This article is born of the personal experience of this evolution within ADP’s tax credits practice. One of our most complex offerings is what, on its face, seems very simple—tax credits based on year-over-year growth. It is surprising how much data and analysis and documentation go into proving to an auditor’s satisfaction that growth requirements are satisfied. An auditor has myriad ways to attempt to haircut a credit calculation to the point of ineligibility. Over the years, the complexity developed to address these issues has resulted in calculations that can take months to complete, along with the added time and diligence to gather various data sources to document the facts and circumstances of growth activity.

Growth tax credits involve year-over-year comparisons and, to be done well, data sources must be consistent so a true analysis of growth patterns can be demonstrated. As with most compliance practices, in a given year hundreds of calculations may be required for tax credits compliance, and we wait in a relative state of suspension until the tax year closes. Then crunch time begins, starting with gathering data. Addressing the data gathering process itself would be an article in and of itself. But once data for the year is received, then comes the merging of data sources to document the year’s full activity, performing a layered analysis from clean-source data extractions all the way through to a final calculation summary, with audit trail, that is then incorporated in the deliverables. This process requires documenting, from inception to result, all testing, calculations, and adjustments along the way.

After the tax credit calculation, there are multiple levels of review. This review often involves another person to test and evaluate the analysis, normally in a spreadsheet, with the final calculations and supporting documentation. Often the review process takes longer than producing the calculation. Inevitably, somewhere along the chain a material issue arises. Once this issue is identified and more information verified, then everything goes back to the analyst to retest, recalculate, and revise, and the review process begins anew. Afterward, it comes time to finalize the forms and support documentation. At that point, the delivery deadline is upon you—whereupon you might discover an issue with the original source data due to changing business facts and systems unknown to the tax practice. The process starts all over again, and ’round and ’round we go.

This set of facts is typical within any compliance-based practice. Everything depends on correctly identifying and retrieving data sources, correctly evaluating each source, adapting the analysis to the full spectrum of changes in facts, documenting salient facts and circumstances, and replicating this process correctly hundreds of times over. What’s more, the process typically involves variances with legacy systems, dealing with which can feel like sifting through an intricate web of details just to get to Step 1. Scenarios can easily arise where there is more work than people to do it and never enough time. Ever-present within this process is the risk of material error, not to mention the risk of undetected methodological errors that have been replicated again and again each year. All of this occurs with tax folks who are predisposed to perfection and accuracy down to the penny when their names are attached to a work product.

Naturally, when scaling the various process bottlenecks, silos often emerge—teams that address one link in the chain of a process and then pass the work onward to the next team, which completes its own part, and so on. The problem with silos is that each group forms processes independently of the others and, with time, each silo becomes more entrenched in how it does things, erecting walls that prevent knowledge sharing.

For a chief tax officer, fostering a cultural shift for innovation in this scenario can feel impossible. But the reality is, true solutions will not emerge from the same processes that cultivated the problems in the first place. In a risk-averse culture, how do we begin?

Most compliance-based processes can actually be condensed into the elements of the following cycle, shown in Figure 1. Wherever there is a breakdown in this process, people and ad hoc processes can fill the gaps. No robot or automation can replicate experience or critical thinking, but unfortunately processes often develop so that people spend tremendous amounts of time and energy on redundant tasks that can, and should, be automated.

ADP has a data and security culture to begin with; however, many issues in large-scale compliance efforts are universal. Within a twelve-month period, ADP’s tax credits practice evaluated, tested, learned, adopted, and implemented Alteryx, a self-service data analytics platform. The true power of this tool was that it allowed us to change the entirety of how we did things. The reason, quite simply, is that it removed the necessity of code writing in order to create foundational changes to process. Alteryx is not a replacement for code writing and IT. Rather, it expands a novice’s capabilities to automate foundational elements. The business can automate itself. This empowers our IT compadres, because instead of needing them to figure out our tailored business needs, we can now go to them with defined requirements. The rest we can now do ourselves. Alteryx has provided us with that power.

Other tools could conceivably replicate the functionality of Alteryx, but in our particular case, it was our tool of choice. We learned of it through word of mouth, and in the initial two to three months, as we evaluated its viability, we discovered that other departments in our organization already had licenses. So, luckily, it was a matter of adding trial licenses to get started. We discovered that Alteryx was able to address several needs within our tax credits practice. First, it could process massive data sources linked together by common fields. Workflows could be created with a drag-and-drop method, and each step generated a log of that step, creating a natural audit trail. Though some of the logic of Excel is applicable as you format and link fields of data, learning Alteryx is the equivalent of learning a new language. But it’s a language that can be mastered readily with relatively minimal time investment, as Excel was when first adopted. Furthermore, Alteryx offered us virtual and onsite training as well as online instruction guides that enabled our learning.

We didn’t make Alteryx mandatory; rather, we offered training to our tax credit production group. And from this initial training grew an internal movement that not only was monumental but also invigorated and pushed forward our entire production process, speaking to needs that had been unaddressed for over a decade. It was very much a grassroots experience. What happened naturally was a marriage of two vital skill sets: tax credits plus math and data analytics. Two individuals with math and data analytics skill sets took to Alteryx quite naturally and distinguished themselves at the onset as the leaders of a super-user team. However, instead of the natural tendency of this super-user group to erect another closed-in silo, this group joined with our folks who collectively had decades of tax credit experience and had seen the full history of our organization from its genesis. The contribution of team members with extensive tax credit experience was vital as fundamental workflow designs were developed. They could foresee instantly the potential issues in a workflow or change in process. And within ninety days, this shared knowledge and collaboration automated the fundamental processes for our growth credit services. The compliance process detailed above that took months of back-and-forth effort now took minutes. We applied interface tools in Alteryx so that a new associate with no tax credit experience could replicate a complex calculation with apps that were created from contained workflow layers.

Alteryx was a true game changer. It went beyond piecemeal automation and set us all collectively on a new trajectory for how things are done. As shown in Figure 1, countless hours of manpower were spent taking one step forward and two steps back as we navigated the data merge, analytics, calculations, and compliance steps. We have now substantially automated all four of these steps in the cycle. This automation has now freed up tremendous time and resources to invest in our true need: better data sources for information gathering. We now have time to explore and expand the arteries of source data that make what we do more comprehensive, accurate, and timely.

In how our process was transformed, the compliance cycle (see Figure 2) represents the functions within each step. The key factor is that, when data sources are expanded and consistently referenced together, you are effectively indexing the information flowing through your organization. By default, you are creating a comprehensive audit response at the onset of your process.

The impact and the gains were so quick and so powerful, we succeeded in ways unprecedented in our history—the time savings were almost scary. The win also demonstrated immediate value that gained stakeholder trust. That said, we saved so much time in our process that folks were left to wonder, What’s next? Did I just automate myself out of a job?

It is key to continued success that organization leaders recognize that time savings should be reinvested in the people who catalyzed the change. We’d won time: time to figure out how to take the business to the next level. And the implications of what that next level could be were massive. We could automate every tax credit program we do; we could incorporate complex analysis consistently to help substantially reduce human error. And since these calculations can run automatically, virtually any manual, redundant, time-consuming process within the practice could be automated. We can now invest the saved time in a trial-and-error process to transform our operations further. We can examine new sources of data and identify new tools; we can expand our analysis; and we can capitalize on opportunities by changing how things are done.

The Advent of DevOps

When we think of Apple, Amazon, Google, and Uber, we think of progressive high-tech cultures. It is remarkable how quickly and effectively advancements are conceived and deployed in these organizations. One observed difference is that failure is embraced as a step critical to learning and is a natural part of the trial and error on the way to stellar results.

Another observed aspect of these high-tech cultures is DevOps.1 The root of DevOps is creating a culture that can advance and adapt at a pace that far exceeds traditional organizational structures. Ironically, the consensus at technology association panel discussions is that the most successful path to DevOps is as a grassroots movement within an organization rather than as an initiative compelled by executive order. Quite simply, DevOps supports the creation of cross-functional teams. These individuals align their respective strengths, skills, and experiences in a common vision. This alignment creates focused, project-based advancements by aligning members of the team where they are strongest. Natural synergies can develop to deploy value-adding concepts, and the measurement of their successes must also be carefully constructed and communicated to foster this approach.

Taking down the walls that divide our silos is critical to collaboration and sharing knowledge and allowing true innovation. There may be resistance to this approach. The organization quite simply may not be ready. However, it seems inevitable that the divide must be breached at some point. And when business needs compel change, it is important to see how nimble and fast-paced organizations make progress. Interestingly, the personal differences that often occur in separated silos may be a side effect of a process problem. And when that foundational process issue is addressed and resolved, the personal differences are relieved as well.

DevOps is approached as a CAMS model: culture, automation, measurement, and sharing.2 The first step is to determine if your organization’s culture is ready for this shift. If leaders or team members are resistant or risk-averse, the organization may not be culturally ready for change. The cross-functional team, in effect, carves out the necessary resources to focus on what can initially be an uncertain endeavor. These resources can unveil significant initial breakthroughs that can be difficult to translate into a metric that gains the trust of stakeholders. Silos could present resistance that is difficult to transcend. But eventually there comes a tipping point that compels change.

Leadership has to be willing to measure value effectively. Measurements of progress should be carefully crafted, since at the onset the usual metrics could actually deter or diffuse the progress. For example, what if the chosen measurement of success is speed of completion? Does using speed as a metric come at the expense of quality? Or, if success is measured in revenue growth, is this metric measured by the number of new sales or with organic growth in retained and recurring client business?

On executive leadership, it is critical to understand the perspectives of every layer of the process. The person working on the floor day-to-day knows more about design malfunctions than the supervisor overseeing the operation. Understanding the ground-level perspective will help uncover holistic solutions that can create synergies throughout the organization.

DevOps is about finding opportunities and creating continuous improvement. To begin, choose no more than five areas to address, and then focus on the most important. Identify the groups and places to start. Find a project and people with established communication paths and start small. Provide opportunities for cross-functional teams to emerge. Recognize those at every level who take on the charge of catalyzing change. Use tools that result in quick wins that can kickstart transformation and gain trust around the organization. Be a part of the process, share knowledge, and encourage others to do the same. And when failure occurs, recognize that it’s a necessary step to growth. The bigger picture is to create multidisciplinary teams and let them cross-pollinate. Not everyone needs to know everything, but collectively the team has the skill set to produce innovation. Embrace aspects of what each person knows and let them focus. This is the beginning of a shared vision and a shared set of goals that advances change. If there is a new tool and someone steps up to learn it, embrace that effort and encourage them to share what they learn with others. For DevOps to be successful, it has to be organic within the business. If it becomes a regimen of strict directives and measurements, it fails.

Interestingly, in panel discussions on DevOps, I learned that one of the most successful DevOps ventures began when leadership encouraged everyone to start the new year focusing on any process they wished. People naturally gravitated to unaddressed pain points and long-needed solutions and, most important, they were invigorated by the flexibility to be creative. In cases where creativity is encouraged, when a failure occurs, the emphasis should be on collective learning and growth rather than on pointing fingers. This generates a blame-free culture, one that should resonate particularly with individuals who have been with the organization long enough to have seen the genesis of the culture and every variation since. Even if they don’t have knowledge of all the necessary tools and technologies, their capacity to build bridges and connect people can be worth 100 software engineers.

I hope this article is helpful and conveys useful ideas and methods. Transformation is a journey. I hope you explore the tools necessary as well as concepts within DevOps that could be effective for your organization. Another relevant area of interest is DevSecOps (development + security + operations), which embeds security controls within the process.3 We will all find that, as we discover new sources of data and new methods to tap into them, ensuring data security by designing it with safeguards against human error is the next step in a natural progression. Like all journeys, the endeavor is to be continued.


Maryam Ossooli is Southeast practice leader, tax credits, at ADP.

Editor’s note: The opinions expressed in this article are those of the author, and not necessarily those of ADP. The information provided in this document is for informational purposes only and not for the purpose of providing legal, accounting, or tax advice. The information and services ADP provides should not be deemed a substitute for the advice of any such professional. Such information is by nature subject to revision and may not be the most current information available. ADP® and the ADP logo are registered trademarks of ADP LLC. Microsoft® and Excel® are registered trademarks of Microsoft Corporation. Apple® and iPhone® are registered trademarks of Apple Inc. Amazon and Amazon Web Services are service marks of Amazon Technologies Inc. Alteryx® is a registered trademark of Alteryx Inc. Google® is a registered trademark of Google LLC. Uber® is a registered trademark of Uber Technologies Inc. All other trademarks are the property of their respective owners.


Endnotes

  1. For an overview of DevOps, a good place to start is “What Is DevOps?,” Amazon Web Services, accessed May 20, 2019, https://aws.amazon.com/devops/what-is-devops/.
  2. John Wilson, “DevOps Culture, Part 1,” IT Revolution, accessed May 20, 2019, https://itrevolution.com/devops-culture-part-1/.
  3. “What Is the Difference Between DevOps and DevSecOps?,” Quora, accessed May 20, 2019, www.quora.com/What-is-the-difference-between-DevOps-and-DevSecOps.

Leave a Reply

Your email address will not be published. Required fields are marked *

XHTML: You can use these tags <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>