Technology, more than any other single factor, is what drives an economy forward.

Ironically, technology is, more than any other single factor, what holds individual companies back.

Is it what drives economies forward? Of course it is. In the absence of technological change, products and systems eventually optimize themselves, whether through the natural selection imposed by the marketplace, or by the eventual impatience of ingenious employees faced with an inefficient status quo.

Yes, painful as the message may be, without new technology, new-and-improved starts to mean the same old products in new packaging, just as without new technology, internal process improvement starts to mean fixing what’s broken by breaking what’s fixed: Once the stupid stuff is gone, process changes involve trade-offs. Or, to put it a different way, quality might start out being free, but it doesn’t stay that way.

Without new technology, business change is mostly a zero-sum game.

But with new technology? New technologies means new capabilities, some of which might prove useful. Startups base new products on it; established firms might build it into existing products (or else buy the more promising startups). People and companies with money to spend decide to buy the new or improved products, which means that by definition there’s now more wealth in the system than there was before.

And so, the new technologies have moved the economy forward.

Meanwhile, an average CIO in an average business has just survived (barely) an ERP implementation. Was it a good idea? Maybe.

For companies that want an integrated business architecture, ERP is a necessary … not sufficient, but necessary … precondition. Why? Because that’s what ERP does — provide an integrated informational view of an enterprise — and if you don’t buy and implement a commercial alternative you’ll just go through the enormous effort of building your own.

For companies pursuing a more entrepreneurial or holding-company approach, ERP mostly puts all the business units on a common accounting platform — nice, but not a big deal in the greater scheme of things.

Or else it puts handcuffs on the internal entrepreneurs and no-longer-independent business units.

But never mind all that. What matters this week is that the company in question now has an ERP suite in place. Or, if you like cloud stuff better, the company has bought a bunch of Salesforce licenses, configuring it to support its sales and sales management practices and integrating it into its (you know this is coming) ERP suite.

Or … pick your poison: Software that does important stuff for a company takes time and effort to implement. And then, every year, the company in question adds a swarm of small enhancements to tailor and adjust the system so it fits the company even better.

All this represents more than just sunk cost, although the sunk cost is nothing to sneeze at.

No, even more than sunk cost, the software a company runs on represents a collection of ingrained habits — the software becomes embedded in the business culture.

And now, to pursue new opportunities, or to compete with businesses that have newer and better systems to support their operations, or because the company’s old business model has run out of gas and the company has to do something different or die … for one of these reasons or maybe a different one, the company has to do something its current suite of applications won’t support very well.

Faced with the need to rip out and replace major chunks of the company’s business infrastructure, in order to support a new and untried business direction, it’s easy to find dozens of reasons to coast along for one more year, leveraging the sunk costs instead.

What’s the solution? Is there a solution?

According to legend, when American Airlines first invented frequent flier, it ran the whole program on electronic spreadsheets for three years, until it was able to build a “real” system to handle the program. True or not, the concept points the way: When trying out a new business concept, don’t invest in a robust, scalable systems architecture. Doing so will take everyone’s eyes off the ball. Instead, cobble together capabilities out of whatever cheap alternatives will be good enough to get by.

This is, after all, a new business. Nobody knows what it will really need.

And when nobody knows what they really need, there’s no point investing heavily in it.

Ever wonder what separates successful IT departments from the ones that generate nothing but gripes?

Not what separates star-performing IT from “the pack,” but what separates the competent from the rest?

150 factors make the difference, but they aren’t all created equal. Squint at the list hard and 18 float to the top. (Why 18? Because that’s how many actually floated to the top. I didn’t start with a number in mind.)

Some background: Back in the last century when I wrote the  IS Survival Guide I organized the factors needed for IT to work into four buckets. Over time these evolved into the framework I use today: Business integration, process maturity, technical architecture, and human performance.

The 150 factors on my list of what makes the difference come from drilling down into these four categories. Selecting the 18 “critical success factors” from that list was less than scientific but more than arbitrary — it was the result of experience and lots of correspondence over the years.

This week’s column defines the big four and their overall scope. Starting next week we’ll dig into the critical success factors and what to do about them if your organization comes up short. So without further ado:

Business Integration

Business integration covers everything about how IT fits into the enterprise as a whole. It happens at three levels: strategic (meaning enterprise-scale), tactical (divisional), and business-infrastructural (overall “lifestyle” technologies) integration. And yes, I’m abusing the language using it this way. Live with it.

Those are the whats of business integration. The hows are governance and the business/IT relationship.

Process Maturity

Process … more accurately, processes and practices … are how an organization does its work. IT’s processes and practices fall into five broad categories:

  • Delivery management: Primarily on the applications side of IT, how the organization makes sure IT actually does deliver what it’s supposed to deliver. Delivery management breaks down into three levels: Program management, initiative management, and project management.
  • Application support: This includes everything having to do with designing or selecting; building or installing, configuring and integrating; enhancing; maintaining; and (when the time comes) retiring business applications.
  • Information management: Making sure all structured databases and unstructured data repositories contain what they’re supposed to contain, and are organized so as to maximize their maintainability, integrity, and value.
  • IT Operations: If the systems are down, nothing else matters. If they’re sluggish, something else matters but not much. IT Operations is where IT makes sure the value it’s already delivered is there, ready to use when it’s needed.
  • Personal technologies: The ERP suite is strategic and runs the company. The CRM suite is strategic and drives revenue. But employees live their lives on their PCs, smartphones and tablets, using the office suite, email system, and telephones. Handle these well and employees will forgive a lot. Handle them badly and your reputation is shot.

Technical Architecture

Yes, IT might be “about the business,” but in the end, someone has to make sure the company has the right technologies in place, organized well, and put together to facilitate the company’s next step instead of acting as a barrier or bottleneck. Notwithstanding all that’s written about shadow IT, non-IT IT and so on, when it comes to the stuff that can’t just be a standalone “island of automation,” that someone is IT.

Technical architecture encompasses the applications portfolio, the company’s structured and unstructured data repositories, and all the platforms and technical infrastructure they reside and run on. And how they all fit together.

Human Performance

IT might be “about the business,” and its job might be to provide the technology the company needs (and by the way, its job is now bigger than that, but that’s a different topic for a different column).

IT might get its work done through well-organized processes and practices, but in the end it’s the people who work in IT who make the difference between success and failure.

Human performance isn’t about whether the people who work in IT perform. It’s about everything that has to come together so IT has great people working in it, with as few barriers as possible standing between them and success.

These four factors — business integration, process maturity, technical architecture and human performance — are what IT has to be good at if it’s going to be considered competent.

How does IT become good at them? That’s what the list of critical success factors is for. We’ll start digging into it next week.