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:

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:

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:

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:

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:

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:

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:

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:

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:

Development

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

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:

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:

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:

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

Resource Risks

Scope Risks

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

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

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.

Project Phase Milestone Description
Vision / Scope 1 Vision/scope approved
Planning 2 Project plan approved
Development 3 Supplier catalog architecture complete and tested
Development 4 Catalog publication to all trading partners complete and tested
Development 5 Order reception from all trading partners complete and tested
Development 6 Remote shopping implementation for all trading partners complete and tested
Development 7 Code complete
Stabilization / Release 8 Zero bug bounce (ZBB)
Stabilization / Release 9 Final code deployed into production
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

Assessment of Existing Business Processes

Assessment of Trading Partners

Assessment of Planned Market Differentiators

Planning

The deliverables of the planning phase are as follows:

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

Product Manager

Development Lead

Test Lead

User Education Lead

Logistics Manager

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

Message Standard Selection Questions

Business Process Questions

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:

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:

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:

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

Product Manager

Development Lead

Test Lead

User Education Lead

Logistics Manager

Other Development Considerations

The following considerations are important to the development phase:

Stabilization/Release

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

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

Product Manager

Development Lead

Test Lead

User Education Lead

Logistics Manager

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/