Looking for info on abandoned conversion to SQL
Curt
convert away from an MV solution to SQL and spent like 12 million
dollars trying and then abandoned it. Can someone point me to that story
please. Thanks
Tony Gravagno
Reynolds and Reynolds spent about 67 million.
Oxford Health spent millions, and the IT issues directly led to their
company value plummeting. (Hmm, one or two T's? Oh well.)
I believe CUBS had an expensive and unsuccessful migration effort.
No links off the top of my head. :)
HTH
T
Lee Bacall
Here's a start...
http://goliath.ecnext.com/coms2/gi_0199-4996257/Reynolds-tries-to-retain-dealerships.html
http://www.tmcnet.com/usubmit/2005/jul/1165654.htm
There was probably another 20+ million written off by Reynolds and Reynolds
in addition to the 67
million according to some rumors I've heard.
--
Lee Bacall
binarystar.com
NuWiki.com - Collaborative Information Management
"Curt" <Nob...@Nowhere.com> wrote in message
news:MPG.213b400e5...@news-server.tampabay.rr.com...
Ross Ferris
> Curt,
> Here's a start...http://goliath.ecnext.com/coms2/gi_0199-4996257/Reynolds-tries-to-ret...
>
> http://www.tmcnet.com/usubmit/2005/jul/1165654.htm
>
> There was probably another 20+ million written off by Reynolds and Reynolds
> in addition to the 67
> million according to some rumors I've heard.
>
> --
> Lee Bacall
> binarystar.com
> NuWiki.com - Collaborative Information Management
>
> "Curt" <Nob...@Nowhere.com> wrote in message
>
> news:MPG.213b400e5...@news-server.tampabay.rr.com...
>
>
>
> > Somewhere I read a story about a major software house that was trying to
> > convert away from an MV solution to SQL and spent like 12 million
> > dollars trying and then abandoned it. Can someone point me to that story
>
> - Show quoted text -
closer to 30 if you read the fine print
Curt
looking more for a MV style White Paper describing the conversion
failuer was due to the fact that SQL could/can not do what a MV database
can and that's the reason they abandoned the convertion.
Ross Ferris
That IS the reason why the R&R conversion failed - though you are not
going to find a "white paper" about it (too much blood letting)
If you follow the blood trail you will see that there were a LOT of
casualties from this failure, from the CEO down, and ultimately I
believe it is one of the reasons that lead to a "minnow" being able to
swallow the "shark" that was R&R (ie: they have been taken over,
though the new company trades under the R&R name, as it had more
"value"/"recognition" than their own.
You also will not find any white papers detailing the importance that
Microsoft put on the conversion process (I believe that Steve Bulmer
was a frequent visitor) in terms of SQL and .NOT - no-one wants the
harsh light of close inspection to shine on the dark episode.
Even more murky would be stories of banks and other financial
institutions trying to convert from multi-valued technology to more
"mainstream" solutions - both packaged solutions AND rewrites. "The
Markets" would get "jittery" about HUNDREDS OF MILLIONS OF DOLLARS
being written off in failed conversions (people like to think that
banks & financial institutions know what they are doing - but at the
end of the day they are still just "people")
I know all of this sounds very cloak&dagger urban mythical, and
yet ...
Unfortunately I don't think you are going to find any "official" white-
papers on this subject. I'm sure TonyG would be willing to put
something together for you for a price, but there may be other
interested parties to share this - but the resultant manifesto isn't
likely to carry the same weight as a report by a "name" like Gartner
Somebody
Not precisely what you're asking for, but given the response to date,
perhaps you ought to do some research on Oxford Health Plan.
--
Allen Egerton
aegerton at pobox dot com
Tony Gravagno
I'd maintain we would have seen the same result no matter what the
technology if the same people and mentalities were involved. This is
easily arguable so my notes below shouldn't be considered as making a
case for the point but just observations and opinions.
There's something fundamentally wrong when someone says they want to
convert to a different technology as a business strategy. This seems
to be what happened at Oxford and R&R. Change is a tactical approach
to a problem that lies between what you have now and stated
objectives.
If the technology is deficient then the business position is justified
but I can't recall anyone saying in any of these messes that MV
technology is deficient, only (without a lot of explanation)
undesirable. It's the old and new thing - new must be better, but we
all know that's incorrect thinking for many reasons. No, this had
nothing to do with failings or superiority of MV.
It had everything to do with mismanagement and a series of bad
decisions by people who let their "change is the goal" mentality
override the idea that people mistakenly assume to be ever-present,
that "change for the better is the goal". Unfortunately change for
the sake of change is only the goal for people who profit from change,
and unfortunately these are the people who wind up selling a lot of
snake oil and bridges.
It doesn't seem (no facts here) like the decision makers at Oxford and
R&R really considered their options with the existing technology, and
didn't really evaluate what they had in terms of how well it really
supported their existing business. This is another sign of
mismanagement. If they had done this they would be looking at the
same options many people here have: maybe putting a new front-end on
the existing rules, maybe changing databases, maybe doing better
marketing. I dare say few companies as successful as Oxford and R&R
could evaluate their current application and decide it was time to
replace all of the rules, UI, and databases all in one shot.
Now switching from what they left to what they went to: I don't
believe the issue had anything to do with .NET either. Some
statistics say only about 20% of projects finish on time and on
budget, regardless of technology. Many never finish at all, and the
rest struggle somewhere in the love triangle between the time, cost,
and quality. [ Pick two. ;) ] This isn't a technology-specific
statistic, it's industry-wide. It's tough to squeeze enough blame
from those statistics to put on any specific technology, unless you
say about 80% of developers use one technology, or inherently faulty
technology, and either of those propositions would be very difficult
to support.
I think the real blame lies with the way "we" as an industry do
things. We pride ourselves as an industry with a "seat of the pants"
demeanor and then we criticize software that reflects the approach.
We like the idea of agile programming and self-sufficent, independent
thinking developers - especially the renegades and hackers. If we
were architects designing buildings, would we appreciate such lack of
discipline? If we were construction workers could we get away with
such sloppiness? In that industry they have inspectors checking
projects at every step of the way and the project stops if it isn't in
compliance with standards. And you know what? The construction
industry doesn't have near a 20% failure rate, let alone a 20% success
rate. In our industry we forge ahead at any cost, and we can choose
from many standards or none. Everyone supports this - developers, IT
managers, and company management. Is it any wonder that this process
fails 80% of the time, and at a cost of so many millions of dollars?
I know I frequently waste my keystrokes talking about testing
software, insisting that your vendors follow good QA procedures,
pressing management for change, taking responsibility for quality, and
about how tools are irrelevant. But between Oxford Health, and
Reynolds and Reynolds alone, I think I have about 150 million reasons
to justify such statements. This industry needs to grow up on the
supply side and set realistic expectations on the demand side. Stop
blaming the technology and start focusing on the processes and
decisions that supposedly allow the technologies to make the
difference between success and failure. Everyone needs to insist on
quality from developers and vendors, or we will continue to employ
programmers who can't code and struggle with a project failure rate
that costs us more than the GNP of most countries.
Oops, did it again...
TG@ remove.this.pleaseNebula-RnD.com
GlenB
"Tony Gravagno" <address.i...@removethis.com.invalid> wrote in
message news:58qpd3pv2coes4pt9...@4ax.com...
>I think people have the inclination to blame technology for this and
> I'd maintain we would have seen the same result no matter what the
> technology if the same people and mentalities were involved. This is
> easily arguable so my notes below shouldn't be considered as making a
> case for the point but just observations and opinions.
>
> There's something fundamentally wrong when someone says they want to
> convert to a different technology as a business strategy. This seems
> to be what happened at Oxford and R&R. Change is a tactical approach
> to a problem that lies between what you have now and stated
> objectives.
Well, unfortunately I have to disagree here on one point. When you are in
the business of corporate real estate, it's a lot like flipping houses.
There's a lot of money being made in flipping companies and merging
entities. Changing business strategy for the sole purpose of a sale is the
main goal and that normally means changing the fundamental technology under
all or some of the firms being bought. I'm not saying this is what normally
happens, but I'm sure it happens more often than you give credit to. These
scenarios have nothing to do with tactical business change or reaching some
sort of business objective, but they do require major technical changes. The
end results are major in either a good or bad way.
Glen
Tony Gravagno
>Curt wrote:
>> Somewhere I read a story about a major software house that was trying to
>> convert away from an MV solution to SQL and spent like 12 million
>> dollars trying and then abandoned it. Can someone point me to that story
>> please. Thanks
>
>Not precisely what you're asking for, but given the response to date,
>perhaps you ought to do some research on Oxford Health Plan.
Already did the research for someone else, might as well post it
here....
TG@ removethisNebula-RnD.com
Nebula RESEARCH 'n Development
========================================================
http://www.computerworld.com/printthis/2000/0,4814,53014,00.html
High-Flying HMO Modernizes, Crashes
Oxford Health Plans Inc. was the Netscape of health maintenance
organizations. It seemed to burst from nowhere, captivate customers
and force competitors to change the way they operated.
Then Oxford decided to modernize its information technology.
It was 1995 and Oxford's old turnkey, Pick-based billing and
membership tracking system would no longer do. A complete overhaul,
using more modern Unix technology, is what the company wanted - and
fast.
The project included many custom applications that ran with Oracle
databases and other software. But key was a claims processing system,
dubbed Pulse, that Oxford's internal IT people built with Oracle
tools.
Trouble hit the Trumbull, Conn.-based HMO almost as soon as the
rollout started in late 1996. Customers suddenly got claims laden with
errors - when they got claims at all. The company paid bills it
shouldn't have and denied claims it should have paid.
All the late and inaccurate paperwork caused New York state to fine
Oxford $3 million for violating insurance laws.
Overall, the new software overestimated revenue by $392 million for
1997 and 1998 while also underestimating medical costs. That awful
combination led to Oxford's $291 million loss in 1997.
Angry doctors and patients abandoned the HMO. Membership dropped 20%
from 1997 to 1999, partly because of the systems problems and partly
because Oxford withdrew from four of the seven states it did business
in.
Ultimately, top executives left, and Oxford hired a new head of
operations - Kevin Hickey, then an operations manager at Aetna Inc. -
to help with an IT cleanup already under way.
Hickey immediately faced down the billing mess, which "wasn't just an
inconvenience. This was a survival issue," he said in an interview.
First, he shelved Pulse and returned to the old Pick application.
Pulse was never fully integrated with the Oracle software, he said.
Cambridge Technology Partners Inc. and Diamond Technology Partners
Inc. came in for quick-hit assignments to help fix claims processing.
Oxford also shut down its advanced technology unit. Studying
artificial intelligence software for possible future systems was
frivolous now that "emergency" IT problems threatened to incapacitate
the HMO, Hickey explained.
Oxford hired Computer Sciences Corp. to create a plan for outsourcing
its entire IT operation.
But in 1998, a new CEO swept in and swept away that idea, along with
most remaining legacy executives. Hickey, too, was replaced after just
a year at the company.
Today, Oxford is smaller and smarter. It wrote off $5 million for
hardware and software in 1998. Late last year, system fixes even took
precedence over customer acquisition, according to documents filed
with the Securities and Exchange Commission (SEC).
Oxford has since completed major systems fixes and put in place new
quality assurance and other testing programs. But SEC documents warn
that unexpected sales calculations could still turn up.
========================
According to:Top 10 Corporate Information Technology Failures
http://www.computerworld.com/computerworld/records/images/pdf/44NfailChart.pdf
Oxford Health Plans Inc. PROJECT: New billing and claims-processing
system based on Unix Internationaland Oracle Corp. databases
WHAT HAPPENED?A 1996 migration to a new set of applications for health
maintenance organizations operations resulted in hordes of doctors and
patients angry about payment delays and errors. The system also
underestimated medical costs and overestimated income. As a result,
high-flying Oxford posted its first-ever quarterly loss in November
1997: $78 million. All told, Oxford overestimated revenues by $173.5
million in 1997 and $218.2 million in 1998. New York state fines the
company $3 million for violating insurance laws. Oxford replaced large
parts of the home-grown system with off-the-shelf modules.
========================
The Wall Street Journal
December 10, 1997
HOW NEW TECHNOLOGY BECAME A SERIOUS PROBLEM FOR OXFORD
by Ron Winslow and George Anders
Staff Reporters of THE WALL STREET JOURNAL
The annals of business are filled with Frankenstein
stories -- -- tales of technology run amok.
But the computer-system horrors at Oxford Health Plans, Inc.,
take the genre to a new level.
Only two months ago, Oxford was basking in Wall Street
admiration for its blazing growth. This week, the health-
maintenance organization disclosed that it will post a loss of
$120 million or more for the current quarter, on top of
a surprise third-quarter loss of $78.2 million -- its first
loss since going public in 1991.
Oxford's shares closed Wednesday at $17.1250, down $2.9375, or
15%, on the Nasdaq Stock Market. Wednesday's closing stock
price was down 75% from its level just before the company first
revealed its troubles in late October.
How did disaster strike so quickly? As Oxford's business was
faltering, it never saw the warning signs. One reason was a
long list of troubles with a computer system that went on-line
last year: how it was designed, how it was installed and how
Oxford executives managed it.
The computer problems left Oxford unable to send out monthly
bills to thousands of customer accounts and rendered it
incapable of tracking payments to hundreds of doctors and
hospitals.
In less than a year, uncollected payments from customers
tripled to more than $400 million, while the sum Oxford owed
care-givers swelled more than 50%, to more than $650 million.
For any company grappling with new information systems, Oxford
offers a lesson in how not to proceed -- and in how hotshot
technology can create even worse problems than the ones it was
intended to solve.
PLAN FOR GROWTH: Oxford's dazzling growth was both its
distinction and its undoing. The HMO began planning the new
computer system in 1993, when it had just 217,000 members. The
system didn't rev up until October of last year, by which time
the HMO's membership had swelled to about 1.5 million. Thus,
the new system was already outdated and outmanned.
Problems popped up immediately. Processing a new member sign-up
was supposed to take just six seconds but instead took 15
minutes (a lag that later was fixed). And even as Oxford's
backoffice infrastructure was overwhelmed, the company continued
signing up hordes of new customers that its system couldn't
handle -- more than half a million new members in the past year.
"If you drive a train at 150 miles an hour without good tracks,
you derail," says David Friend, a global director at Watson
Wyatt & Co., Bethesda, Md.
TAKE BABY STEPS, NOT BIG ONES: Build your new information
highway from exit to exit, not coast to coast. Oxford locked
into a design for the entire system in late 1993, which made it
difficult to adjust to subsequent technological improvements as
the project moved forward. Moreover, it tried to convert the
bulk of its membership-billing database in one fell swoop --
-- some 43,000 accounts covering 1.9 million members.
Computer specialists say that such a sweeping conversion is far
too difficult; companies should switch just the records for,
say, one county or one business group at a time. "Put all of
your small customers on the new system and see how it goes,"
suggests John Salek, of REL Consultancy in Purchase, N.Y.
Oxford's all-or-nothing approach misfired, making it all the
harder to do further repairs without creating even bigger snags.
Stephen F. Wiggins, Oxford's founder and chairman, acknowledges
that a more incremental conversion would have been preferable.
BEWARE OF "DIRTY DATA": Oxford's old software was riddled with
seemingly innocuous errors in member records that turned out to
cause enormous problems in the new system. For instance, the old
VMark uniVerse database tolerated errors that let a patient's
Social Security number be entered in a box reserved for date of
treatment. But the new database, from Oracle Corp., spit out
such inconsistencies and refused to process the data until they
were corrected.
The new software is "very unforgiving. If you don't get it
right, you don't get it in," says Seth Lefferts, an
information-systems manager at Oxford.
So when the program detected a single mistake in, for example,
a 1,000-member account, it kicked out the entire group --
-- delaying billing and claims processing for all 1,000 members.
When technicians fixed the error and re-entered the account, the
new software would spit it out yet again when it detected the
next mistake in a member's record. And so on.
The volume of individual mistakes "wasn't huge," says Paul
Ricker, Oxford's vice president of information systems. "But the
effect was rather extreme."
Oracle says it continues to work with Oxford and the HMO's
other vendors to get the system working optimally.
DON'T LOSE TRACK OF RECEIVABLES: Once the Oracle software began
balking at the old system's erroneous data, Oxford was forced to
stop billing some customers for months at a time and often sent
flawed invoices to many others. The HMO had no backup system,
not even a platoon of pencil-wielding clerks, to fill the gap.
Yet the company, following standard accounting practices,
continued booking the unbilled income as quarterly revenue.
Then came the rub: When Oxford started to catch up on
long-overdue accounts, contacting customers for the first time
in months, many refused to pay and others said they had quit the
HMO long ago. Hence, the company had to write off $111 million
in uncollectable bills and admit it had overestimated its
membership by 30,000.
Mr. Wiggins now says he should have "hired an army of temps,
put them at a bank of IBM Selectrics, and had them type out
bills. That would have made sure that everybody that owed us
money had a slip of paper saying so."
DON'T FORGET THE LITTLE GUY: When the data overload swamped
Oxford, the company focused first on trying to catch up with
its biggest customer accounts and major providers. That seemed
to make sense: Why not place top priority on fixing the biggest
sources of your revenue and costs?
The risk of such logic, as Oxford now concedes, is that small
customers are the ones most likely to disappear when service
gets bad. They don't yelp; they simply stop paying and sign up
elsewhere. As it turned out, the vast majority of the $111
million hit for uncollectable accounts came from small groups
and individuals.
DON'T IGNORE PAYABLES: Oxford's failure to process claims on
time angered many of the star physicians and renowned teaching
hospitals whose participation was a key selling point of the
HMO. Some providers say they still haven't been paid for care
they delivered well over six months ago. A big doctor group at
Columbia University's respected College of Physicians and
Surgeons was owed $16 million at one point; New York Cornell
Medical Center was owed as much as $17 million earlier this
year.
This meant more than mere embarrassment. Oxford lost track of
its actual medical costs -- critical information for reacting to
surprise problems, setting reserves and projecting future
liabilities. That last item, known as costs "incurred but not
reported," or IBNR, is especially crucial in the insurance
business. Oxford executives "weren't getting the statistics and
data they needed to make accurate estimates on the IBNR," says
Rob Levy of consulting firm William M. Mercer & Co. "So they
were winging it. That's a disaster to any business."
Mr. Wiggins says that the company followed accepted practices
in estimating such costs and that it thought it was making
conservative projections. However, one particularly disturbing
trend went undetected: a sharp 14% rise in Medicare costs at a
time when Oxford's vaunted marketing machine was recruiting new
elderly patients at a rate of more than 100 a day.
FORTIFY RANKS OF 'PROPELLER HEADS': Hire a data chief who knows
how to manage a giant conversion. Many of Oxford's information-
system managers cut their teeth when the company was tiny, but a
wholly different pacing and organization are needed when a
project involves 150 programmers instead of a dozen.
Intermediate goals need to be spelled out precisely, and
multiple projects need to be coordinated.
Oxford dealt with data crises by piling more people onto the
trouble areas, but it didn't seem capable of anticipating the
next snafu.
Mr. Wiggins says his company is now looking for seasoned
managers for information systems, medical management and other
crucial areas of the company.
Copyright 1997 Dow Jones & Company, Inc.
All Rights Reserved
========================
The New York Times
December 10, 1997
OXFORD HEALTH TO SHOW A LOSS FOR THE YEAR
by Reed Abelson
NEW YORK -- Oxford Health Plans, a managed care company that
enjoyed running advertisements questioning why competitors were not
matching its consumer-friendly brand of health care, admitted
Tuesday that it had sorely underestimated the cost of that care.
Under pressure from the New York State Department of Insurance,
Oxford confirmed fears Tuesday that it had misjudged its costs,
with the announcement that it would take a substantial charge to
fourth-quarter earnings and show a loss for the year. It described
the insurance department's review of the company as "continuing."
The full size of the charge was not disclosed. But at least $164
million of it will go just to bolster reserves for medical claims
submitted on behalf of New York policyholders, the core of its
business. The company, based in Norwalk, Conn., said it will set
aside an additional amount to cover customers outside of New York.
Largely because of the charges, the company said it is estimating a
$120 million net loss in the fourth quarter and a loss for the
calendar year. Final numbers will not be available until February,
the company said.
"We make this addition to our reserves to remove any doubts about
our stability," Stephen Wiggins, Oxford's chairman and founder,
told Bloomberg.
In the announcement, Wiggins said the company was "cooperating
fully" with insurance regulators. "In addition, we believe these
steps will enhance our prospects for returning to profitability,"
he said.
Investors, who had an inkling that it might be a bad week for the
once-high flyer, will not have a chance to fully digest the news
till Wednesday. Trading in the company's stock was halted in late
afternoon before the announcement was made and had not resumed by
the time the market had closed. The stock last traded at $20.0625,
down $1.3125 from Monday's close and light years away from the $89
peak it hit in July.
For Oxford's investors, the last few months have been painful to
watch. The company has been late in processing hundreds of millions
of dollars it owes doctors and hospitals, blaming its new computer
system.
It stunned investors in late October, when it warned that its
third-quarter earnings would disappoint, and the stock lost more
than $3 billion in a day.
About a week later, actual third-quarter results came in worse than
expected. That same week, the company disclosed a plan to improve
management, expand its board and hire some computer consultants, at
the urging of New York's insurance department.
While some Wall Street analysts had been predicting yet another
shoe to drop, some were surprised by its size, which will be even
larger than the $94 million, after-tax charge taken for the third
quarter.
"I didn't expect the shoe was going to be this heavy," said Gary
Frazier, a managing director at Bear Stearns who had been among
those waiting for another charge.
Until Tuesday, analysts had been predicting that Oxford would earn
$12.7 million, or 16 cents a share, for 1997, and the company had
felt comfortable with estimates that it might earn at least $1.30
next year. In a hastily convened conference call with analysts
Tuesday, the company was no longer entertaining projections for
1998.
Kenneth Abramowitz, an analyst with Sanford C. Bernstein, described
the loss as "obviously disappointing, but not shocking." He noted
the industry's history of having trouble estimating its reserves.
--
Copyright 1997 The New York Times Company
============================================
Tony Gravagno
>When you are in
>the business of corporate real estate, it's a lot like flipping houses.
>There's a lot of money being made in flipping companies and merging
>entities. Changing business strategy for the sole purpose of a sale is the
>main goal...
We actually do agree - that's exactly what this part was about:
GlenB
"Tony Gravagno" <address.i...@removethis.com.invalid> wrote in
Oh. What can I say. I'm not thinking or reading 100% lately. Caffeine has
lost its effect now too.
Glen
Ross Ferris
> "Tony Gravagno" <address.is.in.po...@removethis.com.invalid> wrote in
> messagenews:2nprd31me600n9jli...@4ax.com...
Maybe this will work .... http://www.audiosparx.com/sa/archive/People/Baby-sounds/Baby-crying-03/135731