NAPA Credit Consolidation Project

Transcription

1 Team Number: Team Members: Six Megan Glass, Joni Staack, and Colin Untiedt NAPA Warehouse Clients NAPA Eau Claire

2 Table of Contents Requirements Specification... 3 Company Name & Address... 3 Mission & Vision Statement... 3 Project Objective... 3 Method of Approach... 3 Feasibility Analysis... 4 Economical Feasibility... 4 Technical and Operational Feasibility... 4 Management Issues... 6 Team member responsibilities... 6 Meetings & Communication... 6 Project Schedule... 7 Design Specification... 9 Logical Design... 9 Use-Case Diagram... 9 DFDs ERD Interface Design Dialogue Diagram Pseudo-Code Decision Tree Decision Table Relation Tables Normalization Physical Design Hardware and Software Specification Test Plan Implementation Plan Page 2

3 Company Name & Address NAPA Auto Parts 3620 Mall Drive Eau Claire, WI (715) Requirements Specification Mission & Vision Statement The mission of Genuine Service and Machine, Inc. dba NAPA Auto Parts is to provide consumers with valuable advice and quality auto parts at a reasonable price. Project Objective The objective of this project is to develop a way to increase the productivity of receiving credit for returned Core and Defective products to NAPA. It is aimed at the shipping and receiving department of the NAPA store and the warehouse levels. The current system NAPA has in place requires almost a full time employee to complete this rather simple task. The current employee uses a combination of and many Microsoft Excel spreadsheets to keep track of the credit lines. Our system design will dramatically decrease the effort and amount of time needed to obtain credit for the returned items. Method of Approach We will develop a real time program that will send credit information between the NAPA and the warehouse. The program will send a notification to the warehouse program requesting credit for core and defective parts that have been returned to NAPA. The warehouse will submit the credit into the new system. When credit has been submitted by the warehouse, it will prompt a notification that is displayed at NAPA. If full credit is received for the part, the entry will be archived and a notification will be sent to NAPA confirming it. If no credit or only partial credit is received it will prompt a notification alert at NAPA to submit full credit request again to the warehouse. The program will be installed on all of the desktops at NAPA and the only desktop located at the warehouse. Page 3

4 Feasibility Analysis Economical Feasibility Our tangible benefit is our increased speed of activity which provides us with higher profit margins of $20,280/year. This is because currently someone works 40 hours/week at $10/hour on a project such as this, and with the new system someone will only have to work one hour/week at $10/hour, creating a profit margin of $390/week. Some intangible benefits include increased organizational necessity and more timely information being sent and received. The tangible costs for the system include system development, new hardware and software purchases, and user training. These will be one-time costs of $14,500. Each PC, six total, will cost $780, totaling $4,680. Then there will be the system development cost of $19,230. The system will take 20 weeks to develop, so our developer will earn $24/hour, working 40 hours/week. Our total for one-time costs will be $23,910. Our intangible cost will be new hardware and software purchases and maintenance. This will total around $300/month, totaling $3,600/year. After calculating all the costs and benefits over a five-year period, it was found that the break-even analysis is at 1.27 years. The complete break even analysis is located on Figure 1 on the next page. Technical and Operational Feasibility The system being developed will be user-friendly, so it s easy to use and easy to learn. There will be a two-day training session required for all employees involved with the system to learn how the basic operations work. In addition, there will be ongoing maintenance needed as time goes on as glitches become apparent. Eventually this will lead to updates in the system as newer and better options become available. Overall, the program that will be built will be an easy integration into the network and will be of rather simple design for the users. Legal and Political Feasibility With us creating a new system for this project there is not a regulatory agency that will affect us; however, we will have to copyright our new system. NAPA is a privately owned company so the owner, Mr. Ken Costley, and the manager, Mr. Lane Costley, will be on hand to make the decisions. The Costleys biggest concerns are price, efficiency of and training on the new system. Page 4

5 Figure 1 Page 5

6 Management Issues Team member responsibilities Colin Untiedt Colin is the team leader and time keeper. As team leader, he is in charge of setting up meeting times and locations. He also has the responsibility to make sure everyone is staying focused on what they need to have done and completing work on time. If any conflicts arise, he will find a compromise with the team and solve without a team meltdown. Colin will also be in charge of submitting all files when they are completed. Also, as timekeeper he is in charge of keeping everything moving and productive during meetings. Joni Staack Joni is the team editor and compiler. All completed files and reports will be submitted to Joni. When submitted, she will proofread for any errors that the files or reports may contain. When any errors are found she will correct them. If she has confusion or questions on the files, she will contact either team member for clarification. As compiler, Joni is in charge of combining separate files from all team members into one complete team file. The complete team file has the same tone and format throughout the file in the team standard to document, Microsoft Word. Megan Glass Megan is the team scribe and researcher. Megan is in charge of researching all hardware and software aspects of the system. She will take note of all specifications of the hardware and software to make sure they will be compatible with the system to be developed and already existing system. She will keep track of the costs of the hardware and software. As scribe, during team meetings she will take careful notes of all discussion so that they may be referenced during future meetings. Meetings & Communication All team meetings will be held at the McIntyre Library on Mondays at 1:00 pm. Colin will be in charge of reserving a meeting room for each meeting. For additional meetings, the team will discuss during the Monday meetings and set the additional date and time then. Communication among the team will consist of: Phone During class Page 6

