Microsoft Solution for Supplier Enablement

Services Guide

Microsoft Corporation

Service Release 1, May 2002

Applies to:
 Microsoft Solution for Supplier Enablement
 Microsoft Commerce Server 2002
 Microsoft BizTalk Server 2002

Summary: Learn about the four phases of a services engagement for the Microsoft Solution for Supplier Enablement (MSSE).

Contents

Introduction
Vision/Scope
Planning
Development
Stabilization/Release
URL Resources

Introduction

This Services Guide for the Microsoft® Solution for Supplier Enablement (MSSE) discusses the four phases of a services engagement for this solution and provides guidance for the successful completion of each phase. The four phases are:

• Phase 1: Vision / Scope
• Phase 2: Planning
• Phase 3: Development
• Phase 4: Stabilization / Release

Reader Guidance

Anyone reading this guide should also read the product documentation for Microsoft BizTalk® Accelerator for Suppliers Service Release 1 (AFS), Microsoft BizTalk Server, and Microsoft Commerce Server, each of which contains specific and detailed information about the corresponding products. Additionally, readers should review the other Microsoft Solution for Supplier Enablement guides.

Vision/Scope

You use the vision/scope phase of a typical service engagement for the MSSE to scope out the following issues:

• Project size
• Business factors driving the project
• Complete assessment of the current situation of the customer
• Determination of the high-level decision-making criteria for the project deliverables
• High-level milestones for the project

The primary deliverable for the vision/scope phase is a vision/scope document that has been approved by all relevant parties. This document, when properly written according to Microsoft Solutions Framework (MSF) principles, serves as the main source of the statement-of-work provided by the solution implementers. Although this document may refer to other documents for specific information and measurements, it should contain enough detail for all team members to understand the vision and scope of the project.

The vision/scope document should bear the signature of all the lead stakeholders of the project, in approval and acceptance of its contents. It should be backed up by other documents containing more specific information and measurements, but it should provide a good basis for all team members to gain a clear understanding of the project parameters. Completion and approval of the vision/scope document and any related documents constitute completion of the vision-approved milestone.

For a comprehensive introduction to the MSF, see the "Microsoft Solutions Framework Overview" white paper, which can be found at http://www.microsoft.com/business/services/mcsmsf.asp.

The remainder of this section provides details about the various sections that should be included in a vision/scope document, and provides a collection of questions that are useful in determining the vision for, and scope of, an MSSE project.

The Vision / Scope Document

The vision/scope document is the primary deliverable of the vision/scope phase of an MSSE project. As defined by the Microsoft Solutions Framework (MSF), the vision/scope document should contain the following sections:

• Executive Summary
• Opportunity / Problem Statement
• Business Benefits
• Vision Statement
• Decision-Making Criteria
• User Profiles
• Solution Concept
• Usage Scenarios
• Project Team
• Critical Success Factors
• Risk Management
• Initial Project Schedule

The remainder of this section discusses the expected content of these sections, as they apply to the MSSE.

Executive Summary

This section should contain a brief but comprehensive summary of the various factors that lead to undertaking the MSSE project, including the business motivation and objectives, the features to be implemented, the project timeline, and the anticipated outcome.

Opportunity / Problem Statement

This section should contain a complete description of the problems this MSSE project is trying to solve, or the opportunities this MSSE project intends to address. The information in this section will drive many of the decisions made in the planning phase of the project.

In the realm of supplier enablement, likely candidates for these problems and/or opportunities are the following:

• Major buyers moving to electronic procurement over the Internet
• Protecting the current set of buyers from eroding due to their moves toward electronic procurement
• An opportunity exists to increase business with existing buyers through early adoption of supplier enablement
• Reducing expenses by increasing the efficiency of the sales cycle
• Deepening relationship with existing buyers by providing additional ways to interact
• Acquiring multiple new customers with one technology investment

Although the implementation of the MSSE may address other problems and opportunities, those listed above are likely to be common to many supplier enablement scenarios.

Business Benefits

This section should list the anticipated business benefits that the completion of this project will yield. These benefits should correspond to the problems and/or opportunities stated in the previous section. Articulation of the project benefits will help drive the acceptance tests that will be written in the planning and development phases.

In a services engagement, a clear statement of the business benefits is very important, because it helps to establish a clear set of exit criteria for the project.

Vision Statement

This section should state the project vision. This section provides the project team and the customer with a common understanding of what the project will achieve, and helps to:

• Establish an agreement with the customer about the goal(s) of the project
• Establish the decision-making criteria for the project
• Make project trade-offs

