Fog Creek Software
Discussion Board




Technology in a Business

... is a mirror of the organization's soul.

This is my pithy rephrasing of something that an MBA professor said to me over dinner:  "The only companies that should implement ERPs are the ones that don't need them."

It took me a while to understand what that meant, since it's counter-intuitive, but I've come to realize that it's a very deep truth.  What it means is that, if a business can't operate efficiently without computer systems to run things day to day, then adding technology won't help, and will probably make things worse.

In other words, technology can't fix problems, and using it to do so will only make things worse.

The professor's perspective was that technology should be used only to gain clear efficiencies; sort of "Okay, we've figured out how to route invoices through accounts payable--now let's make our computer system do the boring, repetitive stuff for us."  You can't effectively computerize processes that you haven't mastered yourself.

After five years managing the IS department at a manufacturer, I have to agree.  The most successful applications we've deployed are the ones that move a well-understood process from paper to screen.  New features and process modifications that are clearly articulated are also successful.

In contrast, I've been pulled into meetings where senior management looks at me and says "Planning is a mess--can't the computer system help us out somehow?"  Well, no, it can't.  You have no idea what you want the computers to do because you have no idea how to solve the problem.  Throwing silicon at it won't fix anything but hide the root problem beneath a lot of unnecessary expenses.

So, I've come to conclude that technology is perfectly neutral in terms of business value.  Well run businesses can use technology for clear wins; badly run businesses will use it to hide problems and delay solutions.

This may not seem like a very profound insight if you agree, but to me it's a strong antidote to all the hype in the technology market, and I remind myself of it now and then just to remain sceptical about all the promises of software vendors.

Thoughts?

Justin Johnson
Tuesday, July 20, 2004

As Mahatma Gandhi said, "Find purpose. The means will follow".

Mis-conceptions and mis-perceptions arise when the person who uses a tool for his ends is made to deal with another for who the tool is the purpose.

KayJay
Tuesday, July 20, 2004

My father who worked at IBM in the sixties used to tell a story of how a screwed up buisness would get an IBM salesman to figure out how to  "computerize" his business. This would mean analyzing what they should do with all their paperwork.

Once the salesguy did all the analysis, if the business implemented the suggestions manually, they wouldn't need the computer and the salesguy wouldn't get the sale.

MilesArcher
Tuesday, July 20, 2004

Justin, I think you've hit the nail on the head.

Technology is indeed just a tool, a means to an end.  Your goal may be to provide quality tools to other tool-users, but you have to keep in mind the fact that the tool you provide must be genuinely useful to them, not merely a cool widget that has little real functionality.  The compaines the buy the cool widgets that do nothing are the ones that are flailing, expecting the technology to do the real problem solving.

Aaron F Stanton
Tuesday, July 20, 2004

I disagree with the premise. (This thread needs a contrarian, right?)  It's a fine academic argument, but it doesn't match up with the realities of business.

If a company does not have robust business processes, an ERP system can be the catalyst to make their processes more robust.

I've had the displeasure of being with two companies that have switched ERP systems.  Both times the companies went through rigorous evaluation of, and changes to, their processes.  This type of effort takes a lot of company-wide commitment and man-hours and is very unlikely to happen without a major driving force (e.g., a new ERP system).

Yet another anon
Tuesday, July 20, 2004

My experience with workflow systems, of which ERP is usually a really expensive version, is that what businesses think they are doing is very different from what they actually do.

Managers sometimes have a distorted, or incomplete, view of what their subordinates (have to) do to get the work done.