7 Project Schedule Gantt chart PERT Chart (Critical Path indicated in RED) Page 7

8 1. Requirements Collection During this phase we will collect information about the project from NAPA. We will get specifics on what the problem is and how they think we could make it easier for them to get credit for returned cores and defects. We will also find out what existing methods they use and the computer specifications that they have. 2. Screen System Design Come up with ideas within the team to create the system. Come up with a final plan for creating the system. Determine all specifics to report the system design to NAPA. 3. Report System Design Report our final system design plan to NAPA for approval to start building the program. Also, get feedback and answer any question NAPA may have about the plan. 4. Program/Database Design Develop the design for the program so it can be sent to programmers to be created. Have everything very specific and organized so output from programmers is what we need. 5. User Documentation Write documentation for the system to be built. This should be given to programmers and to NAPA. Gives them a good idea of what the program will do when completed. 6. Programming Documentation is given to programmers. The programmers will build the complete program. This could possibly be a problem area. The completed program may not have the user-friendly environment we are trying to create. This can be avoided and resolved by careful and thorough documentation. 7. Testing Program is tested for bugs. This step is crucial because this will show us that the program is full proof. We must assure all bugs are ironed out before installation into NAPA. 8. Installation The final step of the project. The program is installed on desktops at NAPA and the warehouse. The program can now be run and used to enhance the efficiency of receiving credit for returned and defective cores. Page 8

9 Logical Design Design Specification Use-Case Diagram NAPA Credit Consolidation System Purchase Products «uses» «uses» Check for Core Value Customer Return Products Staff Member Process Reports «uses» Management Staff Warehouse Staff Process Product Credit Page 9

