Maximl’s asset management (AM) platform does what you’d expect such a solution to do. It does a perfectly fine job of enabling the tracking and execution of work orders (WO). The asset explorer lets you view the equipment’s history. The task list helps the technician get the job done. The spare parts inventory is there. Everything is linked. A schedule is machine generated. As a software vendor we can go head-to-head with the biggest names in the industry in the relevant feature categories.
However, Maximl’s AM offering, with all our UX and AI innovations, does more than what a list of features would suggest.
It begins with the UX. It has been our mission to craft software for users, not buying committees. When field workers find the interface intuitive, any observation about the state of plant assets is likely to be recorded in the software.
UX built for the men and women on the floor. Not for those in plant management. And not for those in corporate headquarters who tend to be in buying committees.
There are three broad principles we believe in.
Principle #1 Remove all friction between noticing a thing in the plant and recording it on the AM
The fundamental challenge with industrial software is the gulf between the state of the plant as said state is recorded in the designated software for the purpose, and the state of the plant as it exists in reality. You know. the reality of the odd vibrations, the inadequate lubrication, the breakdowns, the missing parts with long lead times – the reality of atoms, not bits and bytes.
This gulf leads to the two realities diverging until the designated system of record solves no purpose other than ceremonial. There’s a downward spiral of low-quality data reducing field usage, which further reduces data quality, and so on. This goes on until the system-of-record, acquired at great expense, is abandoned.
And of course, in time a new generation of management rises, notes the many failed promises of PM, PdM, and IoT, and attempts another system of record. And the cycle repeats itself every few years.
The solution, we believe, is to reduce the gap between a technician or planner noting a change in asset behaviour AND noting the observation down in the AM software. Not on email, a spread, group chat, a paper form, or mere paper. Recording the observation down should be as simple as talking.
UX is one aspect of it. But far from all. UX here is hygiene. UX here is a philosophy, a value guiding software engineering and reliability teams.
Once again, the goal is to make recording an observation about a plant asset as natural as talking or typing on a phone’s soft keypad. It follows that voice to text will help. As will a mobile interface. As will AI that turns less than perfectly structured data into high-quality information that enters an AM.
Maximl has built all the above. But there’s a lot of additional detail. For example, a well-designed mobile interface is a great start. However, field workers share devices. And there might be reluctance to make an entry without attribution. PIN-based authentication solves this. Likewise, in bandwidth constrained sites offline features and sync ups are a must.
But these are just examples. The principle is: “study the needs of the floor, the smallest detail and design your AM offering accordingly.”
Principle #2: Remove all friction on the path of the AM reflecting actual plant processes
AM dies when something changes on the floor, and it’s too hard to get the software to adapt to the (slightly) new way of doing things.
The rigidity is sometimes due to the architecture. The rigidity is sometimes due to the vendor company’s policies.
A workflow and/or field and/or interface change requires a call to the vendor’s services unit. Also, the change triggers a mini IT project. This introduces friction. Whoever is in charge is already neck deep in work. Now this person must ask for a budget. And document the change request.
Faced with such friction, teams often go back to what they know. That could be work arounds on the existing AM tool. Or email, spreadsheet, and paper. Data quality declines. The two realities – one that exists on the AM and the one that affects outcomes (production, quality, safety, profits) begin to diverge.
If this becomes the case, the AM platform will soon come to mean little more than compliance. In other words, it becomes the official record of asset maintenance activity. It doesn’t help maintenance and reliability get better.
The solution is to reduce the cost of change. Industrial software needs to be based on a foundation of adaptability – workflows, rules, and configurability tools that allow changes to the data model and the interface within reason.
This is table stakes in most sectors. But heavy industry has put up with software with dated architecture, legacy business models, and much tech debt for a long time. It’s time to change that.
Principle# 3 Irrespective of the nature, quality, and the source of data make it all accessible with AI
Industrial software has been trapped in a vicious cycle. The absence of high-quality data makes useful software hard to build, and the consequent lack of useful software makes it unlikely that high-quality data will ever be at one place.
Asset data is heavily distributed. There’s the OEM literature, past permits, the asset hierarchy in the ERP, the asset hierarchy as contained in p&IDs and other technical drawings, and of course all the ERP data and machine data generated by sensors. Much of it is unstructured; much of it not high quality.
This would have been an intractable problem for most plants before AI. But AI’s ability to extract structured, high value information out of text or images is unprecedented. Modern AI has reduced the cost of building vision AI and natural language processing models.
With the above done, on the day of rollout an AM can be populated with data about the state of plant assets, and an accurate snapshot and trend data that establishes a baseline of maintenance and reliability. It becomes valuable from day one.
In addition, with good UX, ease of data entry with AI, and high configurability —the AM platform gets used widely and stays valuable.
In summary…
The net effect of these additional capabilities is that the Maximl AM will improve operations, and the project won’t be shelved in six months.
That is a big claim. Why do we feel confident making the claim?
Here’s why:
We make software for users. We don’t build software for buying teams. Optimizing the product development process for CIO and CFO offices is good for commerce. However, we think it’s not good for long term commerce. Plants around the world are stuck with software that checks all the boxes, clears all the CIO/CFO stage gates, but doesn’t meet the needs of a single field worker. With us you won’t have that problem.
We are built on contemporary architecture. There’s much legacy in industrial software, and horror stories abound. It’s hard to bolt on anything user friendly, mobile, or AI atop legacy. Maximl, born in the digital age, doesn’t have that problem.
We have a demonstrated history of adoption. At a large Asian petrochemicals site, our control-of-work software was rolled out a month before a major 45-day Turnaround. A TAR is a time of permit volume shooting up. The client green flagged the rollout because our platform was readily adopted among field users with minimal training.

