Online Process Management at GBI / part 2
An entire life cycle sounds like a lot to work on. But isn’t that too ambitious and challenging for us? And how is “life” related to IT? As one of the students of Hochschule Harz University of Applied Sciences in Wernigerode, Germany, I sit staring at “our” Business Process Life Cycle …
Harz Roadmap at SAP Solution Manager
As a project management tool for all parties involved we had chosen the SAP Solution Manager hosted by the SAP University Competence Center Magdeburg. First of all it supports our so called GBI Project Roadmap which is related to the Business Process Life Cycle (see first chapter). Thus the Roadmap consists of “Project Preparation”, “Business Blueprint”, “Implementation” and “Go Live”.
Please click on the Hochschule Harz Roadmap for higher resolution !
During “Project Preparation” we defined our resources (e.g. 1 day per student and week), our roles and partners (e.g. quality manager, implementation manager/partner, project manager/partner), project mile stones of our 6 work packages over the next two semesters until next summer and project documents / project standards (e.g. work package status) we are going to use in our GBI Online Process Management project.
The “Business Blueprint” was mentioned in the first blog already. For business blueprinting the Solution Manager serves as a Very Large Business Application (VLBA) repository. Initially we derived the as-is status from the existing GBI enterprise model repository. We found the three levels of process hierarchy predefined in the SAP Solution Manager a good basic structure for horizontal and vertical orientation / navigation and thus assigned the module names of the GBI case study like Materials Management (MM) to the “Scenario level”, the highest level of hierarchy of the Business Blueprint. On the so called Process (second) level we put all single tasks of one case study (e.g. 22 tasks of MM) like “Create New Vendor” and ordered the entire process overview as a value added chain diagram. On the deepest (third) level of hierarchy we focused on “Process Steps” like the SAP Function “create purchase order” represented as very simple EPC. We will talk about their transformation to BPMN models later.
Business Blueprint goes ARIS and vice versa
Secondly we transferred the Business Blueprint from the SAP Solution manager to the ARIS Business Designer for SAP. This part of the GBI enterprise model is called GBI Repository too (like its source) within the ARIS version. Now we could add process splits, joins and loops. We assigned master and transactional data, SAP document flow (which only exist in the ARIS version), system organizational units like “Plant” as well as positions and roles of the GBI repository. Finally we specified the transactions by assigning keys, foreign keys and describing attributes which we put on a new fourth level called “document level” that only exists in the ARIS version. The second part of our enterprise model in ARIS – enriched with detailed GBI case study content – is called GBI Curriculum. Both parts GBI Curriculum and GBI Repository are highly interconnected via Object Occurrances, a very very powerful and useful feature of ARIS.
Finally we synchronized our GBI Repository back to the Business Blueprint of the SAP Solution Manager. After fixing some problems with double “SAP IDs” we could find a certain amount of changes from ARIS (restricted to transactions and functions) in our Business Blueprint what we found really exciting. By double clicking (transaction SOLAR02) we could directly jump from the system organizational units of the Business Blueprint to the customizing transaction of our ERP system. Or we could jump from a transaction like “VA02” from the SAP Solution Manager to the corresponding transaction of the connected SAP ERP system. Not bad !
For creating the to-be status of the GBI enterprise model we went a similar way. The GBI to-be repository additionally covers non SAP business functions like web Services , BAPIs for our business workflows and new WebDynpros for the mobile part of our to-be processes. For presenting these to-be processes we could choose between a BMPN or an EPC version. They are highly interconnected for an easy horizontal navigation forth and back.