WO2022203591A1

WO2022203591A1 - Compatibility scoring system and method for evaluating compatibility

Info

Publication number: WO2022203591A1
Application number: PCT/SG2021/050153
Authority: WO
Inventors: Lounell Bahoy GUETA
Original assignee: Hitachi, Ltd.
Priority date: 2021-03-22
Filing date: 2021-03-22
Publication date: 2022-09-29

Abstract

A system for evaluating compatibility between a requestor and at least one entity may include a requestor unit which may receive a request from the requestor. The system may also include a compatibility scoring unit which may receive the request from the requestor unit. The compatibility scoring unit may generate types of data required based on the request and may choose the at least one entity to request the types of data required from. The system may include at least one data gathering unit which may receive the types of data required from the compatibility scoring unit. The at least one data gathering unit may send compatibility data to the compatibility scoring unit, which may obtain at least one compatibility score based on the compatibility data. The system may include a reporting unit which may receive the at least one compatibility score, and display the at least one compatibility score.

Description

COMPATIBILITY SCORING SYSTEM AND METHOD FOR EVALUATING

COMPATIBILITY

BACKGROUND

[0001] Suppliers of goods and services are generally required to show proof of credibility by providing documentations on financial capability and trustworthiness to potential customers, partners, or trustors (e.g. banks that provide loans). Credit score is often used but may not be applicable for suppliers with limited financial records such as start-up and new companies, or with recently unfavourable records such as companies that have just transitioned to a new business. They may struggle to expand business despite their sufficient capability of providing high quality services or goods. On the other hand, a sourcing company looking for new suppliers may be short-sighted by solely relying on financial information. [0002] Although widely used, credit score as an absolute value may fail to capture nuances in some business situations. For instance, two sourcing companies may be evaluating a supplier using same credit information. These two sourcing companies may have different risk appetites or specific operational requirements, among other factors. A credit score, as an absolute measurement may not be sufficient to determine if a sourcing company and a supplier are compatible with each other in conducting business.

[0003] Aside from requiring financial information, onsite visits in a factory or a workplace where a service or a product is created are required, to onboard new suppliers. This process may be limiting since an inspector may subjectively evaluate the processes, methods, among others as human factors and bias may come into play. Further, onsite visits may not be practical for occasions when stringent and time-consuming measures must be carried out. For example, conducting an onsite visit during a pandemic may be impractical as face-to-face communication is discouraged, and physical movement is restricted. SUMMARY

[0004] An advantage of the present disclosure may include a relative scale which may be influenced by two entities, a supplier and a sourcing entity, which may cover evaluations beyond credit or trustworthiness scores, and may include alignment to business value or goal, sharing risks among others.

[0005] An advantage of the present disclosure may include efficiently evaluating entities, avoiding subjective judgement of an inspecting company, and objectively evaluate a supplier without requiring an onsite visit.

[0006] These and other aforementioned advantages and features of the aspects herein disclosed will be apparent through reference to the following description and the accompanying drawings. Furthermore, it is to be understood that the features of the various aspects described herein are not mutually exclusive and can exist in various combinations and permutations.

[0007] The present disclosure generally relates to a compatibility scoring system for evaluating compatibility between a requestor and at least one entity. The compatibility scoring system may include a requestor unit which may be configured to receive a request from the requestor. The compatibility scoring system may also include a compatibility scoring unit which may be configured to receive the request from the requestor unit. The compatibility scoring unit may be configured to generate types of data required based on the request, and may be configured to choose the at least one entity to request the types of data required from. The compatibility scoring system may include at least one data gathering unit which may be configured to receive the types of data required from the compatibility scoring unit. The at least one data gathering unit may also be configured to send compatibility data from the at least one entity to the compatibility scoring unit. The compatibility scoring unit may be configured to obtain at least one compatibility score based on the compatibility data. The compatibility scoring system may also include a reporting unit which may be configured to receive the at least one compatibility score, and may display the at least one compatibility score.

[0008] The present disclosure generally relates to a method for evaluating compatibility between a requestor and at least one entity. The method may include receiving a request from the requestor using a requestor unit. The method may also include sending the request from the requestor unit to a compatibility scoring unit, and may include using the compatibility scoring unit to generate types of data required based on the request. The method may include choosing the at least one entity to request the types of data required from. The method may further include sending the types of data required from the compatibility scoring unit to at least one data gathering unit. The method may also include sending compatibility data from the at least one entity to the compatibility scoring unit, and may include using the compatibility scoring unit to obtain at least one compatibility score based on the compatibility data. The method may further include sending the at least one compatibility score to a reporting unit, and may include using the reporting unit to display the at least one compatibility score.

[0009] To the accomplishment of the foregoing and related ends, the one or more embodiments include the features hereinafter fully described and particularly pointed out in the claims. The following description and the associated drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.

BRIEF DESCRIPTION OF THE DRAWINGS [0010] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the present disclosure. The dimensions of the various features or elements may be arbitrarily expanded or reduced for clarity. In the following description, various aspects of the present disclosure are described with reference to the following drawings, in which:

[0011] FIG. 1 illustrates a compatibility scoring system according to an embodiment of the present disclosure;

[0012] FIG. 2A illustrates an item specification according to an embodiment of the present disclosure;

[0013] FIG. 2B illustrates a process specification according to an embodiment of the present disclosure;

[0014] FIG. 2C illustrates a partner specification according to an embodiment of the present disclosure;

[0015] FIG. 2D illustrates a compliance specification according to an embodiment of the present disclosure;

[0016] FIG. 3 illustrates types of data required according to an embodiment of the present disclosure;

[0017] FIG. 4A illustrates examples of compatibility score according to an embodiment of the present disclosure;

[0018] FIG. 4B illustrates a scale for interpreting the compatibility score according to an embodiment of the present disclosure;

[0019] FIG. 5 illustrates a compatibility scoring system according to an embodiment of the present disclosure; [0020] FIG. 6 illustrates a compatibility scoring centralized architecture according to an embodiment of the present disclosure;

[0021] FIG. 7 illustrates a compatibility scoring decentralized architecture according to an embodiment of the present disclosure;

[0022] FIG. 8 illustrates a requestor unit according to an embodiment of the present disclosure;

[0023] FIG. 9 illustrates a compatibility scoring unit according to an embodiment of the present disclosure;

[0024] FIG. 10A shows a flow chart of determining data requirement according to an embodiment of the present disclosure;

[0025] FIG. 10B exemplifies a model to represent the objects for item, entity, and flow according to an embodiment of the present disclosure;

[0026] FIG. IOC exemplifies a model including a requestor according to an embodiment of the present disclosure.

[0027] FIG. 11 shows a flow chart of evaluating compatibility score according to an embodiment of the present disclosure;

[0028] FIG. 12 illustrates a reporting unit according to an embodiment of the present disclosure;

[0029] FIG. 13 illustrates a compatibility scoring unit according to an embodiment of the present disclosure;

[0030] FIG. 14 illustrates examples of compatibility matches according to an embodiment of the present disclosure;

[0031] FIG. 15 shows a flow chart of compatibility matching according to an embodiment of the present disclosure; [0032] FIG. 16A illustrates an exemplary interface of a compatibility scoring unit according to an embodiment of the present disclosure;

[0033] FIG. 16B illustrates an exemplary interface of a requestor profile according to an embodiment of the present disclosure;

[0034] FIG. 16C illustrates an exemplary interface to set a specification according to an embodiment of the present disclosure;

[0035] FIG. 16D illustrates an exemplary interface to view previous evaluation or to view history according to an embodiment of the present disclosure;

[0036] FIG. 17 illustrates an exemplary interface of a report from a reporting unit according to an embodiment of the present disclosure;

[0037] FIG. 18 illustrates an exemplary interface of a supplier’s network according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

[0038] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Other embodiments may be utilized and structural, and logical changes may be made without departing from the scope of the invention. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0039] Embodiments described in the context of one of the systems or server or methods or computer program are analogously valid for the other systems or server or methods or computer program and vice-versa. [0040] Features that are described in the context of an embodiment may correspondingly be applicable to the same or similar features in the other embodiments. Features that are described in the context of an embodiment may correspondingly be applicable to the other embodiments, even if not explicitly described in these other embodiments. Furthermore, additions and/or combinations and/or alternatives as described for a feature in the context of an embodiment may correspondingly be applicable to the same or similar feature in the other embodiments.

[0041] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or designs [0042] In the context of various embodiments, the articles “a”, “an”, and “the” as used with regard to a feature or element include a reference to one or more of the features or elements.

[0043] As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

[0044] The terms “at least one” and “one or more” may be understood to include a numerical quantity greater than or equal to one (e.g., one, two, three, four, [...], etc.). The term “a plurality” may be understood to include a numerical quantity greater than or equal to two (e.g., two, three, four, five, [...], etc.).

[0045] The words “plural” and “multiple” in the description and the claims expressly refer to a quantity greater than one. Accordingly, any phrases explicitly invoking the aforementioned words (e.g. “a plurality of [objects]”, “multiple [objects]”) referring to a quantity of objects expressly refers more than one of the said objects. The terms “group (of)”, “set [of]”, “collection (of)”, “series (of)”, “sequence (of)”, “grouping (of)”, etc., and the like in the description and in the claims, if any, refer to a quantity equal to or greater than one, i.e. one or more. The terms “proper subset”, “reduced subset”, and “lesser subset” refer to a subset of a set that is not equal to the set, i.e. a subset of a set that contains less elements than the set.

[0046] The term “data” as used herein may be understood to include information in any suitable analog or digital form, e.g., provided as a file, a portion of a file, a set of files, a signal or stream, a portion of a signal or stream, a set of signals or streams, and the like. Further, the term “data” may also be used to mean a reference to information, e.g., in form of a pointer. The term data, however, is not limited to the aforementioned examples and may take various forms and represent any information as understood in the art.

