EP1451745A1 - Procede et dispositif d'evaluation executee dans un ordinateur de procedures commerciales clients - Google Patents

Procede et dispositif d'evaluation executee dans un ordinateur de procedures commerciales clients

Info

Publication number
EP1451745A1
EP1451745A1 EP02791714A EP02791714A EP1451745A1 EP 1451745 A1 EP1451745 A1 EP 1451745A1 EP 02791714 A EP02791714 A EP 02791714A EP 02791714 A EP02791714 A EP 02791714A EP 1451745 A1 EP1451745 A1 EP 1451745A1
Authority
EP
European Patent Office
Prior art keywords
data
business process
computer system
computer
business
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
EP02791714A
Other languages
German (de)
English (en)
Inventor
Jürgen AHLERS
Hermann Eichert
Johannes Musseleck
Heiner GÖRISSEN
Udo Müller
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.)
BASF SE
Original Assignee
BASF SE
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 BASF SE filed Critical BASF SE
Publication of EP1451745A1 publication Critical patent/EP1451745A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0637—Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q30/0241—Advertisements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/98—Detection or correction of errors, e.g. by rescanning the pattern or by human intervention; Evaluation of the quality of the acquired patterns
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/22—Procedures used during a speech recognition process, e.g. man-machine dialogue

Definitions

  • the present invention relates to a method and a device for computer-implemented evaluation of electronic customer business processes, as well as a computer program with program code that is suitable for executing the method according to the invention when it is run on a computer system, and a storage medium with such a computer program.
  • evaluation encompasses the recognition, structuring and processing of business processes.
  • Business processes are understood to mean, for example, orders, delivery plans, invoices, order changes, inquiries, etc. This can be just as much internal company processes between a department representing the customer and a department representing the supplier as processes between individual companies and their external customers.
  • the processes that can be processed with a system according to the invention extend to all possible areas of business and industrial life.
  • the system according to the invention is also suitable in connection with the control of industrial manufacturing and manufacturing processes.
  • S2S processes system-to-system processes
  • ERP systems Coordinated company systems
  • ERP Enterprise Resource Planning
  • Figure 1 shows a schematic representation of the communication channels in typical customer business processes.
  • the customer (client) is shown on the left-hand side of the diagram in FIG. 1, and the company receiving the order (contractor) on the right-hand side.
  • the integration of processing by a person is usually necessary on both sides.
  • coordinated ERP systems are used on both sides (which is usually only economically feasible for large customers with a high order volume)
  • the business processes running on the Internet or by fax can also be linked to the interposition of human processing at least on one of the waive on both sides.
  • the customer transmits his order orally to an employee of the contractor, who then enters this order into the contractor's in-house order system.
  • the order must be passed on to a responsible person before entering it into the system, who then enters the order.
  • the customer then receives an official order confirmation only after the order has been entered into the system.
  • the invention proposes a method and a device for computer-implemented evaluation of customer business processes with the features of claims 1 and 6 or 9 and 14, with the aid of which an interposition of human activity in the processing of incoming orders on the part of the contractor can be avoided without the customer having to stick to the data structures or forms specified by the contractor. Orders can be received by electronic mail (email), fax or by telephone.
  • the data is checked statically on the basis of character recognition and hypotheses are created for the content of each checked date, and in a second check - a dynamic test of the hypotheses created.
  • data relevant to business process contained in a business process (GP) entered into the computer system is used Comparison of electronically recognized data content with customer and / or material-specific data contained in a knowledge base (200).
  • the order system available at the contractor (and possibly other existing EDP systems including databases) is combined with an image and / or text recognition system that is able to provide the required information and data from the customer's incoming forms extract and make it available to the company's own ERP system directly and without human intervention.
  • the existing ordering system is combined with a telephone (voice) recognition system which recognizes voice and / or key inputs by telephone and, if necessary, converts them into digital data which can be processed by the internal ordering system.
  • a telephone voice recognition system which recognizes voice and / or key inputs by telephone and, if necessary, converts them into digital data which can be processed by the internal ordering system.
  • the image and / or text recognition system is able to identify the customer and the relevant order details in unformatted orders and other business processes (e.g. letters or emails written in the body text) and to the company's own system of Forward the contractor.
  • This can be achieved through the use of a database that is based on an existing system (e.g. a bus ness warehouse system) with customer and / or material-specific information.
  • an existing system e.g. a bus ness warehouse system
  • This enables the information and data recognized in a received document to be compared and, if necessary, corrected or supplemented.
  • the data is compared based on master data and historical information that is stored in the warehouse system.
  • This flow logic enables the system, for example, to recognize the customer independently and to interpret the content of the order completely and without errors, and to automatically generate an order for the company's own ERP system.
  • master data systems and so-called data warehouses data warehouses; this designation is understood to mean large, structured, distributed data stocks which are of long-term value and are preferably used for query and analysis) with recognition systems.
  • the detection provided by the detection systems takes place in two stages.
  • a character recognition known per se, in which the information transmitted by a customer is converted into a format that is understandable for the company system. This is done, for example, using so-called OCR software (OCR: Optical Character Recognition), ie optical recognition of plain text.
  • OCR software OCR: Optical Character Recognition
  • the document statement ie the semantic content of the transmitted data and information, is recognized.
  • This level is preferably implemented by combining artificial intelligence, semantic text recognition or fuzzy comparisons and linking with master data systems and data warehouses (for historical information).
  • the obtained through the two steps of recognition "knowledge” is converted into an understandable for the company's internal system of the 'contractor format.
  • the sequence according to the invention described is in the gur 2 shown highly schematic functional diagram.
  • FIG. 3 shows a somewhat more detailed schematic functional diagram, in which the partial processes, in particular in the area of the detection system, are shown in more detail.
  • the recognition system (briefly referred to as "system” in the illustration in FIG. 3) receives a customer business process GP.
  • the customer can also transmit so-called setup data to the system.
  • This initial setup data is stored in the system in the knowledge base, which comprises learned / historical knowledge.
  • the business process received is examined by the system, in particular using the data available in the knowledge base, i.e. learned / historical knowledge and supplier ERP system information.
  • the customer business process is recognized
  • the recognized information is transferred in a format compatible with the company's internal ERP system.
  • the customer business process is not recognized
  • a business process recognized by the recognition system runs through a system confidence query after the transfer into an ERP-compatible format. This is particularly useful in the implementation or initial phase of operation of the system according to the invention when the detection rate is still below a predefinable threshold value. If the detection probability is insufficient (detection rate ⁇ x%), the identified business runs through process another check before it is released in the contractor's ERP system.
  • data and information obtained from the recognition process are stored in the knowledge base (represented by dashed lines in the functional diagram). This can be done by storing the forms or form features and the associated recognition results, in particular those supplemented by manual intervention, or by transferring the generated order data without resorting to order forms, i.e. a dynamic improvement of the knowledge base.
  • the invention naturally also extends to computer programs with program code means which are suitable for executing a method according to the invention when the computer program runs on a computer, as well as to computer-readable data carrier media with computer programs according to the invention stored thereon and to computer program products with such computer-readable data carrier media.
  • FIG. 1 shows a schematic illustration to illustrate the problem underlying the invention.
  • Figure 2 shows a highly schematic functional diagram of the invention.
  • FIG. 3 shows a more detailed illustration of the functional diagram of FIG. 2.
  • FIG. 4 shows an outline of the recognition steps according to the invention.
  • FIG. 5 shows, using a flow chart, the schematic sequence for the recognition of a business partner according to the invention in the case of an electronic message (email).
  • FIG. 6 uses a flow chart to show the schematic sequence for the recognition of the business partner according to the invention in the case of a fax message.
  • FIG. 7 shows, using a flow chart, the schematic sequence of the recognition of the document type or the business process according to the invention.
  • FIG. 8 shows a schematic representation of the detection or determination of the information requirement.
  • FIG. 9 shows a schematic flowchart representation of the inventive recognition of the information from the transmitted business process.
  • FIG. 10 shows a schematic overview of a system architecture according to the invention.
  • FIG. 11 shows a schematic representation of the structure of the recognition module (module 100).
  • FIG. 12 illustrates in a flow chart the sequence of dynamic recognition of a document content according to the invention.
  • FIG. 5 schematically shows an example of the process of recognizing the business partner / customer in the case of an electronic message (e-mail).
  • the exemplary description is based on the structure of an e-mail address according to the usual standard, namely [email protected], where 2ld is the 2nd level domain and tld is the top level domain.
  • 2ld is the 2nd level domain
  • tld is the top level domain.
  • the sender's (customer) email address is compared with the email addresses stored in the business partner database. For the example described, the sender's email address should be "[email protected]”. Is this email address saved in the business partner database the business partner is recognized immediately, and the second step "recognition of the document type / business process" (cf. FIG. 4) can be continued.
  • the 2nd level domain in the present case "schroeder" will be used using the business partner database and, if necessary, of the data in the company's internal ERP system (customer list) examined.
  • the next step is to examine the user name (in the present case "one"). If a customer with the name "Meier” is identified in the ERP system database, the company for which he works must be compared with the information known from the 2nd level domain. If the determined customer Meier works for a company with the name Schroeco AG, for example, it can be determined from the stored data that this is a holding company to which a company Schröder GmbH belongs.
  • the last option is to determine the business partner using a semantic / fuzzy search in the entire content of the electronic message.
  • the information to be recognized can therefore also refer to the information recognized in another recognition stage.
  • An analogous procedure takes place in the case of the transmission of a business process by fax.
  • the recognition process is carried out on the basis of the business partner's fax number (cf. FIG. 6).
  • FIG. 7 illustrates the second step “recognition of the document type / business process” in the recognition process according to the invention, as shown in FIG. 4.
  • this second step can also be exchanged with the first, that is to say before the business partner is recognized. This is particularly recommended if only a few business processes are supported by the process, for example in the initial phase of a system implementation. In the present exemplary embodiment, however, a procedure as shown in FIG. 4 is assumed, in which the recognition of the document type / the business process is the second step.
  • information is first retrieved from the business process database which business processes the identified customer has with the provider / contractor.
  • Schroeco AG which has already been given as an example, it follows that it has previously carried out the business processes "delivery schedule" and "order”. It is then checked whether there are corresponding sample documents in the document database. If this is the case, a comparison is made as to whether the documents received match the sample documents. If this is again the case or almost the case, then a semantic or fuzzy check is used to determine whether it is an order or a delivery schedule with a sufficiently high degree of certainty / probability. As a result, it can be stated, for example, that Mr. Meier von has sent an order electronically to Schroeco AG.
  • step 3 Determining the information requirement (cf. FIG. 4), according to the exemplary representation in FIG. 8, a table is used to determine which data are necessary for the complete recognition of the business process (in the example described an order) and where it is, for example, in the data warehouse appropriate relevant information is available.
  • the quantity and the delivery date are required for the complete recognition of an order.
  • Information from the customer's historical orders, i.e. from Schroeco AG, and product data available via database such as minimum order quantity etc. can be used for the quantity.
  • product data available via database such as minimum order quantity etc.
  • a calendar and product data such as manufacturing time, etc., which are also available via databases, are used. The information obtained is stored in the document database.
  • FIG. 9 schematically illustrates the sequence of the fourth and last step of the “recognition of information from the business process”.
  • the term date used here represents the singular of "data”, meaning single data information.
  • the first date to be extracted in the exemplary embodiment is the delivery quantity.
  • historical order data from Schroeco AG are researched and it is found, for example, that 90% of Schroeco AG orders 20 tons and only 10% orders 10 tons. From the ERP or other database, information is received that 10 tons represent the minimum order quantity.
  • the information that Schroeco AG orders 20 tons is extracted with the help of semantic recognition and / or artificial intelligence / fuzzy queries.
  • the second date to be extracted in this embodiment is the delivery date. Following the table previously created in the document database, orders prior to today are excluded and, given a manufacturing time (obtained from the database) of 10 days, an order for the period starting in 10 days is considered most likely. With the help of semantic recognition and / or artificial intelligence / fuzzy queries, the information is extracted on the basis of this knowledge that Schroeco AG wishes a delivery in three weeks.
  • an EDP and software system for the fully automatic recognition of customer orders and for the transfer of read and recognized orders to an ERP (Enterprise Resource Planning) system (for example of the type SAP R / 3).
  • the system according to the invention comprises the modules described in more detail below, namely a recognition module 100, a knowledge base 200, an enrichment module 300, a transmission module 400 and an ERP system 500.
  • the recognition module 100 is used to recognize the data necessary for generating a business process (for example an order) in an ERP system. It is assumed here that not all data that have to be entered in an ERP system to create a business process (e.g. an order) must be recognized, but that the data to be recognized can be completed, for example, by material master data and customer profile data.
  • the components of the detection module 100 are as follows:
  • System for character recognition e.g. Optical Character Recognition (OCR)
  • OCR Optical Character Recognition
  • Module 200 serves to support the activity of the recognition module 100.
  • the module 200 represents a knowledge base in the form of a database or a bidirectionally addressable ERP system.
  • the components of the knowledge base 200 are as follows:
  • Master data for materials that can be ordered i.e. data for an assortment of relevant articles
  • Master data for business partners i.e. profiles of possible customers (includes, for example, information on customer roles with associated unique identification numbers, addresses, ordering habits, special requests, etc.)
  • Enrichment module 300 is used for manual enrichment of output data records of module 200 that are not fully recognized.
  • the transmission module 400 is used for enrichment and reformatting into a format of the data record recognized from module 200 or module 300 that can be imported by the ERP system used.
  • business integration software of the type TSI Mercator is used for this.
  • the components of the known transmission module 400 are as follows:
  • Output component for transferring the formatted data record to an ERP system The module labeled 500 is an ERP system, for example of the type SAP R / 3.
  • the components of the ERP system 500 are as follows:
  • the recognition module 100 accesses a file in the “character recognition” component 110 and converts the information contained in this file into a text file (cf. FIG. 11).
  • Input formats form, for example, image files, for example of the types BMP, BW, DCX, DIB, EMF, GIB, GIF, TIF, ILBM, JFIF, JIF, JPEG, LBM, PCD, PCS, PIC, PIX, PNG, PSD, RGB, RLE, SGI, TGA, TIFF or WMA, Postscript and reader files, e.g.
  • the Types Postscript or Adobe Acrobat Reader File markup language files such as HTML or XML files, document files from a word processing system, eg Microsoft Word documents, text files, eg of the ASCII or Rieh Text Format type
  • the files are read in by known and commercially available Optical Character Recognition (OCR) systems, for example of the OCE Docustar type, and output or reformatted as an ASCII or Rieh Text format file.
  • OCR Optical Character Recognition
  • the “rules” component 130 provides a set of rules with two types of rules: on the one hand, rules for the format of the ones to be found Fields [example: order date has the format (dd / mm / yyyy) or (dd / mm / yy) or (dd-mm-yyyy) or ...] and on the other rules for the semantic context of the information relevant to hypothesis creation [example : "The order number is often close to the string (order no.)" Or "The order date is always before the desired delivery date”].
  • the hypotheses are passed on to the "dynamic recognition" component 140 for testing, which checks the hypotheses obtained from the "static recognition” 120 using criteria and rules from the "criteria / rules” component 150 and using the knowledge base 200 corresponding test algorithm is shown in Figure 12.
  • the elements in the algorithm shown are defined as follows:
  • the criteria in component 150 are divided into two classes: on the one hand, criteria that can be used exploratory (exploratory criteria j) and, on the other hand, those that cannot be used exploratory but only confirmatively (confirmatory criteria k).
  • the criteria are arranged hierarchically within their class, the sharpest criterion of the class is the first (j ⁇ (Ri) or ki (Ri)), as the index number increases, the criteria decrease.
  • the criteria can be checked by a sharp yes / no query (possible results would be mathematically designated 0 or 1 here) or by an unsharp query (fuzzy logic).
  • the affiliation of the hypothesis to be tested to a fuzzy set defined by the rule of the criterion and the possibly associated data from the knowledge base can be normalized by a value in the interval [0.1].
  • a confidence interval i.e. an area within the in- tervalls, for which the hypothesis withstands the criterion if the value of membership in the fuzzy set is within the range.
  • hypotheses If there are more than zero hypotheses [H m (R ⁇ )], the compatibility with the first exploratory criterion (j ⁇ (Ri)) is checked in succession for all available hypotheses. Hypotheses that are not compatible with the criterion are rejected. After checking all the hypotheses, the remaining hypotheses [H m (R ⁇ )] are counted. If the hypothesis count is more than 1 and there are other exploratory criteria, the test is repeated with the next hierarchically lower criterion. If there are no further exploratory criteria or if the hypothesis count was 0, the Ri detection failed. It is checked whether further data to be found are missing. If this is the case, the process is continued with the next date (here: R 2 ), otherwise the process is ended.
  • R 2 next date
  • the compatibility of the hypothesis with the hierarchically highest confirmatory criterion (here: ki (R x )) is checked. If the compatibility is not given, the recognition of the date (here: R x ) has failed. It is checked whether further data to be found are missing. If this is the case, the process is continued with the next date (here: R 2 ), otherwise the process is ended.
  • the content of the criteria used relates to the data in the knowledge base (component 200). For example, a criterion when searching for the client (example: read: "The company name mentioned in the hypothesis can be found in this or similar form in the customer list in the knowledge base”.
  • the data to be found as well as the criteria should be in a hierarchical order so that the results of previous sub-processes can be referred to during the recognition process, thus reducing the complexity and increasing the probability of recognizing a specific date.
  • a criterion for identifying the recipient of the goods could be: "The company address specified in the hypothesis can be found in this or similar form in the customer list in the knowledge base, if Ri was successfully found in the list of recipient addresses assigned to this customer ".
  • the output module 160 checks whether all the data to be found (Ri to R max ) have been found by the “dynamic detection” component 140. If so, the data found (Ri to R ma ⁇ ) are transferred to the transmission module 400, if so they are not passed to module 300 for manual enrichment.
  • module 130 states that this must be a sequence of letters that begins with a capital letter.
  • the first exploratory criterion is:
  • the client named in the hypothesis is available in the customer database in the knowledge base (module 200).
  • the test finds a "Meier GmbH” in the knowledge base.
  • the fuzzy test gives a value of, for example, 0.8 of the belonging to the value "Meier” from the hypothesis H ⁇ (R ⁇ ). Since the confidence interval for this criterion is 0.6 to 1, the hypothesis holds up to the test.
  • the second exploratory criterion would result in only the hypothesis H ⁇ (R ⁇ ) remaining. Meier GmbH would therefore be accepted as the client. Nevertheless, there is still an exploratory criterion. This would be applied to Meier GmbH. Meier GmbH also adheres to this criterion was standing. So the exploratory criterion was transformed into a confirmatory criterion, so to speak. Accordingly, other exploratory criteria would be used before the Meier GmbH test with the confirmatory criteria is continued. If the hypothesis also holds up, the detection of Ri is true, the result is the customer number of Meier GmbH, for example "4711".
  • a system design is also conceivable in which the confirmatory use of criteria does not immediately result in a negative test result Rejection of the hypothesis leads, but is correspondingly included in an assessment parameter of the hypothesis quality, which, after having gone through all the criteria, is compared with a corresponding confidence interval and only leads to rejection of the hypothesis below a confidence threshold.
  • the knowledge base can, for example, be limited to the consignees who are assigned to the customer 4711, i.e. Meier GmbH.
  • the work station module 300 receives from the output 160 of the module 100 the data records in which not all of the data has been completely recognized.
  • the clerk has the option of manually maintaining unrecognized data fields on a screen.
  • the system either provides it as a soft copy, i.e. on the image screen, the original document, or creates a hard copy, for example in the form of a paper printout.
  • the clerk thus has the opportunity to understand which value is to be assigned to the corresponding field and inserts the corresponding data into the module 300.
  • it can be offered optional options based on the hypotheses generated in component 120.
  • the work station module 300 transfers the data to the transmission module 400.
  • the clerk searches for it in the original document and adds it to the data record via the user interface in the work station module 300. If no further data are missing, the module then passes the data on to module 400 as described.
  • the transmission module 400 receives the complete data from module 100 or 300.
  • the data may be different. not complete enough to trigger a business transaction, in our example an order, in an ERP system.
  • Component 410 enriches the data record with information that is defined as inevitable when the data is combined as in the data record. This could be, for example, a warehouse that is mandatory for a certain customer-product combination to send the goods.
  • component 420 After the data record has been enriched, it must be converted in component 420 into a format that the ERP system can process in module 500. If a system of type SAP R / 3 is used in module 500, for example, component 420 converts the data record into a SAP intermediate document (IDoc). Component 430 transfers the result to the ERP system, so in the exemplary embodiment described it sends the IDoc to the SAP R / 3 system.
  • SAP R / 3 SAP intermediate document
  • the ERP system (module) 500 describes an ERP system that has at least the functions customary in the market.
  • An example of such a system is the R / 3 model from SAP.
  • the ERP system must be able to receive records that it receives from component 430 for processing. This requires an interface that processes the generated format, in the example described an interface that can process IDocs (component 510). Since the other functions are not part of the system described here, but are common in the market, we will not go into them here.
  • Component 520 is an exception:
  • the knowledge base (module 200) must have the ability to access the defined information from the ERP system. Depending on the system design, this is done by direct (online) access of the knowledge base to the data storage in the ERP system, for example to the SAP data warehouse, or via a periodic or event-related download of the relevant information directly into the database the knowledge base. The supply of the required data warehouse with the necessary data from module 500 must therefore be ensured.
  • the system according to the invention comprises a known interactive answering machine, which the customer at his Order call welcomed and accompanied by the order process.
  • the customer's information is entered using keys or voice input.
  • the customer provides his customer number and / or an identification and authorization number (PIN) in turn, it should be noted that the invention also works without such a PIN due to the above-described recognition system.
  • PIN identification and authorization number
  • the customer can then specify whether it is a new order or the processing of an already placed order (change / cancellation).
  • a new order the customer specifies the consignee number, customer order number, article number, desired quantity and desired delivery date.
  • the customer shall indicate the order number of the contractor already known to him at that time and whether it is a change or cancellation.
  • the customer then hears a summary of the information he has provided.
  • the answering machine "reads" the recorded voice inputs, that is, plays them back.
  • the customer is played a voice message generated electronically based on the key inputs.
  • the customer then has the option of making changes, making further orders and / or placing the order to confirm.
  • the customer details are transferred to the internal ordering system and, as explained in detail above, are transferred to the Plausibility of the order checked. After the check has been carried out, the customer receives an automatically generated order confirmation by electronic mail or by fax.
  • the telephone information of the customer is checked in parallel with his order, so that the customer can still receive automatic feedback during the telephone ordering process as to whether his order (or change / cancellation request) has been accepted and which order - number assigned to the order.
  • the customer can also query the status of his order over the phone by specifying the order number known to him at the time of the call and receiving an answer from the ordering system (ERP system) as to whether the Order is still open (ie has not yet been produced or sent), has been allocated (ie has been produced but not yet sent) or has already been sent.
  • ERP system ordering system
  • the invention thus makes it possible for customers to carry out business processes on the basis of a running text, other unformatted text, the telephone or even using their own order forms, which can be recognized and processed completely and correctly on the contractor side with little or no human intervention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Data Mining & Analysis (AREA)
  • Multimedia (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Character Discrimination (AREA)

Abstract

L'invention concerne un procédé et un dispositif d'évaluation exécutée dans un ordinateur de procédures commerciales électroniques à l'aide d'un système informatique. Pour vérifier des données pertinentes en termes de procédure commerciale et contenues dans la procédure commerciale (GP) entrée dans le système informatique, lors d'une première étape de vérification, on procède à la vérification statique des données sur la base d'une reconnaissance de caractères et à la création d'hypothèses sur le contenu de chaque donnée vérifiée et, lors d'une deuxième étape de vérification, on procède à une vérification dynamique des hypothèses créées. Selon l'invention, on synchronise les contenus de données reconnus par voie électronique aux données spécifiques au client et/ou au matériel et contenues dans une base de connaissances (200).
EP02791714A 2001-11-26 2002-11-26 Procede et dispositif d'evaluation executee dans un ordinateur de procedures commerciales clients Ceased EP1451745A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10158843 2001-11-26
DE10158843 2001-11-26
PCT/EP2002/013277 WO2003046779A1 (fr) 2001-11-26 2002-11-26 Procede et dispositif d'evaluation executee dans un ordinateur de procedures commerciales clients

Publications (1)

Publication Number Publication Date
EP1451745A1 true EP1451745A1 (fr) 2004-09-01

Family

ID=7707561

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02791714A Ceased EP1451745A1 (fr) 2001-11-26 2002-11-26 Procede et dispositif d'evaluation executee dans un ordinateur de procedures commerciales clients

Country Status (7)

Country Link
US (1) US20050131751A1 (fr)
EP (1) EP1451745A1 (fr)
JP (1) JP2005510810A (fr)
KR (1) KR20040058328A (fr)
AU (1) AU2002358041A1 (fr)
CA (1) CA2467967A1 (fr)
WO (1) WO2003046779A1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8396859B2 (en) 2000-06-26 2013-03-12 Oracle International Corporation Subject matter context search engine
US7536634B2 (en) * 2005-06-13 2009-05-19 Silver Creek Systems, Inc. Frame-slot architecture for data conversion
US7945891B2 (en) * 2006-04-12 2011-05-17 Microsoft Corporation Time business process validations within data context
US8108764B2 (en) * 2007-10-03 2012-01-31 Esker, Inc. Document recognition using static and variable strings to create a document signature
US8094976B2 (en) * 2007-10-03 2012-01-10 Esker, Inc. One-screen reconciliation of business document image data, optical character recognition extracted data, and enterprise resource planning data
US8136095B2 (en) * 2007-12-19 2012-03-13 Microsoft Corporation Relations in fuzzing data
US8286133B2 (en) * 2007-12-19 2012-10-09 Microsoft Corporation Fuzzing encoded data
JP2016536655A (ja) * 2013-09-17 2016-11-24 ストリームライン・メディア・グループ・インコーポレーテッド 柔軟なプロジェクト管理のためのコンピュータ・ベース・システムおよび方法
CN108256829B (zh) * 2018-01-26 2020-07-31 北京语言大学 一种面向erp技能在线阅卷的数据抽取方法及***
JP6592731B2 (ja) * 2018-01-30 2019-10-23 ツバイソ株式会社 自律型システム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5937084A (en) * 1996-05-22 1999-08-10 Ncr Corporation Knowledge-based document analysis system
US6519562B1 (en) * 1999-02-25 2003-02-11 Speechworks International, Inc. Dynamic semantic control of a speech recognition system
AU2002334954B2 (en) * 2001-10-11 2008-07-31 Omniture, Inc. System, method, and computer program product for processing and visualization of information

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO03046779A1 *

Also Published As

Publication number Publication date
WO2003046779A1 (fr) 2003-06-05
JP2005510810A (ja) 2005-04-21
AU2002358041A1 (en) 2003-06-10
US20050131751A1 (en) 2005-06-16
CA2467967A1 (fr) 2003-06-05
KR20040058328A (ko) 2004-07-03

Similar Documents

Publication Publication Date Title
DE69736973T2 (de) Informationsverarbeitungssystem und Verfahren dafür
DE60002876T2 (de) Darstellung, verwaltung und synthese von technischen inhalten
Inmon et al. Tapping into unstructured data: Integrating unstructured data and textual analytics into business intelligence
DE19844071A1 (de) Verfahren zum Lösen von Datenkonflikten in einem gemeinsamen Datenumfeld
DE19706419A1 (de) Verfahren und Vorrichtung zur Steuerung von Prozessen unter Verwendung einer Technologie zur maschinellen Sprachverarbeitung
EP2323083A1 (fr) Système de classification technique
EP1451745A1 (fr) Procede et dispositif d'evaluation executee dans un ordinateur de procedures commerciales clients
DE10151648B4 (de) Verfahren und Vorrichtung zum Erfassen und Speichern von während einer computerbasierten Sitzung gemachten Notizen
DE112020000004T5 (de) Informationsbereitstellungssystem und Informationsbereitstellungsverfahren
DE112020000003T5 (de) Informationsbereitstellungssystem und Informationsbereitstellungsverfahren
DE60203117T2 (de) Signalisierung von ereignissen in arbeitsfluss-verwaltungssystemen
WO2000072114A2 (fr) Systeme et procede pour la publication de manuscrits
EP1605368B1 (fr) Génération des fichiers electroniques de signatures
EP1239375B1 (fr) Procédé de conversion de documents
WO2023066629A1 (fr) Procédé mis en œuvre par ordinateur pour assister la planification et l'organisation d'un projet de construction, dispositif de traitement de données en tant que partie d'un tel procédé et programme informatique permettant la mise en œuvre d'un tel procédé
Kwok et al. A web services integration to manage invoice identification, metadata extraction, storage and retrieval in a multi-tenancy SaaS application
DE10234004A1 (de) Verfahren und System zur Abwicklung von Bestellvorgängen
DE19635351C2 (de) Verfahren zur Formatkonvertierung
DE10116540A1 (de) System und Verfahren zur kontextbezogenen Protokollierung insbesondere im Umfeld Produktion, Montage, Service oder Wartung
EP0749604B1 (fr) Procede de communication
DE102015008607A1 (de) Adaptives Anpassen von Netzwerk-Anforderungen auf Client-Anforderungen in digitalen Netzwerken
DE202022002785U1 (de) Ein computerimplementiertes Vernetzungssystem einer Prozessumgebung zum Steuern eines oder mehrerer Prozesse in der Prozessumgebung
DE102010055508A1 (de) Dialogsystem für ein Sozialmedien-Kontakt-Center
EP1191458B1 (fr) Association bidirectionale d'une base de données à un système de fichiers
EP3531300A1 (fr) Procédé mis en oeuvre par ordinateur permettant d'obtenir des informations

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

17P Request for examination filed

Effective date: 20040628

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

17Q First examination report despatched

Effective date: 20040824

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20050906