WO2017150467A1 - プログラム、情報処理方法および情報処理装置 - Google Patents

プログラム、情報処理方法および情報処理装置 Download PDF

Info

Publication number
WO2017150467A1
WO2017150467A1 PCT/JP2017/007545 JP2017007545W WO2017150467A1 WO 2017150467 A1 WO2017150467 A1 WO 2017150467A1 JP 2017007545 W JP2017007545 W JP 2017007545W WO 2017150467 A1 WO2017150467 A1 WO 2017150467A1
Authority
WO
WIPO (PCT)
Prior art keywords
contract
service
product
cpu
model
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.)
Ceased
Application number
PCT/JP2017/007545
Other languages
English (en)
French (fr)
Inventor
豊 岩山
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of WO2017150467A1 publication Critical patent/WO2017150467A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the present invention relates to a program, an information processing method, and an information processing apparatus.
  • a web server system that manages the number of times a question is received by classifying users who have purchased hardware into three types: unregistered users, registered users who have not signed a maintenance contract, and registered users who have signed a maintenance contract (Patent Document 1).
  • an object is to provide a program that outputs candidate service products with high priority for review.
  • the program calculates the contract rate of the service product for each combination of the model to which the device belongs and the service product based on the identification information for identifying the sold device and the presence / absence of a contract for the service product related to the device Then, the variation of the contract rate between the models is calculated for each service product, and the computer is caused to execute a process of outputting at least one service product selected based on the variation of the contract rate.
  • FIG. 10 is an explanatory diagram illustrating a record layout of a ranking DB according to the second embodiment.
  • FIG. 10 is an explanatory diagram illustrating a screen that displays an information processing result according to Embodiment 2.
  • FIG. 12 is a flowchart illustrating a processing flow of a program according to the second embodiment. 12 is a flowchart showing a flow of processing of a subroutine for model-specific contract data calculation according to the second embodiment. 10 is a flowchart showing a flow of processing of a subroutine for model-specific service result data calculation according to the second embodiment. 12 is a flowchart illustrating a flow of processing of a subroutine for calculating data for each product according to the second embodiment. 10 is a flowchart showing a flow of processing of a ranking subroutine according to the second embodiment. FIG.
  • FIG. 10 is an explanatory diagram showing a record layout of a non-contracted device provision number DB according to the third embodiment.
  • FIG. 10 is an explanatory diagram illustrating a record layout of an estimated provision rate DB according to the third embodiment. It is explanatory drawing which shows the record layout of model classification DB of Embodiment 3.
  • FIG. 14 is a flowchart showing a flow of processing of a subroutine for calculating service-specific service result data according to the third embodiment. 14 is a flowchart illustrating a processing flow of a subroutine for calculating the number of non-contracted device provision according to the third embodiment. It is explanatory drawing which shows the record layout of sales volume DB of Embodiment 4.
  • FIG. 10 is an explanatory diagram showing a record layout of a non-contracted device provision number DB according to the third embodiment.
  • FIG. 10 is an explanatory diagram illustrating a record layout of an estimated provision rate DB according to the third embodiment. It is explanatory drawing which shows the
  • FIG. 15 is a flowchart illustrating a flow of processing of a subroutine for calculating data for each product according to the fourth embodiment. It is explanatory drawing which shows the record layout of contract number DB of Embodiment 5.
  • FIG. FIG. 20 is an explanatory diagram showing a record layout of a ranking DB according to the fifth embodiment.
  • FIG. 20 is an explanatory diagram showing a screen for displaying an information processing result according to the sixth embodiment.
  • FIG. 19 is a functional block diagram illustrating an operation of the information processing apparatus according to the seventh embodiment.
  • FIG. 20 is an explanatory diagram illustrating a configuration of an information processing device according to an eighth embodiment.
  • FIG. 1 is an explanatory diagram illustrating a configuration of the information processing apparatus 11.
  • the information processing apparatus 11 includes a CPU (Central Processing Unit) 12, a main storage device 13, an auxiliary storage device 14, an input unit 15, a display unit 16, a communication unit 17, a reading unit 18, and a bus.
  • the information processing apparatus 11 according to the present embodiment is an information device such as a general-purpose personal computer, a tablet, or a large computer. Further, the information processing apparatus 11 of the present embodiment may be a virtual machine that operates on a large computer.
  • the CPU 12 is an arithmetic control device that executes a program according to the present embodiment. As the CPU 12, one or a plurality of CPUs or a multi-core CPU is used. The CPU 12 is connected to each hardware part constituting the information processing apparatus 11 via a bus.
  • the main storage device 13 is a storage device such as SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), flash memory or the like.
  • the main storage device 13 temporarily stores information necessary during processing performed by the CPU 12 and a program being executed by the CPU 12.
  • the auxiliary storage device 14 is a storage device such as SRAM, flash memory, hard disk or magnetic tape.
  • the auxiliary storage device 14 stores a program to be executed by the CPU 12, a sales DB (DataBase) 31, a candidate DB 32, a model-specific evaluation DB 33, a product-specific evaluation DB 34, and various information necessary for executing the program.
  • the reading unit 18 is a device that reads a portable recording medium 72 (see FIG. 34), which will be described later, and specifically, for example, an SD (Secure Digital) card slot, an optical disk drive, a USB (Universal Serial Serial Bus) port, or the like. .
  • SD Secure Digital
  • USB Universal Serial Serial Bus
  • FIG. 2 is an explanatory diagram for explaining the relationship between hardware models and service products.
  • the manufacturer manufactures and sells a plurality of hardware products indicated by model S to model W.
  • the characters from S to W indicate a model code for identifying the model.
  • the hardware product is, for example, an information processing system such as a large computer, a desktop personal computer, a notebook personal computer, or a tablet, or a combination of a plurality of information processing devices.
  • the hardware may be an information device such as a printer, a multifunction peripheral, a scanner, or a home appliance.
  • the hardware may be a monitoring system combining a computer and a plurality of video cameras.
  • the product of each model is described as a device.
  • the manufacturer also sells a plurality of service products indicated by contract A to contract F for hardware products.
  • characters from A to F indicate a product code for specifying a service product.
  • Service products include, for example, data recovery in the event of trouble, firmware updates, response to questions via telephone, 24-hour remote support, business trip support, supply of consumables, remote failure diagnosis, remote failure prediction, etc. .
  • contract A and contract C correspond to model S.
  • Contract A, contract B, and contract C correspond to model T.
  • Contract A corresponds to model S and model T.
  • Contract B corresponds to model T and model U.
  • the device purchaser can select and purchase service products corresponding to the model of the purchased device.
  • Service products can be purchased at the same time as the device or at a later date as needed.
  • a purchaser of a device may purchase a plurality of service products for one device.
  • a manufacturer or a retail store may provide a service product free of charge to a device purchaser in a sales promotion campaign or the like.
  • FIG. 3 is an explanatory diagram showing a record layout of the sales DB 31.
  • the sales DB 31 is a DB that associates sold hardware products with service products.
  • the sales DB 31 has a hardware product field and a service product field.
  • the hardware product field has a model code field, a serial number field, and a device sales date field.
  • the service product field has a product code field, a contract date field, a start date field, and an end date field.
  • the model code field the model of the sold device is recorded.
  • the production number field the production number of the sold device is recorded.
  • the production number is an example of identification information for identifying an individual device sold.
  • a combination of the model code and the manufacturing number is used for the identification information.
  • a production number is used as identification information will be described as an example.
  • the equipment sales date field the date when the equipment was sold is recorded.
  • the product code field the product code of the service product sold in combination with the device is recorded.
  • the contract date field the date on which the service product is contracted is recorded.
  • the start date field the start date of the service contract is recorded.
  • the end date field the end date of the service contract is recorded.
  • the service product field is blank.
  • the sales DB 31 records a plurality of records corresponding to each service product. Therefore, the sales DB 31 has one record for one combination of sold equipment and service products. The sales DB 31 is updated each time equipment and services are sold.
  • FIG. 4 is an explanatory diagram showing a record layout of the candidate DB 32.
  • the candidate DB 32 is a DB that associates a product code of a service product that is a review candidate with a product name.
  • review means reviewing the contents, price, contract conditions, and corresponding hardware product models of existing service products, improving service products, improving sales methods, and developing new service products. And so on.
  • the service product to be recorded in the candidate DB 32 is selected based on the manufacturer's business plan, service product development plan, and the like.
  • the candidate DB 32 has a product code field and a product name field.
  • the product code field the product code of the service product to be reviewed is recorded.
  • the product name field the name of the service product is recorded.
  • the candidate DB 32 has one record for one review candidate.
  • FIG. 5 is an explanatory diagram showing a record layout of the model-specific evaluation DB 33.
  • the model-specific evaluation DB 33 is a DB that associates the product code, the model code, and the contract rate of the service product.
  • the model-specific evaluation DB 33 has a product code field, a model code field, and a contract rate field.
  • the product code field the product code of the service product to be reviewed is recorded.
  • the model code field the model code of the hardware product corresponding to the service product recorded in the product code field is recorded.
  • the contract rate field the contract rate of the service product divided by the number of hardware products sold is recorded.
  • the model-specific evaluation DB 33 has one record for the combination of the product code and the model code.
  • the model evaluation DB 33 is a DB created by the CPU 12 based on the program of the present embodiment. An outline of a method for creating the model-specific evaluation DB 33 will be described below.
  • the CPU12 takes out one candidate record from candidate DB32.
  • the CPU 12 extracts a sales record from the sales DB 31 using the product code recorded in the product code field of the extracted candidate record as a key.
  • the CPU 12 refers to the model code field of the extracted sales record and extracts the model code without duplication.
  • the description thereof is omitted.
  • the CPU 12 creates the same number of records as the number of model codes in the model evaluation DB 33 in which the product code read from the candidate DB 32 is recorded in the product code field and the model code extracted in the model code field is recorded.
  • the CPU 12 takes out one model-specific evaluation record from the model-specific evaluation DB 33.
  • the CPU 12 extracts a sales record from the sales DB 31 using the model code recorded in the model code field of the extracted model-specific evaluation record as a key.
  • CPU12 calculates
  • the CPU 12 re-extracts the sales record from the previously extracted sales record using the product code recorded in the product code field of the above-mentioned model-specific evaluation record extracted from the model-specific evaluation DB 33 as a key.
  • the CPU 12 calculates the number of service product contracts by counting the number of sales records that have been re-extracted.
  • the CPU 12 calculates the contract rate by dividing the number of service product contracts by the number of models sold.
  • the CPU 12 records the contract rate in the contract rate field of the aforementioned model-specific evaluation record.
  • the CPU 12 performs the above processing for all the records recorded in the model-specific evaluation DB 33.
  • the model-specific evaluation DB 33 described with reference to FIG. 5 is completed.
  • FIG. 6 is an explanatory diagram showing a record layout of the evaluation DB 34 for each product.
  • the product-by-product evaluation DB 34 is a DB that associates the product code with the average value and variation of the contract rate of the service product indicated by the product code.
  • the product-by-product evaluation DB 34 has a product code field, a contract rate field, and a contract rate variation field.
  • the product code field the product code of the service product to be reviewed is recorded.
  • the contract rate field an average value of the contract rate for each model corresponding to the service product is recorded.
  • the contract rate variation field the contract rate variation for each model corresponding to the service product is recorded.
  • the product-specific evaluation DB 34 has one record for one service product to be reviewed.
  • the product evaluation DB 34 is a DB created by the CPU 12 based on the program of the present embodiment. An outline of a method for creating the product-specific evaluation DB 34 will be described below.
  • the CPU12 takes out one candidate record from candidate DB32.
  • the CPU 12 extracts a record from the model evaluation DB 33 using the product code recorded in the product code field of the extracted candidate record as a key.
  • the CPU 12 calculates the average value and the variance of the contract rate recorded in the contract rate field of the extracted record.
  • the CPU 12 creates a record in the product evaluation DB 34, and records the product code in the product code field, the average value in the contract rate field, and the variance in the contract rate variation field.
  • the CPU 12 performs the above processing for all records recorded in the candidate DB 32.
  • the product-by-product evaluation DB 34 described with reference to FIG. 6 is completed.
  • the average value is an example of a typical contract rate. Instead of the average value, for example, a mode value, a median value, a geometric average value, or the like may be used.
  • the variance is an example of an index indicating the variation in the contract rate. Instead of the variance, for example, a standard deviation, a difference between the maximum value and the minimum value, or the like may be used.
  • FIG. 7 is an explanatory diagram showing a screen for displaying the information processing result.
  • the CPU 12 displays the screen shown in FIG.
  • the screen shown in FIG. 7 has a rank column 21 and a breakdown column 22.
  • the ranking column 21 displays data obtained by ranking the records recorded in the product evaluation DB 34 in descending order of the values recorded in the contract rate variation field.
  • the CPU 12 may display a record having a predetermined order or higher in the order column 21.
  • the CPU 12 may display in the ranking column 21 a record in which a numerical value equal to or greater than a predetermined value is recorded in the contract rate variation field.
  • the CPU 12 may display only the topmost record in the rank column 21.
  • a selection frame 23 is displayed around the first row.
  • data recorded in the model evaluation DB 33 corresponding to the product code in the row surrounded by the selection frame 23 is displayed.
  • the selection frame 23 encloses a line in which B is displayed in the product code.
  • records whose product code is B in the model-specific evaluation DB 33 are displayed.
  • the CPU 12 accepts selection of a row surrounded by the selection frame 23 via the input unit 15.
  • the CPU 12 changes the data displayed in the breakdown column 22 in accordance with the line surrounded by the selection frame 23.
  • FIG. 8 is a flowchart showing the processing flow of the program. The process flow of the program according to this embodiment will be described with reference to FIG.
  • the CPU 12 starts a model acquisition subroutine (step S501).
  • the model acquisition subroutine is a subroutine for searching the sales DB 31 to acquire the model of a hardware product sold in combination with the service product recorded in the candidate DB 32.
  • the processing flow of the model acquisition subroutine will be described later.
  • the auxiliary storage device 14 stores a model-specific evaluation DB 33 in which the contract rate field is blank.
  • the CPU 12 re-extracts records from which the same date is recorded in the device sales date field and the contract date field from the re-extracted sales records.
  • the CPU 12 obtains the number of service products purchased at the same time as the device by counting the number of re-extracted records.
  • the CPU 12 determines whether or not the processing of all the records in the model evaluation DB 33 has been completed (step S709). If it is determined that the process has not been completed (NO in step S709), the CPU 12 adds 1 to the counter I (step S710). Thereafter, the CPU 12 returns to step S703. If it is determined that the process has ended (YES in step S709), the CPU 12 ends the process.
  • Step S671 the CPU 12 initializes evaluation DB34 classified by goods (Step S671). Specifically, when the product-by-product evaluation DB 34 is stored in the auxiliary storage device 14, the CPU 12 deletes all the records stored in the product-by-product evaluation DB 34. When the product-specific evaluation DB 34 is not stored in the auxiliary storage device 14, the CPU 12 creates the product-specific evaluation DB 34 that does not have a record.
  • the CPU 12 records the average value of the simultaneous purchase rates calculated in step S677 in the simultaneous purchase rate field of the record to be created.
  • the CPU 12 records the average value of the no-contract device provision rate calculated in step S678 in the no-contract device provision rate field of the record to be created.
  • a user who is in charge of reviewing service products can review service products that are reviewed based on a plurality of indicators. Further, since the user does not directly access the data recorded in the sales DB 31 and the service result DB, it is possible to prevent information leakage or the like.
  • the product code field of the record that records the contact with the non-contracted device in the service performance DB described with reference to FIG. 13 is blank.
  • the record in which the production number field in FIG. 13 is “V0001” is a record that records the contact with the non-contracted device, and the product code field is blank.
  • the record whose manufacturing number field is “V0052” is also a record in which the contact with the non-contracted device is recorded, and the product code field is blank.
  • model code field the model code of the hardware product is recorded.
  • product code field the ratio of providing services is recorded.
  • a specific example will be described.
  • the record of the model code S 0.8 is recorded in the A field, 0.2 is recorded in the C field, and 0.0 is recorded in the other fields. This indicates that the communication about the device whose model code is S is estimated that 80% is subject to the contract A and 20% is subject to the contract C.
  • FIG. 26 is an explanatory diagram showing a record layout of the model-specific evaluation DB 33 according to the third embodiment.
  • the model-specific evaluation DB 33 shown in FIG. 26 is a DB used in place of the model-specific evaluation DB 33 of the second embodiment described with reference to FIG.
  • the provided number field records the number of service provided for the device with which the corresponding service product is contracted.
  • a value obtained by estimating the service provision number for the non-contracted device is recorded.
  • the total provided number field the total provided number obtained by adding the value recorded in the estimated number field to the value recorded in the provided number field is recorded.
  • the non-contracted device provision rate field the service provision rate for the non-contracted device obtained by dividing the value recorded in the estimated number field by the value recorded in the total provision number field is recorded.
  • the model-specific evaluation DB 33 has one record for the combination of the product code and the model code.
  • the model evaluation DB 33 is a DB created by the CPU 12 based on the program of the present embodiment. An outline of a method for creating the model-specific evaluation DB 33 will be described below.
  • the CPU 12 calculates the estimated number of service provisions for the non-contracted device by multiplying the uncontracted device provision number extracted from the unlicensed device provision number DB by the ratio extracted from the estimated provision rate DB.
  • the method for calculating the estimated number will be described with a specific example.
  • the unsigned device provision number DB shown in FIG. 24 the number of service provisions to the unsigned device regarding the device whose model code is S is ten.
  • the CPU 12 performs the above processing for all the records recorded in the model-specific evaluation DB 33.
  • the model-specific evaluation DB 33 described with reference to FIG. 26 is completed.
  • the subroutine for calculating the service data for each model according to the present embodiment is a subroutine for calculating and recording data corresponding to the service providing field of the model evaluation DB 33 described with reference to FIG.
  • the process flow of the model-specific service result data subroutine of this embodiment will be described with reference to FIG.
  • CPU 12 records the product of the number of non-contracted device provided extracted in step S805 and the ratio extracted in step S806 in the variable “estimated number” (step S807).
  • the CPU 12 records the sum of the variable “provided number” and the variable “estimated number” in the variable “total provided number” (step S808).
  • the CPU 12 records a value obtained by dividing the number of non-contracted device provision extracted in step S805 by the variable “total number of provisions” in the variable “uncontracted device provision rate” (step S809).
  • the CPU 12 records the calculated provision number, estimated number, total provision number, and unsigned device provision rate in the service provision field of the record extracted in step S802 (step S810).
  • FIG. 28 is a flowchart showing a process flow of a subroutine for calculating the number of unsigned device provision according to the third embodiment.
  • the subroutine for calculating the number of non-contracted devices provided is a subroutine for calculating the number of services provided to the non-contracted devices based on the service performance DB and creating the number of non-contracted devices provided DB described with reference to FIG.
  • the processing flow of the subroutine for calculating the number of non-contracted device contracts will be described with reference to FIG.
  • CPU 12 sets counter I to initial value 1 (step S822).
  • the CPU 12 extracts the I-th record from the model-specific evaluation DB 33 (step S823).
  • the CPU 12 determines whether or not the model code recorded in the record extracted in step S823 is recorded in the model code field of the unsigned device provision number DB (step S824). If it is determined that it is not recorded (NO in step S824), the CPU 12 records the model code in the model code field of the uncontracted device provision number DB (step S825).
  • step S824 When it is determined that it is recorded (YES in step S824) and after the end of step S825, the CPU 12 determines whether or not the processing of the record recorded in the model evaluation DB 33 has ended (step S826). When it is determined that the process has not been completed (NO in step S826), the CPU 12 adds 1 to the counter I (step S827). The CPU 12 returns to step S823.
  • the CPU 12 determines whether or not the processing of the record recorded in the unsigned device provision number DB has been completed (step S837). If it is determined that the process has not been completed (NO in step S837), the CPU 12 adds 1 to the counter I (step S838). The CPU 12 returns to step S832. If it is determined that the process has ended (YES in step S837), the CPU 12 ends the process.
  • the present embodiment relates to the information processing apparatus 11 that performs weighting based on the number of devices sold when the product-by-product evaluation DB 34 is created. Description of portions common to the second embodiment is omitted.
  • FIG. 29 is an explanatory diagram showing a record layout of the sales volume DB according to the fourth embodiment.
  • the sales volume DB is a DB that associates the model code with the sales volume.
  • the sales volume DB has a model code field and a sales volume field.
  • the model code is recorded in the model code field.
  • the unit sold is recorded in the unit sold field.
  • the sales volume DB has one record for each model.
  • the sales volume DB is created, for example, by recording the sales volume calculated in step S644 of the model-specific contract data calculation subroutine described with reference to FIG.
  • FIG. 30 is a flowchart showing a flow of processing of a subroutine for calculating data for each product according to the fourth embodiment.
  • the subroutine shown in FIG. 30 is a subroutine used in place of the commodity data calculation subroutine of the second embodiment described with reference to FIG. With reference to FIG. 30, the flow of processing of the subroutine for calculating data for each product according to the present embodiment will be described.
  • step S674 Since the process up to step S674 is the same as the subroutine described with reference to FIG. 22, the description thereof is omitted.
  • the CPU 12 extracts a record of each model from the sales unit DB using the model code recorded in the model code field of each record extracted in step S674 as a key (step S741).
  • the CPU 12 calculates a weighted average value in which the contract rate recorded in the contract rate field of each record extracted in step S674 is weighted by the number of units sold (step S742).
  • the weighted average value is calculated by, for example, equation (1).
  • CPU12 calculates the dispersion
  • CPU 12 calculates a weighted average value in which the simultaneous purchase rate recorded in the simultaneous purchase rate field of each record extracted in step S674 is weighted by the number of units sold (step S743).
  • the CPU 12 calculates a weighted average value obtained by weighting the unsigned device provision rate recorded in the unsigned device provision rate field of each record extracted in step S674 by the number of units sold (step S744). Note that the calculation method of the weighted average value is the same as that in the equation (1), and thus the description thereof is omitted.
  • CPU12 creates a record in evaluation DB34 classified by goods, and records data on each field (Step S679). Subsequent processing is the same as that shown in FIG.
  • the CPU 12 may calculate a weighted average value of any one or two of the contract rate, the simultaneous purchase rate, and the non-contracted device provision rate.
  • the CPU 12 may perform weighting based on the sales amount or price of each model.
  • FIG. 31 is an explanatory diagram showing a record layout of the contract number DB according to the fifth embodiment.
  • the contract number DB is a DB that associates the product code, the price, and the number of contracts.
  • the contract number DB has a product code field, a price field, and a contract number field.
  • a product code is recorded in the product code field.
  • a price is recorded in the price field.
  • the number of contracts for service products is recorded in the number of contracts field.
  • the contract number DB has one record for each service product.
  • the price field of the contract number DB is recorded based on the price list of service products.
  • a value obtained by summing up the number of contracts calculated in step S646 of the model-specific contract data calculation subroutine described with reference to FIG. 20 for each product code is recorded.
  • FIG. 32 is an explanatory diagram showing a record layout of the ranking DB according to the fifth embodiment.
  • the rank DB shown in FIG. 32 is a DB used in place of the rank DB of the second embodiment described with reference to FIG.
  • the ranking DB of the present embodiment has a product code field, a ranking point field, an overall score field, and a review ranking field.
  • the ranking point field includes a price field, a contract number field, a contract rate field, a contract rate variation field, a non-contracted device provision rate field, and a simultaneous purchase rate field.
  • the product code field, the contract rate field, the contract rate variation field, the non-contracted device provision rate field, the simultaneous purchase rate field, the total score field, and the review rank field are the same as those in FIG.
  • ranking points determined based on the data recorded in the price field of the contract number DB described with reference to FIG. 31 are recorded.
  • the ranking points of the price field are determined in ascending order of price.
  • the information processing apparatus 11 determines the rank of a service product with a high price and a service product with a large number of contracts.
  • the present embodiment relates to an information processing apparatus 11 that also displays past data. Description of portions common to the second embodiment is omitted.
  • FIG. 33 is an explanatory diagram showing a screen for displaying the information processing result of the sixth embodiment.
  • the screen shown in FIG. 33 is a screen that the CPU 12 displays on the display unit 16 instead of the screen of the second embodiment described with reference to FIG.
  • the 33 has a first chart column 27, a data column 26, and a second chart column 28.
  • a radar chart similar to the chart column 25 described with reference to FIG. 18 is displayed.
  • the second chart column 28 displays a radar chart created using the sales DB 31 and the service performance DB as of one year ago.
  • the CPU 12 may store, for example, the product-specific evaluation DB 34 created one year ago in the auxiliary storage device 14 and display it in the second chart column 28.
  • the CPU 12 may create the product-specific evaluation DB 34 based on the model-specific evaluation DB 33 and the product-specific evaluation DB 34 filtered based on the date such as the sales date, and display the product-based evaluation DB 34 on the second chart column 28.
  • the CPU 12 may display three or more chart columns. Different axes may be used for the first chart column 27 and the second chart column 28.
  • a user who is in charge of reviewing service products can review service products to be reviewed by referring to changes in the status of service products.
  • FIG. 34 is a functional block diagram illustrating the operation of the information processing apparatus 11 according to the seventh embodiment.
  • the information processing apparatus 11 operates as follows based on control by the CPU 12.
  • the first calculation unit 61 provides service for each combination of the model to which the device belongs and the service product based on the identification information for identifying the sold device recorded in the sales DB 31 and the presence / absence of a contract for the service product related to the device. Calculate the contract rate of the product.
  • the 2nd calculation part 62 calculates the dispersion
  • the output unit 63 outputs at least one service product selected based on the variation calculated by the second calculation unit 62.
  • FIG. 35 is an explanatory diagram illustrating a configuration of the information processing apparatus 11 according to the eighth embodiment. The configuration of the present embodiment will be described using FIG. Note that description of portions common to the first embodiment is omitted.
  • the computer includes a CPU 12, a main storage device 13, an auxiliary storage device 14, an input unit 15, a display unit 16, a communication unit 17, a reading unit 18, and a bus.
  • the computer is an information processing apparatus such as a general-purpose personal computer.
  • the program 71 is recorded on a portable recording medium 72.
  • the CPU 12 reads the program 71 via the reading unit 18 and stores it in the auxiliary storage device 14.
  • the CPU 12 may read the program 71 stored in the semiconductor memory 73 such as a flash memory mounted in the computer. Furthermore, the CPU 12 may download the program 71 from the communication unit 17 and another server computer (not shown) connected via a network (not shown) and store the program 71 in the auxiliary storage device 14.
  • the program 71 is installed as a computer control program, loaded into the main storage device 13 and executed. Thereby, the computer functions as the information processing apparatus 11 described above.

