Home
 > Research and Reports > TEC Blog > Microsoft Business Network (MBN)--Coming of Age? Part Fou...

Microsoft Business Network (MBN)--Coming of Age? Part Four: More Challenges and User Recommendations

Written By: Predrag Jakovljevic
Published On: September 4 2004

More Challenges

At the end of March, during its annual conference for North American customers, Convergence 2004, Microsoft Corporation's (NASDAQ: MSFT) Microsoft Business Solutions (MBS) division previewed upcoming versions of its enterprise resource planning (ERP) and customer relationship management (CRM) solutions: MBS Axapta, MBS Great Plains, MBS Navision, MBS Solomon, Microsoft CRM, and related services. The main takeaway from the conference was that MBS will continue to invest in its current offerings to provide customers with the enriched functionality they need to remain competitive in today's evolving marketplace and exploit their existing information technology (IT) investments. Business processes will be streamlined, and the information they need will be more accessible allowing companies to make educated business decisions.

Given this immense, ongoing developmental undertaking, which began at MBS even before its strategy was espoused in 2002 (see Microsoft Lays Enforced-Concrete Foundation for Its Business Solutions), the incremental approach towards building a more complete enterprise applications portfolio seems logical, if not the only possible option. MBS strives to not only retain the existing install base within the maturing ERP product lines, but also to stimulate the acceptance of recent ERP-adjacent product extensions, some of which are featuring parts of the latest Web services-based technology, and drive sales or upgrades of high-volume products like Microsoft Office 2003 within the MBS' large install base that is nearing the 300,000 mark.

Hence, one should not be surprised by MBS' recent more upbeat results which are, in a great part, from up-selling so-called "surrounding" applications like Microsoft Business Network (MBN), Microsoft Demand Planner, or Microsoft Business Portal to its existing ERP users (see Microsoft Keeps on Rounding Up Its Business Solutions). Namely, late in 2003, to enhance its current line of ERP business solutions and service offerings in order to help its small, mid-market segment, and even to help certain large corporate customers improve the effectiveness of current ERP investments, MBS announced the general availability of MBN, and the upcoming delivery of two demand planning modules.

While some may point out that the adoption of business-to-business (B2B) connectivity technology is still largely driven by larger corporations that recommend and often require that their smaller trading partners adopt Internet electronic data exchange (EDI) technology, at least MBN and the slew of the above competitive products that are emerging, should come in handy for small businesses. These small businesses, which now might not be proactively pursuing this technology, will eventually have to act upon their larger customers' mandate. This, however, may again prove Microsoft's astuteness when it comes to technological enablement, but not necessarily when it comes to complex domain knowledge of several industries and their supply chain management (SCM) processes. While MBS might not have necessarily underestimated the services and support required by small-to-medium businesses (SMB) when engaging in B2B integration with their own suppliers and customers, it will have to prove its seriousness by delivering many more business process templates.

Linking electronically with each new supplier that uses EDI is typically a week's-long process and the threat to MBN comes from some enterprises opting to link with their non-EDI-capable suppliers through specialized, third-party, intermediary, EDI service providers. These providers receive EDI messages from a trading network or manufacturer and provide the information to suppliers in whatever format that works for the company (even through fax), and vice versa. Communication is then taken from the suppliers and translated into EDI for transmission back to the exchange. As manufacturers continue to extend the efficiencies that come with EDI to a larger portion of their supply base, while reducing the required time and effort to connect to a large number of suppliers, for the smaller supplier company, advantages include the ability to do business with much bigger partners while avoiding the need for a large IT staff, not to mention the cost of setting up individual EDI connections with different customers. Some of these providers could even perform fulfillment for the supplier in addition to acting as an EDI intermediary.

One such third-party service provider would be Mercury Commerce, which offers a service called VendorBridge. The product provides shipping information to the participants in a file that could be imported directly into a UPS application so that the customer's staff do not have to re-key the data. Last but not least, the solution is entirely Web-based, with no software to install at either side and with no upfront costs for the initial set-up.

This is Part Four of a four-part note.

Part One detailed recent events.

Part Two covered the market impact.

Part Three presented challenges and competition.

Summary

Therefore, existing and potential MBS customers and resellers will face a confusing assortment of EDI and XML products, both within and outside the MBN realm. The picture gets much more cluttered with the many other ISV partners that potentially have similar solutions to Inovis, and their consternation and resentment to the MBS' possible acquisition of an independent service vendor (ISV) that is EDI specialist. On one hand, some ISVs and value-added resellers (VARs) partners, particularly those that have been building atop the MBN functionality, should become more competitive (e.g., by delivering a special business process template customization and integration, by performing help-desk functions for a certain hub or community, etc.). Many other partners would see the eventual acquisition as yet another competitive threat from MBS' ever-increasing appetite for providing more and more applications-level functionality than mere electronic connectivity functionality.