[0047] The term “processor” or “controller” as, for example, used herein may be understood as any kind of entity that allows handling data, signals, etc. The data, signals, etc. may be handled according to one or more specific functions executed by the processor or controller.

[0048] A processor or a controller may thus be or include an analog circuit, digital circuit, mixed-signal circuit, logic circuit, processor, microprocessor, Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), integrated circuit, Application Specific Integrated Circuit (ASIC), etc., or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as a processor, controller, or logic circuit. It is understood that any two (or more) of the processors, controllers, or logic circuits detailed herein may be realized as a single entity with equivalent functionality or the like, and conversely that any single processor, controller, or logic circuit detailed herein may be realized as two (or more) separate entities with equivalent functionality or the like.

[0049] The term “system” (e.g., a drive system, a position detection system, etc.) detailed herein may be understood as a set of interacting elements, the elements may be, by way of example and not of limitation, one or more mechanical components, one or more electrical components, one or more instructions (e.g., encoded in storage media), one or more controllers, etc.

[0050] A “circuit” as user herein is understood as any kind of logic-implementing entity, which may include special-purpose hardware or a processor executing software. A circuit may thus be an analog circuit, digital circuit, mixed-signal circuit, logic circuit, processor, microprocessor, Central Processing Unit (“CPU”), Graphics Processing Unit (“GPU”), Digital Signal Processor (“DSP”), Field Programmable Gate Array (“FPGA”), integrated circuit, Application Specific Integrated Circuit (“ASIC”), etc., or any combination thereof. Any other kind of implementation of the respective functions which will be described below in further detail may also be understood as a “circuit.” It is understood that any two (or more) of the circuits detailed herein may be realized as a single circuit with substantially equivalent functionality, and conversely that any single circuit detailed herein may be realized as two (or more) separate circuits with substantially equivalent functionality. Additionally, references to a “circuit” may refer to two or more circuits that collectively form a single circuit.

[0051] As used herein, “memory” may be understood as a non-transitory computer- readable medium in which data or information can be stored for retrieval. References to “memory” included herein may thus be understood as referring to volatile or non-volatile memory, including random access memory (“RAM”), read-only memory (“ROM”), flash memory, solid-state storage, magnetic tape, hard disk drive, optical drive, etc., or any combination thereof. Furthermore, it is appreciated that registers, shift registers, processor registers, data buffers, etc., are also embraced herein by the term memory. It is appreciated that a single component referred to as “memory” or “a memory” may be composed of more than one different type of memory, and thus may refer to a collective component including one or more types of memory. It is readily understood that any single memory component may be separated into multiple collectively equivalent memory components, and vice versa. Furthermore, while memory may be depicted as separate from one or more other components (such as in the drawings), it is understood that memory may be integrated within another component, such as on a common integrated chip.

[0052] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects in which the present disclosure may be practiced. These aspects are described in sufficient detail to enable those skilled in the art to practice the present disclosure. Various aspects are provided for the present system, and various aspects are provided for the methods. It will be understood that the basic properties of the system also hold for the methods and vice versa. Other aspects may be utilized and structural, and logical changes may be made without departing from the scope of the present disclosure. The various aspects are not necessarily mutually exclusive, as some aspects can be combined with one or more other aspects to form new aspects.

[0053] To more readily understand and put into practical effect, the present system, method, and other particular aspects will now be described by way of examples and not limitations, and with reference to the figures. For the sake of brevity, duplicate descriptions of features and properties may be omitted.

[0054] It will be understood that any property described herein for a specific system or device may also hold for any system or device described herein. It will also be understood that any property described herein for a specific method may hold for any of the methods described herein. Furthermore, it will be understood that for any device, system, or method described herein, not necessarily all the components or operations described will be enclosed in the device, system, or method, but only some (but not all) components or operations may be enclosed. [0055] The term “comprising” shall be understood to have a broad meaning similar to the term “including” and will be understood to imply the inclusion of a stated integer or operation or group of integers or operations but not the exclusion of any other integer or operation or group of integers or operations. This definition also applies to variations on the term “comprising” such as “comprise” and “comprises”.

[0056] The term “coupled” (or “connected”) herein may be understood as electrically coupled or as mechanically coupled, e.g., attached or fixed or attached, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.

[0057] The term “entity” herein may be understood as a human user, a business, a group of users or an organization.

[0058] FIG. 1 illustrates a compatibility scoring system according to an embodiment of the present disclosure.

[0059] In an embodiment of the present disclosure, the compatibility scoring system 100 may be used for evaluating compatibility, for example, between a requestor and at least one entity.

[0060] In an embodiment, the compatibility scoring system 100 may include a requestor unit 110. In an embodiment, the requestor unit 110 may provide an interface for the requestor. The requestor may be an entity, for example, a supplier entity or a sourcing entity.

[0061] In an embodiment, the requestor unit 110 may receive a request from the requestor. The request may include a specification 111. In an embodiment, the specification 111 may identify or state a precise requirement. In an embodiment, the specification 111 may include at least one of an item specification, a process specification, a partner specification and/or a compliance specification. [0062] As an example, a supplier entity as a requestor may intend to find a sourcing entity.

As another example, a sourcing entity as a requestor may intend to search for a supplier, e.g., based on a specified specification input. Other suitable permuatations may also be used. [0063] In an embodiment of the present disclosure, the compatibility scoring system 100 may include a compatibility scoring unit 120. In an embodiment, the compatibility scoring unit 120 may be configured to receive the request from the requestor unit 110.

[0064] In an embodiment, the compatibility scoring unit 120 may process the request which may include the specification 111. In an embodiment, the compatibility scoring unit 120 may generate types of data required 121 based on the request and/or the specification 111. The types of data required 121 may also be referred to as data requirement 121.

[0065] In an embodiment, the types of data required may include credibility data, operationality data and sustainability data. In an embodiment, the credibility data may include at least one of partner specification, product portfolio, and credit score. In an embodiment, the operationality data may include at least one of product specification, process specification, production flow, material flow and supply flow. In an embodiment, the sustainability data may include at least one of compliance specification and sustainability requirement.

[0066] In an embodiment, the at least one data gathering unit 130 may be configured to choose the at least one entity to request the types of data required from. In an embodiment, the at least one data gathering unit 130 may be configured to choose the at least one entity based on the types of data required.

[0067] In an embodiment of the present disclosure, the compatibility scoring system 100 may include at least one data gathering unit 130. In an embodiment, each data of the at least one data gathering unit 130 may be associated with each entity of the at least one entity. In another embodiment, at least one data gathering unit 130 may be used as a central unit, and each entity of the at least one entity may communicate with the at least one data gathering unit 130. In an embodiment, the types of data required 121 may be sent to the at least one data gathering unit 130.

[0068] In an embodiment, the at least one data gathering unit 130 may include a sensing element and/or a database. The at least one data gathering unit 130 may gather data from the sensing element. The at least one data gathering unit 130 may fetch data from the database. The data gathered from the sensing element and/or the data from the database may be referred to as compatibility data 131. In an embodiment, the compatibility data 131 may be sent to the compatibility scoring unit 120.

[0069] In an embodiment, the compatibility scoring unit 120 may receive the compatibility data 131. In an embodiment, the compatibility scoring unit 120 may calculate at least one compatibility score 122. In an embodiment, the compatibility scoring unit 120 may calculate one compatibility score 122 for each entity of the at least one entity. In an embodiment, the compatibility scoring unit 120 may calculate the at least one compatibility score 122 based on the compatibility data 131. In an embodiment, the compatibility score 122 is a score for compability between the requestor and one entity of the at least one entity. [0070] In an embodiment, the compatibility scoring unit may be configured to obtain at least one compatibility score based on a first score of the credibility data with a first weight, a second score of the operationality data with a second weight, and a third score of the sustainability data with a third weight.

[0071] In an embodiment, the first weight, the second weight and the third weight may add up to 1.0 (i.e.,100%). In an embodiment, the first weight, the second weight and the third weight may be predetermined. In another embodiment, the first weight, the second weight and the third weight may be derived from historical data through machine learning.

[0072] In an embodiment, the compatibility scoring unit 120 may be configured to recommend an entity from the at least one entity based on the at least one compatibility score. In an embodiment, the compatibility scoring unit 120 may choose the entity with the highest compatibility score to recommend.

[0073] In an embodiment of the present disclosure, the compatibility scoring compatibility scoring system 100 may include at least one reporting unit 140. In an embodiment, the at least one reporting unit 140 may receive the compatibility score 122 from the compatibility scoring unit 120. In an embodiment, the reporting unit 140 may display the compatibility score 122.

[0074] In an embodiment, the at least one reporting unit 140 may receive details of the recommended entity from the compatibility scoring unit 120. In an embodiment, the reporting unit 140 may display the details of the recommended entity. In an embodiment, the reporting unit 140 may also display details of other entities which may not have the highest compatibility scores.

[0075] In an embodiment, the requestor may choose the recommended entity or a different entity which may have a lower compatibility score than the recommended entity to work with. In an embodiment, even though the compatibility scoring unit 120 may recommend an entity, the requester may decide to choose a different entity instead of the recommended entity as the requestor may feel that a different entity is more suitable. Therefore, although the compatibility scoring compatibility scoring system 100 may recommend an entity, the decision on which entity to choose may lie with the requestor. Advantageously, the requestor might be able to enjoy flexibility in choosing a preferred entity to work with. For example, the recommend entity may have a compatibility score of 90, while another non-recommended entity may have a compatibility score of 88. Even though the compatibility score of the recommended entity is higher, the requestor may not mind a slight difference in the compatibility scores, and may prefer working with the other non-recommend entity. [0076] According to various embodiments, the requestor unit 110, the compatibility scoring unit 120, at least one data gathering unit 130 and/or the at least one reporting unit 140 may be in communication with each other through one or more communication network. Even though FIG. 1 shows lines connecting the requestor unit 110, the compatibility scoring unit 120, at least one data gathering unit 130 and/or the at least one reporting unit 140, the components of the compatibility scoring system 100 may not be physically connected to each other, for example through cables. Instead, the requestor unit 110, the compatibility scoring unit 120, at least one data gathering unit 130 and/or the at least one reporting unit 140 may be able to communicate wirelessly through one or more communication network by internet communication protocols or through a mobile cellular communication network.

