1. Introduction

There is great pressure on companies to free employees from non-value-adding tasks and transfer their time, knowledge, and competence onto more creative tasks. Particularly in the quality management (QM) of Original Equipment Manufacturers (OEM), there is increasing quality pressure due to constant changes in internal and external requirements and an increasing number of products for several markets. As a result, product complexity increases. Recalls and restrictions imposed by authorities due to quality defects are threatening corporate goals and reputation more and more frequently. Today, QM employees are occupied with more manual tasks (data transfer, consistency checks, copying, pasting, reporting, etc.) for numerous products, whereas creative and value-adding activities are often neglected due to capacity reasons. Therefore, QM needs automation to carry out business processes more efficiently and reduce the workload of employees to ensure competitiveness.

Recent studies show that Robotic Process Automation (RPA) has the potential to automate processes in various industries and departments, thus leading to improved productivity [1], higher accuracy [2], faster and more efficient processes [3]. However, in the literature, we find little or no case studies conducted in the field of QM and the automotive industry using RPA. Compared to current research results, this case study focuses on the application of RPA in QM to ensure product compliance and to reduce process time. Further case studies can provide more use cases and share experiences in using RPA. Considering the lack of research, we propose the following research question: How can RPA contribute to the automation of QM processes and what does its application show? We conducted a case study with Mercedes-Benz AG (MB) seeking to improve the quality of its technical registration document by means of RPA. The research paper is based on one business case of MB and semi-structured interviews with management, users, and developers of RPA technology. Furthermore, we analyzed the automated business process, and documented results which allowed us to investigate the efficiency gains enabled by RPA. In addition, we will present action principles in preparing and implementing RPA for other adopters.

The research paper starts with a literature review on RPA (chapter 2). Afterwards, the case study is described in more detail (chapter 3), and the results and action principles are discussed (chapter 4). Finally, the paper ends with a conclusion and outlook on further research aspects (chapter 5).

2. Literature Review

The term RPA is often associated with physical robots that automate processes. The focus, however, is not on production processes, but on repetitive and dreary tasks that are performed on computers (reporting, data transfer, invoicing, etc.) in the virtual world [4].

RPA is synonymous with a software license that takes over human tasks previously performed manually by employees. As a result, employees are free to focus on non-routine and creative tasks. RPA interacts with existing systems like a human would. Unlike Business Process Management (BPM) solutions, no interfaces or even systems need to be adapted. In addition, employees need no programming skills and can automate their own processes after only a short training period. Implementation of RPA primarily requires process knowledge instead of technical understanding [2]. According to the Institute for Robotic Process Automation & Artificial Intelligence [5], RPA solutions support employees in performing transactions, data manipulation and communicating with digital systems.

Today companies have access to a wide range of automation software. Some studies described the differences between three leading platforms: UiPath Studio, Automation Anywhere and BluePrism [6]. Companies looking for RPA opportunities might consider several criteria for identifying the best-suited processes for RPA [7]. A four-step approach which supports companies to evaluate process eligibility is given in [8]. According to this approach, only rule-based processes that require manual interaction with a software application suit automation. Some authors propose further models to analyze processes and determine if RPA technology should be implemented [9].

Recent studies report numerous benefits by using RPA. A Business Process Outsourcing (BPO) service provider, for example, automated a process to generate a payment receipt. Two groups were formed (one with and one without RPA) in order to analyze the results. The group with RPA was able to handle 21% more cases, thus the main benefit was increased productivity (measured by cases per agent). Mean case duration, in contrast, was similar due to skilled employees performing some activities quickly. Productivity, however, was higher because the RPA solution processes many transactions simultaneously [1].

Another case study at Telefónica O2 shows that RPA enables faster and more accurate performance of business processes. Telefónica O2 started the RPA journey in 2010 and implemented an RPA solution using BluePrism software. Over 160 robots were deployed to perform 400,000 to 500,000 transactions per month. As a result, turnaround time was reduced from several days to a couple of minutes in some processes and customers “chase up” calls have been reduced by over 80% per year. RPA can achieve an annual return on investment of up to 200% [2].

