IEEE Business Management System (BMS) Business Entity...

IEEE Business Management System (BMS)

& Business Entity System (BES)

Background Paper

Prepared for Information Technology Strategy Committee (ITSC)

By IEEE Information Technology Staff

Date July 02, 2004

Version 1.0

of 23 BMS_BES ITSC Background Paper Vx.doc

ITSC BMS/BES Document Sequence Introduction I. BMS Project

• Overall Scope • Current Challenges that BMS addresses • Current Legacy ICSS Background and Evolution • Current Technology and future trends/plans • Current State of Project and Project Approaches • Current Project Cost Estimates and Timelines

II. BES Project

• Overall Scope • Current Challenges that BES addresses • Current Legacy System Background and Evolution • Current Technology and future trends/plans • Current State of Project and Project Approaches • Current Project Cost Estimates and Timelines

III. Potential BMS and BES linkages

• Business Case Comparison • Processes and Business Rules Comparison • Project/Component Comparisons (Modules, Scope) • Technical Components

IV. Combined BES/BMS Risk Factors

• Customer and Member Satisfaction • Operational Costs • Customer/Member Service Costs • Growth Inhibition • Technology Costs • IT Resource Costs

V. BMS/BES Shared Timelines, Shared Costs

• To be developed later in 2004 during BMS RFP evaluation Appendix A – Acronyms Appendix B – Project Methodology and Approach


Introduction The purpose of this document is to provide a high level overview of IEEE’s membership system also known as the IEEE Customer Service System or “ICSS” and provide more insight on two new initiatives underway – the IEEE BMS and IEEE BES projects. The document describes the ICSS system at a high level and explains what business functions it currently supports, and highlights some of the limitations of this system. The document also provides historical perspective on what has been done so far in keeping up with the changing business needs.

I. Business Management System (BMS) Project BMS Project Scope The BMS Project’s first phase is the upgrading and/or replacement of the current IEEE Customer Service System (ICSS) – also known as “The Membership System”. The business scope of Phase 1 for this project encompasses:

• Management of Member Information – Store and maintain member information such as customer address, email address, TIP codes and other opt-in opt-out preferences. It also maintains historical information such as grade histories.

• Management of Subscription and membership – Manage execution of new Applications and Renewal of Membership Societies and Publications

• Management of Product definition Maintain and manage product definitions, pricing related to society memberships and subscriptions

• Fulfillment of Publications – Generate labels (List management) for paper fulfillment of subscriptions

• Provide support to other IEEE specific processes and other financial/ancillary services

Current Challenges that BMS addresses Some of the limitations with the current ICSS system are reflected in the ten Vision/Problem Statements developed as part of the Requirements Gathering process of BMS in the Spring 2004.

• Current technology stack is outdated and is now de-supported by software and hardware vendors for the Membership, List Management, Statistics, Accounts Receivable functions.

• Inability to capture, integrate and make available relevant and complete customer information (no single unified view of a customer).

• Inability to support different market segments and customer types.


• Inability to classify and segment customer based on different criteria including customer preferences that can be used to recommend the most likely IEEE Offerings, Products and Services.

• Current business processes and ICSS system is membership and subscription driven.

• Inability to keep complete customer profile/transaction history, and inability to purge or archive old/irrelevant data..

• Current system is not flexible in supporting the new many-to-many Product and Offering relationships.

• The current system is not making full use of Web-based technologies. • Inability to normalize customer and product/offering data and inability to

(Create/read/Update/delete) across different applications and restrictions on data flows between them – real time or otherwise.

The above mentioned limitations have evolved into a high-level set of BMS features that include:

• Unified View of the Customer and Member • Authoritative repository for all IEEE Offerings, Products, and Services • Flexible framework for creating new Offerings, Promotions, and Pricing • Data-driven model of defining and enforcing business rules and policies • Integration of both individuals/members, and their relationship with IEEE Entities

and outside Businesses. • A generic Order Fulfillment engine that would consistently process payments and

initiate fulfillment processes. • System Architecture that is maintainable, agile, and cost-effective in the volatile

environment that the IEEE exists. • Information availability within the IEEE organization where and when it is