Decision-Making Criteria

This section should address the three standard, potentially conflicting, factors of any project: ship date, resources, and features. Constraining more than one of these factors results in a much greater chance that the project will not succeed in all respects.

Part of the process of determining the vision and scope of a project is determining in advance the relative priorities of the three factors being discussed here. For example, if the ship date is critical, features may need to be cut to a minimum, and more resources applied; or it might be sufficient to trim features, or to add resources, but not both. Alternatively, if resources are limited, and features are already minimized, the ship date may be the only variable factor.

In any event, this section of the vision/scope document should provide information about the relative importance of the ship date, resources, and features for the MSSE project.

User Profiles

This section should describe the roles of the various users of the MSSE, focusing primarily on those users within the supplier organization. Depending on the supplier, the number of unique types of users will vary, and consequently the number of different types of tasks performed by any one user will also vary. For example, is the organization large enough so that two different groups of people handle catalog publication and order processing? Or does one group handle both tasks?

Although the buyer and the trading partner also represent distinct user roles in the overall scenario, you do not need to consider these users in this section. They are outside the realm of the supplier, which this solution addresses.

Solution Concept

This section should outline the solution approach and architecture at a high level. The outline should contain sufficient information to begin the planning phase. The outline should consider the following aspects of the solution:

• Required hardware
• Required software
• Integration with existing systems
• Performance requirements

This section should not be too detailed, and should not attempt to take the place of the functional specification that is delivered in the planning phase.

In practice, this section can be constructed from various sections of the MSSE Architecture Guide and the MSSE Deployment Guide including those sections that are relevant to the solution being developed.

Usage Scenarios

This section should describe the basic scenarios in which the MSSE will be used. This should correspond to the roles defined in the User Profile section, and should be divided according to the three basic areas of functionality: catalog publishing, remote shopping, and purchase order reception.

For example, with regard to catalog publishing, the following types of issues should be considered:

• From where did the catalog data originate? Was it imported into the Commerce Server Product Catalog System or was it entered manually in the Commerce Server Product Catalog System using Commerce Server Business Desk?
• After the catalog data is in the Commerce Server Product Catalog System, will it be maintained there? Or will it be maintained elsewhere and periodically imported into Commerce Server?
• How often will new versions of the catalog be published?
• Will individual products in the catalog be available for remote shopping?

Project Team

This section should identify the roles on the project team and their corresponding responsibilities. It should also discuss issues related to team interaction, such as the frequency of various meetings and the combination of attendees at those meetings, how common team documents and other project information will be maintained, and so on.

The MSF team model defines a set of roles and corresponding responsibilities that have been found to be a constructive way to organize a project team. Although the names of various roles and precisely how the various responsibilities are distributed may vary in different organizations, the different responsibilities described should be attributed to a role. Further, some responsibilities tend to conflict with each other and are better distributed to unique roles. For example, a person who develops a particular software product should not be the same person who tests that product.

The various project roles defined by the MSF are described below.

Product Management

The goal of the product management role is satisfied customers. Product management team members engage in the following types of activities:

• Act as a customer advocate
• Drive the project vision and scope
• Work with customers to define and maintain requirements
• Develop and refine the business case for the project
• Manage customer expectations
• Drive feature versus schedule decisions
• Manage marketing and public relations
• Act as product evangelist

Program Management

The goal of the program management role is to deliver the project within the defined constraints. Program management team members engage in the following types of activities:

• Drive the development process
• Manage the product specification
• Facilitate communication and negotiation within the team
• Maintain the project schedule
• Report project status
• Drive high-level trade-off decisions

Development

The goal of the development role is to build the solution as specified. Development team members engage in the following types of activities:

• Specify the features of the physical design and options
• Estimate time and effort to complete each feature
• Build the features
• Prepare the solution for deployment

Logistics Management

The goal of the logistics management role is to ensure smooth rollout of a manageable and supportable product. Logistics management team members engage in the following types of activities:

• Act as an advocate for operations, support, and delivery channels
• Manage procurement
• Manage product deployment
• Drive manageability and supportability trade-off decisions
• Manage operations, support, and delivery channel relationships

User Education

The goal of the user education role is to enhance user performance and reduce support costs. User education team members engage in the following types of activities:

• Act as an end-user advocate on the team
• Define user requirements
• Design and develop performance support systems
• Drive usability and user performance enhancement trade-off decisions

Test Management

The goal of the test management role is to ensure a high-quality product. Test management team members engage in the following types of activities:

