A typical car trade in process could go something like this. First a customer would come to the dealer and say that they would like to see how much trade in they can get for their vehicle. The dealer would gather the information about the car such as Make, Model, Year, Color, Features, Condition, etc. This information will then be submitted to the dealer's internal data warehousing system to figure out how much they could potentially sell the car for. The dealer would then review this information and then tell the customer how much they could receive for their vehicle. If the customer decides to hold onto the car then the exchange is completed. If they decide that the value is reasonable then they will trade the car to the dealer. The car dealership will add the car to their records as to how many and what used cars they own. The dealer will fill out a form which details the transaction (dealer that completed the purchase, customer info, car info etc.) for record keeping. The customer will be given the money promised for the car and the dealership's total funds will be deducted the proper amount. The customer will then be given the option to take the money and complete the transaction or use the money as credit towards purchasing another car. If they choose to take the money the transaction is finished and if they choose to purchase another car that will complete the current scenario and lead into the same type of scenario that would result if they were just coming in to purchase a car. A possible incentive to purchase another car would be for the customer to get more credit towards a new car then they would get if they just took the money in cash and left.

A typical part ordering scenario could go something like this. The need for a part to be ordered is identified from one of many sources (car sensor, low inventory levels, or mechanic request). The request for a part is passed into the inventory system to make sure that there is a need for that part. If the inventory system says that the part is in stock then the request is canceled; otherwise the order is stored in an object for the request to be processed. The requests will be stored in a queue and popped off as they are fulfilled based on the date that the request was made. Once a the request is at the top of the list, the parts company (which should be generalized into one body to simplify things) will be contacted. They will be given the product number and various other important information about the part as needed. The parts company will then tell the dealership if they have the part in stock and (regardless of if it is in stock) how long it will take for them to receive the part. The request then goes into a PartsOrdered object with a Boolean accessor indicating that the part has been ordered but has not arrived yet. Once the part has arrived, the Boolean will be set to true (that it has arrived) and then the date at which the part came in will be recorded to the log. After the part has arrived at the dealership it will be added into the inventory listing for all parts available to the mechanics and whoever requested the part (most likely mechanic) will be informed that the part for whatever vehicle they need it for has been received. If a customer ordered the part then they will be informed of it's arrival. This will effectively complete the transaction but it is important to note that this transaction's time can vary greatly based on availability of the product at any given time. If we are working with the car dealership like a simulation where days pass and functions are called accordingly then this will become important because recommendations about availability of products and when to order them can be extrapolated from the data.

After a salesman sells a car, the application uses the profits earned on the car's sale to determine how much the salesman earns as a commission. The amounts of commissions are sent to the dealership's payroll and added to the salesman's salary. Each salesman should also have an "account" of the commissions he has earned, and he should be able to check this amount for correctness and for personal recordkeeping. It could also be used for internal events, such as competitions between salesmen for rewards.
Claims Analysis: The application must contain the formulas for calculating commissions. If there are differing amounts earned (say, senior salesmen earn a higher rate), the application will need to differentiate between them. Also, for the account system to function there will be a need for persistent data storage and retrieval. The system could be integrated with the sales/inventory system, crediting a salesman with a commission as soon as a sale is finalized. This would be incredibly streamlined, but would remove a bit of control from the dealership and its staff. It could also be "standalone;" it wouldn't actually be a separate application, but it could function independently, requiring salesmen/management to input sales manually for the purposes of commissions. This enables a little extra control (management adding 10% to the value of a vehicle sold as a reward), but is also open to abuse (a salesman adding 10% to the value of a vehicle sold to cheat the dealership out of extra commission). With this system, though, comes the fact that commissions are relatively fixed, and that an update would take additional effort, and possibly a new version of the application. It would also become difficult to issue "bonus" commissions (extra amounts on top of a normal commission, say for reaching certain milestones).

A mechanic needs a part for a repair he is working on. He checks the application to see if the shop has any in stock. If it does, it shows its location in storage. The mechanic tells the program he is taking one, which the program should then subtract from available inventory. Should the desired part not be in stock, options should be made available. The mechanic could order one from the manufacturer, or call a local mechanic/dealership to see if any extras are available. To avoid this scenario, the program should alert users, particularly those involved in purchasing, when specific items are running low/sold out. If could even automatically order, if that is desired by the dealership.
Claims Analysis: To keep track of all of the parts (I assume there are many.) would require a great deal of persistent data. This data could become rather complex with each item's quantity, location, price, and identification stored somewhere in the system. Automatic ordering takes some control away from the dealership, and should only be implemented at their request, as it could end up in the dealership ordering (and more importantly, paying for) parts they don't need or want. However, if implemented well, parts will almost never be out of stock, and customer service could be phenomenal.

