Kunskap anses idag vara den viktigaste faktorn för att skapa konkurrenskraftiga organisationer. I projektverksamheter har kunskap ännu större betydelse, då medarbetarna är uppdelade i fristående projekt och distansen mellan dem är större än i traditionella linjeverksamheter. Detta har resulterat i omfattande forskning kring Knowledge Management (KM) i projekt-organisationer. Forskningen har då utgått ifrån traditionell projektledning som härstammar ifrån tillverkningsindustrin. Inom systemutveckling har nya projektledningsmetoder utvecklats som är anpassade till denna bransch och kallas för agila metoder. Inom detta område saknas det forskning och eftersom systemutveckling är en kunskapsintensiv bransch är det intressant att undersöka hur KM bör anpassas till agila utvecklingsmetoder. Studiens syfte är att skapa förståelse kring hur kunskapsöverföringen kan förbättras hos organisationer som bedriver systemutvecklingsprojekt utifrån agila metoder. Detta har åstadkommits genom en fallstudie på Trafikverkets avdelning för systemutveckling. Data-insamling har skett genom observationer och semistrukturerade intervjuer med tio anställda på Trafikverket samt med tre oberoende experter inom agil systemutveckling. Studien visar att agil projektledning förbättrar resultat och kunskapsöverföring inom systemutvecklingsprojekt (intra-projektlärande), eftersom systemutveckling domineras av tyst kunskap som agila metoder är bra på att ta vara på. För att förbättra kunskapsöverföring för hela organisationen (inter-projektlärande) behövs dock ytterligare stöd. Organisationer bör anta ett holistiskt synsätt med hänsyn till KM-strategi, ledningsstöd, företagskultur, incitament, processer, IT-verktyg, kommunikation, utbildning och mätvärden. Praktiska rekommendationer ges för hur dessa nyckelfaktorer kan förbättras. KM-strategin är den övergripande nyckelfaktorn som bör ha syftet att förbättra nätverkande och interaktion mellan människor. Dokumentation av kunskap bör ske lätt och dynamiskt med syftet att kartlägga var i organisationen kunskap finns. Övriga nyckelfaktorer fungerar som stödjande funktioner för att kunna uppnå KM-strategin.

The goal of this project has been to create an interface for time accounting thatthe digital agency Devize can use in its own system Devize Admin. In the project, the work has been carried out in an agile development with various elements. As an introductory step, the work has consisted of planning followed bycreating design sketches/prototypes. User tests have since been performed where Devize's own developers have tested the prototypes. The tests have then beencompiled to find improvements which then have been implemented in a newversion of the prototype. In the process, the interface has since been developedwith the front-end framework React Admin within the frameworks and rulesfound in Devize's graphic profile and the existing system Devize Admin. In parallel with front-end development, back-end functionality has been developed ina sister project that the interface has since used to be able to handle and accessdata. Continuously through interface development, the environment has alsobeen tested in the browser and console to detect potential error messages andunclear structures. Based on the development process that has been carried outand the functionality that has been implemented, the application has resulted inan interface for time accounting that has the basic functionality that is necessaryto be able to report time. With that outcome, a conclusion has been drawn that the outcome is to some extent consistent with the project's set goals. / Målet med detta projekt har varit att skapa ett gränssnitt för tidsredovisning som digitalbyrån Devize kan använda i sitt egna system Devize Admin. I projektet har arbetet utförts i en agil utveckling med olika moment. Som inledande moment har arbetet bestått av planering följt av att skapa designskisser/prototyper. Användartester har sedan utförts där Devize egna utvecklare har testat prototyperna. Testerna har sedan sammanställt för att hitta förbättringar som sedan har implementerats i en ny version av prototyp. I processen har gränssnittet sedan utvecklats med frontend-ramverket React Admin inom de ramar och regler som finns i Devize grafiska profil samt det existerande systemet Devize Admin. Parallellt med frontend-utveckling har backend-funktionalitet utvecklats i ett systerprojekt som gränssnittet sedan har använt sig av för att kunna hantera och komma åt data. Kontinuerligt genom gränssnittsutveckling har miljön även testats i webbläsaren och konsolen för att upptäcka potentiella felmeddelanden och oklara strukturer. Utifrån den utvecklingsprocess som genomförts och den funktionalitet som implementerats, har tillämpningen resulterat i ett gränssnitt för tidsredovisning som har grundläggande funktionalitet som är nödvändig för att kunna tidsredovisa. Med det utfallet har en slutsats dragits om att utfallet till viss del stämmer överens med projektets uppsatta mål.

