Microsoft Business Network (MBN)--Coming of Age? Part Four: More Challenges and User Recommendations
Written By: Predrag Jakovljevic
Published On: September 4 2004
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.
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
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
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.
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.
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
is Part Four of a four-part note.
One detailed recent events.
Two covered the market impact.
Three presented challenges and competition.
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
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.
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.
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
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.
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.
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.