• Ensure all issues are known
• Develop testing strategy and plans
• Manage test execution and the reporting of results

Critical Success Factors

This section should identify the key factors that will influence the success of the project. The identified factors may be those that have either a positive or a negative impact on the project. Relevant factors may include people, processes, technology, management, and competition. They may be internal or external to the supplier for whom the solution is being built.

The factors identified in this section are important because they help determine when the project is successfully completed. Reaching a common understanding with the customer about such issues at an early stage in the project definitely contributes to a harmonious project conclusion.

Risk Management

This section should establish a common understanding between you and your customers about risk management and risk management procedures. All projects have risks that can hinder the critical success factors of the project. To minimize the impact of these risks, they must be identified as early as possible so that mitigating plans can be developed.

Educating the customer about risks that can affect the success of the project is an important discipline to develop and foster. Often, these risks are outside the control of the project team, such that they cannot be avoided even with excellent planning.

These risks must be identified and brought to the attention of the customer as early as possible. And since new risks can arise during the course of the project, risk management must be ongoing through the life of the project.

There are a wide variety of possible risks to a project. The following list identifies a number of common types of risks that should be considered, grouped into schedule risks, resource risks, and scope risks.

Schedule Risks

• Tasks that are exceptionally complicated
• Tasks with a duration longer than two weeks
• Tasks on the critical path
• Tasks that have several predecessor tasks
• Tasks with overly optimistic time estimates
• Tasks that depend on external groups
• Start-to-start and finish-to-finish dependencies
• Dependencies with lags
• Major milestones
• Unforeseen issues (for example, reorganizations and office moves)
• Unstated assumptions

Resource Risks

• Tasks with one key individual assigned
• Tasks using scarce resources
• Tasks for which the resource are mismatched
• Tasks that require a large number of resources
• Unavailability of appropriate tools
• Tasks which rely on third-party vendors for their completion
• Tasks which rely on resources within another group for their completion

Scope Risks

• Uncertainty of new technology
• Changing customer requirements
• Tasks with significant business impact
• Overly aggressive performance requirements

The following techniques can be helpful in mitigating many of the risks identified above:

• Add resources to tasks for cross-training
• Establish independent parallel efforts
• Schedule high-risk tasks earlier in the development phase
• Reduce project scope
• Add review tasks
• Shift more experienced people to difficult tasks
• Intentionally design redundancy into the solution
• Change the approach to eliminate high risk tasks
• Add prototyping tasks to prove concepts

With respect to the MSSE, a particular class of solution-specific risks need to be considered and identified as early as possible. These include:

• Overall quality of the implementation by the trading partner(s)
• Varying interpretations of XML standards
• Degree of implementation of XML standards
• Degree of error handling implemented by the trading partner(s)
• Network reliability
• Anticipated catalog and purchase order sizes
• File size limitations
• Details of existing supplier infrastructure

A variety of risk management techniques and information are part of MSF and can be found on the Microsoft Solutions Framework site at http://www.microsoft.com/business/services/mcsmsf.asp.

Initial Project Schedule

This section should provide an initial project schedule. Whether or not the initial project schedule is realistic, given the features to be included and the resources to be engaged, will be determined as the schedule is refined during the planning phase. In any event, it should be possible to establish solid milestones, if not their associated dates, in the initial project schedule.

The following table shows an example of an initial project schedule for a typical MSSE project.

Note An operations representative, probably working through the logistic management team, should be involved in the vision/scope phase of the project. Experience suggests that when this is not done, significant delays in the successful deployment into a production environment are common. For more information, see the MSSE Operations Guide.

Project Assessment Questions

One of the keys to success in the vision/scope phase of an MSSE project involves figuring out the right questions to ask, and then getting the answers to those questions. This process helps formulate the correct vision for the project and leads to an accurate assessment of the scope of the project.

The purpose of this section is to provide you with some of these questions. They are divided into several different categories.

Assessment of Existing Infrastructure

• Does the supplier have a Web site? Do they already sell their products on the Web site? What operating system and Web server platform do they use for the Web site?
• Does the company already have a product catalog? Do they have multiple product catalogs? If so, what format is the catalog data in? How is the catalog organized?
• Are any of the products configurable?
• Does the supplier have a corporate discount strategy?
• Does the company operate a warehouse?
• Does the company use an ERP system? Multiple ERP systems?
• Does the company have subsidiaries with which it must interact? If yes, how diverse is the geographical base?
• Does the supplier have a Private Key infrastructure (PKI)? If yes, using what platform?

