WO2016209223A1

WO2016209223A1 - Enterprise resource planning (erp) system input translation

Info

Publication number: WO2016209223A1
Application number: PCT/US2015/037414
Authority: WO
Inventors: Steven MARNEY; Chandra Kamalakantha; Parag Doshi
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-06-24
Filing date: 2015-06-24
Publication date: 2016-12-29

Abstract

In example implementations, a non-vendor specific input is received for an enterprise resource planning (ERP) system. At least one vendor specific ERP system for applying the non-vendor specific input is identified. The non-vendor specific input is translated to a vendor specific input of the at least one vendor specific ERP system. The vendor specific input is used to cause at least one device in the at least one vendor specific ERP system to be modified.

Description

ENTERPRISE RESOURCE PLANNING (ERP) SYSTEM INPUT

TRANSLATION

BACKGROUND

[0001] An examination of the information technology (IT) architecture of most enterprises reveals a "spaghetti-like" architecture consisting of technologies that span multiple vendors each with its own core competency. For example, an enterprise may use a number of enterprise resource planning (ERP) systems from a first vendor for general ledger, inventory management, etc., while using a number of ERP systems from a second different vendor for human resource management, and customer relationship management technologies from a third different vendor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] FIG. 1 is a block diagram of an example system of the present disclosure;

[0003] FIG. 2 is a block diagram of an example application deployment manager (ADM) integration device of the present disclosure;

[0004] FIG. 3 is a flowchart of an example method for translating a non- vendor specific input for an enterprise resource planning (ERP) system to a vendor specific input; and

[0005] FIG. 4 is a flowchart of another example method for translating a non- vendor specific input for an ERP system to a vendor specific input.

DETAILED DESCRIPTION

[0006] The present disclosure discloses a method, system and apparatus for translating a non-vendor specific input for an enterprise resource planning (ERP) system to a vendor specific input. As discussed above, information technology (IT) architecture of most enterprises reveals a "spaghetti-like" architecture consisting of technologies that span multiple vendors each with its own core competency. For example, an enterprise may use a number of enterprise resource planning (ERP) systems from a first vendor for general ledger, inventory management, etc., while using a number of ERP systems from a second different vendor for human resource management, and customer relationship management technologies from a third different vendor.

[0007] Enterprises may want to execute a command or implement a configuration change in the ERP systems. However, since the enterprise may use different vendor specific systems, the command or the configuration change that is provided as an input is implemented multiple different times using multiple different formats or protocols that are specific to each one of the different vendor specific systems. This may be a laborious and inefficient process. In addition, the different implementations may lead to incorrect implementations, errors, bugs, and the like.

[0008] Examples of the present disclosure provide a method for translating a non-vendor specific input for an enterprise resource planning (ERP) system to a vendor specific input. For example, each vendor specific ERP system used by the enterprise may be abstracted into a non-vendor specific input model. The user may learn a single non-vendor specific language and provide inputs as non-vendor specific inputs. The non-vendor specific inputs may automatically be translated to a vendor specific input for each vendor specific ERP system that implements the non-vendor specific input.

[0009] FIG. 1 illustrates an example system 100 of the present disclosure. In one example, the system 100 includes a unified application deployment manager (ADM) 02. The unified ADM 102 may include a user interface (Ul) 120, an application programming interface (API) module 122, and a plurality of service models 124.

[0010] In one example, the unified ADM 102 may be in communication with an ADM integration device 104. In one example, the unified ADM 102 and the ADM integration device 104 may be deployed as parts of a single server or computer. In another example, the unified ADM 102 and the ADM integration device 104 may be deployed as separate servers or computers. In other words, the ADM 102 and the ADM integration device 104 may each include separate processors and memory or may share a common processor and memory. [0011] In one example, the ADM integration device 104 may be in communication with a plurality of different vendor specific ERP systems 108-1 to 108-n (herein also referred to individually as vendor specific ERP system 108 or collectively as vendor specific ERP systems 108). The ADM integration device may also be in communication with an operations (OPS) management and monitoring module 1 10 and an invoice and billing module 1 2. The operations management and monitoring module 1 10 and the invoice and billing module 1 12 may each be deployed as a server or a computer.