[0077] According to various embodiments, the requestor unit 110 may also include an input and/or output module allowing the requestor unit 110 to communicate over the communication network. The requestor unit 110 may also include a user interface for user control of the requestor unit 110. The user interface may include, for example, computing peripheral devices such as display monitors, user input devices, for example, touchscreen devices and computer keyboards.

[0078] In various embodiments, the compatibility scoring unit 120 may be a single unit as illustrated schematically in FIG. 1, or have the functionality performed by the compatibility scoring unit 120 distributed across multiple computing units. The compatibility scoring unit 120 may include one or more computing units. The various functions performed by the compatibility scoring unit 120 may be carried out by the one or more computing units. In some embodiments, the various functions performed by the compatibility scoring unit 120 may be carried out across the one or more computing units. In other embodiments, each specific function of the various functions performed by compatibility scoring unit 120 may be carried out by specific computing units of the one or more computing units. [0079] In an embodiment, the compatibility scoring unit 120 may be a centralized server. In an embodiment, the compatibility scoring unit 120 may be configured to obtain the compatibility data from the at least one data gathering unit. In an embodiment, the compatibility scoring unit 120 may be configured to obtain at least one compatibility score based on the compatibility data. Advantageously, the centralized server may be shared by various requestors and entities, which may reduce the number of computing units required. [0080] In an embodiment, the compatibility scoring unit 120 may be a decentralized server. In an embodiment, the compatibility scoring unit 120 may include a first computing unit of the at least one entity. In an embodiment, the compatibility scoring unit 120 may include a second computing unit of the requestor. In an embodiment, the at least one data gathering unit may be configured to send the compatibility data to the first computing unit. In an embodiment, the first computing unit may be configured to obtain at least one compatibility score based on the compatibility data. The first computing unit may be configured to send the at least one compatibility score to the second computing unit. Advantageously, since only the at least one compatibility score is shared outside of the at least one entity, compatibility data of the at least one entity may be protected and the at least one entity may enjoy a higher level of privacy.

[0081] In an embodiment, the first computing unit may be configured to calculate only the operationality component since the operationality component may depend on the suppliers of a supplier. The first computing unit may be configured to send the operationality component score sent to a second computing unit. The second computing unit may be configured to access to the supplier’s data on credibility and sustainability to calculate the credibility score and the sustainability score. The second computing unit may be configured to finalize an overall compatibility score based on the operationality component score, the credibility score and the sustainability score. [0082] In some embodiments, the compatibility scoring unit 120 may include a memory. The compatibility scoring unit 120 may also include a database. The memory and the database may be one component or may be separate components. The memory of the compatibility scoring unit 120 may include computer executable code defining the functionality that the compatibility scoring unit 120 carries out under control of the one or more computing units. The database and/or memory may include historical data of past compatibilty scores and/or matches. The memory may include or may be a computer program product such as a non- transitory computer-readable medium.

[0083] According to various embodiments, a computer program product may store the computer executable code including instructions for evaluating compatibility between a requestor and at least one entity according to the various embodiments. The computer executable code may be a computer program. The computer program product may be a non- transitory computer-readable medium. The computer program product may be in the compatibility scoring system 100 and/or the compatibility scoring unit 120.

[0084] In some embodiments, the compatibility scoring unit 120 may also include an input and/or output module allowing the compatibility scoring unit 120 to communicate over the communication network. The compatibility scoring unit 120 may also include a user interface for user control of the compatibility scoring unit 120. The user interface may include, for example, computing peripheral devices such as display monitors, user input devices, for example, touchscreen devices and computer keyboards.

[0085] According to various embodiments, the at least one data gathering unit 130 may also include an input and/or output module allowing the at least one data gathering unit 130 to communicate over the communication network. The at least one data gathering unit 130 may also include a user interface for user control of the at least one data gathering unit 130. The user interface may include, for example, computing peripheral devices such as display monitors, user input devices, for example, touchscreen devices and computer keyboards. [0086] In some embodiments, the at least one data gathering unit 130 may include a memory. The at least one data gathering unit 130 may also include a database. The memory and the database may be one component or may be separate components. The memory of the at least one data gathering unit 130 may include computer executable code defining the functionality that the at least one data gathering unit 130 carries out. The database and/or memory may store compatibility data received from the one or more entity. The memory may include or may be a computer program product such as a non-transitory computer-readable medium.

[0087] In an embodiment, the specification 111 may group qualities that may be related to each other. In an embodiment, under each category, a specification item may be indicated by an identifier, for example “Name”, “Type”, “Quantity” and “Unit”. In an embodiment, other specification and/or qualities may be included to indicate requestor- specific requirements, or any other specification that may be relevant.

[0088] In embodiment, a requester may specify a corresponding value for identifier. In an embodiment, in preparing specification 111, a requestor may select one specification item or a combination of specification items based on the requestor’s perceived requirement. Each specification may be composed of items that a requestor may select individually. In an embodiment, the corresponding value of an item may be specified by entering a value or selecting from choices. In an embodiment, the entered value may be single value, or a range of values defined by lower and upper limits, a list or an array of values. It may be numerical, logical, character or string value.

[0089] FIG. 2A illustrates an item specification according to an embodiment of the present disclosure. [0090] In an embodiment, an item specification 210 may be used by a requestor when evaluating or searching a partner that provides a specific item. The item may be a finished part, an assembled product, a physical object, a product, a facility, an office, a location. In an embodiment, a description 211 may provide the identification of an item such as name, type, quantity, and unit. In an embodiment, a physical property 212 may indicate the weight and dimension of an item. In embodiment, a composition 213 may indicate the material composition of an item such as the main material ingredient or the trace materials. In an embodiment, an origin 214 may indicate the origin and/or the transit location of an item. The origin 214 may be specified at various location resolutions such as address, city, and country. In an embodiment, a packaging 215 may specify the material and size of the packaging. In an embodiment, other characteristics 216 may specify any other possible specification that are important to an item.

[0091] FIG. 2B illustrates a process specification according to an embodiment of the present disclosure.

[0092] In an embodiment, a process specification 220 may be used by a requestor when a specific process may be considered as significant with regard to finding an entity. In an embodiment, the process specification 220 may also be used when a process is closely associated to an item. In an embodiment, the process specification 220 may typically be used together with an item specification. For example, when a process is a key factor for a finished item such as item quality, lead time, quantity, cost, among others. In an embodiment, description 211 may provide a description of a process such as name, the associated product name and/or type, and the valid machine name and/or type. For compatibility scoring which involves production processes which may require control of lead time, the process specification 220 may require measurements of lead time 222. The measurements of lead time 222 may be mean, median and/or maximum lead time values. For compatibility scoring in which production capacity is important, process specification 220 may require types of data such as lead time 222, availability 223, yield rate 224, and job count 225. Other specification 226 may specify any other possible specification that are important to a process. [0093] FIG. 2C illustrates a partner specification according to an embodiment of the present disclosure.

[0094] In an embodiment, a partnership specification 230 may be used by a requestor to specify the key attributes of a partner. In an embodiment, the partnership specification 230 may be used when a partner background is deemed to be critical in the partner evaluation or compatibility scoring. In an embodiment, the partnership specification 230 may indicate the status on finance 231 specified by at least one of capital amount, revenue, sales, liability, location 232 specified by country and/or region, partnership 233 with other company, and experience 234 which may be specified by the number of years and/or number of branches. [0095] FIG. 2D illustrates a compliance specification according to an embodiment of the present disclosure.

[0096] In an embodiment, a compliance specification 240 may be used by a requestor to ensure that a partner qualifies to certain standard required by a governing body, an organization, and by the requestor. In an embodiment, the compliance specification 240 may include specifying any compliance requirements such as environmental compliance 241 to certain regulations and standards such as Carbon Trust Standard, Environmental Management Association of Singapore (EMAS) standard, business continuity plans 242, government compliance 243 to certain laws and policies, or to a private regulatory body 244. In an embodiment, these specifications may be specified by a yes or no options with uploaded supporting documents.

[0097] FIG. 3 illustrates types of data required according to an embodiment of the present disclosure. [0098] In an embodiment, the types of data required 121 may be referred to as data requirement 121. In an embodiment, the data requirement 121 may define the data elements to be sent to the at least one data gathering unit 130. In an embodiment, the data requirement 121 may be determined by the compatibility scoring unit 120 in a specified format. In an embodiment, the specified format may be filled out by the at least one data gathering unit, for example, with operation data values. In an embodiment, the data requirement 121 may include credibility 310, operationality 320, and sustainability 330.

[0099] In an embodiment, the credibility 310 may specify the required data elements relating to cash flow, company profile, and peer sentiments. In an embodiemnt, the credibility 310 may include partner specification 230, product portfolio 311, credit score 312 and other data 313. In an embodiment, the partner specification 230 may be initially specified by a requestor as part of specification 111. In an embodiment, the compatibility scoring unit 120 may not be able to verify these specifications yet due to unavailable data. In an embodiment some or all the identifiers in partner specification may have to be gathered as a part of credibility 310. In an embodiment, the credibility 310 may include product portfolio 311. The product portfolio may include a list of items offered by a company. In an embodiment, the credit score 312 may be provided by financial institutions. In an embodiment, the other data 313 may be ratings of companies in same industries or any other suitable data element. [00100] In an embodiment, the operationality 320 may specify the required data elements related to actual operations of producing, and/or providing and/or delivering an item to a requestor. In an embodiment, the item may be but is not limited to a physical object, a product, a facility, an office, a location. The details of the operationality component may include some or all the identifiers of the item specification 210 in FIG. 2A, and/or process specification 220 in FIG. 2B. [00101] In an embodiment, the details of the operationality component may include at least one of production flow 321, material flow 332, supply flow 323 and other related data 324. In an embodiment, a flow may be a defined sequence of at least one of a manufacturing processes, business processes, machine operations, worker tasks, operation procedures, that may be undertaken to complete a process or sub-process may contribute to the completion of rendering service such as delivery of parts or finished good inventory, or to the completion of manufacturing a product or part. In an embodiment, in specifying the operations or processes included in a flow, a list of standard names may be provided as selection to unify and may avoid confusion when defining various flows.