Assessment of Existing Business Processes

• Who is in charge of the product offerings? What is the flow of information from creation to publication?
• How does the supplier take orders today?
• What needs to happen before the supplier can ship the order?
• Does the company have to buy any products on-demand from other suppliers?
• How does the company ship products to customers? What geographies are covered?
• How is inventory controlled? What are the replenishment policies?
• What kind of authorization is needed on special orders and new customers? Is the authorization based on quantity or on total cost, or both?

Assessment of Trading Partners

• Who are the relevant trading partners and what business document standards do they support?
• What business documents do the trading partners expect to exchange?
• Does each trading partner have any special business processes?
• Which trading partners are suppliers and which trading partners are buyers? Are some both suppliers and buyers?
• For trading partners that are buyers, are the catalogs published to them customized in any way?
• How many purchase orders per day are being processed from these trading partners? What percentage of those purchase orders are being migrated to the solution that is being considered?
• How sensitive is the information to be exchanged by the proposed solution?

Assessment of Planned Market Differentiators

• Are there any specific ways in which the supplier wants to differentiate itself from its competitors? For example, using personalization, auto-replenishment, and so on.

Planning

The deliverables of the planning phase are as follows:

• Functional specification. Describes the solution to be built and includes the solution design goals, requirements, features, and dependencies.
• Master project plan. Describes how the solution will be built.
• Master project schedule. Describes when and in what order the solution will be built.

The planning phase ends with the project plan approved milestone, which signals approval to build the solution.

Planning Phase Tasks by Role

The following tasks, listed by role, are performed during the planning phase.

Program Manager

• Own and drive the schedule, including rolling individual schedules into a master schedule.
• Own the project feature set, and communicate this through the functional specification.
• Own the budget for the project.
• Own progress reporting.
• Coordinate resources.
• Facilitate team communication.
• Drive critical decisions and make trade-offs based on project constraints.

Product Manager

• Drive customer satisfaction.
• Act as customer advocate to the team, and act as team advocate to the customer.

  (It is important to distinguish between the customer and the end user. The customer pays for the product while the end user uses the product.)

• Understand and communicate customer requirements.
• Articulate the business case for the project.
• Ensure the team and the customer share the same vision for the project.
• Assume communication leadership with the customer.
• Manage customer expectations.

Development Lead

• Lead the development team in building the prototype.
• Ensure that the prototype, as built, meets customer expectations.
• Build the prototype to drive the functional specification.
• Serve as the technology expert.
• Contribute to high-level designs.
• Evaluate alternative technologies.
• Develop proof-of-concept prototypes.
• Mitigate development risks early.

Test Lead

• Lead test team in ensuring product quality.
• Ensure that all issues are known and addressed prior to project completion. Issues include flaws in the code and documentation, and deviations from the functional specification.
• Develop comprehensive test strategies, plans, and schedules.

User Education Lead

• Act as the advocate for the end user.
• Help ensure product usefulness.
• Ensure product usability.

Logistics Manager

• Act as the advocate for operations and product support.
• Help ensure a deployable product.
• Help ensure a manageable product.
• Help ensure a supportable product.
• Understand the product infrastructure and support requirements.
• Develop installation and support plans.

Determining the Project Size

This difficult task is important because an accurate estimate is required to properly determine the project budget, schedule, and resource requirements. To accomplish this task you need to determine the required functionality of the product and compare that to the functionality provided by the MSSE. This functionality includes both the out-of-the-box functionality provided by Microsoft BizTalk Accelerator for Suppliers (AFS) Service Release 1 and the functionality enhancements discussed in the associated documentation.

It is important to have a thorough understanding of the AFS architecture in order to be able to determine the size of an MSSE project. Refer to the MSSE Architecture Guide or to the AFS online help for this information.

Determining the answers to the questions in the following sections is critical to properly estimate the size of the MSSE project.

General Questions

• How many trading partners are to be integrated?
• Which message standards will be involved? MSSE provides support for catalog and purchase order exchange using cXML 1.1 and 1.2 (Ariba and Clarus), and xCBL 3.0 (Commerce One). Do any other message standards need to be supported? If so, this will increase the size of the project.

  For more questions about choosing a message standard, see the next section "Message Standard Selection Questions" in this document.