needed (“Federated Model”). Since Phase 1 of BMS will minimally support the equivalent functions which ICSS supports today, the following three sections describe the background ICSS functions, its evolution, and technical platforms/components. ICSS Background Our current ICSS (IEEE Customer Service System) system’s primary purpose is sustaining Membership information, their Memberships/Subscriptions, and the services that the IEEE offers to this market. This is accomplished by ICSS having four major functional areas:

• Member Information and Maintenance – o Recording of individual’s personal information, as well as IEEE Member

information such as Grade, Societies, and other IEEE-specific history


o New Member Applications and Renewal processes – some of which are Web-enabled and follow a self-service model.

o Back-end integration with Oracle Financial Systems.

• Product/Subscription/Membership Information – o The source for some, but not all of IEEE Offerings, Products, and

Services. o Not included are certain Web-services, Conferences, Society-level

offerings, and Meetings.

• Subscription Fulfillment – o Maintains Subscriptions for Members (and Non-Members) o Executes processes for producing mailings of publications by various

printers and distributors.

• Ancillary Processes – This includes specific processes such as: o List Sales o Membership Statistics o Balloting o Circulation/Business Publication Audit (BPA) o Publication/society conversions o Other IEEE-specific functions that are typically unique to the IEEE, and in

most cases, far surpass other non-profit societies in terms of sheer complexity and/or volumes.

The above four areas comprise the functional scope of Phase 1 of BMS as defined by the current ICSS system environment. However, the ICSS system interfaces directly or indirectly with over 25 other systems. Some examples are:

• Business Objects – Staff and Volunteer’s access to ICSS data • Lightweight Directory Access Protocol (LDAP) Directory – Web access to

applications and services • Oracle Financials – Tax calculations and reconciliations of revenue recognition • Society Data feeds – To Computer and Communication Society • Lotus notes applications - Work-flow and Customer Relationship Management

(CRM) In phase I of our BMS project, the focus will be on redesigning the ICSS system’s current functionality and integrating it with other systems mentioned above. If a vendor of choice provides any of those functionalities along with ICSS functionalities, a decision would be made on case–by-case basis to bring that business functionality within the scope of Phase I. Our goal will be to understand the priorities of any new key business functions and ensure they are implemented with the appropriate timing. The next section highlights the evolution of ICSS, and some of the improvements that have been implemented over the years. This will give the reader an appreciation of the


enhancements that have been made to the system over the past 10 years and what the current challenges are. ICSS Evolution In 1994, the mainframe-based Membership system was replaced by a client-server architecture utilizing Oracle Financial modules, plus custom developed modules for Membership, Subscriptions, and List Management. Its primary focus was in defining customers and products in terms of Members, and was not geared toward non-member markets such as Corporations, Libraries, and other market segments. 1998 - An entire suite of Web-based applications (Renewal on the Web, New Membership Application, Web Account Registration, etc.) were developed and they continue to be used by both Members and Staff in updating Member and Subscription information. This Web-based front-end is still substantially usable in its current form in future Architectural evaluations. 1997-2003 – Web-based services/products such as Xplore, Email Alias, Entity Web Hosting, IEEE Electronic Store, electronic Article Sales, and “What’s New” newsletter services were launched. Early in this period, there were no common tools or building blocks to standardize these processes. As a consequence, system and data integration was not easy. Many of these systems and processes remain inconsistent and un-integrated to provide “instant service”, as well as not being known, serviced, or tracked through the ICSS system. 2000 - 2003 - Much of the technology continued to be leveraged in the area of Membership workflow and supporting back-office systems. Scanning, Lotus Group Mail, Data Access, and Sales Force Automation, are examples of systems that directly or indirectly interacted with the ICSS system. Integration varies by each system, but still are key components in supporting current efficiency levels and process improvements 2003 -The most significant system-based/enabling work for the BMS project was the de-coupling of the Oracle Financial Modules from the Membership system. This allowed the Financial Systems to be upgraded to supported software package release levels, without the retrofitting of modifications that remain in the ICCS Membership system. The most immediate application benefits of the de-coupling were upgrading of existing Oracle Financial modules, as well as the start of the Business Entity System (BES) system project using new Oracle modules such as Customer On-Line. 2003-2004 – Oracle, HP, and other vendors announced the de-support of various components of the Membership System that continues to process the majority of IEEE business transactions. This requires that the IEEE upgrade or replace the core ICSS Membership applications. At present a short-term migration/port to a supportable operating level is underway. This migration adds new functionality, (for example, browser-based user interface and enhanced security features), and provides a suitable platform/systems environment which will support our needs between now and our future BMS implementation.


