I talked to a friend a few weeks ago about why his former company didn't succeed with their IT solutions, even with a huge workforce and a big budget. He said that some other rival company did so much better with less budget and people, ergo they have to be doing something better. The rival company is about a quarter of the size of my friend's ex company.
We argued a bit about it and then he said "I'm tired of IT when it becomes some sort of self-worth entity in a company" meaning that it was consuming so much time and effort just doing "nothing". He said "They [the rival company] just changed their system with little effort, from a terminal based consoles to modern GUIs." My guess is that they had wrapped their old system with a GUI. I know that the rival company doesn't do anything if the change hasn't been through an rigorous screening process, even before being developed. They are not even close to being an agile (not as in "agile development") company.
I spoke with a former CEO of a company and he told me that they had invested a huge amount of money in a purchased system to automate their distribution. After the budged being spent and the transition failed they gave up and started over to develop the same thing from scratch and ended up in the same situation as the purchased situation. A product no one wanted or could use. The first case the product wasn't satisfying their needs because the product couldn't adapt to their process, and with the self developed product the budget was heavily underestimated to build whatever process they needed. ie simply ran out of money. They started out too big and failed to reach the goal.
I think the the main problem is the idea of IT being just a tool, particular when the systems are automating your company's business, and the leadership regards it as "just a tool". IT should be a tool and simple things are, but immediately when you start out incorporating your business into a system, the system becomes your company. Your company is as flexible as your tools. As an side effect, if your tools are depending on each other to function the harder it is to change, so just buying more tools won't do it. So to create a flexible company you have to create a flexible toolbox.
When using a tool you can only do whatever the tool is designed for. If you buy a rocket it won't serve as a car, and vice versa. You could build a rocket car but you would have to make trade offs, and its not even certain that the technology is invented to build an effective rocket car.
As an example: Excel is a tool, great for different "business" things. A person can create models and number crunchers quite easily, but even when you start out with filling in the first cell with some value you have to maintain this spreadsheet. The more complex the spreadsheet it is the harder it is to maintain, and the more of the business' information represented by the spreadsheet the harder it is to change. The more people that uses it the more general it has to become, since you want more and more functionality out of the same set of base information. The more people using it the more dependent they become of the tool. As more and more business information is put into the spreadsheet more different parts of your business relies on it. Also at some point you will find yourself with a something you depend on but can't do that new thing which would be so critical to have.
If you decide to automate a process into a system you have to really think of the following parameters:
What am I replacing by automating the business process (what would I have to have instead in form of manpower).
What would be the cost of not doing it.
What would be the cost if I throw away the system (how important is it).
How much will it cost me if we decide to replace the system with another system (are we going to be flexible enough, because this is going to happen).
However these are really hard questions to answer, but I think, they are really valid. I'd say to the first question is that you replace a significant amount of people doing the same job (people can always do the same job as a computer, but in most cases a lot slower). So lets say, I get a system which would replace 50000 people that could cut down costs. The missing problem here is that the system is dumb and can only do what they are told to do. Also that you lock your business with the weaknesses of that system. If it can't do it you either have to buy another product which might do the thing you want and merge those two system, or replace.
Systems can't do everything you want it to do. If you want something out of the ordinary you have to do it your self. The smaller the building blocks needed to create that system you might find some product which does some part of it, but you still have to develop most of it.
And in most businesses what they are doing is quite complicated. A human is a lot easier to "reprogram" although could do what ever they see fit according to the situation, as a computer won't (humans do mistakes, computers don't). You could regard this as, if considering the 50000 people as a system, the endpoints of it is a lot smarter than the endpoints (programs) in a system. And in regards of the third question same applies for the 50000 persons, wouldn't it hurt the company if you fire all of these people and you'd loose a significant amount of your business knowledge since, they outline your business. If not, don't buy/develop that system.
A person is always replaceable, 50000 persons is not, it would probably bleed your company too much if you try to replace all of those at the same time. The same thing if you would just pull the plug on a system, your company will probably not survive.
The same applies to your system. Its relatively easy to write a system. Its really hard to write a modular system, most of the times people say its modular but its really not since there are no (current) ways of knowing if it is. SOA is a good start but its not a guarantee. The recipe for an agile company is to have a system which is always built for tomorrow, e.g it has to be modular, contained and restricted. There has to be a strategy of always change and to be able to do it quick. Even so this is incredible hard to achieve and everyone has to realize that the system is your company and when you have a system, your company will not be more flexible and market responsive than your system is.
No comments:
Post a Comment