Detailed Visibility into Complex Workflows
Custom medical products are highly personalized. A complex network of manufacturing processes is needed to satisfy patients’ needs. A high volume of custom orders moving across multiple plants adds further complexity to the usual tasks involved in tracking orders from receiving to shipping.
As order volume increased and more systems were added on the plant floor, management’s visibility into products moving through the custom manufacturing process diminished.
Technicians created numerous manual sub-processes to deal with customizations. They had to make routing decisions on the fly, often under pressure. Variability among technicians and processes led to quality control issues, but without visibility into these processes, there was no way to mitigate them.
Because so much of the custom manufacturing process is manual, even determining the status of an order is challenging. If a customer called, staff could say when the order was received, but could not update the customer about where their order was in the process or when it would be delivered.
The company’s culture of innovation led their software team to look for new kinds of tools to turn their complex manufacturing process to their advantage. A graph database like Neo4j was a natural fit. The team began devising solutions to their workflow and routing problems using the connections in their data.
“We switched from a relational database to Neo4j for several reasons. The first is that Neo4j provides a natural representation of a workflow; after all, a workflow is a series of connected processes,” said a senior software engineer who worked on the project. “Next, our business needs are complex and continually evolving. The flexible data model provided by Neo4j, especially in comparison to a relational database, made it easier to accommodate these evolving needs. It also enables us to efficiently traverse connected data – without complex queries and excessive JOINs – and make real-time decisions.”
The team thought that creating a workflow engine was conceptually similar to a common graph database use case, real-time recommendations. These systems use a person’s data – such as their profile and system preferences – to make decisions about products to recommend. Similarly, a workflow engine takes a custom order – which includes information about the order, the customer, the customer’s preferences and the technician working with the customer – and uses all of that information to recommend the most appropriate workflow and automatically route the order into that workflow.
Using Neo4j, the team developed a flexible workflow model. Their workflow engine adopted a polyglot persistence approach, using Neo4j for the live workflow and MongoDB for versioning and metadata.