1995-2004 – Divergence of Non-Member Systems processes from ICSS-based systems. The ICSS system was geared toward Memberships, Annual billing, and rules that were based on Members. During this same period, substantial growth in non-Member businesses and products (ASPP, IEL, other packages both electronic and hard-copy) required work-around processes to ICSS limitations in non-member contract renewal operations. In response to this worsening situation, the BES (Business Entity System) Project was launched in 2003 to introduce an equivalent ICSS system that would serve non-member customers. The potential relationship of BES to the BMS project is in a later section.


ICSS Technology stack and integration points In summary, the view below represents the building blocks of ICSS currently with functionality, technology, and major system integration points. The functionality will be improved and/or enhanced based on the features that have been articulated in the previous BMS Feature set. Specific features will be based on feasibility, priority, and the timing that the business needs in order to service the Members and supporting operation. The Technical Layer will be upgraded based on the concepts of re-usability of existing technologies and components. The specific technical solutions proposed by Vendors will be the other major variable in assessing changes or additions to the technical foundation. The System Integration Layer will be maintained to support the entire landscape of related IEEE systems that require information from the existing and new Membership system. Where possible, integration will be maintained with the minimum of changes in order to avoid “scope creep” in the Phase I implementation of the BMS system.

ICSS System

Supporting Technology Stack

Oracle AccountsReceivalble 10.7

Oracle RelationalDatabase 7.3.4

HP 10.2 OS/HP570

Other SupportInfrastructure,

Software

Add ServiceAnnual RenewalsCustomer Profile

Product Management

Business Processes Supported

Billing, Invoicing, and TaxCustomer Correspondence

Managing Organizational UnitsSingle Sales Pricing and Promotion

OracleForms 2.4

LabelGeneratio

n/ListManagem

ent

Stats andAudit

Reports

SocietyExtracts

DataWarehou

se andData

Extracts

Replications to

OracleLDAP

Databases

WebApplicatio

ns

Major ICSS Application Integration Points

OracleFinancials

11i


IEEE BMS The IEEE BMS is a strategic initiative to support and manage IEEE‘s individual entity customers. The customer definition is much broader than the current membership definition however it is felt that there are unique differences on how IEEE conducts business between individuals and corporations. Although we need a view that integrates a common customer view of both the individual and non-individual customer, it is not certain at this point if they both need to be in one central system. This determination/assessment will occur during the BMS design recommendations. Please refer to Section III where these two entities are compared and contrasted. Current State of BMS Project An internal Stakeholder team and supporting set of three BMS sub-teams were formed in 2003 to define the replacement system for the ICSS Membership System. The primary milestones (completion dates) have occurred or are planned:

• Vision Statement May 2004 • Requirements Development July, 2004 • Requirement Buy-In by Stakeholders August, 2004 • RFP Process Sept, 2004 • Short List of Vendors, Project Approach Oct, 2004 • Operational Plan, Proposal for Funding Nov, 2004 • Approval to Proceed. Dec, 2004

The cross departmental team from IEEE and societies are working on defining our requirements document. Senior Management has been socializing this project with key stakeholders and volunteers. The Information Technology Strategy Committee (ITSC) will be assisting with the vision, strategy and requirements buy-in from stakeholders. Concurrently, several options in terms of identifying solutions are being considered. These solutions include factors such as system selection, funding, and integration with existing systems and the parallel BES system. The general approaches are:

1. Evolutionary approach with existing Architecture and custom-developed Membership Functions.

2. Leverage Oracle’s “Trading Community Architecture” (TCA) with additional

modules that will perform the majority of new Membership BMS requirements.

3. Look for a robust Membership Package that can integrate with Oracle Financials, non-Member databases, and residual ancillary systems.


The above approaches represent the generally anticipated choices that will evolve out of the RFP process. Internal, Oracle, and other outside vendors will be part of this discovery, proposal, and negotiation phase. BMS Project Costs Refer to BMS New Initiative documents. Current Timelines Currently timelines are focused on requirements definition/buyin and solution option definition through the end of 2004. However, it is anticipated that the implementation will be multi-phased, multi-year, based upon priorities of business needs. It will also be influenced by any constraints in terms of priorities, features, resources, and changing business needs. More detail will be available after RFP selection, approach, and Operational Plan and supporting budgets are developed.


