Can someone please go back and proof read this article?
The CIO of John Lewis makes no apologies for what he’s about to do. Quite the contrary. I’m meeting Paul Coby at John Lewis's offices in Victoria, a concrete tower fitted with JL’s fittings and furniture that overlooks the jumbled innards of London's £700m upgrade of the Victoria underground line. It's also a tube-strike day. …
Can someone please go back and proof read this article?
What could go wrong?!
Time to buy shares in Debenhams?
Don't worry, they've got a guy from Accenture to project manage it.
Thanks for a good peek into how these things come to life from the top
Not really, they missed the bit about playing golf and the visit to the strip club.
When introducing any system which replaces existing trusted, legacy systems problems are bound to appear.
I think the major issue is incompatible schemas between legacy system 1..N and the destination system wether it be Oracle, OpenERP or SAP. The best example of this is how a name or an address is stored in the source and destination databases. It is very common to see differences in something so basic, so when you start talking about objects with much more complex relationships this problem is amplified several million times! This is why I think most of these rollouts result in delays and pain.
What is wrong with the legacy systems or the *schemas* which support them? Not fit for purpose anymore? Why not integrate them in a non-SQL like way?
incompatible schemas between legacy system 1..N and the destination system
True, which is why the single most important thing is to define the interfaces. Get that right, and everything else falls out OK. All too often this sort of rollout starts at the wrong end, picking systems & software, then trying to work out how to plug them together.
I actually have quite a lot of faith that JL can do this, it's a business that works because it knows its customers, and what they expect. Hopefully that will translate into being on the other side of the deal, but time will tell.
>I think the major issue is incompatible schemas between legacy system 1..N and the destination system wether it be Oracle, OpenERP or SAP.
You are also forgetting the issue of incompatibility between version releases of Enterprise systems, due to new versions adopting new paradigms such as SOA, giving an upgrade many characteristics of a move between vendors. Plus as these systems are long lived, it is usual to look at the business and ask what can we do different and what do the new generation of these products now enable us to do.
Probably a lot of the systems are end of life on old hardware which can't be replaced any more - we still have to support one customer whose ERP system is still running on a DEC Alpha from the mid 90s!
Having worked on dozens of migration projects, moving data from the old systems to the new one isn't that big a problem, you write conversion scripts to take care of 95% of the data, it creates exception reports and a bunch of lusers sit there and punch the correct data into the system and key users take random samples of the data to ensure that it has been transferred properly.
It is a lot of work, but it can work out a lot cheaper than trying to keep legacy systems running - especially if all the developers have now retired or have moved on.
"incompatible schemas between legacy system 1..N and the destination system"
I worked one place were we installed Red Prairie WMS on an Oracle DB, that was to interface with an existing Syspro OMS. Syspro refused to allow Red Prairie to directly interface with their database, so the only way we could get orders out of Syspro into Red Praire was to have Syspro drop a text file of the order into a shared folder and have Red Prairie check every 30 seconds for new text files.
That system did work eventually, but we had 6 months of pain before it was in any way reliable
I think this is the problem when you try and go RDBMS -> RDBMS in any type of project when there are incompatibilities between version or schema. All I was suggesting was a middle step of RDBMS (many) -> XML (or some other open, human readable, extensible format) -> RDBMS (destination).
The middle step being a normalised version and overarching index of the many allowing for easier understanding of existing information sets. It would be easier to import from here than from many RDBMS in one jump. It's also a good idea to talk to API's instead (in my experience) so as to get any application level goodness out with the data (some of the XML/JSON stitching may already be done for you too).
That sort of brings me back to your point about business need. Many of these ERP projects are undertaken with a view of being more efficient. A lot of process surrounds the use of these systems (of course sometimes the system dictates the process), my suggestion is always to understand what wealth of data is available before we even look at process and how it interacts with that data. If the ERP solution doesn't fit the data then your processes likely wont work with the ERP either.
Trying to bend either to the other will result in pain, scope creep and all the other goodness that comes with it. Just look at NHSpfIT and the integration projects that the UK Police Forces undertook. Incompatible schemas abound and normalising to SQL = absolute agony.
Just my $0.02
As I say, if the data is compatible, then all good. And a 95% hit rate is good. All I am saying is that in moving sometimes information is lost.
If there are many systems involved sometimes we just cant copy everything.
I have done many a migration project with high levels of success too, its integration, mixed with migration, that I am worried about. Integration alone is one of the biggest challenges around today, and big data is supposed to solve it.
Again, colour me dubious as to whether JL can deliver it.
All I was suggesting was a middle step of RDBMS (many) -> XML (or some other open, human readable, extensible format) -> RDBMS (destination).
Golden Gate is a product specifically designed to do this and, curiously, it was bought by Oracle a year or so back.
They took on someone from a company that spent 9 years on an ERP rollout and then decided to abandon it to conserve money. To run the ERP introduction.
And JL has a 4 year timescale.
I wish I had somehow found the ability to go after these jobs. On the face of it, success in your previous role doesn't exactly seem to be the highest priority.
<<They took on someone from a company that spent 9 years on an ERP rollout and then decided to abandon it to conserve money. To run the ERP introduction.>>
FWIW the ERP at BA was SAP. Which I presume didn't put SAP in a good place when the guy in charge of deciding which to buy at JL was the guy previously in charge at BA :-)
And, presumably having 9 years experience of how not to do it, he must have a "dont do that" list.
At my last place we had a 20 year old software system that had first been used in a timber merchants, had then been customised for the spares department of a car dealership round the corner, then we used it to manage warehouse &nationwide branch stocks for a distribution sompany.
Everything ran well, but slowly, with maybe a requirement for 15-20% additional monthly stocks to cover for poor forecasting in the software.
Then we were bought by a US Globocorp who decided we absolutely had to use their SAP software, which was built for a manufacturing division of the corporation, not for warehousing & distribution, but blind to our objections it was shoehorned into place, and on 1st Jan 2011 the switch was flicked and we started to run SAP.
We had to pretty much right-off January that year, as customers left us in droves in favour of suppliers who could process orders and deliver goods.
Customers who stayed found that once goods arrived, if they were lucky in the same week as they ordered, rather than the normal next day, they didn't see any invoices for months, which was nice for a while, but a bugger when 6 months worth arrived all at once.
Over all I'd say that SAP was a total failure, and the business still hasn't recovered
I would say the migration was a failure. If they had used the logistics modules and got warehousing and logistics specialists in to do the conversion, it would probably gone a lot smoother.
SAP has square pegs for square holes and round pegs for round holes. If some idiot decides to bash a square peg in a round hole, that isn't the tools fault... And yes, SAP has a lot of faults.
hah they will build on ATG. Fooligans. Should have chosen hybris.
The excuses given are not the root causes. And I have direct experience on a number of EMEA scale projects (thus anonymity), at least two of which had multi-year delays and 100M plus costs recovery exercises. I'm sitting not too far from such a project as we speak.
The primary problem is excessive scale, coupling and complexity of the solution. Any "all in one box" solution will do this. Risk is highly non-linear on scale. Underspecification/over-customisation is a matter of hindsight, and so a completely useless statement. Especially as Oracle (or any other system like this) do nothing of value out of the box. They all require massive customisation masquerading as configuration. They do not isolate these customisations. They build them in. Thus the horrific underlying data models e.g. anonymous columns like 'customColumn1, customColumnName1, customColumnType1' all over the place.
Even when they are functionally working, they tend to be very inefficient and brittle, which means extremely poor performance (though that sells monster hardware) and a tendency to fail in odd ways. Certainly the system becomes instant legacy as no-one can afford to change it.
The solution is to insist on incremental delivery, isolation of customised elements, and heavy testing from the start, as that forces the correct behaviours and manages risk with a fast-fail approach. I don't know if big-ERP can do this, I've never seen it.
"The solution is to insist on incremental delivery, isolation of customised elements, and heavy testing from the start, as that forces the correct behaviours and manages risk with a fast-fail approach. I don't know if big-ERP can do this, I've never seen it."
Ah, the voice of reason speaks... Have an upvote for pointing out the bleeding obvious... The fact that suit clad exec types still insist on delivering huge monolithic projects big bang style suggests that these guys really are incapable of learning from failure.
I suspect 2017 was a typo, they really meant 2107, :-). Well, you would hope that tey are not going to be daft enough to try a big bang switch over. Unfortunately we don't know JL's current architecture, if it's all that old. If they already have a Service Bus moving stuff around, it gets easier, and lowers the risk, in fact you can use your service bus to do the transformations from old to new, and even parallel run for a while.
4 years really is a bit optimistic, unless that's when the first bit comes online.
Time to go long in teary endings I think.
>like when builders filled the Victoria control room with concrete - the result was nothing worse than a > storm of angry Tweets, incredulous headlines, and red faces for those in charge.
You forgot to mention an entire Tube line knocked out of commission and the presumably very expensive replacement of a whole room of switching equipment.
The failed ERP implementation at the Quest division which resulted in the share price diving resulting in dropping outside the FTST 100 for the first time in its history. First the Quest CEO and then the ICI CEO (yes CEO not CIO) fell on their swords to placate the city - and ultimately (many think) this led to demise / sale / break-up of ICI.
Oft quoted as #1 in all time IT failures!
The management thinks its buying a tried and tested application which just needs a few configuration tweaks.
In reality these "configuration" tweaks involve a number of interacting configuration files using various syntax-es to effectively implement a 4GL.
The trouble is its a really c***p 4GL. Which is difficult to program, a nightmare to debug with an unbelievably slow and clunky interpreter.
Any modern software development environment will beat these "packages" hands down on all fronts: cost, time to market, reliability and resource consumption and run times.
You might just be able to convince your management that programming has moved on from COBOL and punched cards, but, its pretty hard for a mere techie to compete with the round of golf followed by a bottle of fizz at the dogy night club of your choice.
Limiting customization, sorting out the work flow properly, picking the software before the servers or the OS etc.
As others have noted dumping the various data schemas of each system (if it's even possible for some of them), merging them and weeding out the (inevitable) junk data before they populate the master (Oracle) system are all good moves.
But it's still a huge task and a lot could go wrong.
I'll wish him luck, as I'm sure they will need it.
Biting the hand that feeds IT © 1998–2017