Landscapes

  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】見直しを行う優先順位が高いサービス商品の候補を出力するプログラム等を提供すること。 【解決手段】プログラムは、販売した機器を特定する識別情報と、前記機器に関連するサービス商品の契約有無とに基づいて、前記機器が属する機種と前記サービス商品との組合せごとに前記サービス商品の契約率を算出し、前記サービス商品ごとに機種間の前記契約率のばらつきを算出し、前記契約率のばらつきに基づいて選択される、少なくとも一つのサービス商品を出力する処理をコンピュータに実行させる。

Description

プログラム、情報処理方法および情報処理装置
　本発明は、プログラム、情報処理方法および情報処理装置に関する。
　コンピュータ等の多機能なハードウェアに対して、メーカから有償保守契約等のサービス商品が提供される場合がある。１つの機器に対して複数のサービス商品が提供され、ユーザがニーズおよび予算に応じて必要なサービス商品を選択する場合がある。また、一つのサービス商品が、複数の機種のハードウェアに対応する場合もある。
　ハードウェアを購入したユーザを、未登録ユーザ、保守契約を締結していない登録ユーザ、保守契約を締結済の登録ユーザの３種類に分けて質問を受け付ける回数等を管理するウェブサーバシステムが開示されている（特許文献１）。
特開２００４－２８８０４３号公報
　特許文献１に開示されているウェブサーバシステムでは、ユーザからの質問状況を記録して、サービス商品の改善を検討するために有効なデータを出力することはできない。
　一つの側面では、見直しを行う優先順位が高いサービス商品の候補を出力するプログラム等を提供することを目的とする。
　プログラムは、販売した機器を特定する識別情報と、前記機器に関連するサービス商品の契約有無とに基づいて、前記機器が属する機種と前記サービス商品との組合せごとに前記サービス商品の契約率を算出し、前記サービス商品ごとに機種間の前記契約率のばらつきを算出し、前記契約率のばらつきに基づいて選択される、少なくとも一つのサービス商品を出力する処理をコンピュータに実行させる。
　一つの側面では、見直しを行う優先順位が高いサービス商品の候補を出力するプログラム等を提供することが可能となる。
情報処理装置の構成を示す説明図である。 ハードウェアの機種とサービス商品との関係を説明する説明図である。 販売ＤＢのレコードレイアウトを示す説明図である。 候補ＤＢのレコードレイアウトを示す説明図である。 機種別評価ＤＢのレコードレイアウトを示す説明図である。 商品別評価ＤＢのレコードレイアウトを示す説明図である。 情報処理結果を表示する画面を示す説明図である。 プログラムの処理の流れを示すフローチャートである。 機種取得のサブルーチンの処理の流れを示すフローチャートである。 機種別契約データ算出のサブルーチンの処理の流れを示すフローチャートである。 商品別データ算出のサブルーチンの処理の流れを示すフローチャートである。 販売ＤＢを作成するプログラムの処理の流れを示すフローチャートである。 実施の形態２のサービス実績ＤＢのレコードレイアウトを示す説明図である。 実施の形態２の機種別評価ＤＢのレコードレイアウトを示す説明図である。 実施の形態２の商品別評価ＤＢのレコードレイアウトを示す説明図である。 実施の形態２の順位ルールＤＢのレコードレイアウトを示す説明図である。 実施の形態２の順位ＤＢのレコードレイアウトを示す説明図である。 実施の形態２の情報処理結果を表示する画面を示す説明図である。 実施の形態２のプログラムの処理の流れを示すフローチャートである。 実施の形態２の機種別契約データ算出のサブルーチンの処理の流れを示すフローチャートである。 実施の形態２の機種別サービス実績データ算出のサブルーチンの処理の流れを示すフローチャートである。 実施の形態２の商品別データ算出のサブルーチンの処理の流れを示すフローチャートである。 実施の形態２の順位付けのサブルーチンの処理の流れを示すフローチャートである。 実施の形態３の無契約機器提供数ＤＢのレコードレイアウトを示す説明図である。 実施の形態３の推定提供率ＤＢのレコードレイアウトを示す説明図である。 実施の形態３の機種別評価ＤＢのレコードレイアウトを示す説明図である。 実施の形態３の機種別サービス実績データ算出のサブルーチンの処理の流れを示すフローチャートである。 実施の形態３の無契約機器提供数算出のサブルーチンの処理の流れを示すフローチャートである。 実施の形態４の販売台数ＤＢのレコードレイアウトを示す説明図である。 実施の形態４の商品別データ算出のサブルーチンの処理の流れを示すフローチャートである。 実施の形態５の契約数ＤＢのレコードレイアウトを示す説明図である。 実施の形態５の順位ＤＢのレコードレイアウトを示す説明図である。 実施の形態６の情報処理結果を表示する画面を示す説明図である。 実施の形態７の情報処理装置の動作を示す機能ブロック図である。 実施の形態８の情報処理装置の構成を示す説明図である。
［実施の形態１］
　図１は、情報処理装置１１の構成を示す説明図である。情報処理装置１１は、ＣＰＵ（Central Processing Unit）１２、主記憶装置１３、補助記憶装置１４、入力部１５、表示部１６、通信部１７、読取部１８およびバスを備える。本実施の形態の情報処理装置１１は、汎用のパーソナルコンピューター、タブレット、大型計算機等の情報機器等である。また、本実施の形態の情報処理装置１１は、大型計算機上で動作する仮想マシンでも良い。
　ＣＰＵ１２は、本実施の形態に係るプログラムを実行する演算制御装置である。ＣＰＵ１２には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。ＣＰＵ１２は、バスを介して情報処理装置１１を構成するハードウェア各部と接続されている。
　主記憶装置１３は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の記憶装置である。主記憶装置１３には、ＣＰＵ１２が行う処理の途中で必要な情報およびＣＰＵ１２で実行中のプログラムが一時的に保存される。
　補助記憶装置１４は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶装置１４には、ＣＰＵ１２に実行させるプログラム、販売ＤＢ（DataBase）３１、候補ＤＢ３２、機種別評価ＤＢ３３、商品別評価ＤＢ３４およびプログラムの実行に必要な各種情報が保存される
　入力部１５は、マウス、キーボード、タッチパネル、ペンタブレット、マイク等の機器であり、ユーザによる操作をＣＰＵ１２が受け付ける際に使用する。表示部１６は、ディスプレイ、プリンタ、プロッタ等の機器であり、ＣＰＵ１２が出力する情報を表示する。通信部１７は、図示しないネットワークとの通信を行うインターフェイスである。
　読取部１８は、後述する可搬型記録媒体７２（図３４参照）を読み取る装置であり、具体的にはたとえばＳＤ（Secure Digital）カードスロット、光学ディスクドライブまたはＵＳＢ（Universal Serial Bus）ポート等である。
　図２は、ハードウェアの機種とサービス商品との関係を説明する説明図である。メーカは、機種Ｓから機種Ｗで示す複数のハードウェア製品を製造販売する。ここで、ＳからＷまでの文字は、機種を特定する機種コードを示す。ハードウェア製品は、たとえば大型計算機、デスクトップパソコン、ノートパソコン、タブレット等の情報処理装置または複数の情報処理装置を組み合わせた情報処理システムである。ハードウェアは、プリンタ、複合機、スキャナ等の情報機器または家電製品等でも良い。ハードウェアは、コンピュータと複数のビデオカメラ等とを組み合わせた監視システム等でも良い。以下の説明では、各機種の製品を機器と記載する。
　メーカは、ハードウェア製品に対する契約Ａから契約Ｆで示す複数のサービス商品も販売する。ここで、ＡからＦまでの文字は、サービス商品を特定する商品コードを示す。サービス商品は、たとえばトラブル発生時のデータ復旧、ファームウェア等のアップデート、電話等による質問への対応、２４時間リモートサポート、出張サポート、消耗品の補給、遠隔による故障診断、遠隔による故障予測等である。
　図２に直線で結んで示すように、機種Ｓには契約Ａと契約Ｃとが対応している。機種Ｔには、契約Ａ、契約Ｂおよび契約Ｃが対応している。契約Ａは、機種Ｓと機種Ｔとに対応している。契約Ｂは機種Ｔおよび機種Ｕに対応している。
　機器の購入者は、購入した機器の機種に対応するサービス商品を選択して購入することができる。サービス商品は、機器と同時に購入することも、後日必要に応じて購入することもできる。機器の購入者は、１台の機器に対して複数のサービス商品を購入する場合もある。また、販促キャンペーン等でメーカまたは販売店が機器の購入者に対してサービス商品を無償で提供する場合もある。
　図３は、販売ＤＢ３１のレコードレイアウトを示す説明図である。販売ＤＢ３１は、販売したハードウェア製品とサービス商品とを関連づけるＤＢである。販売ＤＢ３１は、ハードウェア製品フィールドと、サービス商品フィールドとを有する。ハードウェア製品フィールドは、機種コードフィールド、製造番号フィールドおよび機器販売日フィールドを有する。サービス商品フィールドは、商品コードフィールド、契約日フィールド、開始日フィールドおよび終了日フィールドを有する。
　機種コードフィールドには、販売した機器の機種が記録されている。製造番号フィールドには、販売した機器の製造番号が記録されている。製造番号は、販売した機器の個体を識別する識別情報の一例である。なお、異なる機種間で製造番号が重複する可能性がある場合には、機種コードと製造番号との組合せを識別情報に使用する。以後の説明では識別情報に製造番号を使用する場合を例にして説明する。
　機器販売日フィールドには、機器を販売した日付が記録されている。商品コードフィールドには、機器と組み合わせて販売したサービス商品の商品コードが記録されている。契約日フィールドには、サービス商品を契約した日付が記録されている。開始日フィールドには、サービス契約の開始日が記録されている。終了日フィールドには、サービス契約の終了日が記録されている。
　機器の購入者が、対応するサービス商品を購入していない場合、サービス商品フィールドは空欄である。機器の購入者が複数のサービス商品を購入している場合、販売ＤＢ３１にはそれぞれのサービス商品に対応する複数のレコードが記録される。したがって、販売ＤＢ３１は、販売した機器とサービス商品との１つの組合せについて、１つのレコードを有する。販売ＤＢ３１は、機器およびサービスが販売される都度更新される。
　図４は、候補ＤＢ３２のレコードレイアウトを示す説明図である。候補ＤＢ３２は、見直し候補であるサービス商品の商品コードと商品名とを関連づけるＤＢである。ここで、見直しとは、既存のサービス商品の内容、価格、契約条件、対応するハードウェア製品の機種等を再検討して、サービス商品の改善、販売方法の改善、および新たなサービス商品の開発等を行うことである。候補ＤＢ３２に記録するサービス商品は、メーカの事業計画、サービス商品の開発計画等に基づいて選定される。
　候補ＤＢ３２は、商品コードフィールドと商品名フィールドとを有する。商品コードフィールドには、見直し対象であるサービス商品の商品コードが記録されている。商品名フィールドには、サービス商品の名称が記録されている。候補ＤＢ３２は、１つの見直し候補について、１つのレコードを有する。
　図５は、機種別評価ＤＢ３３のレコードレイアウトを示す説明図である。機種別評価ＤＢ３３は、商品コード、機種コードおよびサービス商品の契約率を関連づけるＤＢである。機種別評価ＤＢ３３は、商品コードフィールド、機種コードフィールドおよび契約率フィールドを有する。
　商品コードフィールドには、見直し対象であるサービス商品の商品コードが記録されている。機種コードフィールドには、商品コードフィールドに記録されたサービス商品に対応するハードウェア製品の機種コードが記録されている。契約率フィールドには、サービス商品の契約数を販売したハードウェア製品の数で除したサービス商品の契約率が記録されている。
　機種別評価ＤＢ３３は、商品コードと機種コードとの組合せについて１つのレコードを有する。機種別評価ＤＢ３３は、本実施の形態のプログラムに基づいてＣＰＵ１２が作成するＤＢである。機種別評価ＤＢ３３を作成する方法の概要を以下に説明する。
　ＣＰＵ１２は、候補ＤＢ３２から１個の候補レコードを取り出す。ＣＰＵ１２は、取り出した候補レコードの商品コードフィールドに記録された商品コードをキーとして、販売ＤＢ３１から販売レコードを抽出する。ＣＰＵ１２は、抽出した販売レコードの機種コードフィールドを参照して、機種コードを重複無く取り出す。なお、重複する情報が記録されたレコードを排除してレコードを取り出す方法は公知であるので説明を省略する。
　ＣＰＵ１２は、商品コードフィールドに候補ＤＢ３２から読み込んだ商品コードを、機種コードフィールドに取り出した機種コードをそれぞれ記録した、機種コードの数と同数のレコードを、機種別評価ＤＢ３３に作成する。
　ＣＰＵ１２は、候補ＤＢ３２に記録されているすべてのサービス商品に対して以上の動作を繰り返す。これにより、ＣＰＵ１２は候補ＤＢ３２に記録されているそれぞれのサービス商品に対応して販売されている機種を抽出し、機種別評価ＤＢ３３に記録することができる。
　ＣＰＵ１２は、機種別評価ＤＢ３３から１個の機種別評価レコードを取り出す。ＣＰＵ１２は取り出した機種別評価レコードの機種コードフィールドに記録されている機種コードをキーとして、販売ＤＢ３１から販売レコードを抽出する。ＣＰＵ１２は、抽出した販売レコードから製造番号フィールドが重複しているレコードを削除した場合の販売レコード数を数えることにより、機種の販売台数を求める。なお、複数のレコードから重複するレコードを削除する方法およびレコードの数を数える方法は公知であるので説明を省略する。
　ＣＰＵ１２は、先に抽出した販売レコードから、機種別評価ＤＢ３３から取り出した前述の機種別評価レコードの商品コードフィールドに記録されている商品コードをキーとして販売レコードを再抽出する。ＣＰＵ１２は、再抽出した販売レコード数を数えることにより、サービス商品の契約数を求める。
　ＣＰＵ１２は、サービス商品の契約数を機種の販売台数で除して、契約率を算出する。ＣＰＵ１２は、前述の機種別評価レコードの契約率フィールドに、契約率を記録する。
　ＣＰＵ１２は、機種別評価ＤＢ３３に記録されたすべてのレコードについて上記の処理を行う。以上により図５を使用して説明した機種別評価ＤＢ３３が完成する。
　図６は、商品別評価ＤＢ３４のレコードレイアウトを示す説明図である。商品別評価ＤＢ３４は、商品コードと、商品コードが示すサービス商品の契約率の平均値およびばらつきとを関連づけるＤＢである。商品別評価ＤＢ３４は、商品コードフィールド、契約率フィールドおよび契約率ばらつきフィールドを有する。
　商品コードフィールドには、見直し対象であるサービス商品の商品コードが記録されている。契約率フィールドには、サービス商品に対応する機種ごとの契約率の平均値が記録されている。契約率ばらつきフィールドには、サービス商品に対応する機種ごとの契約率のばらつきが記録されている。
　商品別評価ＤＢ３４は、見直し対象である一つのサービス商品について１つのレコードを有する。商品別評価ＤＢ３４は、本実施の形態のプログラムに基づいてＣＰＵ１２が作成するＤＢである。商品別評価ＤＢ３４を作成する方法の概要を以下に説明する。
　ＣＰＵ１２は、候補ＤＢ３２から１個の候補レコードを取り出す。ＣＰＵ１２は、取り出した候補レコードの商品コードフィールドに記録された商品コードをキーとして、機種別評価ＤＢ３３からレコードを抽出する。ＣＰＵ１２は、抽出したレコードの契約率フィールドに記録されている契約率の平均値および分散を算出する。ＣＰＵ１２は、商品別評価ＤＢ３４にレコードを作成し、商品コードフィールドに商品コードを、契約率フィールドに平均値を、契約率ばらつきフィールドに分散をそれぞれ記録する。
　ＣＰＵ１２は、候補ＤＢ３２に記録されたすべてのレコードについて上記の処理を行う。以上により図６を使用して説明した商品別評価ＤＢ３４が完成する。
　平均値は、契約率の代表値の一例である。平均値の代わりに、たとえば最頻値、中央値、相乗平均値等を使用しても良い。分散は、契約率のばらつきを示す指標の一例である。分散の代わりに、たとえば標準偏差、最大値と最小値との差等を使用しても良い。
　図７は、情報処理結果を表示する画面を示す説明図である。ＣＰＵ１２は、表示部１６に図７に示す画面を表示する。図７に示す画面は、順位欄２１および内訳欄２２を有する。順位欄２１には、商品別評価ＤＢ３４に記録されたレコードを、契約率ばらつきフィールドに記録された値が大きい順に順位付けしたデータが表示されている。
　ＣＰＵ１２は、あらかじめ定められた順位以上のレコードを順位欄２１に表示しても良い。ＣＰＵ１２は、契約率ばらつきフィールドにあらかじめ定められた値以上の数値が記録されたレコードを順位欄２１に表示しても良い。ＣＰＵ１２は、最上位の１個のレコードのみを順位欄２１に表示しても良い。
　図７では、一位の行の周囲に選択枠２３が表示されている。内訳欄２２には、選択枠２３で囲まれた行の商品コードに対応する機種別評価ＤＢ３３に記録されたデータが表示されている。具体的には、選択枠２３は商品コードにＢが表示された行を囲んでいる。内訳欄２２には、機種別評価ＤＢ３３のうち、商品コードがＢであるレコードが表示されている。
　ＣＰＵ１２は、入力部１５を介して選択枠２３が囲む行の選択を受け付ける。ＣＰＵ１２は、選択枠２３が囲む行に合わせて内訳欄２２に表示するデータを変更する。
　サービス商品の見直しを担当するユーザは、図７に示す画面を見ることにより機種ごとの契約率のばらつきが大きいサービス商品を認識することができる。契約率のばらつきが大きいサービス商品は、たとえば契約率が低い機種の購入者を対象とした販促活動を強化することにより、販売数を増加させることができる可能性がある。契約率が低い機種を組合せ対象外に変更することにより、コストを削減して収益性を高めることができる可能性もある。このような、サービス商品の具体的な改善策の検討には、時間および手間を要する。図７に示す画面を表示部１６に出力してユーザに提示することにより、ユーザは見直しによる効果が高いと期待できるサービス商品の見直しに優先的に取り組むことができる。
　図８は、プログラムの処理の流れを示すフローチャートである。図８を使用して、本実施の形態のプログラムの処理の流れを説明する。
　ＣＰＵ１２は、機種取得のサブルーチンを起動する（ステップＳ５０１）。機種取得のサブルーチンは、候補ＤＢ３２に記録されたサービス商品と組み合わせて販売されているハードウェア製品の機種を、販売ＤＢ３１を検索して取得するサブルーチンである。機種取得のサブルーチンの処理の流れは後述する。機種取得のサブルーチンの終了後、補助記憶装置１４には契約率フィールドが空欄の機種別評価ＤＢ３３が記憶されている。
　ＣＰＵ１２は、機種別契約データ算出のサブルーチンを起動する（ステップＳ５０２）。機種別契約データ算出のサブルーチンは、機種別評価ＤＢ３３の契約率フィールドに対応するデータを算出して記録するサブルーチンである。機種別契約データ算出のサブルーチンの処理の流れは後述する。機種別契約データ算出のサブルーチンの終了後、補助記憶装置１４には完成した機種別評価ＤＢ３３が記憶されている。
　ＣＰＵ１２は、商品別データ算出のサブルーチンを起動する（ステップＳ５０３）。商品別データ算出のサブルーチンは、機種別評価ＤＢ３３に基づいて商品別評価ＤＢ３４を作成するサブルーチンである。商品別データ算出のサブルーチンの処理の流れは後述する。商品別データ算出のサブルーチンの終了後、補助記憶装置１４には完成した商品別評価ＤＢ３４が記憶されている。
　ＣＰＵ１２は、契約率ばらつきフィールドに記録された数値が大きいレコードから順番に、商品別評価ＤＢ３４に記録されたレコードを順位付けする（ステップＳ５０４）。ＣＰＵ１２は、図５を使用して説明した画面を表示部１６に表示する（ステップＳ５０５）。ＣＰＵ１２は、以上で処理を終了する。
　図９は、機種取得のサブルーチンの処理の流れを示すフローチャートである。機種取得のサブルーチンは、候補ＤＢ３２に記録されたサービス商品と組み合わせて販売されているハードウェア製品の機種を、販売ＤＢ３１を検索して取得するサブルーチンである。図９を使用して、機種取得のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、機種別評価ＤＢ３３を初期化する（ステップＳ５１１）。具体的には、補助記憶装置１４に機種別評価ＤＢ３３が記憶されている場合、ＣＰＵ１２は機種別評価ＤＢ３３に記憶されているすべてのレコードを削除する。補助記憶装置１４に機種別評価ＤＢ３３が記憶されていない場合、ＣＰＵ１２は、レコードを有さない機種別評価ＤＢ３３を作成する。
　ＣＰＵ１２は、カウンタＪを初期値１に設定する（ステップＳ５１２）。ＣＰＵ１２は、候補ＤＢ３２のＪ番目のレコードを抽出する（ステップＳ５１３）。ＣＰＵ１２は、ステップＳ５１３で抽出したレコードの商品コードフィールドに記録されている商品コードをキーとして、販売ＤＢ３１からレコードを抽出する（ステップＳ５１４）。具体的には、ＣＰＵ１２は、販売ＤＢ３１から商品コードフィールドにキーの商品コードと同一のデータが記録されているレコードを抽出する。
　ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ５１５）。ＣＰＵ１２は、ステップＳ５１４で抽出したレコードのうちＩ番目のレコードを取得する（ステップＳ５１６）。
　ＣＰＵ１２は、ステップＳ５１６で取得したレコードの商品コードフィールドに記録されている商品コードと機種コードフィールドに記録されている機種コードとの組合せが、機種別評価ＤＢ３３に記録されているか否かを判定する（ステップＳ５１７）。記録されていないと判定した場合（ステップＳ５１７でＮＯ）、ＣＰＵ１２は機種別評価ＤＢ３３に新たなレコードを作成し、商品コードフィールドおよび機種コードフィールドにステップＳ５１６で取得したレコードと同じデータを記録する（ステップＳ５１８）。
　記録されていると判定した場合（ステップＳ５１７でＹＥＳ）またはステップＳ５１８の終了後、ＣＰＵ１２はステップＳ５１４で抽出したすべての販売レコードの処理が終了したか否を判定する（ステップＳ５１９）。終了していないと判定した場合（ステップＳ５１９でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ５２０）。その後、ＣＰＵ１２はステップＳ５１６に戻る。
　終了したと判定した場合（ステップＳ５１９でＹＥＳ）、ＣＰＵ１２は、候補ＤＢ３２に記録されたすべての候補レコードの処理が終了したか否かを判定する（ステップＳ５２１）。終了していないと判定した場合（ステップＳ５２１でＮＯ）、ＣＰＵ１２はカウンタＪに１を加算する（ステップＳ５２２）。その後、ＣＰＵ１２はステップＳ５１３に戻る。終了したと判定した場合（ステップＳ５２１でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　図１０は、機種別契約データ算出のサブルーチンの処理の流れを示すフローチャートである。機種別契約データ算出のサブルーチンは、機種別評価ＤＢ３３の契約率フィールドに対応するデータを算出して記録するサブルーチンである。図１０を使用して、機種別契約データ算出のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２はカウンタＩを初期値１に設定する（ステップＳ５４１）。ＣＰＵ１２は、機種別評価ＤＢ３３からＩ番目のレコードを抽出する（ステップＳ５４２）。ＣＰＵ１２は、ステップＳ５４２で抽出したレコードの機種コードフィールドに記録された機種コードをキーとして、販売ＤＢ３１からレコードを抽出する（ステップＳ５４３）。
　ＣＰＵ１２は、ステップＳ５４３で抽出したレコードから、製造番号フィールドに記録されている製造番号が重複しているレコードを削除した場合のレコード数を算出し、変数「販売台数」に記録する（ステップＳ５４４）。
　ＣＰＵ１２は、ステップＳ５４３で抽出したレコードから、ステップＳ５４２で抽出したレコードの商品コードフィールドに記録された商品コードをキーとして、レコードを再抽出する（ステップＳ５４５）。
　ＣＰＵ１２は、ステップＳ５４５で再抽出したレコードの数を数え、変数「契約数」に記録する（ステップＳ５４６）。ＣＰＵ１２は、変数「契約数」を変数「販売台数」で除して契約率を算出する（ステップＳ５４７）。
　ＣＰＵ１２は、ステップＳ５４７で算出した契約率をステップＳ５４２で抽出したレコードの契約率フィールドに記録する（ステップＳ５４８）。ＣＰＵ１２は、機種別評価ＤＢ３３のすべてのレコードの処理を終了したか否かを判定する（ステップＳ５４９）。終了していないと判定した場合（ステップＳ５４９でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ５５０）。その後、ＣＰＵ１２はステップＳ５４２に戻る。
　終了したと判定した場合（ステップＳ５４９でＹＥＳ）、ＣＰＵ１２は処理を終了する。機種別契約データ算出のサブルーチンの終了後、補助記憶装置１４には完成した機種別評価ＤＢ３３が記憶されている。
　図１１は、商品別データ算出のサブルーチンの処理の流れを示すフローチャートである。商品別データ算出のサブルーチンは、機種別評価ＤＢ３３に基づいて商品別評価ＤＢ３４を作成するサブルーチンである。図１１を使用して、商品別データ算出のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、商品別評価ＤＢ３４を初期化する（ステップＳ５７１）。具体的には、補助記憶装置１４に商品別評価ＤＢ３４が記憶されている場合、ＣＰＵ１２は商品別評価ＤＢ３４に記憶されているすべてのレコードを削除する。補助記憶装置１４に商品別評価ＤＢ３４が記憶されていない場合、ＣＰＵ１２は、レコードを有さない商品別評価ＤＢ３４を作成する。
　ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ５７２）。ＣＰＵ１２は、候補ＤＢ３２からＩ番目のレコードを抽出する（ステップＳ５７３）。ＣＰＵ１２は、ステップＳ５７３で抽出したレコードの商品コードフィールドに記録されている商品コードをキーとして、機種別評価ＤＢ３３からレコードを抽出する（ステップＳ５７４）。
　ＣＰＵ１２は、ステップＳ５７４で抽出したレコードの契約率フィールドに記録されているデータの平均値を算出する（ステップＳ５７５）。ＣＰＵ１２は、ステップＳ５７４で抽出したレコードの契約率フィールドに記録されているデータのばらつきを算出する（ステップＳ５７６）。なお、平均値の代わりに、たとえば最頻値、中央値、相乗平均値等を使用しても良い。ばらつきは、たとえば分散、標準偏差または最大値と最小値の差等である。
　ＣＰＵ１２は、商品別評価ＤＢ３４にレコードを作成し、各フィールドにデータを記録する（ステップＳ５７７）。具体的には、ＣＰＵ１２は、作成するレコードの商品コードフィールドに、ステップＳ５３７で抽出したレコードの商品コードフィールドに記録されている商品コードを記録する。ＣＰＵ１２は、作成するレコードの契約率フィールドに、ステップＳ５７５で算出した平均値を記録する。ＣＰＵ１２は、作成するレコードのばらつきフィールドに、ステップＳ５７６で算出したばらつきを記録する。
　ＣＰＵ１２は候補ＤＢ３２に記録されたすべてのレコードの処理を終了したか否かを判定する（ステップＳ５７８）。終了していないと判定した場合（ステップＳ５７８でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ５７９）。その後、ＣＰＵ１２はステップＳ５７３に移動する。終了したと判定した場合（ステップＳ５７８でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　図１２は、販売ＤＢ３１を作成するプログラムの処理の流れを示すフローチャートである。図１２を使用して、販売ＤＢ３１を作成するプログラムの処理の流れを説明する。
　ＣＰＵ１２は、販売データを取得する（ステップＳ５９１）。販売データは、たとえば販売店のＰＯＳ（Point Of Sale）データを図示しないネットワークを介して取得する。また、営業部門のオペレータ等が入力したデータを取得しても良い。
　販売データについて説明する。ハードウェア製品が単独で販売された場合、販売データには販売した機器の機種コード、製造番号および機器販売日が含まれる。サービス商品が単独で販売された場合、販売データには販売したサービス商品の商品コード、契約日、契約開始日、契約終了日およびサービス商品の対象であるハードウェア製品の製造番号が含まれる。ハードウェア製品と対応するサービス商品が同時に販売された場合、販売データには販売した機器の機種コード、製造番号、機器販売日、サービス商品の商品コード、契約日、契約開始日および契約終了日が含まれる。
　ＣＰＵ１２は、ステップＳ５９１で取得した販売データがサービス商品の販売のみであるか否かを判定する（ステップＳ５９２）。サービス商品の販売のみであると判定した場合（ステップＳ５９２でＹＥＳ）、ＣＰＵ１２はサービス商品の対象であるハードウェア製品の製造番号をキーとして販売ＤＢ３１を検索してレコードを抽出する（ステップＳ５９３）。
　ＣＰＵ１２は、抽出したレコードのサービス商品フィールドに記録があるか否かを判定する（ステップＳ５９４）。サービス商品フィールドに記録がないと判定した場合（ステップＳ５９４でＮＯ）、ＣＰＵ１２はステップＳ５９３で抽出したレコードのサービス商品フィールドに、ステップＳ５９１で取得した販売データを記録する（ステップ５９５）。これは、機器を購入した顧客が後日サービス商品を追加で購入した場合の処理である。ＣＰＵ１２は、その後処理を終了する。
　サービス商品フィールドに記録があると判定した場合（ステップＳ５９４でＹＥＳ）、ＣＰＵ１２はステップＳ５９４で抽出したレコードの商品コードフィールドに記録されている商品コードと、ステップＳ５９１で取得したサービス商品の商品コードとが同一であるか否かを判定する（ステップＳ５９６）。同一であると判定した場合（ステップＳ５９６でＹＥＳ）、ＣＰＵ１２はステップＳ５９３で抽出したレコードを更新する（Ｓ５９７）。具体的には、ＣＰＵ１２は終了日フィールドに記録されている日付をステップＳ５９１で取得した終了日に変更する。これは、既にサービスを購入済の顧客が、契約期間を延長した場合の処理である。ＣＰＵ１２は、その後処理を終了する。
　同一でないと判定した場合（ステップＳ５９６でＮＯ）、ＣＰＵ１２は販売ＤＢ３１にレコードを追加する（ステップＳ５９８）。具体的には、ＣＰＵ１２はハードウェア製品フィールドにステップＳ５９４で抽出したレコードと同一のデータが記録されているレコードを販売ＤＢ３１に追加する。ＣＰＵ１２は、追加したレコードのサービス商品フィールドに、ステップＳ５９１で取得した販売レコードを記録する。これは、既にサービスを購入済の顧客が、同じハードウェア製品に対応する別のサービス商品を購入した場合の処理である。ＣＰＵ１２は、その後処理を終了する。
　サービス商品の販売のみではないと判定した場合（ステップＳ５９２でＮＯ）、ＣＰＵ１２は販売ＤＢ３１にレコードを追加し、ステップＳ５９２で取得した販売データを記録する（ステップＳ５９９）。これはハードウェア製品が販売された場合またはハードウェア製品とそれに対応するサービス商品とが販売された場合の処理である。ＣＰＵ１２は、その後処理を終了する。以上の処理により、図３を使用して説明した販売ＤＢ３１が作成される。
　本実施の形態によると、見直しを行う優先順位が高いサービス商品の候補を出力するプログラム等を提供することができる。また、販売ＤＢ３１に記録されているデータに対してユーザが直接アクセスしないので、情報流出等を防止することができる。
　あらかじめ所定の条件でフィルタリングした販売ＤＢ３１を使用しても良い。所定の条件は、たとえば機器販売日または契約日が所定の期間であること、特定の事業部門の製品であること、特定の業種の顧客に販売した機器であること等である。このようにすることにより、本実施の形態のプログラムの情報処理量を削減することができる。なお、ユーザがフィルタリングの条件を設定できるようにしても良い。このようにすることにより、様々な角度からデータを検討することも可能になる。
　使用するＤＢの一部または全部が、図示しないネットワークを介して接続された記憶装置に記憶されていても良い。
［実施の形態２］
　本実施の形態は、ハードウェア製品を購入した顧客に対するサービス提供実績および機器とサービス商品と同時購入率を優先順位の判定に使用する情報処理装置１１に関する。実施の形態１と共通する部分については、説明を省略する。
　図１３は、実施の形態２のサービス実績ＤＢのレコードレイアウトを示す説明図である。サービス実績ＤＢは、販売したハードウェア製品と、お客様ＩＤ（IDentification）と、サービス商品と、顧客からの連絡日とを関連づけるＤＢである。サービス実績ＤＢは、ハードウェア製品フィールドと、お客様ＩＤフィールドと、サービス商品フィールドと、連絡日フィールドとを有する。
　ハードウェア製品フィールドは、機種コードフィールドおよび製造番号フィールドを有する。サービス商品フィールドは、商品コードフィールド、契約日フィールド、開始日フィールドおよび終了日フィールドを有する。
　機種コードフィールドには、販売した機器の機種が記録されている。製造番号フィールドには、販売した機器の製造番号が記録されている。お客様ＩＤフィールドには、機器を購入した顧客を識別するＩＤが記録されている。商品コードフィールドには、機器と組み合わせて販売したサービス商品の商品コードが記録されている。契約日フィールドには、サービス商品を契約した日付が記録されている。開始日フィールドには、サービス契約の開始日が記録されている。終了日フィールドには、サービス契約の終了日が記録されている。連絡日フィールドには、顧客からの連絡を受け付けた日付が記録されている。
　サービス実績ＤＢは、顧客からの連絡を受け付けるサービス部門等が、連絡を受け付ける都度データ入力するＤＢである。ハードウェア製品を購入しているが、対応するサービス商品を購入していない顧客からの連絡を受け付けた場合、サービス部門は連絡内容に対応するサービス商品を商品コードフィールドに記録し、契約日フィールド、開始日フィールドおよび終了日フィールドを空欄にする。サービス実績ＤＢは、顧客からの１回の連絡について１つのレコードを有する。
　図１４は、実施の形態２の機種別評価ＤＢ３３のレコードレイアウトを示す説明図である。本実施の形態の機種別評価ＤＢ３３は、商品コード、機種コード、サービス商品の契約率、機器とサービス商品との同時購入率およびサービス商品が購入されていない機器に対するサービスの提供率を関連づけるＤＢである。機種別評価ＤＢ３３は、商品コードフィールド、機種コードフィールド、契約率フィールド、同時購入率フィールドおよび無契約機器提供率フィールドを有する。
　商品コードフィールドには、見直し対象であるサービス商品の商品コードが記録されている。機種コードフィールドには、商品コードフィールドに記録されたサービス商品に対応するハードウェア製品の機種コードが記録されている。契約率フィールドには、サービス商品の契約数を販売したハードウェア製品の数で除したサービス商品の契約率が記録されている。
　同時購入率フィールドには、機器と同時に販売したサービス商品の契約数を当該サービス商品の総契約数で除した同時購入率が記録されている。同時購入率は、本実施の形態の第２比率の一例である。
　第２比率には、機器と同時に販売したサービス商品の契約数を機器の販売数で除した価を使用しても良い。機器を販売した後たとえば１ヶ月以内に販売したサービス商品を、機器と同時に販売したサービス商品とみなして、第２比率を算出しても良い。
　無契約機器提供率フィールドには、対応するサービス商品が購入されていない機器に対するサービス提供数を当該サービスの合計提供数で除した値が記録されている。以後の説明では、対応するサービス商品が購入されていない機器を無契約機器と記載する場合がある。また、無契約機器に対するサービスの提供率を無契約機器提供率と記載する場合がある。無契約機器提供率は、本実施形態の第１比率の一例である。
　第１比率には、無契約機器に対するサービス提供数を当該サービスの契約数で除した値を使用しても良い。第１比率には、無契約機器に対するサービス提供を受けた顧客の人数を、サービスを契約した顧客の人数で除した値を使用しても良い。
　なお、無契約機器には、対応するサービス商品が購入されているが、契約範囲外のサービスを提供した機器を含む。たとえば、電話によるサポートを提供するサービス商品のみを契約している機器に対して出張サポートを提供した場合には、無契約機器に対するサービスの提供である。また、複数の機器を購入し、そのうちの一部の機器に対応するサービス商品を購入している顧客に対して、契約対象外の機器に対するサービスを提供した場合も、無契約機器に対するサービスの提供である。
　機種別評価ＤＢ３３は、商品コードと機種コードとの組合せについて１つのレコードを有する。機種別評価ＤＢ３３は、本実施の形態のプログラムに基づいてＣＰＵ１２が作成するＤＢである。機種別評価ＤＢ３３を作成する方法の概要を以下に説明する。
　商品コードフィールド、機種コードフィールドおよび契約率フィールドについては、図５を使用して説明した実施の形態１の機種別評価ＤＢ３３と同様であるので、説明を省略する。機種別評価ＤＢ３３の商品コードフィールドおよび機種コードフィールドにデータが記録されている状態から説明を行う。
　ＣＰＵ１２は、機種別評価ＤＢ３３から１個の機種別評価レコードを取り出す。ＣＰＵ１２は取り出した機種別評価レコードの機種コードフィールドに記録されている機種コードをキーとして、販売ＤＢ３１から販売レコードを抽出する。ＣＰＵ１２は、抽出した販売レコードから製造番号フィールドが重複しているレコードを削除した場合の販売レコード数を数えることにより、機種の販売台数を求める。
　ＣＰＵ１２は、先に抽出した販売レコードから、機種別評価ＤＢ３３から取り出した前述の機種別評価レコードの商品コードフィールドに記録されている商品コードをキーとして販売レコードを再抽出する。ＣＰＵ１２は、再抽出したレコードの数を数えることにより、サービス商品の契約数を求める。
　ＣＰＵ１２は、再抽出した販売レコードから機器販売日フィールドと契約日フィールドに同一の日付が記録されているレコードを再々抽出する。ＣＰＵ１２は、再々抽出したレコードの数を数えることにより、機器と同時に購入されたサービス商品の数を求める。
　ＣＰＵ１２は、機器と同時に購入されたサービス商品の数を契約数で除することにより、同時購入率を算出する。ＣＰＵ１２は、前述の機種別評価レコードの同時購入率フィールドに算出した同時購入率を記録する。
　ＣＰＵ１２は前述の機種別評価レコードの機種コードフィールドに記録されている機種コードをおよび商品コードフィールドに記録されている商品コードをキーとして、サービス実績ＤＢからサービス実績レコードを抽出する。ＣＰＵ１２は、抽出したサービス実績レコードの数を数えることによりサービスの合計提供数を求める。
　ＣＰＵ１２は、抽出したサービス実績レコードから、契約日が空欄であるレコードを再抽出する。ＣＰＵ１２は、再抽出したレコード数を数えることにより、契約を締結していない機器に対するサービスの提供数を求める。ＣＰＵ１２は、無契約機器に対するサービスの提供数をサービスの合計提供数で除して、無契約機器提供率を算出する。ＣＰＵ１２は、前述の機種別評価レコードの無契約機器提供率フィールドに無契約機器提供率を記録する。
　ＣＰＵ１２は、機種別評価ＤＢ３３に記録されたすべてのレコードについて上記の処理を行う。以上により図１４を使用して説明した機種別評価ＤＢ３３が完成する。
　図１５は、実施の形態２の商品別評価ＤＢ３４のレコードレイアウトを示す説明図である。商品別評価ＤＢ３４は、商品コードと、サービス商品の契約率の平均値およびばらつきと、同時購入率の平均値と無契約機器提供率の平均値とを関連づけるＤＢである。商品別評価ＤＢ３４は、商品コードフィールド、契約率フィールド、契約率ばらつきフィールド、同時購入率フィールドおよび無契約機器提供率フィールドを有する。
　商品コードフィールドには、見直し対象であるサービス商品の商品コードが記録されている。契約率フィールドには、サービス商品に対応する機種ごとの契約率の平均値が記録されている。契約率ばらつきフィールドには、サービス商品に対応する機種ごとの契約率のばらつきが記録されている。
　商品別評価ＤＢ３４は、見直し対象である一つのサービス商品について１つのレコードを有する。商品別評価ＤＢ３４は、本実施の形態のプログラムに基づいてＣＰＵ１２が作成するＤＢである。商品別評価ＤＢ３４を作成する方法の概要を以下に説明する。
　ＣＰＵ１２は、候補ＤＢ３２から１個の候補レコードを取り出す。ＣＰＵ１２は、取り出した候補レコードの商品コードフィールドに記録された商品コードをキーとして、機種別評価ＤＢ３３からレコードを抽出する。ＣＰＵ１２は、抽出したレコードの契約率フィールドに記録されている契約率の平均値および分散を算出する。ＣＰＵ１２は、抽出したレコードの同時購入率フィールドに記録されている同時購入率の平均値を算出する。ＣＰＵ１２は、抽出したレコードの無契約機器提供率フィールドに記録されている無契約機器提供率の平均値を算出する。ＣＰＵ１２は、商品別評価ＤＢ３４にレコードを作成し、各フィールドに商品コード、契約率、契約率ばらつき、同時購入率および無契約機器提供率を記録する。
　ＣＰＵ１２は、候補ＤＢ３２に記録されたすべてのレコードについて上記の処理を行う。以上により図１５を使用して説明した商品別評価ＤＢ３４が完成する。
　図１６は、実施の形態２の順位ルールＤＢのレコードレイアウトを示す説明図である。順位ルールＤＢは、商品別評価ＤＢ３４の各フィールドの項目と順位付けを行うルールとを関連づけるＤＢである。順位ＤＢは、項目フィールドおよびルールフィールドを有する。
　項目フィールドには、商品別評価ＤＢ３４のフィールド名に対応する項目名が記録されている。ルールフィールドには、順位付けを行う際のルールが記録されている。具体例を挙げて説明する。契約率の項目の順位付けを行う際のルールは、大きい順である。
　図１７は、実施の形態２の順位ＤＢのレコードレイアウトを示す説明図である。順位ＤＢは、商品コード、順位点、総合点および見直し順位を関連づけるＤＢである。順位ＤＢは、商品コードフィールド、順位点フィールド、総合点フィールドおよび見直し順位フィールドを有する。順位点フィールドは、図１５を使用して説明した商品別評価ＤＢ３４と同じ名称のフィールドを有する。
　順位点について説明する。順位点は、図１５を使用して説明した商品別評価ＤＢ３４の各フィールドの項目を、図１６を使用して説明した順位ルールＤＢに記録されたルールにしたがって順位づけして定めた点数である。
　具体例を挙げて説明する。図１６に示す順位ルールＤＢによると、契約率の順位づけのルールは「大きい順」である。図１５に示す商品別評価ＤＢ３４について、契約率が大きい順に商品コードを示すと、Ｆ、Ｂ、Ａの順番である。したがって、ＣＰＵ１２は契約率の一位は商品コードＦ、二位は商品コードＢ、３位は商品コードＡであると判定する。図１７に示す順位点ＤＢでは、この順位を示す数字をそのまま順位点に使用する。すなわち、商品コードＡの契約率フィールドには３位に対応する順位点３が記録されている。商品コードＢの契約率フィールドには２位に対応する順位点２が記録されている。商品コードＡの契約率フィールドには１位に対応する順位点１が記録されている。
　総合点フィールドには、順位点フィールドに記録された順位点の合計が記録されている。たとえば、商品コードＡについては、順位点フィールドには、３、１、２、１の各順位点が記録されているので、これらの合計である７が総合点フィールドに記録されている。
　見直し順位フィールドには、総合点の大きい方から付けた順位を示す数字が記録されている。図１７に示す順位ＤＢについては、総合点が一番大きい商品コードＢの見直し順位が１位である。
　見直し順位の考え方について、図１６および図１７を使用して説明する。図１６を使用して説明した順位ルールＤＢは、項目ごとに見直しの優先順位が低くなる特性に高い順位が付くように定められている。具体的に説明する。契約率が大きいサービス商品は、既に顧客の要求に合致している商品であり、見直しの優先順位は低い。したがって契約率は「大きい順」に順位を付ける。
　契約率ばらつきが大きいサービス商品は、ハードウェア製品の機種によって契約率が異なる。契約率が特に低い製品の契約率を上げることにより、販売数を伸ばすことができる可能性がある。逆に、契約率が特に低い製品を対象外にする等により、コストを低減することができる可能性がある。このように、見直しによる効果が期待できるため、見直しの優先度が高い。したがって、契約率ばらつきは「小さい順」に順位を付ける。位である。
　同時購入率が大きいサービス商品は、ハードウェア製品を購入した顧客の多くがサービス商品も既に購入している。したがって、見直しを行ってもサービス商品の販売数を伸ばせる余地が少なく、見直しの優先順位は低い。したがって、同時購入率は「大きい順」に順位を付ける。
　無契約機器提供率が大きいサービス商品は、サービス商品を購入していない顧客がサービスの提供を求めている。すなわち、顧客のニーズが高いサービス商品であり、見直しを行うことにより販売数を伸ばせる可能性が高い。したがって、無契約機器提供率は「小さい順」に順位を付ける。
　なお、ルールＤＢに記録するルールは、「大きい順」と「小さい順」とに限定しない。たとえば、あらかじめ定めた値に近い方から、または遠い方から順位を付けるルールでも良い。
　図１８は、実施の形態２の情報処理結果を表示する画面を示す説明図である。ＣＰＵ１２は、表示部１６に図１８に示す画面を表示する。図１８に示す画面は、チャート欄２５およびデータ欄２６を有する。チャート欄２５には、図１７を使用して説明した順位ＤＢの順位点フィールドに記録されたデータがレーダチャートにより表示されている。データ欄２６には、図１５を使用して説明した商品別評価ＤＢ３４に記録されたデータが、順位ＤＢの見直し順位フィールドに記録された順番で表示されている。
　ＣＰＵ１２は、あらかじめ定められた順位以上のレコードをチャート欄２５およびデータ欄２６に表示しても良い。ＣＰＵ１２は、商品別評価ＤＢ３４の契約率ばらつきフィールドにあらかじめ定められた値以上の数値が記録されたレコードをチャート欄２５およびデータ欄２６に表示しても良い。
　実施の形態１と同様に、ＣＰＵ１２は、入力部１５を介してデータ欄２６の行の選択を受け付けて、内訳欄２２（図７参照）を表示しても良い。
　サービス商品の見直しを担当するユーザは、図１８に示す画面を見ることにより実施の形態１よりもさらに詳細に見直しを行うサービス商品を検討することができる。
　図１９は、実施の形態２のプログラムの処理の流れを示すフローチャートである。図１９を使用して、本実施の形態のプログラムの処理の流れを説明する。
　ＣＰＵ１２は、機種取得のサブルーチンを起動する（ステップＳ６０１）。機種取得のサブルーチンは、図９を使用して説明したサブルーチンと同一のサブルーチンを使用する。ＣＰＵ１２は、機種別契約データ算出のサブルーチンを起動する（ステップＳ６０２）。本実施の形態の機種別契約データ算出のサブルーチンは、図１４を使用して説明した機種別評価ＤＢ３３の契約率フィールドおよび同時購入率フィールドに対応するデータを算出して記録するサブルーチンである。機種別契約データ算出のサブルーチンの処理の流れは後述する。
　ＣＰＵ１２は、機種別サービス実績データ算出のサブルーチンを起動する（ステップＳ６０３）。機種別サービス実績データ算出のサブルーチンは、図１４を使用して説明した機種別評価ＤＢ３３の無契約機器提供率フィールドに対応するデータを算出して記録するサブルーチンである。機種別サービス実績データ算出のサブルーチンの処理の流れは後述する。機種別サービス実績データ算出のサブルーチンの終了後、補助記憶装置１４には完成した本実施の形態の機種別評価ＤＢ３３が記憶されている。
　ＣＰＵ１２は、商品別データ算出のサブルーチンを起動する（ステップＳ６０４）。商品別データ算出のサブルーチンは、機種別評価ＤＢ３３に基づいて図１５を使用して説明した本実施の形態の商品別評価ＤＢ３４を作成するサブルーチンである。商品別データ算出のサブルーチンの処理の流れは後述する。商品別データ算出のサブルーチンの終了後、補助記憶装置１４には完成した本実施の形態の商品別評価ＤＢ３４が記憶されている。
　ＣＰＵ１２は、順位付けのサブルーチンを起動する（ステップＳ６０５）。順位付けのサブルーチンは、商品別評価ＤＢ３４に基づいて図１７を使用して説明した順位ＤＢを作成するサブルーチンである。順位付けのサブルーチンの処理の流れは後述する。
　ＣＰＵ１２は、図１８を使用して説明した画面を表示部１６に表示する（ステップＳ６０６）。ＣＰＵ１２は、以上で処理を終了する。
　図２０は、実施の形態２の機種別契約データ算出のサブルーチンの処理の流れを示すフローチャートである。本実施の形態の機種別契約データ算出のサブルーチンは、図１４を使用して説明した機種別評価ＤＢ３３の契約率フィールドおよび同時購入率フィールドに対応するデータを算出して記録するサブルーチンである。図２０を使用して、機種別契約データ算出のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２はカウンタＩを初期値１に設定する（ステップＳ６４１）。ＣＰＵ１２は、機種別評価ＤＢ３３からＩ番目のレコードを抽出する（ステップＳ６４２）。ＣＰＵ１２は、ステップＳ６４２で抽出したレコードの機種コードフィールドに記録された機種コードをキーとして、販売ＤＢ３１からレコードを抽出する（ステップＳ６４３）。
　ＣＰＵ１２は、ステップＳ６４３で抽出したレコードから、製造番号フィールドに記録されている製造番号が重複しているレコードを削除した場合のレコード数を算出し、変数「販売台数」に記録する（ステップＳ６４４）。
　ＣＰＵ１２は、ステップＳ６４３で抽出したレコードから、ステップＳ６４２で抽出したレコードの商品コードフィールドに記録された商品コードをキーとして、レコードを再抽出する（ステップＳ６４５）。
　ＣＰＵ１２は、ステップＳ６４５で再抽出したレコードの数を数え、変数「契約数」に記録する（ステップＳ６４６）。ＣＰＵ１２は、変数「契約数」を変数「販売台数」で除して契約率を算出する（ステップＳ６４７）。
　ＣＰＵ１２は、ステップＳ６４５で再抽出したレコードから機器販売日フィールドと契約日フィールドとに同一のデータが記録されているレコードを再々抽出する（ステップＳ６４８）。ＣＰＵ１２は、再々抽出したレコードの数を変数「同時購入数」に記録する（ステップＳ６４９）。
　ＣＰＵ１２は、変数「同時購入率」に、変数「同時購入数」を変数「契約数」で除した値を記録する（ステップＳ６５０）。ＣＰＵ１２は、算出した契約率および同時購入率をステップＳ６４２で抽出したレコードの契約率フィールドおよび同時購入率フィールドに記録する（ステップＳ６５１）。
　ＣＰＵ１２は、機種別評価ＤＢ３３のすべてのレコードの処理を終了したか否かを判定する（ステップＳ６５２）。終了していないと判定した場合（ステップＳ６５２でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ６５３）。その後、ＣＰＵ１２はステップＳ６４２に戻る。終了したと判定した場合（ステップＳ６５２でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　図２１は、実施の形態２の機種別サービス実績データ算出のサブルーチンの処理の流れを示すフローチャートである。機種別サービス実績データ算出のサブルーチンは、図１４を使用して説明した機種別評価ＤＢ３３の無契約機器提供率フィールドに対応するデータを算出して記録するサブルーチンである。図２１を使用して、機種別サービス実績データ算出のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ７０１）。ＣＰＵ１２は、機種別評価ＤＢ３３からＩ番目のレコードを抽出する（ステップＳ７０２）。ＣＰＵ１２は、ステップＳ７０２で抽出したレコードに記録された商品コードおよび機種コードキーとして、サービス実績ＤＢからレコードを抽出する（ステップＳ７０３）。ＣＰＵ１２は、変数「合計提供数」にステップＳ７０３で抽出したレコードの数を記録する（ステップＳ７０４）。
　ＣＰＵ１２は、ステップＳ７０３で抽出したレコードから、契約日が空欄であるレコードを再抽出する（ステップＳ７０５）。ＣＰＵ１２は、変数「無契約機器提供数」にステップＳ７０５で再抽出したレコードの数を記録する（ステップＳ７０６）。
　ＣＰＵ１２は、変数「無契約機器提供率」に、変数「無契約機器提供数」を変数「合計提供数」で除した値を記録する（ステップＳ７０７）。ＣＰＵ１２は、算出した無契約機器契約率をステップＳ７０２で抽出したレコードの無契約機器提供率フィールドに記録する（ステップＳ７０８）。
　ＣＰＵ１２は、機種別評価ＤＢ３３のすべてのレコードの処理を終了したか否かを判定する（ステップＳ７０９）。終了していないと判定した場合（ステップＳ７０９でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ７１０）。その後、ＣＰＵ１２はステップＳ７０３に戻る。終了したと判定した場合（ステップＳ７０９でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　図２２は、実施の形態２の商品別データ算出のサブルーチンの処理の流れを示すフローチャートである。商品別データ算出のサブルーチンは、機種別評価ＤＢ３３に基づいて図１５を使用して説明した本実施の形態の商品別評価ＤＢ３４を作成するサブルーチンである。図２２を使用して、商品別データ算出のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、商品別評価ＤＢ３４を初期化する（ステップＳ６７１）。具体的には、補助記憶装置１４に商品別評価ＤＢ３４が記憶されている場合、ＣＰＵ１２は商品別評価ＤＢ３４に記憶されているすべてのレコードを削除する。補助記憶装置１４に商品別評価ＤＢ３４が記憶されていない場合、ＣＰＵ１２は、レコードを有さない商品別評価ＤＢ３４を作成する。
　ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ６７２）。ＣＰＵ１２は、候補ＤＢ３２からＩ番目のレコードを抽出する（ステップＳ６７３）。ＣＰＵ１２は、ステップＳ６７３で抽出したレコードの商品コードフィールドに記録されている商品コードをキーとして、機種別評価ＤＢ３３からレコードを抽出する（ステップＳ６７４）。
　ＣＰＵ１２は、ステップＳ６７４で抽出した各レコードの契約率フィールドに記録されているデータの平均値を算出する（ステップＳ６７５）。ＣＰＵ１２は、ステップＳ５７４で抽出した各レコードの契約率フィールドに記録されているデータのばらつきを算出する（ステップＳ６７６）。なお、平均値の代わりに、たとえば最頻値、中央値、相乗平均値等を使用しても良い。ばらつきは、たとえば分散、標準偏差または最大値と最小値の差等である。
　ＣＰＵ１２は、ステップＳ６７４で抽出したレコードの同時購入率フィールドに記録されているデータの平均値を算出する（ステップＳ６７７）。ＣＰＵ１２は、ステップＳ６７４で抽出したレコードの無契約機器提供率フィールドに記録されているデータの平均値を算出する（ステップＳ６７８）。
　ＣＰＵ１２は、商品別評価ＤＢ３４にレコードを作成し、各フィールドにデータを記録する（ステップＳ６７９）。具体的には、ＣＰＵ１２は、作成するレコードの商品コードフィールドに、ステップＳ６７３で抽出したレコードの商品コードフィールドに記録されている商品コードを記録する。ＣＰＵ１２は、作成するレコードの契約率フィールドに、ステップＳ６７５で算出した契約率の平均値を記録する。ＣＰＵ１２は、作成するレコードのばらつきフィールドに、ステップＳ６７６で算出した契約率のばらつきを記録する。
　ＣＰＵ１２は、作成するレコードの同時購入率フィールドに、ステップＳ６７７で算出した同時購入率の平均値を記録する。ＣＰＵ１２は、作成するレコードの無契約機器提供率フィールドに、ステップＳ６７８で算出した無契約機器提供率の平均値を記録する。
　ＣＰＵ１２は候補ＤＢ３２に記録されたすべてのレコードの処理を終了したか否かを判定する（ステップＳ６８０）。終了していないと判定した場合（ステップＳ６８０でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ６８１）。その後、ＣＰＵ１２はステップＳ６７３に移動する。終了したと判定した場合（ステップＳ６８０でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　図２３は、実施の形態２の順位付けのサブルーチンの処理の流れを示すフローチャートである。順位付けのサブルーチンは、商品別評価ＤＢ３４に基づいて図１７を使用して説明した順位ＤＢを作成するサブルーチンである。図２３を使用して、順位付けのサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、順位点ＤＢを初期化する（ステップＳ７２１）。具体的には、補助記憶装置１４に順位点ＤＢが記憶されている場合、ＣＰＵ１２は順位点ＤＢに記憶されているすべてのレコードを削除する。補助記憶装置１４に順位点ＤＢが記憶されていない場合、ＣＰＵ１２は、レコードを有さない順位点ＤＢを作成する。
　ＣＰＵ１２は、カウンタＪを初期値１に設定する（ステップＳ７２２）。ＣＰＵ１２は、順位ルールＤＢのＩ番目のレコードのルールフィールドに記録されたルールに則って、商品別評価ＤＢ３４のＩ番目のフィールドに順位を付ける（ステップＳ７２３）。ＣＰＵ１２は、順位点ＤＢのＩ番目のフィールドに順位を記録する（ステップＳ７２４）。
　ＣＰＵ１２は、商品別評価ＤＢ３４のフィールドの処理を終了したか否かを判定する（ステップＳ７２５）。終了していないと判定した場合（ステップＳ７２５でＮＯ）、ＣＰＵ１２はカウンタＪに１を加算し（ステップＳ７２６）、ステップＳ７２３に戻る。終了したと判定した場合（ステップＳ７２５でＹＥＳ）、ＣＰＵ１２はカウンタＩを初期値１に設定する（ステップＳ７２７）。
　ＣＰＵ１２は、順位点ＤＢのＩ番目のレコードの総合点を算出し、総合点フィールドに記録する（ステップＳ７２８）。具体的には、ＣＰＵ１２は順位点ＤＢの順位点フィールドに記録された値の合計を算出して、総合点フィールドに記録する。ＣＰＵ１２は、順位点ＤＢのすべてのレコードの処理が終了したか否かを判定する（ステップＳ７２９）。終了していないと判定した場合（ステップＳ７２９でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ７３２）。ＣＰＵ１２はステップＳ７２８に戻る。
　すべてのレコードの処理が終了したと判定した場合（ステップＳ７２９でＹＥＳ）、ＣＰＵ１２は、総合点に順位を付ける（ステップＳ７３０）。具体的には、ＣＰＵ１２は総合点フィールドに記録されたデータを比較し、数値の大きいレコードから順番に順位を付ける。
　ＣＰＵ１２は、見直し順位フィールドにステップＳ７３０で付けた順位を記録する（ステップＳ７３１）。その後、ＣＰＵ１２は処理を終了する。
　本実施の形態によると、サービス商品の見直しを担当するユーザは、複数の指標を総合して見直しを行うサービス商品を検討することができる。また、販売ＤＢ３１およびサービス実績ＤＢに記録されているデータに対してユーザが直接アクセスしないので、情報流出等を防止することができる。
　無契約機器契約率と同時購入率とのいずれか片方または両方の算出を省略しても良い。契約率の順位点の算出を省略しても良い。無契約機器購入率のばらつきを算出して、図１８のチャート欄２５に追加しても良い。同時購入率のばらつきを算出して、図１８のチャート欄２５に追加しても良い。
　順位点は、たとえば１位を１点、２位を２点、３位を４点、４位を８点のように、順位を表す数値とは異なる値の点数としても良い。順位を表す数値と順位点との関係は、項目によって異ならせても良い。
［実施の形態３］
　本実施の形態は、サービス商品を購入していない顧客からの連絡に対応するサービス商品コードを推定して順位を判定する情報処理装置１１に関する。実施の形態２と共通する部分については、説明を省略する。
　本実施の形態では、図１３を使用して説明したサービス実績ＤＢのうち、無契約機器に対する連絡を記録したレコードの商品コードフィールドは空欄である。具体的には、図１３中の製造番号フィールドが「Ｖ０００１」であるレコードは無契約機器に対する連絡を記録したレコードであり、商品コードフィールドは空欄である。同様に、製造番号フィールドが「Ｖ００５２」であるレコードも、無契約機器に対する連絡を記録したレコードであり、商品コードフィールドが空欄である。
　図２４は、実施の形態３の無契約機器提供数ＤＢのレコードレイアウトを示す説明図である。無契約機器提供数ＤＢは、機種コードと無契約機器に対するサービス提供数とを関連づけるＤＢである。無契約機器提供数ＤＢは、機種コードフィールドおよび無契約機器提供数フィールドを有する。機種コードフィールドには、ハードウェア製品の機種コードが記録されている。無契約機器提供数フィールドには、無契約機器に対するサービスの提供数が記録されている。
　無契約機器提供数ＤＢは、１つの機種コードについて１つのレコードを有する。無契約機器提供数ＤＢは、本実施の形態のプログラムに基づいてＣＰＵ１２が作成するＤＢである。無契約機器提供数ＤＢを作成する方法の概要を以下に説明する。
　ＣＰＵ１２は、機種別評価ＤＢ３３の機種コードフィールドに記録された機種コードをキーとして、図１３を使用して説明したサービス実績ＤＢからレコードを抽出する。ＣＰＵ１２は、抽出したレコードから契約日フィールドが空欄であるレコードを再抽出する。ＣＰＵ１２は、機種コードを機種コードフィールドに、再抽出したレコードの数を無契約機器提供数フィールドにそれぞれ記録する。
　図２５は、実施の形態３の推定提供率ＤＢのレコードレイアウトを示す説明図である。推定提供率ＤＢは、機種コードと、商品コードと、サービス提供数の比率とを関連づけるＤＢである。無契約機器提供数ＤＢは、機種コードフィールドと商品コードフィールドとを有する。商品コードフィールドは、ＡフィールドからＦフィールドまでの各商品コードに対応するフィールドを有する。
　機種コードフィールドには、ハードウェア製品の機種コードが記録されている。商品コードフィールドには、サービスを提供する比率が記録されている。具体例を挙げて説明する。機種コードがＳのレコードでは、Ａフィールドに０．８、Ｃフィールドに０．２が記録され、それ以外のフィールドには０．０が記録されている。これは、機種コードがＳである機器に関する連絡は、８割が契約Ａの対象であり、２割が契約Ｃの対象であると推定することを示している。
　推定提供率ＤＢは、たとえばサービス部門が受け付けた顧客からの連絡の内容をサンプリング調査して作成する。過去の製品に対する顧客からの連絡の内容に基づいて、推定提供率ＤＢを作成しても良い。
　図２６は、実施の形態３の機種別評価ＤＢ３３のレコードレイアウトを示す説明図である。図２６に示す機種別評価ＤＢ３３は、図１４を使用して説明した実施の形態２の機種別評価ＤＢ３３の代わりに使用するＤＢである。
　本実施の形態の機種別評価ＤＢ３３は、商品コード、機種コード、サービス商品の契約率、機器とサービス商品との同時購入率およびサービスの提供状況を関連づけるＤＢである。機種別評価ＤＢ３３は、商品コードフィールド、機種コードフィールド、契約率フィールド、同時購入率フィールドおよびサービス提供フィールドを有する。サービス提供フィールドは、提供数フィールド、推定数フィールド、合計提供数フィールドおよび無契約機器提供率フィールドを有する。
　商品コードフィールドには、見直し対象であるサービス商品の商品コードが記録されている。機種コードフィールドには、商品コードフィールドに記録されたサービス商品に対応するハードウェア製品の機種コードが記録されている。契約率フィールドには、サービス商品の契約数を販売したハードウェア製品の数で除したサービス商品の契約率が記録されている。同時購入率フィールドには、機器と同時に販売したサービス商品の契約数を総契約数で除した同時購入率が記録されている。
　提供数フィールドには、対応するサービス商品が契約されている機器に対するサービス提供数が記録されている。推定数フィールドには、無契約機器に対するサービス提供数を推定した値が記録されている。合計提供数フィールドには、提供数フィールドに記録した値に推定数フィールドに記録した値を加算した合計提供数が記録されている。無契約機器提供率フィールドには、推定数フィールドに記録された値を合計提供数フィールドに記録された値で除した無契約機器に対するサービス提供率が記録されている。
　機種別評価ＤＢ３３は、商品コードと機種コードとの組合せについて１つのレコードを有する。機種別評価ＤＢ３３は、本実施の形態のプログラムに基づいてＣＰＵ１２が作成するＤＢである。機種別評価ＤＢ３３を作成する方法の概要を以下に説明する。
　商品コードフィールド、機種コードフィールド、契約率フィールドおよび同時購入率フィールドについては、図１４を使用して説明した実施の形態２の機種別評価ＤＢ３３と同様であるので、説明を省略する。機種別評価ＤＢ３３の商品コードフィールド、機種コードフィールド、契約率フィールドおよび同時購入率フィールドにデータが記録されている状態から説明を行う。
　ＣＰＵ１２は、機種別評価ＤＢ３３から１個の機種別評価レコードを取り出す。ＣＰＵ１２は取り出した機種別評価レコードの機種コードフィールドに記録されている機種コードおよび商品コードフィールドに記録されている商品コードをキーとして、サービス実績ＤＢからサービス実績レコードを抽出する。ＣＰＵ１２は、抽出したサービス実績レコードの数を数えることによりサービスの提供数を求める。
　ＣＰＵ１２は、前述の機種別評価レコードの機種コードフィールドに記録されている機種コードをキーとして、図２４を使用して説明した無契約機器提供数ＤＢからレコードを抽出する。ＣＰＵ１２は、抽出したレコードから無契約機器提供数フィールドに記録されている無契約機器提供数を抽出する。ＣＰＵ１２は、前述の機種別評価レコードに記録されている機種コードおよび商品コードをキーとして、図２５を使用して説明した推定提供率ＤＢから比率を抽出する。
　ＣＰＵ１２は、無契約機器提供数ＤＢから抽出した無契約機器提供数に、推定提供率ＤＢから抽出した比率を乗じて、無契約機器に対するサービス提供数の推定数を算出する。
　推定数の算出方法について、具体例を挙げて説明する。図２４に示す無契約機器提供数ＤＢより、機種コードがＳの機器に関する無契約機器へのサービス提供数は１０である。図２５に示す推定提供率ＤＢより、機種コードがＳである無契約機器に対する連絡は、８割が契約Ａの対象である。したがって、ＣＰＵ１２は、図２６の一番上に示す商品コードがＡ、機種コードがＳの組合せでは、無契約機器に対するサービスの提供数は１０×０．８＝８件であると推定する。
　ＣＰＵ１２は、提供数と推定数とを加算して、サービスの合計提供数を算出する。ＣＰＵ１２は、推定数を合計提供数で除して無契約機器提供率を算出する。
　ＣＰＵ１２は、機種別評価ＤＢ３３に記録されたすべてのレコードについて上記の処理を行う。以上により図２６を使用して説明した機種別評価ＤＢ３３が完成する。
　図２７は、実施の形態３の機種別サービス実績データ算出のサブルーチンの処理の流れを示すフローチャートである。図２７に示すサブルーチンは、図２１を使用して説明した実施の形態２の機種別サービス実績データ算出のサブルーチンの代わりに使用するサブルーチンである。
　本実施の形態の機種別サービス実績データ算出のサブルーチンは、図２６を使用して説明した機種別評価ＤＢ３３のサービス提供フィールドに対応するデータを算出して記録するサブルーチンである。図２７を使用して、本実施の形態の機種別サービス実績データサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ８００）。ＣＰＵ１２は、無契約機器提供数算出のサブルーチンを起動する（ステップＳ８０１）。無契約機器提供数算出のサブルーチンは、サービス実績ＤＢに基づいて無契約機器に対するサービス提供数を算出して、図２４を使用して説明した無契約機器提供数ＤＢを作成するサブルーチンである。無契約機器契約数算出のサブルーチンの処理の流れは後述する。
　ＣＰＵ１２は、機種別評価ＤＢ３３からＩ番目のレコードを抽出する（ステップＳ８０２）。ＣＰＵ１２は、ステップＳ８０２で抽出したレコードに記録された商品コードおよび機種コードキーとして、サービス実績ＤＢからレコードを抽出する（ステップＳ８０３）。ＣＰＵ１２は、変数「提供数」にステップＳ８０３で抽出したレコードの数を記録する（ステップＳ８０４）。
　ＣＰＵ１２は、ステップＳ８０２で抽出したレコードに記録された機種コードをキーとして、無契約機器提供数ＤＢからレコードを抽出する。ＣＰＵ１２は、抽出したレコードの無契約機器提供数フィールドに記録された無契約機器提供数を抽出する（ステップＳ８０５）。ＣＰＵ１２は、ステップＳ８０２で抽出したレコードに記録された機種コードおよび商品コードをキーとして、推定提供率ＤＢから比率を抽出する（ステップＳ８０６）。
　ＣＰＵ１２は、変数「推定数」にステップＳ８０５で抽出した無契約機器提供数とステップＳ８０６で抽出した比率との積を記録する（ステップＳ８０７）。ＣＰＵ１２は、変数「合計提供数」に変数「提供数」と変数「推定数」との和を記録する（ステップＳ８０８）。
　ＣＰＵ１２は、変数「無契約機器提供率」に、ステップＳ８０５で抽出した無契約機器提供数を変数「合計提供数」で除した値を記録する（ステップＳ８０９）。ＣＰＵ１２は、算出した提供数、推定数、合計提供数および無契約機器提供率をステップＳ８０２で抽出したレコードのサービス提供フィールドに記録する（ステップＳ８１０）。
　ＣＰＵ１２は、機種別評価ＤＢ３３のすべてのレコードの処理を終了したか否かを判定する（ステップＳ８１１）。終了していないと判定した場合（ステップＳ８１１でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ８１２）。その後、ＣＰＵ１２はステップＳ８０２に戻る。終了したと判定した場合（ステップＳ８１１でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　図２８は、実施の形態３の無契約機器提供数算出のサブルーチンの処理の流れを示すフローチャートである。無契約機器提供数算出のサブルーチンは、サービス実績ＤＢに基づいて無契約機器に対するサービス提供数を算出して、図２４を使用して説明した無契約機器提供数ＤＢを作成するサブルーチンである。図２８を使用して、無契約機器契約数算出のサブルーチンの処理の流れを説明する。
　ＣＰＵ１２は、無契約機器提供数ＤＢを初期化する（ステップＳ８２１）。具体的には、補助記憶装置１４に無契約機器提供数ＤＢが記憶されている場合、ＣＰＵ１２は無契約機器提供数ＤＢに記憶されているすべてのレコードを削除する。補助記憶装置１４に無契約機器提供数ＤＢが記憶されていない場合、ＣＰＵ１２は、レコードを有さない無契約機器提供数ＤＢを作成する。
　ＣＰＵ１２は、カウンタＩを初期値１に設定する（ステップＳ８２２）。ＣＰＵ１２は、機種別評価ＤＢ３３からＩ番目のレコードを抽出する（ステップＳ８２３）。ＣＰＵ１２は、ステップＳ８２３で抽出したレコードに記録された機種コードは、無契約機器提供数ＤＢの機種コードフィールドに記録されているか否かを判定する（ステップＳ８２４）。記録されていないと判定した場合（ステップＳ８２４でＮＯ）、ＣＰＵ１２は無契約機器提供数ＤＢの機種コードフィールドに、機種コードを記録する（ステップＳ８２５）。
　記録されていると判定した場合（ステップＳ８２４でＹＥＳ）およびステップＳ８２５の終了後、ＣＰＵ１２は機種別評価ＤＢ３３に記録されたレコードの処理を終了したか否かを判定する（ステップＳ８２６）。終了していないと判定した場合（ステップＳ８２６でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ８２７）。ＣＰＵ１２はステップＳ８２３に戻る。
　終了したと判定した場合（ステップＳ８２６でＹＥＳ）、ＣＰＵ１２はカウンタＩを初期値１に設定する（ステップＳ８３１）。ＣＰＵ１２は、無契約機器提供数ＤＢからＩ番目のレコードを抽出する（ステップＳ８３２）。ＣＰＵ１２は、ステップＳ８３２で抽出したレコードの機種コードフィールドに記録されている機種コードをキーとして、サービス実績ＤＢからレコードを抽出する（ステップＳ８３３）。
　ＣＰＵ１２は、ステップＳ８３３で抽出したレコードから、契約日フィールドが空欄であるレコードを再抽出する（ステップＳ８３４）。ＣＰＵ１２は、変数「無契約機器提供数」に、ステップＳ８３４で抽出したレコードの数を記録する（ステップＳ８３５）。ＣＰＵ１２は、ステップＳ８３２で抽出したレコードの無契約機器提供数フィールドに、変数「無契約機器提供数」の値を記録する（ステップＳ８３６）。
　ＣＰＵ１２は、無契約機器提供数ＤＢに記録されたレコードの処理を終了したか否かを判定する（ステップＳ８３７）。終了していないと判定した場合（ステップＳ８３７でＮＯ）、ＣＰＵ１２はカウンタＩに１を加算する（ステップＳ８３８）。ＣＰＵ１２は、ステップＳ８３２に戻る。終了したと判定した場合（ステップＳ８３７でＹＥＳ）、ＣＰＵ１２は処理を終了する。
　本実施の形態によると、サービス商品を購入していない顧客からの連絡を受け付けた場合に、対応するサービス商品コードを推定してサービス実績ＤＢに記録する必要が無い。そのため、たとえば顧客サービス受付部門の負荷を減らすことができる。
［実施の形態４］
　本実施の形態は、商品別評価ＤＢ３４を作成する際に、機器の販売台数に基づいて重み付けを行う情報処理装置１１に関する。実施の形態２と共通する部分については、説明を省略する。
　図２９は、実施の形態４の販売台数ＤＢのレコードレイアウトを示す説明図である。販売台数ＤＢは、機種コードと販売台数とを関連づけるＤＢである。販売台数ＤＢは、機種コードフィールドと販売台数フィールドとを有する。機種コードフィールドには、機種コードが記録される。販売台数フィールドには販売台数が記録される。
　販売台数ＤＢは、機種ごとに１つのレコードを有する。販売台数ＤＢは、たとえば図２０を使用して説明した機種別契約データ算出のサブルーチンのステップＳ６４４で算出した販売台数を記録することにより作成する。
　図３０は、実施の形態４の商品別データ算出のサブルーチンの処理の流れを示すフローチャートである。図３０に示すサブルーチンは、図２２を使用して説明した実施の形態２の商品別データ算出のサブルーチンの代わりに使用するサブルーチンである。図３０を使用して、本実施の形態の商品別データ算出のサブルーチンの処理の流れを説明する。
　ステップＳ６７４までは、図２２を使用して説明したサブルーチンと同一の処理であるので、説明を省略する。ＣＰＵ１２は、ステップＳ６７４で抽出した各レコードの機種コードフィールドに記録された機種コードをキーとして、販売台数ＤＢから各機種のレコードを抽出する（ステップＳ７４１）。
　ＣＰＵ１２は、ステップＳ６７４で抽出した各レコードの契約率フィールドに記録されている契約率に、販売台数で重みを付けた重み付け平均値を算出する（ステップＳ７４２）。重み付け平均値は、たとえば式（１）により算出する。
Figure JPOXMLDOC01-appb-M000001
　ＣＰＵ１２は、ステップＳ６７４で抽出した各レコードの契約率フィールドに記録されているデータのばらつきを算出する（ステップＳ６７６）。
　ＣＰＵ１２は、ステップＳ６７４で抽出した各レコードの同時購入率フィールドに記録されている同時購入率に、販売台数で重みを付けた重み付け平均値を算出する（ステップＳ７４３）。ＣＰＵ１２は、ステップＳ６７４で抽出した各レコードの無契約機器提供率フィールドに記録されている無契約機器提供率に、販売台数で重みを付けた重み付け平均値を算出する（ステップＳ７４４）。なお、重み付け平均値の算出方法は、式（１）と同様であるので説明を省略する。
　ＣＰＵ１２は、商品別評価ＤＢ３４にレコードを作成し、各フィールドにデータを記録する（ステップＳ６７９）。以後の処理は、図２２と同様であるので説明を省略する。
　本実施の形態によると、機器の販売台数を考慮して見直しを行うサービス商品を検討することができる。
　ＣＰＵ１２は、契約率、同時購入率および無契約機器提供率のいずれか１つまたは２つの、重み付け平均値を算出しても良い。ＣＰＵ１２は、各機種の売上金額または価格に基づいて重み付けを行っても良い。
［実施の形態５］
　本実施の形態は、サービス商品の価格および契約数を含めて順位付けを行う情報処理装置１１に関する。実施の形態２と共通する部分については、説明を省略する。
　図３１は、実施の形態５の契約数ＤＢのレコードレイアウトを示す説明図である。契約数ＤＢは、商品コードと価格と契約数とを関連づけるＤＢである。契約数ＤＢは、商品コードフィールド、価格フィールドおよび契約数フィールドを有する。商品コードフィールドには、商品コードが記録される。価格フィールドには、価格が記録される。契約数フィールドには、サービス商品の契約数が記録される。
　契約数ＤＢは、サービス商品ごとに１つのレコードを有する。契約数ＤＢの価格フィールドは、サービス商品の価格表等に基づいて記録する。契約数ＤＢの契約数フィールドは、たとえば図２０を使用して説明した機種別契約データ算出のサブルーチンのステップＳ６４６で算出した契約数を商品コードごとに合計した値を記録する。
　図３２は、実施の形態５の順位ＤＢのレコードレイアウトを示す説明図である。図３２に示す順位ＤＢは、図１７を使用して説明した実施の形態２の順位ＤＢの代わりに使用するＤＢである。
　本実施の形態の順位ＤＢは、商品コードフィールド、順位点フィールド、総合点フィールドおよび見直し順位フィールドを有する。順位点フィールドは、価格フィールド、契約数フィールド、契約率フィールド、契約率ばらつきフィールド、無契約機器提供率フィールドおよび同時購入率フィールドを有する。商品コードフィールド、契約率フィールド、契約率ばらつきフィールド、無契約機器提供率フィールド、同時購入率フィールド、総合点フィールドおよび見直し順位フィールドは、図１７と同様であるので説明を省略する。
　価格フィールドには、図３１を使用して説明した契約数ＤＢの価格フィールドに記録されたデータに基づいて定められた順位点が記録されている。価格フィールドの順位点は、価格が安い順に定められている。
　契約数フィールドには、図３１を使用して説明した契約数ＤＢの契約数フィールドに記録されたデータに基づいて定められた順位点が記録されている。契約数フィールドの順位点は、契約数が少ない順に定められている。
　本実施の形態によると、価格の高いサービス商品および契約数が大きいサービス商品の順位を高く判定する情報処理装置１１を提供することができる。
［実施の形態６］
　本実施の形態は、過去のデータも表示する情報処理装置１１に関する。実施の形態２と共通する部分については、説明を省略する。
　図３３は、実施の形態６の情報処理結果を表示する画面を示す説明図である。図３３に示す画面は、図１８を使用して説明した実施の形態２の画面の代わりにＣＰＵ１２が表示部１６に表示する画面である。
　図３３に示す画面は、第１チャート欄２７、データ欄２６および第２チャート欄２８を有する。第１チャート欄２７には、図１８を使用して説明したチャート欄２５と同様のレーダチャートが表示されている。第２チャート欄２８には、１年前の時点の販売ＤＢ３１およびサービス実績ＤＢを使用して作成したレーダチャートが表示されている。
　ＣＰＵ１２は、たとえば１年前に作成した商品別評価ＤＢ３４を補助記憶装置１４に記憶しておき、第２チャート欄２８に表示しても良い。ＣＰＵ１２は、販売日等の日付に基づいてフィルタリングした機種別評価ＤＢ３３および商品別評価ＤＢ３４に基づいて商品別評価ＤＢ３４を作成して、第２チャート欄２８に表示しても良い。ＣＰＵ１２は、３個以上のチャート欄を表示しても良い。第１チャート欄２７と第２チャート欄２８とで、異なる名称の軸を使用しても良い。
　本実施の形態によると、サービス商品の見直しを担当するユーザは、サービス商品の状況の変化を参照して見直しを行うサービス商品を検討することができる。
［実施の形態７］
　図３４は、実施の形態７の情報処理装置１１の動作を示す機能ブロック図である。情報処理装置１１は、ＣＰＵ１２による制御に基づいて以下のように動作する。
　第１算出部６１は、販売ＤＢ３１に記録された販売した機器を特定する識別情報と、機器に関連するサービス商品の契約有無とに基づいて、機器が属する機種とサービス商品との組合せごとにサービス商品の契約率を算出する。第２算出部６２は、サービス商品ごとに第１算出部６１が算出した契約率の機種間のばらつきを算出する。出力部６３は、第２算出部６２が算出したばらつきに基づいて選択される、少なくとも一つのサービス商品を出力する。
［実施の形態８］
　実施の形態８は、汎用のコンピュータとプログラム７１とを組み合わせて動作させることにより、本実施の形態の情報処理装置１１を実現する形態に関する。図３５は、実施の形態８の情報処理装置１１の構成を示す説明図である。図３５を使用して、本実施の形態の構成を説明する。なお、実施の形態１と共通する部分の説明は省略する。
　本実施の形態のコンピュータは、ＣＰＵ１２、主記憶装置１３、補助記憶装置１４、入力部１５、表示部１６、通信部１７、読取部１８およびバスを備える。コンピュータは、汎用のパソコン等の情報処理装置である。
　プログラム７１は、可搬型記録媒体７２に記録されている。ＣＰＵ１２は、読取部１８を介してプログラム７１を読み込み、補助記憶装置１４に保存する。またＣＰＵ１２は、コンピュータ内に実装されたフラッシュメモリ等の半導体メモリ７３に記憶されたプログラム７１を読出しても良い。さらに、ＣＰＵ１２は、通信部１７および図示しないネットワークを介して接続される図示しない他のサーバコンピュータからプログラム７１をダウンロードして補助記憶装置１４に保存しても良い。
　プログラム７１は、コンピュータの制御プログラムとしてインストールされ、主記憶装置１３にロードして実行される。これにより、コンピュータは上述した情報処理装置１１として機能する。
　各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
　今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
　１１　情報処理装置
　１２　ＣＰＵ
　１３　主記憶装置
　１４　補助記憶装置
　１５　入力部
　１６　表示部
　１７　通信部
　１８　読取部
　２１　順位欄
　２２　内訳欄
　２３　選択枠
　２５　チャート欄
　２６　データ欄
　２７　第１チャート欄
　２８　第２チャート欄
　３１　販売ＤＢ
　３２　候補ＤＢ
　３３　機種別評価ＤＢ
　３４　商品別評価ＤＢ
　６１　第１算出部
　６２　第２算出部
　６３　出力部
　７１　プログラム
　７２　可搬型記憶媒体
　７３　半導体メモリ

