As a global enterprise, one of the major challenges facing Schindler is ensuring the swift and professional maintenance of all its lift installations around the world. Making it quicker to find replacement parts for its mobility solutions in Europe alone would be a major plus for the company. So, Schindler put its money where its mouth is, so to speak, and asked Liip AG to design and develop its new spare parts catalogue.
Applications tend to enjoy better user acceptance if they have been designed precisely with the users’ needs in mind. This, in turn, boosts productivity and business efficiency. When it came to developing the Schindler spare parts catalogue, every hierarchical level was involved, from service technicians right up to management, a move which ensured that developers were able to take into account the process know-how of each and every stakeholder and to come up with a solution that perfectly matched users’ actual needs.
Given the many different stakeholders involved, Liip and Schindler organised a series of workshops with a view to establishing a set of harmonised specifications for the future application. As well as the widely shared goal of shortening the identification process by 30%, a set of objective criteria were established to measure the progress made in reaching the desired goals.
Before work began in earnest on the development project, the main users of the application had to be identified. On the one hand, there are the service technicians who carry out the repairs, and, on the other, the back-office staff who act as intermediaries between the technicians and the central warehouses. One of the main priorities for both groups was that the application features an intelligent search and filter function.
The next step involved defining the functions that the app should have, building the wireframes, and then asking members from both groups to test it. Based on feedback from the testers, Liip added a comparison function, as well as a comments box. The team also used the information they gleaned from discussions with users to develop the procedure for identifying spare parts. Application models were built and tested, once again, by the service technicians. As a result, the development team was able to integrate users’ various mental models. The last thing on the list was to come up with a workable design that reflected the Schindler brand, but one which could also be adapted for any possible dual-branding in the future.
In the end, two solutions were developed: a mobile app for service technicians and a desktop version for the back-office team. Given that the service technicians would mostly use the app in lift shafts, where reception is, at best, patchy, the app features an all-important offline function. The offline catalogue comes with a wealth of search functions - autocomplete, fuzzy search, facetted search, full-text search and visual search - and the identification process is made even quicker thanks to back-office communication, a comparison function and a comments box.
AngularJS provides the framework for the desktop catalogue, allowing the sophisticated user interface to perform at the desired speed. .NET was used to implement the back-end systems, as this will allow Schindler to maintain and develop them independently. Xamarian was used to build the framework of the mobile app because it allowed the developers to build a native application that delivers in terms of both the complex functions and performance the customer wanted, while also ensuring the portability of the app and its integration in line with Schindler’s strategy.
Lucene.Net was used to develop the offline function, the first time that it has been used in this way for a mobile device. ElasticSearch provides the app with an online search function, as well as data processing and indexing capabilities.