This thesis is a feasibility study for a more comprehensive work at Process Automation (PA) ABB, Västerås. The business units this work is focusing on are Mining and Crane Systems with the mission to map their quality processes within supply collaboration, acceptance control and data such as their supplier’s fault frequency. This thesis was initiated because of an internal audit where these business units at PA received remarks on their long term quality development and that they didn’t calculated supplier faults. To evaluate these business units and to find the root causes of these problems, the involved staff was interviewed and their internal documentation database was examined. The work method that is used in this thesis is ABB’s 4Q and it’s practiced in quality development projects at ABB. The thesis report is also structured after 4Q. From the interviews could the conclusion be made that the remarks from the internal audit was correct, but that the business units had different root causes to their problems. It was made clear that Mining had problems with reporting faults found at site. It’s not possible to calculate metrics, that global ABB determined shall be used, if the occurring faults aren’t reported. A plausible root cause to why there are insufficient faults reported is that the business units’ decision-making authority haven’t succeed to reach out with enough information to the staff about the importance of the process. It has led to a staff that isn’t aware of the real usefulness of fault reporting. Even the 100k SEK guideline showed to be a root cause to the problem. This guideline hampers the possibility to collect relevant data and goes against ABB’s regulations to generate statistics. It makes it impossible to monitor field failure rates (fault at site) when minor fault are ignored because of the guideline. Crane Systems have on the contrary a functioning fault reporting process, but their shortage is in the generating of statistics. Even though the business unit has enough data to calculate and monitor their supplier’s error rate in the forms of lots accepted and PPM, are the statistics not communicated further. The statistics are neither reported internally within the organization, to the supplier or to central ABB. Both product and system managers generate their own statistics for their specific responsibility areas and needs, which mean that the general picture gets lost and the suppliers total fault frequency can’t be found. Summarized are these deficiencies leading to poor feedback to the suppliers about their delivered quality, and consequently makes it hard for the suppliers to know what to improve.

<p>Computer errors are a constant problem for software providers. To completely avoid bugs has proven very difficult even though computer software goes through rigorous testing before released. One of the challenges for developers is recreating errors that end-users experience. User-submitted error reports can often be of help for developers to localize and fix bugs. However, the reports often vary in quality depending on the user's experience and the effort they put into writing the report. Instead of relying on manual error reports, some software providers have equipped their software with automated error reporting functionality. These programs are set to collect important information about the computer and the software in the event of a crash. There are pros and cons with both automated and manual error reporting.</p><p>The research that has previously been done in the field of error reporting has mostly focused on the situation where private persons are senders and corporations are receivers. This report addresses the setting where both parties are corporations, which brings several new aspects to the problem. The five main topics this report focuses on are: customer attitude, which data to send, privacy, user interaction and feedback. A study has been conducted at the ERP system provider IFS in Sweden where interviews with employees and customers have been performed. Interviewees in the customer companies have been primarily ERP and application managers. The results of the study show that companies are less concerned than what the literature suggests even though the attitudes differ some depending on line of business. Conclusions are that a high degree of configurability of what is sent in the error reports and the level of user interaction is needed for companies to accept automated error reporting.</p> / <p>Buggar är ett ständigt problem för mjukvarutillverkare. Att helt undvika dessa har visat sig vara mycket svårt trots rigorösa tester innan ny mjukvara släpps. En av utmaningarna för utvecklare är att återskapa felen som uppstår hos användarna. Felrapporter inskickade av användare kan ofta vara till hjälp för utvecklare när de ska lokalisera och åtgärda fel. Men rapporterna kan variera i kvalitet beroende på användarnas erfarenhet och tiden de lägger på att skriva rapporten. Istället för att förlita sig på manuella felrapporter har vissa mjukvarutillverkare utrustat sin programvara med funktionalitet för automatiska felrapporter. Dessa program ska samla in viktig information om datorn och programvaran i händelse av att en krasch uppstår.</p><p>Viss forskning har skett inom området automatiserad felrapportering men fokus har då legat på situationen då privatpersoner är avsändare och företag är mottagare. Denna rapport behandlar läget då båda parter är företag, vilket tillför flera nya aspekter till problemet. De fem huvudfrågorna som den här rapporten fokuserar på är: kunders attityd, vilken data ska skickas, integritet, användarinteraktion och feedback. En studie har utförts hos affärssystemleverantören IFS i Sverige, där intervjuer med anställda och kunder har genomförts. De intervjuade hos kundföretagen har huvudsakligen varit ERP- och applikationsansvariga. Resultaten av studien visar att företagen är mindre oroade än vad litteraturen indikerar även om attityderna skiljer sig något i olika branscher. Slutsatserna är att en hög grad av konfigurerbarhet behövs när det gäller vad som skickas i felrapporter samt vilken grad av interaktion med användaren som behövs. Detta för att kundföretagen ska acceptera automatisk felrapportering.</p>