[0012] In one example, each one of the vendor specific ERP systems 108 may have devices deployed in different infrastructure pools. For example, the vendor specific ERP system 108-1 may have a device or devices 132, the vendor specific ERP system 108-2 may have a device or devices 134, and the vendor specific ERP system 108-n may have a device or devices 136 in a non- cloud infrastructure pool 1 14. In one example, the vendor specific ERP system 108i may have a device or devices 138, the vendor specific ERP system I O8₂ may have a device or devices 140, and the vendor specific ERP system 108_n may have a device or devices 142 in a private cloud infrastructure pool 116. In one example, the vendor specific ERP system 108-1 may have a device or devices 144, the vendor specific ERP system 108-2 may have a device or devices 146, and the vendor specific ERP system 108-n may have a device or devices 148 in a public cloud infrastructure pool 1 18.

[0013] In one example, the non-cloud infrastructure pool 114 may be a pool of devices 132, 134, and 136 that are local to the enterprise. For example, endpoints within an enterprise location or at the same location of the devices 132, 134, and 136 may access the devices 132, 34, and 136. In one example, the private cloud infrastructure 1 16 may be a pool of devices 138, 40 and 42 that are accessible by any authorized endpoint device with access to the Internet. For example, an enterprise may allow employees who are remotely located all over the world to access the devices 138, 140, and 142 on the private cloud infrastructure 1 16. In one example, the public cloud infrastructure 118 may be a pool of devices 144, 146, and 148 that are accessible by any endpoint device with access to the Internet. [0014] In one example, each of the devices 132, 134, 136, 138, 140, 142, 144, 146, and 148 may be a hardware device. For example, the device may be a computer system, a server, storage network, and the like. In one example, the devices 132, 134, 136, 138, 140, 142, 144, 146, and 148 are configured to communicate in a protocol or programming language specific to the respective vendor specific ERP system 108. For example, the devices 132, 138, and 144 are configured to communicate with the vendor specific ERP system 108-1 , the devices 134, 140, and 46 are configured to communicate with the vendor specific ERP system 108₂ and the devices 136, 142, and 148 are configured to communicate with the vendor specific ERP system 108_n.

[0015] Previously, if an enterprise wanted to deploy a command or a configuration change to modify the devices 132, 134, 136, 138, 140, 142, 144, 146, and 148, the enterprise would have to implement the change at least N times for each one of the different vendor specific ERP systems 108-1 to 108-n. As noted above, this would be a laborious and inefficient process that could lead to many errors and bugs.

[0016] In one example of the present disclosure, a non-vendor specific input may be automatically translated to a vendor specific input and each one of the devices 132, 134, 136, 138, 140, 142, 144, 146, and 148 across each one of the different vendor specific ERP systems 108 may be modified (e.g., a hardware change, a software change, or a combination of both a hardware and a software change). In other words, a single non-vendor specific input may cause all of the devices 132, 134, 136, 138, 140, .142, 144, 146, and 148 across each one of the different vendor specific ERP systems 108 to be modified in accordance with the non-vendor specific input.

[0017] In one example, the modification may be implemented by the ADM integration device 104. In another example, the ADM integration device 104 may cause another server or device to implement the modification in accordance with the non-vendor specific input.

[0018] In one example, to automatically translate the non-vendor specific input, a non-vendor specific model can be created by abstracting a model associated with each one of the vendor specific ERP systems 108. For example, the plurality of service models 124 may include vendor specific models 126-1 to 126-n (herein also referred to individually as vendor specific model 126 or collectively as vendor specific models 126) for translating non-vendor specific inputs into a vendor specific input. In one example, the abstraction may be created using Topology and Orchestration Specification for Cloud Applications (TOSCA). However, it should be noted that other abstraction models may also be used.

[0019] With the vendor specific models 126 abstracted, the user may enter a non-vendor specific input via the Ul 120. The non-vendor specific input may be a verb that initiates a command or a configuration change. The non-vendor specific input may include, for example, a deploy command, a clone, copy and refresh command, an upgrade command, a re-configure network configuration command, a storage configuration command, a customizations, enhancements, modifications, localizations and integrations (CEMLI) command, and the like.

