EP1234260A2 - System and method for developing and managing a financial services product - Google Patents

System and method for developing and managing a financial services product

Info

Publication number
EP1234260A2
EP1234260A2 EP00922145A EP00922145A EP1234260A2 EP 1234260 A2 EP1234260 A2 EP 1234260A2 EP 00922145 A EP00922145 A EP 00922145A EP 00922145 A EP00922145 A EP 00922145A EP 1234260 A2 EP1234260 A2 EP 1234260A2
Authority
EP
European Patent Office
Prior art keywords
product
data file
development
management
principal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00922145A
Other languages
German (de)
English (en)
French (fr)
Inventor
Marcia I. Cantor-Grable
Allison M. Kipp
Joseph A. King Jr.
Justine M. Metz
William F. Sughrue
Robin F. Bram
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GE Financial Assurance Holdings Inc
Original Assignee
GE Financial Assurance Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GE Financial Assurance Holdings Inc filed Critical GE Financial Assurance Holdings Inc
Publication of EP1234260A2 publication Critical patent/EP1234260A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00Handling natural language data
    • G06F40/10Text processing

Definitions

  • the present invention relates to a system and method for developing and managing a financial services product.
  • the present invention relates to an integrated system and method for designing, approving, launching and managing a financial services product.
  • U.S. Patent No. 5,819,230 to Christie et al. discloses a system and method for administering a combined mortgage and life insurance program to finance a real estate purchase and to purchase a life insurance product.
  • the primary objective of this system and method is to manage a mortgage and life insurance combination program in which all or a portion of the funds normally used as a down payment for the mortgage are used to purchase a life insurance policy.
  • U.S. Patent No. 5,806,042 to Kelly et al. discloses a system and method for designing and implementing a so alled "bank owned life insurance” plan. This system and method, however, is focussed on addressing the unique problems associated with such "bank owned life insurance” plans under legal regulatory requirements (i.e., federal and state guidelines).
  • U.S. Patent No. 4,837,693 to Schotz discloses a method and apparatus for facilitating operation of an insurance plan. The insurance plan to which this patent is directed, however, is of the type that would enable an employer to allow an employee to convert from a group insurance plan to an individual contract.
  • U.S. Patent No. 5,839,118 to Ryan et al. discloses a system and method for premium optimization and loan monitoring.
  • the insurance plan to which this patent is directed involves an employer pension plan funded with life insurance.
  • U.S. Patent No. 5,752,236 to Sexton et al. discloses a life insurance method and system which involves an insurance plan with at least two separate but related insurance contracts on the same insured person or entity.
  • U.S. Patent No. 5,655,085 to Ryan et al. discloses a computer system for initiating, processing, preparing, storing and tr ⁇ msmitting illustrations of universal life insurance.
  • U.S. Patent No. 5,523,942 to Tyler et al. discloses a design grid for inputting insurance and investment product information in a computer system. More particularly, it discloses a computer implemented graphical user interface displayed on a computer screen for receiving instructions and information relating to a plurality of insurance products and for displaying an insurance proposal related thereto.
  • U.S. Patent No. 5,761,063 to Jannette et al. discloses a design and engineering project management system.
  • the type of product to which this patent is primarily directed is a multi-component product such an automobile which, here again, has its own unique problems associated with and encountered during product development.
  • U.S. Patent No. 5,548,506 to Srinivasan discloses an automated, electronic network-based, project management server system for managing multiple work-groups.
  • U.S. Patent No. 5,050,074 to Marca discloses a system for facilitating coordination of activities by a plurality of actors.
  • U.S. Patent No. 5,408,663 to Miller discloses a resource allocation method to optimize project scheduling.
  • U.S. Patent No. 5,675,745 to Oku discloses an organization activity management system employing a database.
  • U.S. Patent No. 5,596,502 to Koski et al. discloses a computer system for decision support scheduling to assist in the allocation of resources to produce products.
  • a method for developing financial services products includes the steps of: [a] assembling a cross-functional market assessment team including team members representing at least a plurality of the following: a business leader, a project leader, a market assessment process owner, a market assessment analyst, a develop solutions leader, a key stake holder, a market research supplier and a subject matter expert; [b] providing each member of the team with a user interface coupled to a central processing unit; [c] programming the central processing unit with a process to assist in the development of the products, wherein the process includes:
  • a computer system having input means, memory means, processor means and display means, for developing a financial services products.
  • the system includes: [a] a first data file stored in the memory means containing statements of a plurality of principal steps involved in the development of the financial services product including steps for assessing a market and identifying opportunities; [b] a second data file stored in the memory means containing statements of a plurality of component sub-steps associated with each principal step including the sub-steps of collecting secondary data, conducting primary research, creating a market strategy, and validating opportunities; [c] a third data file stored in the memory means containing statements of criteria for determining whether a principal step has been successfully completed, including by identifying necessary approval entities and the standards to be applied by the entities; [d] a fourth data file stored in the memory means containing a plurality of tools associated with at least one principal step or sub-step and further including a representational icon associated therewith, the icon to be displayed on the display means with the principal step or sub-step with which the tool is associated, the tools being chosen from the group comprising: [dl] a glossary of terms and phrases useful in developing and managing a financial
  • a system for developing financial services products includes a [a] a central processing unit; [b] a plurality of user interfaces coupled to the processing unit for use by members a cross-functional market assessment team, each including as associated user display and user input means; [c] a memory coupled to the processing unit and including the following data files stored therein to be accessed and reviewed by members of the cross-functional market assessment team through the user interfaces: [cl] a first data file containing statements of a plurality of principal steps involved in the development and management of the financial services product including steps for assessing a market and identifying opportunities; [c2] a second data file containing statements of a plurality of component sub-steps associated with each principal step including the sub-steps of: collecting secondary data, conducting primary research, creating a market strategy, and validating opportunities; [c3] a third data file containing statements of criteria for deterrr-ining whether a principal step has been completed; [c4]
  • an integrated system for developing a financial services product includes: [a] a central processing unit programmed to assist in the development of the product by a cross-functional market assessment team including: a business leader, a project leader, a market assessment process owner, a market assessment analyst, a develop solutions leader, a key stake holder, a market research supplier and a subject matter expert; [b] a plurality of user interfaces coupled to the central processing unit each including an input means and display means adapted for use by the cross-functional market assessment team; [c] a memory coupled to the central processing unit including data files for storing pre-selected information in connection with the development of the product, wherein the data files can be retrieved by members of the market assessment team through the user input means, said data files including at least: [cl] a first data file associated with a first stage of the development of the product wherein the first stage includes steps for assessing a market and identifying opportunities comprising: collecting secondary data, conducting primary research,
  • a method for developing a financial services product includes the steps of: [a] assembling a cross-functional market assessment team including team members representing at least a plurality of the following: a business leader, a project leader, a market assessment process owner, a market assessment analyst, a develop solutions leader, a key stake holder, a market research supplier and a subject matter expert; [b] programming a central processing unit with a process to assist in the development and management of the product by the cross-functional market assessment team; [c] coupling a plurality of user interfaces to the central processing unit wherein each user interface includes an input means and display means adapted for use by the cross-functional market assessment team; [d] storing in a memory coupled to the central processing unit data files with pre-selected information in connection with the development of the product, wherein the data files can be retrieved by members of the market assessment team through the user input means, said data files including at least: [dl] a first data file associated with
  • FIG. 1 is a schematic representation of a computerized system for developing and managing a financial services product in accordance with the present invention
  • FIG. 2 is a block diagram showing a method for developing and managing a financial services product in accordance with the present invention
  • FIG. 3A is a block diagram illustrating certain features associated with a principal step in accordance with the present invention.
  • FIG. 3B is a block diagram illustrating certain features associated with a component sub-step in accordance with the present invention.
  • FIG. 4 is a block diagram showing a preferred method for developing and managing an insurance product in accordance with the present invention.
  • FIG. 5 is a screen display illustrating an exemplary process window showing the tool bar and principal steps in connection with the preferred embodiment of the invention illustrated in FIG. 4;
  • FIG. 6 is a screen display illustrating an exemplary process window showing the tool bar and component sub-steps of principal step No. 3 in connection with the preferred embodiment of the invention illustrated in FIG. 4;
  • FIG. 7 shows an illustrative embodiment of a risk exposure tree in accordance with the present invention.
  • FIG. 8 shows an illustrative embodiment of a failure mode effectiveness analysis tool in accordance with the present invention
  • FIG. 9 shows an illustrative embodiment of an impact on systems & structures tool in accordance with the present invention.
  • FIG. 10 shows an illustrative embodiment of a decision tree in accordance with the present invention.
  • FIGS. 11A-E show an illustrative embodiment of a template used for a process risk control system in connection with the preferred embodiment of the process illustrated in FIG.4;
  • FIG. 12 shows a preferred embodiment of the market assessment method in accordance with present invention.
  • FIGS. 13A-C are a flow chart illustrating exemplary roles and responsibilities of the members of the cross-functional team in connection with the method of FIG. 12.
  • FIG. 1 is a schematic representation of the computerized system for developing and managing a financial services product in accordance with the present invention.
  • System 10 includes central processing unit 12, memory 14 and a plurality of user interfaces 26A - 26N comprising input devices 27A - 27N and display devices 28A -
  • memory 14 includes one or more of the following data files: principal step data file 16, sub-step data file 18, completion criteria data file 20, document data file 22 and tool data file 24, to be described further below.
  • These data files are used by system 10 for assisting in, guiding and tracking the design and marketing of a financial services product.
  • a user of system 10 can be a member of a cross-functional product development team composed of, for example, a plurality of individuals performing one or more of the following functions: marketing, product management, systems, operations, finance, product development, channel management, risk management, sales, actuarial, investments and legal/ compliance.
  • System 10 includes a plurality of user interfaces 26A-26N to facilitate product development and management in a cross-functional environment were team members have simultaneous access to, and control over, central processing unit 12 and memory 14 associated with the particular product being developed and managed by the team.
  • central processing unit 12 is capable of being programmed with a unique process to provide an improved financial services product.
  • central processing unit 12 is programmed with a consistent, sustainable and repeatable process applicable to a wide variety of financial services products.
  • the process is capable of incorporating one or more of the following features for standardizing the product development process for financial services products:
  • the process can be programmed to incorporate risk management principles for identifying risks associated with the proposed product and creating a complete risk assessment, including mitigants, sensitivity analysis, trigger points and exit strategies, to be discussed further below.
  • the process can be programmed to incorporate quality control principles to make sure the proposed product is developed to meet certain predetermined quality standards.
  • the process can be programmed to incorporate data-driven analytics so that the proposed product is developed based on documented and quantifiable data (as opposed to subjective anecdotal factors).
  • process 30 includes one or more stages 32, 34, 36 and 38 in connection with the development and management of the product.
  • Stage 32 is a design step for designing the product.
  • Stage 34 is an approval step for obtaining proper approval from appropriate members of the development team and others (for example, a company president or regulatory authority).
  • Stage 36 is a product launch step for introducing the product to its respective channel/ market.
  • Stage 38 is a managing step for facilitating management of the product after it has been launched to market.
  • each of these four stages can include one or more of the four features described above, namely: (1) risk management processes (see steps 32A, 34A, 36A and 38A), (2) quality control processes (see steps 32B, 34B, 36B and 38B), (3) a data-driven analytics approach (see steps 32C, 34C, 36C and 38C) and (4) a cross functional team approach (see steps 32D, 34D, 36D and 38D).
  • risk management processes (see steps 32A, 34A, 36 A and 38 A in FIG. 2) set guidelines and standards for promoting consistency across the business in product development. Accordingly, integrated into the four stages of the life cycle for a new product development program is a complete risk assessment, including mitigants, sensitivity analysis, trigger points and exit strategies, that is not only documented, but is an inherent part of the process.
  • mitigants are specific corrective actions (eg., raise rates, lower commissions or internal expenses) that are planned to manage an identified risk ( ⁇ i ., profit margin) associated with a financial services product.
  • a sensitivity analysis is a process for stress testing (e., to target the identified operational risks and to test their performance capabilities to ensure that they can support the demands of a new product) risks of a product.
  • a sensitivity analysis generally involves working with a best and worst case scenario in order to determine expected profitability of a new product. Results of the sensitivity analysis are used to establish trigger points.
  • a trigger point is an early warning signal used to manage the identified risk, namely, a pre-determined threshold level (eg., profit margin 20 % below budget) established for each risk driver (e., the primary variables or assumptions that are critical for the product to achieve its projected financial return) which signals when the level of risk is moving outside the risk/ return range for the product program.
  • a pre-determined threshold level e.g., profit margin 20 % below budget
  • An exit strategy is a specific corrective action for managing risk.
  • the exit strategy can be implemented to provide a "way out” and protect against further loss.
  • risk management concepts By incorporating such risk management concepts into at least one or all of the stages 32, 34, 36 and 38, the product development process becomes more disciplined and well grounded.
  • process 30 is flexible in that the amount of risk management incorporated into a product development program can be tailored to the particular type of product being developed. For example, for long-standing products that are simply being changed in a minor way (e.g., where attributes or features of the product are being slightly modified in order to enhance perceived customer value), process 30 does not need to incorporate the level of risk management that would be needed, for example, to bring an innovative product to market (Le., one that is "new" to the world). Accordingly, the cross-functional product development team can decide during design stage 32 the level of risk management needed in the subsequent stages 34, 36 and 38 of the development process.
  • process 30 is flexible in that the amount of quality control incorporated into a product development program can be varied depending upon the particular type of product being developed or managed. Accordingly, the cross-functional product development team can decide during design stage 32 the level of quality control needed in the subsequent stages 34, 36 and 38 of the development process. As illustrated in FIG.
  • stages 32, 34, 36 and 38 are also grounded in a decision making process based on documented and quantifiable data (e., data-driven analytics), as opposed to subjective, anecdotal factors that are less reliable and predictable. Such data is used to also assist in risk management and quality control processes incorporated into process 30.
  • documented and quantifiable data e., data-driven analytics
  • Such data is used to also assist in risk management and quality control processes incorporated into process 30.
  • FIG. 2 inherent in process 30 is a decision making process that includes input from a cross-functional team at each stage of the development process.
  • process 30 illustrated in FIG. 2 can be implemented on the computerized system show in FIG. 1.
  • system 10 illustrated therein includes (i) central processing unit 12 programmed in accordance with process 30 of FIG. 2 and (ii) memory 14 capable of storing one or more of the following data files associated with this process:
  • a principal step data file 16 that includes an identification of the principal steps involved in developing and managing the financial services product.
  • principal steps are specific stages in the disclosed process that require, at their completion, structured review and approval before the process can proceed to the next stage of development. Such approval checkpoints at various stages of product development help ensure product viability and profitability.
  • the principal steps include one or more of the following: product design, product approval, product launch and product management.
  • a sub-step data file 18 that includes an identification of the component sub-steps associated with each of the respective principal steps stored in principal step data file 16. These sub-steps provide rigor and guidance to the cross-functional product development team in carrying out the principal steps of the process.
  • a principal step completion criteria data file 20 that includes an identification of pre-selected criteria needed to determine whether each respective principal step in the process of development and management of the financial services product has been appropriately completed.
  • a document data file 22 that includes an identification of documents associated with each respective principal step in the process of development and management of the financial services product.
  • documents can include, for example, product and market analyses, customer surveys, product specifications, pricing and financial results, pricing models, profitability assessments, sales forecasts and marketing/ training materials.
  • the documents can also include previous "examples" of relevant documents (e.g., best practices).
  • a tools data file 24 that includes an identification of computer-aided tools associated with each respective principal step in the process of development and management of a financial services product.
  • Such tools can include, for example, risk scorecard charts, time-to-profit analyses, market opportunity assessment tools and product approval review templates, to be discussed further below.
  • FIG. 3A is a schematic block diagram of an exemplary principal step 16A with associated sub-steps 18A, completion criteria 20A, document information 22A and tools 24A.
  • FIG. 3A are analogous completion criteria (also stored in completion criteria data file 20), document information (also stored in document data file 22) and tools (also stored in tools data file 24).
  • completion criteria also stored in completion criteria data file 20
  • document information also stored in document data file 22
  • tools also stored in tools data file 24.
  • FIG. 3B is a schematic block diagram of an exemplary sub-step 18A with associated completion criteria 20A, document information 22A and tools 24A.
  • user interfaces 26A- 26N are used by members of the cross-functional product development team to access, review and/ or update the data contained in data files 16, 18, 20, 22 and 24 in connection with the development and management of a particular financial services product.
  • the project manager (or any other member on the team) can use user input 27A to display on display 28A each of the principal steps associated with the product and stored in principal step data file 16 (eg., "Product Design,” “Product Approval,” “Product Launch” and “Product Management”).
  • the project manager (as well as others) can access, review and/ or update information associated with any of the sub-steps (stored in sub-step data file 18), completion criteria for the principal step (stored in completion criteria data file 20), document information related to the principal step (stored in document data file 22) and tools related to the principal step (stored in tools data file 24), as illustrated in Fig. 3A.
  • the project manager can access, review and/ or update information associated with any of the completion criteria for the sub-step (stored in completion criteria data file 20), document information related to the sub-step (stored in document data file 22) and tools related to the sub- step (stored in tools data file 24), as illustrated in Fig. 3B.
  • the system includes a central processing unit, a plurality of user interfaces for use by a cross- functional product development team, and a memory including data files for storing particular information in connection with the method.
  • the data files can be accessed, reviewed and/ or updated by various members of the product development team.
  • the central processing unit is programmed to incorporate a unique product development process including one or more stages associated with designing, approving, launching and managing the product. Each of these stages, in turn, incorporates one or more of the following features: risk management processes, quality control processes, data-driven analytics and cross-functional team attributes.
  • FIG. 4 is a block diagram showing a preferred embodiment of a process for developing and managing a financial services product such as an insurance product.
  • Process 50 includes four stages 52, 62, 72 and 82 analogous to stages 32, 34, 36 and 38, respectively, discussed above in connection with FIG. 2.
  • stage 52 is a design stage for designing the insurance product
  • stage 62 is an approval stage for obtaining proper approval to proceed with marketing the product
  • stage 72 is a product launch stage for introducing the product to market
  • stage 82 is a managing stage for facilitating management of the product after it has been launched to market.
  • Product design stage 52 includes principal step Nos. 1 through 5 identified in FIG. 4 with reference numerals 53 through 57, respectively, and which comprise the following:
  • Step No. 2 How/When Product?: This step assists in documenting potential new product features based on the information gathered through Step No. 1 and guides in the creation of a team for a further "feasibility" study along with the development of a timeline for the study.
  • step No. 3 assists in evaluating the feasibility of the product from marketing, product management, systems, operations, finance and compliance perspectives (e., function by function). For example, this step guides in: defining a potential "go to market" strategy; validating product features with potential customers/ career agents; providing an initial pricing of the product; evaluating the new product launch and how the product would impact the systems requirements of the business.
  • step No. 4 assists in assessing the product function by function. For example, this step guides in: identifying topics requiring further information; obtaining management review and approval to continue design of the product; reaching consensus on rates and profitability; listing key issues and mitigants; drafting the contract; creating a product team (for product design/ approval/ implementation/ launch); and defining a detailed timeline for product design, approval and launch.
  • step No. 5 Final Product Specification: After the feasibility of the product is analyzed through step No. 4 and the decision is made to proceed, the final product is designed through step No. 5. For example, this step assists in revising and documenting all product design information based on the final product design. It also guides the identification and documentation of risk management factors such as trigger points, sensitivity analysis, mitigants and exit strategies.
  • product design stage 52 is completed and process 50 moves on to a product approval stage 62.
  • product approval stage 62 includes principal step No. 6 identified with reference numeral 63 and which comprises:
  • (No. 6) Internal/ External Approval This step assists in the preparation for and conduction of a product review meeting to internally review the product and obtaining either internal or external approval. Thereafter, external approval is sought by the appropriate regulatory boards. If approval is not obtained, process 50 returns to design stage 52 where further analysis and design of the proposed product is undertaken (if desired). If approval is obtained, process 50 proceeds to a product launch stage which includes principal step Nos. 7 through 9 identified with reference numerals 73 through 75 in FIG. 4, respectively, and which comprise: (No.7) Final Rollout Plan: This step assists in the preparation of a detailed product rollout plan including, for example, defining a state filling schedule and a detailed implementation plan for all operations. In addition, it guides the development of a marketing prototype of the product and the reconciliation of the product specification with the designed (Step No. 5) and approved (Step No. 6) product.
  • step No. 7 Final Review Prior To Launch: After the detailed rollout plan is prepared in step No. 7, final review of the product is undertaken prior to launch. For example, this step assists in the preparation for final launch and, if applicable, the structuring a test launch.
  • process 50 includes a product management stage 82 comprises principal step No. 10 identified with reference numeral 83 in FIG.
  • This step assists in the analyst and implementation of product feedback. For example, it guides the measurement of and the analysis of the market response to the new product; review and validation of the financial strategy of the product; and the review of risk management trigger points on a quarterly basis (e.g., threshold versus actual).
  • each of the ten principal steps includes a set of associated component sub-steps. These sub-steps are chosen and programmed into CPU 12 in order to provide a consistent, sustainable and repeatable process applicable to a variety of products.
  • the sub-steps for each principal step may include those set forth in Table I below.
  • MGPP multi-generational product plan
  • ROI Investment
  • ROE Return on Equity
  • Profitability Assessment sales forecast, profit test results, competitive rate/ benefit analysis, sensitivity analysis, pricing analysis, trend analysis
  • measurements & process maps include environmental, lagging & leading indicators
  • the sub-steps identified in Table I above are designed so that the process is well-documented, grounded in a risk management framework and in which quality control principles are incorporated throughout.
  • decisions are made along the way based on an analytical analysis of data gathered by the process. This is to be contrasted with subjective decision making based on an anecdotal approach as in the prior art or where decisions are made by a top producer's subjective needs and perceptions.
  • the product is developed in a cross-functional environment where many aspects of the business are taken into consideration and where departments and/ or individuals with special skills are involved with the project to develop the proposed product. This approach is facilitated by the system shown in FIG.
  • FIG. 5 is a main page 100 of a user computer display in connection with the preferred embodiment of the present invention illustrated in FIG. 4 discussed above.
  • central processing unit 12 of system 10 is programmed to display on user displays 28A-28N statements of the principal steps stored in principal step data file 16 and to permit a user to select, through user input devices 27A-27N, one of the principal steps.
  • page 100 includes a tool bar 102 for launching applications such as tools and templates, to be discussed further below.
  • Page 100 also includes a bottom frame 104 that lists each of the principal step Nos. 1-10 and provides links to additional detail, also to be discussed below.
  • tool bar 102 includes icons labeled as follows: Project Plan
  • Project Plan icon 105 launches an application such as Microsoft Project PlanTM which provides a detailed summary of the status of each principal step of the process and their associated sub-steps including: % of the step or sub-step that is completed, duration (e.g., 5 days) and start date, along with a week by week graphical summary of its status (e.g., is the step or sub-step: "not started,” “in progress,” “finished,” a "milestone,” etc.).
  • Microsoft Project PlanTM provides a detailed summary of the status of each principal step of the process and their associated sub-steps including: % of the step or sub-step that is completed, duration (e.g., 5 days) and start date, along with a week by week graphical summary of its status (e.g., is the step or sub-step: "not started,” “in progress,” “finished,” a "milestone,” etc.).
  • Such an icon allows members of the product development team, along with management, to determine quite efficiently the status of the development of a proposed new product including tracking of whether or
  • Library icon 106 links the user to another page that provides a list of examples of product approval review documents (used, for example, in connection with principal step No. 6 for internal approval) with hypertext that launches an application such as Microsoft PowerPointTM that contains the slides used for the product approval review. This icon is useful when drafting a new product approval review because it provides easy access to a full library of prior product approval review documents for reference.
  • Approval matrix icon 107 provides a means for launching an application that contains a listing of the approvals necessary for each respective principal step of the process. For example, for each principal step Nos. 2 (sub-step 1), 4 (sub-step k), 6 (sub-step e), 8 (sub-step c) and 10 (sub-step f), where formal approval is required, activation of this icon provides information on whether any the following need to approve the particular step at issue: Business Mgr. Finance, Business Risk Manager, Channel Leaders, CEO, CFO, Director-Administration, Director-Compliance,
  • Glossary icon 108 provides a means for launching an application that provides a glossary for important terms and phrases used in connection with the computerized system 10 for developing and managing a financial services product so that those users not familiar with certain terms and phrases have easy, on-line access to a glossary that defines and explains them.
  • Template icon 109 provides a means for launching a template that allows a user to begin to draft the "product approval review" document referred to in connection with principal step Nos. 4 and 6. This document is used during the product review meeting in connection with Principal Step No. 6 for obtaining internal approval of the product.
  • Thermometer chart icon 110 provides a means for launching an application that identifies the sub-steps of each principal step in matrix form (i.e., column headings are labeled with a principal step number and entries down the column are the associated sub-steps) and color-codes each entry with the following scheme: (1) Green: sub-step is completed with no identifiable risks; (2) Yellow: sub-step is either incomplete or completed but has only low risk associated therewith; and (3) Red: sub-step is either incomplete or completed but has elevated risk associated therewith.
  • Such a chart can be used to quickly assess the status of a product development project and determine (through a visual color-coding scheme) whether certain tasks have either elevated (red), low (yellow) or no (green) identifiable risks associated with them.
  • Risk scorecard icon 111 provides a means for launching an application that summarizes certain identified risks (e.g., profit margin, 1st year premiums, variable expense ratio, loss ratio, cash flow, number of claims, claim type, customer & agent satisfaction, commission, policy lapse rate, etc.) in connection with a particular product. For example, in connection with each such risk, the scorecard tabulates the risk “trigger” value, the "target” value, the "actual” value and its “variance” for such risk along with a brief summary of any corrective action that can be taken if the trigger value is achieved.
  • risks e.g., profit margin, 1st year premiums, variable expense ratio, loss ratio, cash flow, number of claims, claim type, customer & agent satisfaction, commission, policy lapse rate, etc.
  • Time-to-profit scorecard 112 provides a means for launching an application that summarizes profit information associated with the particular product and provides an indication of when that product will become profitable after launch.
  • this scorecard can provide: (1) a graphical plot of income/ expense versus time; (2) projections in connection with the plot; (3) a summary of the plot and (4) a list of needs/ recommendations in connection with the time-to-profit issue.
  • a user of system 10 may access from page 100 illustrated in FIG. 5 any of the tools or templates identified in tool bar 102 or, in the alternative, link to additional information associated with any of the principal step No. 1 through 10 identified in bottom frame
  • FIG. 6 is a page 120 of a user computer display in connection with this step in accordance with the preferred embodiment of the present invention illustrated in FIG. 4.
  • page 120 includes a tool bar
  • Page 120 also includes a bottom frame 124 that lists each of the sub-steps of principal step No. 3 and provides a link to additional detail, information and descriptions associated therewith.
  • central processing unit 12 of system 10 is programmed to be responsive to a user's selection of a principal step for: accessing the component sub-step data file 18 (in FIG. 1); retrieving from the data file statements of the sub-steps associated with the selected principal step and; displaying on user displays 28A-28N the retrieved statements of the principal step and associated sub-steps.
  • Processing unit 12 is also programmed to be responsive to a user's selection of a principal step or an associated sub-step for: accessing the tools data file 24 (FIG. 1); retrieving information from the data file relating to the tools associated with the selected step or sub-step; and displaying on user displays 28A- 28N icons for those tools.
  • tool bar 122 includes icons labeled as follows: Project Plan 125, Library 126, Tools & Deliverables 127, Roles 128, Approvals Required 129, Glossary 130, Thermometer Chart 131, Risk Scorecard 132, Time-To-Profit Scorecard 133, Tool Instructions 134 and Process Maps 135.
  • these icons launch applications that are useful in connection with principal step No. 3 of the product under development.
  • Tool bar 122 includes the following icons:
  • Roles icon 128 provides a means to laimch an application that identifies the various members on the product development team and their role in the process.
  • Approvals Required icon 129 provides a means to launch an application that identifies the people in the business who need to review and approve principal step No. 3 before product development formally proceeds to the next step of the process.
  • Tool Instructions icon 134 provides a means to launch an application that provides a detailed set of instructions on how to use the various tools associated with principal step No. 3.
  • Process Maps icon 135 provides a means to launch an application that graphically maps in flowchart form all activities in connection with principal step No. 3 and how they interelate.
  • Tools & Deliverables icon 127 provides a means to link the user to -mother page that provides descriptions of additional tools and deliverables (e., supporting documentation information) associated particularly with principal step No. 3.
  • additional tools and deliverables e., supporting documentation information
  • sub-step (m) of principal step No. 3 listed in Table I above requires the generation of nine particular types of documents to support and complete the step (namely, a Systems Review, a Regulatory Assessment, an Executive Overview, an Infrastructure Analysis, an Investment Strategy, a Market Feasibility report, a Pricing
  • the display linked to by icon 127 includes an entry for each of these documents, and clicking on the hypertext for each entry launches an application that provides additional detail on the user's display relating thereto.
  • clicking on the Tools & Deliverables icon in connection with other principal steps of the process causes display of a list of documents tailored to the particular step at issue (i.e., for principal step Nos. 1, 2, 4, 5, 6, 7, 8, 9 and 10, the documents listed by clicking on the Tools & Deliverables icon include those identified in sub-steps f, m, 1, s, g, i, d, b and g, respectively, of Table I above).
  • the list linked to by the Tools & Deliverables icon on pages such as 120 in FIG. 6 also includes a list of additional tools useful in connection with carrying out the sub-steps associated with principal step at issue.
  • additional tools may be useful in connection with certain sub-steps of the ten principal step Nos. 1-10:
  • a Marketing Points Log tool that captures information can be useful in the marketing of the new product.
  • This log provides a correlation between relevant points and issues that may arise in meetings, conversations, market studies, focus groups, etc., on the one hand, and implications these points and issues have for launching, marketing and managing the product, on the other hand.
  • Such a correlation provides, in effect, a "feed-forward" loop in the new product development process. Accordingly, such a tool would be most useful in connection with principal step Nos. 2 and 3 of the preferred embodiment illustrated in FIG. 4 where marketing feasibility and strategy are initially determined.
  • a Product Prioritization tool that can be used to provide a priority listing of which product development projects should be completed first.
  • the matrix should yield a priority listing of which product development projects should be completed first. Accordingly, such a tool would be most useful in connection with principal step No.l of the preferred embodiment illustrated in FIG. 4 where market needs are identified and potential opportunities are determined (sub-step (a) in Table I above).
  • a Distribution Matrix tool that can be used to help highlight the likelihood of success in distributing a product and assist in early discussions of determining marketing strategy.
  • Key product team members score each proposed channel of distribution (eg., Payroll Specialist and Broker- Agent).
  • a weighted framework can quantify the critical considerations in choosing an optimal channel for the product (e.g., factors such as: (i) is it currently sold in channel by competition, (ii) experience/ knowledge with product, (iii) represented in target market, (iv) ease of implementation/ administration, (v) receptivity/ eagerness for product, (vi) fit with existing portfolio, (vii) customer receptivity to channel rep, (ix) promotional capability and (x) relative income expected/ success). Accordingly, such a tool would be most useful in connection with principal step No. 2 of the preferred embodiment illustrated in FIG. 4 where distribution channels are selected (sub-step (d) in Table I above). (4) A Risk Exposure Tree tool that can be used to identify risks embedded in products and processes.
  • FIG. 1 A Risk Exposure Tree tool that can be used to identify risks embedded in products and processes.
  • Step 7 shows an illustrative embodiment of a risk exposure tree and can be generated as follows.
  • Step (1) The item under analysis is placed at the top of the tree (i.e., "New Product” identified in box 150 of FIG. 7).
  • Step (2) In the next row 151, the sub-categories are laid out that make up the level above (i.e., the "functional" areas: finance 152, marketing 153, underwriting 154, IT 155, legal 156, administration 157, actuary 158 and contracts 159), keeping risk identification in mind as the ultimate goal.
  • Step (4) Key risks associated with each risk category are then identified. Accordingly, this tool would be most useful in connection with principal step Nos. 2, 3 and 4 of the preferred embodiment illustrated in FIG. 4 where key risks and mitigants are identified and assessed.
  • FIG. 8 shows an illustrative embodiment of such an analysis tool and is generated as follows. Step (1): Major risk categories are aligned in far-left column 171 under the heading PIE (for Process for Introduction and Enhancement), a name used by the assignee of the present invention in connection with the invention hereof. Each step that follows occupies an additional column of FIG. 8. Step (2): Key input factors (i.e., final risk sub-categories) are then grouped into column 172.
  • PIE for Process for Introduction and Enhancement
  • Step (3) Potential failure modes (risks) are then identified in column 173.
  • Step (8): The necessary control or mitigation strategies to monitor and prevent each failure mode are then determined in column 176.
  • FIG. 9 shows an illustrative embodiment of such a tool (in template form).
  • the horizontal axis 181 identifies the functional components of the business
  • the vertical axis 182 graphs the impact (i.e., low, medium and high) of the proposed product on such components. Accordingly, this tool would be most useful in connection with principal step No. 1 of the preferred embodiment illustrated in FIG. 4 where market needs are identified and potential opportunities are determined in connection with a proposed new product.
  • FIG. 10 shows an illustrative embodiment of a Decision Tree 200.
  • critical information in connection with the development of a particular product is initially broken down into four categories in the tree: (i) product overview 210, (ii) marketing 220, (iii) operations 230 and (iv) financials 240. These categories are then broken down again into further sub-categories (for example, sub-categories 210A, 210B, 210C, 210D, 210E in connection with the "Product Overview" category 210) to help in providing a framework for the product development team.
  • sub-categories 210A, 210B, 210C, 210D, 210E in connection with the "Product Overview" category 210
  • a Product Pitch (Approval Review) Template tool that can be used to provide a standard format for the information collected and analyzed in connection with a product approval review that is the subject matter of a product review meeting.
  • a Cost Benefit Analysis tool that can be used to provide a standard format for a cost benefit analysis associated with the development of a proposed product. Accordingly, this tool would be most useful in connection with principal step Nos. 2 and 3 of the preferred embodiment of the invention illustrated in FIG. 4 where new product features are identified and feasibility is studied based on data driven analytics.
  • a Market Identification tool that can be used to explore the market to identify all profitable opportunities.
  • Such a tool can include an analysis in connection with the following three steps: (i) Define the market by identifying profitable opportunities and determining target segments, (ii) Maximize potential by understanding the value created by the product so as to cover the existing market and beat the competition, (iii) Grow and expand relationships with the right customers to capture full value of the product. Accordingly, this tool would be most useful in connection with principal step No. 1 of the preferred embodiment of the invention illustrated in FIG. 4 where market needs are identified and potential opportunities are determined.
  • a Market Opportunity Assessment tool that can be used to assess opportunity in the market by focussing on customer needs and any mis-alignment between those needs and existing products on the market. Accordingly, this tool would be most useful in connection with principal step Nos. 1 and 2 of the preferred embodiment of the invention illustrated in FIG. 4 where market opportunities are analyzed.
  • a Gap Analysis tool that can be used to itemize in chart form for each principal step of the process the so-called "gap” between the particular information that has already been gathered in connection with the step (i.e., "what we have?) and what is needed to complete the step (i.e., "what we need”?).
  • the chart can also include a column for associated " action/ timeframe/ who?" Accordingly, this tool would be most useful in connection with principal step Nos. 1 and 2 of the preferred embodiment illustrated in FIG. 4 which are data collection intensive.
  • a Multi-Generational Product Planning (“MGPP” tool that can be used to apply foresight to product introduction and enhancement.
  • MGPP Multi-Generational Product Planning
  • channel managers need to focus on both the current initiative and future generations of the initiative.
  • This type of tool can help a channel manager focus on what is already know to being planning or investigating for future enhancements.
  • Considering the next generation of a product adds a new dimension to channel management. Accordingly, channel managers need to anticipate industry trends and be cognizant of opportunities to plan for a product in the future.
  • this tool would be most useful in connection with principal step No. 6 of the preferred embodiment of the invention illustrated in FIG. 4 where a multi-generational product planning document is generated (see sub-steps (a)(vi) and (g)(iv) of principal step No. 6 in
  • FIGS. 11A-E show an illustrative embodiment of a template used for a process risk control system in connection with the preferred embodiment of the process illustrated in FIG. 4.
  • twelve "key risks” labeled (1) through (12) including associated risk “indicators” and “mitigants” are identified therein in a table at the bottom of each figure and along side a graphical summary of the process. Accordingly, this tool would be most useful in connection with principal step No. 4 where key risks and mitigants are reviewed in connection with a risk assessment (see sub-steps (c) and (l)(iv) of principal step No. 4 in Table I above)
  • the tools identified above are stored in tool data file 24 illustrated in FIG. 1 and are used throughout the product development process to streamline and standardize the process.
  • Such tools, along with the documents that they generate, are accessible to all members of the product development team by simply clicking on their respective icons on the user displays associated with user interfaces 26A-N of FIG. 1.
  • an improved market assessment method for providing early identification of high- potential opportunities (eg., products, services, distribution channels, customer groups) in connection with financial services products.
  • the improved method is preferably incorporated into principal step Nos. 1 ( e., Why New Product) and 2 (i.e, How/ When New Product) discussed above in connection with product design stage 52 of FIG. 4.
  • FIG. 12 is a diagram showing a preferred embodiment of the improved method for assessing the market in accordance with this aspect of the present invention.
  • market assessment method 300 includes the following sequential steps: step 302 comprising the collection of secondary market data; step 304 comprising conducting primary research; step 306 comprising creating a high level solution concept and strategy; and step 308 comprising the validation of identified opportunities.
  • step 302 comprising the collection of secondary market data
  • step 304 comprising conducting primary research
  • step 306 comprising creating a high level solution concept and strategy
  • step 308 comprising the validation of identified opportunities.
  • arrow 310 represents the input (to be discussed below) to step 302 and arrow 312 represents the output of step 308 to be fed to the remaining portion of the product design stage (eg., principal step No. 3 in FIG. 4) shown in phantom.
  • Arrow 314 represents that the output of collect secondary data step 302 is also fed as input into step 306 (along with the output of conduct primary research step 304).
  • feedback loop 316 represents that information from the remaining portion of the product design stage (shown in phantom) is fed back and used as additional input to steps 302, 304, 306 and 308.
  • steps 302 and 304 correspond substantially to principal step No. 1 while steps 306 and 308 correspond substantially to principal step No.2.
  • collect secondary market data step 302 takes as input certain predetermined strategy hypotheses, market hypotheses and core process data (along with feedback from other steps). The hypotheses are selected based on the business' strategy and desired profitability.
  • secondary market data e., non-proprietary research data which is available to everyone that is relatively quick to gather, does not require market research expertise, and is generally free or inexpensive
  • secondary market data is collected at step 302
  • the process proceeds to step 304 where primary research (i.e., proprietary research which is designed with a specific business purpose objective in mind and is designed by an external market research supplier in conjunction with the business' market research leader) is conducted with the purpose of corifirming, refining and prioritizing customers, markets, issues critical to quality and/ or hypotheses.
  • step 306 high level solution concepts (Le., descriptions of products and/ or services that can be evaluated by a customer) and strategy are created with the purpose of creating a tangible, high level solution concept, assessing the general feasibility for the business and developing a recommended strategy.
  • step 308 opportunities are examined with the purpose of validating, refining and prioritizing the tangible solution concept created in connection with step 307.
  • each of the four steps 302, 304, 306 and 308 discussed above includes a set of associated sub-steps. These sub- steps are chosen in order to provide a consistent, sustainable and repeatable process for providing strategic direction and early identification of high-potential opportunities.
  • the sub-steps of each step may include those set forth in Table II below.
  • Step 302 Collect Secondary Market Data (Input: market hypothesis, research objectives, concept, research results, screening process, business strategy, current product enhancement hypothesis, customer expectations; Output: actionable data, report of findings, conclusions and recommendations including solution opportunities, preliminary issues critical to quality ["CTQs"] and potential customers; business leader approval to proceed)
  • Step 304 Conduct Primary Research (Input: output of step 302, Research Objectives, Research Methodology; Output: Actionable Data, Report of Findings, Conclusions and Recommendations including: CTQs, Segment and product opportunities; Business leader approval to proceed)
  • Step 306 Create high level solution concept and strategy (Input: output of steps 302 and/ or 304; Output: Actionable data with high risks identified,High level marketing plan, Solution(s), Written concepts)
  • Brainstorm solution/ product features including product(s), channel(s), marketing and servicing with team to fulfill identified market(s) and satisfy CTQ's
  • Step 308 Validate opportunities (Input: output of step 306; Output: Validated high potential opportunity, Senior approval)
  • the market assessment method discussed above and illustrated by way of Table II is preferably carried out by a cross-functional team composed of at least the following: (1) Business Sponsor (Le., a leader in the business with authority to initiate, implement and complete a project), (2) Project Leader (Le., a person designated by a Business Sponsor to manage the day-to-day activities to implement and complete a project), (3) Market Assessment Process Owner (Le., a person responsible for all market assessment activity in the business and who is focussed on Principal Step Nos.
  • Business Sponsor Le., a leader in the business with authority to initiate, implement and complete a project
  • Project Leader Le., a person designated by a Business Sponsor to manage the day-to-day activities to implement and complete a project
  • Market Assessment Process Owner Le., a person responsible for all market assessment activity in the business and who is focussed on Principal Step Nos.
  • FIGS. 13A, 13B and 13C are a flow chart illustrating exemplary roles and responsibilities of the various members of the cross-functional team (identified at the top of each column) in connection with carrying out the primary steps of the market assessment method of the present invention.
  • flow chart 400 begins at step 401 where a Business Sponsor states a hypothesis, objectives and/ or rationales for developing a strategic business plan for identifying high-potential opportunities.
  • the process then continues to step 402 where the Business Sponsor identifies a Project Leader and cross-functional resources to assess the plan. Thereafter, at step 403, the selected Project Leader confirms the hypothesis, objective and/or rationales.
  • the process then proceeds to step 404 where the Project Leader identifies the information needed to prove the hypothesis and meet objectives. In order to do so, the process continues to step 405 where a data collection plan is jointly developed by the Project Leader, a Market Assessment (ATM) Process Owner, a Market Assessment (ATM) Analyst and a Develop Solutions Leader.
  • ATM Market Assessment
  • ATM Market Assessment
  • the process proceeds to test 406 where the Business Sponsor determines if the plan is acceptable. If the plan is not acceptable, the process repeats to step 404 discussed above. If the plan is acceptable, the process proceeds to test 407 where the Market
  • step 304 illustrated in FIG. 13B (discussed below). If secondary data is a source, the process proceeds to steps 408 (where data is collected), 409 (where the data is analyzed), 410 (where the data is manipulated to yield conclusions and recommendations), 411 (where opportunities are prioritized) and 412 (where findings, conclusions and recommendations are documented), all of which are carried out by the Market Assessment Analyst. Thereafter, the process proceeds to step 413 where the Market Assessment Analyst determines whether, in light of the collected secondary data, the hypothesis is still valid and to recommend killing" (i ⁇ e., terminating), revising or proceeding with the project.
  • step 414 if the hypothesis is not acceptable, the process repeats to data collection step 408 discussed above. If it is, the process proceeds to steps 415A, 415B and 415C where the Project Leader, Market Assessment Analyst and Develop Solutions Leader jointly discuss the conclusions and recommendations. If they agree to the findings at tests 416A, 416B and 416C, respectively, the process proceeds to step 417 where the collected data is deposited in a data repository by the Project Leader. If they do not, the process repeats data collection step 408 discussed above. As a check, after step 417, the process proceeds to test 418 where the Project Leader determines if the hypothesis is still valid. If not, at test 419, the Project Leader determines whether to kill the project (where the process would then stop at step
  • step 419 the Project Leader decides not to kill the project, the process proceeds to step 421 where the hypothesis is revised and the process then repeats to step 405 where a revised data collection plan is developed. If at test 418 the Project Leader determines that the hypothesis is still valid, the process proceeds to test 422 where it is determined if there are any gaps in knowledge associated with the project. If there are, the process repeats to step 405 where a revised data collection plan is developed. If there are not any gaps in knowledge, the process proceeds to step 460 illustrated on FIG. 13C (discussed below).
  • Process Owner and Analyst jointly determine what Market Research Suppliers to meet with and carry out that aspect of the plan. Thereafter, at steps 431A, 431B, 431C and 431D, the Project Leader, Market Assessment Analyst, Develop Solutions Leader and Market Research (MR) Suppliers meet to: (1) share board business background, (2) discuss research objectives, (3) discuss time and cost parameters, (4) address any Supplier questions and/or concerns, and (5) request written proposals and preliminary design by a specific date. Thereafter, the process proceeds to step 432 where the research plan is designed by the Market Research Supplier. After the research plan is designed, the Market Research Supplier writes a proposal at step 433 and provides it to the Market Assessment Analyst, where at step 434, it is evaluated.
  • MR Market Assessment Leader
  • the Market Assessment Analyst determines if the proposal is acceptable based on design, cost and time criteria. If not, the process repeats to steps 431A-D discussed above. If the proposal is acceptable, the process proceeds to step 436 where a research design/ proposal is recommended. Thereafter, the process goes to test 437 where the Market Assessment Process Owner determines if the proposal is acceptable based on design, cost and time criteria. If not, the process repeats to steps 431A-D discussed above. If the proposal is acceptable, the process proceeds to tests 438A and 438B where the Project Leader and Develop Solutions Leader also determine from their prospectives whether the proposal is acceptable. Similar to tests 435 and 437, if not, the process repeats to steps 431A-D discussed above.
  • the process they proceeds to test 439 where the Business Sponsor also determines if the proposal is acceptable. If not, the process repeats to steps 431A-D discussed above. If the proposal is acceptable to the Business Sponsor, the process proceeds to steps 440 (where the Market Research Supplier conducts the research) and 441 (where the results are analyzed). Thereafter, the process proceeds to steps 442A and B (where the data is manipulated to yield conclusions and recommendations), 443A and B (where opportunities are prioritized), 444A and B (where findings, conclusions and recommendations are documented) carried out simultaneously by the Market Assessment Analyst and Market Research Supplier.
  • step 445 determines, at test 445, whether the conclusions and recommendations are acceptable. If not, the process repeats to step 441 discussed above. If they are, the process proceeds to steps 446A, 446B, 446C and 446D where the Project Leader, Market Assessment Analyst, Develop Solutions Leader and Market Research Supplier jointly discuss the conclusions and recommendations. If they agree with the findings (see tests 447A, 447B, 447C and 447D), the process proceeds to step 448 where the relevant data is deposited in a data repository. If they do not agree with the findings, the process repeats to step 441 discussed above. After step 448, the process proceeds to test 449 where the Project Leader checks to determine if the hypothesis is still valid.
  • step 452 it is determined whether to kill the project by stopping at step 451. If the Project Leader decides not to kill the project but instead to revise the hypothesis (see step 452), the process proceeds back to FIG. 13A to collect data in connection with the revised hypothesis.
  • test 449 the process proceeds to test 453 where the Business Sponsor determines if the conclusions and recommendations are acceptable. If not, the process repeats to steps 442A and B discussed above. If they are acceptable, the process proceeds to test 454 where the Business Sponsor determines whether or not the research was performed to prioritize concepts. If the answer is yes, the process proceeds to FIG. 13C to perform a risk assessment (to be discussed further below). If the answer is no, the process proceeds to test 455 where it is determined whether or not the research was performed to validate high-level solution concepts and strategy. If the research was done for such validation, the process proceeds to test 484 of FIG. 13C (to be discussed further below).
  • step 460A, 460B, 460C and 460D (of FIG. 13C) where the Project Leader, Market Assessment Analyst, Develop Solutions Leader and Subject Matter Expert (SME) jointly review the conclusions and recommendations from steps 302 and 304 in an effort to assess risks (to be discussed further below).
  • SME Subject Matter Expert
  • steps 460A-D the process proceeds to steps 461A-D, respectively, where solution opportunities based on research are determined.
  • the process proceeds to test 462 where the Market Assessment Process Owner determines whether the solution opportunities are acceptable. If not, the process returns to steps 460A-D discussed above. If the solution opportunities are acceptable to the Market Assessment Process Owner, the process proceeds to test 463 where the Business Sponsor in turn determines if the solution opportunities are acceptable. If they are not, the process returns to steps 460A-D discussed above. If the opportunities are acceptable, the process proceeds to test 464 where Key Stake Holders determine if the proposed solution opportunities are also acceptable to them as well. If the Key Stake Holders determine that the opportunities are not acceptable, the process returns to steps 460A-D discussed above. Otherwise, if the solution activities are acceptable to the Key Stake Holders, the process proceeds to step 465 where a cross functional brainstorming team is created by the Develop Solutions Leaders.
  • test 469 the Business Sponsor determines whether or not the solution concept is acceptable. If the solution concept is not acceptable, the process returns to step 465 discussed above. If the solution concept is acceptable to the Business Sponsor, the process proceeds to test 470 where it is determined if research is needed to prioritize concepts. If prioritization research is needed, the process returns to steps 430A and 430B of FIG. 13B discussed above. If prioritization research is not needed, the process proceeds to step 471 where solution concepts are prioritized. In connection with prioritization, the process proceeds to steps 472 (where business risk [eg., compliance and regulatory] are assessed), 474 (where operational and system feasibility are assessed), 476 (where distributions channels are assessed) and 478 (where financial analysis is developed).
  • business risk eg., compliance and regulatory
  • 474 where operational and system feasibility are assessed
  • 476 where distributions channels are assessed
  • 478 where financial analysis is developed.
  • the Develop Solutions Leader consults with Subject Matter Exports 472A, 474A, 476A and 478A, respectively. After steps 472, 474, 476 and 478, the process proceeds to associated tests 472B, 474B, 476B and 478B, respectively. If the answer to any of these four tests is no, the process returns to step 465 discussed above to provide additional brainstorming. When the answer to all four of these tests is yes (see test 479), the process proceeds to step 480 where a high level solution strategy is developed by the Develop Solutions Leader. In doing so, the process proceeds to steps 481A, 481B, 481C and 481D where high level solution concepts and strategy are discussed amongst the Business Sponsor, Project Leader, Market Assessment Analyst and Develop Solutions Leader.
  • step 482 the Business Sponsor determines whether the discussed concepts and strategy are approved for validation. If not, the process returns to step 465 discussed above. If the discussed concepts and strategy -ire approved for validation, the process proceeds to step 483 where relevant data is deposited in the data repository by the Project Leader. Thereafter, the process proceeds to steps 430 A and B for validation (FIG. 13B). After validation research (see test 455 in FIG. 13B), the process returns to FIG. 13C and performs test 484 where it is determined whether or not the conclusions and recommendations are acceptable to the Key Stake Holders. If so, the process proceeds to develop solutions in connection with the remaining portion of the product design stage.
  • the market assessment method aspect of the present invention can be used to develop and/ or enhance financial services products to both create differentiation and drive competitive advantages in the market place.
  • This method also helps to reduce the need to rework such products after market introduction as a result of an inadequate or incomplete understanding of the relevant market.
  • it provides an improved method for developing and managing a financial services product compared to the prior art.
  • the method provides a systematic and quantifiable procedure for identifying early on unique market opportunities with high potential. Accordingly, based on the above, an integrated system and method has been disclosed for developing and managing a financial services product.
  • One skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments.
  • memory 14 in FIG. 1 is illustrated with five separate and distinct data files 16, 18, 20, 22 and 24, some or all of the functions associated with those data files can be merged into a single file (if it is so desired).
  • process 30 in FIG. 2 is illustrated with four separate and distinct stages 32, 34, 36 and 38, some or all of the functions associated with those stages can be merged into a single stage (if it is so desired).

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Artificial Intelligence (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
EP00922145A 1999-04-16 2000-04-13 System and method for developing and managing a financial services product Withdrawn EP1234260A2 (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US29339899A 1999-04-16 1999-04-16
US293398 1999-04-16
US47569399A 1999-12-30 1999-12-30
US475693 1999-12-30
PCT/US2000/009899 WO2000063824A2 (en) 1999-04-16 2000-04-13 System and method for developing and managing a financial services product

Publications (1)

Publication Number Publication Date
EP1234260A2 true EP1234260A2 (en) 2002-08-28

Family

ID=26967936

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00922145A Withdrawn EP1234260A2 (en) 1999-04-16 2000-04-13 System and method for developing and managing a financial services product

Country Status (4)

Country Link
EP (1) EP1234260A2 (ja)
JP (1) JP2003524222A (ja)
AU (1) AU4237500A (ja)
WO (1) WO2000063824A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11977858B2 (en) 2022-02-07 2024-05-07 T-Mobile Usa, Inc. Centralized intake and capacity assessment platform for project processes, such as with product development in telecommunications

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7849117B2 (en) 2000-01-12 2010-12-07 Knowledge Sphere, Inc. Multi-term frequency analysis
JP2002269334A (ja) * 2001-03-13 2002-09-20 Shiseido Co Ltd 商品開発方法、商品開発システム、商品開発プログラムおよび商品開発プログラムを記録した記録媒体
US7657474B1 (en) 2003-03-04 2010-02-02 Mantas, Inc. Method and system for the detection of trading compliance violations for fixed income securities
US8175910B2 (en) * 2007-11-15 2012-05-08 Ebay Inc. Marketing allocation request systems
KR100967442B1 (ko) * 2007-12-04 2010-07-01 주식회사 티맥스 소프트 통합 상품 관리 시스템
JP5300824B2 (ja) * 2010-11-17 2013-09-25 株式会社東芝 情報処理システム、情報処理方法および情報処理プログラム
US9208462B2 (en) * 2011-12-21 2015-12-08 Mu Sigma Business Solutions Pvt. Ltd. System and method for generating a marketing-mix solution

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11977858B2 (en) 2022-02-07 2024-05-07 T-Mobile Usa, Inc. Centralized intake and capacity assessment platform for project processes, such as with product development in telecommunications

Also Published As

Publication number Publication date
WO2000063824A8 (en) 2002-06-13
WO2000063824A2 (en) 2000-10-26
JP2003524222A (ja) 2003-08-12
AU4237500A (en) 2000-11-02
WO2000063824A9 (en) 2002-04-04

Similar Documents

Publication Publication Date Title
Alexander Financial planning & analysis and performance management
US8370250B2 (en) Total return to shareholders target setting
US20050278202A1 (en) Information technology transformation assessment tools
US20050209945A1 (en) Mapping total return to shareholder
US20100082407A1 (en) System and method for financial transformation
US7127421B1 (en) Method and system for identifying bottlenecks in a securities processing system
US20130246126A1 (en) System and method for customer value creation
WO2000063824A2 (en) System and method for developing and managing a financial services product
Saporito Applied insurance analytics: a framework for driving more value from data assets, technologies, and tools
Kepczynski et al. Implementing Integrated Business Planning: A Guide Exemplified With Process Context and SAP IBP Use Cases
Januarie The rationale of using standard costing in manufacturing organisations in the eastern cape when modern alternatives are available
WO2002033581A2 (en) System and method for developing and managing a financial services product
Harris Planning and Control Using Microsoft Project 2013
Kottemann Formalisms for business information system development
Heponiemi Robotic process automation as a tool for lean supply management processes
Agrawal Critical success factor and metrics for new product development success
Renner Software robot-based automation of financial administration’s processes
Kivinen Enhancing Operations Management Efficiency and Employee Experience Through Data
Rautio Integration of substance compliance and a product lifecycle management system in case organization
Eze Pursuing Efficient Human Resources Management using Computerized Systems
Räty Robotic process automation in financial controlling
Hunt et al. Software Acquisition & Supplier Management: Part 1–Product Definition & Supplier Selection
Oskarsson et al. Introducing purchasable technical service packages in a productoriented organization-A Go-To-Market Study
Pussep Firm Strategies and Business Models in the Software Industry: A Configurational Approach
Sitarama Murali Krishna Effective Utilization of Historical Data to Increase Organizational Performance: Focus on Sales/Tendering and Projects

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): DE FR GB IT

17P Request for examination filed

Effective date: 20021213

17Q First examination report despatched

Effective date: 20090213

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090825