Introduction
Every enterprise has the same story. There are numerous maintenance contracts with various vendors. The majority of the time, those are on multi-year contracts. SLAs (Service Level Agreements) are also well defined. However, companies struggle to evaluate the performance of the vendor for a variety of reasons.
Fortunately, there is a hack for it. But, before we get to the solution, let’s look at why this problem of vendor SLA quantification exists in the first place. Here are the primary reasons.
1. Service Request Mode:
If something breaks down, we contact the maintenance vendor via email, phone, messaging app, or phone call. These legacy channels lack a quantification mechanism. It is nearly impossible to keep a record of the call logging with the type of service requests and SLA as per the contract. When something is broken and operations are stalled, returning to the desk and noting the time of report and the type of incident is nearly impossible.
2. Work Tracking :
The vendor would eventually arrive once we had launched the request. However, the call attendance time is not quantifiable. It would be in the visitor book somewhere, but the true reason for the visit would not be mentioned.
3. Solution Time:
Again, after receiving the call, the vendor technician may be able to solve the problem on the spot, or he may require more time, which would necessitate the approval of additional spare parts. These conversations are buried somewhere in email trails.
4. Delivery Commitment:
The deviation from the delivery commitment is frequently not tracked because it is a verbal or email-based commitment. Again, the actual time required to resolve the issue is not clearly stated.
The challenges listed above are just a few examples; the list could go on and on. We all know and agree that the problem exists. But what is the solution to this problem?
1. Quantify SLA Expectation:
There is no way to measure something unless it is quantified. As a result, we must quantify the SLA and record these expectations in the system.
2. Digital Service Requests (Non Connected Assets):
The service request to the maintenance vendor must be digital in nature. Ideally, it should be on the shop floor or facility via mobile application, SMS, or AI-based call logging. All you should be able to do is enter the asset code, either by writing or speaking, and the system should automatically convert the work order.
3. Digital Service Requests (Connected Assets):
If the asset is connected, the failure should be automatically detected and the work order system should generate the work order for the reliability team or vendor depending upon the type of issue. If it goes to reliability team, the easy interface on mobile phone itself to assign the job to vendor digitally.
4. Vendor Engagement:
It is critical to consider the vendor as a member of the reliability team, or possibly the extended reliability team. An easy-to-use and secure interface through which the vendor can obtain all asset information, type of issue, images or video of the problem, or, in the case of a connected system, the error log should be available for initial review.
5. Digital work permit:
The system should issue the work permit to ensure that the vendor has a scheduled visit to the facility and is authorised to work on the asset. The authorised person would issue these permits with a single click.
6. On Arrival:
The technician should have access to all information pertaining to the service request. In addition, the full history of the asset in question should be available to him, saving time in gathering the information. This information would be accessible through simple phone number and OTP-based authentication by simply scanning the QR code printed on the asset.
7. Estimates & Quotes:
The vendor should submit the spare parts and labour quote estimates digitally on the same platform. The approval workflow will allow stakeholders to quickly approve the quote from their mobile device
8. Proof of work done:
When the job is finished, the proof of work done will be submitted in accordance with the predefined checklist. This will allow the vendor’s completion time to be quantified.
9. Escalation Matrix:
In the event of a SLA time delay, automated escalation emails would be sent to both the vendor and the stakeholder. This ensures that timely reminders are sent to the vendor from our end.
10. Contextual Reports:
For the Assets, reports evaluating key KPIs such as MTTA, MTTR, MTBF, and so on are automatically generated. Alongside, the vendor performance KPIs as per the initial set terms are also available in real-time and on finger tips. The penalty for not meeting SLAs could also be calculated, making life easier for enterprise managers.
Is it too good to be true? Fortunately, this is true. Sysma is developing a future-proof maintenance and operations platform that will increase the efficiency of the reliability and operations teams. Speak to us today to know the power of Sysma.
