This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Alteryx is an awesome data analytics and productivity tool, uncovering up entirely new possibilities for users to employ data analytics. As the population of Alteryx users grows, one topic becomes increasingly important: how are we ensuring that Alteryx workflows are well controlled and governed?
Governance can mean many things, ranging from how to properly enable and train users to ensuring analytics is ethical and accurate to governing data or building in workflow checks and controls (we may expand on these issues in subsequent posts). Here, we want to focus specifically on building a plan for governing Alteryx workflows that would be subject to an Audit or Compliance review with the goal of getting an enthusiastic nod of approval.
Many of our clients have developed their own best practices for governing Alteryx workflows, often aligned or inspired by policies and standards around change management, software development, or (statistical) model usage. Below we summarize some of the best practices we have gathered from amazing practitioners and ask you to add your own.
We acknowledge that not all analytics need audit-proofing. To maintain the ability for rapid innovation and flexible execution while providing safeguards for workflows in production, some customers use a risk classification framework and a tiered risk approach designed to replicate core elements of typical change management policies.
The exact definition of what constitutes a low vs. high-risk workflow will depend on the institution, but a common guiding principle can be whether an error in a workflow could result in a material financial impact or substantial reputation risk. Also, manipulations of confidential and sensitive data (like patient records, client information, etc.) are indications of a potential risk. Assuming that we have two risk tiers (high/low), the infographic below highlights some of the questions one may ask to determine the risk rating of a workflow.
Once the risk classification of workflows has been established, a governance “checklist” can be put together. While details may vary across industries, sectors, and use cases, some common guiding principles we observe among our clients include:
Elements of good governance for lower-risk workflows are detailed documentation, independent reviews, and a formal sign-off/approval process. Specifically, we consider it helpful to document the calculation logic (either in the workflow or in an independent document, like a desktop procedure), an independent review process (within the team or by an outsider), tracking manager sign-offs, and a change log with evidence of review. Some of our analytic professionals leverage customer-managed telemetry to generate views of data sources and outputs; others leverage third-party applications like the WAM tool.
For higher-risk workflows, we recommend separate development and production environments with a formal process to promote to production, a formal review process for existing workflows (depending on risk, either continuous monitoring or a routine cadence like re-validation 1x per year), having separate user ID’s for workflows (not IDs of individual developers), and control points with automated pass/fail triggers that stop execution if an error occurs.
In many cases, it is useful to ask questions such as:
In the face of unexpected staff turnover, how can we ensure that the workflow can be executed?
How can we expedite new team members to step in and familiarize themselves with workflows and underlying logic?
Do our policies and standard ensure data to be correct, updated, and fit for purpose?
Lastly, while governance requirements can vary, we can probably all agree that we should make it easy for users to remember and facilitate adherence to them. To ensure that every Alteryx user is aware of best practices, consider handing out a “governance summary” during the onboarding process (or enable users to print a "checklist" they can run through as they complete their workflow), much like the document attached at the bottom of this article.
Let's hear from you! In this post, we described just a few of the techniques we hear from analytic professionals around the globe. What do you think? Do you have other tips or tricks to ensure that every user contributes to ensuring that good governance practices are implemented and followed?