[00102] In an embodiment, a flow may also be provided as templates including ordered process names which may be based on the actual process flow. In an embodiment, a template may be customized by adding or removing processes. In an embodiment, a production flow may mean at least one of a process flow inside a production plant, factory or processing area wherein a product is processed. In an embodiment, a material flow may mean a transfer of a raw or processed material from its origin location to a destination location. In an embodiment, a supply flow may be similar to a material flow. In an embodiment, a supply flow may refer to the transfer of a supply inventory such as part supply from one location to another location. In an embodiment, a location may be one of a storage location (such as shelf, stacking area, warehouse), a processing location (such as machine, production area, production line, and factory location), a distribution location (such as distribution center), or purchasing location (such as shopping area, mall).

[00103] In an embodiment, the sustainability 330 may specify the required data elements related to the requirements from regulating bodies. In an embodiment, the sustainability 330 may include compliance certification 240, sustainability requirement 331, and other requirements 332. In an embodiment, the sustainability 330 may initially specified by a requestor as part of specification 111. In an embodiment, the compatibility scoring unit 120 may not be able to verify this specification yet due to lack of supporting documents. In an embodiment, some or all the identifiers in compliance specification may have to be gathered as a part of sustainability 330. In an embodiment, since the sustainability component score may mainly involves certifications, the sustainability component may require optical character recognition to extract data from documents and/or natural language processing technology (NLP) for analyzing extracted data. In an embodiment, the sustainability component score of an entity will remain the same even when paired with different requestors. [00104] In an embodiment, the data requirement 121 may be transmitted from the compatibility scoring unit 120 to the at least one data gathering unit 130 in one of a template form, in a table or JSON format, via a text file indicated with required fields, or other means of electronic exchange such as API. In an embodiment, after the at least one data gathering unit 130 collects the data, this is sent to the compatibility scoring unit 120 as compatibility data 131. In an embodiment, compatibility data 131 may follow a format indicated in the data requirement 121 with the filled values and information from the gathered data.

[00105] FIG. 4A illustrates examples of compatibility score according to an embodiment of the present disclosure.

[00106] In an embodiment, the score may be defined by at least one of the requestor 410, requestor type 420, partner 430, partner type 440, score component 450, weight 460 or value 470. In an embodiment, the requestor 410 may indicate the company name, and the requestor type 420 may define the role of the requestor as either a sourcing entity or a supplier. In an embodiment, the partner 430 may indicate the name of a company that is evaluated as a partner or is found to be a potential partner. In an embodiment, the partner type 440 may be defined as a sourcing or a supplier. In an embodiment, the component 450 may identify the compatibility score components. In an embodiment, a compatibility score may include credibility, operationality and sustainability. In an embodiment, the score components may be summarized to a single value as overall score.

[00107] In an embodiment, the value 470 indicates a compatibility score between a requestor and a partner. The compatibility score is a measure of how compatible a requestor is with a partner. In an embodiment, the compatibility scoring unit may be configured to obtain the compatibility score based on a first score of the credibility data with a first weight, a second score of the operationality data with a second weight, and a third score of the sustainability data with a third weight.

[00108] In an embodiment, the first weight, the second weight and the third weight are predetermined or are derived from historical data through machine learning.

[00109] In an embodiment, the overall score may be calculated as the sum of the weighted values of score components. In an embodiment, the weighted values may be calculated by multiplying the values of components in 470 (except for that of Overall component) with their associated weight values in percentage in 460. In an embodiment, the score value and its components values may range from 0 to 100 as described in 470.

[00110] For example, the credibility component may be given a weight of 30%, the operationality component may be given a weight of 40%, and the sustainability component may be given a weight of 30%. The total weight for the component score may be 100%. [00111] FIG. 4B illustrates a scale for interpreting the compatibility score according to an embodiment of the present disclosure.

[00112] FIG. 4B illustrates the scale for interpreting the compatibility score with 0 as the minimum value, which may mean high risk, and 100 as the maximum value, which may correspond to being low risk. In an embodiment, the range of values may be associated with certain risks to define the compatibility of two entities. In an embodiment, a value from 0 to less than 50 (i.e., 0 <= value <50) may be recognized as poor compatibility 482. In an embodiment, a value from 50 to less than 80 (i.e., 50 <= value <80) may be recognized as fair compatibility 483. In an embodiment, a value from 80 to 100 (i.e., 80 <= value<=100) may be recognized as good compatibility 484. In an embodiment, this scale may be similar to that of the business credit score by Equifax, Experian, Dun and Bradstreet and FICO, wherein a low score value is said to be high risk and a large value as being low risk. In an embodiment, the difference is that compatibility score may be a measurement that is relative to a a requestor and a partner, and may change for different requestor-partner pairs.

[00113] FIG. 5 illustrates a compatibility scoring system according to an embodiment of the present disclosure.

[00114] In FIG. 5, the compatibility scoring system 100 may be used by a requestor 510, a service provider 520 (e.g., a logistics service provider), a supplier 530 (e.g., a part supplier), and another supplier 540 (e.g., a material supplier). In an embodiment, the simplest system architecture may include only one requestor 510 and the compatibility scoring system 100. In an embodiment, the requestor 510 may send specification 111 via the requestor unit 110. In an embodiment, the system 100 may calculate the compatibility score, assuming that all the required data are available in the system, and may send the compatibility score 122 via the reporting unit 140. In an embodiment, the system 100 may be utilized by more than one supplier, and by more than one service provider.

[00115] In an embodiment, since the data may not be available locally in one of the data bases of the system, the system may need to send data requirement 121 to the gathering unit 130. In an embodiment, the at least one data gathering unit 130 may be deployed locally to the service provider 520, the supplier 530, and the other supplier 540 in order to gather compatibility data 122. In an embodiment, the at least one data gathering unit 130 may be a physical sensor or sensing element that may be attached to a machine to gather operation data such as the processing time for a specific item, the quality evaluation of an item (e.g., passed or failed), the job size or the number of jobs currently processed, and the machine status (e.g., idle, broken, working). In an embodiment, the at least one data gathering unit 130 may be a software agent that interfaces with MES and/or SCADA systems and/or database systems to collect data based on the data requirement.

[00116] In an embodiment, as shown in FIG. 5, the data requirement may be determined based on the type of service providers as indicated by 551.1, 551.2 and 551.3. In an embodiment, the data requirement may change as entities provides different services or products. In an embodiment, for example, for a logistics service provider, it provides delivery, warehousing, and packaging services, therefore the data requirement may be related to these services. In an embodiment, as another example, part suppliers may manufacture specific parts and thus the data requirement may be related to the production.

[00117] In an embodiment, the data requirement 551.1 may be associated to a supply flow 323. In an embodiment, the data requirement 551.1 may include the transfer of a part supply from the location of part supplier 530 to an assembly factory of a requestor (if the requestor is a sourcing company in FIG. 5). In an embodiment, the logistics service provider 520 may provide the locations of pick-up location, transit location and destination locations as well as the log times (e.g., time in and time out) at these locations since it may handle the delivery of the part supply.

[00118] In an embodiment, the data requirement 551.2 may be associated to the part supplier 530 which may require information about the production flow 321, which may indicate the process flow and information in producing parts.

[00119] In an embodiment, the data requirement 551.3 may be associated to a material supplier 540 which may require information about material flow 322. In an embodiment, the data requirement 551.3 may include the information about the transfer of the material from the material supplier 540 to part supplier 530, which may be a case when 540 handles the delivery operation. In an embodiment, if the delivery may be outsourced to a trucking company, then this company may be provide the material flow. In an embodiment, the material supplier may provide the production flow, for example, if a raw material is processed prior to the delivery.

[00120] FIG. 6 illustrates a compatibility scoring centralized architecture according to an embodiment of the present disclosure.

[00121] FIG. 6 provides a detailed description of interactions 600 between a scoring system 100, a requestor 510, a provider 520 and a supplier 540. In an embodiment, the calculation of compatibility score may be centralized at one server for the scoring system 100 such that all the compatibility data may be sent towards the central server. In this embodiment, the requestor 510 may be a part manufacturer of a certain product that may expect to receive materials from the supplier 540 and the delivery from the material supplier to the part manufacturer may be provided by the provider 520.

[00122] In an embodiment, the process of compatibility evaluation (e.g., supplier evaluation) may be started by sending specification in step 611 from requestor 510 to system 100. In an embodiment, the system 100 may receive the specification 612 and may processes it to determine the data requirement (e.g. data related to operation) in step 613. In an embodiment, the system 100 may request in step 614 the details to identify supplier/s (e.g., the supplier 540) and provider/s (e.g., the provider 520) in an inquiry 615. The inquiry 615 may include details such as the name, type of business, among others from the requestor 510 by sending a request to provide the details in the inquiry 615. In an embodiment, the inquiry 615 may include the data requirement for the requestor 510. In an embodiment, the requestor 510 may respond to the inquiry 615 by sending supplier and provider details 617 after confirming that the provider 520 and the supplier 540 are available or agreeable to provide the details and that requestor 510 can comply to the data requirement. [00123] In an embodiment, after the system 100 receives the supplier and provider details 617, it may send notification 619 to the provider 520 and send notification 620 to the supplier 540 to confirm their involvement in the evaluation requested by the requestor 510. In an embodiment, notification 619 and notification 620 may include the data requirements for the provider 520 and the supplier 540, respectively. In an embodiment, upon receiving the separate notifications, the provider 520 and the supplier 540 may confirm to the system 100 by sending confirmations 622 and 624, respectively. In an embodiment, assuming that both the provider 520 and the supplier 540 have affirmative confirmations, the system 100 in step 625 may send the initiation signals 626, 627, and 628 to start the collection of data to the requestor 510, the provider 520 and the supplier 540 respectively. The requestor 510, the provider 520 and the supplier 540 may send operation data and other information in steps 629, 631 and 633, respectively.