The purpose of a support organisation is to provide help and support around something. To provide help and support to users of software may involve guiding users how the software is supposed to work, investigate why the software may not work as intended or to fix software errors. A prerequisite for the support organisation to be able to provide this help and support is that it itself has a certain degree of understanding of the software. A good tool for understanding software is documentation. Well-written documentation is easy to understand, updated, correct and describes the software in a pedagogical way. This study aims to investigate which deficiencies in documentation complicates the work of a support organisation and in what way the work is made more difficult by these deficiencies. The study is in the form of a qualitative interview study, conducted at Novacura’s support organisation. To analyze the result, Documentation Process Maturity Model (Visconti & Cook, 1993), which defines different quality levels of documentation and criterias for achieving these levels, as well as previous research, has been used. The study identified eight different deficiencies in the documentation as well as eight consequences for these deficiencies. The study also showed that the documentation at Novacura is located between level 1 and 2 of the Documentation Process Maturity Model. / En supportorganisation har syftet att tillhandahålla hjälp och stöd kring något. Att ge hjälp och stöd till användare av mjukvara kan innebära att vägleda användaren hur mjukvaran är tänkt att fungera, undersöka varför mjukvaran inte fungerar som tänkt eller åtgärda fel i mjukvaran.  En förutsättning för att supportorganisationen ska ha möjlighet att tillhandahålla detta stöd är att den själv har en viss grad av förståelse mjukvaran. Ett bra hjälpmedel till att förstå mjukvara är dokumentation. Välskriven dokumentation är lättöverskådlig, uppdaterad, korrekt och beskriver mjukvaran på ett pedagogiskt sätt. Denna studie ämnar att undersöka vilka brister i dokumentation som försvårar arbetet i en supportorganisation samt på vilket sätt arbetet försvåras av dessa brister. Studien är i form av en kvalitativ intervjustudie, utförd på Novacuras supportorganisation. För att analysera resultatet har Documentation Process Maturity Model (Visconti & Cook, 1993), vilken definierar olika kvalitétsnivåer på dokumentation och kriterier för att uppnå dessa, samt tidigare forskning använts. Studien identifierade åtta olika brister i dokumentation och åtta påföljder av dessa brister. Den visade även på att Novacuras dokumentation befinner sig mellan nivå 1 och 2 i Documentation Process Maturity Model.

In today’s modern society information technology (IT) is being used more than ever. Computers, smartphones, and other electronic devices where the user interacts with the software creates new demands on the developers. To meet the new requirements, users are invited to participate in the design process to secure high level of usability. Research shows that effective user involvement tends to stop when the system has been implemented, even though most of the requirements can be successfully evaluated after the system have been implemented. The purpose of this study is to examine what factors that contribute to effective user involvement after a system has been implemented and how an interface for the purpose should be designed. The study is conducted in collaboration with a company that is developing a new system for an organization in the public sector. Four semi-structured interviews were executed with a variation of respondents from system administrators to end users. The results show that easily accessible feedback function in the system was a key factor. Furthermore, the author has obtained seven requirements for a successful feedback function. These seven requirements are “Ease of use”, “Constant presence”, “Transparency”, “Frequently asked questions”, “Multimedia annotations”, “Priority list” and “Notices”. These requirements were the basis of the prototype of a feedback function that the author designed for the new system.

