In a similar fashion to my good friend and colleague Andrew Noone, in his recent article about SAP Security & GRC “Why Bother?”, I wanted to propose a number of reasons why you absolutely should consider utilising Solution Manager for more than just the bare minimum, when it comes to managing your SAP solutions and projects.
Over a series of articles, I will explain real-life use cases and insights into the various offerings from within SAP’s Application Lifecycle Management (ALM) product – SAP Solution Manager.
If you work with SAP solutions, you have probably heard people drone on about ‘Solman’ or Solution Manager as a pain in the neck, a necessary evil, or any other number of idioms that are frankly outdated. Solution Manager has improved considerably in the last 7+ years and continues to be invested in, by SAP.
I’m not going to go through the ‘ROI’, ‘value proposition’ or whitepaper material, you can find that on SAP’s website. Chances are, if you are still reading, then you already know the background of why an ALM product like SAP Solution Manager exists.
I am here to share some of my experience of designing, implementing, and using SAP Solution Manager to deliver and manage major S/4HANA implementations, from project inception through to Business as Usual (BAU) Operations.
Process Management and Solution Documentation
Before starting your S/4HANA journey, you already have a clear business case and firm understanding of your existing business processes, right?…
That is a huge ask, and most likely unrealistic – there is a scale of ‘preparedness’. It is commonplace that companies pitch themselves further down the scale, where these crucial steps are overlooked completely. However, most likely there is a business case and knowledge of some business processes, but it can be neatly tucked away within the minds of the employees, managers and C-level execs.
Before you know it, your IT and/or Procurement people will have the “this deal won’t be on the table next week” conversation with the software vendor/reseller. The deal is done, and your management team are being poached by the Big 4, all wanting a piece of the S/4 pie.
There is nothing unique about that scenario, but here is where Solution Manager can help set the pace of those daunting first months of programme delivery, or if you are lucky enough, you can setup and prepare for the project, before pen hits paper on the sales order form!
Solution Manager 7.2 offers Process Management functionality, which means you can structure your business processes, documentation, configuration, and test scripts in a hierarchical format, providing a centralised, single source of the truth for your SAP solutions and their underpinning artefacts.
Process Management is split into several areas, but this article will focus on the core feature, known as Solution Documentation. In my opinion, it is one of the standout features of Solution Manager, that can save you actual pain, time, money and tears, throughout your SAP implementation and beyond.
The process modelling capabilities within Solution Documentation are realised using an inbuilt BPMN graphical editor, which lets you draw process diagrams, ‘drag and drop’ reusable steps, link processes together and export to pdf, all within the tool itself.
The modelling tool easy to use, but I would recommend deploying Business Process Modelling expertise as early as possible. They will be used to modelling with BPMN2.0 notation and can start to extract and translate process information into process models.
If you don’t know where to start with the process design, you can use SAP best-practice processes, download them into your Solution Manager system and enhance them as you see fit, or you may even decide to adopt the SAP standard (even better, as SAP delivers pre-created configuration and test scripts with the business processes).
So, you have a tool for mapping out your business process hierarchy and drawing pretty pictures – great, and I would encourage you to make full use of this free capability, but to really get to grips with your S/4HANA (or any SAP project) implementation, lets talk about some other elements of Solution Documentation…
The SAP help pages will give you an in-depth account of the features and tools, but here is how configuring certain aspects of Solution Documentation gave a previous customers’ S/4HANA project some tangible benefits and saved countless hours of meetings/emails about ‘that was never agreed’, ‘we’ve finished the design’, ‘sorry that’s not in scope’… You get the picture.
- Document Types
- Document Status Schemas
- Digital Signatures
These configurable areas require you as the customer to decide on how you want your project documentation to be handled. The below table gives examples, such as; (FSD) Functional Specification, (TSD) Technical Specification, (FUT) Functional Unit Test.
|Document Status Schema
|(FSD) Functional Specification
|(TSD) Technical Specification
|(FUT) Functional Unit Test
It’s not unrealistic to have over 30 Document Types, especially during an S/4HANA greenfield implementation. Again, it’s up to you as the customer how granular you make want to be, as there is a trade off between the number of document types and the maintenance of them.
You could have a Document Type per WRICEF type, so ZFSDW – Workflow, ZFSDR- Report, and so on, so that you could report on each development area, such as; “I want a status report of all the Enhancements in the HR Stream” – Which is perfectly and easily doable within Solution Documentation.
Each Document Type requires a template to be attached. For example, you need to create a new Functional Spec (ZFSD) for an Enhancement object to be built during the project. When users go to create the FSD, they chose to create a new document, using the Document Type ZFSD, users are then presented with the pre-agreed template, removing the need for PMO to hold the keys to project documentation and versions. It’s all managed centrally.
Why is that so powerful? Well, as the customer, you are in control of your documentation requirements – what do you want to be in the Functional Spec, for example, rather than having several versions of FSD’s, TSD’s, Blueprint docs…. If you multiply the number of document types, by how many templates you have from across your organisation, your SI and other partners, it can become unmanageable very quickly.
Tip: Having documentation reporting requirements would help to determine the strategy you take with the Document Types.
Moving on, lets take the ZFSD example and use it for the next area that the customer should design – Document Status Schemas.
Document Schemas allow you to predefine the document control mechanism, or the ‘flow’ for each Document Type. For example, you may decide that you want all FSD’s to be “Formally Signed”, (let’s go with ZFORMAL as the Document Status Schema name) which will be applied to all documents that meet the above criteria.
Here is how the ‘ZFORMAL’ schema for an FSD might look:
|Digital Signature Required?
|Approval 1 (SAP Team)
|Approval 2 (Business Rep)
Of course, this is a simple example. You will also need a process map to understand how the document flow will work, for example if you need to go back to an earlier review stage, if the approval is rejected! A Project RACI would also be useful…
A quick note on Digital Signatures – The user who is requested to sign-off the document, does so by inputting their SAP Solution Manager password, so the approval is tied to their user and is auditable from within the Solution Manager’s document history and available for document reporting.
So now you have a process hierarchy that defines how your business processes will be organised after the S/4HANA implementation. You have set of template documents, and a document schema that you can start to use with your implementation partner and of course, use yourself.
But why have you done all of this? – You now have a set of documents, reporting capabilities and a framework in place, that you can use with your implementation partner(s). For example, you can agree gating criteria, embedding your Document Status Schema within the process for project phase completion, which is usually backed by financial payments…
A specific example will hopefully help here; You insist that all Functional and Technical Specs must be 100% approved, before you let the code/configuration be transported into the QA system for further testing. So, in “project-speak”, the Formal Sign-off, of the FSD’s and TSD’s forms part of the ‘Test Phase – Gate Entry” criteria.
Having a tool like SAP Solution Manager’s Solution Documentation available, to quickly spin-up document status reports is extremely useful when engaging in gate exit and entry meetings with your System Integrator and partners, as you can imagine. It puts you as the customer, in the driving seat.
These examples are just options that are available to you, the beauty of these features is that it puts you in control of how you want your project documentation to be managed, and how it should be reported on.
If you have been through these types of major implementations in the past, you will know just how painful PMO reporting, document status reporting and a single source of the truth can be to maintain.
I have barely skimmed the surface of what you can do with Process Management and Solution Documentation, in SAP Solution Manager. You can customise the system with your own fields and attributes, so you can report on your entire SAP solution and the documentation that underpins it, in the way that makes sense to you and your projects.
I hope you found this article useful. If you still have questions, or need help with SAP Solution Manager, please get in touch with us via firstname.lastname@example.org.