[00124] In an embodiment, after this stage, the system 100 may receive compatibility datas 630, 632, 634 from the requestor 510, the provider 520 and the supplier 540 according to the data requirements. In an embodiment, the transmission of compatibility datas 630, 632, 634 may be asynchronous. The duration period and sampling rate of data gathering may be dependent on specific process. In an embodiment, the transmittal of compatibility datas 630, 632, 634 may be conducted in several ways, through API between systems, through devices that function as data gathering unit, or through manual uploading of data.

[00125] In an embodiment, after receiving the data in step 635, the scoring system 100 may evaluate the compatibility score(s) 636. The compatibility score(s) 636 may include a credibility score, an operationality score and a sustainability score. In an embodiment, the compatibility score(s) 636 may be sent in step 637 to the requestor 510. It may include an overall score as well as component values. [00126] FIG. 7 illustrates a decentralized architecture of compatibility scoring according to an embodiment of the present disclosure.

[00127] FIG. 7 provides another interaction 700 between scoring system 100, a requestor 510, a provider 520 and a supplier 540. In an embodiment, the calculation of compatibility score may be decentralized at various servers in order that the compatibility data may be stored at separate servers and the calculation of a compatibility score may be made locally at same network of the data gathering unit and/or database containing compatibility data. In an embodiment, the process from steps 711 to 713 may follow the same interaction as that of FIG. 6. In an embodiment, in step 714, the system 100 after calculating the data requirement, may request for compatibility evaluation to the requestor 510 by sending evaluation request 715. In an embodiment, the evaluation request 715 may include the data requirement for the requestor 510. In an embodiment, upon receiving the evaluation request 715 in step 716, the requestor 510 may send a confirmation 717 to the system 100 to signify that it has agreed to evaluate compatibility score. In an embodiment, the evaluation may be facilitated by the requestor 510. In an embodiment, the requestor 510 may send request for score evaluation to the provider 520 and the supplier 540 in step 718 by sending evaluation requests 719 and 720, respectively. In an embodiment, these evaluation requests 719 and 720 may include the individual data requirements for the provider 520 and the supplier 540, respectively. In an embodiment, upon receiving the separate notifications, the provider 520 and the supplier 540 may send to the requestor 510 confirmations 722 and 724 in steps 721 and 723, respectively. In an embodiment, assuming that both the provider 520 and the supplier 540 have affirmative confirmations, the requestor 510 may send the initiation signal 725 to start the collection by sending initiation signals 726 and 727 to the provider 520 and the supplier 540, respectively. In an embodiment, according to the data requirements, the provider 520 and the supplier 540 may send the compatibility data 729 and 730, respectively. In an embodiment, the transmission of the compatibility data 729 and 730 may be asynchronous. The duration period and sampling rate for data gathering may be dependent on specific process or operation. In an embodiment, after receiving the compatibility data 729 and 730 in step 732, the requestor 510 may evaluate score component values 732. In an embodiment, in step 733, the score components evaluations which may include the operationality component 734 may be sent to the system 100. In an embodiment, in step 735, the value may be received, and the score may be finalized. In an embodiment, in finalizing the score, it may include the calculation of other component scores such as the credibility and sustainability scores, as well as the application of the weight values of each component. In an embodiment, in step 736, the overall component scores 737 may be sent from the system 100 to the requestor 510.

[00128] FIG. 8 illustrates a requestor unit according to an embodiment of the present disclosure.

[00129] In an embodiment, the requestor unit 110 exemplified in FIG. 8 may provide an interface for a requestor to enter values for input specification 111, and may transmit it electronically to scoring unit 120. In an embodiment, the requestor unit 110 may allow a requestor to customize locally the details of input specification based on requestor’s needs by managing, updating and storing the details of specification in a requestor database 860. Once the details is inputted by the requestor, the requestor unit 110 may use the details inputted by the requestor in the future without the requestor needing to input the details again. In an embodiment, if a requestor has different or updated requirements, the requestor unit 110 may allow the requestor to update or change the previous details.

[00130] In an embodiment, the item specification input 810 may allow a requestor to select details and input values of item specification. In an embodiment, the selections may be the item details provided in FIG. 2A. In an embodiment, in providing selections such as item type, material composition, the selections may be managed, stored and updated in item data 861. In an embodiment, the item specification input 810 may provide an interface to update the list of details for item specification of a requestor.

[00131] In an embodiment, the process specification input 820 may provide the input interface to input values of process specification based on the details stated in FIG. 2B. In an embodiment, the details of process specification may be stored in process data 862.

[00132] In an embodiment, the partner specification input 830 may provide an interface for a requestor to specify the characteristics of partner based on the details stated in FIG. 2C. In an embodiment, the selections and values may be stored locally in partner data 863. In an embodiment, a requestor may select a partner for compatibility scoring based on the list of current suppliers or sourcing companies that may be stored in company data 863. In an embodiment, the compliance specification input 840 may provide an interface for a user to specify the compliance measures that may be associated with the selections made in either item specification input, process specification input, or partner specification input.

[00133] In an embodiment, the statistical computing 850 may be a computational unit that may provide analysis of certain numerical and logical values associated to particular specifications. In an embodiment, the statistical computing 850 may calculate statistical values such as minimum, median, mean, range, maximum, mode in order to provide guided information to a requestor when selecting a value. In an embodiment, the statistical computing 850 may also provide information about previous evaluations by providing graphs and charts of data from compatibility score 865 based on the selected specifications of item, process, partner, and compliance.

[00134] FIG. 9 illustrates a compatibility scoring unit according to an embodiment of the present disclosure.

[00135] In an embodiment, the compatibility scoring unit 120 which may be exemplified in FIG. 9, may include data requirement determination 910, score evaluation 920, device management 930, and data storages for data requirements and specifications 940, company data 950, compatibility scores 960, and device mapping 970. In an embodiment, the data requirement determination 910 may analyze the specification 111, may determine which of the data are required, may evaluate the data size required for calculating score evaluation, and may determine if this data is available. In an embodiment, if it is found to be not available or that the data size is not sufficient, at least one data gathering unit 130 may be determined and may sent a request to gather and transmit the required data. In an embodiment, the evaluated data requirement may be sent to at least one data gathering unit 130. In an embodiment, it may be stored in data requirement together with specification 111 in the specifications 940. [00136] In an embodiment, the score evaluation 920 may analyze the compatibility data received from at least one data gathering unit 130 and may calculate the values of score components and overall values.

[00137] In an embodiment, the device management 930 may provide a set of management functions for maintaining a network of data gathering units. In an embodiment, it may allow enlistment of devices as data gathering units by automatic and manual means, as well as deletion and blocking of certain devices. In an embodiment, it may allow a user to configure by manual means, or a device to provide by automatic means, device identifications such as device model, MAC address, IP network address, as well as to tag or associate a device to related specifications such as flow type, process, item name, among others.

[00138] In an embodiment, the data requirements and specifications database 940 may store the specifications and data requirements of previous evaluations conducted by block 910. In an embodiment, the term “block” may include a processor or a controller for performing specified actions. For example, block 910 may be used for data requirement determination, block 920 may be used for score evaluation and block 930 may be used for device (e.g., the compatibility scoring unit) management. In an embodiment, these data may be retrieved as reference in future evaluations. In an embodiment, if specification 111 is found to be similar to previous specification, the previous data requirements may be retrieved from the database 940. In an embodiment, this retrieved data may be taken into consideration in block 910 in determining the data requirement. In an embodiment, the compatibility scoring unit 120 may use the previous data requirements may be retrieved from the database 940 to determine the compatibility score.

[00139] In an embodiment, the company data 950 may include information of companies which may be identified by name, as a requestor or partner, as a supplier or a sourcing company and other profile items stated in FIG. 2C. In an embodiment, the company data 950 together with compatibility scores 960 may be used by block 920 to calculate score evaluation.

[00140] In an embodiment, when initially there were no previous evaluations to determine data requirements and to calculate compatibility scores, all or at least some of the information listed in FIG. 3 may be collected. In an embodiment, collecting the data from data gathering units for many score evaluations may be impractical considering potentially large requirement for computational resources. In an embodiment, it may be possible that rule-based or heuristic methods may be applied to facilitate the determination of required data. In an embodiment, an if-then rules may be crafted based on experience so that if a certain item is stated in specification 111, then a corresponding data requirement may be specified. In an embodiment, the data requirement may be a single data requirement or a set of data requirements. In an embodiment, data may be collected to build a large database of data requirements and specifications 940. In an embodiment, as the number of evaluations for data requirement determination and compatibility scoring increases, the data size in data requirements and specifications 940, company data 950, compatibility scores 960 may subsequently grow which may become suited for conducting statistical analysis and other methods to determine data requirements.

[00141] In an embodiment, assuming that a large amount of data is stored in the specifications 940, company data 950, compatibility scores 960, the data requirement is determined by analyzing these stored data along with specification 111. In an embodiment, it may be determined by conducting statistical data analysis to ascertain the types of data that have high correlations or impact to the values of compatibility component and overall score, by applying rule-based systems to select the types of data required, and by applying graph theory or discrete event simulation to determine, for instance, bottleneck processes in material, supply and production flows.

