We need more sex in the workplace.

In some cases, much more.

Not among co-workers, for heaven’s sake. That’s their business, and if you’re very lucky they won’t make it your business.

No, this column is about sex in its biological sense — as a dramatic accelerator of adaptive evolution.

To understand the significance of sex, compare it to evolution in asexual populations. Imagine the offspring of an asexual creature contains a random, beneficial mutation. If it’s beneficial enough, eventually the population will consist entirely of that organism’s descendants. Then, a member of that future generation might have an offspring that contains another random, beneficial mutation. The process repeats, and with excruciating slowness the population will evolve.

Compare that to sexually reproducing organisms. Two parents give rise to an offspring containing a random, beneficial mutation. More of its offspring survive to reproduce than average, so the beneficial gene spreads.

Meanwhile, in another part of town, another beneficial mutation occurs elsewhere in the population. Among asexual organisms, the two beneficial mutations would compete. But these organisms reproduce sexually, which means two organisms, each having one of the mutations, can mate, giving rise to offspring that have both. The word is recombination. It’s what lets sexual evolution take place at a vastly faster pace.

Now, imagine a business with branch offices — maybe it’s an insurance company with agencies, a retailer with stores across the country, or a manufacturer with a number of local distribution warehouses.

The company could plan all innovations at headquarters. This is neither sexual nor asexual. It’s an attempt at divine creation. As few business leaders are divine, the odds of anything useful happening are limited, proportional to the number of former branch employees working at headquarters.

The company could, instead, encourage each branch office to innovate — to run itself as an independent business. This will encourage innovation, and innovation that fits local circumstances. But if that’s all the company does, it’s asexual. The branch offices will diverge, and because each will have to reinvent each others innovations, progress will be slow. Another disadvantage is that IT gets the miserable job of supporting as many different ways of doing business as there are branch offices.

Add sex. On a regular basis, bring the independently innovating branches together to compare notes and spread the best innovations back among the remaining branches. It’s recombination. But it isn’t as easy to accomplish as it sounds.

Among the barriers: It’s natural for the people in each branch to think their circumstances are unique, allowing them to ignore what the others do. Another: Designing an incentive system that, with the best of intentions, creates a barrier to adoption. If for example, you give a bonus to managers whose innovations are used elsewhere, everyone will focus on selling the benefits of their great ideas while denigrating those of the others.

This misses the point entirely. You want your managers to be the brokers of great ideas, not their originators. Give bonuses to the employees who suggest the successful innovations, and to the managers who adopt and implement as many innovations as possible, wherever they come from.

IT’s role in all of this is difficult. Not as difficult as supporting diverse ways of doing business, but still more difficult than if all innovations are designed at headquarters. You’ll need to create a systems architecture that supports multiple parallel innovation. Version control, change management and regression testing become challenges as well.

One solution: Create an environment that encourages IT innovation through end-user tools that link to the standard core systems. For those that spread sexually (DON’T SAY IT!), institutionalize them by rebuilding them into the core applications using enterprise-grade tools.

This isn’t a solved problem, by the way, which is just one of the aspects to branch innovation that makes it fun.

If you compare the benefits of branch innovation coupled with recombination to any of the alternatives, the advantages are clear: The business gets to try lots of experiments. It finds out which ones work and which ones don’t at modest risk, never betting the whole company.

It’s how nature works, and while evolution did give us the platypus, it has also led to a tremendous panoply of amazingly diverse creatures, each exquisitely adapted to its particular set of circumstances.

It’s a very sexy way to run your business.

“Oh my gawd!!!” cried Chicken Little a few years ago. “Microsoft bought Great Plains! It’s the end of third-party accounting packages! And oh, by the way, the sky is falling too.”

If you haven’t noticed, the sky hasn’t fallen yet (although that pesky ozone hole keeps growing) and Microsoft is still just another player in the low-end business software marketplace. What happened?

What happened is one of life’s little ironies. Start by recognizing that Microsoft is in the platform business. It does a pretty good job at it, too. The business, that is — form your own opinion about the platforms themselves.

Microsoft Windows is a platform — two actually, desktop and server. Visual Basic and Studio, Exchange, SQL*Server, and BizTalk all live in the platform layer, because you build things on them. That’s what platforms are. Microsoft Office is, if you squint, a platform, too. You build things on it — documents, presentations, and financial models for the most part. They’re simple compared to, say, an ERP suite, but they’re still applications of a sort, built on a platform of a sort.

Microsoft is in the platform business. The major ERP suites have become platforms, and as a result Microsoft probably thought its acquisition of Great Plains was a natural fit. It’s a syllogism: All ERP suites are platforms, Great Plains is an ERP suite, therefore Great Plains is a platform.

Except for one detail: Not all ERP suites are platforms. You might not agree that any of them are. If you don’t, you’re half right: They aren’t necessarily platforms, but they can, and probably should be. It’s up to the company implementing ERP to decide whether it’s going to be a platform or an application.

Imagine you’re in charge of IT for a Fortune 1000 company. You’ve implemented one of the big three — SAP, Oracle or PeopleSoft. Is it an application or a platform?

Before answering: Everyone who just groaned and said, “This is just semantics,” go to the blackboard (if you can find one — otherwise use a whiteboard) and write, 50 times, “Words reflect ideas. Ideas drive action. That makes semantics important.”

I feel much better now. Back to business. Is your ERP suite an application or a platform? It depends. When IT is called on to provide new or different functionality to the enterprise, does it figure out which module to add to those already installed, what customizations or configuration changes to make, and if there is new functionality to create from scratch, how to leverage the ERP suite to the extent possible in building what’s needed?

Or does IT buy a suitable application, or build one using a standard set of development tools if there’s nothing suitable to be found in the marketplace, and then integrate it as well as possible?

For a Fortune 1000 company, the first answer, in which IT treats the ERP suite as a platform, usually makes better business sense, because it results in a better integration and a more straightforward architecture. And in a Fortune 1000 company, poor integration and bad architecture are two big problems, because they make every project cost a lot more and take a lot longer than it otherwise would.

Now, imagine you’re in charge of IT for a Fortune 100000 company, assuming there even is such a thing. Your whole IT department consists of four people, and you write code when you aren’t managing a project or consulting with one of the business managers. You implemented Great Plains Accounting. Now the business needs something else.

If there’s a Great Plains module that does the job without having to make too many compromises on features and functionality, you’ll probably choose it, but that’s about it. Great Plains isn’t a development platform the way SAP is. It’s just an application. Nor, in a small business, are strong architecture and tight integration as important as they are in a big one.

And if the small business grows to a point where it needs to manage its architecture more formally and achieve tight integration, it will find itself outgrowing Great Plains at around the same time.

It’s ironic. Poor Microsoft bought an ERP suite, probably figuring it could do for (to?) the small and middle market what SAP did in bigger companies: Sell an application that becomes a platform, thereby extending its control of the architecture. Instead, it just has an accounting package and some other stuff to sell.

I’d be crying in my beer, if I had a beer in front of me.