II. Business Entity Project (BES)

BES - Overall Scope The Business Entity System Project (BES) is the new Strategic System that will support our current Non-Individual Customers such as Corporations, Libraries, and Institutions. The business scope of Phase 1 and 2 (these phases are funded) of the BES project encompasses:

• Integration of Sales Force Automation processes. • Management of Customer Information • Execution of Contracts, renewal, and servicing • Fulfillment of Electronic Contracts (via Xplore) • Providing support to other IEEE specific processes and other financial/ancillary

services The ICSS Evolution discussion in the previous BMS section highlighted some of the gaps in the Membership system in handling Non-Member Customer products, processes, rules, and terms/conditions. One example is the ability to support Anniversary billing versus the annual renewal process that Membership employs at this time. Based on ICSS self-imposed limitations by being member/subscription oriented, as well as the growth and nature of the Non-Member IEEE business, new Vision and Requirements for the BES system were developed. Some of the vision/requirements/features of BES (Phases 1-3):

• Capabilities of having multiple views of Customers, and multiple Hierarchies • Integration of Sales Force Automation systems/processes with BES system. • Ability for flexible Contract terms, pricing, and billing arrangements • Streamlined Contract Renewal process • Where necessary, to have ability to fulfill electronic products in real-time. • Authoritative repository for all IEEE Offerings, Products, and Services • Flexible framework for creating new Offerings, Promotions, and Pricing • Data-driven model of defining and enforcing business rules and policies • Integration of both individuals/members, and their relationship with IEEE Entities

and outside Businesses. • If necessary, to integrate or replace print fulfillment processes for subscriptions

shared between Non-Members (BES) and Members (BMS/ICSS) • System Architecture that is maintainable, agile, and cost-effective in the volatile

environment that the IEEE exists. While many of these features are identical in wording to BMS, their business rules, implementations and detailed requirements are , in some ways, very different ICSS Functions and Relationship to BES


At present, the Non-Member operations area uses ICSS primarily for the fulfillment of hard copy packages and individual subscriptions sold to non-members. Individual subscriptions are based on the Annual Membership cycle, since the business rules only function with the one option. For packaged products that involve hard copy (hard copy or combination packages), the print portion of the product uses ICSS for Fulfillment as well. Again, Annual billing is the only option supported by ICSS. Electronic products only (IEL, ASPP Electronic only, POP Electronic only, etc.) do not use ICSS, since there are no hard copy requirements that need the ICSS fulfillment functions. At present, the Electronic-only products have been entered into the standard Oracle financial Accounts Receivable for billing purposes, and contracts have been tracked using Excel spreadsheets. This growing manual effort, along with other Business Drivers provided the incentive for creating the BES Project, whose evolution is discussed in the next sections. BES/Non-Member Evolution In the last few years, electronic-only sales have grown and resultant manual contract processes, servicing, and sales efforts have added additional costs and reduced efficiency. In response to this trend, the Business Entity System Project (BES) was launched in late 2003 with early funding for new Oracle modules being provided by the New Initiative Committee.


Planned BES Technology and Trends The center box represents the technology stack. Normal Business Processes are listed on the left, and the interaction with the other systems are represented with the white arrows.

Planned BES Technology and Trends The layered diagram below depicts the major functions, technology, and integration points that are the foundation of the BES project being implemented starting with Phase 1 in 4th Quarter, 2004.

BES

Supporting Technology Stack

Oracle ERPModules 11i

Oracle RelationalDatabase 9.02 Sun OS 5.9/1280's

Other SupportInfrastructure,

Software (Notrix,9IAS)

Add ContractsAnnual Contract Renewals

Sales Commissions TrackingPackage/Offering Management

Business Processes Supported

Billing, Invoicing, and TaxCustomer Service/Activation

Consortia and Customer HierarchiesThird Party/Agency Processing

OracleWeb

EnabledUI

Ad HocReporting

SalesForce

Automation

(Notrix)

DataWarehou

se andData

Extracts

ICSS(9IAS)

Major BES Application Integration Points

OracleFinancials

11i

• Lotus Notes Maximizer - Sales Force Automation application. • Notrix - Data synchronization tool between Sales Force information and Oracle