Claims (16)

  1. 　販売した機器を特定する識別情報と、前記機器に関連するサービス商品の契約有無とに基づいて、前記機器が属する機種と前記サービス商品との組合せごとに前記サービス商品の契約率を算出し、
    　前記サービス商品ごとに機種間の前記契約率のばらつきを算出し、
    　前記契約率のばらつきに基づいて選択される、少なくとも一つのサービス商品を出力する
    　処理をコンピュータに実行させるプログラム。
  2. 　前記契約率のばらつきが所定の値をこえる前記サービス商品、または前記契約率のばらつきが大きい方から所定の数の前記サービス商品を出力する
    　請求項１に記載のプログラム。
  3. 　前記機器に関連するサービスの提供実績に基づいて、未契約の機器に対するサービスの提供数を前記サービス商品ごとに抽出し、
    　前記サービス商品ごとに、前記提供数と、前記サービス商品の契約数または契約済の機器および前記未契約の機器に対するサービスの合計提供数との第１比率を算出し、
    　前記契約率のばらつきおよび前記第１比率に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項１または請求項２に記載のプログラム。
  4. 　前記サービス商品ごとの前記契約率のばらつきが小さい方からの順位および前記第１比率が小さい方からの順位に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項３に記載のプログラム。
  5. 　前記識別情報および前記機器の販売日と、前記契約有無および前記サービス商品の契約日とに基づいて、前記機種と前記サービス商品との組合せごとに前記販売日と前記契約日とが同一である前記サービス商品の契約数と、前記販売数または前記契約数との第２比率を算出し、
    　前記契約率のばらつきおよび前記第２比率に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項１または請求項２に記載のプログラム。
  6. 　前記サービス商品ごとの前記契約率のばらつきが小さい方からの順位および前記第２比率が大きい方からの順位に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項５に記載のプログラム。
  7. 　前記識別情報および前記機器の販売日と、前記契約有無および前期サービス商品の契約日とに基づいて、前記機種と前記サービス商品との組合せごとに前記販売日と前記契約日とが同一である前記サービス商品の契約数と、前記販売数または前記契約数との第２比率を算出し、
    　前記契約率のばらつき、前記第１比率および前記第２比率に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項３または請求項４に記載のプログラム。
  8. 　前記サービス商品ごとの前記契約率のばらつきが小さい方からの順位、前記第１比率が小さい方からの順位および前記第２比率が大きい方からの順位に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項７に記載のプログラム。
  9. 　前記サービス商品ごとに前記契約率の代表値を算出し、
    　前記契約率のばらつきおよび前記代表値に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項１または請求項２に記載のプログラム。
  10. 　前記サービス商品ごとに前記契約率の代表値を算出し、
    　前記契約率のばらつき、前記第１比率および前記代表値に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項３または請求項４に記載のプログラム。
  11. 　前記サービス商品ごとに前記契約率の代表値を算出し、
    　前記契約率のばらつき、前記第２比率および前記代表値に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項５または請求項６に記載のプログラム。
  12. 　前記識別情報および前記機器の販売日と、前記契約有無および前期サービス商品の契約日とに基づいて、前記機種と前記サービス商品との組合せごとに前記販売日と前記契約日とが同一である前記サービス商品の契約数と、前記販売数または前記契約数との第２比率を算出し、
    　前記サービス商品ごとに前記契約率の代表値を算出し、
    　前記契約率のばらつき、前記第１比率、前記第２比率および前記代表値に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項３または請求項４に記載のプログラム。
  13. 　前記サービス商品ごとの前記契約率のばらつきが小さい方からの順位、前記第１比率が小さい方からの順位、前記第比率が大きい方からの順位および前記代表値が大きい方からの順位に基づいて選択される、少なくとも一つの前記サービス商品を出力する
    　請求項１２に記載のプログラム。
  14. 　前記機種ごとに機器の販売数を算出し、
    　前記代表値は、前記契約率を前記販売数で重み付けした平均値である
    　請求項９から請求項１３のいずれか一つに記載のプログラム。
  15. 　販売した機器を特定する識別情報と、前記機器に関連するサービス商品の契約有無とに基づいて、前記機器が属する機種と前記サービス商品との組合せごとに前記サービス商品の契約率を算出し、
    　前記サービス商品ごとに機種間の前記契約率のばらつきを算出し、
    　前記契約率のばらつきに基づいて選択される、少なくとも一つのサービス商品を出力する
    　処理をコンピュータに実行させる情報処理方法。
  16. 　販売した機器を特定する識別情報と、前記機器に関連するサービス商品の契約有無とに基づいて、前記機器が属する機種と前記サービス商品との組合せごとに前記サービス商品の契約率を算出する第１算出部と、
    　前記サービス商品ごとに前記第１算出部が算出した契約率の機種間のばらつきを算出する第２算出部と、
    　前記第２算出部が算出したばらつきに基づいて選択される、少なくとも一つのサービス商品を出力する出力部とを備える
    　情報処理装置。