Viljan att hålla en hög kvalitet på den kod som skrivs vid utveckling av system och applikationerär inte något nytt i utvecklingsvärlden. Flera större företag använder sig av olika mått för attmäta kvaliteten på koden i sina system med målet att hålla en hög driftsäkerhet.Trafikverket är en statlig myndighet som ansvarar för driften av bland annat de system somhåller igång Sveriges järnvägsnät. Eftersom systemen fyller en viktig del i att säkra driften ochse till att tågpositioner, planering av avgångar och hantering av driftstörningar fungerar dygnetrunt för hela landet anser de att det är viktigt att sträva efter att hålla en hög kvalitet påsystemen.Syftet med det här examensarbetet var att ta reda på vilka mått som kan vara möjliga attanvända under systemutvecklingsprocessen för att mäta kvaliteten på kod och hur måtten kananvändas för att öka kvaliteten på IT-lösningar. Detta för att redan på ett tidigt stadie kunnamäta kvaliteten på den kod som skrivs i både befintliga och nyutvecklade system.Studien är en fallstudie som utfördes på Trafikverket, de olika måtten som undersöktes varcode coverage, nivån på maintainability index och antalet inrapporterade incidenter för varjesystem. Mätningar utfördes på sju av Trafikverkets system som i analysen jämfördes motantalet rapporterade incidenter. Intervjuer utfördes för att ge en bild över hur arbetssättet vidutveckling kan påverka kvaliteten. Genom litteraturstudier kom det fram ett mått som inte kundeanvändas praktiskt i det här fallet men är högst intressant, detta är cyclomatic complexity somfinns som en del av maintainability index men som även separat påverkar möjligheten att skrivaenhetstest.Resultaten av studien visar att måtten är användbara för ändamålet men bör inte användassom enskilda mått för att mäta kvalitet eftersom de fyller olika funktioner. Det är viktigt attarbetssättet runt utveckling genomförs enligt en tydlig struktur och att utvecklarna både harkunskap om hur man arbetar med enhetstest och följer kodprinciper för strukturen. Tydligakopplingar mellan nivån på code coverage och inflödet av incidenter kunde ses i de undersöktasystemen där hög code coverage ger ett lägre inflöde av incidenter. Ingen korrelation mellanmaintainability index och incidenter kunde hittas. / The desire to ascertain a high level of quality on the code written during the development of systems and applications is not something new in the system development world. Several larger companies use different kinds of metrics to measure the quality of the code in their systems with the goal of maintaining high reliability and quality.Trafikverket is a government authority responsible for the operation of the system that keeps the Swedish railroad running. Their systems play an important part in ensuring the operation and to ensure that train positions, the planning of departures and error handling works around the clock for the entire country, they find it important and strive to maintain the high quality of the systems.The aim of this thesis was to find out which measurements may be possible to use during the system development process to measure the quality of the code and how measurements can be used to increase the quality of IT solutions. It should be possible to measure the quality of the code that is written in both existing and newly developed systems at an early stage. The study is a case study conducted at Trafikverket, the metrics that were examined were code coverage, the level of maintainability index and the number of reported incidents for each system. Measurements were performed on seven of Trafikverket's systems. In the analysis the measurements were compared to the number of reported incidents. Interviews were conducted to provide a picture of how the operation of the development may affect the quality. Through literature studies we discovered a metric that could not be used practically in this case, this was cyclomatic complexity, it is available as part of the maintainability index, but also separately affects the ability to write unit tests. The results of the study show that the measurements are useful for this purpose but should not be used as individual metrics to measure quality because they all have their own function. A clear link between the level of the code coverage and the number of incidents could be observed in the investigated systems where high code coverage provides a lower rate of incidents. No correlation between maintainability index and incidents could be found.

<p>Vad kan man idag begära av ett informationssystem?</p><p>Det står klart att informationssystem ska stödja och ersätta arbetsuppgifter inom företag för att öka effektiviteten eller minska kostnaderna. Men vilka arbetsuppgifter ska ett system klara av att göra lika bra som en människa och hur ska det lyckas göra lika bra bedömningar om vad som bör göras när man möter en svår uppgift, där det kanske verkligen behövs ett bra IT-stöd för att enklare ska klara av situationen?</p><p>Bakgrunden till vårt arbete grundades på en tidigare undersökning en av oss gjort på sågverket där man hade problem med lagerstyrningen. Det rekommenderades då att Bodafors skulle implementera truckdatorer och en grafisk truckmodul för effektivare lagerhantering med hjälp av RFID. Det beslutades då att ett första steg skulle genomföras under hösten med truckdatorer i två av truckarna och en utbyggnad av det befintliga systemet för att truckförarna ska få se en aktuell bild över lagret och utlastningarna som ska ske under veckan.</p><p>Vi kom fram till att SYSteams arbetssätt grundade sig på vattenfallsmodellen som kanske är den mest klassiska modellen för systemutveckling, med sina rötter på 60-talet. Vi konstaterade också att man har mycket att lära av modern Knowledge Management-teori som försöker fånga kompetenser och kunskap hos individer i system för att uppmuntra en företagsmiljö där kunskap delas mellan individerna. Vi sammanställde en serie konkreta råd för systemutvecklare för att bli bättre på att fånga kunskap i en systemutvecklingsmodell med en iterativ utvecklingsprocess som vi kallar för kunskapsfrämjande systemutveckling.</p> / <p>What can be expected of an information system today?</p><p>It stands clear that information systems should support and replace tasks within companies to enhance efficiency and/or reduce costs. But which tasks should we rely on that a system could manage as well as a human being can today? Especially in difficult situations where human experience is put to the test and where we really could use the help of an information system to make the right judgements.</p><p>The background of our essay was based on a former investigation one of us made during the spring of 2006 in the company due to logistic problems in the warehouse. It was then recommended that Bodafors should get truck computers and a graphic truck module for more efficient warehousing alongside with RFID. It was decided that a first step was to be taken during the autumn with computers in two of the trucks and the implementation of a system for trucks for an outline of the actual supply in the warehouse and the current orders to be loaded during the week.</p><p>We reached the conclusion that SYSteams development of TruckSaw was founded on the classic waterfall model, with its roots in the 1960’s. We also learned that developers has alot to learn from modern Knowledge Management theory, with its focus on catching key competence and knowledge within an organisation and the creation of an environment encouraging the sharing of competence and knowledge. With a Knowledge Management driven approach we put together a series of advice for developers to become better at catching knowledge by using a different, iterative approach to developing a system, knowledge promoting system development.</p>

