Tomato Energy

[johnb80]

If things were really that simple I don't think I would have had a job in IT for 36 years.

Did you work for British Gas

You surely must agree, they had peoples customers details on the database, they must have in order to take their supply? That being the case they must also have had on the same database the end reading of the previous supplier? Its hardly taxing for any IT bod to export the above data and import it into another database, it's as basic as breathing which babies manage from birth.

I would imagine the data in the Tomato system is a complete mess as they couldn't even bill customers correctly.

The majority of customers were billed correctly, there was a number that were not and that's widely publicised and acknowledged. The ones that were correctly invoiced again would be easy to see on the database and should be readily transferred to whoever they want as their supplier. It's mainly smoke and mirrors from British Gas who are milking it for all it's worth.

 

[tsedge]

Octopus Fan Club, Octopus COSY Heatpumps and Tariffs, Electroverse discounted EV charging, Octopus Mini get almost live data from your smart meter onto your PC / Octopus APP, Intelligent Octopus GO and more.

Yes. A lot of these were available several years ago.

I suppose they have reached a plateau, a bit like smartphones there's only so much you can innovate in a particular field, then you just have to refine and improve rather than innovate.

Perhaps. Although not in customer service, in my experience.

 

[GaryMG4]

40+ years in IT, including British Gas (late 1970s). Data migration is never that easy unless both companies use the same software and even then it can be full of pitfalls. It all depends on the structure of the data and what are the entry points as well as how well documented it was and whether people are available to write the extract programs in the old company, reformat the data with the appropriate key data for the new company and load programs.
When I worked for what became BG each region had its own system running on its choice of hardware with little or no compatibility of data despite it just being customer data.

 

[Gomev]

Did you work for British Gas

You surely must agree, they had peoples customers details on the database, they must have in order to take their supply? That being the case they must also have had on the same database the end reading of the previous supplier? Its hardly taxing for any IT bod to export the above data and import it into another database, it's as basic as breathing which babies manage from birth.

They may have their details on a database but it is not the BG database. What sort of database is it? What details do they have and are they the same details? Are they in the same format? Are they complete? New processes have to be written to do conversions and the new data has to be integrated into the adopting systems. Just a few of the things that have to be worked out.
I have been involved in several large scale data migrations over the years including The Lloyds takeover of HBOS and these things are not as straightforward as the unknowing eye may think they are.

 

[tsedge]

Even when the job is simple technically, it often isn't simple due to bureaucracy. It is quite likely these days that you'd have to write a bunch of documentation and have a ton of meetings and involve lawyers, just to be able to import from one customer database to another, for compliance purposes.

Factor in outsourced IT and procurement processes and you are talking many months in most big organisations.

Of course this is absolutely absurd. But unfortunately, the absurd is also normal.

 

[mg4mc]

40+ IT years consulting for big corporates and government for me too, and I have to agree it is never simple, even when the data is all available.

I came across a bank keeping vital bits of customer information in an Excel spreadsheet on a office desktop. Another that was running a custom written undocumented program on an office desktop, with the source code lost long ago and the original "developer" (someone else in the office, not IT) had also long left the company. That program handled the records of multi-mullions of customer money! The IT department had no idea it even existed.

 

[Kenp1]

They may have their details on a database but it is not the BG database. What sort of database is it? What details do they have and are they the same details? Are they in the same format? Are they complete? New processes have to be written to do conversions and the new data has to be integrated into the adopting systems. Just a few of the things that have to be worked out.
I have been involved in several large scale data migrations over the years including The Lloyds takeover of HBOS and these things are not as straightforward as the unknowing eye may think they are.

Exactly, and that's if the data is in good order. we are dealing with Tomato energy here.

 

[salty]

I've no idea about IT at all. But reading these replys. Is it all, not made far more complicated, than it really needs to be. Which to be fair, stands for most things.

 

[Gadget Geek]

Exactly, and that's if the data is in good order. we are dealing with Tomato energy here.

Does that mean it's a data salad?

 

[GaryMG4]

I've no idea about IT at all. But reading these replys. Is it all, not made far more complicated, than it really needs to be. Which to be fair, stands for most things.

I think the issue is that what seems to be really simple, address/person/meter may be the case for the majority of customers, can be very complicated when add in properties becoming HMOs, tower blocks with communal heating, sheltered homes, meter changes, address changes, person changes, bank account changes and the associate history of these. Then you have that a lot of these system have had layer upon layer of changes applied to them and probably should have been rewritten years ago, you end up with one unholy mess.
When you switch supplier, you enter your details into their system, they check you, they can get a reading from your meter. If they are happy they can start taking money from you and the jobs a good'un. Historical data may then be requested if its required or possibly in the case of a simple switch the existing supplier is required to keep it, not sure what happens if a company folds.
To extract that data from another system and use it to populate yours is a different matter. I don't know if there's a requirement to extract the history of accounts from a defunct company, but that would make it much harder.

 

[salty]

