Solution Manager 7.2 – Fasten your seatbelts.
Having now experienced a bit of Solution Manager 7.2 for real, I’d like to share a few initial thoughts. It goes without saying this is a big improvement on the earlier 7.1 in terms of three key areas that really need to be integrated: documentation of existing processes, process modelling new features, and change control from one to the other. I’m hopeful this is an inflexion point on Solution Manager demand, as the integrated approach is a much more compelling story than piece-meal adoption of tools. There are many things that seem deserving of mention, I’d just like to explore two of them for now.
The Branch Concept
Solution Manager 7.2 introduces a branch concept for storing documentation (and through integration, process monitoring and change control between them). Starting with a single and solitary Solution, there is always a Production branch (locked), and child “Maintenance” branch (unlocked). New, changed and deleted changes can be released into the production branch. If other branches exist off the Production branch, such as parallel developments, or other innovation and upgrade projects, these too will recieved the released changes. If there is a difference between branches, then the conflict has to be resolved resolved before the changes can be released. If ChaRM is integrated, then changes can’t be made until a change request is approved and change request assigned.
When trying to understand the behviour of elements in the branches, I think it is a mistake to think of them as directories in the conventional sense, with copies moving up and along the branches. In reality, each branch is a different view of the one Knowledge Warehouse document repository in which the mulitiple physical versions of a named logical artefact are stored. Changing an artefact in one branch changes the physical (hidden) version but the logical (displayed) identifier remans the same, and connects them together.
While the Production branch is paired with the production environments, the maintenance branch is for all sub-production environments: development, QAS and Pre-production (if it exists). Therfore the branch concept does not reflect the managed system landscape, but is a virtual representation for the PRD / DEV Solution Manager landscape. Let me illustrate this point with a warning. If you are are to upgrade an existing 7.1 system you have to think carefully about planning it. Many customers would perhaps start with Development. That is not a problem per se, but the process documentation put into the system is not meant to transported to Production when it arrives, nor is it a viable option to perform a system copy of the development system. The process documentation and configuration is meant to be entered into the Production Solution Manager 7.2 system directly, at the level of the Maintainance or equivalent child branch to be relased when ready into the Production branch. The branch concept thus represents a virtual representation of SolMan Dev and Prd, all in the physical Production instance.
The Process Level Seven – freedom at last?
The much anticipated extension of the three process hierachy levels (Scenaro/Process/Step) to seven levels was interesting to explore. So how best can these seven levels be used? Let’s start with the restrictions.
In Solution Manager 7.1, a Solution could act as fourth level. It’s use was never well defined, and originally was the only place were interfaces could be documented. In 7.2, Solutions are meant to exist uniquely, except perhaps for service providers with multiple customers where one customer is managed per Solution. Nevertheless a second Solution has proved useful as it appears that Best Practices can only be downloaded once per Solution. If there was a problem there appears to be no facility to delete and start again except with a new Solution (but this is only a provisional finding to report, there may be more to this).
Another restriction is the sequence Scenario > Process > Step. No other levels are allowed between Scenario and Process or Process and Step. I would imagine this is kept for compatibility reasons, though in actuality Senario is merely another folder level with a dfferent icon. Processes must belong to scenarios and steps must belong directly to a Process. Steps are always the lowest level, there can be no futher sub-divisons. Further sub-processing is only catered for by the abstraction of an interface business process step, in which further levels used to document preceding and post interface steps are contained in the Interface Library.
Finally, the very first level is occuppied with division between Business Processes and Libraries. Therefore there exists three levels in addition to Scenario > Process > Step to fit alongside, for example, the SAP standard process modelling hierarchy
I think the following comparisons can be made:
1. Process Model Level 6 (Activity, single actions to perfom a process step) corresponds to Solution Manger Assignments for a Process Step.
2. Process Model Level 4 (Process Variants) has no corresponding Solution Manager level. The recommended way is to either have one process per variant (as for Test Automation purposes) or handle the variants within the step, either by modelling every variation within the one BPMN diagram, of each variant as one seperate BPMN diagram assigned to the same process level.
3. Process Model Level 2 (Process Groups) could (should?) be represented at the Solution Manager Scenarios levels. For example, if the Process Model Level 1 is take to be 1.0 Purchase-to-Pay (or other E2E business area), each scenario is a grouping of processes along the way. For P2P this could be
1.1 Ordering, 1.2 Receipting, 1.3 Paying.
There’s obviously a lot more to say about Solution Manager 7.2 features, and this blog has really only touched on a couple of areas I’ve looked at in detail so far. Solution Manager 7.2 will keep everyone very busy and very happy for some time to come.