PCT/JP2017/007545 2016-03-03 2017-02-27 プログラム、情報処理方法および情報処理装置 Ceased WO2017150467A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016-041524 2016-03-03
JP2016041524A JP2017157106A (ja) 2016-03-03 2016-03-03 プログラム、情報処理方法および情報処理装置

Publications (1)

Publication Number Publication Date
WO2017150467A1 true WO2017150467A1 (ja) 2017-09-08

Family

ID=59743973

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/007545 Ceased WO2017150467A1 (ja) 2016-03-03 2017-02-27 プログラム、情報処理方法および情報処理装置

Country Status (2)

Country Link
JP (1) JP2017157106A (ja)
WO (1) WO2017150467A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014041399A (ja) * 2012-08-21 2014-03-06 Nippon Telegr & Teleph Corp <Ntt> Ｉｃｔサービス環境影響評価システムおよび方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014041399A (ja) * 2012-08-21 2014-03-06 Nippon Telegr & Teleph Corp <Ntt> Ｉｃｔサービス環境影響評価システムおよび方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KEN'ICHI KITAGAWA: "Desktop·Service: Open-kei Shinto de Un'yomen no Riyo ga Zoka", NIKKEI SYSTEM PROVIDE R, vol. 93, 21 January 2000 (2000-01-21), pages 85 - 89 *

