Setting up a business Essay Example for Free

Setting up a business Essay Introduction Tods tyres is a company which deals in fitting new sets of tyres to fleets of cars. Tod has to record the details of each car, and send the owners a letter when the cars are due for new tyres. Previously, this could all be done manually, but the growth of the company has meant there is a need for a more efficient system. The existing system is all manual, with Tod or one of his clerks keeping a book containing all the details of cars he maintains, as well as the addresses of his clients. He writes out a letter on a basic word processor on his home computer, and changes the address manually. A new design is needed to make the company more efficient, as Well as increase the capacity for adding new customers in the future. Ideally, the system should be very easy to use, as Tod himself is not very experienced with computers. Because Tod holds the details of his customers on this computer, it must be protected from unauthorised use. A good way to do this would be to protect either the entire computer or the database with a password Specification of solution The Solution, for it to be a complete success, must be capable of each of the following: 1. It must store each record in a way that it is easily visible, easily compared with similar records, and easily retrievable with a query 2. It has to be protectable with at least a password, to satisfy the requirements of the data protection act. 3. The database itself must be easy and intuitive to use for its users, and must be a stable and reliable program. 4. The data itself must be transferable to a common storage medium, like floppy disks or CDRs, for cheap and compact back-up storage. However, these disks must be kept safe from unauthorised access, as per the data protection acts. 5. The programme must update the file in real-time; e. g. a change to the database at one workstation will register at the others with immediately after. The solution, as a secondary objective, should be relatively cheap and easy to upgrade in the future. For instance, a few spare RAM sockets would be useful, as data flow increases and extra memory is needed. The program developed to solve the problem should be widely compatible with most widely available platforms, so that the records can be viewed on other computers, in case the office computer is inaccessible, so that backups can be used. It is recommended the whole database be backup as often as possible, but every week or so would be sufficient, depending on the rate of data transfer in and out of the database. The new system should also be easy to use and straightforward to operate. This will mean that Tod and the clerks can use the system quickly and easily, and so reduce operating time and shop stress. Therefore, I think a windows 98 system (stable, basic, and needs a modest spec to run) with Access XP or 2000, whichever is cheaper. After a fitting of a tyre is completed, the quantity of the appropriate tyre available is reduced by the appropriate amount, and the last tyre date of the car data table is updated manually. This way we can easily find how many tyres of each type are in stock, and how long each car has before it is due in again. The solution program must be: 1. Easy and intuitive to use 2. Able to operate on a low spec The firm will want to keep the spending on hardware to a minimum. 3. Able to search for records, for quick access to data. 4. Protected by a password + anti-virus software, under the data protection act. 5. Easy to backup: i. Must support floppy disk backups ii. Must be a commonly used format (e. g. must be able to be read on most machines, etc. ) Feasibility study Although the computerised process would save time in the long term, there is the short-term cost of buying and setting up the computer equipment. However, I think this would save the company time and money in the middle/ long term. To keep the firm efficient whilst it expands, computerising the administration system would free up staff time, making the workforce bigger than it needs to be. This computerised system means the firm will not need to employ a secretary or any other manual filing system, until the database grows too large to manage. This is all part of the process of mechanisation, and cant be helped. If the firm expands too much without checks being made on efficiency, a diseconomy of scale may well result. This would increase running costs, and decrease profits over time. In all, I think the middle- and long-term benefits far outweigh the short-term costs. There is the possible problem of Tod having to personally fill in all the records himself, since he is the only one with the knowledge of who gets the 5% discount or not. The system would result in a much better reminder system, so that more customers will potentially come back to the firm. The only cost would be the cost of the computer equipment, and the cost in time and money of maintenance in the future. The system runs basic hardware and common software, so technicians able to deal with the system would be common. Why use a database? Databases are very practical methods of data storage, because they provide a very simple, uncluttered GUI for a novice user, but can prove very powerful tools for searching and the like for the advanced user. This is why I decided not to use Excel; the interface is comparatively complex in relation, and may confuse the first-time user. Also, databases allow for many more types of record to be shown there is the option to publish the results in an individual record card, which Excel cannot do. Excel is not totally useless for this project; Tod might be able to make use of its graph-making and accounting features, especially as the company grows and needs to be more in control of its productivity and expenses. Hardware Specification Required At the moment, we are going for a very cheap, reliable system, because of the low system requirements of the programs involved. Following the recent leaps in processor speed, and the advent of new technology like the Pentium 4 series, you can purchase new Pentium 3/ duron processors at very low prices. Because of rapid increases in new CPU speeds, we can now set up a very competent system very cheaply. RAM has also become cheaper, which is just as well, because were going to need 128 Meg in each machine in order to maintain a good level of stability, and safely clear the minimum requirements of Windows 98. A 128 Meg RAM chip costs about i 20. We wont bother with DDR Ram; SDR is cheaper and has no noticeable downgrade in performance, as well as the added cost of getting a compatible motherboard, since the technology is relatively recent. I would recommend buying the parts from a registered computer fair, rather than a large- scale retailer, because larger shops are only interested in i 700 home systems and upwards. The older parts used in these systems enable a complete computer to be built for under i 180. CPU: 450-mhz p3 Less than i 25 if used. Hard Disk: 10-gig ATA 133 Surpassed, but cheap and plenty of room for OS and database. RAM: 128 MEG, SDR. Motherboard: Old ABIT models have legendary reliability. About i 50 used. Case: Minitower case. Theyre cheap (ish) and save space on the desk. About i 15. Graphics card: Cheap, low-end versions cost about i 10, or some motherboards carry one on-board. For this sort of application, we really have no choice but to use a database/ spreadsheet program, because they have a better capacity to index and sort data by name, price etc. more easily than having each record on paper, for instance, or even entering the information in a word-processing application. For example, its a lot easier to add a record in-between two others, because a Database program like Access will automatically update other fields, like the Autonumber field, for example. Its also a lot easier to move the records down in the first place, because the database program has many spreadsheet features. The screenshot here shows the option clearly visible. However, performing the same operation in word can send records all over the page. Entity Relationship diagram This illustrates the relationships the solution will need to take into account. The relationships should ideally be linked in real time, so that changing the record in one table will automatically update the fields in another table. Database Notation: ACCOUNTS (Customer account ID, No.of cars name, company address ,company postcode, 5% discount? ) CARS (Customer account ID, Car ID, Model name, Reg number, Last tyres date) CURRENT JOBS (Customer account ID, Car ID, Date in, reg number) TYRE STOCKS(Tyre ID, Number left in stock) Data dictionary Car Database Fieldname Type Description Customer ID Number duplicates OK Car ID Autonumber Duplicates not OK Comments Text (256 characters) Allows other car details to be recorded, e. g. year of production Reg Number Text Only accepts new numbers ( ) Tyre type needed Text (P1000 OR P3000 OR P5000 OR P7000). Indicates which tyre type best suits the car Last change date Date/time Should display the date in days, months and years. Example Accounts Database Fieldname Type Description Customer ID Autonumber Must be indexed, duplicates not OK No. of cars Number Preferably looks up quantity of cars listed 5% Discount? Boolean Tick box Customer Name Text Normal Text Customer Address Text Normal Text Customer Postcode Text Normal Text Example Current jobs Database Fieldname Type Description Customer Account Number Number Identifies customer (lookup from customer accounts, duplicates OK) Car ID Number Duplicates not OK.. Date in Date Reg number Text ( ) Lookup from car table, by car ID Tyre type needed Number Must be below that in the tyre stocks field for that particular tyre in the tyre stock table Example Tyre stocks Database Fieldname Type Description Tyre Type ID Autonumber Gives a primary key for lookup functions Manufacturer ID Text P1000, P3000 P5000, P7000 Tyre price Currency Cost of tyre to buy Number of tyres in stock Number Gives tyre stock Reports Invoice report Fieldname Type Description Customer ID Autonumber Lookup from Accounts table. Car ID Number Lookup from car table 5% discount Boolean Lookup from accounts Sub total Currency formula 1 VAT/ other tax formula 2 Total Currency formula 3 Cars due in report Fieldname Type Description Customer ID Number Lookup from Accounts table Car ID Number Lookup from car table Car Reg # Text string   Lookup from car table Last tyres date Date Lookup from car table Queries Name Function qryaccount Inputting an account number allows the user to access that customers history qryRegistration. Inputting a valid registration number will reveal the owner and other details qrytyrestocks Allows the user to enter a tyre type and view details of how many tyres of that type are left in stock, and how much they are sold to the customer for. qryCarsduein Allows the user to enter a date and view details of the cars that are due for new tyres Validation rules. To ensure the smooth running of the database, it is important to ensure that errors are found and corrected by the user. To ensure these errors are detected, the following measures have been implemented. Format checks all dates input into the system must be in the format DD/MM/YYYY. For instance, a date like 02/06/2002 will be accepted, but anything not in this format or a letter will create the following error message The short date criteria means data is only accepted in numerical A similar set of rules apply for the car registration numbers. They must be in the new style European format, or this error box will appear: Range check A date from before 1950 is very unlikely to be valid. Since Tods tyres hasnt been around very long, a rule preventing dates from before 1953 being put in is useful. Query Design. Firstly, we need a query to highlight cars which are due in for new tyres, i. e. those which the last tyres date was over a year ago. To do this, we can set up the following query. Standard letter query Fields displayed = Car ID, Customer address, customer postcode, date due in Criteria for Date due in date() + 365 This query will produce a list of the cars which are due in for new tyres; this list can then be used to set up a mail merger, so that the customers address, postcode and the registration of the car will be inserted into the letter. An example of this letter is attached at the back of the report. An example of this could be given by a car with a last tyres date of 02/05/2001. This would be picked up by the query, and entered into the mail merge letter with the owners address and postcode. Dataflow diagram Level one diagram Why use a database? Databases are very practical methods of data storage, because they provide a very simple, uncluttered GUI for a novice user, but can prove very powerful tools for searching and the like for the advanced user. This is why I decided not to use Excel; the interface is comparatively complex in relation, and may confuse the first-time user. Also, databases allow for many more types of record to be shown there is the option to publish the results in an individual record card, which Excel cannot do. Test plan Test number Description Expected result 1 Security password Only accepts correct password 2 Relationships cross referencing Extending a field in one table will show relevant contents of other tables. 3 Relationships Real-time updating Updating one table will update the other tables correctly 4 Query Searching for Customers by name will provide the desired result 5. Invoice lookup The mail merges produce the correct customer details, car registration number etc 6 Invoice Calculation 5% discount is applied correctly, totals are added up correctly and end result is formatted correctly (e. g. as a currency) 7 Car registration Validation rules An incorrect format for a car registration will be picked up 8 Date validation rules An impossible date for a new car (e. g. 1953) would be picked up on. 9 Switchboard functionality Changing the amount of tyres left in the switchboard should update the tyre stocks table. 10 Tyre usage rule The current jobs table wont accept more than 5 tyres being fitted at a time. Testing report 1. On opening the database, the user is asked for a password before the database will open. If the password specified is incorrect, the database will refuse access: 2. Extending an entry in the accounts field can display data for the cars owned by a particular account holder: 3. Updating the last tyres date in the table above has updated the data in the original table, so that one table can be used to change or update another: 4. Searching for Cross, the name of one of the customers, brings up the file for Mr. Cross account. 5. The mail merge correctly inserts Elliot Cross Name, Address and Postcode successfully into the table 6. The mail merge also inserts a final paragraph, dependant on whether the account holder is entitled to a 5% discount. 6. An invalid car registration number is picked up by the validation rule 7. The validation rule stops the user from inputting a very suspectable value, a date before 1953 for a new car 8. Using the switchboard to increase tyre stocks (e. g.following a delivery of fresh tyres) automatically updates the tyre stocks table. The table is updated successfully, which suggests the switchboard has allowed for real-time editing of the database 9. Because of the following validation rules in the tyres used field: Putting in a value greater than 5 or lower than 1 produces the following error message: Evaluation The system has left Tod with a powerful database of stock and account details. This has completely computerised the system, making it more efficient and productive. This has meant addresses are accessible at the touch of a button, saving time. The added increase in staff morale has made the firm more efficient, as happier workers are more productive. This increased efficiency will save the firm money in the short run. This means extra profit for the firm. However, improvements could still be made in the future, including these points: 1. Connecting the system to the internet, allowing Tod to simply email reminders to interested clients. This would make the entire system more reliable and efficient, since labour costs are reduced by eliminating the need for a clerk to put the letters in envelopes, etc. It also reduces the possibility for human error, as long as the details are correctly input in the first place. 2. Upgrading the computer to make the system more stable. More RAM in future upgrades may prove particularly useful. Also, over time the company may wish to transfer the details into a bespoke system. This would maximise processing power, since RAM is being dedicated only to the basic functions of the database, and not unnecessary functions such as a windows shell. Also, it would reduce the possibility of time being wasted by employees on unrelated applications, like games on the computer. Tom ONeill Page 2 07/05/07.