Accounting and finance also explore RPA to increase efficiency. RPA can execute financial transactions, managing data as well as monitoring and reporting tasks. RPA, however, is not prone to human error and enables continuous performance of processes. The entire end-to-end process should be analyzed to identify best suited processes for automation. Therefore, a financial service company considered several criteria: The company determines potential savings in time (annual hours) for each process step. Companies should take into account that savings in high-cost regions may differ from those in low-cost regions. RPA’s prerequisites are processes that have been performed over multiple periods and do not require professional judgements. Data coordination should be limited to a few systems without necessary manual intervention. In accordance with these criteria, the company ranks the processes as low, medium or high for automation. The financial service company identified tax consolidation process as suitable for RPA. As a result, 2,800 working hours were saved, employees were relieved, and manual errors were reduced [3].

Xchanging, a business process and technology service provider, uses RPA to manage transactions for a client in insurance sector. Xchanging performs the insurance premiums for brokers. The company deployed RPA to perform parts of this process (finding errors in data, retrieving data, etc.) and consequently reduced the processing time for 500 notes from several days to 30 minutes. The Associated Press (AP) also deployed RPA and automated earning reports because journalists preferred to cover stories instead of dreary tasks. By means of automation, AP saves three full-time equivalents (FTE) and expands its coverage [4].

However, some authors also emphasize the disadvantages and risks of RPA. Under certain circumstances immature and flawed RPA can lead to lower productivity and higher error rates [10]. Furthermore, deploying RPA without initial testing entails high risks of error rates [11]. In addition, jobs may be lost due to efficiency gains, or employees may need retraining to pursue other activities [7]. Finally, studies mainly focus on theoretical foundations and use cases in finance and outsourcing. Apart from this, there is only little research for identifying the best-suited processes for RPA [12].

3. Case Study

3.1. Background

The case study was conducted in the QM department of MB. This department is responsible for the Conformity of Production (COP) and thus for the quality assurance of all vehicles worldwide. The QM, however, is faced with the challenge to ensure the validity of component certificates for the Chinese market due to strict regulatory requirements, regular audits by authorities and missing information flow between MB and its suppliers. Numerous countries require market-specific certification of products to guarantee product quality. These regulations are subject to constant change and must be complied at any time to avoid restrictions by authorities. The Chinese authority defines several products as relevant for China Compulsory Certification (CCC). MB and its suppliers must comply with these strict requirements to sell these products in Chinese market. MB’s suppliers therefore have to certify their products by the respective authority. After successful certification, MB is allowed to assemble products in vehicles. In detail, CCC-relevant components must provide the following features: model name, manufacturer name or trademark, factory code and mark of authority (CCC logo). After approval by the authority, both the supplier and MB have to store the product’s certificate. In most cases, suppliers are given access to a supplier data base (SDB) for uploading the product certificates. If the supplier changes a feature, e. g. a model name, they have to ensure a reissue of the certificate by the authority. After reissuance, the old certificate loses its validity. Furthermore, the recent certificate must be uploaded by the supplier to ensure the MB’s SDB is up to date. Otherwise, MB will no longer have valid certificates. Continuous information flow between suppliers and MB is necessary due to numerous purchased parts in the automotive industry. In regular audits, the authorities check the certificates’ validity in SDB. In the case of invalid product certificates, restrictions can be imposed.

3.2. As-Is Process

The SDB of MB stores a total of approximately 1500 certificates uploaded by suppliers. In preparation for an audit, a random check of 1150 certificates ranging from July to October 2018 which was conducted by an external service provider identified 43% invalid or missing certificates in SDB. The certificate check was performed once and not continuously. The random check was time-consuming, error-prone, rule-based, repetitive, and not feasible on a regular basis due to capacity reasons. In the following months, suppliers were informed and asked by MB to upload a valid certificate on the SDB. Due to the deviations found, MB decided to initiate another certificate check in April 2019. The certificate check was carried out to inspect all 1500 uploaded component certificates in SDB and monitor the processing status of the deviations found by the service provider in the previous check. Some of the suppliers, however, were not connected to the SDB so that these certificates were partly stored on other databases. Thus, MB distinguished between invalid and missing certificates. To gain more transparency, MB checked how many certificates were invalid or missing. As a result, 17% of the certificates were still invalid and 22% not even uploaded to the SDB at all. MB then decided to connect all suppliers to the SDB in medium term but to focus on the invalid certificates first. The manual inspection took 229 hours.

