Microsoft Business Network (MBN)--Coming of Age? Part One: Event Summary

Event Summary

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 continues to invest in its current offerings to provide customers with the enriched functionality they need to remain competitive in today's evolving marketplace and to exploit their existing information technology (IT) investments by streamlining business processes, and by more easily accessing the information they need to make educated business decisions.

Given the immense ongoing development 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, in a great part due to 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, as to enhance its current line of ERP business solutions and service offerings in terms of helping its small, mid-market segment and even 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.

During Convergence 2004, however, MBS announced ongoing momentum and upcoming plans to expand the reach of Microsoft Business Network to a broader audience of trading partners, whereby it also highlighted the solution's success thus far and road map for the future. Microsoft Business Network (MBN) is a combination of on-premise software that is integrated with Microsoft Office, eventually with all MBS ERP applications (albeit currently only with MBS Great Plains) or with Microsoft BizTalk Server, and hosted Web services. MBN works with a set of Web services that facilitate connecting to and swapping information with trading partners. These Web services will be hosted by Microsoft, in part because smaller enterprises may not have a dedicated broadband Internet connection, and partly because some companies might not want to expose a Web service call outside their firewall. Future versions might nevertheless allow customers to manage the Web services on-site or to work with a third-party hosting partner.

This is Part One of a four-part note.

Part Two will discuss the market impact.

Part Three will cover challenges and competition.

Part Four will continue discussing challenges and make user recommendations.

Microsoft Business Network (MBN)

MBN was designed to help businesses more easily and effectively work with their trading partners (suppliers and customers) through a fully automated Microsoft .NET-connected solution, thereby increasing efficiency with a deep degree of integration throughout their enterprise and desktop applications and lowering the total cost of business-to-business (B2B) collaboration. In other words, MBN uses the messaging and collaboration facilities of Microsoft Outlook and the integration facilities of BizTalk Server to solve the supply chain connectivity part of the overall supply chain management (SCM) puzzle. The product facilitates inter-company collaboration (through minimizing data capturing and paper-based processes) with several key software components, tools, and community-building services, which will eventually include connectivity options for trading partners of all sizes, a trustworthy Web services network, a library of business process templates, partner management tools, and support to help companies automate their network of trading partners.

Since its launch in October 2003, MBN has reportedly experienced early adopter customer success. Possibly the best example would be Mikimoto (America) Co. Ltd., a subsidiary of the world-renowned creator and distributor of cultured pearls, which has completed its first phase of deployment (a pilot project with ten customers, which are all small retailers) and has successfully integrated these multiple organizations into its community of trading partners, streamlining its connection with customers. These customers can place an order by sending a Microsoft Excel form via Microsoft Outlook directly into Mikimoto's MBS Great Plains back-office system. When the order is received, an order acknowledgement is automatically generated and sent via Outlook back to the customer. In a similar manner, advanced shipment notices (ASNs) and invoices too are generated and sent via Outlook.

Mikimoto America is therefore using MBN to automate its ordering processes, which have traditionally been manual and paper-based, with e-mail, electronic data interchange (EDI) or fax as communication means, and to raise customer satisfaction levels through increased responsiveness, flexibility, and availability of information. Since deploying the solution, Mikimoto America has reportedly realized a number of benefits. For one, by streamlining the ordering process to make it faster and easier for both Mikimoto America and its customers, MBN saves Mikimoto America employees the time they would previously spend on manual sales processes, enabling them to focus instead on building more personal and productive relationships with customers. The solution has also helped the company significantly reduce its order-to-cash cycle (to one week from two or more weeks), allowing the company to increase its customer service standards and minimize manual sales process inaccuracies, rework, and delays in order fulfillment. On the other hand, the retailers (customers in this case) should end up with more accurate orders and faster shipments, and they can also use only Outlook to store all of the transactions with Mikimoto.

Based on these positive results, Mikimoto America has recently further launched a broad community-building effort to connect to the rest of its customer base. It is hereby reaching out to 500 resellers, most of which are small, family-owned stores, and the company expects at least one hundred of those resellers to join within the next few months. On the other, suppliers' side, Mikimoto has also been talking to a luxury watch manufacturer about using MBN too, thereby encouraging even wider customer adoption.

In the future, the company will also leverage the MBN's upcoming connectivity with EDI value-added networks (VANs), enabling its users to send EDI documents to trading partners that do not currently subscribe to MBN and receive them in return.

MBN Support for EDI

EDI might likely be the original embodiment of B2B e-commerce, which had started with a lot of mainframes and minicomputers talking to other mainframes and minicomputers. To refresh our memory, EDI emerged in the 1960s when the railroad industry sought a way to speed up and automate business communications between remote computer systems, and to eliminate the high cost of sending paper documents by snail-mail. The concept did not fully take hold industry-wide until the 1980s though, when standards were introduced to define data exchange, and when it became apparent that B2B, computer-mediated communications would require all parties to adopt a common protocol for purchase orders, acknowledgements, ASNs, and other pertinent documents. As a result, several technical committees have developed protocols governing such exchanges, which, channeled through VANs carrying these exchanges, became collectively known as EDI.

