support system for sample...
TRANSCRIPT
SUPPORT SYSTEM FOR SAMPLE DISTRIBUTION
Abstract
With the growth of a company, working tasks can evolve to a whole new section this is the case for Sample Section at Sony Ericsson Mobile Communications in Lund. At a new section there is seldom time for process improvements and all time is absorbed by the daily work. This tends to erase section boarders, make the interfaces and the areas of responsibility vague and does not give the expected process benefits. The reasons can be that the working process is not clearly defined and can not be applied by the new section or the lack of good support systems.
Within this thesis the processes related to the relatively new section Sample Section are investigated and analysed, resulting in a new proposed working flow for Sample Section.
The thesis also results in a prototype support system existing of a database for controlling the information flow for the department. Also a prototype interface towards the stakeholders was implemented to database forms. This result is also based on interface analysis and interviews with Sample Section and other stakeholders concerned.
The structure of this prototype database will be used in a larger support system for the entire order and distribution process from the planning stage to the final delivery.
Acknowledgement
We would like to express our thanks to our supervisor at Sony Ericsson Mobile Communications, Magnus Hjern for giving us the opportunity to perform our thesis for Sample Section. We will express our special thanks to Sample Section, Maria Lindberg, Christer Andersson, William Romero and Linda Grönqvist for having patience with us when asking complicated questions.
Thanks also to Bengt Ljungquist PhD student at Department of Communications System, for reviewing our ER-model and some other database difficulties.
At last we will express our gratitude to our supervisors of Lund Institute of Technology, Per Runeson, professor at Department of Communication System and Bertil I Nilsson lecturer at the Department of Industrial Management and Logistics.
Thank you all for making our thesis a challenging assignment but also a happy end to our time of study at Lund Institute of Technology.
Sara Blomquist and Håkan Bengtsson
2 (60)
Table of Contents
1 Introduction.................................................................................................................................. 5 1.1 Company Description.............................................................................................................. 5
1.1.1 Company Values 5 1.1.2 Company Structure 6 1.1.3 Sample Section 7
1.2 Background............................................................................................................................. 7 1.3 Problem Area .......................................................................................................................... 8 1.4 Goal ........................................................................................................................................ 8 1.5 Expected Result ...................................................................................................................... 9 1.6 Report Outline ......................................................................................................................... 9
2 Theory......................................................................................................................................... 10 2.1 Process Theory ..................................................................................................................... 10
2.1.1 Process improvement 13 2.2 Interface Theory .................................................................................................................... 13 2.3 System Theory ...................................................................................................................... 15
2.3.1 Business Administration Systems 15 2.3.2 Databases 15 2.3.3 Spreadsheet 17
3 Methodology .............................................................................................................................. 18 3.1 Applied Research.................................................................................................................. 18 3.2 Analysis Methodology ........................................................................................................... 18 3.3 Interview Methodology .......................................................................................................... 19 3.4 Workshop Methodology ........................................................................................................ 20 3.5 Composed Working Process................................................................................................. 20
3.5.1 Starting Phase 20 3.5.2 Research Phase 21 3.5.3 Development Phase 21 3.5.4 Closing Phase 22
3.6 Composed Methodology ....................................................................................................... 22 3.6.1 Interviews 22 3.6.2 Process and Interface Analysis 23 3.6.3 Workshops 23
4 Results........................................................................................................................................ 24 4.1 Performed Interviews ............................................................................................................ 24
4.1.1 Performed Interviews with Sample Section 24 4.1.2 Performed Interview with Project Assistants 25
4.2 Workshops ............................................................................................................................ 26 4.3 Process Analysis................................................................................................................... 27
4.3.1 Sample Handling Process 27 4.3.2 Ready to Launch Process 28 4.3.3 RTL and Sample Handling Process Overlap 29
4.4 Interface Analysis.................................................................................................................. 30 4.4.1 The Project Interface 31 4.4.2 The Factory Interface 32 4.4.3 The Customer Interface 32
4.5 Sample Section Working Flow .............................................................................................. 33 4.6 Evaluation of alternatives ...................................................................................................... 35
5 System Proposal........................................................................................................................ 38 5.1 Implementation...................................................................................................................... 38
3 (60)
5.1.1 ER-model 38 5.1.2 Tables and Relationships in Access 38 5.1.3 Interfaces as Forms 39
5.2 Testing .................................................................................................................................. 39 6 Conclusions ............................................................................................................................... 41 7 Possible Expansions................................................................................................................. 43 A. Software Requirement Specification ....................................................................................... 44 I. Introduction................................................................................................................................ 44 II. Reference document ................................................................................................................. 44 III. System requirements ................................................................................................................ 44
IV. Functional service requirements ........................................................................................... 44 V. Storage 44 VI. Order system 45 VII. Search function 47 VIII. Error registration 49 IX. Revision 49
X. Quality requirements ............................................................................................................. 49 XI. User friendly 49
B. ER-model.................................................................................................................................... 50 C. Tables and Relationships ......................................................................................................... 51 D. Forms.......................................................................................................................................... 52 E. Terminology ............................................................................................................................... 59 References ................................................................................................................................. 60
4 (60)
1 Introduction
In the interface between a project-based development and an order-based distribution, the distribution system must be both flexible and precise. The order input can change rapidly which demands large information flow in both directions. In this process, it is extremely important to have a tool that facilitates the information exchange, eliminates information errors and makes important time free for other tasks. That is to say, a good working tool can help the departments to be an efficient busy bee!
Within this chapter, there is an introduction of Sony Ericsson Mobile Communications the host company of the thesis followed by an introduction to the problem area of which the thesis is based on and the expected goals and result. This first chapter also contain the report structure with a short outline of each chapter.
1.1 Company Description
Ericsson and Sony Corporation established Sony Ericsson Mobile Communications in 2001. The ownership is divided equally between the two companies. Sony Ericsson Mobile Communications provides consumer products for mobile communication and is responsible for product research, design and development, as well as manufacturing, marketing sales, distribution and customer services1.
1.1.1 Company Values
In order to inspire the employees and to mark the company’s ideals Sony Ericsson has built their values on three pillars2
Passionate about Success Being passionate means believing in what we as individuals and as a company are doing and trying to achieve. It is about loving success and inspiring others with our enthusiasm. It is about having pride and being performance-driven
Innovative in our thinking Innovation is at the very heart of the Sony Ericsson brand. It is not only about creating innovative products but also striving for new ways of thinking and working. It is about being curious and bringing continual improvements to the company.
5 (60)
Responsive to customers Being responsive in everything we do should be the framework around every relationship and activity. Don’t confuse it with always saying ‘yes’ – it means delivering what we promise and responding to customers in a positive and timely fashion but with integrity, quality and purpose.
Within this thesis, all pillars are playing an important role. In order to achieve a project goal in time, the focus must be performance-driven and have in mind the customer of this thesis. The solution must contain a new way of thinking and new ways of working if the improvements are going to be durable.
1.1.2 Company Structure
The company's global management is based in London, The R&D, (research and development) in Sweden, Japan, China, US and UK, and in total has approximately 4000 employees around the world. For an overview of the different departments see Figure 1 Overview of relevant areas of Sony Ericsson Mobile Communications.
This thesis is being performed at Sony Ericsson Mobile Communications Development Unit Europe’s (DU Europe) Research & Development (R&D) department in Lund. Product Configuration is a unit within R&D that includes Customization Product Management. This department is responsible for the customization of the products, the documentation of the same and the product information. Within Customizing Product Management, Sample Section is a small unit for distributing samples (telephones). The section receives telephones and accessories from the factory and simultaneously distribution orders from the Development Project; Sample Section’s task is to fulfil the order successfully.
6 (60)
DU Europe
IndustrializationR&D Program Management
Entry Program Management
Figure 1 Overview of relevant areas of Sony Ericsson Mobile Communications
R&D
1.1.3 Sample Section
Sample Section was established in the beginning of 2003 because there was an increasing need of distributing samples for product acceptance as well as marketing to open the sales channels.
The Projects lay orders for Sample Section to execute. The orders contain which and to whom the units/samples shall be sent. It also describes which software the units shall contain and which tests that shall be performed before shipment to the consignee. Sample Section receives the orders and performs the specified tasks and ships the units to the customers3.
For each Project, Sample Section distributes thousands of units in hundreds of different settings. The settings differ a lot, for example customer specific software, cosmetic character, special information CDs, manuals etc. The samples are shipped, for example to operators for acceptance tests and to journalists for commercial purpose.
1.2 Background
There is a large information flow between the Project and Sample Section with several updates. It is also required that all the information is saved to be able to trace errors or samples and to give information support to the customer.
Electronics R&D Project Office
MechanicsHW Development
Product Configuration
Product Configuration
Customization Documentation & configuration
Phone kit
material
Customization Product
Management
Phone kitMaterial Support
Object leading
User Documentation
Sample Section
7 (60)
Currently a spreadsheet in MS Excel is used to monitor and control the flow of orders from the Project and shipment of units from Sample Section, see Figure 2 An abstract of the existing system (Spreadsheet in MS Excel). Here a Project places an order by filling in a new row of the spreadsheet. Sample Section then receives the order; carry out the order and document the configuration and distribution information on the same order-row in the spreadsheet.
To Country Volume KRH/DPY SW-Rev Colour Kit content Ship date
Luica Ortiz Germany 50
DPY 101 2786 R1A
25 white + 25 blue
9 orange straps, 9 black straps, 50 battery, and delta list. 2003-08-15
Kon Leng Ang. Singapore 25
DPY 101 2786 R7A
12 white+13 blue
5 black + 4 orange straps, 25 battery, delta list. 2003-08-15
Figure 2 An abstract of the existing system (Spreadsheet in MS Excel)
Within the group of stakeholders (users of this document), the experience differs a lot. The permanently employed staff at Sample Section are using the system daily, while the Projects and temporary employees at Sample Section uses the system in periods.
1.3 Problem Area
The existing spreadsheet in Excel is difficult to maintain. There are limited opportunities to observe changes made by the Project after an order has been initiated. Instead, oral updates are made which increase the possibility of errors and misunderstandings. Since the same row is being filled in by the Project and later by Sample Section the changes are likely to be missed. This can lead to shipments of incorrect configured units, or shipments to wrong consignees.
The opportunities to search among orders for shipped units are limited. This renders that the contacts with the consignees are affected. Without an automatic update of storage volume, there is no control of which units are in storage or witch units are shipped during a specific time period. Furthermore, the existing system cannot provide information about the status on defected units.
1.4 Goal
The goal of the thesis is to help Sample Section to be more efficient by reducing all monotonously extra work that today’s ordering system demands. By evaluating a process improvement Sample Section shall evaluate their needs and demands on a new order system. The thesis shall provide Sample Section with a prototype of an ordering system that ensures that the development of a new system solves their problem both today and tomorrow.
The goal is also to create a new interface between the project-based organization and the ordering system where the order information is stored. The information exchange between the different organizational parts shall be aligned, simplified and elucidated.
8 (60)
1.5 Expected Result
This thesis expects to deliver a prototype version of a new system that supports the Sample Section working flow and to make a survey of the work at Sample Section, identify and specify the content in a new system
1.6 Report Outline
Chapter two Theory summarize all the theory the work is based on. The chapter provides a short description of areas of interest in the thesis in the attempts of reaching the project goals.
Chapter three Methodology applies the theory on the tangible problem. How to approach, gather and analyse data.
Chapter four Results describes the interviews and analysiss based on facts and theory. How the problem area can be changed to the better based on the theories described in chapter two.
Chapter five System Proposal describes the system that this thesis proposes to solve the initial problem. This chapter also contains a description of how the system was implemented and tested
Chapter six Conclusions contains the solution account of the problem and an evaluation regarding validity and reliability of the result.
Chapter seven Possible Expansions describes possible expansions of the implemented system
9 (60)
2 Theory
This chapter contains a platform of theory whereupon chapter 4 Results is based on. The three main areas are Process Theory, Interfaces towards the stakeholders and System Theory.
2.1 Process Theory
There is not one organizational form that generally is better compared to others. Whether an organizational form is optimal or not depends on the company goal, market and culture. The modern theory on development models often proclaims process orientated activity. Lars Stigdal and Tomas Johansson refer to three main reasons for choosing process orientation.
o Culture o Quality o Efficiency
Culture, includes terms like customer focus, a comprehensive picture and commitment. The second reason is quality; process orientation provides a platform for structural work. Finally efficiency includes important activities and continually improvements are in focus.4
By defining a process with the words of Harrington5 “It is the processes within any organization that get things done”, the importance of processes is understood.
There are many metaphors used for illustrating a process. All of them explain the process as the clear defined route, where multiple units are moving towards the same goal. Depending on what organisational level the process is designed for, the units that goes though the process have different similarities. The process thinking requires that the units must have high similarity level between each other in order to create a useful process.
Organizational level and Usability area To determine the usability of a process the abstraction level in the organisation is decisive6. On a high organizational level the usability area for the process is greater, but to apply the process on units with similar configuration will become harder. The problem occurs if all units follow the same process but need different treatments. Then the real usability becomes low and inefficient. If the chosen organizational level is low, the equality for the units will be greater but the usability area for the process becomes more limited. Figure 3 Organizational level illustrates this.
10 (60)
Process Usability
Middle-management
Project manage ent mProcess Owner
Organizational levelTop management
Enginering
Figure 3 Organizational level
Functional vs. process focus In an organisation with a functional focus the organization’s goal does not aim to the customer but to the organization’s management team. By introducing a process focus, the goal aims in another direction, towards the customer. In order to introduce process focus successfully the basic way of thinking must be changed; instead of dividing the company into functional areas, the dividing perspective must be flow-oriented7. In Figure 4 The difference between functional (top) and process focus the difference between the two focuses are illustrated. On top, functional focus shows how the customer seems to be left out and below the process focus where the whole organization aims to satisfy the customer.
Figure 4 The difference between functional (top) and process focus (bottom) Customer-Supplier relations The model of a process provides a picture with several customer-supplier relations8,9 there is not only the external customer-supplier relation but also many internal customer-supplier relations, see Figure 5: Internal end external customer-supplier relations. If attention is not put on these internal relations, sub-optimizing and non value-adding actions easily can appear. Exposing areas of sub-optimizing is one of the major intentions of process orientation.
Customer
Customer
11 (60)
Figure 5: Internal end external customer-supplier relations
Process design The process design in product development can be in three different settings, sequential, parallel or overlapped see Figure 6 Sequential, Parallel and Overlapped . A: Sequential process is a process where the upstream’s activities are done before starting up the downstream activity. This design is most used in the building trade the advantage of this design is that no work in the downstream activity will be made unnecessarily because of preliminary information from the upstream activity. B: Parallel process, is a process where the coupling between upstream and downstream is removed resulting in total parallel process activities. This design is most used in research activities. C: Overlapped process is instead a process where the couplings are kept and the activities are overlapped through frequent information exchange.10 This design is most used in the IT-trade where the time aspect is extremely high.
Figure 6 Sequential, Parallel and Overlapped Processes
If choosing the overlapped process design a few questions have to be answered; When should downstream act on upstream information? How should the activities be overlapped when the downstream activity can not work on preliminary information? When is it better to freeze the upstream information rather than transfer it in a preliminary form to the downstream activity?
The overlapped design when the upstream activity is finalizing information early may cause a quality loss. Also changes in information in preliminary versions shall be chosen so that the downstream efforts will not substantially increase. Overlapping activities are often easier when the upstream development is fast and harder when it is slow.
External Customer
Internal Customer
Downstream
Upstream
Downstream Downstream
Upstream Upstream
B: Parallell A: Sequential C: Overlapped
12 (60)
2.1.1 Process improvement
A process can be improved in two ways11. The existing process can be streamlined. For example, the use of computers can speed up a calculation, which renders in that the process goal is reached faster. This kind of improvement is a constantly ongoing work. The other kind of improvement is more radical and a one time activity. These kinds of improvements are defined as finding solutions aiming at improving the framework of a process. According to Persson12 the way of thinking must change in order to make this kind of improvement.
Both ways of improvements are important. They are even dependent on each other13. As help when determining how to improve the process, Rentzhog’s14 three different ways of process breakdown can be useful.
One way of process analysis has a vertical approach. This detaches the functionality area in the process. In addition, the dependency of the previous process step is easy to point out. A second point of view brings light on different phases in the process. This can be preferable when the activities are not a hand-in-hand process. A horizontal division can be useful in an organization where the processes have great differences in complexity. Here all non-value adding parts, where the process and working activities are not equal can be eliminated.
The improvements of a process, characterize of activities that facilitates for all the intended units. The benefits of improving the flow, compared to adjustments of the units’ capability are many. The most obvious is that in just one improvement of the flow, simultaneously the practicability of all units will increase.
The improvement shall also lead to a positive result for the entire process. If not having this goal in mind the risk of sub-optimizing one or a few parts of the process is large and leading to an overall negative result for the process.
2.2 Interface Theory
This area of theory takes off with Rhenman’s stakeholders’ model Figure 7 Rhenman's stakeholders’ model. This model shows how many interfaces there can be. The model provides a picture of the environment as an arena where the different stakeholders are participators. On the arena, the communication and information flow among the stakeholders is a game. Practically this game is affected and coloured by different individual interests. The model provides the picture of the environment, the arena and the participators; the players are unaffected of each other and of the game15.
13 (60)
Figure 7 Rhenman's stakeholders’ model
Within a project, project management stakeholder controls the game. The main reasons for the activity are to identify the most important stakeholders, the primary stakeholders, and create opportunities to gain most of the project. The stakeholders’ interests vary from contractual and legal to personal interest and responsibility. In person, these are identified by project members, top management, organizational entities, orderer and customer. The identification is initiated by answering the questions: Who are the parties concerned? Who has interest in this matter? To commit these primary stakeholders to the project they have to understand the purpose of the project. The managers must be fully behind the change and all stakeholders must realise their benefits. Five steps can make a creative mix of stakeholders16. (1) Identification of the stakeholders, (2) tiered approach to involvement, (3) active investigation of issues of concern or conflict, (4) resolution of issues and (5) formal approval.
Now the relevant interfaces have been analysed from both sides. The influence and prejudice from other strong stakeholders can be objectively validated. By using blinkers and approaching the interface from all stakeholders’ point of view, the interfaces analysis results in a more objective and optimal solution. The arena with Rhenman’s different stakeholders can not be compared with our arena. In our case the arena is inside the company. This internal arena provides a similar picture of the stakeholders and their interfaces. The only difference is the stakeholders’ titles.
Interface Improvement To improve the interfaces in a process, two areas are important: a better information system and a stronger internal and external integration17. How the interfaces shall be optimized depends on coordination ability and co-ordination need. First, determine which level of coordination the search is preformed at. Then the internal coordination can be grouped in three different categories, see Figure 8 Coordination of .
Company
State
Municipality
Employees
Management
Owner Customer
Supplier
Lender
14 (60)
Figure 8 Coordination of ability and need
The organizational coordination mechanisms are organization’s structures with a logistic responsibility. The formal coordination mechanisms are formal guidelines, procedures and programs. Informal coordination mechanisms are informal rules and agreements.
2.3 System Theory
Because of the problem description and the demarcations three different type of systems are a possible solution for this thesis; Business Administration Systems, Databases and Spreadsheets. Below the systems are described to provide the reader with basic knowledge of these three systems.
2.3.1 Business Administration Systems
A business Administration System is a computer system that can handle a company’s business applications. The company gets reliable routines and techniques by installing a business system directly into the business. The business system is built on a common database for all the functions within the company to avoid double storing of the information and the specific functionality for the company is made by changing different parameters.
A business system contains several fundamental functions like economic accountant, customer order management, invoicing, logistics, product planning, personal administration etc. Today almost all big companies use some kind of business system for some part of their organization and have exceedingly replaced systems developed on their own. Common business systems used in big companies are for example SAP R/3, Oracle Applications and Movex.
To implement a business system in a company one has to understand how the different functions in the company are related and how they can be shaped in an effective way. Often one also has to be experienced in programming to connect the business system to other information systems. The users also have to increase their co-ordination, process handling and understanding of the total business chain. 18,19
2.3.2 Databases
“A database is used to store and manage a collection of persistent and structured data. This collection is used to retain or retrieve relevant information”.20 This is the definition of a database according to Data Power’s course book, Introduction to Microsoft Access 97.
Informal Coordination
Formal Coordination
Organizational Coordination Co-
ordination ability
Coordination need
15 (60)
A database also consists of a description of the structure. A database management system’s (DBMS) task is to store and manage databases; the DBMS allows users to query the data via a query language, it supports concurrent access to the data and handles backup and crash recovery.21
A relation database saves the data in tables. The structure of the tables and relations between these tables make it possible to extract information.22 There are many different database management systems, most of today’s DBMS are of the type relation database.23 Examples of DBMS are Microsoft SQL Server, Oracle, MySQL, DB2 and Microsoft Access.
Database Design The first step designing a database is to make the ideas tangible in a data model24, for example an Entity-Relationship model (ER-model). In this model, all Entities and their mutual relationships are explained. The Entities have different attributes that describes the entity. One or many attributes makes an entity unique.
There is no existing standard for describing the database but a common way is to express entities with boxes, relationships with diamonds, attributes with ovals and the entities relation conditions with figures on the connectors. In Figure 9 Example of ER-model persons described by social security number, name and age, own cars described by registration number and the year that they where built. The social security number is a key for the entity person, two persons cannot have the same social security number but they can have the same age or name. The entity “car” has the attribute “registration number” as the key for the entity. The relation’s conditions are defined as one person can own 0, 1, 2…N cars.25
Figure 9 Example of ER-model
The ER-diagram is created on paper. In order to implement this model into the computer the ER-diagram transforms to a relation model. Now the designer decides which tables the database should contain and whether a relationship becomes a table or just a column in the entities table. This model is more or less equal to the end solution, for example see in Figure 10 Example of where the relationship owns is a column in table person.
F
Person Car Owns
Built year Name
Social Security Number Registration
Number
Age
N1
Person Social Number
Name Age
6806172421 Mary 36 4904058914 Eric 55
igure 10 Example of tables
16 (60)
Car Registration Number
Built Year
Owner
AWP933 1972 4904058914FCO101 2004 6806172421SAB742 1996 4904058914
2.3.3 Spreadsheet
Spreadsheets in general enables that large amounts of data presented as information, with tools to analyse, communicate and share results.26 The program MS Excel consists of five areas. Calculation, diagram, database, macro and advanced graphic presentation27.
Excel is an easy program to get started with, and is often used in small business, divisions in big companies or for private calculations.
17 (60)
3 Methodology
Two questions ought to be answered when choosing investigation method. “What do I need to know?” and “Why do I need to know it?”. Based on these answers, the next question to be asked is “Which method shall I use?” It is also very important to take available time and resources in consideration when deciding method28
The stakeholders more or less always have an opinion on how to solve a problem. During the work this subjective opinion must be considered. At the same time, the solution must be based on objective theory and methodology. This must be remembered when choosing method and not loosing the uninfluenced point of view from a person facing a new problem.
This chapter contains descriptions of the methodology method in interest for this thesis; Applied Research, Analysis Methodology, Interview Methodology and Workshop Methodology. In the end of this chapter the Composed Working Process and Composed Methodology for this thesis is presented
3.1 Applied Research
Sample Section’s problem occurs because of practical difficulties and problems that demands practical applicable solutions and results, we call this Applied Research.
The ambition in all research work should be using full method-awareness29. This presumes that the solution is based on analysis of different techniques that elucidate the problem area from different angles. The optimal and likewise the theoretical demarcation must therefore be based on the subject and not on available time and means. Within a master thesis, where the author for the first time is facing both the result demands from the company and the theoretical demands from the school the difference between the two worlds is fully exposed.
3.2 Analysis Methodology
There are two basic methods of analysis, Qualitative analysis and Quantitative analysis. The Qualitative analysis means a possibility to increase the understanding of new knowledge and detailed information from few people. Quantitative analysis on the other hand gives knowledge about “how much” and more servile information from a large amount of people30, 31.
When making a process analysis, there are three different questions to be answered:32
o Why does the current process look as it does? o How good is the process ability? o How good is the standard compared to similar processes in other
organizations (benchmark)?
18 (60)
3.3 Interview Methodology
By interviewing, there is a great opportunity to seize and understand different people’s opinion of an issue. During the interview, the respondent can point out and explain the areas that are important for him/her. Depending on how structured the interview is, the respondent has the freedom to slant the topics of the interview. The greatest value of interviews is when a problem aims to obtain qualitative determination of the reality. By interviewing several respondents about the same topic the understanding will be unique and context definite.33
An open interview is characterized as:34
o Descriptive o Focused on a definite theme o Open to changes o Aim to understand the problem from the respondents perspective
Qualitative interviews are for increasing the knowledge in an area and there are five different types of qualitative interviews35.
o Explanatory interviews. These interviews give the interviewer knowledge about unknown or vaguely-known topics.
o Deep interviews. These interviews aim to provide further understanding on a topic that the interviewer already has a lot of knowledge in.
o Goal-oriented subject interviews. These forms of interview intend to give knowledge with direct questions about a decided subject.
o In-depth interviews. These interviews are characterized by that they are needed only when studying data material.
o Focused interviews. These interviews are characterized by previous decided themes. The interviewer makes sure that, during the interview the predefined demarcations are kept.
There is a slight friendship between the interview types. Usually more than one type is used during an interview. Depending on the structure of the interview, the different types can be combined (but there are some natural restrictions). There are three different grades of structure.36
o Structured interviews, follow the predefined questions closely but it also gives the respondent opportunities to frame her answers and go into details.
o In Semi-structured interviews, there are no predefined questions. The interviewer asks only about topics that are relevant for the interview. This kind of interview shall be more like a dialogue between the interviewer and the respondent.
o Unstructured interviews, give the respondent the opportunity to speak his/her free mind. The interviewer starts the dialogue and then has a more passive roll in the interview.
When planning an interview, the interview form has to be objective, both to the respondent and the interviewer. As interviewer, the curiosity of the facts shall inspire and motivate the respondent. At the same time, the interviewer shall be critical to her own thoughts and conclusions during the interview. When choosing an interview form it is important to think about the goal of the interview and what kind of questions can get you there, only then can the interviewer see which interview form that fits her goals and questions.37
19 (60)
3.4 Workshop Methodology
Workshops can be used as a complement to ordinary meetings. Workshops are a generic term for a few techniques and methods. A workshop consists of a workshop leader and workshop members with specific competence and experience representing different parts of the organization.38 The difference between workshops and normal interviews is that the workshop leader does not need to be as objective to the subject as an interviewer needs to be and when performing a workshop one puts the interaction in the group under a greater consideration than the individual opinion as in an interview.39 Workshops are especially recommended when starting a project, goal-discussions, process analysis, handling requirements and when searching for a solution to a problem.40
The disadvantage of workshops can be that it is difficult to document the information that is being said when people are interrupting each other and talking at the same time. People can also be unwilling to expose their opinions about emotional, personal and political subjects. The opposite can also occur when one or a few outgoing persons can dominate the discussion.41
3.5 Composed Working Process
This thesis problem area has both research assignments and development assignments. Research is categorized as production of knowledge with necessity of theoretical anchorage; development on the other hand is described as utilization of knowledge to contribute with a change42. This mix makes knowledge production and utilization of knowledge work hand in hand; this mix is known as R&D (Research and Development). In this thesis, production of knowledge is a pronounced part of the development assignment. That is because the knowledge of such a specific area as this problem is insufficient.
In order to achieve the thesis goal and the expected result the structure of the working process is based on a project process. The choice is based upon the similarities of the thesis work and a R&D project. The time plan consists of four phases; Starting Phase, Research Phase, Development Phase and Closing Phase, with equal length and a baseline at the end. This chapter describes the four phases in more detail.
3.5.1 Starting Phase
Figure 11 Starting Phase
Company Approval Of SRS
Project Specific
ation
Theory
Facts
Software requirement specification (SRS)
Doc. template Report template
Start m
eeting
External Account
Supervisor Meeting
20 (60)
In order to create a successful and durable solution, the first question to answer is: What is the problem? This question is to be asked at the first meeting for this thesis and is answered in a Project Specification. The goal in Starting Phase is to obtain the companies approval of a Software Requirement Specification (SRS). Parallel to the development of the SRS, facts is collected and a theory gathering starts. The structure of this report is developed in this first phase.
3.5.2 Research Phase
Figure 12 Research Phase
Research Phase starts with further collection of facts and theory. At one point in this phase the main question to be answered changes. At this point, we also decide that the theoretical platform for this thesis is stable enough for evaluation. In addition, this point marks that the collection of facts must stop and start being analysed. This to know what information that is useful in the following work. How the problem shall be solved? Also analysis shows what theoretical area we need more information about. By here, the SRS will face different solutions in order to establish the optimal option. The baseline of this phase is a proposal of a solution.
System Proposal
Facts Analyse facts
3.5.3 Development Phase
Figure 13 Development Phase
The baseline in the Development Phase is to attain a functional solution. The implementation follows by testing both internal in the project and by the department at the company. Since this is our customer this will be more or less a acceptance test or solution evaluation.
Implementation
Report
Tests
Company Evaluation
Follow-up
Test Acceptance
SupervisorMeeting
SupervisorMeeting
Supervisor Meeting
Supervisor Meeting
External Account
Report
Theory evaluation
Develop system
proposal
Supervisor Meeting
Theory
21 (60)
3.5.4 Closing Phase
Figure 14 Closing Phase
The forth stage in the thesis work is the last phase. This is the most important phase. Here the thesis is presented, both oral and in text. Before giving the account of this thesis, we shall act as opponents on an external thesis. A confirmation and evaluation of the results and work are performed. The foundation at the oral account will be a short illustrated presentation of the thesis.
Revise
Give the account Report
3.6 Composed Methodology
This subchapter describes the chosen methodology for this thesis based on 3.3 Interview Methodology and 3.4 Workshop Methodology. Below Figure 15 Methodology Processis a description of how the methodology and theory will lead to an analysis and to a proposal.
Figure 15 Methodology Process
3.6.1 Interviews
In order to understand the problem area and the special requirements from Sample Section it is suitable to make unstructured explaining interviews. This interview form is chosen to give the interviewers more knowledge in the requested task. By making an open dialog between the interviewers and Sample Section, the stakeholders have an opportunity to speak their free mind.
The most important interface, Sample Section towards the Project must be observed from different perspectives. Seeing the special requirements from only one side would make the solution Sub-optimized. Those who are using the current order system are the Project. Therefore, they can provide a different perspective on the direct contact with Sample Section. By choosing the Project assistants as respondents in a structured goal-oriented subject interview the desired objectivity is reached. A structured goal-oriented interview is chosen to obtain more knowledge of requirements on an ordering system replacement by asking predetermined questions based on the interviews with Sample Section but also to give the respondent possibility to make her answers deeper.
SupervisorMeeting
Act as opponents
Result Analyse
Proposal
• System Theory• Interviews • Workshops • Analysis
22 (60)
3.6.2 Process and Interface Analysis
In order to demarcate the responsibility area of Sample Section a survey of the relevant processes is an essentiality. With an aligned working process, this thesis is similar to a general system development suitable for all Projects. As a starting point we have decided to make a qualitative analysis of the relevant existing processes.
With the help from Figure 7 Rhenman's stakeholders’ model all interfaces and its stakeholders are found. By analyzing the interfaces from both sides, all external requirements are detected and the proposed system becomes more objective and optimal.
3.6.3 Workshops
When special questions occur during the thesis it is important to deal with them immediately. We have chosen workshops to evaluate these sorts of questions in an efficient way. This to come to a decision in the question as soon as possible, taking everyone’s opinion under consideration. A Workshop with Product planer, product manager and Sample Section represents will make a complete view of the distribution flow.
23 (60)
4 Results
This chapter describes the results from Process Analysis, Interviews, Interface Analysis and Workshops based on chapter 2 and 3. It also contains an Evaluation of the alternatives and how to improve Sample Sections working flow.
4.1 Performed Interviews
This subchapter describes the interviews and the result of the interviews made for this thesis. Two groups of people were interviewed: employees from Sample Section and from the project which is the major interface to Sample Section. According to Sample Section the Project Assistants are those who are working closest with the ordering process.
4.1.1 Performed Interviews with Sample Section
Unstructured explaining interviews with Sample Section’s employees were made three times during the thesis. Beside these occasions, Sample Section contributed with information in a more informal way during the work. All of the interviews were made in groups with two interviewers and between two and four employees. This choice was made to give the group an opportunity to directly discuss important issues during the interview in order to increase the information output. Below the three different interviews are explained in a chronological order.
Interview 1: To start the interview the interviewers told the recipients how much they knew about Sample Section. This interview was made in the beginning of the thesis to give the interviewers more knowledge about Sample Section’s tasks and how they work. The general working flow at Sample Section was described from the respondents’ point of view and they gave the interviewers a short demonstration of the daily work. Expectations on a new system were discussed briefly and Sample Section handed over a compilation of their present requests concluded after having a workshop about their needs in the group.
Interview 2: To start the interview Sample Section were asked to explain how the spreadsheet was structured and how they used it. This interview was made to discuss shortage of the spreadsheet in MS Excel used for orders, working and shipping information. This discussion led to a more specified view of the working flow but one could easily see the complexity of using the spreadsheet because of the differences between the orderer’s requirements on the samples and the high frequency at which the information changes. During the interview, Sample Section were asked to bring up the good and bad functionalities of the spreadsheet ordering system to elucidate, which functionalities that are considered necessary to keep.
Interview 3: When the Software Requirement Specification (SRS) was created for a new system, a third interview was made with Sample Section’s employees. Before this interview, the SRS was sent to the employees with a request to read it and criticise it as much as possible. The document was then the foundation during the interview. The purpose of the interview was to give Sample Section a chance to discuss and comment the requirements, but also to give the opportunity for Sample Section to come up with new requirements in an early stage of the thesis work.
24 (60)
4.1.2 Performed Interview with Project Assistants
Based on information from interview 2 with Sample Section, the Project Assistants were selected for Semi-structured focused interviews. Within the important interface towards the Project, they have the most frequent contact with Sample Section’s MS Excel ordering system. Three Project assistants were individually interviewed.
Interview 4 The interviews with the Project Assistants were divided into five question themes, General, Orders, Factories, Errors and Closing, based on the identified problem area from interview 2 with Sample Section.
General: In the beginning of the interview the interviewers were interested in getting a general understanding of the contact between the respondent and Sample Section and if there is anyone else who may have more contact with Sample Section.
Orders: Questions about the ordering procedure were asked to investigate if the orders were the same in all Projects. Special attention was given to how early in the procedure the orders were laid, this to extend planning opportunities for Sample Section. Questions were asked to track down which information the Projects provide and if it is possible to provide all requested information from Sample Section. The important task here was to find shortages in today’s system from the Project’s point of views.
Factories: Questions were asked to get a deeper understanding of the ordering of units that later Sample Section receives and to evaluate the possibility to get electronic packing lists from the factories. Questions were also asked to investigate the need of a more controlled storage keeping at Sample Section.
Errors: Questions were asked to understand the need of information on units that has failed tests, error units from Sample Section to the Projects.
Closing: The closing questions were asked to let the respondent be more open in her answers and to let the respondent brainstorm a bit about a new system to get the interview together.
This is what the Project Assistants answered on the five themes:
General: All the Project Assistants agreed on that they were the ones that had most contact with Sample Section from the Project but that in one case also the Project Manager was involved in the order process to Sample Section. All three Project Assistants pointed out that they had intensive contact with Sample Section at certain isolated points in the Project.
Orders: The way the orders are laid to Sample Section differs a lot. Almost all Projects lay their orders different. The Project Assistants said that Sample Section’s MS Excel ordering system is too complex and they did not always know what information they were supposed to put in the columns.
Factories:
25 (60)
According to the Project Assistants the person responsible of ordering units and kits from the factories vary; sometimes the Project Assistant places the order and sometimes the Verification Assistant does. The Project Manager or the Ready To Launch-leader also makes orders. Normally there is no confirmation with Sample Section’s storage regarding the goods in stock before ordering. However, when Project asks for a storage status Sample Section must count the units by hand. It is usually possible to get packing slips from the factory. Errors: The three Project assistants agree on that they only needed IMEI-number, Serial-numbers and the error description for error-units from Sample Section.
Closing: Many opinions on Sample Section’s MS Excel ordering system came up during the interviews, for example is the spreadsheet very complex. It is hard to know what to fill in, in all the columns and sometimes the Project make their own Excel spreadsheet to Sample Section. A new ordering system was asked to be easy and unequivocal. A special requirement from the Project Assistants is also that some kind of address book/database handles the customers’ addresses.
4.2 Workshops
Half way trough the thesis a proposal came up from Global Product Management about automating the sample process with an interface to Sample Section. A workshop was performed to evaluate if such a system was needed. The workshop consisted of a Product Planner, a Product Manager, a Sample Section representative and the thesis workers.
The workshop members elucidated the flow of sample planning by giving their view of today’s Sample Ordering System and the proposed automated system is shown in Figure 16 ASOS Automated Sample Ordering System. The figure describes the five most important documents and their mutual information flow.
MSP, Master Sample Plan is the overall plan of sample distribution and PSP, Product Sample Plan is the product specific sample plan based on MSP. From all the PSPs, a Sample Submission document is created to view assembled distribution per week for resource planning. The MSP and the PSP is executed into an order draft including from the MSP, Addresses and from the PSP, amount, order responsible etc. To this order draft the Project is adding for example Software information and the order is sent to Sample Section.
26 (60)
Figure 16 ASOS Automated Sample Ordering System
After the workshop, questions were raised regarding if ASOS, Automated Sample ordering System, also should contain the execution phase of the sample distribution. Further discussions led to the decision that ASOS shall contain the whole sample distribution process. The execution face in ASOS will be developed based on this report. This decision takes the streamlining of the Sample Handling Process to a new level and makes the flow in the interface Sample Section-the Project even more aligned. The decision about including the entire sample process will affect the thesis by only using the database as a prototype for the last part of the complete system.
Master Sample
Plan
Order Draft
Product Sample
Plan
Sample Submission
Plan
Sample Order
4.3 Process Analysis
This subchapter analyses two fundamental processes for sample distribution, Sample Handling Process and Ready to Launch process. Since Sony Ericsson is a young company, some of the company processes are still in its infancy.
4.3.1 Sample Handling Process
In the main process for sample distribution, the goal is to distribute samples. This is also the value adding action in the process Sample Handling Process see Figure 17 Sample Handling Process. The process shows what departments are involved and which role they play in the development of samples.
The Global Product Management and Product Management create the frame for the distribution. The frame consists of MSP Master Sample Plan and PSP Product Sample Plan, the MSP is a general plan for all sample distribution while PSP is a specific sample plan for each product. This frame render in a resource plan.
Found on the PSP the Project places sample orders that goes through the Planning and Preparation stage before reaching Sample Section. At Sample Section, the samples are received from the factory in the Sample received stage and after that in the Test and Packing stage, the orders are processed. At last, the samples are delivered to the customer in the Delivery stage. The dotted lines and the Change impact review stage is for updating sample orders, already sent to Sample Section.
27 (60)
Figure 17 Sample Handling Process
At high organizational level the Sample Handling Process aligned a roadmap for the work at Sample Section. The process has a clear structure and an aligned process flow. From this point of view, the process has a good level of usability. However, because of order updates with short notice, lack of resource planning and equivocal ordering, Sample Section cannot work in accordance to the process. Because of the problems, occurred applying the process on a low organizational level, there must be some kind of process improvement. A more aligned and controlled ordering system could be a solution for Sample Section to be able to better follow the Sample Handling Process.
We have two alternatives of improving the process, streamline or to improve the framework of the process. To evaluate if it is necessary to improve the framework of the process we looked into if the process also lacked on a higher organizational level. Nevertheless, when looking at the level above Sample Section it is much easier to follow the process structure and the process flow in the daily work, therefore there is no need of improving the whole framework of the process. Instead, we decided to streamline the process on the lower organizational level see Figure 3 Organizational level. At a low level, a new support system will change the working flow. On one hand, the impact on the working flow will be radical. On the other hand, according to Figure 6 Sequential, Parallel and Overlapped Processes the support system only aligns the working flow and creates possibilities to follow the predefined process. This alignment should be a constantly ongoing work.
4.3.2 Ready to Launch Process
Sony Ericsson has a process for launching; Ready to Launch (RTL) process defines what actions are made in order to prepare a product for the market. In this process one can see the interface between the Project and Sample Section from the Projects point of view.
28 (60)
This thesis will not analyse this process in detail. The point is that within the process there are actions related to Sample Section. In the third stage “Design & Block verification” of the RTL process Figure 18 Design & Block verificationthe Product Sample Plan is designed. This is the foundation for the orders to Sample Section. The purpose with Operator Acceptance (OA) samples is to ensure that the Product Customization Requests (PCR), meets the company’s major customers, mainly international operators, around the world. Therefore, there will be several occasions in this process before Sony Ericsson Mobile Communications receives the operator’s acceptance. The frequent use of this process makes it extremely important not to have misunderstandings between the departments and not to have transmission errors of information.
Figure 18 Design & Block verification
The sixth stage “Ramp up”, see Figure 19 Ramp up, contains another action related to Sample Section. It regards the shipment of commercial and journalist samples. This action is very similar to the one for OA samples. Therefore, the working procedures are similar between the two departments.
Figure 19 Ramp up
As said above there is a high frequency in these actions between the Project and Sample Section. The process has clear lines in the handover stage between the two departments but there is a lack in this handover action in reality today. But if adding a new interface meeting this action in a new system as investigated for the Sample Handling Process also this action between Sample Section and the Project will be as aligned as in the processes.
4.3.3 RTL and Sample Handling Process Overlap
The RTL process and the Sample Handling Process overlaps in information exchange. The RTL process delivers order information in a various flow and Sample Section works according to the latest information delivered. This overlap has flaws considering;
o Information delivery way o Information delivery frequency o Sample Section workload
29 (60)
The information delivery way is not distinct, to get an optimal flow in the overlap the information source should only be one, using telephone and mail as complements not as direct information sources. The frequency in information delivery is irregular which contributes to the third flaw; Sample Section workload, Sample Section has a possibility to plan their workload but the plan is very unreliable as they do not know when and in what extent the complementary information will come. With an improvement of the ordering system planning work will be easier. For an efficient overlap like Figure 6 Sequential, Parallel and Overlapped Processes, specific days or time strokes for deliveries can be used.
Because of the nature of this process Sample Section shall always immediately act on the upstream information and it is not possible to freeze the information.
4.4 Interface Analysis
This chapter is an analysis of the interfaces that Sample Section has. This analysis brings up the needs and provisions at Sample Section and their interface departments.
Sample Section has three interfaces; the Projects, the factories and the customers see Figure 20 Sample Section’s stakeholders’ model based on Figure 7 Rhenman's stakeholders’ model.
Figure 20 Sample Section’s stakeholders’ model
Project Customer
Sample Section
Factory
Project
Sample Section
Factory
Customer
o The most important interface is the one towards the Project. Here is a mutual interest. The Project is ordering from the factory, making the orders to Sample Section and the necessary updates. Sample Section has information regarding order status and error units in readiness for the Project.
o The factory delivers units to Sample Section.
o The customer receives the samples and is able to ask Sample Section about the received samples.
30 (60)
Next chapter describes the three interfaces and explain them individually. The external interfaces, towards the factory and the customers are by the physical localisation more of a formal kind. The most important interface, between the Project and Sample Section is more informal. However, according to Figure 8 Coordination of and that the need of co-ordination is great at this interface the support system must guide the stakeholders along the predefined process.
4.4.1 The Project Interface
The interface between Sample Section and the Project is two-sided. Table 1 The Project interface provides an overview of the information exchange between the departments. The information exchange is overlapped from the Project as upstream activity and Sample Section as downstream activity see Figure 6 Sequential, Parallel and Overlapped Processes. The information marked with an * in Table 1 The Project interface can be delivered early in the Project and other information can not be given to Sample Section before the upstream activity is finished, which is chosen to avoid quality losses and unnecessary increased work effort for Sample Section.
Figure 21 The Project interface The Project provides following: Sample Section needs following:
Project Customer
Sample Section
Factory
o Name (Project*, responsible*) o Name (Project, responsible) o Customer (operator*, country*,
Address*, tel*, e-mail*, Cc e-mail*) o Customer (operator, country,
address, tel, e-mail, Cc e-mail) o SW (CXC, CDA, TAE) o SW (CXC, CDA, TAE) o HW (KRH,DPY) o HW (KRH, DPY) o Build o Build o Keyboard* o Keyboard o GOS* o GOS o Language* o Language o Sim-lock o Sim-lock o Amount (normal*, RF-prepared*) o Amount (normal, RF-prepared) o Tests* (if needed) o Tests o Label* o Label o Purpose* o Purpose o Invoice information* o Shipping date* o Shipping date o Attachments*
The Project needs following: Sample Section provides following: o Error information (Serialls nbr, IMEI
nbr, error description) o Error information (Serialls nbr , IMEI
nbr, error description) o Order status o Order status o Invoice information
31 (60)
o Storage status
o Storage status
Table 1 The Project interface
As one can see in Table 1 The Project interface, the information that the Project can give is the needed information for Sample Section to perform shipping and the information that the Project needs can be prepared by Sample Section except from the gap in Invoice information. The problem concerning Invoice information for the deliveries is not solved by this thesis because as seen in Table 1 The Project interface Sample Section does not need this information to distribute the samples. Instead, this problem has to be solved by the Projects.
4.4.2 The Factory Interface
The interface between Sample Section and the factories is one-way. Table 2 The factory interface, provides an overview of the information and article exchange between the two instances.
Figure 22 The factory interface The factory provides following: Sample Section needs following:
Project Customer
Sample Section
Factory
o Units (telephone, charger, manuals, etc.)
o Units (telephone, charger, manuals, etc.)
o Packing lists including identity of telephones (sometimes)
o Packing lists including identity of telephones
Table 2 The factory interface
As one can see in the table Sample Section’s needs are here obtained despite of one minor problem that the factories not always include packing lists of the delivery.
4.4.3 The Customer Interface
The interface between Sample Section and the customers is one-way. Table 3 The customer interface provides an overview of the information and article exchange between the two instances.
32 (60)
Project Customer
Sample Section
Figure 23 The customer interface Sample Section provides following: The customers need following:
Factory
o The product o The product o Information support
o Information about the purpose of
the unit
Table 3 The customer interface
The customer’s needs are obtained when Sample Section is able to perform the orders in time and answer relevant questions without major inconvenience.
4.5 Sample Section Working Flow
The current working flow at Sample Section was analysed during interview 1 and 2 with Sample Section and viewpoints of improvements where made. The current working flow is visualized in Figure 24 Current Working Flow at Sample Section which can be compared with the proposed working flow with a new support system see Figure 25 Proposed Working Flow at Sample Section.
Figure 24 Current Working Flow at Sample Section Figure 24 Current Working Flow at Sample Section shows the complex information flow in today’s working flow at Sample Section. At the top, the Project provides their orders to Sample Section in the middle. The Project also asks Sample Section for Storage Status information, Reports on Error units and information about their executed orders, shipments. All questions must go through Sample Section.
Project
Sample Section Questions
Document IMEI Serial number
Error Report If Order not completeAdditional info will be asked for. C
ustomer
Storage Status Info Shipping Info Order
Excel Spreadsheet
OrderStorage Status info
Error Registration
Error Info Shipping info
Shipping info
Counted by hand
33 (60)
In the middle Sample Section receives the orders from the Project, if the order is incomplete Sample Section asks the Project for completion before registration into their Excel Spreadsheet. If Storage Status information is requested from a Project, Sample Section needs to count the storage items by hand because the Excel spreadsheet does not support the Storage content. This work is both time consuming and monotonous recurrent. With a jointly system, time can be saved and problems can be solved. During the work at Sample Section information about telephones that have failed in tests, error units and all the shipping information including IMEI-number and Serial number of the shipped telephones are registered into the spreadsheet. If the Project needs any of this information everything must go through Sample Section.
Figure 25 Proposed Working Flow at Sample Section
Figure 25 Proposed Working Flow at Sample Section shows a proposed working flow at Sample Section. Here a new system is placed between the Project and Sample Section, this facilitates for both departments and the flow will be more aligned. By placing the system between the two departments the areas of responsibility will be more distinct. This is important when establishing a new department such as Sample Section.
The Project places their order direct into the system and the system has a filter that controls that all demanded information will be filled in before accepting an order. Sample Section registers all incoming goods into the system. During the processing of an order the IMEI-numbers and Serial numbers, error information about telephones that fail in tests and all shipping information about executed orders are registered by Sample Section into the system. If the Projects need any information about these orders or units all the information is accessible in the new system without the dependence of Sample Section.
The amount of information that the support system contains must weigh against the time and effort to put the information into the system. By registration of units as individuals with IMEI-number and Serial number when delivered to Sample Section, the units always must be updated at every configuration and test session. This work takes a lot of time, if the information is needed the time can be well invested otherwise the activity should be simplified or ignored. We suggest that the units are registered as an amount when arriving to Sample Section and just registered as individuals when connected to an order or failing in test.
Sample Section
System
Document IMEI Serial number
Error Report
Questions
Shipping Info
Shipping Info Storage Status Info
Storage Registration Error Registration
Order
Custom
er
Project
34 (60)
The current working flow at Sample Section is divided into functional areas and the information flow is slow because it has to be transported from the different areas many times and the same information is in different places at the same time. The proposed working flow for Sample Section is on the other hand more aligned. The information will never be transported around in the different areas and it will always stay in one place, in the system accessible for Sample Section and the Project.
The difference between Figure 24 Current Working Flow at Sample Section and Figure 25 Proposed Working Flow at Sample Section shows that the proposed working flow will change the way of working. In the comparison one can easily see the benefits of streamlining the Sample Handling Process with a new system.
4.6 Evaluation of alternatives
Table 4 Evaluation of alternatives provides a compiled overview of the three system alternatives, Business Administration System, Database and Spreadsheets technically explained in chapter 2.3.
Issue Business Administration
System
Database Spreadsheets
Cost Expensive Cheap Cheap
Implementation Difficult Middle Facile
Updates Difficult Middle Facile
Security High Depend MS Access: Low
Low
Stability High Depend MS Access: Middle
Low
User-friendly Yes Yes No Table 4 Evaluation of alternatives
Based on the problem area, theory and analysis these six most important requests for creating a new system at Sample Section are defined:
a) Rationalize and automate work at Sample Section
To rationalize and automate the work for Sample Section a support system with clearly defined functions and no ambiguous interfaces to work in is necessary. This makes it important to use a system where the design can be created with no boundaries concerning design.
b) Clearly define the responsibility areas between the departments
35 (60)
Since several Projects are passed on through Sample Section, a new system has to have clear lines between different areas of responsibility. In addition, the interface has to be open and flexible. The ordering interface must be as user friendly so that all orders can be created directly there. At the time of this report, the ordering process is not defined. Therefore, creating a structure is the essential start. This structure will be based on Sample Section, the external users and the process designers’ opinions and experiences.
c) Simplify work for none experienced temporary workers
If the group of users is limited to Sample Section the need of security around the system is small. More important is that the maintenance and the interfaces are easy to understand. The introduction for a part time worker should be short and the possibility to make errors should be minimized. In addition, Sample Section should be able to make proper changes and system updates if necessary.
d) Eliminate non-value adding actions
To eliminate non-value adding actions in a future system the information should be added directly from respective department, the system should prevent that non-workable orders are being placed. Also, attend those orders that have high priority.
e) Change from “information hunting” to “information collecting”
To avoid the extra work the “information hunting” demands when Sample Section needs to search for the parameters they need to fulfil the order request, it is important to have a filter when laying the orders so that it is not possible to lay an order without certain parameters.
f) Facilitate working planning and prioritization
Planning and prioritization does not work satisfactory for Sample Section. They need information that is more reliable when planning and concerning prioritization.
By solving these six requests the work at Sample Section will be more aligned. Weighing these six requests to Table 4 Evaluation of alternatives gives following;
o Business Administration systems satisfy four out of six requests, it has the disadvantage of not being free to design and has a high level of introduction but on the other hand it has very good results in the table. Technically this choice can be preferable but the implementation level is far too high for a master thesis. Even when Sample Section System has been integrated to (ASOS) an external database is preferred to a Business Administration system.
o Databases can fulfill the six requests and has also relatively good results in the table. Because of the user-friendly interfaces and the relatively facile implementation level and update accessibility, a database is the alternative that is suitable for Sample Section to work in.
o Spreadsheets do not have many good results in the table and it can just fulfill one; of the six requests.
This evaluation renders in using a database because of its good results in solving the requests and for having good results in the table.
36 (60)
According to every belief for the future the sample distribution is an important and ever growing area for mobile manufacturers. The trend is that more and more of the customers are demanding customized telephones. In the footstep of this the sample distribution will continue to grow. Therefore it is wise to create a system that is flexible enough for adjustments when the needs and complexity growths.
37 (60)
5 System Proposal
A database program that fulfils the criterions in 4.6 is Microsoft Access Database. Access is adapted for personal use or for use in small working teams; it is also built in a Microsoft environment that Sample Section is very used to work in which facilitates their ability to make changes and system updates. In addition, the part time workers have Microsoft tools experience, which makes it easy for them to adjust to a database in Access.
5.1 Implementation
The implementation of a database, see 2.3.2 Databases, is divided into two basic steps. The first high-level implementations consist of forming the ER-model and sketch the interfaces on paper. The second step, the low-level implementation consists of implementing the tables and relationships. This subchapter explains these two implementation steps for our proposed system. We also explain a third step containing the development of the interfaces as forms. A form is used to facilitate for the user. With a form the user is able to save information in underlying tables without having to enter the table.
5.1.1 ER-model
The ER-model, Appendix B, is the system high-level description of the system. It has been based on the information gathered from interviews and process analysis.
The entities are chosen to:
o Telephones o Accessories o Tests o Errors o Orders o Order History o Customers
These entities are the main groups of information that Sample Section wants to keep track of. From the SRS, Software Requirements Specification, Appendix A, the attributes were picked and the existing relations was added to the ER-model. The ER-model was also extended with some key attributes when no natural key was available and some new relations was added.
The model has been used as a comprehensive description of the system in an early stage. The model has also been useful as a communication tool; both in discussions with stakeholders that lack the technical knowledge about databases and as an environmental description to people that have supported us technically.
5.1.2 Tables and Relationships in Access
After developing the ER-model it is easy to translate the entities directly into tables. There are however a few new things one has to consider. All the attributes are given an attribute type, for example text, number, yes/no etc. It is also possible to give the attributes proper explanations, which is useful if other people will update the database, as in this case, and not by the people that has developed it.
38 (60)
In this stage, we also decided not to set all the relations because we did not yet know the final design result and setting the relations too early in the design process complicates changes further in the design process. The final tables and relations can be viewed in Appendix C.
5.1.3 Interfaces as Forms
Simultaneously as the contemplated user evaluated the ER-model, the first sketches of the user interface were drawn. On paper, we defined what views that are needed and the connections among them. What information that will be on each view is selected based on the process and information flow. By designing the views on paper before designing them into the database, facilitates the implementation. Because trying out one design suggestion in the database takes more time and one has to set many properties that probably need to be changed further in the process. Designing a paper version also makes it easy to see the whole view flow on an early stage before implementing them into the database.
To make the system work as a roadmap for the processes where Samples are ordered the different views due to be chronologically oriented. From the order, there is a natural flow towards the shipment. To achieve this flow we based the views on Figure 17 Sample Handling Process. Other guidelines we used where the experience and special requirements from Sample Section that came up during interview 2. The initiation of the chronological flows must be natural. The solution is a Switchboard see Appendix D and from the switchboard, the user can initiate all working flows.
From the Switchboard, the stock is manoeuvred and updated. The important issue to extract information on request from customers, Projects or other stakeholders can be reached with the search function. Most important on the switchboard is the field for new orders. By clicking on one of the latest non-executed orders, the order information will be displayed and a new shipment can be created. From here a suitable telephone that matches the request is automatically selected from the storage and the identity (IMEI-number) can be entered.
The implemented forms can be viewed in Appendix D where one also can view the suggested design for possible expansions of the forms.
The implementation of the views in the Access database demands writing SQL questions, macros and some Visual Basic coding. These can be seen as several automatically executed programs that enforces that the working process is kept aligned. Also the programs eliminates frequent work
After having implemented the different views and connected them to tables new special relationships are needed and added and in some cases also the attributes types where changed in order to fit into the aligned process. These changes where made to adjust the designed forms and relations to Microsoft Access environment.
5.2 Testing
We performed tests to validate the requirements specification. The tests contained for example tests on the ordering system and on the storage system in order to see if there were any absences in the functionality of the system
39 (60)
After the tests, three tests sessions on the system were performed with Sample Section. The co-workers had opportunity to change and add information and exterior on the database. Between the three sessions, desired updates where made and reviewed in the beginning of the following test session.
Test session 1 During this test session Sample Section and the thesis workers performed a static test. We showed the system to Sample Section by this, the opportunity to give general response on the interfaces were possible. The aim for the first session was to present the system for future major stakeholders. They had the opportunity to affect the appearance of the system design. They were also able to ad functionality or change input parameters. Sample Section took the opportunity to view the system in detail and pointed out major changes desired and an overall impression of the system. They were happy to see the system in such good shape and it made them see their working process more clearly.
Test session 2 This session was a dynamic test session. Sample Section was requested to perform functional and system tests on the system with real input data and their own test cases that can occur in their daily work. And also to come up with special and rare situations that the system could be facing. This session was performed with only cosmetic changes desired from Sample Section. They had also further ideas about possible expansions of the system, see Chapter 7 Possible Expansions.
Test session 3 The last test was the Acceptance test. Final test session, where the system changes were shown and a final approval were given from Sample Section. Sample Section approved the proposed prototype system and felt that the system and this report covered the area satisfying. The tests were preformed based on the requirements in Chapter 4.6. Because of the new demarcation of this system since the ASOS project started, no extensive tests were preformed our prototype.
40 (60)
6 Conclusions
This thesis shows the importance of aligning the process flow to avoid non-value adding actions in the organisation. We have showed that with small facilities the organisation can be lifted to a higher level of process alignment. For example, only by taking a step back and overview the process and all involved departments, a comprehensive picture points out important areas. By breaking down the work in the process an understanding of the lacks in a process can be revealed. These two perspectives are hard to understand for someone involved in the process. Either you have the comprehensive picture or the detail knowledge but seldom both. By a thesis of this kind both perspectives can be considered and evaluated.
A small department like Sample Section with much information to keep track of usually uses their own developed spreadsheets; these can often rather quickly be too complex for non-frequent users and can make it hard to keep track of changes and late updates. Designing a database in Microsoft Access is made by almost the same effort as designing the spreadsheets but with a remarkable result, both for the employees at the department and to other involved departments.
A database in Microsoft Access can be designed with user-friendly forms for input of data and data views and reports can be designed for frequent viewed data summaries. The database tables are designed to store the information not for viewing or inputting information. This thesis shows that this structure makes it harder to perform errors, easier to keep track of changes and facilitates for non-frequent users.
When different stakeholders are involved a project have a tendency to grow. At the start this thesis was more or less a local matter for Sample Section. Halfway through the thesis an intertwining with a more complex process improvement occurred with Project ASOS (Automated Sample Ordering System). The goal with ASOS is to further align the process of Sample Orders and Distribution. ASOS will initiate the whole flow from the common plan for samples to the actual distribution to the customer, collecting all information and storing it at one place within reach for all stakeholders. This will liberate time from “information hunting” in favour for the development and progress for the company. From this point our focus turned to creating a framework and a prototype were the database structure will be reused in the future (ASOS) and thereby absorb Sample Section System see Figure 26 ASOS.
41 (60)
Figure 26 ASOS, Automated Sample Ordering System
Master Sample
Plan
Order Draft
Sample Order
Sample Submission
Plan
Product Sample
Plan
Tests Error
Accessories
Telephones
Shipment form
Customer
42 (60)
7 Possible Expansions
Because the time for this thesis is limited it only results in a prototype of an order system at Sample Section. There are many possible expansions of the system and some of them are explained below.
The structure of the database covers the needs at Sample Section. The forms make it possible to perform tasks and gain access to stored data. However, the use of the forms and reports that present the data is limited. The development of more reports would make the work at Sample Section more rational. By automatically generating reports; errors made by hand will be eliminated. Also, there are more expansions within the forms. These improvements affect the usability e.g. will reports of storage, shipments and orders are useful in the everyday work. The reports can also be useful at meetings and inventories. Specifically a period summery would be essential where the user can specify the period herself and get a report on delivered units, model, description and errors. For more specific report expansions see Appendix D. With an existing support system a bench marketing can easier be preformed in order to further improve the process.
An automatic mail merge function would also make the process go faster. A lot of shipping mail is sent to recipients with well-structured information. Therefore, a function that automatically generates a mail to the receivers specified in the order eliminates duplicated work. These mails can contain information and attachments from the order. To see proposed designs of this mail merge see, Appendix D.
A possible expansion of the system to align the entire process even more is to make the database communicate with the ordering system at the shipping company. The shipment address could be exported into the shipping agents ordering system and in the other direction could the created shipment number be connected to the specific shipment.
Within the system, small changes will speed up the process. Such changes are e.g. extended matching of telephones to shipments that correspond to an order. If more than one telephone is connected to an order, the information from the first telephone should be automatically copied to the next telephone. If a function for counting connected telephones to shipment some mouse-clicks and time can be saved. If there is no telephone that corresponds to an order the possibility of manual shipment connection is essential for the stability of the ordering system.
During the development and testing of the system several smaller issues that would facilitate the work appeared e.g. rules for spelling in all input fields, warnings before closing windows and deleting telephones or accessories, view total percentage completed of the order in the switchboard and the search function can be extended by using multiple parameters or search with asterisks.
Sample Section also expressed their desire that some order fields are to be eligible to be filled in but at the same time give Sample Section a signal that the Project has deliberately not chosen to fill in this field and not has forgotten it.
We hope all of these desires will be implemented into ASOS to facilitate the sample distribution for Sample Section and the Project even more.
43 (60)
APPENDIX
A. Software Requirement Specification
I. Introduction
This document describes the requirements for the system that shall be produced by a master thesis for Sony Ericsson Mobile Communications department of Customizing, Sample Section.
The document describes system requirements in detail (Chapter 3).
II. Reference document
[1] Project Specification 4/159 35-FEA 202 8403
III. System requirements
This chapter describes the requirements on the system. Every requirement has its unique name and contains a shall-sentence. The first characters in the name is for determine what kind of a requirement it is.
IV. Functional service requirements
This subchapter describes the functional requirements divided into the four different services.
V. Storage
FS101: All incoming telephones shall be registered into the system.
FS102: A telephoneinformation shall contain a Series-number.
FS103: A telephoneinformation shall contain the colour of the telephone.
FS104: A telephoneinformation shall contain the telephone’s status.
FS105: A telephoneinformation shall contain error information.
FS106: All incoming amounts of accessories shall be registered into the system.
FS107: A telephoneinformation shall contain the CXC information.
FS108: A telephoneinformation shall contain IMEI-number.
FS109: A telephoneinformation shall contain model.
FS110: A telephoneinformation shall contain owner.
FS111: A telephoneinformation shall contain arrival date.
FS112: A telephoneinformation shall contain the CDA information.
FS113: A telephoneinformation shall contain the KRH information.
44 (60)
FS114: A telephoneinformation shall contain the keypad information.
FS115: A telephoneinformation shall contain the DPY information.
FS116: A telephoneinformation shall contain the build.
FS117: A telephoneinformation shall contain the manufacture date
FS118: A telephoneinformation shall contain unlocking codes.
FS119: A telephoneinformation shall contain Certificate.
FS120: A telephoneinformation shall contain tests that have been performed on the telephone. FS121: A telephoneinformation shall contain a field for Comments. FS122: A telephoneinformation shall contain a field for Sim-lock. FS123: A telephoneinformation shall contain a field for CXC revision. FS124: A telephoneinformation shall contain a field for CID. FS125: A telephone information shall contain a field for File system. FS126: A telephoneinformation shall contain a field for Script. FS127: A telephoneinformation shall contain a field for TAE.
VI. Order system
FS201: An order shall contain an order form.
FS202: An order shall contain a field for the Project name.
FS203: An order shall contain a field for the name of the person responsible of the order.
FS204: An order shall contain a field for the operator.
FS205: An order shall contain a field for the country.
FS206: An order shall contain a field for the number of ordered telephones.
FS207: An order shall contain a field for the number of RF-prepared ordered telephones.
FS208: An order shall contain a field for DPY-number.
FS209: An order shall contain a field for KRH-number
FS210: An order shall contain a field for CXC-number
FS211: An order shall contain a field for TAE-number.
FS212: An order shall contain a field for CDA-number.
FS213: An order shall contain a field for desired tests.
45 (60)
FS214: An order shall contain a field for purpose label.
FS215: An order shall contain a field for purpose.
FS216: An order shall contain a field for cost centre.
FS217: An order shall contain a field for customer.
FS218: An order shall contain a field for desired ship date.
FS219: An order shall contain a processing form.
FS220: A shipment form shall contain a field for tests that have been performed.
FS221: A processing form shall contain a field for scanning information.
FS222: A processing form shall contain a field for Sim-codes.
FS223: A shipment form shall contain a field for number of telephones that will be sent.
FS224: A processing form shall contain a field for optional information.
FS225: A shipment form shall contain a field for delivery address.
FS226: A shipment form shall contain a field for type of shipment.
FS227: A shipment form shall contain a field for shipment number.
FS228: A shipment form shall contain a field for shipment date.
FS229: A shipment form shall contain a field for AWB-number.
FS230: All new orders shall get a unique order number.
FS231: It shall be possible to save the information written in the order at any time when filled in minimum parameters.
FS232: It shall be possible to change the order at any time.
FS233: All changes after the order is sent to Sample Section shall be attracted attention.
FS234: In a form it shall clearly appear what status the order has.
FS235: The order status shall be either “not started”, “processing” or “sent”.
FS236: An order shall contain a field for different priority.
FS237: It shall be possible to update several orders simultaneously.
FS238: A shipment form shall contain a field for IMEI-numbers.
FS239: An order shall contain a field for file attachments.
FS240: An order shall contain a field for build.
46 (60)
FS241: An order shall contain a field for co-brand label.
FS242: An order shall contain a field for keypad.
FS243: An order shall contain a field for number of GOS-units ordered.
FS244: An order shall contain a field for language.
FS245: An order shall contain a field for Sim-lock.
FS246: An order shall contain a link to phone number to the recipient.
FS247: An order shall contain a link to e-mail address to the recipient.
FS248: An order shall contain a link to Cc. e-mail addresses.
FS249: An order shall contain a field for RF-kit content.
FS250: An order shall contain a field for comments.
FS251: A shipment form shall contain a field for comments.
FS252: The order shall contain a specification of the Kit content.
FS253: Sample Section shall be able to change the information in the order form.
FS254: The user shall be able to obliterate orders.
FS255: If an order has been obliterated shall Sample Section be notified.
FS256: An order shall contain a field for Certificate.
FS256: An order shall contain a field for Script
FS257: An order shall contain a field for File System.
FS258: An order shall contain a field for RF-prepared GOS-units ordered.
FS259: An order shall contain a field for Cc. e-mail addresses for the shipment mail.
FS260: An order shall contain a link to delivery address.
FS261: An order shall contain a field for CXC revision.
FS262: An order shall contain a field for CID.
FS263: An order shall contain a field for colour.
FS264: A shipment form shall contain a field for amount of RF-prepared units.
FS265: A shipment form shall contain a field for amount of GOS units.
FS266: A shipment form shall contain a field for amount of RF-prepared GOS units.
VII. Search function
FS301: The user shall be able to search on IMEI-number.
47 (60)
FS302: The user shall be able to search on Serial-number.
FS303: The user shall be able to search for error units.
FS304: A search on IMEI-number shall generate telephoneinformation for the unit.
FS305: A search on Series-number shall generate telephoneinformation for the unit.
FS306: A search for error units shall generate telephoneinformations of the units.
FS307: The user shall be able to search on order number.
FS308: The user shall be able to search on Project name.
FS309: The user shall be able to search on orderer.
FS310: The user shall be able to search on customer.
FS311: The user shall be able to search on country.
FS312: The user shall be able to search receiver.
FS313: The user shall be able to search AWB-number.
FS314: The user shall be able to search shipment number.
FS315: The user shall be able to search order status.
FS316: The user shall be able to view order statistics.
FS317: A search on order number shall generate the order.
FS318: A search on Project name shall generate orders made by this Project.
FS319: A search on orderer shall generate orders made by this orderer.
FS320: A search on customer shall generate orders related to this customer.
FS321: A search on country shall generate orders related to this country.
FS322: A search on receiver shall generate orders related to the receiver.
FS323: A search on AWB-number shall generate the order related to this number.
FS324: A search on shipment number shall generate the order related to this number.
FS325: A search on order status shall generate orders in this status.
FS326: A search on order statistics shall generate desired report.
FS327: The user shall be able to view a report on amount of stock goods.
FS328: A search on amount of stock goods shall generate quantity.
FS329: The user shall be able to search on model.
48 (60)
FS330: An order based search on model shall generate orders containing this model.
FS331: The user shall be able to search on build.
FS332: A search on build shall generate orders containing this build.
FS333: The user shall be able to search with free text.
FS334: The user shall be able to search with a combination of search parameters.
FS335: A search on model shall generate a list of telephones of this model.
FS336: A search on build shall generate a list of telephones of this model.
VIII. Error registration
FS401: The user shall be able to register error status for a telephone.
FS402: The error status shall be registered in the telephoneinformation.
FS403: The user shall be able to register error for a telephone.
IX. Revision
FS501: All orders shall be revision handled after sent to Sample Section.
FS502: Revision history shall contain date of change.
FS503: Revision history shall contain name of responsible for changes.
FS504: Revision history shall contain information about what has been changed.
FS505: The latest changes shall attract attention.
X. Quality requirements
This subchapter describes the quality requirements for the system.
XI. User friendly
QR101: Employees at Sample Section shall be able to use the Sample Section System guided by a short instruction.
QR102: The Project Manager shall be able to use the Sample Section System guided by a short instruction.
49 (60)
B. ER-model
50 (60)
C. Tables and Relationships
51 (60)
D. Forms
Sample Section switchboard Functionality: From here the user can go directly to the base functions and also see an overview and go to all the orders that not have been shipped. Possible expansions: Show percentage completed/shipped units per order.
52 (60)
New Order Functionality: Here the Project can lay their orders. The field above the Order history is compulsory for laying an order. Possible expansions: Automate “Total amount completed”
53 (60)
Shipment Functionality: All shipment information presented and connected IMEI-numbers to this shipment. Possible expansions: Shipping-mail see “Shipping-mail”.
54 (60)
Customer Functionality: All information about the customers is saved and all the orders to this customer are presented. Possible expansions:
55 (60)
Incoming Telephones Functionality: All incoming telephones are stored in the system with all static parameters. Possible expansions: “Delete Telephones” for inventory use. Save telephones as individuals with IMEI-number and Serial-number.
New Accessories Functionality: Register incoming accessories as chargers, manuals etc. and delete accessories for inventory use. Possible expansions:
56 (60)
Search Functionality: Search for telephones, orders, shipments and accessory. Possible expansions: Searching with multiple parameters.
Reports Functionality: Being able to view and print “Telephone Storage” and “Accessory Storage”. Possible expansions: “Period Summary” and “Error Report”
57 (60)
Telephone Functionality: All information about a telephone stored in one view. Possible expansions:
Shipping-mail: Shipment notification e-mail with attachments (compilation and Project’s attachment)
58 (60)
E. Terminology
Word Explanations
IMEI-number The identification number for every unit
Serial-number The serial-number for every unit.
KRH Hardware information
DPY Kit information
Kit Telephone box with Telephone, charger, manual etc.
CXC/CDA/TAE Software
Script/File System Software put together
Build Hardware version
RF-prepared Telephone prepared for measurement
MSP Master Sample Plan, General plan for all sample distribution
PSP Product Sample Plan, Specific product plan for sample distribution
Certificate Flashing security level
Shipment form DHL, FedEx, hand carried etc.
AWB-number Air-Way-Bill number
Accessory Charger, manual, headset, towel etc.
Flashing Uploading software to a telephone
59 (60)
References 1 www.sonyericsson.com 2004-03-25 2 Ace Magazine no. 3 2004 3 Sony Ericsson’s Intranet 2004-04-01 4 Sven Jirby (2004), Processorienteringens paradoxer, Kvalitetsmagasinet 5 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur, page 9 6 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur, page 57-60 7 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur, page 62-63 8 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur, page 89 9 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur, page 102 10 Viswanathan Krishnan, Steven D. Eppinger and Daniel E. Whitney (1997), A Model-Based Framework to Overlap Product Development Activities 11 Anders Ljungberg, Everth Larsson (2001) Processbaserad verksamhetsutveckling, Lund: Studentlitteratur 286 12 Dag Bjorndal, Göran Persson och Helge Virum (red) (2003), Logistik för konkurrenskraft, Lund: Liber, page 348 13 Anders Ljungberg, Everth Larsson (2001) Processbaserad verksamhetsutveckling, Lund: Studentlitteratur 289 14 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur page 101-108 15 Per Darmer and Per V. Freytag (red) (1995), Företagsekonomisk undersökningsmetodik, Lund: Studentlitteratur, page 22 16 Cleland, D & Ireland, L (2002): Project Management. Strategic Design and Implementation. 4th international edition. MrGraw-Hill, Singapore, page. 161-190. 17 Dag Bjorndal, Göran Persson och Helge Virum (red) (2003), Logistik för konkurrenskraft, Lund: Liber, page 360-362 18 Internationella Handelshögskolan i Jönköping, www.ihh.hj.se/utbildn/utbildpro/produktionslogistik.htm 2004-04-27 19 IT-universitetet i Kista, http://www.it.kth.se/artikel/618/004004004/se, 2004-04-27 20 Data Power UK Ltd, Microsoft Access 97, page 25 21 Thomas Padron-McCarthy (2003), http://www.ida.liu.se/~tompa/databaser/databaser.html, 2004-04-20, Part 1 22 Data Power UK Ltd (1997), Microsoft Access 97, Steinkjer, page 24 23 Thomas Ahlandsberg and Marie Kallin (1999), Microsoft Access 97, Stockholm: Docendo Läromedel, page 3 24 Lars Axelsson and Martin Hodefjäll (1993), Praktisk datamodellering, Lund: Studentlitteratur, page 19 25 Thomas Padron-McCarthy (2003), http://www.ida.liu.se/~tompa/databaser/databaser.html, 2004-05-18, Part 1 26 Microsoft, www.microsoft.com/office/Excel/prodinfo/overview.mspx 27 Karin Olson (1997), Grundkurs i Excel 7.0 28 Judith Bell (1993), Introduktion till Forskningsmetodik, Lund: Studentlitteratur, page 63 29 Per Darmer and Per V. Freytag (red) (1995), Företagsekonomisk undersökningsmetodik, Lund: Studentlitteratur, page 34 30 Annika Lantz (1993), Intervjumetodik, Lund: Studentlitteratur, page 31-32 31 Martyn Denscombe (2000), Forskningshandbok –för småskaliga forskningsprojekt inom samhällsvetenskaperna, Lund: Studentlitteratur, page 132 32 Olof Rentzhog (1998), Processorientering en grund för morgondagens organisationer, Lund: Studentlitteratur, page 115 33 Annika Lantz (1993), Intervjumetodik, Lund: Studentlitteratur, page 33 34 Annika Lantz (1993), Intervjumetodik, Lund: Studentlitteratur, page 34 35 Per Darmer and Per V. Freytag (red) (1995), Företagsekonomiskundersökningsmetodik, Lund: Studentlitteratur, page 252-255 36 Per Darmer and Per V. Freytag (red) (1995), Företagsekonomiskundersökningsmetodik, Lund: Studentlitteratur, page 255-257 37 Inge Carlström and Lena-Pia Hagman (1992), Metodik för utvecklingsarbete & utvärdering, Göteborg: Akademiförlaget, page 111 38 www.nfi.se/webbdok.asp?DokID=231 2004-06-02 39 Martyn Denscombe (2000), Forskningshandbok –för småskaliga forskningsprojekt inom samhällsvetenskaperna, Lund: Studentlitteratur, page137 40 www.humantalent.se/produktblad/workshopledarutbildning.htm 2004-06-03 41 Martyn Denscombe (2000), Forskningshandbok –för småskaliga forskningsprojekt inom samhällsvetenskaperna, Lund: Studentlitteratur, page 138 42 Runar Patel and Bo Davidsson (1994), Forskningsmetodikens grunder, Lund: Studentlitteratur, page 8-10
60 (60)