10 DFDs ` Level-0 Customer Formatted Core/Defect Data Updated Credit Data D2: Core/Defect Files Return product Payment And Receipt 1.0 Receive and transform Core/Defect Return Data Core/Defect Reports 2.0 Update Core/Defect File Approved Reports Defect Report Core-Defect Report Approved Credit Report Notification Core Report Accounting Data Accounting 3.0 Produce Management Reports Management Reports Approved Reports Resubmit/Reminder Notification NAPA Warehouse Store Managers Page 10

11 Level-1 of Process 1 Receipt Customer Return product 1.2 Generate customer receipt Return data 1.1 Receive customer s Core/Defect return Return data 1.4 Transform data to Core/ Defect file Return data Accounting Accounting Data 1.3 Transform data to Accounting format Level-1 of Process 2 Return Data 2.1 Update Core Defect File Formatted Core/Defect Data Approved Reports 2.2 Pull & Approve Reports Core Report Core-Defect Report Defect Report D2: Core/Defect Files Approved Reports Updated Credit Data NAPA Warehouse Resubmit/Reminder Notification Approved Credit Report Notification 2.3 Received Full or Partial Credit Page 11

12 ERD Defect File PK Defect ID PK,FK1 Product ID PK,FK1 Line Code Cost Core Files PK,FK1 Product ID PK,FK1 Line Code PK Core ID Cost may have / belong to PK PK Product Product ID Line Code Cost may have / belong to may belong to / has PK,FK2 PK,FK1 PK,FK1 PK Line Item Ship ID Line Code Product ID Line ID Quantity Cost has / must have PK Shipment Ship ID Date Date Paid Amount Paid Page 12

13 Interface Design Figure 2 shows the interface that will be implemented at the NAPA store. Here the user will input all the required credit information that will be sent to the warehouse. Figure 2 Figure 3 is the simple pop-up that will arrive at the warehouse machine when the credit request is sent from the NAPA store. Figure 4 is the notification that is received at the store once the warehouse submits credit for the returned item. Figure 3 Figure 4 Page 13

14 Dialogue Diagram 0 Credit Request Screen 0 1 Enter Returned Part Information 0 2 Choose Return Type 0 3 Submit Info to Warehouse 0 4 Warehouse Submit Credit Amount Re-Submit Info to Warehouse Confirm Credit 3 0 Page 14

15 Pseudo-Code BEGIN IF IF you receive full credit THEN CLOSE file ELSE IF you receive partial credit THEN SEND correction request ELSE IF original request is >60 days old THEN RE-SUBMIT original credit request ELSE IF original request is <15 days old THEN DO nothing ELSE SEND a gentle reminder END IF Page 15

16 Decision Tree Process: Credit Process Did the warehouse credit for the amount requested? Yes Close file No Was partial credit received? Yes Send correction request No Is original request > 60 days old? Yes Re-submit original credit request No Is original request < 15 days? Yes Do nothing No Send a gentle reminder Page 16

17 Decision Table Conditions Rules Received Full Credit Y N N N N Partial Credit Y N N N Original Request >60 days old Y N N Original Request <15days old Y N Actions Close File Send Correction Request Re-submit original request Send a reminder Do Nothing x x x x x Page 17

18 Relation Tables Page 18

19 Normalization DEFECT FILES(Defect_ID, Product_ID, Line_Code, Cost) CORE FILES(Core_ID, Product_ID, Line_Code, Cost) PRODUCT(Product_ID, Line_Code, Cost) LINE ITEM(Line_ID, Product_ID, Line_Code, Ship_ID, Quantity, Cost) SHIPMENT(Ship_ID, Date, Date_Paid, Amount_Paid) Page 19

20 Physical Design Hardware and Software Specification For our system we will employ an IS graduate to design and code the program. The program will organize and send out notifications to the warehouse program, which will then send out a notification back to NAPA. This requires NAPA to get six new computers. The recommended PCs for NAPA have an Intel Core 2 Duo processor E7300, 4GB DDR2 SDRAM, double-layer DVD±RW/CD-RW drive, 640GB hard drive, Intel Graphics Media Accelerator 3100 and Windows Vista Home Premium with SP1 and Microsoft Outlook. The monitor will be a 19" widescreen flat-panel LCD monitor with ultrafast 5 ms response time and 1000:1 contrast ratio; HD-ready via DVI-D input with HDCP; and built-in power and cable management. In addition, an Internet connection will be required on each PC containing the NAPA system. Test Plan In order to test our implemented system we would use existing data and trial run the system, essentially performing a system test. We would gather previous records from all different types of situations and enter them into the program as if these were real customers. This can be done without any professionals or IS specialists, because this is the type of work that will be expected of the employees, so this way it can also be used as training. The system would process the data and send out all necessary notifications. In this trial run we expect to see that the system runs as planned. All necessary notifications are sent out according to the situation, and all the correct files are recorded in the correct place. In the end, NAPA will accept and credit the orders to us without any glitches occurring. Overall, we don t expect to see any major errors occurring within the program. Implementation Plan In order to implement the program we will use a parallel installation because this allows us to compare the old program with the new program to see exactly how much time and money will be saved. It also allows for training and major errors to be worked out before the new system is put into full effect and the old system is turned off. This will provide for a little security/backup in case something dramatically wrong with the new system occurs. Our user training will consist of a two-day training session just on the use of the new system. This will provide employees with the knowledge of how to use the program and how it operates compared to the old system. As a post installation review we will look at records after a few weeks of operation and compare it with the old system to see if this program is going according to plan in the sense of it saving money and time. This will just consist of a quick analysis or old records. Page 20

21 Appendix Appendix A: Records of Team Meetings Appendix B: Existing Forms from Old System Page 21

22 Appendix A Records of Team Meetings Page 22

23 September 9, 2008: Met in library at 1pm. Decided exactly what company and program we wanted to implement. We decided on NAPA and a system to organize all the products into one program on the computer. We submitted our Getting Organized Report. We also submitted our Project Title. September 10, 2008: We revised our Getting Organized Report in class. September 15, 2008: We met in the library at 1pm. We submitted our Project Status Report #1, and discussed potential roles for Colin, Joni, and I throughout the project. September 29, 2008: We met in the library at 1pm. We worked on the Project Proposal for an hour and divided up the parts. We needed additional time to thoroughly complete the whole proposal, so we decided on another meeting time for later in the week. September 29, 2008: We met with Dr. Pratt to go over our project briefing. Here we decided to change the project to a credit consolidation program instead of the original product organization system. October 2, 2008: We met in the library in the evening for two hours. We brought together our parts of the proposal and combined all the information into one document. We then altered any parts to become more professional. We submitted the Project Proposal. October 13, 2008: We met in the library at 1pm to just work on some DFDs and other side stuff needed for the project. October 19, 2008: We met in the library to put some more touches on different aspects of the project. October 26, 2008: We met in the library to work on the DFDs. November 6, 2008: We met in the library at 11am. We submitted Project Status Report #2. November 10, 2008: We met in the library to work on the ERD. November 10, 2008: We had our meeting with Dr. Pratt to discuss our ERD. Here we revised the entire ERD. November 20, 2008: We added the revisions to the ERD. More work was also performed on the DFDs. December 2, 2008: We met in the library and completed the decision table, decision tree, and pseudocode. We also started discussing the interface design. December 4, 2008: We met in the library to work on the Access part of the project. We also complete the DFDs. Lastly, the dialogue diagrams were completed. December 7, 2008: Finishing touches were made to the project. The last details were added. The overall structure was put together, and the appendix was finished. Page 23

24 Appendix B Records of Team Meetings Page 24

25 These are screen shots of the existing Microsoft Excel spreadsheets that NAPA currently uses as their credit system. Page 25

26 Page 26

27 Page 27