[00142] In an embodiment, the credibility component may utilize item specification 210 and partner specification 230 along with credit score and other types of data as shown in FIG. 3. In an embodiment, depending on item specification 210 (e.g., item type in description 211), the credibility component or compatibility score may be determined by conducting statistical analysis from the accumulation of previous evaluations. In an embodiment, as a result of the analysis, some data elements in partner specification 220 or product portfolio 311 may be found to be not correlated to the value of credibility component or compatibility score. In an embodiment, the analysis may be conducted through exploratory factor analysis, principal component analysis, structural equation modelling. In an embodiment, in this type of analysis, the data elements in specification 111 and data requirement 121 may be the independent parameters and the credibility component value or compatibility score may be the dependent parameter. In an embodiment, when evaluating component score, a similar analysis may be made to determine if credit score must be given higher weight values than other factors. For example, if the requestor does not wish to work with suppliers with credit problems or with potential credit problems such suppliers with a large debt to earning ratio, the requestor may give the credit score a higher weight value. In an embodiment, requestors of small company sizes may be more wary of working with suppliers with credit problems as the risk of the suppliers not fulfilling the requirements due to credit problems may be higher.

[00143] In an embodiment, in determining required data for operationality component 320, it may employ graph analysis and graph theory. In an embodiment, the graph may be represented by nodes which may correspond to the operations of material flow, production flow, or supply flow. In an embodiment, any two nodes which correspond to consecutive operations may be connected by a line that is directional and weighted by at least one numerical value. In an embodiment, this value may correspond to some performance index such as lead time, yield rate, manufacturing capacity, throughput, work-in-progress volume, or a combination of KPIs. In an embodiment, a bottleneck analysis may be conducted to determine processes or process sequence with large delay, high defect rate, low manufacturing capacity, large build-up of volume. In an embodiment, it may be possible that only the data of bottleneck processes, or a set of processes which may be associated to a key production line may be gathered to avoid the sizeable amount of data coming from all operations. In an embodiment, requestors of large company sizes may put a stronger weight value on the operationality as reliable and stable operationality may be an important factor to them.

[00144] FIG. 10A shows a flow chart of determining data requirement according to an embodiment of the present disclosure.

[00145] FIG. 10A exemplifies a data requirement determination 910. In an embodiment, upon receiving specification 111, the scoring unit 120 may determine a requestor name, item name process name and partner name in step 1010. In an embodiment, it may retrieve additional information of partner from company data 950. In an embodiment, it may search database 940 for previous evaluation of data requirements that have same or similar specification. In an embodiment, this previously evaluated data requirement may serve as a template. In an embodiment, in step 1020, if it is found to be that no template exists then it may conduct analysis such as statistical analysis, graphical analysis, among others to determine data requirement. In an embodiment, the template may be used to request the types of data required. In an embodiment, in step 1030, the properties of data gathering units associated to data requirements may be configured beforehand through device management 930 or may be retrieved from device mapping 970. In an embodiment, it may include the IP address, sampling rate, operation time schedule of sensing device. In an embodiment, it may be possible that a data gathering unit may be a server that may send periodically operation data. In an embodiment, based on these properties, a required data sampling period may be calculated. In an embodiment, the amount of data size may be pre-determined, and may be sufficient enough to conduct and verify measurements such as mean values for lead time, defect rates, among others. In an embodiment, in step 1040, the evaluated data requirement may be sent to corresponding data gathering units. In an embodiment, the calculated data requirement and corresponding specification may be used to update the database 940. In an embodiment, the evaluation may be displayed on a reporting unit 140 for a requestor to confirm and to allow modifications.

[00146] FIG. 10B exemplifies a model to represent the objects for item, entity, and flow according to an embodiment of the present disclosure.

[00147] FIG. 10B exemplifies a model to represent the objects for item, entity, and flow. In an embodiment, the A circle such as 1050, 1051, 1054 and 1056 may represent an entity, or a set of entities, which may be a private person, a company, a sourcing individual or company, a supplier individual or a company, a group of companies. In an embodiment, the flow may be a sequence of processes that operates on an item. In an embodiment, the item may be a physical object, a product, a facility, an office, or a location. [00148] In an embodiment, there may be several types of flows such as production flow, material flow, supply flow, but these names may be relative to the viewpoint of an entity. In an embodiment, a supplier may be a part supplier or a material supplier or other supplier. In an embodiment, the curved line inside a bounding box such as 1051 may represent a production flow wherein entity 1050 delivers an item and hands it overy to 1052 for processing by following production flow 1051. In an embodiment, a dotted line such as 1053 may be a material or supply flow which may represents a delivery flow wherein an entity 1054 picks up the item from entity 1052, and delivers it to entity 1056. In an embodiment, the touch point of entity 1050 and 1051 may represent the start process of process flow 1051 while the touch point of entity 1052 and production flow 1051 may represent the completion of last process of 1051. In an embodiment, the item may proceed to flow 1053 and may be handled by entity 1054. In an embodiment, this representation may be used in evaluating operationality component. In an embodiment, it may be the basis to define the object model representation for entity, item and flow types, or to create the object model diagram, for object oriented programming languages such as Java, C++ C#, among others.

[00149] FIG. IOC exemplifies a model including a requestor according to an embodiment of the present disclosure.

[00150] In an embodiment, the model may consist of a requestor, which may be a supplier 1070 and its corresponding flows such as production flow 1069, supply flow 1067, production flow 1065, supply flow 1063, production flow 1061 wherein the entities may consist of multiple layers of suppliers such as 1062, and 1066. In an embodiment, while the figure shows only single path flow from 1060 to 1070, it should be recognized that multiple paths are possible. In an embodiment, the above representation may be extended to represent these paths. [00151] FIG. 11 shows a flow chart 1100 of evaluating compatibility score according to an embodiment of the present disclosure.

[00152] In FIG. 11 thes compatibility score evaluation 920 may be conducted such that score components are individually calculated, and may be scaled from 0 to 100 and may be aggregated into an overall score. In an embodiment, in step 1110, the credibility component 310 may be evaluated by analyzing the data of partner specification 230 such as capital, revenue, and number of years, as well as product portfolio 311, credit score 312 and other related data 313. In an embodiment, in step 1120, operationality component may be evaluated by analyzing the data gathered in operationality 320 such as item specification 210, process specification 220, production flow 321, material flow 322, supply flow 323 and other related data 324. In an embodiment, in step 1130, sustainability component may be evaluated by checking submitted documents on compliance and sustainability with respect to the data relating to compliance specification 240, sustainability requirement 331 and other requirements 332. In an embodiment, in calculating the overall compatibility score, it may require weight values for each component as shown below:

[00153] Overall = wl*Credibility + w2 * Operationality + w3*Sustainability such that wl+w2+w3=100%.

[00154] In an embodiment, the values of weights (wl, w2, w3) may be defined by a requestor or may be determined by considering the characteristics of industry such as lead time and production volume. In an embodiment, some industries may have short lead time and high production volume such that operationality component may be weighted higher than other components to ensure that a selected partner has capability of producing and delivering products with no or minimal delay. In an embodiment, the weight values may be changed according to the type of items such as commodity, luxury and high-precision products. In an embodiment, credibility component in a commodity product may not be as high as that of luxury or high-precision products. In an embodiment, these weights may be statistically determined based on company profile, industry, business type, among others. In an embodiment, the values may be determined by Machine Learning methods by way of analyzing the previous compatibility evaluations in compatibility scores 960, determining patterns in weight values by item, partner, component score values, and considering successful cases of partnering or partnership of supplier and sourcing entities in 1140. [00155] FIG. 12 illustrates a reporting unit according to an embodiment of the present disclosure.

[00156] FIG. 12 exemplifies reporting unit 130. In an embodiment, the reporting unit 130 may provide an interface to display graphical plots, charts and diagrams to display flows, supplier network, or supplier levels through data flow visualizer 1210, and may display the result of compatibility score evaluation through compatibility score display 1220. In an embodiment, the reporting unit 130 may compare several compatibility score evaluations that may be conducted by a requestor through plots, graphs and tables as provided by score variation plotter 1230. In an embodiment, in providing a detailed report of compatibility score, support tables may be provided for interpretation through Support tables 1240. In an embodiment, the selection menus 1250 may provide a user interface to navigate through the reporting unit interactively. In an embodiment, the reporting unit may provide an interface to select and view previous compatibility evaluations in a form of drop-down boxes, radio buttons, among others. In an embodiment, the editor and modifier 160 may allow for customization of reports by selecting only few graphs and tables, and changing graph type. [00157] FIG. 13 illustrates a compatibility scoring unit according to an embodiment of the present disclosure.

[00158] In an embodiment, the compatibility scoring unit 120 may be configured to retrieve stored data of previous compatibility matches, wherein the previous compatibility matches have similar types of data as the types of data required by the compatibility scoring unit, and wherein the compatibility scoring unit is configured to obtain the at least one compatibility score based on the stored data of the previous compatibility matches. Further details will be described in the example of FIG. 13.

[00159] In FIG. 13, the compatibility scoring unit 120 may evaluate a partner by using only limited information as a result of the evaluation of compatibility matching 1310 and may utilize the stored data from compatibility matches 1320. The stored data from the compatibility matches 1320 may include previous compatibility matches and associated partner requirements and component details. In an embodiment, a supplier and a sourcing company may be evaluated by analyzing similarity in the company profiles, and specification 111. In an embodiment, by using previous compatibility matches, the compatibility scoring unit 120 may be able to provide a more accurate compatibility matches for current/future matches.

[00160] In an embodiment, the compatibility matching 1310 may extract the company profiles of a requestor and a partner, may search the compatibility matches 1320 for supplier and sourcing companies with similar profiles to that of the requestor and partner, may analyze compatibility score components of the previous matches and estimates the compatibility score. In an embodiment, the compatibility matching 1320 may consider specific data in item specifications such as item type in the analysis in order to evaluate a particular item from a set of items such as a product from a product line.

[00161] FIG. 14 illustrates examples of compatibility matches according to an embodiment of the present disclosure.