modules. • 9IAS - Data synchronization tool between Non-Member Contracts and Print

Fulfillment in ICSS. The primary new components that deliver necessary functionality through the 11i Oracle system are the new three modules purchased in late 2003:

• Data Librarian • Contract Management



• Customer OnLine These three modules, in conjunction with the current 11i Oracle Financial Modules (Accounts Receivable, General Ledger, etc.), will provide additional capabilities that are necessary in the growing number of electronic products/packages being configured/offered to various non-member market segments (Enterprise, BMS, other planned products). The technology stack for BES will be at the current levels, and is the target level for BMS to achieve in late 2004, or early 2005. Current State of BES Project and Project Approach Oracle modules are the base functionality integrated with the Maximizer Sales Force Automation system. Phase 1 and 2 are in-process with User and Technical Teams per timelines listed below. The current approach is to expand use of Oracle existing and new modules, and integrate common processes/modules where possible with the parallel BMS system project effort. Future Trends from an application viewpoint include releases by Oracle of modules/extensions that encompass:

• Subscription Orders • Subscription Fulfillment

These will be evaluated when available. The project methodology follows a gradual, phased migration of contracts which supports the overall strategies defined later in this document under BMS/BES Project Methodology and Approach. Current BES Timelines and Costs Timelines Initial deliverables included conversion of the following types of Non-Member Contracts:

Phase 1 Oct, 2004 IEL, Electronic Only, Domestic-only Phase 2 1Q, 2005 All other Electronic Only contracts Phase 3 2005 Integrate Sales History, Hierarchy Structures

2005 Additional use of Promotion, Advance Pricing 2005 Enhanced Renewal processing and integration 2005 Interface Print Product Fulfillment/Invoicing


Phase 4 2006 Customer Facing Self-Service Automated Electronic Fulfillment Interface Agency/3rd Party Renewals Streamline Enterprise, other higher-volume services Evaluate, potentially Integrate

Oracle/Maximizer CRM environments.

Costs Refer to BES New Initiative documents.


III. Potential BMS and BES Linkages The following series of tables compares and contrasts various aspects of these two projects, by comparing the markets they serve, the offerings they support, the business rules and processes. These comparisons will become the basis for evaluating at any commonality in implementations that might satisfy Vision and Features of either project. Evaluations will be conducted during the RFP/Vendor selection process. Grayed areas signify major differences in the quantity, nature, or complexity of the System comparisons. White areas are generally common, with relatively simple differentiators such as price.

Component BES/Non-Member BMS-Individual Notes

Customer Attributes # of Customers 2,000 400,000 Turnover per year 300 70,000

Customer interaction

Through Sales Channel and personal interaction

Self service and mass mails / emails

Nature of Customer Non individual entity Usually Hierarchical. –Individual Entity

Contact person Individual contact

Relate Employer to Member

Relate Member to Employer

Standard Attributes Standard Attributes Name, Address

Unique Non individual Atributes

Unique Member-specific attributes Geocodes, Grades, etc.

Organizational Unit Hierarchy Subsidiaries, Contacts

Offerings

Societies Not Offered Offered exclusive to Members Pubs Offered Offered shared Proceedings Offered Offered shared Standards Offered Offered shared Conferences Offered Offered shared Books, Single Sale Offered Offered shared Single Articles Offered Offered shared

IEL, ASPP, POP Packages Offered NA - Commercial Offering

Typical Customer Contract/Membership Range $5,000-$125,000 $140-$250

Very different processing and impact dynamics


Sales/Renewal Process Sales Force, some Telesales

Direct - via Web or Mail

Primarily Packages - Long sales cycle in Non-Member

Third Party, Agency Sales

Primarily Non-Member individual subscribers.

Terms and Conditions Quotes Negotiated Prices Standard Prices Specialized Setup

Membership Rules, Processes

NA - No Memberships (ITSO?) Complex

Customer qualification relatively simple.

Needs for workflow due to high volume Low (for now) High Organizational Unit assignments None-just territory

Complex - RAB, TAB

Web Offerings Alias, MDL, etc. No What's New, Web Account Offered Offered Enterprise Offered These attributes will be expanded, quantified (revenue, number of products, etc.) and judged on their priorities to each project. They will also be evaluated on the impact they may have on the customer, and any changes in terms of:

