Back to the Data Model
The Requirements have been defined by the User as follows :-
Date: Wed, 2 Jun 2004 21:08:12 +0200
From: Guy Harris
[ Add to Address Book | Block Address | Report as Spam ]
To:
Subject: RE: Car Parts E-commerce Database?
Hi Barry!
Apologise for the late reply! In the middle of wedding preparations ...
hectic!
Catalogue: yes, the point would be to provide access to the inventories of
several suppliers, so that the customer could search and compare on price,
quality, delivery times, etc. Shopping basket would be essential. The
optimal solution, to break into the commercial market would be true B2B
e-commerce portal functionality, which would allow ordering from car
maintenance / workshop software packages. Currently, these packages in the
US do provide a certain amount of this functionality, but it is not as
integrated as it should be, due to the incompatibility of cataloguing
information.
I have some experience of good parts ordering e-commerce packages, as I
worked for SpecTec, which provide computerised PMS (Planned Maintenance
Systems) to the shipping industry, where a high degree of reliability and
economy is required, with difficult last-mile-delivery issues, so I know a
reasonable amount about the standards required.
The AAIA site is here: http://www.apaa.org/ There is A LOT of very useful
information available at and through this site. The Americans are way ahead
of the Europeans (what a surprise) in the uptake of IS in this industry
segment.
On the other stuff we talked about, I've enclosed a few slides on the PER
(Political, Emotional, Rational) indices used by Gemini Consulting. I've
had to take out customer-specific information, but this stuff is still
proprietary, so it is for your eyes only; you seem like the kind of bloke I
can trust with this kind of thing! There are also two very useful toolkits,
some of which are 'ho-hum' standard consulting stuff, and some of which are
really good.
The PER scale stuff is only a tool. Personally, I use it in projects in a
slightly different way to that described by the Gemini; you will find
slides that describe the key people in any given environment:
- Decision maker
- Authoriser
- Technical Authority
- Key Influencer / Gatekeeper
- etc.
These 'roles' are dependent on the kind of project. I try to keep these
roles down to 4, although CGEY now uses more. Although these roles in
themselves can be categorised according to the PER:
- Decision maker - Political
- Authoriser - Political / Rational
- Technical Authority - Rational
- Key Influencer / Gatekeeper - Emotional
... I prefer to set up a grid whereby I use my in-house guide / coach to
establish how each of the people scores on these three elements:
MD Decision Maker - P60% - E10% - R30%
BoardSec Authoriser - P80% - E0% - R20%
TD Technical Authority - P20% - E20% - R60%
SysUser KI - P10% - E60% - R30%
This gives you a useful starting point on how to handle people and who
requires what information. A lot of this seems like common sense, and in
small projects, with one consultant, common sense is often enough. However,
as soon as you have more than one person working on a team (which is most of
the time in IT-heavy projects) then perceptions tend to vary. For example,
one team member who has to face off with the MD may not have cottoned onto
the fact that the MD doesn't give a stuff about how people feel about the
Change Processes that the project requires further down and will destroy the
team's credibility by appealing to the MD's 'better nature' rather than
providing him with political / technical ammunition to force the Board to
swallow the required medicine of a short-term reduction in turnover during
the reengineering process.
In any case, it is very useful for a Team Leader to be able to coordinate
the information that is given outwards from the project team, to ensure
consistency. These kind of tools help towards that goal.
I'd be happy to give you more on this kind of thing, if you feel it's
useful!
Talk soon.
Best regards
Guy
A Database to be built and support an e-commerce web application.
This would include a Search facility so that people could look for the Parts that they were interested in.
The data model would contain :-
Component � part hierarchies,
Fields such as weight, condition, mileage of donor vehicle, etc.
A. Things of Interest :-
A.1 Addresses
A.2 Customers
A.3 Car Parts
A.4 Suppliers
A.5 Vehicles
Organizations include :-
Suppliers.
People include :-
Customers, Suppliers.
Transactions include :-
Purchase and Payments.
C. How are these Things of Interest related ?
C.1 A Person can be related to many Organizations.
C.2 An Organization can be related to many People.
Barry Williams
15th. May 2004
Principal Consultant
Database Answers