John drives his 1986 Toyota Corolla into a Honda dealership with intent to sell. Bob the salesperson at the dealership intercepts John and they go and look at his car. The car is old, but has new decent tires, and the paint is faded and starting to rust. The interior is in excellent condition and it looks as if some aftermarket work had been done to the car. Bob marks this information down on his paper and clicks on the Trade-in button on the software application. Bob enters the car's name and specs into the system along with the condition. The software reports back a figure and Bob has to decide if the car is worth it for the dealership. He decides to take the trade in and writes out a check to John. Afterwards, Bob enters the trade in price into the system and the system adds the car to the lot at a new marked-up selling price.

Claims Analysis
To support this scenario, the application must be able to correctly appraise a car based on the information given to it by the dealership employee. To do this, the system is required to have a database of car prices. However, this may be too difficult to keep current since the database would have to be updated manually. Another approach would be to have the application query the online Kelly Blue Book site with the information given to it about the car. This would return the appraised price of the traded in car. One more approach would be to have set values in the application for certain types of cars between certain years. Once these bounds would be established in the program, the condition of the car could accordingly adjust the final price.

John has been driving his rather newly purchased car around for awhile now. It is only natural for normal wear and tear to plague the car. Since John lives in the city, with a lot of stop-and-go traffic, the brakes pads on his car are wearing thin. They are almost to the point of the metal warning tab rubbing against the rotor, which indicate that the brakes are completely shot. However, in this case, John's car is equipped with special dealership sensors to warn of this. The sensor sees the brake pad is almost completely warn and sends a signal to the dealerships software system to indicate of this problem. At the dealership, Bob receives the signal and turns off the warning. He then calls John to try and schedule an appointment to come in and service the brakes.

Claims Analysis
For the scenario's goal to be met there has to be good communication between the customer and the dealership so time isn't wasted before the part fails. Also, there must be some sort of conditional contract for the use of the dealerships special sensors. The sensors should only appear on new cars bought directly from that specific dealership. The customer may also have the option for the sensors to not be included in the purchase of their new car. The warranty on the lifetime use of these sensors should also be a specified time by the dealership, and after this time expires the sensors become inactive due to the car's age. Another part of the product lifecycle management could include customer specific profiles. The car dealership can suggest different brakes for that customer depending on the kind of driving he is doing. This can also apply to situations such as tire wear and tune ups. Depending on the kind of driving the owner does, he may need more or less aggressive tread on his tires, and the PLM of the system would determine this. How many miles the owner drives his car and how frequently may warrant different oil to be used in the car as well.

Tom will bring his old car to Bob's dealership where he is buying a new car. Bob will get the vehicle identification number (VIN) off of Tom's old car. Bob will then take the VIN and enter it into his car dealership management software. The software will decode the VIN which allows Tom to see all of the features that the car has. The program will automatically get the current Kelly Blue Book value for the car from the VIN information that was entered. Tom may than use this value as the trade in credit that Bob will receive for his car.

Claims Analysis: In order for the application to obtain the Kelly Blue Book value the computer must be connected to the Internet. Also the salesman must check to make sure the car has the features in originally had as according to the VIN information. Another approach is to have someone else at the dealership look over the car and determine a price according to what he or she thinks of the car.

Rob the manager decides that Jim an employee currently working for Rob at the dealership is not performing up to his standards and needs to be fired. After Jim is fired Rob must remove Jim's status as an employee from the car dealership management system. In order to do this Rob first much check how much he has worked and the commissions he has earned since the last pay check. Once this is determined a check must be printed in Jim's name for the amount that he has made. Next, Rob can change the status of Jim from employee to past employee. This will make sure Jim does not have access to the system anymore and cause harm to the system.

Claims Analysis: In stead of changing an employee's status to past employee after they are fired, one might want to just change there login rights to the system. This could potentially reduce the amount of work that is needed to be done.

A customer walked in with an idea of what car he wants. He approached the salespeople and asked if this specific brand with this model available at this dealership. The salespeople immediately enter all the information includes: brand, year model, mileages, etc… The application would return the result with the car if it there is one or more available. If the car is available at a different dealership location then it should indicates that location. The salespeople can click on that link and it would shows all the information about that car likes price, features, and option, etc…
Analysis: To fully supports what described above, this application should able to contact a centralized database to make the search if that specific model from other dealership location. However this application will not fully works if a small dealership where there is no centralized database. On the other hand, an option can allow the dealership to toggle if there is an centralized database or not.

