Microsoft Business Solutions is setting the stage for big-time channel conflict among resellers

Everyone knows that Microsoft is moving aggressively to enter the enterprise applications market, with its acquisition of Great Plains and Navision earlier this year, as well as its development of its own enterprise CRM systems and other applications. This is old news.

But what is not generally recognized is that Microsoft is heading for trouble in how it is signing up resellers. Anecdotal evidence indicates that Microsoft is showing no restraint in how many resellers it signs up in a given geography, as if the more the merrier.

This was the mistake that Baan made in the late 1990s, when it signed up many resellers without considering that they might be competing against each other. During this period, I was doing a software vendor selection where three Baan resellers were attempting to sell to my one client, and none of them would back off. Apparently, even Baan couldn't control the situation because they eventually told me that I should make the decision on which reseller to use.

I see the same thing happening shortly with Microsoft, as its Great Plains, Navision, and Axapta resellers watch Microsoft merrily signing up additional resellers down the street.

Whoever is in charge in Redmond/Fargo needs to understand that selling enterprise applications is not the same as selling Win2000, Exchange, or SQL Server seats. These are complex sales with long lead times. One of the little secrets of selling enterprise applications in the mid-tier is that although the reseller channel is key, it is also limited. There are not many good or great reseller organizations. When you find good ones, you don't turn around and undercut them by creating competitors next door.

For more discussion, see my post on Axapta and my post on unintended consequences of Microsoft's move into enterprise systems.

ERP vendor consolidation continues, with MAPICS acquiring Frontstep

Frontstep (FSTP), formerly Symix, is the latest casualty of the downdraft in spending on enterprise systems, agreeing to a buyout by ERP vendor MAPICS (MAPX). MAPICS has been holding up better than many in this economic climate, profitable in the last three quarters on flat sales of $128 million in the trailing 12 months. The two vendors do have much in common. Both focus strongly on mid-tier discrete manufacturing firms, and each vendor has a significant client base. The combined entity will reportedly have something in the neighborhood of 10,000 customers, so on the surface the acquisition might seem like a good thing.

But what is curious about this transaction is the rationale. MAPICS is one of the oldest vendors selling on the IBM iSeries (AS/400) platform. Although its acquisition several years ago of another vendor, Pivotpoint, gave it offerings in the Unix/NT/Oracle markets, MAPICS is still strongly identified with IBM. Frontstep, on the other hand, just completed a major rewrite of its flagship product, Syteline, abandoning its Progress database roots in favor of 100% pure Microsoft technology.

With Frontstep rapidly running out of cash, it's easy to see why Frontstep would agree to be acquired. But the question is, what is MAPICS thinking? The first explanation might be that MAPICS wants Frontstep's client base for its maintenance revenues. But Frontstep's clients are vulnerable right now, having just been told they will need to migrate from Progress to Microsoft SQL Server at some point in the future. I've already received one call from a Frontstep client, asking for my opinion on this. So those maintenance revenues might not be so secure. The more likely explanation is that MAPICS wants to diversify its products to include a Microsoft-centric offering. Frontstep bet the farm on its migration to Microsoft technology and it looks like it lost the farm in the process. But if MAPICS was planning to develop a Microsoft-centric product anyway, it would be a lot cheaper and faster to simply buy it from Frontstep than to build it themselves. The question now is whether MAPICS can sell it, first to Frontstep's own installed base and then to the rest of the mid-market.

Generally, major software vendors that have tried to grow by acquisition frequently have found themselves with too many packages to support on too many platforms. Epicor is one example. Unless MAPICS has some grand scheme in mind that I haven't thought of, I don't see how this acquisition makes sense.

Buzzword alert: Web services

What are Web services? A Web service is a program that can be remotely invoked by another program means of an Internet protocol, such as HTTP. The term is unfortunately ambiguous, because the word "Web" does not refer to "Web sites" but to the Web transport protocol (HTTP) that is typically used by Web services to communicate with each other. Hence, Web services are a way of implementing a distributed computing model across heterogeneous computing platforms. If you've ever visited Amazon's Web site and entered a FedEx tracking number to retrieve delivery status, you've seen a Web service in operation. In this case, the Web service is provided by FedEx, which the Amazon's Web site invokes to retrieve your package tracking information. Another live example you can play with is Microsoft's MapPoint, which is actually Microsoft's first commercial Web service. If you have a Web site or other application that needs mapping information, you can sign up for MapPoint and pay Microsoft by the transaction. In both examples, you've got information delivered from remote systems on demand by means of Web services.