[00162] In an embodiment, the compatibility matches 1320 exemplified in FIG. 14 may include a data storage, which may be a collection of data from collaborating companies of known compatibility scores, component score details, and partner requirements. ID 1411 may be an identifier of previous compatibility matching. In an embodiment, the requestor profile 1412 may refer to a set of variables about a requestor company (e.g., name, type, size, industry as indicated in Company data 960) which may include specifications (e.g., item specification, process specification, compliance specification) and their values. In an embodiment, the partner profile 1413 may refer to the partner profile which may refer to a set of variables about the partners company including specifications and their values. In an embodiment, the parameters 1414, 1415, 1416 may refer to the credibility, operationality and sustainability score components, respectively. The credibility score component may be score components of credibility data which may include at least one of partner specification, product portfolio, and credit score. The operationality score component may be score components of operationality data which may include at least one of product specification, process specification, production flow, material flow and supply flow. The sustainability score component may be score components of the sustainability data which may include at least one of compliance specification and sustainability requirement.

[00163] In an embodiment, the success index 1417 may refer to a parameter that denotes if the compatibility matching is successful or not. In an embodiment, it may be defined by a Boolean value referring TRUE as a successful matching, FALSE if otherwise.

[00164] In an embodiment, it may be expressed as a peer rating (e.g., from 0 to 100), active or not, time length (e.g., number of years of partnership). In an embodiment, it may also be expressed by various success levels (e.g., not successful, fair, good, excellent), which may be based on trusted review, expert’s view, peer perception, among others. In an embodiment, the data from 1411 to 1416 may be automatically collected after the system performs score evaluation in 920. In an embodiment, the success index 1417 may be collected at a later stage by conducting a verification through Internet search, interview or survey on whether the two companies (a requestor and a partner) have had successful partnership, or supplier- sourcing relationship.

[00165] In an embodiment, the sustainability score 1416 of a supplier (i.e., partner) may not change when paired with different requestors. For example, in ID1, when requestor is Company 1 and the partner is Company2, the sustainability score is 70. In ID3, when requestor is Company4 and the partner is Company2, the sustainability score is still 70. Since sustainability score is generally obtain based on government requirements and/or compliance requirements, the sustainability score will remain the same even when paired with different requestors.

[00166] FIG. 15 shows a flow chart of compatibility matching according to an embodiment of the present disclosure.

[00167] FIG. 15 exemplifies compatibility matching 1310. In an embodiment, the compatibility matching 130 may receive the data requirement (i.e., current requirement) in stepl510. In an embodiment, it may receive the profile of the requestor and/or partner which may be derived from specification 111. In an embodiment, the company profile details may be retrieved from company data 950 since specification 111 may only contain company name. In an embodiment, the previous data requirements in 940 may be evaluated and may be compared to the current requirement. In an embodiment, the previous requirements with high similarity to the current requirement may be selected and may be processed later.

[00168] In an embodiment, in steps 1520 and 1530, a similarity value may be calculated to evaluate the similarity. In an embodiment, it may be performed by processing the specification 111 and comparing it to the data from previous specifications in 940. In an embodiment, for specifications with non-numerical values such as item type (e.g., product type), main material and trace material, country of origin, process type, machine type, the previous data may be filtered to find exact matches of this type. In an embodiment, after selecting the data with exact matches, the specifications with numerical values such as item dimension, lead time, availability, and yield rate may be evaluated. In an embodiment, the evaluation may be made by defining a deviation value, which may be used as a basis to calculate minimum (numerical value of current specification minus the deviation value) and maximum limit values (numerical value of current specification plus the deviation value). In an embodiment, these limits may be used to filter the previous data with values that are within the calculated limits.

[00169] In an embodiment, the similarity may be evaluated by applying distance functions such as Euclidean distance. In an embodiment, suppose there are M number of previous data requirements and for each requirement, there are N number of items in specifications with numerical values. A distance value may be determined by calculating a variance value between previous and current specifications. In an embodiment, the previous specification with the least distance value may have the most similarity to the current specification. [00170] In an embodiment, another way of finding similarity may be to perform clustering analysis by applying clustering algorithms such as K-means, and support vector classifiers. [00171] In an embodiment, after determining the similar previous data requirements, the corresponding item profile(s) (e.g., the company) may be determined in step 1540. The corresponding item profile(s) may include an item profile or may include a set of item profiles. In an embodiment, the compatibility matches of these entities (e.g., companies) may be retrieved from the compatibility matches 1320.

[00172] In an embodiment, the compatibility component such as credibility, operationality and sustainability components may be estimated in step 1550. In an embodiment, each component may be derived mathematically, for example by calculating the mean or mode of the values in the compatibility matches. In an embodiment, the outlier values (exceedingly high or low values) may not be included in the calculation. [00173] In an embodiment, in step 1560, the weight values may be determined by analyzing the patterns in the weight values and the component scores of the retrieved values. In an embodiment, it may be determined by finding a prediction function f(). In an embodiment, from retrieved values, a function may be denoted as cw= f(cs) such that cw may denote a weight value of credibility component and cs denotes a credibility component value. In an embodiment, the function f(cs) may be calculated through curve fitting, or by fitting a function of known form to cs values, and estimating the resulting cw values. In an embodiment, it may be a linear, exponential, or other mathematical expressions depending on the distribution of cs values. In an embodiment, after finding the prediction function, the weight value for the credibility component may be calculated by evaluating f(cs=ccal), where ccal may be the value of the calculated credibility component in 1550. In an embodiment, the similar processes may be applied to calculate the weight values of operationality and sustainability components.

[00174] In an embodiment, a compatibility score may be evaluated in step 1570 by processing the weight values and the calculated component scores (e.g., using eq. 1). In an embodiment, the weight values may be scaled to ensure that the sum of weights values are equal to 100%. In an embodiment, all component scores may also be scaled so that the values may be bounded by 0 and 100.

[00175] In an embodiment, in step 1530, the similarity may be decided by a threshold value SimilarityThreshold which may be pre-selected, manually or automatically adjusted. In an embodiment, it may be possible that there are no similar data that may be found. In an embodiment, as shown in step 1580, the compatibility matching may proceed as normal score evaluation by requesting compatibility data. In an embodiment, the scoring unit may prompt in the reporting unit that compatibility matching is not feasible due to absence of similar data. [00176] FIG. 16A illustrates an exemplary interface of a compatibility scoring unit according to an embodiment of the present disclosure.

[00177] FIG. 16A is an example of requestor unit 110. In an embodiment, the Button 1610 may provide an interface to view and edit the requestor profile. In an embodiment, the Button 1620 may provide an interface to set the specification 111 and may invoke request to evaluate partner. In an embodiment, the Button 1630 may provide an interface to review previous evaluations.

[00178] FIG. 16B illustrates an exemplary interface of a requestor profile according to an embodiment of the present disclosure.

[00179] FIG. 16B is an example of the interface to view requestor profile 1610. In an embodiment, the requestor profile 1610 may allow modification of the requestor name in 1611, company type as either sourcing or supplier entity om 1612, setting of the industry category 1613, and the industry sector, 1614. In an embodiment, the save button 1615 may allow the changes to be stored locally in the requestor unit and may be sent to the compatibility scoring unit 120 for storage in 950.

[00180] FIG. 16C illustrates an exemplary interface to set a specification according to an embodiment of the present disclosure.

[00181] FIG.16C is an example of the interface to set the specification 111, which also exemplifies the interface for item specification 810, process specification 820, and partner specification 830. In an embodiment, the item specification 1621 may include the item name and item type. In an embodiment, the partner specification 1622 may include at least of one of the partner type and supporting details such as capital, credit score, and country or region. In an embodiment, the process specification may at least consist of functions to add process 1623 and add details of each process 1624. In an embodiment, the function to add processes may include at least one of the process sequence and process name which may be typed in or selected from a drop-down dialog. In an embodiment, in defining the process details in 1624, the parameters may depend on the item type. In an embodiment, for an item type that is an electronics part, the process details may require data about lead time, reject or defect rate, and availability. In an embodiment, the changes in process list 1634 and process details 1624 may be saved through button 1625. In an embodiment, these specifications may be sent out to 120 by pressing button 1626, which may subsequently initiate the search for finding partner. In an embodiment, if the purpose is to evaluate compatibility with a partner, then a part of the partner specification in 1622 may be selecting specific partner name instead of specifying partner type and/or region.

[00182] FIG. 16D illustrates an exemplary interface to view previous evaluation or to view history according to an embodiment of the present disclosure.

[00183] FIG. 16D shows an example of interface to view previous evaluation or view history after pressing Button 1630. In an embodiment, it may also constitute as the part of the evaluation result of the function 850. In an embodiment, by selecting a partner name in 1631 (e.g., Part Manufacturer 1) and/or item name in 1632, historical details of previous evaluation may be shown in charts 1633 and 1634. In an embodiment, the chart 1633 may provide a timeline of compatibility score from the past years up to the current year. In an embodiment, the compatibility score in this example is increasing despite the varying changes in compatibility component values. In an embodiment, the operationality component may improve from 60 to 90 over the 4-year span, while the credibility component (which is mainly based on financial status) may decrease from 70 to 40. In an embodiment, this decline in the credibility component may be associated to generally poor market conditions for part manufacturers, or having several competitors. In an embodiment, the steady increase in the compatibility score may be due to setting higher values on the weight for operationality component (e.g., 0.5) than that of the credibility component (e.g., 0.2). In an embodiment, if the evaluation is based only on financial status, Part Manufacturer 1 may be considered as having “poor” status based on the scale in 400B. With the consideration of operationality component, the resulting evaluation may be kept as “fair”. In an embodiment the calculated result in this example may be based on fixed weight values applied for each year. In an embodiment, the weight values may need to be adjusted on regular basis.