A customer just bought a car at this dealership and his warranty has not end yet, and he wants to add additional warranty on his car and certain part of his car (lets just say his sound system). The salesperson has couple options to pull this purchased; he can search the purchased date which will shows all purchased for that day, or he can search by first name and last name. For this scenario he searched by first and last name. The result shows detail information for that purchased and also has an option for upgrading features or option package and of course warranty. The warranty portion includes all warranty packages available for that car. If that car is an old car then number of packages will be less than new one. After picked out the package that customer wants and hit submit, it will print out the form where the customer needs to sign; for other information (name, address, etc…) the application will pulled from the record.
Analysis: Like previous scenario, this one also required a working database. Also one draw back for this application is the use of third party warranty. If we limit to just warranty from the dealership then the problem has shrink.

To begin, the person or people in charge of performing this job will receive a list of all the new vehicles with all their information. This information will include but not be limited to make, model, year, pin number, color, options included on the vehicle, and whatever else the dealership thinks is relevant data. On the program interface, there will be an option to add new vehicles to the existing list. This option should be password protected in order to prevent any unauthorized access to the information. Upon clicking OK, there will be an interface that appears that will have various drop-down menus that will have a select type of input that the user can enter in order to prevent and inconsistency between separate. Obviously these select inputs will be preprogrammed into the system due to the fact that all the different choices that will be known ahead of time. i.e. There are only certain colors a select car model can be available in. Also, keep in mind that to prevent confusion, none of these values can be left null when the user clicks the submit key. If the user does click it, and there is a value that wasn't entered, the user will be prompted to fill in those values. After those appropriate actions are taken, the information will then be stored in the database to be viewed by the rest of the staff.

Claims Analysis- As far as coding is concerned, there will need to be a class or two that will display an interface that will allow the user to enter the given inputs and submit them to whatever form of storage the group decides on using.
The following is the list of pros and cons for this particular part of the system:

Pros
-Having this interface, although repetitive for the user entering the info, will keep the procedure organized to prevent mistakes and data in consistencies.
-Having the information in drop-down menus prevent inconsistent data. i.e. An employee adding the color Light Red for a car that's Pink.

Cons
-The interface won't allow cars to be entered if all the information isn't known.
-The drop-down menus don't account for special situations. One example would be if the dealership gets an old used car that may have features on it that aren't in the new models.

Immediately after a car is bought from the dealership, the employee will schedule a date for when the owner will need to take the car for servicing. When that time comes, the mechanics will perform any work that is necessary to keep the car in working order, than they will have an option in the system to enter all the information that was done. Some of this information includes, but is not limited, car pin number (not all information on the car is required due to the fact that that information is already present in the database (See previous scenario)), what kind of repairs were done to the car, and the new date for the next servicing. As far as the restrictions in the interface, the only major check that should be put in place will be a check that compares the car number to make sure that the car was actually one sold from the dealer. If the numbers don't match, the user is prompted to reenter the number. As far as the rest of the information, the interface displays a text box for the other inputs. The only information that will not be required to be entered when the submit button is pressed will be the information on what was done with the car. The input will not be accepted if the car number and new service date isn't there. Pressing the submit button will add the new servicing information into the archives.

Claims Analysis- For the coding, there will need to be some written that will display an interface that gives the user the text boxes to enter the info. There will also need to be coding that checks to make sure that the car number is correct and that the required fields are filled. The form of storage for the information must also be decided and implemented.
The following are pros and cons of this interface:

Pros
-This interface allows the dealership to have an organized way of keeping track of the servicing of their cars.
-The checks that are implemented into the system prevent inconsistent data to be entered. It also makes sure that none of the car services were skipped or forgotten.

Cons
-This interface does not include special situations. i.e. A car breaks down unexpectedly and need special repairs. This could probably be fixed by have an option in this interface that will allow the user to enter data of special situations.

The class I thought about to create is one that does a lemon check. The basis of this class is to keep a record of the cars whether or not they have been in accidents. The class will keep track of the cars overall mileage, the unique VIN (vehicle identification number), type of work needed on a car, and other necessary attributes. The classes' behaviors will be to run a lemon check and to keep a record if the car falls under the qualifications of a lemon. Another behavior of this class is to recreate the record of the car.
This class should be a subclass of a parent class like vehicle. The class will inherit some of the attributes of the higher class like car's make, model, year, color, etc for the lemon check. The report should mimic the report of carfax.com giving any customer the information about the car. Some of those attributes would include Title information, including salvaged or junked titles:
" Flood damage history
" Total loss accident history
" Odometer readings
" Lemon history
" State emissions inspection results
" Number of owners
" Service records
" Lien activity, and/or
" Vehicle use (taxi, rental, lease, etc.)

