Chapter 2   Planning the Upgrade


This chapter describes how to plan the upgrade from a BuyerXpert 3.x instance to a BuyerXpert 4.x instance using the Upgrade utility.

This chapter contains the following sections:

• Establishing an Upgrade Team

• Analyzing the Buying Environment

• Planning the Organizational Hierarchy

• Writing an Upgrade Plan

Establishing an Upgrade Team

---

To plan for the upgrade process, you should create an upgrade team that consists of the following members:

• BuyerXpert technical expert

• LDAP expert

• Oracle expert (DBA)

• Business expert

BuyerXpert Technical Expert

This person must be experienced in installing, configuring, and maintaining the existing BuyerXpert 3.x instances, understand the resources set at the organization and user level, and understand the Import utility. The technical expert can be from professional services or can be a BuyerXpert administrator.

The technical expert should be able to replicate the approval processes in the procs.seed setup in BuyerXpert 3.x to BuyerXpert 4.x. The technical expert is also responsible for completing post migration tasks and manually migrating customizations lost in the automated data migration.

LDAP Expert

This person must be familiar with LDAP server handling and support, because BuyerXpert 4.x uses LDAP to store the membership details. In BuyerXpert 3.x, membership data is stored in an Oracle database. The Upgrade utility transfers data from Oracle to LDAP if the LDAP schema or the directory structure in LDAP is available. The LDAP organization structure varies between organizations, so the LDAP expert must know how to structure with the BuyerXpert system.

Oracle Expert (DBA)

Even though both versions of BuyerXpert use Oracle as a native database, BuyerXpert 4.0 has schema changes and new features. The Oracle expert should be able to create the database environment with the basic BuyerXpert requirements. Expected expertise for this person is a DBA level.

Business Expert

This person works with BuyerXpert core member to fill the gap after the data migration as the rules cannot be matched one to one between both the BuyerXpert versions. Helping in setting up rules for the users and the organization is the primary task of the business expert. The business expert is responsible for designing the multi-organizational system and give assisting the LDAP expert in setting up the directory structure.

Analyzing the Buying Environment

---

To develop an upgrade plan, you need to calculate the average time it takes your buyer organization to approve a requisition and submit it as an order. You can use your average submission/approval time for a requisition to plan how far in advance your buyer organization must stop submitting new requisitions. This allows you to minimize the number of requisitions that are still pending approval on your planned data migration date.

After migrating your data, you must resubmit any requisitions that are pending approval. You should minimize the number of pending requisitions before migrating your data to reduce the number of post migration tasks.

Establishing a Cut-off Date for New Orders

It is important that you establish a clear cut-off date for creating new orders.

For example, if your average approval process takes four days for 85% of the requisitions, the cut-off date should be at least four business days before your migration date. If you can increase this time period without disrupting your business, it is recommended.

Planning the Organizational Hierarchy

---

Before you can migrate data to BuyerXpert 4.x, you must first determine whether or not your e-Procurement system will be multi-organizational. If so, you must define the membership structure within each organization.

There are two main areas to consider when making the multi-organizational decision:

• Current BuyerXpert 3.x system

• Planned BuyerXpert 4.x. system

You must consider both environments before determining your upgrade strategy and deciding if your BuyerXpert 4.x system will be multi-organizational.

Current BuyerXpert 3.x System

You could have deployed your current BuyerXpert 3.x system in one of several ways:

1. One instance of BuyerXpert 3.x that represents a single organization.

2. Several instances of BuyerXpert 3.x, where each instance represents a separate organization.

3. Multiple instances of BuyerXpert 3.x, where each instance does not functionally represent a separate organization.
   

   ---

   Note	A single instance of BuyerXpert 4.x can accommodate all organizations within an enterprise. Therefore, all the upgrade scenarios addressed here contain only one instance of BuyerXpert 4.x.

   ---

   
   

Multi-Organizational Structure

Although the decision on whether or not to implement a multi-organizational structure in BuyerXpert 4.x is most likely determined by your existing BuyerXpert 3.x system configuration, you can change the organizational structure from its present configuration.

---

Note	Changing your existing BuyerXpert 3.x configuration is not recommended by iPlanet, nor is it fully supported by the Upgrade utility.

---

If you want to pursue this path, Table 2-1 outlines the characteristics, benefits, and limitations of a single versus a multi-organizational structure.

Table 2-1    BuyerXpert 3.x and 4.x Multi-Organizational Characteristics  (1 of 2)

Factor	3.x Characteristics	3.x Limitations	4.x Improvements	4.x Issues
Accounting and Commodity Codes	Each instance supports only one set of accounting and commodity codes.	Each unique set of commodity or accounting codes requires a separate instance of BuyerXpert 3.x	Each organization can maintain one set of accounting and commodity codes. Structure and values can vary per organization.	Each set of accounting and commodity codes are specific to an organization and cannot be shared. There will be duplication if you have a large amount of data overlap in the codes, and you will need to maintain each organization separately.
Business Rules	Each instance supports only one set of business rules at the organizational level.	If you want several sets of rules at the organizational level, you need to install several instances of BuyerXpert 3.x.	Multi-organizational structure supports one set of rules at the organizational level. These rules can be inherited from the root organization or defined separately at the individual organizational level.	A higher complexity in rules needs to be maintained.
Approval Processes	Only one set of approval processes can be maintained for each BuyerXpert instance.	There is no possible separation of approval processes within one instance of BuyerXpert 3.x.	Approval processes are owned at the organizational level. A multi-organizational structure allows each organization to have its own approval processes, which would be distinctly separated from any other organizations.	The creation of a multi-organizational structure within an enterprise that has no need for separate approval processes creates a situation with data duplication and maintenance.

Defining the Membership Structure

You should also plan the remainder of the membership hierarchy, from organization down, at this time. Refer to the BuyerXpert Administrator's Guide for instructions about how to define the membership structure.

Writing an Upgrade Plan

---

The upgrade team should develop an overall plan for their BuyerXpert upgrade. This plan varies for different organizations, and should be based on, but not limited to, the following factors:

• Life cycle of the average purchase requisition

• Size and complexity of the current BuyerXpert 3.x stem

• Size and complexity of the upgraded BuyerXpert 4.x system

• Overall strategy for the upgrade process

• Functionality of a multi-organizational structure and any relevant implications

• Functionality of the Upgrade utility and any relevant implications

The upgrade plan concludes with a go live date, at which time the staging system becomes the production environment.

The upgrade plan must be communicated to those involved in the buying process so that they are aware of key dates, such as the cutoff date for the creation of new purchase requisitions.