This past week, I had both the honor and the privilege to present a session as part of the Intermediate Track at the 2017 FileMaker Developer Conference, held in Phoenix, AZ. My topic was “Workflow Automation with Script Triggers”. If you will indulge me, I would like to share some of my key discussion points over the course of several blog posts. To begin, we will focus on Workflow.
I don’t have any empirical data, but I believe it is safe to say that almost every organization is concerned with the business processes they follow and the continual improvement to this workflow. This is not a new trend. It should come as no surprise that the study of workflow – or the study of the deliberate, rational organization of the work – began in manufacturing at the turn of the 20th century, which is about twenty years before it was even dubbed ‘workflow’. Every industry had embraced modernization and automation processes by this point so each company’s goal was to formalize the steps required to make a specific widget. This allowed them to introduce optimization techniques as the workflow for building each part was refined. This repeatability in the process also lead to improved quality since the part was made the same way each time.
Now, the origin of workflow is rooted in the physical space, but, as custom app developers, we spend the majority of our time in the virtual space. As a result, we need to expand the definition of workflow into the area of technology. If we look at dictionary.com, we read: “Workflow is the set of relationships between all the activities in a project, from start to finish. The activities are related by different types of trigger relations. These activities may be triggered by external events or by other activities.” Please notice that this definition brings into focus both the tasks required to see a process to completion and the events which start the movement from one step to the next. Our job is to observe the physical process and translate it into the world of a FileMaker custom app.
By its very nature, each FileMaker solution we build is a custom app, designed for a specific use case. In the same way, the workflow we define and automate for each process will be unique. The workflow could involve the flow of required information or tasks from one staff member to the next, or macro level workflow as I like to call it. Or, it could relate to a single task of a single employee when gathering information, entering that data, or generating the report, which would be micro level workflow. Regardless of number of steps in the workflow, it always comes down to (1) a sequence of operations (2) performed by an individual or group (3) to complete the task.
As we move from the general concept of workflow to the specific process or task our client has asked us to automate, there are few key things to keep in mind.
First, workflow with the same starting and ending points will be different for two different companies. Do not assume we can “copy and paste” portions of Solution A into Solution B to solve a problem the exact same way. We are dealing with unique individuals, each with his/her own priorities when it comes to completing that same task. Since we are talking about a custom app built using the FileMaker platform, we need make certain that the workflow we have designed into their solution matches the client’s processes for each job or task.
Second, we need to take a page out of the User-Centered Design handbook, and keep the user at the forefront of the process. So how does this happen? It starts by observing the problem to be solved. This may be as simple as talking to one person in a micro level case and then implementing the solution. Or, it could be as involved as interviewing multiple team members, observing the existing process, and building a proof-of-concept solution before making any changes to a production system for a macro level case.
During this process, we need to ask the right questions to determine what the user needs, not what he wants. Never ask “What do you need to see?” because the user will most likely say he/she needs to see everything, especially if that user happens to be a manager. We want to ask questions like “What do you need to do?” or “What happens next?” so that we can focus on the physical steps needed to complete the task and determine how those become scripted actions or button clicks in a FileMaker solution.
Third, after asking the question comes an even tougher task: Listening to the answer. Tell me if this sounds familiar. You ask a client a question. The individual starts to describe the process, and before he/she finishes speaking, you are already cataloging the five different techniques you know in FileMaker that can potentially solve the problem. It’s not that you don’t care about what the user has to say; you’re just really excited to get started. I know I’ve been guilty of this. Regardless of the reason, we have missed a crucial piece of information and started down the wrong development path. We need to make sure we are listening to understand, and not just to give an answer.
Finally, I spoke of the importance of User-Centered design just a few paragraphs above, and the client certainly knows their business better than anyone else. However, we are experts in our field of custom FileMaker app development. We need to be confident enough to suggest process improvements when we see them. We bring a wealth of knowledge to the table as developers, and we can use that experience to avoid the same pitfalls encountered on previous projects.
In part 2 of this blog post, we will dive into some important considerations as they relate to Script Triggers. Before I sign off, let me leave you with this final thought on workflow: When working on a solution for a client make certain you understand the workflow because automating the wrong process is worse than having no automation at all.