• Which messages will be involved? Any messages other than catalogs going out and purchase orders coming in? If so, this will increase the size of the project.
• Does the project require content management? If you are going to maintain your catalog in Microsoft® Commerce Server 2002, you should consider a content management solution such as Microsoft® Content Management Server 2001.
• Do you need reporting and monitoring?
• Do you need to keep organization and/or user profiles?
• Do you need to support remote shopping? Within the out-of-the-box MSSE scenarios, this is perhaps the most important question in determining the size of the project. Supporting remote shopping will increase the size of the project.
• Do you need to authenticate users or are you leaving that to the marketplaces? The marketplaces will send you a buyer ID, but you may still want to authenticate the buyers on remote shopping sessions for security or personalization reasons.
• Do you need to provide personalization and targeting during remote shopping sessions? Commerce Server supports this functionality, but it is not implemented by AFS.
• Do you need to implement payment processing? There is no payment solution provided by AFS or Commerce Server.
• Do you need to provide a “configurator” for complex configurable products? Depending on the complexity of your products, this can be a significant effort. You could also consider some third-party solutions for this.
• Do you need to build a conventional shopping site? If so, remote shopping can leverage your regular shopping pages. Or, if a conventional shopping site already exists, remote shopping code from AFS can be integrated into it.
• Do you require a fully redundant and highly available system? How will this affect the complexity of development, deployment, and operations? This will multiply the number of servers required, and consequently, the complexity of the deployment and management.
• Are you building onto an existing Commerce Server 2002 site or do you need to implement a new one? If you already have a Commerce Server 2002 site, your planning activities will be somewhat different. You need to take a good look at what files you have in place and which ones you do not, which ones are customized and which ones are not, so that when you start using files from the MSSE, you can make updates and adjustments accordingly.
• Is there an existing order processing and fulfillment system in place? If not, how complex will it be to build? The Commerce Server 2002 Order Processing pipeline is very comprehensive, but you will still need to modify it for your needs.
• Do you have existing functionality (such as shipping, inventory, and tax calculation) that you can leverage? Allow plenty of time for integrating such functionality. BizTalk Server can help where connectors already exist; otherwise, this can involve significant effort.
• If an order processing system exists, does it need to be augmented or is it self-sufficient?
• If you have an existing order processing system, determine how difficult the integration will be. Consider leveraging BizTalk Server, especially where accelerators or connectors already exist.
• Do you need to integrate with other back-end systems like ERP, CRM, MRP? If you need to integrate other systems into a complete order processing system, allow for plenty of integration time.
• Do you need to integrate with an existing master content source? If so, you should provide an automated catalog update mechanism.
• Is there a significant data migration or cleansing effort required to move the existing content to the new system? This can involve significant effort, depending on the amount of data you have to aggregate and its current format. You may want to consider a third-party service for data cleansing and migration.
• What skill sets are needed? How many people in each skill set will be required? A typical AFS implantation requires the following skills:
  • Information architect
  • Microsoft® SQL Server™ developers
  • Microsoft® Visual Basic® or Microsoft Visual C++® COM developers
  • Web/ASP developers
  • XML/XSLT developers
  • Commerce Server developer and administrator
  • BizTalk Server developer and administrator
  • Advanced Microsoft® Windows® IT resources for deployment
  • Backup operators
• What is the deployment environment? Does the customer have the infrastructure and IT organization required to deploy and support this system?
• How much staff does the customer have to support this effort?
• What are the classification needs for the stock-keeping unit (SKU) number set? Does the catalog structure need to be redefined?
• Do you need high availability? How much exactly? Most organizations require 24/7, but how much downtime is acceptable per year or per week? Will you require a hot backup for instant switchover? Or is a warm backup with a 10 or 15-minute switch over time acceptable?
• What are the scalability and performance goals?
• How many simultaneous users do you need to support? Most business-to-business (B2B) implementations do not require supporting a high number of users.
• What is the longest acceptable response time during a remote shopping session? What is the desired average response time? Studies show that most users lose patience after 10 to 30 seconds.
• How many purchase orders per minute will need to be processed?
• How many SKUs are there in the catalog(s) to be published? Although the Commerce Server 2002 Product Catalog System was tested with one million SKUs, AFS runs into various constraints between 30,000 and 60, 000 SKUs. Depending on factors such as available memory and the richness of your catalog schema, your results may vary. If you are considering publishing catalogs in excess of 10,000 SKUs, you should consider dividing the catalog into multiple, smaller catalogs in order to keep such problems more manageable.
• What are the maximum limits on the size of catalogs that the relevant trading partners can process? Sometimes these limits will be smaller than your publishing process can produce.
• What are the reporting and monitoring needs? Commerce Server includes a data warehouse, but you will probably need to adjust which fields are tracked, and you may need to build custom reports.
• What are the user experience requirements, such as branding and image? During a remote shopping session, you can use the opportunity to brand your site, your services, and your products. You can also do up-selling and cross-selling.