The next scenario I plan on making is an Inventory class. The class could be as small as just keeping inventory of the cars or even the whole dealership. I have the class attributes as number of vehicles in inventory. Second, types of vehicles in stock would be another attribute. A third attribute would be the inventory's worth for possible liquidation purposes. Another one is to include the car's worth and if it is used or new
The inventory would also have behaviors, firstly, having the ability to check inventory and making a report of the cars in stock if necessary. Another behavior would have the ability to add or subtract vehicles based on the buying or selling of vehicles.
The inventory class can also be a subclass working under a main class of dealership or maybe be a division of the dealership.

Inventory class
Attributes:
numberofVehicles
TypeofVehicles
inventorysWorth
Behaviors
check inventory
addVehicle
subtractVehicle

1. Mary enters car dealership looking to buy a new vehicle.
2. She meets John, who persuades her to test drive a new Ford Focus.
3. Mary decides to buy a new Ford Focus.
4. Mary and John negotiate price, features, and manufacturing warranty agreements.
5. Mary signs a formal written contract and provides an acceptable form of payment.
6. John enters the car sale's data into the car dealership's specialized software application.
7. Jeff, the general dealership manager is passed the information entered by John and reviews the information on his own personal computer.
8. Upon successfully reviewing the details of John's sale, Jeff sends a message to John's computer providing feedback and congratulations.
9. Jeff approves of the sale using the dealership application and the program removes Mary's car from the dealership's inventory.
10. At the end of the day, Jeff reviews the day's top sales and car dealers and generates commissions and bonuses based upon performance.

Flow of events 1. Vera leaves work late and begins to drive her two year
old Ford Escape home.
2. The sun sets and Vera switches on her headlights.
3. The headlights trigger a luminosity meter designed to monitor the effectiveness of the headlight's bulbs.
4. The luminosity reading is below the threshold for safe driving.
5. Car computer is alerted and attempts to automatically find and connect to open wifi hotspots while driving in order to alert car dealership of the car's headlight failure.
6. No wifi access points are found.
7. Vera pulls into her garage, and computer automatically recognizes the presence of Vera's home personal protected wifi network and uses her supplied password to gain internet access.
8. Car computer notifies dealership and data pertaining to headlight status is stored in company database. Computer finds that Vera's warranty plan provides automated repairs and orders new headlights.
9. Vera receives a call two weeks later to bring her car to the dealership at her convenience for new headlights.

The sales agent will invite the customer into the sales office. Both users will sit at the desk/workstation, and the sales agent will walk the customer through using the application. The sales agent will start by selecting the model that the customer is interested in. This will provide the salesman and the customer were the specifics about a particular model (gas mileage, expected service, etc…) He will then be presented with a choice of packages/deluxe features. Each package/deluxe feature will be accompanied by a short description of its contents, as well as any additional costs associated with the package. Once selecting the options that the customer desires, the sales agent will be presented with a screen breaking down the cost information relating to the sale. This portion of the application will display the base price, price of any options, sales tax, the cost of the title and other closing costs, as well as the amount of commission the agent will receive. This information will then be passed through the application to the segment where the actual transaction can be completed.

Claims Analysis:
The main trade offs of this scenario deal with keeping the interface as straight forward as possible, yet providing both the salesman and customer with as much relevant information as possible.

The manager in charge of the dealerships inventory will open the application, and go to the feature (tab, screen, etc…) that contains the purchasing options. The manager will then select current inventory to see a listing of the vehicles currently in stock. From here, the manager will look at the sales from the previous month, by vehicle, model, or another criterion. The manager could then either choose to look at sales from another month, or the previous year, quarter etc… Once enough information has been gathered to make a decision, the manager could then return to the purchasing options, and determine what vehicles, and what quantity to purchase. Then the application could either make the transactions for the manager, or they could be passed on to an agent in charge of making purchases for the dealership.

Claims Analysis:
The main requirements of this scenario are relative information regarding sales from previous periods. Such information would no doubt be part of the dealerships accounting practices. The main trade off would be providing the manager with a clear picture of what was currently in stock, matched with an clear image of what was sold during previous periods.

Salesperson

The salesperson will determine the value of a trade-in car and enter the value into the system. The system will already contain the proposed down payment, cost of the new car, monthly payments, etc. If the value of the trade-in exceeds the down payment price, the system will subtract the remaining trade-in credit from the total cost of the car. The system would then recalculate the monthly payments of the car.

Claims Analysis - This scenario requires that the sales person know the value of the trade-in. This information would come from market value and other data that car dealers use in determining trade-in value. This scenario also assumes that the agreed price of the car and financing details are worked out so that when the trade-in value is entered it can modify the existing payment information.

Service Technician

When a manufacturer notifies the dealer of a recall the service department would enter the recall into their system. The entry would keep track of the recall including the part affected, the issue with the part, and the model of car affected by the problem. The service department would then use the system to gather the names of every person who bought that particular model of car and then notify them of the recall. They would then set up an appointment to get their car serviced with the new part.

