The Wonderful World of Cable & Wireless Software Developers
A Quote From the Briefcase Guide To e-Business Strategy, by C&W
" 'When you stand on a dog's tail the head barks. If the dog was five miles long, the head would still bark. Thats how the telephone Internet works, only there's no dog' With apologies to Alexander Graham Bell"
Well, thats just great isn't it? Tens of years, millions of man-hours, innovation after innovation, and its turns out we've just re-invented the fucking phone.
A little tale of hilarity. This is a wonderful story that someone told me, that nicely illustrates the sheer lunacy of large corporations (I'd be a naive fool if I thought it was just C&W where this happened). Anyway:
A new web-based billing tool has been recently introduced and now customers on the right billing platform can get their bills via email. Its quick, its paperless and its very very popular with account managers and customers alike. Basically, its A Good Thing (tm). Now for the funny part - we have a large team (100+ people) of credit controllers, to chase customers for payment of the bill. So clearly, this team needs to know the status of the bill and the account before they call the customer. The web-based billing tool allows them to log in and view the current status of all of our customers, when they recieved the bill, any problems that occured, the email address the bill was delivered to etc etc. Fantastic, you would have thought - they can log in, and see all this, they don't need to call account managers or billing teams or anything. Except ...
... the manager of credit control has banned the team from using the web-based billing tool. No-one's really sure why, but the upshot of this is that credit control now have to call the billing analysts or billing support (neither of which they're officially allowed to do by the way) to find out when the bill was delivered, and what its current status is. This creates more work for the credit controllers, more work for the analysts and more work for the support teams. And all of these problems have already been solved, its just the team aren't allowed to use the solution
Sometimes real life actually is a Dilbert cartoon
More Wiki. I've been using it to store all my bugs and change requests for the Complex Rating project. Comment from boss: "its an absolute godsend for seeing all your stuff". The complex rating users are using it as well, to see what changes I've done so far, and whilst I've not yet got them adding stuff to it (that's stage 2!), I think they are enjoying getting almost real time updates on what I'm doing. Its a good thing, and we're going to upgrade it to one of our production servers soon
Wiki. Put all my email weekly reports in it and gave the page to the BRAHMS project manager instead of another email with this week's report on. He thought it was great.
So there are people out there who are open to possibilites and not in fear of the organisation.
Number of applications within C&W. Currently, still, at around the 1,500 mark apparently. This is causing us as a company to try and reduce this number (a good idea really - 1,500 is far too many). But it got me thinking as to how its going to affect my role.
Our team traditionally wrote small, quick ASP 3.0 applications to solve a particular business problem. Because they were specific, they were usually very good at what they did, and some got used very widely. The problem is that with this drive to reduce systems, we're moving now into supporting and developing "enterprise-wide" solutions such as SAP, Siebel and various content management systems. And if we're not doing this right now, its definitely the way we're heading. No biggie, you might think, but I've been thinking about this, and I don't think using these sorts of systems actually provides the business with solutions to their problems.
The problem with SAP or Siebel or whatever is that they're square pegs trying to be forced into round holes. A system which is generic enough to do "anything" is never going to match what the business users require, because their specifics cannot be accounted for. The great thing with our previous approach was that the business got exactly what they wanted to deal with the problem. And it was lightweight, web-based scripting, so if half-way through they realised it needed to work in another way, or another thing needed to be added, then we could easily adapt to what they wanted. We tended to follow a rough Extreme Programming methodology, and I thought it worked quite well. Certainly, my two most successful applications were written in this manner. Each solve one specific problem within the business. Job done.
But with these new "enterprise systems", we can't solve their problems - we start instead adapting their problems to fit in with our system. Now, I'm not sure exactly what our role should be within the business, but it strikes me that it should be to solve business users' problems. To make their jobs easier, quicker and more effective, thereby saving and making the company money. Whilst I accept that support for all these applications is difficult, its surely no more difficult than supporting several bastardised SAP modules, which don't accurately solve the business problem.
So going forward, what should be our plan? I'm not sure I know, but I can't approve of trying to force everything through systems that won't properly fix the problem. However, I'm also aware that having thousands of tiny bespoke systems isn't great either. Particularly in ASP 3.0, a soon-to-be-dead programming language. Maybe the answer lies down a middle path, something like a well-designed object-oriented system (Java or C# I guess). My thinking is that a well designed system would allow us to firstly meet and solve the exact problem the business has (we're writing it after all, so it should at least do that). Secondly, we could then build on this, and increase the scope and scalability of the application to try and include other similar problems that we come across. For example, a lot of the applications I used to build were basically fault tracking systems. They all had specifics that would prevent them fitting nicely with Siebel or anything like that, but they all had key modules that would have been the same. A well designed, carefully managed object-oriented application should have been able to scale upwards to include new functionality, written by any one of us. Perhaps I'm a little naive in my thinking, and its not possible in practice to do this, but this is currently my best idea. Any thoughts?
Workflow Analysis. It's even got a beautiful name.
Last week we are asked to fill out a voluminous excel spreadsheet about EVERY task we received/performed in the week with such useful information as, 'Authority Required to Perform the Task' and, 'The Average Time that Any Single Person Would Take To Carry Out the Task'. Leaving alone the fact that the latter is not really a sentence that makes any sense it was arduous and basically pointless. And I had to wonder, who the hell is going to read these?
Of course the guy up the tree who asked for them can't read them because he'd have to read a big Excel spreadsheet for every person in the tree under him. With an average branching factor of about 8 locally on our organisation chart that makes about 512 (83) for the earliest guy it could be for (I don't know who its for but I know its not for my boss or his boss), obviously the numbers grow exponentially for every step up from there (although in other parts of the organisation both vertically and horizontally branching factor is typically a lot lower than 8).
Anyway you don't have to worry about Francesco Ciao (CEO) having to read more than 12,000 spreadsheets because it turns out that's not how it's going to work. In fact the boss is going to have to go through the 10 or so he gets from his direct report and amalgamate them (and so on up the tree? I don't know.) So this whole thing was just an exercise in getting raw material for our department's über-spreadsheet -- even more pointless than I first imagined. I'm glad mine was sarky, random and incomplete now.