Owing to those roots, the technology remains an expensive proposition with VANs functioning like sort of electronic toll roads, charging per document or kilo-characters of data. Amounts can quickly add up. Indeed, EDI has a reputation for being expensive to set up and run, given the companies had to deploy numerous VANs, which are essentially proprietary e-mail systems that store and deliver EDI-formatted documents. It drove their suppliers' network costs up and forced them to be proficient in various communications protocols.

Aside from the upfront cost of the EDI infrastructure software (such as, set-up fees and leased lines fees), companies choosing to go with a provider of VAN EDI networks, face additional costs in maintenance and transaction processing fees alone (i.e., interconnect costs). For the above reasons, one would expect companies to begin gravitating in droves toward extensible markup language (XML), Internet-based EDI, and related Web services for transaction communications. Therefore, MBS' intention with MBN has been to make the EDI process easier by removing at least one layer of the technical problem, so that its partners can then focus more on the business issues that the customer really cares about.

Accordingly, MBN will support generic EDI with XML standards, while it will also enable interoperability with other EDI standards and more traditional EDI data transports in future releases. MBN will support generic versions of American National Standards Institute (ANSI) X12-formatted documents such as the 810-invoice, 850-order request, and 856-ship notice, but MBS is committed to providing maps that translate any company-specific EDI implementations into the generic format. The product will also provide VAN-like functionality for direct XML-to-XML data exchange. However, Microsoft notes it has been in talks to provide a connection to at least one high-profile proprietary VAN, albeit which trading will involve additional customary charges (e.g., per document or per kilo-character of text) in addition to the purchase and subscription costs for MBN.

Besides traditional VAN support, MBN will also eventually provide support for emerging EDI Internet Integration standards, such as AS1 and AS2, as to meet the increasing demand for Internet delivery of EDI services rather than over proprietary VANs. Namely, while VAN-based EDI traffic has lately been flat by and large, Internet EDI transactions have been growing at an annual rate of over 50 percent. Specifically, during the past few years, a number of EDI suppliers have breathed new life into this old workhorse technology by developing offerings that use the Internet as the communications medium, eliminating the need for multiple VANs and driving the per-transaction cost downward.

In addition, vendors have developed hosting services that reduce or eliminate customers' need for in-house EDI resources, whereby, further EDI complexities can be hidden behind a browser-based "thin" client interface, making EDI communications practical for many small companies that would not have considered its use before. As a result, although XML is more flexible and easier to use than EDI, EDI protocols will run for years among major manufacturers or retailers that have heavily invested in their use, and that have the clout to demand their trading partners use EDI as well. As a matter of fact, EDI, XML, and any other format are merely "semantics" and input streams for expressing data, and whether a transaction is transmitted in EDI format or XML is largely secondary to the fact that electronic document and data exchange is growing rapidly. For more information, see EDI versus XML--Working in Tandem Rather than Competing?

To that end, Microsoft has begun talking to many independent software vendors (ISVs) about providing support for applications, services, and infrastructure. For example, working closely with Inovis Inc., a provider of business commerce automation solutions that was formed from the merging of Harbinger and Extricity, MBS has recently completed a proof-of-concept project demonstrating that MBN can successfully receive and send EDI-based documents. MBS expects to connect with the Inovis:Access VAN for expanded connectivity and EDI managed services, offering these capabilities as a third-party service by the end of 2004.

Inovis provides the XML to EDI and EDI to XML mapping, document acknowledgement, interconnect services, and secure VAN services, including document tracking, archiving, and reporting. Thus, during the proof-of-concept phase, EDI-based transactions were mapped for compatibility with MBN's XML messaging. A customer would thereby send an EDI transaction wrapped inside an XML message to MBN, which would forward it to Inovis to translate it into normal EDI format and deliver it to the user's mailbox. The reverse would work as well, with Inovis being able to translate an EDI transaction into XML. In both cases, Inovis will use an Internet-based, EDI flavor, AS2 as the preferred medium, although the company can handle EDI of all kinds, depending on the end user's needs and technology commitments.

The ability to send EDI-based documents via VANs, according to both Inovis and MBN, will allow MBN's customers to expand their trading communities by successfully connecting to a broader range of businesses, regardless of their size, technical expertise, and use of legacy systems. MBN and Inovis pledge to address these issues by allowing small and midsize businesses to continue to trade EDI-based documents via a single connectivity point, regardless of the standards or networks the trading partners use.

This concludes Part One of a four-part note.

Part Two will discuss the market impact.

Part Three will cover challenges and competition.

Part Four will continue discussing challenges and make user recommendations.

comments powered by Disqus