Claims Analysis: This scenario requires the car manufacturer to supply all the necessary data to the dealer so that they can enter it into their system. It also requires that there be a system in place at the dealer to keep track of customer information including contact information and the model of car they own.

The associate will select the Lender button on the systems interface. The system will provide the associate with a list of banks starting with the banks that the dealership has dealt with most frequently in the past. The associate will select a bank or more than one bank from the list. The system will contact the selected bank or banks with the client's information. The banking system will accept or deny lending money to the client. If a banking system accepts the deal, the dealerships system will terminate any other transactions started with other banking systems. It will also provide output to the associate about the bank that has accepted the client as a borrower and directly connect them if possible. If the banking system denies the deal, the dealerships system will make the link to that bank inactive so the associate does not select it again. It will also provide output to the associate about the banks that have denied the client as a borrower.
Claims Analysis: In order for this scenario to work, there has to be banking systems that support this type of transaction. The tradeoffs for such a system would be fast contact and response time from banking establishments for a limited list of banks that support online dealership transactions. The dealership would be able to quickly find a bank to lend money to the client, but banks that do not support this type of online transactions will have to be excluded from the search. Also, this scenario will need a method for keeping track of which banks have been dealt with the most in the past to provide the associate with the names of the lenders that will most likely lend. A pro of this feature is that it might save time finding a lender by starting with the ones that seem to be most lenient. A con of this feature is that it leaves out the possibility that the client was turned down because of bad credit and not because of a lack of leniency.

The car in this scenario can be used or new, but for the sake of the example we'll use a used car.

The scenario narrative starts with the user picking out first which car he wants, and determining the price of that car. Next, the application determines that the user's total income can not pay for the current car, and gives the option to try another model or attempt to create a payment plan. If the payment plan option is chosen, the user then picks the number of months the payment plan will be for and the application divides up the amount of the car into that many months and asks the user to confirm the plan. If this is accomplished, then the user agrees to pay the amount of dollars each month to keep his car.
The claims analysis for this scenario requires that we know the user's income, the price of the car, and that the application can divide it up accordingly. There shouldn't be any trade offs for doing the feature this way, because it gives the option for just choosing another model if the user does not want to do a payment plan, or it can change the payment plan if the user doesn't like the one set forth by the application. The con of doing the feature like this however is that it's not necessarily the way payment plans work for most products, it's just a simple method of dividing it. An additional scenario that could be added is a bank feature, because the application automatically assumes that the money the person has on them (cash only, in this case) is all that they have. In reality, the person should be able to choose several payment options such as withdrawing more cash for the bank, credit, checks, etc. etc.

Since not all the cars at the dealership are new, and all are not necessarily taken in on a trade in (the nature of trade ins can be random). The dealer will refresh the used inventory by going to special auctions where they can acquire a car for sometimes less than wholesale value. This use case scenario would come into play when one of these said cars was purchased at auction, and now needs to be added to the list of active inventory.

1. User starts the application.
2. User clicks "View Inventory" and then "Add to Inventory"
3. Here the user is presented with a series of input boxes that all pertain to the car just bought.
4. The user would first enter the VIN number of the recently purchased car.
5. Based on the VIN, the program would then attempt to fill in some of the values based on the information found there (place of manufacture, model type, restraint system, engine type, etc.)
6. The user would then fill out the comprehensive form with all the known options the car has, as well as appearance characteristics such as color, condition, etc.
7. Based on that information, the program would then query the blue book site in order too get the wholesale value of the car and insert it into the form.
8. The user would also then verify that all the information pertaining to the actual car was correct, and then begin to add information about the purchase.
9. Fields such as the entity purchased from (name of the auction, in this case) purchase price and initial condition would be entered manually into the form.
10. Based on current policies, a list price will be generated for the car automatically.
11. The user will then click the button to indicate that all the information was entered successfully.
12. The program will automatically update the printed list of inventory, as well as create an entry for the car information on the dealership website.

Exceptions:

If for any reason the program can't update the fields based on the information given (IE car type based on VIN, wholesale value based on options, the user would just have to enter these values manually.

Cars can be problematic, and for a used car to be sold optimally there has to be only minimal technical problems for a potential buyer to consider the investment. Because of this, a new car dealership often has an in-house shop to maintain the active inventory. Check-ups are usually scheduled for each car on the lot at some point (usually when first taken in), however should a seller notice something wrong with the car that needs checked out, a maintenance request should be officially made to the repair staff (of course explained in non-technical terms since no intricate mechanical knowledge is assumed of the seller). This scenario would take place when a seller notices an irregularity that could indicate a problem, thus prompting the seller to inform the maintenance staff about it.

