Hi All,
LTV is exceedingly difficult to estimate across a whole range of industries...no question.....but what is the 'prize'?
Ultimately, vastly greater profitability by engaging with clients more likely to be profitable...one bank I worked with was able to be twice as profitable as their competitors on a number of customers and asset base basis.....double!! (I can't claim to be the difference by the way...I just happened to pass along a good idea I invented...)
It is amazing how much difference it makes by jettisoning unprofitable customers...
Tom Peters Challenges us to ask 'How many customers have we fired today?'
Companies should fire more 'tire kicker', 'low margin' customers and provide differentiated service levels for customers who deliver higher margins.
Send all the 'tire kickers' to be serviced by companies who focus on low cost to support a telephone call...inevitably to India.
I was 'walking the pier' with a good friend of mine last weekend in Dublin....we were talking about all this 'stuff'.
I told him:
'Peter, I would be pleased to put my business with companies who provided excellent service and charged me for it.....but all the companies I deal with provide crap service!!! In all of Europe it is hard to find companies who actually care about their customers.'
Of all the companies I deal with, only one of them is 'helpful'....I am happy to 'throw money at them' just to be helpful....!!
Best Regards
Peter
-----Original Message-----
From: SQLUSA via dw-select [
Sent: 17 August 2006 04:23
To: pete...
Subject: RE: [dw-select] How to best estimate the number of ELT jobs needed in a project
>To be fair they were a Life Insurance Company and revenue and profit
are
>exceedingly hard to measure in those places....
>
The same is true for online gambling companies. LTV (Life Time Value) of
a
customer is pretty difficult to estimate, especially for a new gaming
syste
m. Sports betting LTV is more predictable.
Kalman Toth, DB, DW & BI Architect
URL:
World
>From: " pete... via dw-select" <dw-select@Groups.ITtoolbox.com>
>Sent: Aug 16, 2006 5:19 PM
>To: SQLUSA <technicalsqlusa@earthlink.net>
>Subject: RE: [dw-select] How to best estimate the number of ELT jobs
neede
d in a project
>Hi Nic,
>I can beat that one...
>I once had a client who, after gathering together the best minds in the
>company many a time for a period of a year could not decide what $1 of
>revenue really meant....
>Best Regards
>Peter
>-----Original Message-----
>From: Nic Harvard via dw-select [
>Sent: 14 August 2006 11:21
>To: pete...
>needed in a project
>OLTP systems deliver functionality within a new context.
>So the barrier is change management, education, and training.
>(E.g: "yesterday '3' meant '$3', tomorrow it will mean
>'3_local_currency" -
>as a trivial example)
>DW's need to get the views and beliefs (right or wrong) about what the
>data
>elements *MEANT* historically, in which systems, to which users.
>Once you got that, the transforms and ETL bit is a techie issue - you
>just
>have to code/map it.
>I have spent almost 40 hours (on and off) with a group of no more than
8
>key
>users, from only two departments, trying to agree what "sales" meant
>(!!)
>Once done, it to a developer around 3 hours to write, test, regress and
>assure the required 20 or so mapplets.
>Now translate that to an EDW with several hundred users, ranging from
>CxO /
>SVP level, down to analysts, over maybe many SBU's and functions.
>Gets ugly..
>Nic Harvard
>From: SQLUSA via dw-select [
>Sent: Friday, August 11, 2006 10:27 PM
>To: Harvard, Nicolaus
>Subject: Re: [dw-select] How to best estimate the number of ELT jobs
>needed
>in a project
>> Very important note though: the time to actually build these jobs is
>utterly
>> trivial when compared with the time to agree the context, business
>definiti
>> on and meaning, rules etc. That is what kills 80% of projects.
>Nic - details please.
>How about an OLTP project? Why isn't it killed at the same high rate?
Or
>it
>is?
>Kalman Toth, Database, Data Warehouse & BI Architect
>URL:
>Practices
>----- Original Message -----
>From: "Nic Harvard via dw-select" <dw-select@Groups.ITtoolbox.com>
>To: "SQLUSA" <technicalsqlusa@earthlink.net>
>Sent: Friday, August 11, 2006 11:36 AM
>>
>> Number of data elements (table:fields)
>> *
>> ([number of historic business contexts]+[translator/mapping tables])
>> Is a good start. If you're lucky, you can divide the above number by
>the
>> number of relevant source tables, and only do one ETL job per table
>per
>> system. (Of course, you still need to do the relevant
>> transform/clean/aggregate per field, which is why I think of each as
>"job
>> ")
>> on
>> and meaning, rules etc. That is what kills 80% of projects.
>> Nic Harvard
>> -----Original Message-----
>> From: David_Brisbane via dw-select
>[
>> Sent: Wednesday, August 09, 2006 1:14 AM
>> To: Harvard, Nicolaus
>> Subject: [dw-select] How to best estimate the number of ELT jobs
>needed in
>a
>> project
>> I have discovered a few estimation tools that compute the amount of
>ETL
>> effort required to deliver a DW project based on the number of
simple,
>> medium and complex ETL jobs that have to be designed, developed and
>> tested.
>> However, I have not found an estimation tool, paper, or rational for
>how
>> to estimate the number of simple, medium and complex ETL jobs in the
>> first place.
>> I was wondering what methods the people in this community typically
>use?
>> Is it based on the number of tables in the DW or based on something
>> else?