Engine Works

Under the hood of Alteryx: tips, tricks and how-tos.
caltang
17 - Castor
17 - Castor

Not all existing processes are created equal. Most are complex and often come with little to no documentation for a myriad of reasons. Here are five things to review to better reverse engineer a process like that!

 

My previous article was on Tips for Building a First-Class Alteryx Center of Excellence, and I’m very excited to write a follow-up to it – this time detailing reverse engineering!

 

#1 Speak with the RIGHT people the RIGHT way

 

It's essential to talk to those who have in-depth expertise and understanding of the current process before reverse engineering it into Alteryx. Find subject matter experts who can shed light on the subtleties, dependencies, and underlying logic of the current workflow. Often, we find that managers or project sponsors would push for Alteryx to automate their department’s pain points – this is great, but as they are not the ones who work with the process, they are not the right people to ask about the process. Instead, it is a good idea to ask them to identify the key people who are.

 

Once the key people are identified, it is important to know that time is valuable to both parties. It is also important to know to what extent that person knows the process. The reason for this is that people come and go, and sometimes handovers are done poorly. The identified person in charge may just know enough to get the process working but may not understand what the process is doing inside.

 

A simple litmus test for this is for them to explain the process to you like you are 5 years old.

 

Explaining it easily for others to understand is a skill! Goes both ways too! Source: GIPHY

 

Consider this popular Einstein quote:

“If you can't explain it simply, you don't understand it well enough.”

 

If they can explain it to you without issue, great! Your job in reverse engineering has been made a thousand times simpler. If not, then it is going to be a little bit more challenging, especially when it comes to What-If scenarios or updating mapping requirements. Regardless, cut them some slack because they are going through a lot – Alteryx is here to help.

 

Once you know the process, it is important to simplify it even further and find ways to do it in Alteryx with more efficient methods, no hard-coding, and more dynamic approaches to handle a myriad of scenarios.

 

#2 Getting Inputs & Outputs right

 

Once the process has been simplified, you now have a game plan that requires an entry and exit point. Something must go in; something must come out.

 

Identifying inputs and outputs may seem like a trivial thing, but it is the most important thing in this process. As you get into it more, you will notice that inputs start to evolve from normal flat files to database files, SharePoint files, OneDrive files, and so on and so forth. It is important to ask your end user where the input is from, what it does, what it looks like, and if they can provide you with the file provided access/approvals have been granted.

 

The same applies to output files. It is easy to output many file types with Alteryx. Sometimes, end users want it stored somewhere specific, or if there are conditions to where they want to store the files. They may even want to write the data back into a database or send it as a report via email to stakeholders.

 

Getting the inputs and outputs correct will ensure that you are on the right track. If you get either one wrong, then it may mean more work to redo the connections from scratch toward the end of your build. It is also important to provide advice where possible to end users because sometimes their processes may not have the best practices. Don’t be like Michael Scott and follow directions blindly and literally into a (data)lake, have some rooms to question and advise as well.

 

Step-by-step is great, but it must be logical too. Ask, always and frequently. Source: GIPHY

 

#3 Differentiate between BAU documentation & Data documentation

 

BAU stands for “Business as Usual” and is often what is done by the people who run the process. They are often concerned about getting what they need from the process rather than what goes on in the process. As someone who is reverse engineering a process, it is more important to know what goes on in the process. Information such as the data types, the ETL process, any manual judgment calls, or formula-generated fields are some examples of things to take note of in the current process.

 

That is not to say that BAU documentation should be discarded. It is important to go through it, too, to better understand what is done by the end-user and to see where you can improve from a build perspective. It gives you a better appreciation of what you are trying to solve, and it helps in explaining to stakeholders after you are done about what you solved and the areas that you improved. If you do not go through any documentation, it is going to make your job even harder.  Understanding both aspects will enable you to recreate the process effectively within Alteryx. In the wise words of Creed, there would be no way of knowing.

 

Know the documentation! Otherwise, what are you even doing? Source: GIPHY

 

#4 Establish milestones in the project & update progress regularly

 

The reverse engineering effort should be broken down into checkpoints or stages. This strategy assures consistent development and assists in managing complexity. Share frequent updates with stakeholders, being transparent about the efforts put into reverse engineering, the difficulties encountered, and the successes attained.

 

Milestones are important because they give the Alteryx development team an aim to achieve and help with mapping out the next phases with new information from building the process in Alteryx. In addition, updating progress is also equally important to the stakeholders to know what is being done and what they can expect from the workflow. It gives the project sponsors and stakeholders some confidence that the deliverables can be delivered and for them to recalibrate if there are major changes required or new information arises.

 

The best part about this is seeing everyone’s face when you solve with Alteryx. The room just beacons with hope and joy!

 

Everyone’s reaction when they see that you saved them hours of work with just a button on Alteryx. Source: GIPHY

 

#5 QA & UAT with concurrent runs for an established period

 

Once you finish building, it is important to test out the workflow that you have built for your end users.

 

The QA period, also known as the Quality Assurance period, will be focused on ensuring that the workflow runs according to what you describe and all the complexities involved, such as with dependency files, macros, file paths, analytic apps, and so on, are working as intended without any errors. It is best to do this with your project manager and quality assurance team!

 

The UAT period, also known as the User Acceptance Testing period, will be focused on the end user testing the workflows themselves on Alteryx to see if they can understand, use, and get the result they want. It is best to leave the user on their own to test to truly understand their experience and see if what you built was intuitive enough for them to learn on their own.

 

Whilst the end user runs the process on Alteryx, it is also important for them to do concurrent runs with their existing process to see if the outputs tally with what they need. This ensures that you have an anchor to compare it with. Even if there are differences, do not fret. This is normal, and all you have to do is review the workflow and account for the differences more properly.

 

Sometimes you’ll miss, and that’s fine. Source: GIPHY

 

Finale

 

It is important to remember that whilst you re-engineer a process, you are replicating the old into Alteryx. It is also vital to go further beyond and transform some of the processes to make them more streamlined so that your users do not have to maintain legacy issues. For example, if it is hard coded, make it dynamic. Try not to use Text Input tools as mapping tables; instead, use flat files like Excel to maintain a mapping table.

 

Thank you for reaching the end of this blog post! I really appreciate that you took the time to read everything. Do you have any tips you wish to add to this? Comment down below what you are doing in your organization so that we can all learn from each other!

 

Do not forget to like, comment, and share this blog post – it will mean the world to me!

Comments