<p>The Thesis purpose is in the context of system development validate the Scrum Methodology. Projects concerning information technology are difficult to manage and tend to fail in quality, time or costs. Scrum presents a new view of the system development. Better cooperation between customers and developers, continuous follow-up on daily basis and extensive communication in the development team are all characteristics of Scrum. Scrum is described as a new paradigm by its founders but has been criticized by experts of system development too. This Thesis discuss if Scrum is a better way to develop software than older models like the Rational Unified Process and the Spiral Model with focus in five factors. The result of the study is that Scrum has given system development new ways to manage requirements and methods to push the project forward. Lack of management commitment and user involvement can be better with Scrum if the model is used in the right way. Answers concerning coding and testing differ between the respondents in the study which makes it different to make conclusions regarding this factor.</p> / <p>Syftet med uppsatsen är att i en systemutvecklingskontext beskriva de problem som gör att IT-projekt misslyckas och utvärdera om användningen av den agila utvecklingsmodellen Scrum reducerar problemen. IT-projekt tenderar att misslyckas och de bakomliggande orsakerna är flera. Uppsatsen grupperar misslyckande av IT-projekt i fem faktorer. Ledningsstöd, användarmedverkan, projektstyrning, kravhantering samt kodning och test. Scrum är en agil systemutvecklingsmodell som av sina skapare beskrivits som ett paradigmskifte inom systemutvecklingen. Korta tidsintervaller, självgående systemutvecklare, daglig uppföljning är några av Scrums kännetecken. För att besvara syftet har en kvalitativ datainsamlingsmetod använts. En intervjuserie med tio intervjuer och en observation ligger till grund för undersökningens resultat. All insamlad data är insamlad på fallföretaget Banverket Verksamhetsstöd IT. Undersökningen har visat att Scrum ger en del nya angreppssätt främst avseende projektstyrning och kravhantering. Scrum innehåller möjligheter för ökad användarmedverkan och ledningsstöd men det krävs konkreta åtgärder från projektorganisationen om det ska lyckas fullt ut. Uppfattningar kring kodning och test skiljer sig åt beroende på vilken respondent som frågas. Det tyder på att det saknas tydliga rutiner i det här avseendet. Slutsatsen blir därmed att Scrum reducerar några av de problem som finns i IT-projekt och därmed med fördel kan användas som en best practice.</p>