[00201 In one example, the API module 122 may include an API for each possible non-vendor specific input. For example, the API module 22 may be a catalogue of all of the possible non-vendor specific inputs that may be entered via the Ul 120. The API module 122 may act as a gateway to control how each one of the non-vendor specific inputs can access each one of the vendor specific ERP systems 108 and how to perform each non-vendor specific input for each one of the vendor specific ERP systems 108. The API module 122 may include various calls and parameters required for a particular non-vendor specific input. The user may be prompted to provide the parameters via the Ul 120.

[0021] The non-vendor specific input entered by the user may be found in the non-vendor specific input model. Based on the vendor specific ERP system or systems 108 that are to implement the non-vendor specific input, a corresponding vendor specific input may be identified from the vendor specific models 26 using the abstracted non-vendor specific input model. In other words, the non-vendor specific input is translated automatically using the abstracted vendor specific models 126.

[0022] In one example, there may be a one-to-one correspondence. For example, the non-vendor specific input may be a deploy command. The vendor specific model 126-1 used for translating inputs directed towards the vendor specific ERP system 108-1 may also have a deploy command. As a result, the non-vendor specific deploy command is translated to the deploy command for the vendor specific ERP system 108-1 using the vendor specific model 126-1.

[0023] However, some inputs may not have a one-to-one correspondence. As a result, the unified ADM 102 may create the vendor specific input that corresponds to the non-vendor specific input by combining a plurality of vendor specific inputs. Referring again to the non-vendor specific input of a deploy command, the vendor specific model 126-2 used for translating inputs directed towards the vendor specific ERP system 108-2 may not have a deploy command. As a result, the unified ADM 102 may deconstruct what commands are required to perform a deploy command (e.g., an install command, a configure command and an activate command). The unified ADM 102 may then find the different commands in the vendor specific model 126-2 and pass the three commands (e.g., the install command, the configure command and the activate command) to the ADM integration device 104 to implement in the vendor specific ERP system 108-2. Notably, although the deploy command did not have an exact translation in the vendor specific model 126-2, the unified ADM 102 is able to translate the non-vendor specific input into the vendor specific input using a combination of different vendor specific inputs.

[0024] In one example, once the non-vendor specific inputs are implemented and the devices 132, 134, 136, 138, 140, 142, 144, 146, and 148 are modified, the ADM integration device 104 may monitor the operations of the devices 132, 134, 136, 138, 140, 142, 144, 146, and 148 using the operations management and monitoring module 110. The operations management and monitoring module 110 may detect any errors in any modifications that are implemented. The ADM integration device 104 may then automatically correct the errors or create a service ticket in the appropriate vendor specific ERP system 108.

[0025] In addition, the ADM integration device 104 may calculate a cost associated with each non-vendor specific input that is implemented using the invoice and billing module 112. As a result, non-vendor specific inputs for each one of the vendor specific ERP system 108 may be efficiently billed.

[0026] FIG. 2 illustrates a block diagram of the ADM integration device 104 of the present disclosure. In one example, the ADM integration device 104 may include a processor 202 and a memory 204. The processor 202 may be in communication with the memory 204. In one example, the processor 202 may be a hardware processor element, a central processing unit (CPU), a microprocessor, or a multi-core processor. In one example, the memory 204 may be a non-transitory computer readable medium or computer readable storage medium (e.g., a random access memory (RAM), a hard disk drive, and the like).

[0027] Although one processor 202 is shown, it should be noted that the ADM integration device 104 may employ a plurality of processors 202 or processor elements. Furthermore, although one ADM integration device 04 is shown in FIGs. 1 and 2, if the method(s) as discussed below is implemented in a distributed or parallel manner for a particular illustrative example, i.e., the blocks of the method(s) below or the entire method(s) are implemented across multiple or parallel computers, then the ADM integration device 104 of FIGs. 1 and 2 is intended to represent each of those multiple ADM integration devices 104.

[0028] In one example, the memory 204 (e.g., a machine-readable storage medium) may include instructions that are executed by the processor 202. In one example, the instructions may include instructions to receive a vendor specific input 216 and instructions to cause at least one device to be modified 2 8. For example, the ADM integration device 104 may receive the vendor specific input translated by the unified ADM 102 from the non-vendor specific input via a unified ADM interface 210.

[0029] The ADM integration device 104 may cause at least one device to be modified in the vendor specific ERP systems 108 via a respective ERP interface 208-1 to 208-n (herein referred to individually as ERP interface 208 or collectively as ERP interfaces 208). For example, the vendor specific input for the vendor specific ERP system 108-1 may be transmitted via the ERP interface 208-1 , the vendor specific input for the vendor specific ERP system 108-2 may be transmitted via the ERP interface 208-2, and so forth.

[0030] In one example, the ADM integration device 104 may include an operations management (OPS MGMT) and monitoring interface 212 for communicating with the operations management and monitoring module 110. In one example, the ADM integration device 104 may include an invoice and billing interface 214 for communicating with the invoice and billing module 1 12.

[0031] FIG. 3 illustrates an example flowchart of a method 300 for translating a non-vendor specific input for an ERP system to a vendor specific input. In one example, the method 300 may be performed by the unified ADM 102.

[0032] At block 302 the method 300 begins. At block 304, the method 300 receives a non-vendor specific input for an ERP system. For example, a user may enter a non-vendor specific input via the Ul of the unified ADM. The non- vendor specific input may be a command or a configuration change. For example, the non-vendor specific input may include, for example, a deploy command, a clone, copy and refresh command, an upgrade command, a reconfigure network configuration command, a storage configuration command, a customizations, enhancements, modifications, localizations and integrations (CEMLI) command, and the like.

[0033] In one example, the Ul may prompt the user to enter various information or parameters for the non-vendor specific input in accordance with an API associated with the non-vendor specific input. In addition, the user may identify which vendor specific ERP systems are to implement the non-vendor specific input.

[0034] At block 306, the method 300 identifies at least one vendor specific ERP system to apply the non-vendor specific input. For example, the user may provide which vendor specific ERP systems are to implement the non-vendor specific input via the Ul when entering the non-vendor specific input.

[0035] At block 308, the method 300 translates the non-vendor specific input to a vendor specific input of the at least one vendor specific ERP system. In one example, a non-vendor specific input model may be created by abstracting each one of a plurality of different vendor specific ERP systems that are deployed by an enterprise. For example, the non-vendor specific input model may be a collection of non-vendor specific inputs that can be automatically translated into a vendor specific input using a vendor specific model from which the non-vendor specific input model was abstracted. In one example, the abstraction may be performed using TOSCA.

[0036] The non-vendor specific input may be translated for each vendor specific ERP system that was identified at block 306. For example, if two different vendor specific ERP systems were identified, then the non-vendor specific input may be translated using a first vendor specific model for the first ERP system and a second vendor specific model for the second ERP system.

[0037] At block 310, the method 300 may cause at least one device in the at least one vendor specific ERP system to be modified in accordance with the vendor specific input. For example, the unified ADM may send the vendor specific input to the ADM integration device to cause at least one device to be modified. In one example, the ADM integration device can perform the modification directly via a respective interface to each vendor specific ERP system that was identified with the respective vendor specific input translated from the non-vendor specific input. In another example, the ADM integration device may control another device or server to perform the modification in accordance with the vendor specific input. At block 312, the method 300 ends.

[0038] FIG. 4 illustrates an example flowchart of another method 400 for translating a non-vendor specific input for an ERP system to a vendor specific input. In one example, the method 400 may be performed by the system 100.

[0039] At block 402 the method 400 begins. At block 404, the method 400 abstracts vendor specific inputs for each one of a plurality of different vendor specific ERP systems into a non-vendor specific model. For example, each vendor specific ERP system may have a unique protocol, language or input model. However, each vendor specific ERP system can be abstracted into a common non-vendor specific input model. As a result, a user may learn a single non-vendor specific input model and is then able to use the non-vendor specific inputs of the non-vendor specific input model to execute an input across all different vendor specific ERP systems.

[0040] At block 406, the method 400 receives a non-vendor specific input. For example, a user may enter a non-vendor specific input via the Ul of the unified ADM. The non-vendor specific input may be a command or a configuration change. For example, the non-vendor specific input may include, for example, a deploy command, a clone, copy and refresh command, an upgrade command, a re-configure network configuration command, a storage configuration command, a customizations, enhancements, modifications, localizations and integrations (CEMLI) command, and the like.

[0041] In one example, the Ul may prompt the user to enter various information or parameters for the non-vendor specific input in accordance with an API associated with the non-vendor specific input. In addition, the user may identify which vendor specific ERP systems are to implement the non-vendor specific input.

[0042] At block 408, the method 400 identifies at least one vendor specific ERP system to apply the non-vendor specific input. For example, the user may provide which vendor specific ERP systems are to implement the non-vendor specific input via the Ul when entering the non-vendor specific input.

[0043] At block 410, the method 400 identifies the vendor specific input of the at least one vendor specific ERP system that corresponds to the non-vendor specific input from the non-vendor specific input model that is abstracted. For example, a searching function or a matching function may be performed to look for the non-vendor specific input in a vendor specific model that corresponds to or matches a vendor specific input.

[0044] At block 412, the method 400 determines if a match is found. If a match is not found, the method 400 proceeds to block 414. At block 414, the method 400 creates the vendor specific input. For example, the vendor specific input may be created by combining a plurality of different vendor specific inputs from the non-vendor specific model that is abstracted from the at least one vendor specific ERP system. The method 400 then proceeds to block 416.

[0045] Referring back to block 412, if a match is found, then the method 400 proceeds to block 416. For example, one-to-one correspondence exists between the non-vendor specific input and a vendor specific input in a vendor specific model of the identified vendor specific ERP system. [0046] At block 416, the method 400 causes at least one device to be modified in accordance with the vendor specific input. For example, the unified ADM may send the vendor specific input to the ADM integration device to cause the at least one device to be modified. In one example, the ADM integration device can perform the modification directly via a respective interface to each vendor specific ERP system that was identified. In another example, the ADM integration device may control another device or server to perform the modification in accordance with the vendor specific input.

[0047] At block 418, the method 400 monitors the at least one device. For example, an operations management and monitoring module in communication with the ADM integration device may continuously monitor the modified device or devices to ensure that the vendor specific input was deployed correctly (e.g., monitoring the intended function of a command is performed correctly and so on). In one example, if any errors are detected, a service ticket may be created on the respective vendor specific ERP system (e.g., using a service desk of the vendor specific ERP system). In another example, the ADM integration device 104 may automatically analyze the error and correct the error in the vendor specific ERP system.

[0048] At block 420, the method 400 calculates a total cost of a modification to the at least one device. In one example, an invoice and billing module may be in communication with the ADM integration device. The invoice and billing module may track each modification to the devices of the vendor specific ERP systems and calculate a total cost associated with the modifications. At block 422, the method 400 ends.

[0049] It should be noted that although not explicitly specified, any of the blocks, functions, or operations of the example methods 300 and 400 described above may include a storing, displaying, and/or outputting block as required for a particular application. In other words, any data, records, fields, and/or intermediate results discussed in the methods can be stored, displayed, and/or outputted to another device as required for a particular application.

Furthermore, blocks, functions, or operations in FIGs. 3 and 4 that recite a determining operation, or involve a decision, do not necessarily require that both branches of the determining operation be practiced.

[0050] It will be appreciated that variants of the above-disclosed and other features and functions, or alternatives thereof, may be combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, or variations, therein may be subsequently made which are also intended to be encompassed by the following claims.

Claims

1. A method, comprising:

receiving, via a processor, a non-vendor specific input for an enterprise resource planning (ERP) system;

identifying, by the processor, at least one vendor specific ERP system to apply the non-vendor specific input;

translating, by the processor, the non-vendor specific input to a vendor specific input of the at least one vendor specific ERP system; and

causing, by the processor, at least one device in the at least one vendor specific ERP system to be modified in accordance with the vendor specific input.

2. The method of claim 1 , further comprising:

abstracting, by the processor, vendor specific inputs for each one of a plurality of different vendor specific ERP systems into a non-vendor specific input model.

3. The method of claim 2, wherein the translating comprises:

identifying, by the processor, the vendor specific input of the at least one vendor specific ERP system that corresponds to the non-vendor specific input from the non-vendor specific input model that is abstracted for the at least one vendor specific ERP system.

4. The method of claim 2, wherein the translating comprises:

determining, by the processor, that the non-vendor specific input does not have a corresponding vendor specific input from the non-vendor specific input model of the at least one vendor specific ERP system; and

creating, by the processor, the vendor specific input of the at least one vendor specific ERP system by combining a plurality of the vendor specific inputs from the non-vendor specific input model that is abstracted from the at least one vendor specific ERP system.

5. The method of claim 2, wherein the abstracting comprises using

Topology and Orchestration Specification for Cloud Applications (TOSCA).

6. The method of claim 1 , wherein the non-vendor specific input comprises at least one of: a deploy command, a clone, copy and refresh command, an upgrade command, a re-configure network configuration command, a storage configuration command or a customizations, enhancements, modifications, localizations and integrations (CEMLI) command.

7. The method of claim 1 , further comprising:

monitoring, by the processor, that the at least one device that was modified is executing the vendor specific input correctly in the at least one vendor specific ERP system.

8. An apparatus, comprising:

an interface to a unified application deployment management (ADM) server;

a plurality of interfaces to a plurality of different vendor specific enterprise resource planning (ERP) systems, wherein each one of the plurality of different vendor specific ERP systems includes at least one device;

a processor; and

a machine-readable storage medium encoded with instructions executable by the processor, the instructions comprising instructions to:

receive, via the interface to the unified ADM server, a vendor specific input for the each one of the plurality of different vendor specific ERP systems that was translated from a non-vendor specific input by a non-vendor specific input model abstracted from the each one of the plurality of different vendor specific ERP systems; and

cause, via the plurality of interfaces to the plurality of vendor specific ERP systems, the at least one device in each one of the plurality of different vendor specific ERP systems to be modified using the vendor specific input for the each one of the plurality of different vendor specific ERP systems.

9. The apparatus of claim 8, further comprising:

an interface to a operations management and monitoring server for monitoring that the at least one device that was modified in the each one of the plurality of vendor specific ERP systems is executing the vendor specific input correctly.

10. The apparatus of claim 8, further comprising:

an interface to an invoice and billing server for calculating a total cost of a modification to the at least one device in the each one of the plurality of vendor specific ERP systems.

11. The apparatus of claim 8, wherein the non-vendor specific input comprises at least one of: a deploy command, a clone, copy and refresh command, an upgrade command, a re-configure network configuration command, a storage configuration command or a customizations,

enhancements, modifications, localizations and integrations (CEMLI) command.

12. A system, comprising:

a unified application deployment manager (ADM) for translating a non- vendor specific input into a vendor specific input for at least one vendor specific enterprise resource planning (ERP) system;

an ADM integration server in communication with the unified ADM for receiving the vendor specific input and applying the vendor specific input to modify a device of at least one of a plurality of different vendor specific ERP systems in communication with the ADM integration server; and

at least one infrastructure pool in communication with the ADM integration server comprising the device of the at least one of the plurality of different vendor specific ERP systems.

13. The system of claim 12, wherein the unified ADM further comprises: a user interface for receiving the non-vendor specific input; and a database for storing a plurality of application programming interfaces (APIs) for each one of a plurality of different non-vendor specific inputs and a non-vendor specific model abstracted from the each one of the plurality of different vendor specific ERP systems, wherein the non-vendor specific model is used for the translating of the non-vendor specific input to the vendor specific input for the at least one vendor specific ERP system.

14. The system of claim 12, further comprising:

an operations management and monitoring server in communication with the ADM integration server for monitoring that the device that was modified in the at least one of the plurality of different vendor specific ERP systems is executing the vendor specific input correctly; and

an invoice and billing server in communication with the ADM integration server for calculating a total cost of a modification to the device in the at least one of the plurality of different vendor specific ERP systems.

15. The system of claim 12, wherein the at least one infrastructure pool comprises a non-cloud resource, a private cloud resource or a public cloud resource.