• Operations performance metrics • Processing/Service Costs • Business Simplification Opportunities.

Since BES will be using some of the modules that BMS could potentially employ, there will be working basis for a Proof-of-Concept as part of the RFP evaluation of the #2 approach of BMS mentioned in a previous section.


IV. Combined BMS/BES Risk Factors

The scope and discretionary capabilities of the envisioned system have significant potential impact to the IEEE. The quality of planning, system design, data integrity, quality of code, and testing methodologies are some of the key ingredients of any successful system that is introduced at the IEEE. The magnitude and consequences of introducing such changes are reflected in some of the impact areas described below. Operations Impact (Revenues and Costs are estimates) BMS - The impact of any substantial changes in the types of Memberships, Society offerings, and publication choices affect over 360,000 members, as well as Affiliates, Students, and Life Members. Transaction processing (renewals, new applications, publications, etc.) of $58.8 MM will also be at stake with any change in the Core Membership and ancillary systems such as Publication Fulfillment. BES – 2,000 customers, $60MM revenue BMS - Changes in the Membership model may lower or raise the number of Members, their method of communication, as well as the simplicity/complexity of dealing with Offerings and Services. Correspondingly, this may change the dynamics and methods of communicating with the IEEE through Member Services via phone, email, or other methods. BES – Impacts to Customer may be felt in the Sales Force and Customer Service BMS -- Anniversary versus Annual Subscriptions and Memberships would change the seasonality of renewal operations, temporary help, telecommuting, and workflow processes. Introduction of new/replacement publications, billing cycles, conversions, and outreaches to Members can be complex, and operational oversights could be costly or embarrassing. BES – Anniversary Billing is a stated goal of the Features, and does not introduce any changes. BMS -- Representation of these new Membership models, as well as the communication of changes to existing Members or new Prospects could be massive, and adjustments to supporting Web applications could be substantial. BES – No effect on current Customer base. Other new types of memberships for businesses would have an impact. BMS -- Changes in timings of Offerings or Renewals can have impact on vendors such as publication printers, renewal/billing providers, lock-box processors, shipping consolidators and order fulfillment vendors. Negotiated terms and changes to processes may be required.


BES – No major Effect Growth Constraint BMS – with current inflexible methods of configuring new offerings, promotions, and terms/conditions, the time-to-market and ability to compete in the marketplace is compromised. Current limitations also stifle innovation, experimentation, and effective value-propositions to different Member and prospect segments. BES – same effect Technology Costs - Optimization BMS – the ability to consolidate and optimize strategic tools and technology stacks will ultimately yield economies of scale, and greater efficiencies in terms of hardware, supporting infrastructure, system/administrative costs and application maintenance/upgrades. BES – same effect, and further benefits where BMS and BES might potentially share technologies and applications. BMS – finding packages that have maximum functionality built-in are most desired. Where possible, challenge business rules or processes to fit the model. If successful, application maintenance and responsiveness of IT and supporting operational Staff are enhanced. BES – same effect. Bottom line, the deployment of any of the new capabilities of BMS in Phase 1 will require careful Operational Analysis from a Systems, Staff, Partner/Vendor, and Customer/Individual viewpoint Impact on Governance Strategies BMS -- Depending on the kinds of changes to Membership and resultant Society implications, there may be time lags and critical path items in gaining approvals of required entities. These factors have to be factored into any timetables where Governance requests or implementation of rule changes are waiting for the BMS system to be implemented.


IV. Shared Project Timelines, Costs Too early in BMS life cycle to project any commonality of Costs, Resources, or Technology that could be shared with the current BES project.