One time I was tracking down an inconsistancy between what a report (let's call it the TPS report) that came from an employee was showing and what came out of the "new improved workflow doohickey." The conversation went something like this:
Me: why don't you use the data from the computer?
Her: well, I massage the spreadsheet from Suzy to turn into the TPS report.
Me: so why don't you use the data from the computer for the TPS report?
Her: because Suzy's spreadsheet is correct.
Me: OK, so why isn't the computer's data correct?
Her: Oh! that. Bob fiddles with the numbers until he gets the bonus check he wants. But those numbers are useless for the TPS report. And Bill ships product to a customer who turns around and sends it back (called channel stuffing) after the beginning of the month, so he gets credit for the sales, but not punished for the returns.

Another implementation problem happened when the person signing off on the project wanted to have the system keep multiple sets of books: one for tax, one to make themselves look good to investors, one to look good to their superiors and one for real. I bailed on this project. My boss was pissed, but it ended up being a total loss for everyone involved.

When "wants to know what's going on" collides with "wants to look good," your project is doomed.

Some folks act all surprised at how much Enron managed to diddle when they fiddled their books. I remember a movie from the mid 70s about some company (equity funding corp?) who managed to use their computer system to diddle the stock market out of several hundred million dollars (under 1% of what Enron did). The final scene had cops rushing into "the glass house" where the main frames and punchcard machines were kept. And the cops all looked around for bad guys and the operators in the room (horn rim glasses, white shirt, black ties) were staring at the cops with that "wtf" look. Classic.

Peter
Tuesday, July 20, 2004

"Both times the companies went through rigorous evaluation of, and changes to, their processes. "

Well, this is exactly what a company *should* do, and implementing an ERP may trigger the kind of organizational soul-searching that improves things overall.  But how much did that really happen?

The VP of Distribution here was part of the implementation of Baan at his former company, and said that there was a lot of pushback from all areas at fully adopting the new workflow.  Overall, it was a success because the implementation had support at the highest levels to make the change.  But I fear Peter's experience is far more common.

Wasn't it Coke that blew $3,000,000,000 on a failed implementation of SAP?

Justin Johnson
Tuesday, July 20, 2004

A agree completely with Justin.

When I first started I thought software was about solving technical problems.  Then I realized technical skills don't matter if you do not understand the business. These days, I've been running into business problems that I understand perfectly well, but the organization does not have the people and processes in place to handle them, computer system or not.

The other day a wizened IT guy said "Organizations always get the systems they deserve" at a meeting with senior management. I laughed loudly and inappropriatly.

   

Corporate Dork
Tuesday, July 20, 2004

business knowledge is key.

the reality is that i'm an okay programmer. but, i think i have good abilities to understand the financial industry.

one comment, i do think there is a difference for working as a cost center vs. revenue generator. you get treated much better if you generate revenue - duh!

Patrick
Tuesday, July 20, 2004

"business knowledge is key"

Well, if this statement really is a universal truth then why did so many non IT related corporations fire so many knowledgeable full-timers?

Walk into to just about any large coporation today and you will typically find more consulting firm employees and contractors working on maintenance and new software projects than full-time employees. At least this is what I have observed.


Tuesday, July 20, 2004

> So, I've come to conclude that technology is perfectly
> neutral in terms of business value

Not sure I agree with this as a resulting conclusion.  If you're talking about a good scenario where the process was understood, and the computer simply eliminated the paper, drudgery, and the human tendency to be error-prone, then isn't this a plus?  I say it is, as long as the gains from increased efficiency outweigh the development cost of the project.

Just because some companies (or even a lot of them) misuse the tools, doesn't mean that technology itself lacks real business value.  It just isn't the silver bullet the managers and sales people expect it to be...

Joe
Tuesday, July 20, 2004

"Well, if this statement really is a universal truth then why did so many non IT related corporations fire so many knowledgeable full-timers?"

My employer just came through a brutal re-organization in which we lost about half our knowledge overall.  I estimate that the average years of experience per employee dropped from 4 to about 1.5.  4 isn't bad for a ten year old company.  1.5 is a bloody shame.

Why did we let so much human capital go (not that I had any part of the decisions...)?  A couple reasons:

1) Intense pressure from the parent company to show immediate savings in the form of reduced labor costs.  Cut the Marketing department, which is redundant with the parent company's, along with several key business planners, because the parent company's operational logic should be sufficient for us.

2) Lack of awareness of how important some people were.  Three months after firing the head of planning, inventory was spiralling out of control, because no one who made decisions was aware that he was doing a decent job of managing overall inventory levels.  The guy who created all the product specifications was fired because no one really knew how much labor went into the job to keep it flowing smoothly; three months later, we're a mess again.

3) Lack of planning for secondary separations.  The QC manager was fired; four of his close friends, who'd come to the company with him, left a couple weeks later just because they decided they didn't want to work there anymore.  Unfortunately, those four were 80% of the production scheduling department.  Several other key people also decided the time to move on had arrived.

#1 was simple shortsightedness by the decision makers and the parent company, coupled with a dim awareness that we'd be losing some expertise, but that we had a (we thought) sufficient substitute in place.  #2 was exactly what it says: a (stupid) lack of awareness of how the company actually ran.  #3 was a lack of planning.  The head of HR had been through several re-orgs at various companies, and should have strenuously warned the decision makers about a common phenomena of re-orgs.

