IBM continues to submerge its product brands

IBM's last major Systems and Technology Group (STG) reorganization in 2000 both put an exclamation group on and added momentum to the company's resurgence. IBM described the introduction of the umbrella "eServer" brand atop all of its server product lines as:

a product of Project Mach 1, a major cross-company initiative begun three years ago to harness the company's best technologies and practices to support the infrastructure for the next phase of e-business. From the consolidation of IBM server manufacturing and development, to the realignment of its sales force, to breakthroughs such as copper chips, Silicon-on-Insulator and Memory eXtension Technology, to partnerships with leading software vendors, to IBM's corporate-wide embrace of Linux--every corner of IBM moved closer to today's launch of the IBM eServer.

This unification stood in stark contrast to the past norm in which product groups in Poughkeepsie, N.Y., Austin,Texas, Raleigh, N.C., and Rochester, N.Y., often seemed more like warring fiefdoms than different faces of a single integrated company. True, the various product lines--xSeries, zSeries, iSeries, and pSeries--maintained distinct (if sometimes uncomfortably overlapping) identities within the eServer scheme. Nonetheless, by historical IBM standards, eServer under Bill Zeitler looked like a big and (mostly) happy family.

This latest reorg can perhaps be best thought of as taking the next big step toward shifting away from a structure based on technology and product line distinctions, and toward a structure along the lines of distinct customer segments.

The new STG organization retains groups, led by general managers, oriented around the various product lines: Mainframe Platform (System z), Power Platform (System i and p), Modular Business Platform (System x and BladeCenter), and Storage Platform. However, these are now entities mostly concerned with managing product development and rollout. Go-to-market activities, including sales, now reside in four other groups:

• Enterprise Systems. This could also be thought of as "major accounts" because, in addition to selling into large-scale datacenters, Enterprise Systems also encompasses sales to workgroups in large enterprises.
• Business Systems. We first got a taste of this reorg last year when IBM created this SMB-oriented group. Given the nature of the market, much of the sales strategy here will be to leverage partners of various types.
• Industry Systems. This group will focus on areas like retail or health care where IT often plays roles outside of a traditional data center environment--often in the form of embedded OEM products. Although, in a sense, Industry Systems follows in the footsteps of its engineering services predecessor, IBM has also made it clear that its focus is now far more on replicable products than one-off projects.
• Microelectronics continues to offer a variety of services from semiconductor fabrication up through turnkey design.

IBM's justification for these latest changes is that customers want to see one face of IBM. They don't want to see System x and System p sales reps each offering whatever parochial solution is better for their particular comp plan. Even if the customer doesn't mind all that much, IBM is doubtless not a big fan of customers playing IBM divisions and sales reps against each other to get the best price. The customer segment approach is a play that IBM's run before--indeed, run quite successfully. There were good reasons for getting away from it in years past, but there seem to be good reasons to get back to it now.

That said, any organizational scheme has its trade-offs. Product-centric alignments are in some sense more natural, or at least simpler. They match up with the underlying technologies. This makes it easier, for example, for sales teams to become experts on particular product sets--without more complicated overlay sales specialist schemes. A product orientation also means that you're likely to see more effort go into pushing products into new areas where they aren't necessarily the most natural fit; Linux on POWER is one example from IBM's playbook. Although some force-fitting may well be wasted energy, such initiatives can also open up new markets for a company.

At the end of the day, it may even be reasonable to ask how much the specific organizational structure ultimately matters. Some mappings may make more or less sense at a given point in history for a given company, but I've seen so many cycles and fashions over the years that I have some trouble accepting that any one approach is ideal. Perhaps it's more important to occasionally shake things up and avoid complacency than it is to lay out any particular form of organizational chart.