I am considering developing a simple module for tracking the service and maintenance of resources (assets tracked by the resource module). The value to the user would be:
Define any regular (planned, scheduled) maintenance that needs to occur (oil change, filter change, inspections) and the frequency or trigger that indicates a maintenance period
Record any maintenance or servicing that has been performed on a resource (planned or unplanned)
Give visibility into upcoming regular maintenance, or the status or a resource that may be down for repair
From a technical perspective I think there is a lot of potential to leverage existing Dolibarr modules:
The Events/Agenda module can be used to put scheduled maintenance on the calendar
The Ticket module can be used to report problems with a resource if given a new ticket type
The Manufacturing Orders module could be given a new type that allows associating products, services, or work instructions with regular maintenance
The Interventions module could be used to schedule regular maintenance or track performed services
Things that could not be done with existing modules:
Track maintenance intervals based on things other than elapsed time (for example run hours on a machine or miles driven on a car)
Associate required preventative maintenance with resources
Does anyone else think that a module like this would be helpful for your use of Dolibarr? Do you have any feedback on what features or workflows would be important? Does anyone with module building experience have feedback on the technical approach to the problem?
I do not think that it would be useful for me, but it might be useful for others. In previous jobs I could see it potentially being useful for tracking the yearly maintenance of our serverroom cooling. I can also see this being useful for a cooling vendor. Maybe for elevators too. Or cars/engines as you suggest in your own post.
What if your system would support sticking a QR code on the gear, and scanning the code would lead directly to a website that would reveal:
Identifier
What
Where
Last serviced
Email, Form or Phone number to contact for needed service?
And for internal use by a vendor this page could also show:
Which colleague did the work
Which parts was checked, replaced, serviced
Any special knowledge or parts?
In that QR code, if you donāt want to reveal that this is installation number 1, aka no other customers, maybe use a ULID as the identifier?
Thanks for sharing some of the examples of where you might see this useful!
The barcode idea is interesting. The built-in barcode module only seems to support Products and Third Parties, but it might be simple to expand its support to Resources.
I think it is interesting that you considered both an internal use of servicing a serverroom, and the external use of selling someone the service on their serverroom. The interventions module looks to be designed around selling maintenance services (tracking hours and products used, generating invoices, and scheduling repeat services). It even has a direct link to some number of resources (although that seems more to indicate what resources are needed to perform the service, not what resources are being serviced).
I am more interested about internal maintenance services than external services, but your response makes me think I should focus more on growing the existing interventions module to support my use case than try and make a separate internal maintenance module.
I do agree with your point that the view of the resource should include the maintenance record with who did the work and what work was done. Again, this is probably good information to track for both internal and external maintenance which further supports trying to use the interventions module for both cases.
Thanks for your input! It was very helpful to hear your perspective.
I just looked at the resources module the first time. We are considering to use Dolibarr but more producing and selling products to customers and maintaining them. So a maintenance module could be useful for us as part of the product lifecycle management.
Our main use would probably be documenting maintenance of delivered products with a serial number, linking contact persons, documents, and photos.
Just another perspective
EDIT: I just realized that my ideas are partly covered by the services and contracts/subscriptions modules.
I just realized that my ideas are partly covered by the services and contracts/subscriptions modules.
Yes, that and the āInterventionsā module, which is all about performing services at a customer site (scheduled or unscheduled) then billing them for those services (and maybe some parts too). I think there are also ways to link interventions to contracts and tickets.
I do think that a hard link between Interventions and a Resource would be very useful, both for external service (like what you want) and internal service. Currently you can link multiple resources to an intervention, but that link is meant to be āresources used to perform the maintenanceā, not āresources that are having maintenance performed on themā. Here is my current mental model for this potential module:
Optional link from an intervention (or intervention template) to a single resource
Add a card to resources that show all scheduled maintenance (intervention templates) and upcoming due dates
Add a card to resources that show all maintenance events (interventions, in all states of completion)
Add a āboxā (widget) for the home screen with upcoming maintenance
Allow product and service use inside interventions (github link)
This lets you plan to use consumables (filters, etc) during maintenance
Allow interventions without a link to a third party
This will represent internal maintenance, but prevent use of the invoice creation feature
Optional link from a ticket to a single resource
this will help when transitioning a āmaintenance request ticketā to an intervention
The only thing Iām not 100% sure about is linking the resource to the intervention. I think an intervention is supposed to represent a single site visit to a customer for service, which could involve servicing multiple pieces of equipment. perhaps linking the resource to an intervention line would be more appropriate, but then things get a bit more complicated.
Thanks everyone for all of your input! I appreciate the discussion so far.