Web services are an innovation around which fierce competitors (e.g. IBM, Microsoft, Sun, H-P, Oracle) are cooperating to develop open standards for the common good. Some key standards include XML (Extensible Markup Language), SOAP (Simple Object Access Protocol), UDDI (Universal Discovery and Description Initiative), and WSDL (Web Services Description Language). Application development frameworks for Web services fall into two main categories: those that are based on the Microsoft .NET Framework, and those that are based on Java 2 Enterprise Edition (J2EE). Nevertheless, because Web services are standards-based, those developed under Microsoft .NET should have no problem interoperating with those developed under J2EE.

Many enterprise system vendors (e.g. SAP, Siebel, Oracle, Peoplesoft, J.D. Edwards, Microsoft Business Solutions, Frontstep), are working to allow parts of their systems to operate as Web services, to some extent or another. For the enterprise system vendors, the big hope is that Web services will greatly reduce the difficulty of integrating systems internally and between trading partners. Integration in the past has been accomplished either by writing custom interfaces, implementing complex and costly enterprise application integration (EAI) software, or by setting up EDI or XML links. As Rodger Beard wrote me recently,

I view the emerging Web service application architecture as a paradigm shift within the IT industry, and a shift that ultimately will impact basic general business processes in a most fundamental way. I feel Web services is very significant, analogous and maybe even more significant than the movement from mainframes to client server computing in the late 80's....All hype aside, this new architecture permits, and indeed readily facilitates the inexpensive, incremental automation and integration of inter-company, cooperative business processes. The practical possibilities for further process automation, leveraging the cheap hardware now available, is truly mind boggling to me. Not only are Web services applications (and applets) quick to develop, a piece at a time, but they inherently incorporate Internet based data communication protocols--sort of like "EDI on steroids," and without all that startup baggage that EDI has always featured.

It remains to be seen whether Web services will live up to these expectations. Thus far, most development of Web services has been taking place behind firewalls, as some IT departments are experimenting with the technology to build simple interfaces between internal systems. There is a general consensus that the standards are not yet fully developed to the extent needed to handle complex integration logic between business partners, specifically in providing security and multi-step transactional workflow.

For a more detailed discussion on the status of Web services adoption, see Ed Yourdan's article on the Cutter Consortium site.

Time for a system refresh project? BusinessWeek has a short article on the trend away from large projects to implement completely new systems toward smaller projects to repair and improve existing systems. The article says, "Unlike the 1990s' craze of spending millions for new gear and armies of consultants who worked on extended contracts, the trend now is toward shorter, less expensive deals that make the most use out of existing IT resources."

My own observation is that many companies use less than half of the functionality available to them in their enterprise systems (e.g. ERP, supply chain, or CRM applications). There are many reasons for this: incomplete implementation the first time around, new users who are not as well trained as the original users, small changes in business processes, and creative users who develop their own little "side systems." I have often felt that companies would benefit greatly from organizing once every two or three years a small project to assess the use (or non-use) of their existing systems and to formulate corrective actions to improve their use. Such corrective actions can include additional education and training, business process redesign, custom report development, elimination of side systems, and implementation of unused functionality. My own experience in helping clients carry out such system refresh efforts indicates that the benefits are real. More companies should do this.

QAD acquires major international alliance partner

QAD, one of the better known Tier II ERP vendors, is acquiring one of its major alliance partners, TRW ISCS, for a mere $1 million in cash and transaction/integration costs of $4-5 million. According to the press release, QAD expects the unit to generate annual revenue in the range of $13-15 million and be accretive to earnings by the second half of fiscal 2004. If so, this appears to be a good deal for QAD. TRW ISCS was what was left of Largotim, one of the top QAD alliance partners. Largotim was acquired by BDM in the late 1990s. BDM, in turn, was acquired shortly thereafter by TRW. With QAD now acquiring the TRW unit, the cycle is complete.

QAD has traditionally focused on development of its flagship product, MFG/PRO, and left nearly all of the implementation services and much of the sales effort to its alliance partners. But with the slowdown in technology spending, QAD has been moving more and more into direct sales and services. With its large installed base, this is a wise move, and the acquisition of TRW ISCS just accelerates the trend. The same technology slowdown no doubt led to the fire-sale price QAD was able to negotiate. As the enterprise software sector begins to emerge from the doldrums, I expect to see other vendors acquire some of their more attractive yet weakened partners. This positions the surviving vendors to take a larger share of each new deal, instead of having to share it with a partner.

"Rich client" looks promising, but tools are still immature

I've gotten quite a bit of feedback on my post last month about the trend toward "rich client." David Harding, principal of FulcrumPoint Technologies, confirms that pure thin-client solutions leave something to be desired. With experience in developing fat-client, thin-client, and rich-client solutions, Dave says,

