This paper discusses how a new approach, Semantic Business Process Mining (SBPM), can combine with not so new technology (BPCS), to provide knowledge that is of benefit to both the business and information technology members of an organisation.
The BPCS ERP LX application is the biggest selling mid-range ERP application with over 6,500 applications at 18,000 sites. It runs on the IBM i (S/38 and AS/400 and i Series) the biggest selling mid-range computer with over 750,000 installed sites.
Infor’s BPCS ERP LX supports high-volume, repetitive, multimode manufacturing. This product has an installed base in the specialty chemical, food and beverage, pharmaceutical, CPG and automotive supplier industries.
SBPM is new. Only recently developed as part of the SUPER research project (Semantics Utilized for Process Management within and between Enterprises) it has evolved as a methodology to bridge the gap between the different ‘languages’ used by business and IT. SBPM is part of the larger field called Semantic Business Process Management.See http://www.ip-super.org/
How does the BPCS Inventory Management (or any BPCS application) behave over a monthly cycle? Is the process behaving as expected? What does the workflow look like? Which users are working on specific tasks? Which groups of users are working on Inventory Transaction Posting? What programs are used in Cycle Counting or Month end? How does the organisation audit the application?
BPCS does not have any workflow diagrams. There are over 1000 programs and there is no defined hierarchy. There is also no link between the different users of BPCS.
Process Mining is a capability that allows the reverse engineering of event logs to generate workflow diagrams. We have developed an interface between BPCS and the Process Mining application ProM. http://prom.win.tue.nl/tools/prom/
The BPCS customer used in this example manufactures and sells products in Australia as part of a larger US conglomerate. They use all the BPCS modules and no other ERP applications.In order to discover BPCS processes we need to mine its event logs IBM i journals.
Using the BPCS to Prom Interface, BPCS event logs were mined at the end of a one month cycle (June 2009) from the client’s IBM i. Two tasks had to be completed before a semantic analysis could take place;
Create an Originator Ontology – Using WSMO Studio, an ontology was created for the Client. There were about 120 users, split into several groups including; Sales, Manufacturing, Finance and Logistics.
Create a BPCS Ontology – Again using WSMO studio, an ontology of BPCS tasks and groups was created. This was quite time consuming for several reasons; it is difficult to get a comprehensive list of the BPCS tasks and their descriptions, the descriptions are often not clear and we are only interested in those that update the database. It is then important to create ‘super’ concepts in the ontology that are meaningful and useful.
A section of the BPCS ontology is below.
BPCS Inventory Management Ontology
A further problem was to take the program descriptions and turn them from a program name to something more like a process name. For example; INV100D2 is the program called Item Master Maintenance. As a process name ‘Maintain Item Master’ is more appropriate.
Why Use Semantics?
Process Mining on its own will reveal workflows. Process Mining is based on syntax; Semantic Business Process Mining is based on meaning. It allows us to turn these Ontologies into a machine readable format. So the mining process application knows how all the pieces of BPCS fit together and who works for what department in the organisation.
Semantic abstractions provide meaning. BPM raises understanding from a technical level to a business level. Rather than using codes we can now have descriptions in the analysis. They also provide clarity. We can group like codes into a process group.
In the next three diagrams we can see three levels of abstraction in a BPCS workflow.
This diagram shows the BPCS Inventory process as a workflow using program names.
The diagram below is exactly the same but using descriptions instead of codes.
The following diagram is a further abstraction where the tasks have been summarized into a higher level of the ontology.
For example, all the Cycle Count tasks appear as just one task, Perform Cycle Counting.
Clearly there can be as many levels of abstraction required and users can tailor their own ontologies to meet their individual needs. There are many other analyses available.
Note that the above applies to any iSeries application including Oracles ERP OneWorld and EnterpriseOne