1. User starts the application.
2. User clicks "View Inventory" and selects the car that's experiencing the irregular behavior.
3. Here the user is presented with a series of input boxes that all pertain to the car in question, should they need to verify that they selected the current car.
4. The user will enter information pertaining to the car's troubles, what part of the car it seems to concern, noises it's making, any operational failures witnessed, etc..
5. The user would then verify that all the entered information is correct and click the button to add the car to the maintenance queue.
6. Once added to the queue, the program would then send the data to the maintenance crew's software system that keeps track of each repair job.
7. The priority of the day's jobs is determined by the maintenance system and updated as jobs are completed and new requests are made.
8. Once the check up is complete, a note is made to detail what specific ways the shop tried to identify the problem and what actions were taken. If an additional repair needs to be scheduled, the program will automatically suggest this to the dealership staff.

This will require more than JAVA to build. It will need some sort of database that is easily and often updated. It will cost money to maintain it, and will cost money to keep it accurate. However, it should be a free service to the customer because it will help our image as a good company on the side of the customer. Perhaps we could use XML to create the database. A trade off will be the amount of access to our databases. We cannot give out too much information, for that could be detrimental to our company.

A trade off would be cost. However, we can revamp some of our cost by charging a small fee to those who log onto the kiosk from home. This will also have to be updated and maintained, which will cost money as well. This could be done using JAVA, but the database of information perhaps should be made of XML. We will have to be careful of how much information we give out as well. We don't want to compromise security.

Bob is an employee of Terry's car shack down on route 34 in Tennessee. Bob is in charge of ordering parts for cars that come in and usually have some problem with them. These cars need to have parts ordered for them quickly so that their owners can get them back with the least amount of downtime possible. The normal process for ordering car parts involves first finding out which manufacturer to order from depending on the make/model of the car. Next Bob has to either look through catalogs of the manufactures parts, or call up a representative and tell him what part is needed. This would all change with the help of the application. Data would be loaded/updated in the application regularly concerning all of the parts manufactures sell to them. There would be attributes for make/model of the car that would help employees such as Bob limit the number of search results, and get the part ordered quickly. Once the part is found, and email or fax could automatically be sent to the manufacturer requesting that the part be shipped.

Claims Analysis: A possible trade off of this would be that this system would require lots of data entry, or cooperation with companies for a digital format of their warehouse. This would put more cost into the project, and might not make the part ordering process any faster. Some companies might not have the ability to use email or a fax machine, making this process useless. Part ordering might also be slower this way since it requires the companies to check their email more regularly since they'd be used to simply picking up a phone and filling an order.

Bob is an employee of Terry's car shack down on route 34 in Tennessee. Today, Bob is in charge of giving out a loaner car to a customer. This is because Bob's idea for making the part ordering process streamlined hasn't taken effect yet. Therefore, Bob needs to give out a loaner to the customer while their car is being serviced. Bob asked around for what cars were available. He was told that the black '99 BMW M3 was available and should be out back. Bob went out back and it wasn't there. After lots of fretting, he discovered that an employee who wasn't there that day, gave it out as a loaner the previous day without telling anyone. Instead, the employee wrote it down somewhere. This new loaner portion of the application would solve that. When using a car as a loaner, a simple label or attribute would be added to a car in inventory, to say that it is unavailable and is being used by a customer. The customer number would also be put in the cars attributes, which could then be traced back to the customer's profile if need be. When the car came back, the tag could simply be removed, and the car would no longer be a loaner.

Claims Analysis: This would require all vehicles being put into an inventory database. It would also require that every customer be given a profile in the database with all of their information in it. All employees would also be able to use the system, to check if a car is out or not. Some dealerships might not use this method. For example, they may only have a few cars designated loaner cars, which are not included in the inventory. This wouldn't be too difficult to adapt to though.

After choosing his model, the customer, John goes through the customizations options with the sales person. They are able to easily change the colors, options and interiors. The customer wanted to add a set a expensive rims and tires to his new car but there was not an appropriate selection from the interface. The sales person lets the customer know that this is not a problem. He asks the customer what brand of rims he is looking for. John lets him know the brand and model number along with the kind of tires he wants as well. The sales person is able to add to the customizations area and chooses the option to add new customizations. Since, this kind of addition to their offering is not always simple; there are only a few categories that can be easily added to the inventory. Elements like wheels, extra body items such a spoiler or extensive speaker setups can be added without making any major changes to the car. The sales person chooses to add new rims and is given a list of manufacturers to choose from. He finds the manufacturer and the rims he is looking for. He does the same thing with the wheels. The information regarding the new items is placed within the current customizations and the sales person can add the custom items without having a problem.