Nutida organisationer och företag har svårt att undvika användningen avinformationsteknologin (IT). Den stora utmaningen är att lyckas med införandet av etttredjepartssystem i form av ett IT-projekt med ett positivt resultat. Trots att detta anses viktigtstår många organisationer och företag i behov och saknar konkreta förslag för att lyckas vidett införande av ett informationssystem. Därför vill vi åstadkomma med framgångsfaktorervid införande av ett tredjepartssystem i en stor verksamhet.Vi har deltagit och varit aktiva i en fallstudie hos Västfastigheter, därför har uppsatsen etttolkande synsätt. Datainsamling och empirisk data har även kompletterats med intervjuer samtett studiebesök hos en organisation. Denna organisation har infört ett liknandeinformationssystem vilket vår fallstudie fokuseras på.Framtagning av relevanta teorier används som grund för att få en större förståelse för attlyckas vid ett IS införande. Teorierna beskriver vad ett IS är, IT-projekts faser och varförinförandet kan misslyckas samt hur relationer, kommunikation och användarna ska hanterasdå man ska införa ett IS.Utifrån den insamlade teorin och empirin utfördes en analys och detta ledde tillundersökningens slutsatser. Denna uppsats har gjort att vi kommit fram till ett antal faktorersom man bör ha med sig för att lyckas vid ett informationssystems införande, här nedanpresenteras en sammanfattning av framgångsfaktorerna:• Få stöd från verksamheten, främst från ledningen och beslutfattarna• Ett tydligt behov, syfte och värde fås fram av en väl genomförd nuläges- ochverksamhetsanalys• Involvera användarna• Kommunikation och stöd• Ta in hjälp från utomstående om det finns kunskapsbristSammanfattningsvis ser man att de vanligaste misstag som kan uppstå är:1. Man involverar användarna för sent2. Inget stöd av verksamheten från början, främst från personer som har en starkpåverkan.3. Brist på teknikenDessa tre vanliga misstag ovan bör tas med redan vid initiering av arbetet med införande avett informationssystem. Men vi anser att varje enskild verksamhet kan anpassa sättet atthantera ett införande utifrån deras behov och krav, men bör ta hänsyn till dessa ovanståendefaktorer och misstag. / Program: Systemvetarutbildningen

<p>Ett problem med elektroniska patientjournalsystem är att arkitekturen för patientjournalerna inte är gemensam vilket försvårar automatiskt utbyte av patientdata. En arkitektur har skapats inom ett projekt som heter openEHR. Förhoppningen är att denna arkitektur ska klara av automatiskt utbyte av patientdata mellan elektroniska patientjournalsystem.</p><p>I openEHRs arkitektur används något som kallas arketyper. Arketyper är återanvändbara modeller för att begränsa, strukturera och förklara vad som lagras i elektroniska patientjournaler som bygger på denna arkitektur. Istället för att områdesspecifik information, som vad ett blodtryck är, skapas i systemet flyttas den och annan liknande kunskap ut från systemarkitekturen och in i arketyperna. Arketyper kan skapas och redan existerande arketyper förändras utan att några ändringar i systemarkitekturen behöver göras.</p><p>Huvudproblemet i examensarbetet har varit att hitta en metod för att generera ett grafiskt gränssnitt utifrån en elektronisk patientjournal som är konstruerad med hjälp av arketyper. För att lösa detta behövdes det först skapas arketyper och ett system för att generera journaler utifrån dessa. Därefter har en webbportal utvecklats där det går att logga in och läsa de skapade patientjournalerna. Metoden för att generera gränssnittet i webbsidorna använder sig av en rekursiv funktion för att samla in information ur patientjournalerna. Funktionen lagrar den insamlade information i en objektstruktur som följer designmönstret Composite. Utifrån denna struktur går det sedan att generera ett grafiskt gränssnitt.</p><p>Webbportalen kan användas för att demonstrera hur ett system kan se ut där både patienter och behörig personal får tillgång till och möjlighet att läsa inlagda journaler som bygger på openEHRs arkitektur.</p> / <p>One problem with electronic health record systems is that the health records are not built on a common architecture. This makes automatic exchange of patient data difficult. openEHR is a project that has developed an architecture that tries to solve this problem.</p><p>The openEHR architecture uses something called archetypes. Archetypes are reusable models that limit, structure and explain what will be stored in the electronic health record that is built on this architecture.</p><p>The main goal of this master thesis has been to find a method to generate a graphical user interface from an electronic health record created using archetypes. To solve this problem first archetypes and a system that generates health records from these had to be created. Then a Web portal has been developed that displays the generated health records.</p><p>The Web portal can be used to demonstrate the graphical user interface of a system where both patients and authorized personnel can read patient records that are bases on the openEHR architecture.</p>