I think the issue is that what seems to be really simple, address/person/meter may be the case for the majority of customers, can be very complicated when add in properties becoming HMOs, tower blocks with communal heating, sheltered homes, meter changes, address changes, person changes, bank account changes and the associate history of these. Then you have that a lot of these system have had layer upon layer of changes applied to them and probably should have been rewritten years ago, you end up with one unholy mess.
When you switch supplier, you enter your details into their system, they check you, they can get a reading from your meter. If they are happy they can start taking money from you and the jobs a good'un. Historical data may then be requested if its required or possibly in the case of a simple switch the existing supplier is required to keep it, not sure what happens if a company folds.
To extract that data from another system and use it to populate yours is a different matter. I don't know if there's a requirement to extract the history of accounts from a defunct company, but that would make it much harder.

WOW! Mind Blowing!

 

[GaryMG4]

WOW! Mind Blowing!

I used to think that a mortgage was a simple entity until I worked on one. The system was written in the 1980s and still running when I retired 10 years ago, and just last year an old colleague contacted me to see if I was interested in going back to work on it!

 

[johnb80]

It seems to me like some of you guys are emulating plumbers, breathing in through your teeth when looking at a job like this and then explaining how expensive it's going to be.
In an earlier life I was Network Manager for a technology college, we merged with two other secondary schools. Each establishment was handling data in different ways with different programs. I accept the numbers were smaller (3000) put the complexity of the data was much greater. Each location the data was extracted into CSV files, post processed into the format we needed to import into our SQL database. I had 1 day on each site and then 3 days on our new site and the job was done. I dont buy into all the complexity outlined above. HMO's is nothing more than MPAN number associated with a person at an address, the same address would appear for additional MPAN's and people, no big deal here.
Maybe I'm blinkered but a 'can do' attitude is needed as opposed to 'can't do' for everyones sake.

 

[tsedge]

It isn't a technical problem - it's bureaucratic and you were blessed with being able to get on with it.

Many people in larger organisations are actively prevented from this and fired if they persist.

 

[johnb80]

It isn't a technical problem - it's bureaucratic and you were blessed with being able to get on with it.

Many people in larger organisations are actively prevented from this and fired if they persist.

I agree, it really should not be allowed to be this way though.

 

[GaryMG4]

It seems to me like some of you guys are emulating plumbers, breathing in through your teeth when looking at a job like this and then explaining how expensive it's going to be.
In an earlier life I was Network Manager for a technology college, we merged with two other secondary schools. Each establishment was handling data in different ways with different programs. I accept the numbers were smaller (3000) put the complexity of the data was much greater. Each location the data was extracted into CSV files, post processed into the format we needed to import into our SQL database. I had 1 day on each site and then 3 days on our new site and the job was done. I dont buy into all the complexity outlined above. HMO's is nothing more than MPAN number associated with a person at an address, the same address would appear for additional MPAN's and people, no big deal here.
Maybe I'm blinkered but a 'can do' attitude is needed as opposed to 'can't do' for everyones sake.

My experience is mainframe based where there are not CSV extracts that you can just run, you can write a program easily enough to do that but it's extracting the right data from what are usually complex structures that is the problem. A house that becomes an HMO started as a simple mpan/address/person then people come and go, meters may change, people may be associated with other addresses in the database either consecutively or concurrently. Then the house is split up and you potentially have multiple mpans 'live' etc.etc.
SQL is great for writing extract processes because the way the data is linked but hierarchical databases don't work that way.
All that said I would expect that these days these new energy companies would probably use an off the shelf package to manage billing, although if it's on SAP there would still be a monstrous bill to transfer the data.

 

[johnb80]

My experience is mainframe based where there are not CSV extracts that you can just run, you can write a program easily enough to do that but it's extracting the right data from what are usually complex structures that is the problem. A house that becomes an HMO started as a simple mpan/address/person then people come and go, meters may change, people may be associated with other addresses in the database either consecutively or concurrently. Then the house is split up and you potentially have multiple mpans 'live' etc.etc.
SQL is great for writing extract processes because the way the data is linked but hierarchical databases don't work that way.
All that said I would expect that these days these new energy companies would probably use an off the shelf package to manage billing, although if it's on SAP there would still be a monstrous bill to transfer the data.

I bow to your greater experience but I still feel BG will milk it for all it's worth.

 

[GaryMG4]

I bow to your greater experience but I still feel BG will milk it for all it's worth.

I totally agree, when I worked for what became BG it was like working for local government, as bad as that was I bet it is way worse now. I don't know what the SOLR process is but I bet it involves a brown envelope somewhere.

 

[tsedge]

I totally agree, when I worked for what became BG it was like working for local government, as bad as that was I bet it is way worse now. I don't know what the SOLR process is but I bet it involves a brown envelope somewhere.

It probably looks like:

Executives: announce take over and customer base expansion, pop the champagne and off to the golf course and sponsored dinner, not bad for 15 minutes work, let's toast the increased share price.

Back-office: months of toil to implement fighting the system, no support or investment, just extra hours. No thanks, just pressure to do it yesterday.

Front-office: increased workload for no extra pay, double the complaints, no incentive to bother.

 

[GaryMG4]

Ah yes the carefully crafted 'bonus scheme' to ensure the execs stay on the gravy train.