Analysis: The biggest issue in this scenario is having the ability to search for the item in a way that doesn't require something like web browser. One option is to have manufacturers subscribe to provide this interface. They would provide pictures and meta-data describing their products so if the customers doesn't know the exact name of the special item, they can still find what they want. Another possibility would be that a customer could simply search online for their product and a standardized catalog file could be downloaded from website that contained serialized item objects that will allow all the calendar items to be easily added to the current customization offerings. Another question that would need to be addressed is how long a customer addition to the catalog would last or be show within the main group of customizations. A special item could stay in the catalog and just be part of the main offering but that could make the catalog too large to go through. A better option could involve a specialized area that extra customizations can be added that are premium upgrades that the customer can choose from. In this scenario, manufacturers could even pay the dealership for prominence in this area so it would be a form of advertising. In any case, it would be better to keep a special area of customizations that has information kept by manufacturers regarding cost and availability.

The sales person gets a call from the police letting him know one of their customer's cars has been stolen. He immediately goes to his computer to find the customer within the customer database. He enters a first and last name to search for the customer. He confirms the customer by using the address with the police. He is then able to look at their purchases and sees the car that was stolen. He is able to take the cars unique id number and find it in the maintenance records. Within the maintenance records he can open special emergency functionality that allows for location of the vehicle using GPS. This area's requires certain information to be entered such as a contact name of a police or other member of the authorities and a case number. The sales person then has access to the car's GPS records and informs the police of the cars whereabouts. An email and fax is also sent to the police so they have a written record of it, both of which are logged for future reference.

Analysis: This assumes that the cars have a "blackbox" functionality and not merely a phone home mechanism. There should be some sort of permission scheme and heavy record keeping as more information is sought out. Salesmen must also be trained in a way that they will remember how to use the system to find the information they are looking for. This is important because they will not be doing it very often and when they do have to find the information, time could be very important. The largest factor seems to be security. Potentially a sales person could track cars as they wish. Entering a case number and fake contact name would need to be tracked and some central objective party would need to be able to verify information that was entered quickly.

A potentially better solution that might be more effective regarding the speed at which the sales person can help and the efficiency of the police department would be if the police held the main finding functionality. The police would call the sales person and they would find the unique car id and that would be all they would need to provide the police in order for the police to track the car. This would take away much of the record keeping for the dealership. They do not want to find stolen cars, they want to make money. It would also lower the accountability of the dealership because they would not be responsible for keeping the records regarding the car location.

Frequently new shipments of cars come into the dealership to be sold. When they are added to the dealership they need to be added to the dealerships inventory list. The inventory list includes the make, model, package, color, vin number and price of each car that is available to be sold. This list is important because it allows an easy way for the sales people to know exactly what cars they have available for the customers to purchase. As soon as the cars are added to the dealership lot, they need to be added to the inventory list so that everyone that should know knows that it is available to be sold. This way they can easily look up through the system and find on the list which cars they can sell to the customer.
Claims Analysis: This requires that there is a way to add the cars to the inventory list. They can be typed in by a person, uploaded from a file and even able to be scanned in. The best method to use depends on the different dealership and how they want to do it. There is no real advantage over any of them, except time, it obviously takes more time to type in every car as apposed to just a simple scan. Another option that they have with an inventory list is a paper list to look up on. The obvious advantage to having it built in the system is that it is much easier and faster to update and also it is much easier to search from a system then to look through a large list on paper.

Then fist thing the customer needs to do is pick the make and model of the car they want to buy. After they know the make and model they need to pick the package that goes with the car, the package includes many different options that can come on the car. After you have the package is the color, certain makes and models and packages only allow you to choose certain colors. The color includes both the color of the actual car and the color of the seats and interior of the car. They will have to look in the system after they know the make, model and package to check which colors are available with the car that they want. From the results they get from the system they can choose which color they want so they can have to perfect car that the customer wants.
Claims Analysis: This requires that the system has built in it all of the colors that are available with each make, model and package. Also it must be able to update the colors available as they change. Other options that could be used instead of having it in the system would be to use the books that you can often find in a dealership. The books usually have the different colors that are available. The books would also have to be updated when the options were updated. The advantage to having it built in the system is that it is easier to update a system, and also it is nicer for the user to be able to see the car they are actually picking out to buy and with it in the system you can make it so they can actually see the car they are creating.

- Customer arrives at dealership
- Customer approaches Salesman
- Salesman collects data regarding Customer and Customer’s vehicle
- Data input into system
- Customer and Salesman negotiate purchase
- Purchase is either made or not made
If made: Car is added to database of vehicles on the lot
If not made: Data is removed
C L A I M S A N A L Y S I S
Requirements:
- Customer has a used vehicle that they intend to sell
- Dealership has interest or need for the customer’s vehicle
- Vehicle is in decent shape
- Vehicle information is known (could have forgotten, been scratched out,
replaced, etc).

