QM APPS: Quality Business Processes & Report Configuration
Quality Business Processes - 27 July 2016
As part of our monthly SOLABS technology blog series, we’re speaking with our developers and analysts on their reflections on the industry, its development and rapid changes, and how their area of current focus may be pertinent to compliance/regulatory and the future of Enterprise Quality Management System (EQMS) software.
For this interview, we’re talking with SOLABS QM APPS Software Developer & Analyst Francis Lau, whose current work finds him collaborating closely with a Development team engineering QM APPS, the powerful, lean and intuitive automated Business Processes that can be operated on their own, out of the box or customized—but that can also be closely integrated with SOLABS QM centralized Training and controlled Document sections.
Developing Powerful Quality Business Processes & Reports
Gordon Bradley [GB]: Hello Francis! So you work as a Software Developer, Business Process & Report Configuration at SOLABS. Would you like to tell us a little bit about what you do?
Francis Lau [FL]: Hello! Well, I get a wireframe and/or the functional requirements specification for the workflow Business Processes (or QM APPS), and after one of our Product Analysts has spoken with a client I get to build a QM APP, which is composed of:
- A look and feel for the process steps
- A decision on which fields are in the forms
- How the workflow progresses
- How the Process itself interacts with the clients
I do the assembling of the business forms, all the component steps, and the routing as they’re all established in the specifications, making the decisions route as they are intended to, etc.
The SOLABS QM user interface (GUI) framework is in the core software. What I program is in the middle of the browser page, comparable to the ‘meat in the sandwich’, so to speak. The Processes are built from blocks or interactions that are then routed together. We have style guides for programmers, so we can look at examples of how something was done previously for reference, ideas, and best practices.
GB: Would you say it’s as though the Product Analyst writes you a storyboard when they describe the APP?
FL: No, in the specifications the Product Analyst provides a wireframe of the flowchart, so I can already see how the story progresses: a task, a decision, a waiting phase, etc. My job is to translate specifications into automated business processes.
GB: Okay, and you configure reports as well, right? How does that work for you?
FL: Well, normally our Product Analyst will request a table with some values—pre-selected values that interest a client. I generate a database, grab the values and place them in a table that cleanly displays information for the client.
GB: If you just look at databases, it looks random. It’s in the interpretation and presentation that you get something valuable, right?
FL: We know where the data’s stored, and in my case, someone is telling me what they want fetched and displayed. To get to this place where we can confidently extract data from the database:
- We learn variable names
- We see what each table’s holding
- We learn naming conventions
- We comment our code
- We learn through experience
- We present the information in a way that is meaningful and helpful to the client
"...in the specifications the Product Analyst provides a wireframe of the flowchart, so I can already see how the story progresses: a task, a decision, a waiting phase, etc. My job is to translate specifications into automated business processes."
GB: Do you ever discover things in the specifications that are impossible to deliver?
FL: Um, not impossible! Sometimes there are guidelines in the specifications that make sense, but I can tell there’s something missing that’s not explicitly stated, so I fill in the blanks. Humans can do this, but machines can’t. We have to leave absolutely no room for ambiguity.
GB: We’ve already spoken with Diem about the SOLABS Business Process Engine (BPE), and the feeling I get is this is a way of talking about the code that watches, triggers, conditionally activates—all of SOLABS QM’s assembled logic–in a way that makes sense to non-programmers.
FL: This BPE is getting somewhat close to AI, in that it controls the system, it drives it forwards, and it acts on circumstances. But these are all metaphors, or ways of explaining, for non-programmers. Unromantically: it’s many thousands of lines of code.
GB: Some of the flowcharts I’ve seen in the User Functional Design Specifications look like a bowl of spaghetti, with lines overlapping and heading in every direction. Is it any harder to make those ones than it is the less complex ones?
FL: Well, if you think about it, a complex workflow is like several more straightforward ones combined together. You’re only ever in one place in the workflow at one time. It may look complex, but that is just all the routing and potential outcomes. The decisions and the outcomes may be more complex, but only because there are more choices, more routes. It doesn’t mean the Process is complex because the workflow looks graphically complex.
GB: Okay, and what is one thing that people here might find surprising that you enjoy about your job?
FL: The thing I like a lot is writing labor-saving programming tools in Excel…
GB: Excel?! Really?
FL: Yeah, I can do complex iterative search and replaces, pattern recognition, variable assembly. I’ve been doing this since high school. A given process could take 1,000 clicks, and I don’t have that kind of time or patience! When I go through code I don’t recognize, I make an Excel table that hunts for variables and concatenates them. I didn’t know MySQL when I first started at SOLABS, and these tools I make generate the MySQL code in Excel. Then I can run that code in the database. I do this with anything tedious and repetitive, or anything with cycling tasks.
GB: So while you’re writing MySQL in Excel, you can also program reports and process workflows!
FL: All in a day’s work! [Laughs]
GB: I am obliged to ask you what you enjoy about working at SOLABS—just what is it that you love so much about this company?
FL: What I love about working at SOLABS is that the people are all super nice and really smart. I love to code, and I get to code every single day. In other jobs, I never necessarily got a sense of accomplishing things. Finishing something, from start to finish, is very satisfying. Here I can finish a process in 2-3 weeks. I worked on coding projects that took 5 years.
How can QM APPS maximize your company’s efficiency & help you remain compliant?
Access the QM APPS Library