Appendix A -- Acronyms Anniversary Billing – The billing of subscriptions based on any start date through the term of the subscription – also governed by the frequency/term of the publication. i.e., Feb 2004 – Jan 2005 (12 month). Annual Billing – the fixed, single-option billing of Subscriptions from Jan – Dec for all publications. Variations include pro-rating multiple subscriptions to co-terminate/synchronize to the next Jan – Dec billing/sub cycle. This is current model for Society and Publication offerings. AR – Oracle Financial’s Accounts Receivable Module BES – Business Entity System Project – Non-Member oriented project to support contract, fulfillment, service, and sales operations. BMS—Business Management System Project – Member oriented to support membership, fulfillment, services, volunteer, and governance requirements. Conversions, Publication – The periodic re-alignment, addition, or deletion of publication titles for individual Societies, Sister Societies, or bundles offerings – usually on an annual basis. CRM – Customer Relationship Management – typically, tools used in selling products by a Sales Force, either with field sales and/or telesales model. CRM can also have various degrees of Servicing, Up-selling, and Renewal components. Data Driven Model – the application of business rules based on tables/attributes, not programmatic techniques. Data Feeds, Society – the current practice of providing data to different Societies/organizations for local use – whether ultimately synchronized or not. Certain real-time access (such as Web Accounts) is currently in operation. De-Couple – System work that separated the older Membership system from the Newer Oracle Financial Modules (11i). Federated Model – The concept that data can be managed in a distributed and/or central mode, and made available to IEEE entities on an as-needed or scheduled basis. This can be actual data streams, or real-time access to data at other sites. Fulfillment, Subscription – the Part of the List Management system that produces “labels” for each publication for both Member and Non-Member subscriptions/packages. Timing is dependent on the publications, printers, and distributors/consolidators. HP – Hewlett-Packard – The current hardware platform used by ICSS. ICSS – IEEE Customer Service System – Current Membership System being replaced by Business Management System Project (BMS). LDAP – Lightweight Directory Access Protocol – the underlying technology for organization of Web Accounts, hierarchy, attributes, and authentication.


List Sales – The sale of various IEEE Member/Non-Member mailing lists to outside parties. Inclusion is subject to opt-in/opt-out preferences of the member/individual. Maximizer, Lotus Notes – A third party software package that runs under Lotus Notes used for Customer Relationship Management (CRM) for IEEE non-Member customers. Oracle Database – The underlying database that supports Oracle Financials 11i (9.02) and ICSS Membership (7.3.4). Oracle Database versions do not numerically equate to the Applications they support. This is a confusing subject, thanks to Oracle technology and marketing. Oracle Financials – Current Financial Modules such as General Ledger, Accounts Receivable, and Accounts Payable. Most current release is web-based 11i. Oracle TCA architecture – Oracle “Trading Community Architecture”. Consists of over twenty modules that can be mixed and matched to meet the structure and needs of most corporate businesses. TCA is the foundation for the non-member BES project. RAD – Regional Activities Departments TAD – Technical Activities Departments Thin-Client – Web-based client versus the older Oracle forms/text-based client model. Web-to-Primary – The bridge between the Web-based membership renewal/application system and the Oracle Financial System.


Appendix B – Project Methodology, Approach Methodology: Both BMS and BES projects use the concept of phased implementations and a rigorous requirements gathering phase in a total effort to “do it right”. As part of a phased approach, the scope of each release will be evolutionary, and build on base functionality of the major previous releases. For example, the initial functionality of importing purchase history for Conferences may be expanded for purchase history for Wiley as an interim release. This approach:

• Allows for minimum variables in expanding functionality. • Provides optimum environment for producing a Quality Product and robust,

manageable iterative test cycles. • Allows granularity in prioritizing the most important functions from a business

need perspective. Phasing of the project also allows for the supplemental/peripheral systems to be perpetuated as independent or re-architected systems. At the same time, non-strategic building blocks or software packages (PL/SQL, PowerBuilder, etc.) can be phased-out as necessary. Finally, short-interval phasing and releases allows flexibility in adjusting to rapid market changes and organizational needs. Requirements Development is considered a key phase in the BMS and BES project.

A Forrester Research study recently interviewed 704 North American IT decision-makers and found that 57% of software development projects failed because of poorly scoped requirements.

As part of minimizing risk, the BMS project is serving as a pilot for applying a use case based methodology in order to discover and document the desired functional requirements of the BMS system. Additionally, the use of Requisite Pro, a software package that is oriented toward methodical development and management of requirements for major systems is being used to provide adequate tools support. In terms of enlisting the widest scope of participation in requirements gathering, outreaches to Societies and Volunteers were conducted. During the entire Requirements gathering process, participants from Computer Society, Communications Society, and other local entities have been represented. Vision statements and objectives have also been shared with key Volunteers by Staff Directors in RAD and TAD.


---- END DOCUMENT ----

IEEE Business Management System (BMS) Business Entity...

Documents

Transcript of IEEE Business Management System (BMS) Business Entity...