Latest word on the street concerning MAPICS. I'm hearing from reliable sources about some interesting developments concerning MAPICS, following its acquisition of competitor Frontstep last year. At the time of the acquisition, I was skeptical of the ability of MAPICS to support such a wide variety of products: MAPICS XA (written for the IBM iSeries, a.k.a. AS/400), Point.Man (UNIX/Oracle), its Syteline ERP system acquired with Frontstep, plus some secondary products that both MAPICS and Frontstep had acquired, such as the Distribution Architects warehouse management product. The Syteline product itself includes the newly release V7 (completely redeveloped for Microsoft .NET) as well as earlier versions (written on Progress database for Microsoft or UNIX). That's a pretty wide variety.

Although I am still concerned about the ability of MAPICS to support so many products and platforms, it appears that the company at least has a plan. As I noted in my April 19 post, a large installed base is a competitive advantage in the currently weak market for new license sales. And MAPICS, now having over 5,000 customers with 10,000 installed sites, lays claim to one of the largest installed base populations of any enterprise system vendor. The issue will be how to leverage that installed base into new business. With that goal in mind, it appears that MAPICS is taking the following actions:

1. MAPICS plans to develop a set of common complementary products that will be interfaced or integrated across all of its core systems. For example, interfaces from certain products from the Frontstep acquisition may be built to facilitate implementation by MAPICS XA clients. Or, interfaces from certain products within the MAPICS family may be built to facilitate implementation by existing Frontstep clients. If my vote counts, I would suggest a good candidate would be the MAPICS advanced planning and scheduling (APS) product, formerly known as ThruPut, one of the few APS systems that are based on the Theory of Constraints approach to scheduling known as drum-buffer-rope.
   


2. MAPICS plans to continue support for older versions of Syteline on the Progress database. This will be a huge relief to the Syteline user base, most of whom are still running older versions and may not appreciate being forced to upgrade to Microsoft .NET. In this market, MAPICS can ill-afford to alienate its customers, and this is a wise move.
   


3. MAPICS is hoping to use the strength of its Frontstep User group to build a stronger user community among all its users. It will strongly support gatherings of all its users, which it will need as an audience to sell its common product extensions.

In some ways, MAPICS appears to be adopting a similar strategy to that of SSA GT, which is also creating a large installed base by acquiring weaker competitors. SSA GT is also known to be planning to offer common complementary products to all of them. As I noted last week, such complementary products do not need to be "best of breed." They just need to be "good enough" to keep existing customers from leaving the fold. But SSA is different from MAPICS in that most of its acquisitions have been on a single infrastructure platform: IBM. With MAPICS, the challenge will be in supporting multiple platforms: IBM iSeries, Microsoft .NET, and Oracle/Unix.

The other challenge, which MAPICS doesn't seem to recognize, is the name "MAPICS" itself. MAPICS is clearly a brand that screams "IBM." For those of us old enough to remember, the MAPICS system was originally an IBM product from the 1980s, one of the first real MRP II systems for the mid-range computing platform. In the 1990s, IBM sold MAPICS to Marcam, which later spun it off as its own company, where it remains today. But today MAPICS (the company) is staking a good part of its future on Microsoft, and to me at least, it is constantly going to have to explain to people like me that it is no longer just in IBM's camp. As much as I hate the constant name changes in the enterprise systems marketplace, in this case a name change might really be warranted.