Also Published As

Publication number Publication date
JP2017157106A (ja) 2017-09-07

Similar Documents

Publication Publication Date Title
US10153953B2 (en) Network system, control method of a network system and control device
JP2016522523A (ja) 情報を推薦するための方法およびシステム
WO2016174878A1 (ja) 行動分析システム及び行動分析方法
EP3154237A1 (en) Network system, client, and communication control method
JP2014115951A (ja) 属性情報最適化装置、属性情報最適化プログラム及び属性情報の最適化方法、並びにレコメンド対象選択装置、レコメンド対象選択プログラム及びレコメンド対象の選択方法
JP7643421B2 (ja) 情報処理装置、情報処理システム、情報処理方法、及びプログラム
JP2019020944A (ja) 表示装置及びプログラム
CA3169819A1 (en) Systems and methods for automated product classification
JP2023183187A (ja) プログラム、及び情報処理装置
US20230419351A1 (en) Systems and methods for assisting users in assessing costs of transactions
JP6704464B2 (ja) 物流倉庫の業務における事故要因を推定するシステム
US20180253711A1 (en) Inventory management system and method
JP6687964B1 (ja) 販売員評価システム、販売員評価装置、販売員評価方法および販売員評価用プログラム
CN113312446A (zh) 文档创建装置、记录介质及文档创建方法
CN116523600A (zh) 一种基于行为分析的客户分类方法及系统
JP5847137B2 (ja) 需要予測装置及びプログラム
JPH10275185A (ja) 家計簿自動入力システムとマーケティングシステム
WO2017150467A1 (ja) プログラム、情報処理方法および情報処理装置
CN115049448A (zh) 用于优化在线服务的性能的系统和方法
JP6962888B2 (ja) 特徴抽出装置
Estelami et al. Determinants of extended warranty prices for consumer durables
JPH1083484A (ja) 小売業の販売促進方法およびシステム
JP2011100284A (ja) 営業成績管理システム
WO2023182486A1 (ja) 情報処理システム及び情報処理方法
JPWO2022064688A5 (ja) 推定システム、推定方法および推定プログラム

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17759933

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17759933

Country of ref document: EP

Kind code of ref document: A1