The business process of manual certificate check is described in Fig. 1. First, the QM employee opens the technical registration document of the series which is to be tested. A technical registration document is a list of technical data of the series (dimensions, weight, etc.), installed components (tires, catalytic converters, etc.) and their specifications (model name, factory code, manufacturer, certificate number, etc.). Each series has several technical approval documents (Excel files) for different model types, each of which have about 2,800 rows, up to 10 columns and over 28,000 filled cells. For a complete certificate check of SDB, around 80 technical registration documents have to be checked. The QM employee searches for all certificate numbers in the technical registration documents and saves them in a new checklist. The certificate numbers have either 16 digits or 19 digits and can thus be identified. Since a component occurs in several series and a certificate number can also occur in several technical registration documents, the duplicates must be removed from the checklist at the end. Subsequently, each certificate number is queried individually in the SDB and the corresponding issue date is copied and pasted into the checklist (As-Is). This process is error-prone, since the system displays all certificates during data query which were ever uploaded by the supplier. In this process step, it is therefore crucial to select the latest certificate on the SDB. The issue date is found both on a scanned component certificate (PDF) and in a data field provided and uploaded by the corresponding supplier. Afterwards, the certificate number is retrieved on the publicly accessible authority website and the issue date and supplier name is copied and pasted into the checklist (To-Be). Finally, the two issue dates are compared. A data inconsistency occurs if a more recent issue date is found on the authority website than in the SDB. In this case, the supplier has applied for and been issued with a new certificate by the authority but has not uploaded it to SDB. Finally, the deviations found are summarized in an Excel report and sent to the procurement department. The procurement department searches for the responsible supplier for each certificate number in the Excel report and requests the respective supplier to upload a valid certificate in SDB.

Figure 1. As-Is Process

3.3. To-Be Process

MB planned to automate this business process by using RPA due to the high manual error rate, and the high workload (e. g. searching through more than 28,000 cells in up to 80 technical registration documents and copy and paste a large amount of data). Since MB had no previous experience in using RPA, external consultants carried out a proof of concept to determine the feasibility of an automated business process. Furthermore, process time and capacity savings were analyzed. Subsequently, MB discussed whether RPA should be implemented. After the proof of concept which lasted for a total of 3 weeks, MB decided to implement an attended RPA, performing on a dedicated notebook (on-premise). The attended RPA facilitated ad-hoc certificate checks of individual series at any time and is supervised by an employee. In coordination with the IT department and the external consulting firm, UiPath served as the automation software.

The proof of concept showed that automation of almost all process steps is possible. Only the query on the publicly accessible authority website (To-Be data) must still be performed manually since the website is secured by a captcha. MB decided that an internal service provider should deal with this manual query owing to capacity reasons. External consultants supported MB to carry out the development of RPA, which took about two months. Go-live was in June 2019. MB decided that a complete certificate check should be carried out at the beginning of each month. This is sufficient since only 4% of the To-Be data change each month. Therefore, the internal service provider only has to query once a month. MB continuously tracks the status of the invalid and missing certificates to ensure data consistency in the SDB and to remind the supplier again if necessary. These status certificate checks weekly inspect whether the deviations found at the beginning of the month had been corrected without updating the respective To-Be data. Shorter intervals are inappropriate as the procurement department usually needs three to five days to contact the supplier regarding the invalid certificates.

Fig. 2 describes the To-Be process implemented. Before the RPA is started, a QM employee must select the technical registration documents. This step is not automated in order to give QM the opportunity to perform ad-hoc checks of series. Subsequently, RPA begins and all 16-digits and 19-digits certificate numbers are searched for in the technical registration document and saved in a separate checklist. For this purpose, VBA (Visual Basic for Application) macros were programmed. RPA saves the checklist and the QM employee sends it to an internal service provider who performs the query on the publicly accessible authority website (To-Be data). Subsequently, the certificate numbers are retrieved in the SDB via mass query and the corresponding date of issue for each certificate number is copied into the checklist (As-Is data). The challenge for RPA is that a maximum of 30 certificate numbers can be processed simultaneously by the SDB. Furthermore, all certificates ever uploaded by the suppliers are displayed in data output. RPA therefore uses VBA macros to filter the latest data uploaded by the supplier in SDB.

Figure 2. To-Be Process

Once the internal service provider’s results (issue date and supplier name) are available, two issue dates are finally compared. If a more recent issue date for a certificate number is found on the authority website than in SDB, this deviation is listed in an Excel report and sent to the procurement department. The procurement department then requests the respective supplier to update the invalid certificate in SDB.

4. Results

