Thursday, 1 July 2010

How not to fix a problem

Lets say you have a nice fault reporting system using XML.

And there is a problem - when notes are added by the reporter the people working on the fault can't see them. It means you get these strange "talking to a brick wall" exchanges where we reject a fault and add lots of notes but get replies which make no sense. The poor fault engineers have no idea why it is rejected and cannot see the detailed notes. It drives both sides round the bend.

Any sane person faced with this would fix the problem - make the notes visible. Simples.

But no! Big company answer is to change the system so you can no longer send notes - you now get an error telling you the notes have not been added!!!

OK, so you have to work around - send the fault back and email someone to tell them to add the notes manually. Ironically this works as the notes are in fact added, but it ties up people doing it and is rather silly.

Oh, and when you did the fix you also stopped the initial fault report notes coming through and also the "reason" for rejecting a fault coming through. We think that worked before.

So lets fix that - again sane answer is fix the actual problem, but no. The big company decides fix it by not allowing you to even reject faults any more.

So again, emailing a separate department not only to add notes but to clear the fault.

Dilbert is so true on the workings of large companies.

2 comments:

  1. repeat after me ....

    BT aren't interested in serving a customer
    the customer is the dill they dupe into paying for xyz which has a name but cant be printed

    ReplyDelete