"I find it a marvel that people are finally coming to the conclusion that thin-client did not speed up development and that to really get a decent client/server application, the client had to be part of the equation. Besides, if you want to build any sophistication in the interface and distribute processing so as not to overload the servers, a “rich” client is the better, and sometimes only, choice. That is not to say that thin-client apps can’t be a great way to create applications with limited functionality. However, javascript is not ready for primetime (in any flavor) and Java is a promise that Sun just can’t seem to agree on how deliver. The arguable truth is that each technology has its own strengths and weaknesses, and each should be used only when the individual strengths can be leveraged. Every time I hear that a single technology (e.g. thin client, Java, artificial intelligence, add your favorite technology de jour here…) is going to render all its predecessors useless, I have to laugh.”

However, even though the rich client architecture looks promising, some of the tools used to develop such applications are still rough around the edges. Commenting on his experience so far with Microsoft Visual Studio .NET using “managed code” and Webforms, Dave says,

.NET has some cool stuff, but the promise and the reality are still a good distance apart. Performance is an issue now more than ever. Having to download components (.NET components), marshal data across the network, deal with text based API’s and re-learn all of the standard (and new) development tools (e.g. C++, C#, Visual Basic, etc.) make working with these great new technologies a chore… not to mention that they are still in their infancy (read that: filled with fun and interesting bugs that are difficult to determine if it’s a bug or a design issue by the programmer). But still we press forward...

What does all this mean for vendors of ERP, SCM, CRM, and other enterprise applications? If the trend toward rich client architecture continues to build, it means that vendors will have to face one more platform migration. Many of them have not yet fully made the transition from fat client to thin client. Unfortunately, once they get there they may find that the goal line has been moved once again.

Business success is more than regulatory compliance. I spent this past week in Chicago, leading a workshop on software validation for the medical device industry, and we had extensive discussion on FDA regulations for Quality Systems (21 CFR Part 820), as well as electronic records and electronic signatures (21 CFR Part 11). Participants included a group of software developers from Europe, as well as a group of senior ERP consultants from the US. As we worked our way through the regulations section by section, line by line, I realized once again the extent to which, from a business perspective, regulatory compliance is just one aspect of business success. To be successful, a medical device manufacturer, or a pharmaceutical manufacturer, must do a lot of things right. It must bring in revenue, manage costs, meet delivery commitments, maintain quality, and a host of other things. But FDA compliance only addresses one of those dimensions: quality. FDA doesn't care if you properly forecast demand, increase sales, control your costs, accurately plan material, or manage capacity--in fact, FDA doesn't even care if you stay in business. By law, FDA only cares about one thing--that as long as you are in business, you design and make product that is safe and effective.

Sometimes I think that companies lose sight of the fact that, although regulatory compliance is mission-critical, you are not in business to be compliant. You are compliant to be in business. But to be successful, you must do much more.

Let's have a moratorium on vendor/package name changes.

One Spectator reader called yesterday to ask what I knew about MAS 500 from Best Software. Let's see, Best offers the MAS 90 and MAS 200 products, popular Tier III systems. One might assume that MAS 500 must be a new upgrade of MAS 200. Wrong. Here's the story. MAS 500 is the new name for Best Enterprise Suite. Best Enterprise Suite was acquired by Best when it bought Sage Software, which referred to the package as Sage Enterprise Suite. But Sage originally referred to the package as "Acuity," which is how most people still remember it. So here's the bottom line: MAS 500 is the old Acuity product that Best acquired from Sage. It has nothing in common with MAS 90 or MAS 200, except the similar name. With so many software vendors being acquired, and so many package names being "re-branded," it's becoming very difficult to keep them all straight, even for those of us who evaluate systems for a living.

Expect end of year deals on enterprise applications, but read the fine print. Paul Hamerman, a research director for Giga Information Group, has some good recommendations on making year-end deals for new software this year. Q4 is typically a good time for buyers to negotiate with vendors for new systems, because of the vendors' need to meet sales targets. However, because few vendors expect the market to roar back in 2003, it is going to be hard for them to convince prospects that favorable terms will disappear after December 31. Furthermore, watch out for deals where the vendor throws in several "free modules" that you "might need later." Such modules might be free in terms of upfront license costs, but they are frequently included at list price when calculating maintenance fees. Hamerman points out that in such cases the vendor has simply gotten you to agree to pay him an additional recurring revenue stream. I have often felt that companies frequently buy too much software up front. Structure the deal to only buy the modules that you plan to implement over the next 12-18 months. You'll save on maintenance fees, and you'll also have stronger leverage with the vendor during implementation, because he'll know that future purchases will depend on how well he delivers on the stuff you've already bought.

And, never pre-pay for implementation services. One more thought: if the vendor offers a discount on implementation services if you prepay for them, don't take it. You've lost all leverage if services are substandard. And since the vendor already has your money, guess which consultants he'll put on your project.