imagine a company ..

imagine a company that builds and sells computers. they ~~sell~~ want to sell 1000 computers a day. if they didn't have a website with a configurator, what would it be like?

they'd have to have a hundred people sitting by the phone, listening to the customer, answering questions about what's available, how much it costs, what combinations don't work and why.

they'd have hot ears, said my nine year old.

then, when one of these 100 finished taking an order, they'd pick up the phone and call the factory, and tell them what the customer wanted built.

or they'd write it down, and have it delivered by messenger.

i kid you not. i have seen a company where this was happening.

in fact, they'd need another 100 people -- or maybe 50, because both sides speak the same argot, hopefully -- on the factory side to talk to the hundred phone sales people.

i was at a company once where they had already informationtechnologised this setup -- in two different software systems that didn't speak to one another.

so they did have an order-taking system at the front end, and production control system at the back, but guess how they connected the two up? right, sneaker net, plus typo-net.

the front end end people printed out the orders, these were brought -- and i mean that in the most 18th century sense of the word -- to the back end people, who proceeded to type the stuff, in a different format of course, into their back end system.

ask yourself how many errors got inserted into this paper trail along the way. triple your estimate. flash psychic say: you are still way, way, way too optimistic. dude.

this is were some problems creep in:

- how do you ensure the first 100 people do actually know what the second 50 know?

if they told the customer something wrong, and we are lucky, the factory person will notice, and they'll have to call the customer back, and start from scratch.

if we are not lucky, it'll go off to the shop floor, and some time later the sound of a big expensive machine come to a grinding halt shalt be heard for miles around.

- how do you ensure they actually communicate it effectively to the customer, day in and day out?

if you think, now, that these questions are contrived or rhetorical, stop.

products can get very complex, and they change constantly. keeping different groups within a company in synch on what the product actually is, and is not, is a major, major issue in practice.

so, anyway. the motivation for using a configurator is to Do The Right Thing in these situations:

offer the customer

a good interface that cleary shows

what options are available for the product,

- never offering choices that can't or won't be built

- automatically setting choices that are mandatory (that rules say must be selected given the other choices)

and how much they cost,

and possibly even how long a given set of options -- i.e., the chosen configuration -- would take to deliver (this is called ATP in suit-speak, available to promise)

& a one-click, no-hassle way of actually ordering the desired configuration

offer the supplier full integration:

an automagic recepticle for that one-click, no-hassle way of actually ordering the desired configuration

automagic branch-offs into the supplier's product lifecycle managment

- taking and storing the order

- ensuring that it it can be built -- automagically, because we only allowed the customer to specify buildable configurations in the first place

- ensuring that it is built to spec -- automagically, because the data communicated to production is the same, the very self-same & identical, data the customer constructed by using the front end configurator

- ensuring that the front end knows what the back end knows

in fact, there is not front end and no back end anymore. they are now different views on the same, identical core data:
the product model

the product model knows how to present itself to the customer

the product model knows how to present an instance of itself -- a configuration -- to the production people

- and the costing people

- and the materials managment people

- and the control freaks

so the theme of the day is, The Product Model Knows

and who's going to help get one of these product models? esommer.net!

so, doesn't this make so much sense as to be stupid to go through the trouble of actually writing it down?

if not, let me know -- i'm still trying to hone this to the point where i can explain it to my grandmother.

if so, then why is it not being done so much?

have an answer for that, too. because it's hard. very hard, and expensive, and it likely to cut through a great deal of intra-company responsibility thickets. but the thing is, it's mainly a one-time, bootstrap kind of effort that pays out almost immediately if done correctly.

Simple to maintain over time: it can be extremely hard, and expensive, to set up, but it must be maintainable in-house once the suits are gone.

(originally from http://esommer.net/blog/archive/2003/03/index.html#20030307, which may provide some context if it didn't make sense by itself)