- Customer arrives at dealership
- Salesman approaches Customer
- Salesman collects data regarding Customer and Customer’s possible trade-in vehicle
- Data input into system
- Customer and Salesman negotiate purchase
- Purchase is either made or not made
If made: Car is removed from database of vehicles on the lot
If not made: Data is not removed, customer is added to potential customer list
C L A I M S A N A L Y S I S
Requirements:
- Customer wants to purchase a vehicle
- Dealer has a vehicle suiting the customer’s needs
- Price and delivery time/method can be negotiated successfully
- Customer complies with requests for personal information

The actor(s) will use the application to make real-time decisions on where inventory is most in demand, or where it would be most effective to the dealership conglomerate. After the application is in place, it will streamline the process of checking reports and other business data to identify under-producing lots. It will manage the inventory along with some intervention from the actors, much more effectively than the present system. It will be an in-house solution. Although this will be more time consuming, and more involved, it should in turn produce a better result. Some training may be needed by our end users around our organization although since we are developing in-house many of our users' questions or concerns should be easily handled.

Claims Analysis - To support this scenario, we will have to ensure we have the capabilities as far as technology in place at our plant, and at our dealerships. Some end-user training for managers will be required to use the new software application. The cost for training should be far outweighed by benefits to the company in productivity and shipping costs. As some automobiles sit idle on lots that have been underperforming, more shipping costs may be incurred if we want to move inventory to one of our other lots. Pros include the aforementioned ability to more readily see where our car lots stand. Also more importantly it will revolutionize our inventory and distribution setups in place now. Cons to the project, although not major, include end-user training, system, application, integration, and stress testing.

1. User puts in a service request.
2. At time of request the customer is asked if they would like a loaner.
3. A loaner is drawn from the pool in accordance with the users current automobile.
4. Loaner is assigned to the owner and provided when they drop off their car for service.
5. Loaner is reclaimed when the owner returns to pick up their serviced car.

Pros:
• Meets requirements by providing a tracking system for who has loaner cars.
• Provides car to customer during their servicing time.
Cons:
• None, system fulfills requirements.

S c o t t J . R o b e r t s
T u e s d a y , F e b r u a r y 1 , 2 0 0 5
I S T 3 1 1

Ordering a special option on a newly purchased car.

Mechanic, sales person, buyer.

This scenario occurs when a buyer is interested in a extra feature or option not already
offered on a currently existing car or option package.

Provide the buyer with the option they want on their automobile to their specifications.
Give the sales person the ability to price this option in accordance with dealership pricing
and provide that price to the buyer.
Collect and have available the information a mechanic would use to put in the option as
desired by the buyer.

1. Buyer comes in and orders a new car.
2. Buyer asks for a special option on new automobile.
3. Sales person checks and finds that option is not currently available.
4. Sales person calculates price for the option based on buyers specifications on
materials and installation instructions.
5. Information is provided to the mechanic who puts in the option using the buyers instructions.

Pros:
• Provides a structured method of adding features unavailable on normal packages.
Cons: N/A

1. Buyer comes in and orders a new car.
2. Buyer asks for a special option on new automobile.
3. Sales person checks and finds that option is not currently available.
4. Sales person calculates price for the option based on buyers specifications on
materials and installation instructions.
5. Information is provided to the mechanic who puts in the option using the buyers instructions.

Pros:
• Provides a structured method of adding features unavailable on normal packages.
Cons: N/A

1. The car is being driven regularly and is constantly monitoring all systems.
2. The car detects that the ball joint is near it's failing point
3. The car contacts the parts supplier to request a ball joint be sent to the dealer
" Also sends make, model of car and local dealership name and location
4. The parts supplier responds to the car by notifying the car that the part is on back order, and will be sent when available
5. The car then notifies the secretary at the dealership that a part has been ordered, but is on backorder
6. The secretary notifies the customer that a part has been ordered for their car, but that it is back ordered and they will be contacted when the part is shipped to make an appointment
Claims Analysis: The obvious advantage to this scenario is that the part is automatically ordered before it actually fails. Possible disadvantages to this scenario would be that the part still does not ship to the dealership before the part on the car fails or that car incorrectly analyzes the problem and orders the incorrect part.

1. The employee sells a car to the customer for $20,000
2. The secretary in charge of payroll sees that the car has sold and takes notice of who sold it
3. The secretary calculates the 10% commission that the employee has earned ($2,000)
4. The payroll system is modified by the secretary to add $2,000 to the employee's next paycheck.
5. The employee is paid his commission in his next paycheck
Claims Analysis: The advantages of this scenario are that it is simple and that the employee has to do nothing to ensure that he gets his commission. This responsibility is passed on to the secretary. The downfall to this scenario would be if the secretary forgot to add the commission.