[00184] In an embodiment, the chart 1634 is an example of company comparison assuming that a requestor is considering multiple partners. In an embodiment, these potential or existing partners may be compared by compatibility components and overall score, to determine their individual strength.

[00185] FIG. 17 illustrates an exemplary interface of a report from a reporting unit according to an embodiment of the present disclosure.

[00186] FIG. 17 exemplifies a reporting unit 130 by providing a report of compatibility scores. In an embodiment, the Overall Score pane 1710 may provide compatibility score 1711 along with Chart 1712, and the Component Scores pane 1720 may provide the component scores 1721, 1722, and 1723 along with the corresponding Charts 1724, 1725, and 1726.. In an embodiment, the plot of comparative scores 1712 may be shown by providing other scores such as an average of compatibility scores stored in 960 that may belong to same or similar specification 111. In an embodiment, the reference score 1712 may be provided with the best in class score to show the highest compatibility score. In an embodiment, these comparative scores may be calculated by scoring unit 120 without mentioning specific names of other companies. In an embodiment, this comparison may provide insight to a requestor as a way of confirming whether a current evaluation may be acceptable or not with respect to similar evaluations. In an embodiment, under component scores 1720, evaluation details may be provided such as the credibility 1721, operationality 1722 and sustainability 1723 along with their corresponding weight values for verification purposes. In an embodiment, the drill down of information may be provided in 1724, 125 and 1726 to provide the values of individual specifications that contributed to component values. In an embodiment, the credibility component 1721 may be calculated based on sub-components in 1724 such as credit score, product diversity that may be based on the number of products in the product portfolio, longevity that may be scored based on the number of operating years or with respect to the founding year, and growth that may be based on the compounded annual growth rate in revenues or sales, or may be based on the increase rate in the number of branch offices, among others. In an embodiment, these values may be scaled from 0 to 100.

[00187] In an embodiment, the sub-components for operationality component 1722 as shown in 1725 may include the lead time which may be calculated based on the comparison of actual lead time measure from the operation data as compared to the desired lead time which is indicated in specification 111, the quality which may be calculated based on the yield rate or defect rate of producing a product, the capacity which may refer to the manufacturing capacity which may be calculated based on the job size, processing time, machine availability, among other operation data. In an embodiment, the flexibility may be calculated based on the number of redundant or multiple flows (e.g., material flow, supply flow, production flow) that may be possible, for example, in case one production line or a machine broke down. In an embodiment, it may also be measured based on the number of redundant machines of a key or bottleneck process. In an embodiment, these values may be scale from 0 to 100.

[00188] In an embodiment, the sub-components for sustainability components 1723 as shown in 1726 may include the environmental rating which may be calculated based on the ratings received from compliance evaluations, safety which may be calculated based on the recency and frequency of incidences or accidents, and C02 emission rating. In an embodiment, these values may be scale from 0 to 100. [00189] FIG. 18 illustrates an exemplary interface of a supplier’s network according to an embodiment of the present disclosure.

[00190] FIG. 18 exemplifies an interface that allows for displaying supplier’s network as illustrated in 1000B and lOOOC. In an embodiment, it may be provided as part of a reporting unit 140 that may allow a requestor, an operator of compatibility scoring unit 120, or other stake holders to define a list of partners and their connections as shown in partner connectivity 1810, and supplier list 1820. In an embodiment, the diagram may show an overall view of the supplier connections with company names, assuming that all suppliers are willing to share their names. In an embodiment, even without the specific names, the compatibility score evaluation may be possible, provided the relationship between suppliers are clarified by defining a partner 1821, its type 1822, and the next link company 1823, which may be a sourcing or service providing company relative to a preceding company. In an embodiment, the entire data in this table may not be available to any stakeholders or supplier. In an embodiment, a supplier may only add the respective connection without knowing or being shown other suppliers information. In an embodiment, the diagram in 1810 may be shown to any suppliers. In an embodiment, details of a supplier that may be known may be showed to both requestor 1811 and partner 1815. The common connection between the requestor 1811 and the partner 1815 may be supplier 1813.. In an embodiment, requestors, partners and suppliers of a supply chain may be referred to as members of the supply chain. In an embodiment, details of other members which are common connections between groups of members of the supply chain may be shared between the group of members and may be shown to the group of members.

[00191] In an embodiment, by using 1800, each supplier of a network may be able to configure the method for providing operation data which may be either by manual upload or API connections as shown in 1824. In an embodiment, an interface similar to 1800 may be provided to suppliers to define their process flow by defining the connection of processes, and subprocesses as well as the corresponding related machines.

[00192] While the present disclosure has been particularly shown and described with reference to specific aspects, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the present disclosure as defined by the appended claims. The scope of the present disclosure is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

Claims

CLAIMS What is claimed is:

1. A compatibility scoring system for evaluating compatibility between a requestor and at least one entity, the compatibility scoring system comprising: a requestor unit configured to receive a request from the requestor; a compatibility scoring unit configured to receive the request from the requestor unit, wherein the compatibility scoring unit is configured to generate types of data required based on the request, and configured to choose the at least one entity to request the types of data required from; at least one data gathering unit configured to receive the types of data required from the compatibility scoring unit, wherein the at least one data gathering unit is configured to send compatibility data from the at least one entity to the compatibility scoring unit, and the compatibility scoring unit is configured to obtain at least one compatibility score based on the compatibility data; and a reporting unit configured to receive the at least one compatibility score, and to display the at least one compatibility score.

2. The compatibility scoring system of claim 1, wherein the compatibility scoring unit is configured to recommend an entity from the at least one entity based on the at least one compatibility score.

3. The compatibility scoring system of claims 1 or 2, wherein the types of data required comprises credibility data, operationality data and sustainability data.

4. The compatibility scoring system of claim 3, wherein the credibility data comprises at least one of partner specification, product portfolio, and credit score, the operationality data comprises at least one of product specification, process specification, production flow, material flow and supply flow and the sustainability data comprises at least one of compliance specification and sustainability requirement.

5. The compatibility scoring system of claim 3 or claim 4, wherein the compatibility scoring unit is configured to obtain at least one compatibility score based on a first score of the credibility data with a first weight, a second score of the operationality data with a second weight, and a third score of the sustainability data with a third weight.

6. The compatibility scoring system of claim 5, wherein the first weight, the second weight and the third weight are predetermined or are derived from historical data through machine learning.

7. The compatibility scoring system of any one of claims 1-6, wherein the compatibility scoring unit comprises a central server configured to obtain the compatibility data from the at least one data gathering unit and configured to obtain at least one compatibility score based on the compatibility data.

8. The compatibility scoring system of any one of claims 1-6, wherein the compatibility scoring unit comprises a first computing unit of the at least one entity, and a second computing unit of the requestor; wherein the at least one data gathering unit is configured to send the compatibility data to the first computing unit, and the first computing unit is configured to obtain at least one compatibility score based on the compatibility data and configured to send the at least one compatibility score to the second computing unit.

9. The compatibility scoring system of any one of claims 2-8, wherein the reporting unit is configured to display other entities not recommended by the compatibility scoring unit, and configured to allow the requestor to choose between the recommended entity and the other entities.

10. The compatibility scoring system of any one of claims 1-9, wherein the compatibility scoring unit is configured to retrieve stored data of previous compatibility matches, wherein the previous compatibility matches have similar types of data as the types of data required by the compatibility scoring unit, and wherein the compatibility scoring unit is configured to obtain the at least one compatibility score based on the stored data of the previous compatibility matches.

11. A method for evaluating compatibility between a requestor and at least one entity, the method comprising: receiving a request from the requestor using a requestor unit; sending the request from the requestor unit to a compatibility scoring unit; using the compatibility scoring unit to generate types of data required based on the request; choosing the at least one entity to request the types of data required from; sending the types of data required from the compatibility scoring unit to at least one data gathering unit; sending compatibility data from the at least one entity to the compatibility scoring unit, and using the compatibility scoring unit to obtain at least one compatibility score based on the compatibility data; and sending the at least one compatibility score to a reporting unit, and using the reporting unit to display the at least one compatibility score.

12. The method of claim 11, the method further comprising: recommending an entity from the at least one entity based on the at least one compatibility score.

13. The method of claims 11 or 12, wherein the types of data required comprises credibility data, operationality data and sustainability data.

14. The method of claim 13, wherein the credibility data comprises at least one of partner specification, product portfolio, and credit score, the operationality data comprises at least one of product specification, process specification, production flow, material flow and supply flow and the sustainability data comprises at least one of compliance specification and sustainability requirement.

15. The method of claim 13 or claim 14, the method further comprising: using the compatibility scoring unit to obtain at least one compatibility score based on a first score of the credibility data with a first weight, a second score of the operationality data with a second weight, and a third score of the sustainability data with a third weight.

16. The method of claim 15, wherein the first weight, the second weight and the third weight are predetermined or are derived from historical data through machine learning.

17. The method of any one of claims 11-16, wherein the compatibility scoring unit comprises a central server, the method further comprising: using the central server to obtain the compatibility data from the at least one data gathering unit; and obtaining at least one compatibility score based on the compatibility data.

18. The method of any one of claims 11-16, wherein the compatibility scoring unit comprises a first computing unit of the at least one entity, and a second computing unit of the requestor, the method further comprising: using the at least one data gathering unit to send the compatibility data to the first computing unit; using the first computing unit to obtain at least one compatibility score based on the compatibility data; and sending the at least one compatibility score from the first computing unit to the second computing unit.

19. The method of any one of claims 12-18, the method further comprising: displaying other entities not recommended by the compatibility scoring unit using the reporting unit, and allowing the requestor to choose between the recommended entity and the other entities.

20. The method of any one of claims 11-19, the method further comprising: retrieving stored data of previous compatibility matches using the compatibility scoring unit, wherein the previous compatibility matches have similar types of data as the types of data required by the compatibility scoring unit, and obtaining the at least one compatibility score based on the stored data of the previous compatibility matches using the compatibility scoring unit.