Message Standard Selection Questions

• What standard(s) are current trading partners using?

  Out-of-the-box, AFS supports the cXML 1.1, cXML 1.2, SAP XML, and xCBL 3.0 standards. These message standards are widely used and have a horizontal market focus. Since several key messages in these standards are already implemented and tested, they should be employed wherever possible.

  Since AFS is based on BizTalk Server, you can add support for whatever messaging standard you may need. This could include vertical industry standards like RosettatNet (http://www.rosettanet.org/) and HIPAA (http://cms.hhs.gov/hipaa/), or an older and more established standard such as EDIFACT.

• What standard(s) are future trading partners likely to use?
• What are the characteristics of the standards you are considering, and how well do they match your needs?
• How broad is the market coverage of the standard? The cXML standard is widely used, and is the standard used by Ariba and Clarus. The xCBL standard is used by CommerceOne.
• Does the standard support all the message types that your customer requires? For example, does it support advance shipping notices or invoices? The xCBL standard is considerably more complete than the cXML standard in this regard. The xCBL standard is based on EDI, which is apparent not only by its relative degree of completeness, but also by its relative complexity.
• Do the messages in the standard(s) you are considering contain all the required information, such as detailed buyer, payment, and shipping information? Again, the xCBL standard is more complete than the cXML standard.
• For standards not based on XML, can your system and infrastructure support the standard?
• For standards other than xCBL and cXML, does the standard authoring organization provide good documentation and support? Will they provide for validation and testing of your implementation? Do they enforce the standard? Do they continue to improve it?

  Both the xCBL and cXML standards are evolving and are well-supported by their parent organizations.

• Do you have access to the other application you will be trading with, such as a procurement application? If not, is a testing and validation service available? This can be a major problem and it should not be underestimated. Plan to begin testing early, and get a written commitment from the other organizations. Allow for plenty of testing time in your schedule, as you may not have control of the other half of the testing equation.

Business Process Questions

• Will you use Commerce Server as your catalog system? If yes, the development effort will be greatly reduced as AFS has already implemented this for you. Alternative implementations may use an existing catalog from an ERP or similar system.
• If you are using Commerce Server, is the basic content management functionality it provides adequate for your needs? Will you need to use a more sophisticated content management system such as Microsoft Content Management Server?
• If you will use another system for your catalog, how much effort will be required to integrate it with AFS? You will need to change all the catalog-related BizTalk maps and source document specifications.
• If you intend to import catalogs into Commerce Server, they must be in either XML or CSV format. How will you get your catalog data into the right format? Many implementations use Microsoft Excel to generate a CSV file, or a combination of SQL and XSLT to extract a catalog from a database and transform it into the proper format.
• If your content is maintained somewhere else, should you implement an automated catalog import system?
• Do you need to support electronic catalog publishing? In most cases, the answer is yes. But there are some remote shopping scenarios where only a description of the catalog and the remote shopping URL are sent to the trading partner.
• Do you need to support remote shopping? It will require more effort to implement, but it does offer the following potential advantages:
  • Supplier branding
  • Personalized shopping pages
  • Up-sell and cross-sell capabilities
  • Tracking detailed buyer information
  • Custom and dynamic pricing
  • Provides the buyer with more detailed information
  • Provides custom configuration of complex products
  • Reduces the size of the catalogs uploaded to the trading partner
• If you are going to include remote shopping functionality, how will the remote shopping functionality in AFS be used? The answer depends on the nature of the Web site already in use by the supplier, if any.

  If the supplier is already using an e-commerce Web site based on either the Retail or Supplier Solution Site, integrating remote shopping functionality from the AFS Solution Site should be straightforward.

  If the supplier does not yet have an e-commerce Web site, or wants to start from scratch in creating one, the AFS Solution Site should be used as the starting point.

  If the supplier has an e-commerce Web site that is not based on a Commerce Server Solution Site, integrating remote shopping functionality will not be as easy. You will need to study the remote shopping code that was added to the Solution Site code base, and then make similar additions to the existing Web site.

• Do you need to support the reception of electronic purchase orders? In most cases, the answer is yes. AFS supports purchase order reception via HTTP post operations, and then uses BizTalk Server to convert these purchase orders to the native Commerce Server XML format for further processing.
• Do you need to support the reception of purchase orders using a transport mechanism other than HTTP, such as FTP, SMTP, or Message Queue?
• If you intend to integrate purchase order reception with existing business systems, you will need to decide whether to integrate with BizTalk orchestration or with Commerce Server pipelines, as both offer reasonable integration points.
• Because AFS does not handle shipping or invoicing of received orders, you must implement a custom solution for this functionality or integrate with existing systems that can handle these processes.
• Which type of purchase order acknowledgement is expected by the relevant trading partners? AFS uses different solutions for the xCBL and cXML standards, and your needs may vary.

Implementation Cost and Time

Based on the answers to the previous questions, you can now perform a cost and time analysis. In the course of this task, consider the following:

• Does the cost or time of implementation make any of these standards prohibitive to implement?
• Can you postpone one or more implementations to a future version?
• Should you start by implementing one standard first, and then benefit from the experienced gained when implementing subsequent standards?

Identifying and Managing Risk

There are a number of different types of risks associated with an MSSE project, particularly when it involves multiple trading partners using heterogeneous systems. You need to identify, analyze, plan for, track, and control such risks. The relevant risks can be categorized as follows, and characterized by the questions associated with each category:

• Technical risks. Do you have a good understanding of the new technologies being used? Have you prototyped and tested all the technical unknowns?
• Integration risks. Do your trading partners have well-documented interfaces and protocols? Will they provide technical and validation support? Will they be responsive to your questions and needs? This is a significant risk, and one that is difficult to manage because you are dependent on another organization. Allow plenty of time in your schedule to mitigate this risk factor.
• Security risks. Have you considered all the data and infrastructure security measures that will be required to adequately protect the customer? Are there any questionable areas that require specific proof-of-concept testing or analysis by a third-party security expert?
• Schedule risks. Is the delivery date inflexible? Do you adequately understand the development effort required? Can you adjust the scope or resources if you cannot adjust the schedule? The effort required for integration with other organizations and applications is difficult to gauge accurately, so be conservative with these aspects of the project schedule. Also, be careful to not underestimate the learning curve required by technologies such as Commerce Server, BizTalk Server, cXML, xCBL, and so on. In particular, learning and understanding a new XML standard can be quite challenging.
• Budget risks. Is there sufficient funding to bring this project to completion? Is the budget so tight that any unexpected problems or delays will put the project in jeopardy?
• Business risks. Is this project crucial to the survival of the organization? If so, does it have the appropriate level of support from all interested parties? Would a failure of this project put the organization at risk? Would a poor implementation put the organization and its reputation at risk?

All of these risks can be managed, but the more risks that exist, the more risk management effort is required. On the other hand, not managing them will likely end up costing more. To help you identify all of the above risks, you should leverage the test team during the planning phase. They should be well versed in risk analysis and management techniques. You should also make sure that the risks are well understood by all relevant parties, and try to ensure that those parties will constructively participate in solving problems associated with risks that have occurred.

Development

The deliverables of the development phase are as follows:

• Frozen functional specification. At the end of this phase, the functional specification should be frozen and synchronized with the implementation and the final test plan.
• Risk management plan. The risk management plan should be updated with the latest information and data. Some items may justify a higher priority in testing.
• Source code and executables. The source code and executables should be in a source code database, such as Microsoft® Visual SourceSafe®, from which it can be installed by the test team on a clean server or set of servers.
• Test specification and test cases. The test plan should be completed and reviewed before the test passes begins.
• Master project plan and master project schedule. These two documents should be updated with the latest data and they should be distributed to key project personnel.

The developing phase ends with the scope complete milestone. At this milestone, all features are complete and the product is ready for external testing and stabilization. This milestone is the opportunity for customers, end users, operations and support personnel, and other key personnel to evaluate the product and identify any remaining issues that need to be addressed before the product is released.

Development Phase Tasks by Role

The following tasks, organized by role, are performed during the development phase.

Program Manager

• Continually update the project schedule.
• Manage buffer times in order to meet the fixed-date schedule.

Product Manager

• Create an external release schedule.
• Communicate with the customer.

Development Lead

• Manage the development effort.
• Perform code reviews.
• Help make technical trade-offs and decisions.

Test Lead

• Lead creation of the test plan.
• Lead creation of test tools.
• Train testers on what needs to be tested.
• Manage test creation.
• Organize test case review.

User Education Lead

• Lead creation of product documentation.

Logistics Manager

• Create the deployment plan.
• Do capacity planning.
• Install product infrastructure.
• Implement daily build strategy.

Other Development Considerations

The following considerations are important to the development phase:

• How are you going to use the relevant functionality in Commerce Server as part of your solution? This functionality includes profiles, order processing components, database tables, catalog management functionality, and Commerce Server Business Desk.
• How are you going to use the relevant functionality in BizTalk Server as part of your solution? This functionality includes document transformation, transport facilities, and orchestration facilities.
• What is your daily build strategy? How will it incorporate baseline testing on a daily basis?
• If necessary, how will you develop a way to test your solution without ongoing access to a test facility maintained by the trading partner(s)? Can you devise a way to simulate the trading partner(s) so that you can decouple your ability to make progress from their ability to support your development efforts?
• In what ways will you need to extend the solution provided by AFS? AFS includes documentation that explains how to perform such extensions in the areas of supporting additional messages, extending Commerce Server analysis and reporting, integrating with back-end systems, and printing purchase orders.

Stabilization/Release

The deliverables of the stabilization/release phase are as follows:

• Golden release. A code base in which all critical bugs have been addressed.
• Release notes. An itemized list of known issues and work-arounds for the current release.
• Test results and testing tools. A summary of test results and, ideally, the test tools. These test results should include functionality and performance test results for the major feature areas while the site is under a load that represents average or peak usage. In addition to the test results, the test scripts and load generation scripts should be included in this deliverable. These test results will serve as a baseline. All future development and configuration updates should be precluded by running these functionality and performance tests to ensure that the functionality and performance is maintained or exceeded. This defines the release criteria that must be met before releasing the product to production. Performance test results for the MSSE, which were run while the solution was under stress generated by the Microsoft Web Application Stress Tool, are included in the MSSE Architecture Guide. Results of this type of performance testing may vary depending on the hardware configuration and implementation details of each MSSE deployment.
• Source code and executables. An installable program that reflects the debugged source code.
• Project documents. Updated versions of the various project documents: Vision/Scope, Functional Specification, Project Plan, Risk Plan, Test Plan, and so on.
• Milestone review. A post-mortem of both the successful and unsuccessful aspects of the project. This can be a very useful exercise when done immediately after product release and deployment.

The stabilization/release phase ends with the release milestone. At this milestone, the team has addressed all outstanding issues and has either shipped the product or placed it into service.

At the release milestone, responsibility for ongoing management and support of the product officially transfers from the project team to the operations and support teams. For information on operational prescriptions for AFS, see the "MSSE Operations Guide."

Stabilization/Release Phase Tasks by Role

The following tasks, organized by role, are performed during the stabilization/release phase.

Program Manager

• Drive bug fixing to completion.
• Hand off Release deliverables to Microsoft Product Support Services to be audited for supportability.

Product Manager

• Manage customer sign-off.

Development Lead

• Lead development team in fixing bugs.
• Resolve technical issues as they occur.

Test Lead

• Drive testing of product.
• Manage bug fix trade-offs, as dictated by the project goals and trade-off matrix.
• Help determine fixes to be deferred to a future release.
• Determine project completion and sign-off.

User Education Lead

• Lead finalization of all documentation.

Logistics Manager

• Deploy finished product.
• Turn over operations to the operations team.

Live Testing

One of the final aspects of testing an MSSE solution should be "live" testing with the relevant trading partners. Before opening the solution to general use, the catalogs should be published to all of the trading partners, and dummy orders placed through the actual e-procurement applications that the end users will use.

Microsoft Product Support Services (PSS) Release Audit

Many of the Release deliverables should also be delivered to PSS to be audited for supportability. Depending on the complexity and customization of the solution, this may include an on-site visit to review the custom code and implementation details. The Release Audit deliverables include the custom code developed, functional specifications, design specifications and deployment specifications. If significant changes are made to the solution after release, another PSS Release Audit may be required. The more informed PSS is about the implementation, the better equipped they will be at supporting the solution in production.

Release Criteria

Depending on the scope of your MSSE solution, the items in the release criteria list will vary, but will generally include the live testing of all implemented functionality and performance criteria. For example, verifying that a catalog can be published, products can be chosen through the relevant buyer applications supported by the trading partner(s), and the corresponding orders can be received and processed. When remote shopping is implemented, all relevant scenarios must work as expected, and result in the reception of orders by the supplier.

URL Resources

Microsoft Solutions Framework:

http://www.microsoft.com/business/services/mcsmsf.asp

Microsoft Web Application Stress Tool:

http://homer.rte.microsoft.com/

Microsoft Solution for Supplier Enablement:

http://www.microsoft.com/business/solutions/MSSE/