Flextronics Design i Linköping tillverkar prototypskretskort till telekomindus-trin. Examensarbetet tog de fram eftersom de upplever att de har problem medolika områden inom den funktion där själva tillverkningen sker, SMA (SurfaceMount Assembly). De var inte säkra på exakt vilka problemen var men de vis-ste att de rör rutiner, kommunikation, samt materialtillförsel. Genom att i ettexamensarbete definiera och lyfta fram problemen samt ta fram åtgärdsförslag,hoppades företaget att vissa av problem skulle kunna uppmärksammas ochlösas och på det sättet skulle kvaliteten i processerna öka. Genom att förbättravissa områden hoppades de även kunna bli effektivare i sitt arbetssätt vilketi sin tur skulle kunna frigöra värdefull kapacitet, något som är mycket viktigtför Flextronics i Linköping, eftersom de har hög beläggning.Syftet med examensarbetet var att genom en kartläggning tydligt definieraproblemen och ta fram förbättringsområden. Fokus lades sedan på det om-råde som ansågs viktigast att ta tag i. Målet var att ta fram ett konkret åtgärds-förslag, som löser de mest angelägna problemen, och som kan implementeraspå företaget.Kartläggningen bygger främst på ett stort antal intervjuer som gjordes med oli-ka personer som är involverade i SMA och dess stödprocesser. Det visade sigatt det var inom områdena strategier, kommunikation och informationssprid-ning, ansvarsområden, materialrutiner samt personalfrågor som problemenfrämst finns. Inom dessa områden definierades ett stort antal problempunkter,som var och en kategoriserades efter vilket ursprungligt problem de härstam-mar ur, alltså vad som skulle behöva förbättras för att få respektive problem-punkt åtgärdad. Det resulterade i åtta olika förbättringsområden, nämligenåterrapportering, kommunikation, spårbarhet, spill, sårbarhet, plock check, SMA-fel och ansvarsfördelning.Det förbättringsområde som ansågs viktigast att ta tag i var återrapportering.För att kunna förbättra den, och lösa de problem som fanns knutna till detproblemområdet, låg fokus under andra halvan av examensarbetet på att tafram ett informationssystem. Först togs strategier för både utveckling och im-plementering fram och därefter utvecklades systemet med hjälp av program-varan Microsoft SharePoint. Resultatet av arbetet blev informationssystemetReFlex som kommer att implementeras och börja användas på företaget.Med hjälp av ReFlex finns nu möjligheten att effektivisera arbetet på en radpunkter. Tack vare en effektiv återanvändning av informationen kan de frånoch med nu på ett bra sätt utnyttja tidigare erfarenheter, vilket gör att misstaginte behöver upprepas. Problem kommer inte behöva lösas flera gånger, vilketsparar mycket värdefull tid och frigör kapacitet. Kvaliteten i processerna kanöka, då problem kan uppmärksammas på ett smidigare sätt och därmed åtgär-das snabbare. / Flextronics Design in Linköping is an Electronics Manufacturing Services (EMS)company and manufactures printed circuit boards assemblies (PCBAs) for thetelecommunication industry. The site in Linköping is focused on prototypingPCBAs. They have problems regarding their SMA (Surface Mount Assembly)line, where the PCBAs are manufactured. The problems were not clearly de-fined in the beginning, but regarded routines, communication and materialsupply. By defining exactly where the major problems were and by solvingsome of these, they hoped that both the quality of their processes and the effi-ciency regarding their methods of working could improve. That could increasetheir capacity, something that would be valuable to Flextronics, since they areoften working above their capacity level.The purpose of this master thesis was to clearly define the problems through asurvey and suggest different ideas about which areas that should be improved.The area considered most important was then chosen for further work. Theobjective was to create a solution that solves as many problems as possible, asolution that could be implemented at Flextronics.The survey that was carried out is based on interviews with people involvedin the processes concerning SMA. The problems showed to involve strategies,communication and information sharing, management of responsibilities, rou-tines regarding material supply, and human resource issues. Within these ar-eas a large number of problem matters were defined. Each of these were cate-gorised based on what type of action that could solve that particular problem.The result was eight different action areas, that each could be the solution todifferent kinds of problems. The areas were; improving possibilities for report-ing and giving feedback, improving communication, improving traceability,decrease waste, decrease the vulnerability, improve routines for plock check,reduce the number of defect PCBAs due to SMA-problems and make the re-sponsibiliies more clear.The action area that was considered most important was increasing the possi-bilities for giving feedback. To make that happen, an information system wasdeveloped. First strategies for development and implementation was formu-lated and after that, the system was developed in Microsoft SharePoint. Thework resulted in the system ReFlex, that will be implemented at Flextronics.ReFlex will give the possibility to make work more efficient in many ways.Thanks to improved feedback possibilities they can now reuse information andtake advantage of prior experiences when starting a new build. The risk ofmaking the same mistake twice will decrease, which will save a lot of timeand thereby increase their capacity. The quality of the processes can also beincreased, since mistakes are more likely to be paid attention to and can therebybe solved faster.