My department was untouched because two VPs made very clear how important they thought we were; after the re-org, IS now has the highest number of years of experience in the office, and it's gone a long ways towards helping the company limp through and rebuild where necessary.  Maybe that was part of their considerations, as well.

What does that have to do with my OP?  We didn't deploy new systems to replace separated employees, but we did retain enough knowledge about the logic of the business to keep operating, barely.  Business knowledge is absolutely key.

Justin Johnson
Tuesday, July 20, 2004

I don't know if Coke lost on SAP, but it almost killed Hershey.  It cost Hershey more than $150,000,000--They won't ever say the real cost.

Google for: SAP Hershey Disaster
for more than you care to read.

XYZZY
Tuesday, July 20, 2004

It sounds like exactly the sort of thing an MBA professor would say. It's meant to sound profound, but isn't really.


Tuesday, July 20, 2004

Justin Johnson wrote, "...but we did retain enough knowledge about the logic of the business to keep operating, barely"

So the prevailing business logic seems to be that senior managers should never f*ck with the revenue stream (the production of widgets, the selling of insurance policies, etc.) but it is okay to screw with just about everything that was created to support that revenue stream. I guess this strange behavior is simply part of "the eternal quest to maximize company profits and management's compensation".

One Programmer's Opinion
Tuesday, July 20, 2004

Why do all the bean counters get bent about I.T.? It is because of a Harvard Business Review article that has mutated into some fad book: Does IT matter?

http://www.amazon.com/exec/obidos/tg/detail/-/1591394449/

It will be a fad that unfortunately will screw the US for some years. After all, your cheese is moving again. He thinks that software and IT is a commodity. Like buying a car or dvd player.

If you automate a bad or corrupt business process, you only do evil faster. That might be fine and dandy for the folks running SPECTRE or Enron, but not for the average business.

Remember, the old motto GIGO was garbage in, garbage out. But the new motto GIGO means garbage in, gospel out.

Peter
Tuesday, July 20, 2004

Nicely put Justin. I can just imagine the CEO with his feet up on the desk casually glancing at his Executive Dashboard to take the pulse of his moribund business....

MT Heart
Tuesday, July 20, 2004

>>> It will be a fad that unfortunately will screw the US for some years.

Hey, it'll screw us in Canada too!  The idea that IT is a commodity is one of the more successful trolls of our time.  IT isn't a commodity when you're looking at the processes of an individual business - it has to be tailored to the business.  IT also isn't a commodity when you're looking at common processes like typing a letter, adding up columns of numbers because there's not enough of an interchangeable supply of goods: e.g only a few word processors to choose from.

>>> If you automate a bad or corrupt business process, you only do evil faster. That might be fine and dandy for the folks running SPECTRE or Enron, but not for the average business.

I love that!

Although in SPECTRE the outcome of a failed CRM implementation would be a fresh supply of shark food.

Ward
Tuesday, July 20, 2004

Same thing happens in robotics.

A company would find out that they're were having problems with a certain part of the manufacturing process.

They would call in automation consultants, who would go past hundreds of people doing mind-numbingly repetitive jobs that were just crying out for automation and then be shown an incredibly complex process requiring a high degree of human judgement and skill and be asked to automate it.

They would reply that this job couldn't be automated  but that a load of other jobs in the factory could. "Oh, no" the answer would come back, "we don't have any problems with those jobs".

Stephen Jones
Wednesday, July 21, 2004

Deborah Riordain wrote that often when she was called in as a consultant to design a database for a customer, after she had finished the requirements she would be told by the customer "You know, I never really knew how my business worked until now."

Stephen Jones
Wednesday, July 21, 2004

when a business decides it needs a new application to help their processes it is usually because there is some problem that needs to be fixed. it can be that things need to be done faster, processes are messy or that the competitors have got similar applications and you cannot be left behind. in any case you need a serious process analysis to know what kind of software you need.

If you think about the situation and the business setting as a system you may identify these actors: people, business processes and software applications. All three have to work together. There is no point in buying the "best" application in the market if it doesn't fit your processes and people. You can either look for different software or redesign your processes to fit the software. You can also develop your own software and ask people how they like things to be done. All the alternatives require analysts and developers to immerse themselves in the business setting and understand it, so they can identify problems that can be corrected by a computer or just by redesigning a manual process.

Software alone doesn’t solve problems, but a system with software that fits business processes and people’s needs does. 

Cecilia Loureiro
Wednesday, July 21, 2004

*  Recent Topics

*  Fog Creek Home