Namely, MBS has been enticing its partners to focus on providing the application layer, possibly unique to specific vertical markets. However, these partners may feel like being between the rock and the hard place—not only that they might be involved in investing in solutions that might compete with those of another ISV partner, but there is always a danger of MBS entering into a slew of OEM alliances and acquisitions, which might cannibalize current development efforts.

Again, to avoid having to customize its core software, MBS has to try to convince ISVs to build industry-specific applications that leverage the core functionality supplied by its ERP systems and extensions like MBN, while Microsoft would remain the infrastructure supplier (for example of Microsoft Business Framework that includes application functionality, business class libraries, and development tools like .NET and Visual Studio, all running on the Windows OS). MBS will have to energize its resellers about providing industry-specific configurable templates, but that again can only happen once MBS produces a consistent and comprehensive listing of desired extensions (for example, "white spaces" atop the Microsoft stack that seek customization and value add-on by partners). It will also need a certification program ensuring that these extensions' developers use methods that guarantee ongoing compatibility with MBS products, all which might be too far fetched to expect at this stage.

Last but not least, in the long term, MBN holds the promise of becoming the backbone for the bigger picture of collaborative planning, forecasting, and replenishment (CPFR), trade promotions, new product design and introduction (NPDI), sourcing, procurement, etc., but MBS is still far from being a leader in these enterprise applications areas. The messages of enabling customer satisfaction and retention, freeing-up working capital by reducing inventories, increasing returns on trade promotions, bringing new products to the market faster than competitors, and achieving top-line growth by reducing stock-out situations as the first manageable SCM initiatives, should strike a chord with the risk-averse target.

The objectives of end-to-end supply chain visibility are better plans, better service, increased inventory turns, and higher profit margins. MBN might answer only some of these requirements at this stage. It is going to take much time and an orchestrated effort by MBS and its partners to take functionality from SCM, product lifecycle management (PLM), supplier relationship management (SRM) and so on, and make it available as a "software-as-a-service" offering. In any case, MBN is a great, initial idea that can lay the foundations for a future product of a more grandiose, collaborative undertaking.

User Recommendations

Small- and medium-sized manufacturing and distribution businesses (particularly those using MBS Great Plains back-office applications), which have unsophisticated B2B integration practices, but require flexible connections with their trading partners, and which have demand-driven SCM concerns, should evaluate the current MBN functional capabilities as a way to add value to their existing applications. Such business should bear in mind that other ERP or EDI vendors might currently offer more mature and functional products at this stage. These prospective customers should consider adding the announced functionality to their requirements list, as to secure value in terms of both potential cost savings and increased efficiency. Approach MBS to clarify its current skills to support your short- and long-term SCM initiatives, as well as to produce a clarified product roadmap, particularly in terms of EDI enhancements within MBN.

While the smaller businesses must be attuned to what their larger customers and trading partners require, and thus consider MBN and the like products as a relatively simple and inexpensive way to support those customers' demands, MBN is only a small part of the trading relationship equation. Since the technology is only an enabler that facilitates changes, for B2B collaboration to be effective, industry-specific performance measurement and change management will have to be instituted. Thus, true cooperation from suppliers and customers as well as strong support services from MBS and its partners to deal with business-related questions, technical glitches, and data translation issues will be required.

Companies that are dependent on EDI for transaction routing should look hard at the likes of MBN as its pathway into the XML century. What should be most important to them is how smoothly the translation service can be implemented in terms of integration with their other systems. Therefore, size and technical strength are not as important as experience with the same systems users might have.

Given the concurrent use of XML and EDI for some time in the future, companies should think carefully about how to leverage the mix, as to minimize the risk of duplicating efforts (i.e., of both systems doing virtually the same work). To that end, one should thoroughly consider the number of transactions the company will be transmitting on a daily basis, and whether that transaction volume will change over time. Further, every interested enterprise should ascertain whether it has the staffing available to commit certain full-time resources to EDI/XML, while the solution's compatibility with the current operating environment is mission critical. The number of trading partners is also critical, and they should check and see if the EDI/XML solution they are evaluating has ever worked with their trading partners. Also, one should determine the price structure for adding a new trading partner.

Prospective customers should ask MBS and any other competing vendor to produce the total cost of ownership (TCO) and ROI rationale for a particular deployment. Customers should clarify whether they are purchasing all of the software they need to meet their EDI/XML requirements now, and what the costs for implementation, training, support, and upgrades they can expect now and in the future. Such questions include whether trading partner updates be readily available for download, or if the customers must wait for EDI/XML maps to be changed.

 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.