Software in the wild: supporting businesses with data and algorithms
By now, everyone knows what an algorithm is, right? Especially in software development, algorithms are everywhere:
“A finite sequence of well-defined, computer-implementable instructions, typically to solve a class of specific problems or to perform a computation. […] Starting from an initial state and initial input, the instructions describe a computation that, when executed, eventually produces an ‘output’”. (Source: Wikipedia)
The first thing that stands out from the very beginning is the straightforward structure:
input → algorithm → output
From our experience, we know that a slight enhancement of this structure makes it easier for a client company’s management to grasp, adopt and deploy software solutions:
business targets → input → algorithm → output → benefits
So, for the purpose of this article, we will not look into actual algorithms, but at how the above structure was replicated in various software development projects.
Algorithm 1.: Decreasing manufacturing downtimes
For a manufacturer of electromechanical machines, we got the task of eliminating the downtimes on the manufacturing line. Considering the cost of the manufacturing equipment (several millions of euros per piece) and the initial downtime (up to 40%), the potential benefits were clear: any increase of the active time would help the company produce more with lower equipment costs.
Our task: build a software solution that helps the manufacturing engineers do better planning, by showing their machines’ load in real-time.
Once the client’s business goals were clear, our work started by defining the inputs:
- The data structure became a matrix built on three pillars (so-called „anchor” inputs): the manufacturing machine, the target product, and the operation needed to actually make it.
- Extra „object” inputs such as various documents, reports, info on maintenance time, etc.
The client could insert/use data in various forms, such as:
- manual inputs,
- .xls imports via a dedicated graphic interface
- other sources/formats, possibly used for other purposes, such as existing ERPs, etc.
Within this system, the main inputs come from the manufacturing engineers doing the actual capacity planning (per each shift / daily / weekly). But then, the manufacturing operators will also insert real-time data (e.g., “status”: items done/faulty/remaining, time outs, emergencies, etc.). Finally, our dynamic algorithm also considers the specifics of the client’s manufacturing process.
Based on the inputs, the algorithm then runs on a continuous basis to check the real-time status of each manufacturing equipment: is it working, on which product, the delta (+/-) versus the initial plan, etc.
The output is a complex yet consolidated database and display, both of which provide an overview of tens of machine’s load times – think tens of dashboards that are both unified and individually accessible for “fine grain” information.
The resulting software solution helps the client reach 95% load time, which eventually translates into a 50% increase in efficiency and manufacturing output. Because the solution’s “structure” was easy to grasp, it facilitated a quick internal adoption and usage.
Algorithm 2.: Overview/commitment on deadlines
Still in manufacturing, another project looked into the timelines/deadlines of complex products’ manufacturing, with the goal of providing a clear status and commitment confidence to the planners. Because complex products come with complex timelines across multiple parts providers, our software solution starts with a product’s delivery date and computes the timeline to reach it.
Of course, the dataset is much more than the delivery date. Because of products’ complexity (“approximately half a car” – to directly quote the client), the first input comes from breaking the product down into:
- a “supreme”: the final product,
- its “hierarchy”: thousands of smaller components, each with its own info re. provider, timeline, terms & conditions, etc.
- the assembly process: the actual operations, time, sequencing, source of components, etc.
This structure closely replicates planners work mode, and it therefore facilitates data imports from existing “regular” sources such as .xls files or ERP systems.
Based on the data inputs, and starting with the delivery date, the algorithm computes a product’s manufacturing timeline.
The main result is a Gantt diagram with chronological operations to be executed, each with its own starting point, estimated timeline, possible interdependencies with other products, current status, alerts, etc. Say, your final product needs to be shipped on December 1st – the diagram will show you that component A.1. needs to be ordered by February 15, received by March 31, then fed into component C.5. which should be ready by May 1st, etc.
Because the diagram itself can get really complex, it helps that it can be zoomed-in/-out. The various views are made possible by the custom GUI/graphical user interface, e.g. for:
- the product designer/planner: inputs for deconstructing the product into its ever-smaller parts;
- the production planner: the manufacturing timeline, operations, and status;
- the plant management: high-level overview and reporting.
Having a clear timeline and overview of the manufacturing process results in reliable schedules and committed deadlines. The whole manufacturing environment becomes more manageable, with clear and timely action points for all the involved parties. Bottom line: no missed shipping and happy clients.
Although a basic concept, “out in the wild” algorithms can benefit from a clear understanding of their structure (input – algorithm – output) and client’s business context (business targets – … – benefits). After all, software development is not an ivory tower game, but a hands-on, solution-finding one.