<p>The Swedish Transport Administration has, and manages, a database containing information of the status of road condition on all paved and governmental operated Swedish roads. The purpose of the database is to support the Pavement Management System (PMS). The PMS is used to identify sections of roads where there is a need for treatment, how to allocate resources and to get a general picture of the state of the road network condition. All major treatments should be reported which has not always been done.</p><p>The road condition is measured using a number of indicators on e.g. the roads unevenness. Rut depth is an indicator of the roads transverse unevenness. When a treatment has been done the condition drastically changes, which is also reflected by these indicators.</p><p>The purpose of this master thesis is to; by using existing indicators make predictions to find points in time when a road has been treated.</p><p>We have created a SAS-program based on simple linear regression to analyze rut depth changes over time. The function of the program is to find levels changes in the rut depth trend. A drastic negative change means that a treatment has been made.</p><p>The proportion of roads with an alleged date for the latest treatment earlier than the programs latest detected date was 37 percent. It turned out that there are differences in the proportions of possible treatments found by the software and actually reported roads between different regions. The regions North and Central have the highest proportion of differences. There are also differences between the road groups with various amount of traffic. The differences between the regions do not depend entirely on the fact that the proportion of heavily trafficked roads is greater for some regions.</p>

The Swedish Transport Administration has, and manages, a database containing information of the status of road condition on all paved and governmental operated Swedish roads. The purpose of the database is to support the Pavement Management System (PMS). The PMS is used to identify sections of roads where there is a need for treatment, how to allocate resources and to get a general picture of the state of the road network condition. All major treatments should be reported which has not always been done. The road condition is measured using a number of indicators on e.g. the roads unevenness. Rut depth is an indicator of the roads transverse unevenness. When a treatment has been done the condition drastically changes, which is also reflected by these indicators. The purpose of this master thesis is to; by using existing indicators make predictions to find points in time when a road has been treated. We have created a SAS-program based on simple linear regression to analyze rut depth changes over time. The function of the program is to find levels changes in the rut depth trend. A drastic negative change means that a treatment has been made. The proportion of roads with an alleged date for the latest treatment earlier than the programs latest detected date was 37 percent. It turned out that there are differences in the proportions of possible treatments found by the software and actually reported roads between different regions. The regions North and Central have the highest proportion of differences. There are also differences between the road groups with various amount of traffic. The differences between the regions do not depend entirely on the fact that the proportion of heavily trafficked roads is greater for some regions.

Computer errors are a constant problem for software providers. To completely avoid bugs has proven very difficult even though computer software goes through rigorous testing before released. One of the challenges for developers is recreating errors that end-users experience. User-submitted error reports can often be of help for developers to localize and fix bugs. However, the reports often vary in quality depending on the user's experience and the effort they put into writing the report. Instead of relying on manual error reports, some software providers have equipped their software with automated error reporting functionality. These programs are set to collect important information about the computer and the software in the event of a crash. There are pros and cons with both automated and manual error reporting. The research that has previously been done in the field of error reporting has mostly focused on the situation where private persons are senders and corporations are receivers. This report addresses the setting where both parties are corporations, which brings several new aspects to the problem. The five main topics this report focuses on are: customer attitude, which data to send, privacy, user interaction and feedback. A study has been conducted at the ERP system provider IFS in Sweden where interviews with employees and customers have been performed. Interviewees in the customer companies have been primarily ERP and application managers. The results of the study show that companies are less concerned than what the literature suggests even though the attitudes differ some depending on line of business. Conclusions are that a high degree of configurability of what is sent in the error reports and the level of user interaction is needed for companies to accept automated error reporting. / Buggar är ett ständigt problem för mjukvarutillverkare. Att helt undvika dessa har visat sig vara mycket svårt trots rigorösa tester innan ny mjukvara släpps. En av utmaningarna för utvecklare är att återskapa felen som uppstår hos användarna. Felrapporter inskickade av användare kan ofta vara till hjälp för utvecklare när de ska lokalisera och åtgärda fel. Men rapporterna kan variera i kvalitet beroende på användarnas erfarenhet och tiden de lägger på att skriva rapporten. Istället för att förlita sig på manuella felrapporter har vissa mjukvarutillverkare utrustat sin programvara med funktionalitet för automatiska felrapporter. Dessa program ska samla in viktig information om datorn och programvaran i händelse av att en krasch uppstår. Viss forskning har skett inom området automatiserad felrapportering men fokus har då legat på situationen då privatpersoner är avsändare och företag är mottagare. Denna rapport behandlar läget då båda parter är företag, vilket tillför flera nya aspekter till problemet. De fem huvudfrågorna som den här rapporten fokuserar på är: kunders attityd, vilken data ska skickas, integritet, användarinteraktion och feedback. En studie har utförts hos affärssystemleverantören IFS i Sverige, där intervjuer med anställda och kunder har genomförts. De intervjuade hos kundföretagen har huvudsakligen varit ERP- och applikationsansvariga. Resultaten av studien visar att företagen är mindre oroade än vad litteraturen indikerar även om attityderna skiljer sig något i olika branscher. Slutsatserna är att en hög grad av konfigurerbarhet behövs när det gäller vad som skickas i felrapporter samt vilken grad av interaktion med användaren som behövs. Detta för att kundföretagen ska acceptera automatisk felrapportering.