Automating almost all process steps contributes to reduce the process time significantly. Only the query on the publicly accessible authority website still operates manually. At the beginning, the internal service provider needed 50 hours for this manual process step. The automated process steps, however, could be performed by using RPA in about 1 hour, reducing the total process time from 229 hours to 51 hours. The weekly status certificate checks are performed without updating the To-Be data and the total process time can therefore be reduced from 179 hours to 1 hour.

In addition, the use of RPA technology significantly improved data quality in SDB. From April to October 2019, the percentage of invalid certificates decreased from 17% to 5%. The premium vehicles for the Chinese market were also reviewed several times on an ad-hoc basis with the result that no deviations were identified in August 2019. RPA eliminated manual errors during the certificate check completely. Only the manual query of the To-Be data by the internal service provider was still error-prone at the beginning. Partial automation, however, transformed the copy and paste process so that the error rate was reduced to less than 1%. In addition, the process time for querying the To-Be data reduced from 50 hours to 25 hours and the total process time decreased from 229 hours to 26 hours. In the end, the use of RPA technology saved 5.075 FTE.

The case study gives insight into principles which support successful implementation of RPA. A decisive factor therefore is the early involvement of all relevant departments. In the case study, process automation was initialized by QM but not by the IT department. Early involvement in topics like process documentation, software licenses, and debugging during operation, however, is crucial to save costs and avoid further coordination during development. In addition, it was important to coordinate the process with the procurement department and certification department before implementing RPA and to clarify the responsibility for the supplier. These procedural issues should be aligned as early as possible to avoid delaying the development and to ensure a trustworthy cooperation. We also point out that the involvement of an external consulting firm accelerated the development. In addition, the external consulting firm coordinated the certificate checks at the beginning and accompanied the handover of RPA to a subsidiary which is responsible for further development and debugging.

MB gained valuable process knowledge through the certificate check which was carried out manually in advance. We emphasize that MB performed an overall certificate check for all current certificates once before automation. The lack of manual execution was due to capacity reasons and therefore MB performed certificate check for a particular scope of certificates when needed. We encourage potential RPA users to run a process before automation. However, based on the case study, it is also possible to generate enough process knowledge by performing a new process once. Relevant stakeholders have to verify the results generated by RPA before deployment. Initially undetected errors can lead to further problems during regular operation and stakeholders may lose confidence in RPA. In the worst case, these errors cause failure of the project. In addition, RPA solutions need to be adapted immediately in case of change requests to prevent incorrect results. In the case study, for example, adjustments are necessary if the authority changes the structure of the certificate numbers (e. g. from 16 digits to 14 digits) or if captchas block the manual query on the publicly accessible authority website (To-Be data). We also recommend creating an operating manual for RPA solutions which should be approved by all stakeholders in the development process. The operating manual has to explain reasons for implementing RPA. MB, for example, explained these reasons based on a process evaluation and considered direct and indirect benefits. Direct benefits comprise the reduction in process time and capacity savings in FTE; indirect benefits include, for example, the avoidance of regulatory risks or the increase in customer satisfaction. MB’s major benefit was to successfully pass audits and avoid an import stop of vehicles. The operating manual also needs to include a complete process description and a detailed technical description. At MB, human beings interact with RPA since an employee selects the series and starts RPA. This process knowledge must be documented to allow new employees to quickly perform the process. The technical description helps to adjust RPA if an engineering change is requested by stakeholders.

5. Conclusions

The novelty of the case study lies in the application of RPA in QM to ensure product compliance and to free up capacity. The results show that RPA reduces process time in QM from 229 hours to 26 hours, improves process quality and saves 5.075 FTE. MB automated a process that was not continuously performed before. We propose to focus on validating the results of RPA instead of manually performing the process several times. RPA is still limited to rule-based processes. By using Artificial Intelligence (AI), especially machine learning, even more complex use cases become technically feasible. Based on the use case described in this case study, MB discovered further automation potential; for example, data in the technical documentation and the component certificates must match. If a supplier updates a component certificate (e. g. due to the change of a manufacturer name), the technical documentation must also be revised. Therefore, MB conducted a proof of concept using an Optical Character recognition (OCR) and RPA to speed up the transfer of technical data to IT systems and reduce the manual errors. MB also tested OCR and RPA for the transfer of certificate data directly into technical documentation. We propose to review existing automation solutions continuously and to improve them by means of AI. For MB, the RPA represented a starting point for evaluating further use cases.