All you need to know !
Ever since the publication of my last article on SAP Solution Manager 7.2 usage in S4HANA projects, I got many queries from all nooks and corner of the world from several Project Managers on the article and it's relevance for them. I would say Mission Accomplished ! , even if 1 in 10 of them managed to consider ALM concepts right from the project initiation. Over the last year, more and more Project Managers are getting educated and attempting ACTIVATE certification as I see from my LinkedIn feed . That is a good sign If you ask me. In recent years, SAP spent tons of money in campaigns and customer education summits to promote the usage of ALM concepts in customer landscape. Well, that was not the case few years back where the visibility of SAP Solution Manager was very bleak in SAP events. The one thing good that happened was the monetization plan for Focused Solutions, which gave a much needed breather and SAP had to bring SAP Solution Manager to spotlight inevitably. Eventhough, I am not sure how much SAP succeeded in making Focused Solutions as a standalone revenue stream and made any break even in that front. The Focused Solutions is becoming the part of standard offering (i.e license free) from 2020 Jan. onwards and they are being offered at a heavy discount for customers who want to use it now.
I am of the opinion that S4 Project Managers hold the key for the next breakthrough in ALM adoptions and how the Solution Manager would be perceived and adopted in coming years. The S4 wave is still strong and such business transformation initiative would give a fresh perspective to the as-is state of ALM tools and how they could be used in a better way in any new initiatives. The crucial role that holds the responsibility of customer education and internal team upskilling lies with the S4 Project Managers. As you could see I am still worried about the Project Managers who draft the SoW document with Solman as the "Early Watch Alerting" tool thereby shutting the doors for ALM concepts forever, at least until the go-live.
Now coming to the topic, the intention of this article is to narrate the type of queries I got and my experience in dealing with them . From the tons of queries I got over the last year, one thing still baffles me that there is a vast pool of Project Management professionals involved currently in S4 initiatives who are completely clueless or having wrong impressions of the capabilities of SAP Solution Manager as ALM suite. Broadly I would classify them into below categories for narrating my story;
i. The laggards types : This is the most common type of people I have come across. They are very late to the game, Period. These category of Project Managers would suddenly want to use Solution Manager to salvage the User Acceptance Testing or save the Quality system which is dumping form Transport related errors. Few google searches would give the half baked information on CBTA, and other non existent magical capabilities of solman . Thinking that SAP Solution Manager is the perfect tool for building UAT scripts thereby impressing the business users at the 11th hour. Well, that is not the case unfortunately. Solution Manager is not intended (at least as of now) to be used as the UAT tool also If your functional/dev team have already messed up the transport release and sequencing into Quality system, Solution Manager would neither magically fix the Transport errors in subsequent systems nor retrospectively handle the change management.
One very obvious reason for adopting solman so late would be the fact that Project Managers think, Solman Go Live happens in parallel with S4 Go Live. So I want to make things very clear here that Solman instance should be the very first thing to be installed on your project landscape and solman production system should be ready to use or "gone live" when you are about to close the Explore phase of the S4 Project.
ii. The 'good old days' or stick-in-the-mud types : Well, we must admit SOLAR01/02 are the things of the past. It was a long time back when solman and the 'document dumpyard' terms were interchangeable. Some of the fuctional consultants who were part of ERP/R3 implementations during last decade who are now heading S4 Projects as Project Managers have the tendency to relate the word solman to documentation dumpyard. This narrow understanding would eventually curtail the usage of solman to Process Management folders and TS/FS being uploaded as attachment to folders. So we now have "document dumpyard v2.0"
iii. Ambitious but not my job types: Many of the project managers who represent SI's in big ticket S4 implementations/migrations fall under this category because of their attitude towards solman usage in ongoing projects. It was very evident until recent years SI's followed "Don't Know-Don't Tell" policy in ongoing AMS engagements and implementation projects w.r.t solman usage. Since customer was mostly unware of the existence of the ALM concepts and solman as a ALM tool for their SAP landscape, these vendors had the upper hand in keeping customers at dark. Thanks to campaigns and events by SAP in recent years, more and more customers are now aware of ALM tools and their usage. The striking reality is S4 customers might not succeed in befitting unless they include the solman and it's usage as part of implementation contract with their implantation vendors. Because SI's always quote the contractual obligations and say "out-of-scope" for now and push it for production support phase. One thing customers have control and can do is, insisting on including ALM tools in the project plan.
iv. Over ambitious or let's do all types: This over enthusiastic type of Project Managers are not very hard to find either. The turn around duration for S4 projects have come down to few months from previous multi year timelines. Hence it is unrealistic to push the solman usage to the maximum extent in each and every aspects of the project. The reason for this ? most of the resistance for solman adoption comes from within the project team itself since project team members are burdened to the core on the shorter project timelines and things to do in such shot period. Hence when project managers bring the solman word in each and every communications and force project team members to use it fully, the enthusiasm dies down and team members start seeing it as a overhead to their daily tasks instead of value add. I have seen one instance where a project manager wanted to use CBTA for each and everything in S4 testing, so much so that functional consultants had to learn and automate & build CBTA scripts in solman dev system first then transport them to solman production for testing runs where it had tight integration with soldoc & charm with change control enabled branches in process management. As a Project Manager one needs to be realistic than idealistic in usage of solman features and how it is to be used during project phase.
So, as a ALM consultant , what do I think as the ideal usage of solman during S4 implementation which is practical and realistic? What a Project Manager should expect and act upon when some one ( read it as "customer" ) ask about ALM tools and their usage in ongoing project?
Well, I intend to bring this lean & realistic usage in series of blogs in coming weeks hoping to educate more and more existing and future S4 Project Managers. Stay Tuned !
This is a story about a fictional project manager, Kumar, in an ideal world who used SAP Solution Manager 7.2 platform for the life cycle management of S/4Hana implementation. This story narrates how Kumar managed customer's S/4 Projects with SAP Solution Manager 7.2 in it's full potential . Knowingly or unknowingly, proposal submitted to S/4HANA project had that ONE SLIDE of solution architecture diagram which had solman depicted as some cross platform stuff in random places ! (personally, I have seen 3-4 version of S/4 Solution Architecture diagrams by different SIs, each with very imaginative placement of solman in their slides, one even talked about using MOPZ.. yes MOPZ in 2018 for S/4HANA!!)
Coming back to the story; before the project initiation, Kumar had the classical Project Manager's dilemma typical to to-be Project Managers of a S/4HANA engagement ;
Should I tell customer about SAP Solution Manager 7.2?
What if customer is already aware of it and what should I do if they ask me to use it in S/4Hana Project?
If they ask for it, where should I begin? Whom to ask, what to read? How to use it?
Will I be forced to follow Agile way if I start using SAP Solution Manager 7.2 in S/4Hana Project?
What is this 'Solman Activate' or 'Activate Solman' that everyone talks about nowadays?
In the beginning, like many of the Project head responsible for S/4Hana implementation, Kumar too was confused about various jargon associated with Activate & Solution Manager 7.2. The first step he did was to join SAP Activate JAM group via invite ( http://bit.ly/SAPActivate) . Browsing through contents and discussions, helped Kumar to understand the basics of Activate methodology and how SAP Solution Manager could be used along the Activate phases. Kumar was an ardent fan of waterfall methodology and skeptic of Agile concepts; after researching through articles, he understood that SAP Solution Manager 7.2 can be used impartial of methodology chosen to implement S/4Hana. Kumar advised customer to use mixed bag approach where they use "Agilish Waterfall" methodology for implementation.
Chapter 1: Project Management
Now being aware of SAP Solution Manager as a delivery platform for managing S/4 Projects, he then got into self study mode and browsed through Project Management wiki (https://wiki.scn.sap.com/wiki/display/SM/SAP+Solution+Manager+WIKI+-+Project+Management) and decides to toss MS Project aside and use IT Project Management feature of SAP Solution Manager 7.2 to manage the project. It was a tough decision to make because in the initial days of using IT Project Management, he very much missed the simple intuitive screens of excel sheet and MS project. However he later acceded that having the end to end visibility and control over Project was more crucial than the 'look&feel' of Project Management tool existing in silo. Kumar browsed through Roadmap Viewer (https://go.support.sap.com/roadmapviewer) and downloaded the template Project Plan and imported it into Project Management module. He then created his own version of IT implementation project in Solman with phases and WBS elements as per his need. Kumar used template project as a reference to understand nitty-gritty of Project structure in solman IT Project Management module. Kumar used Resource Management feature to staff and forecast resource requirement for the duration of project. This helped Kumar to address some of the crucial questions, like below;
What is happening with my Project? Where do we stand as of today?
What are the open issues and risks to be discussed during weekly meeting? What is being done about them?
Upcoming Milestones & Project Schedule
How is the Resourcing looks like? Are we over staffed, under staffed?
How many Project Tasks are lagging behind? Which tasks are assigned to whom? ......etc
Chapter 2: Process Management
Now with Project setup in place in IT PPM module, Kumar turned his attention towards Business Process documentation. He knew solman could act as a repository where his team can upload project documents (like DMS or Sharepoint), however he was not much aware of other features of Process Management and how this feature is linked to other solman features. To start with this exercise, Kumar asked his Basis/Infrastructure team to setup a 'Solution' in Solution Manager. The idea of a 'Solution' is, it should act as a repository of Technical Landscapes in customer's SAP environment and the Business Processes which are run on these Technical Landscape. This solution would also act as a repository to store all Business Process related documentations that would be implemented in S/4 landscape. So Kumar realized that the true meaning of Business Process Documentation is not just dumping some files (word/pdf/xls) into solman, rather a holistic modelling of Business Processes in a clear cut manner. In order to jump start the Business Process documentation and to check what are the best practice business processes available with latest S/4Hana release, Kumar browsed through Best Practice Explorer (https://rapid.sap.com/bp) and imported suitable Best Practice content into the 'Solution' he earlier created. He learnt that when he imported Best Practice content into 'Solution', he got so many reusable templates, test cases and documentations of hundred of Business Processes. Now, Kumar has the S/4Hana Business Process list as part which came along the Best Practice content, but not the actual physical system where these Business Processes are run. So, in meanwhile, he ordered Software Appliance of latest S/4Hana release (http://www.sap.com/s4hana-trial) using which his Project team set up a Sandbox system. The purpose of using S/4Hana Appliance was to avoid initial setup needed to activate Best Practice Business Process content in S/4 Sandbox system. If they had used standard S/4Hana installation for Sandbox system, then Functional team had to use 'Solution Builder' (/n/SMB/BBI t code) to activate Best Practice content in S/4 Sandbox system. This was avoided by using ready-made appliance system instead. Now Kumar could relate the Business Process structure of Best Practice import in Solution Documentation with the actual Business Processes run in the S/4 Sandbox system as shipped via Best Practice content. This made him realize that actual Business Processes are configured and run on S/4Hana system and Solution Manager has the mirror copy of all documentations of these Business Processes.
Once his Functional Consultants are onboard with the idea od 'Solution' & Business Process Documentation, his project team used Sandbox environment as a 'Show & Tell' system to explore S/4 Business Processes and find out what is relevant for customer and which RICEFW objects would be in scope for development and enhancements. This exercise also helped customer to introspect on how their business processes are aligned with model processes used across industry best practices. For Kumar & his team, this scope validation workshop(also called Show&Tell workshop) helped to prepare a solid Business Blueprint document and foresee the deltas needed on top of Best Practice business processes. Keeping Best Practice processes as baseline, his project team worked through Business Process structure to make it relevant & customer specific process structure. Kumar & his project team then used the inbuilt BPMN 2.0 compliant process modelling tool Kumar then segregated the Business Process structures into various buckets (scopes) based on the business departments, this helped project team to breakdown the massive Business Process structure into functionally relevant, smaller chunks. This was crucial because using this approach Kumar could tell customer is What You See is What You Get ! (WYSWYG). This was a drastic change from standard ASAP where Business Blueprint got finalized without customer's real consent because customer never really imagined what they are gonna get at the end of a project !
This 'Sandbox S4 System + Business Process Documentation in Solman' approach helped Kumar to address some of the crucial questions, like below;
Where do we stand on Business Process Documentation as of today?
Are TS/FS completed for the Business Processes in question?
Do we have a clear buy in from customer on what Business Process to implement and their future state once implemented?
What is available as out-of-box S/4Hana Best Practice? How do we jump start the initial configurations?
Have we identified delta's and captured them against a Business Process documentation?
What are the standard Test Scripts and Documentation available for imported Best Practice processes?
How different/similar is customer's to-be Business Process compared to standard Best Practice processes shipped as part of S/4?
Have all the roles & responsibilities been captured and visually included as part of Business Process graphical view?............etc
Chapter 3: Release Management
In meanwhile, Kumar's Basis team has setup Release Management feature which contained the 'to-be' S/4 landscape and the transport request management track . In the absence of Solution Manager , Kumar used excel sheet and sharepoint to keep track of Transport Requests and their release sequence s. However it turned out to be messy because over the course of 7-8 months there were multiple copies of release sheet and nobody really knew what was happening with actual development and what is being updated in sheets.
Solution Manager release management provided track for the change request train to reach the destination. His team created a release cycle which basically a change release plan with tentative dates highlighted as per the project plan & milestones. This change cycle is then linked to the Project Management.
Chapter 4: Requirement Management
Kumar's project team used the Business Requirement and IT Requirement module to capture the standard configuration objects & delta configuration objects in the Process Management(Business Process Documentation) module. During the Scope Validation, his project team got clear picture on the RICEFW in scope and on what are the standard configuration objects in scope. So all Functional Gaps or extra enhancements needed are to be captured as 'Requirements'. They created the Business Requirement transaction and linked it to the Business Process structure via scopes & also to Project Management structure. These Requirement transactions are later used to generate Change Documents which would in turn act as container for Transport Requests. Now if Kumar looked at any Business Process Structure, he clearly found out below;
The Business Process Flow (Modular or End to End)
The Deltas and Gaps identified and how it is being handled?
The current state of handling these Deltas and Gaps via Requirement Management module.
Chapter 5: Change Control Management
Project team used the Change Request Management module to generate Change Documents which would have 1:1 relationship with the Requirements. These Change Documents then had Transport Requests inside them and movement of these Transport Request were governed by the Change Cycles. This provided overall control to Kumar on synchronizing the Transports and gave visibility on which Transport belonged to which original Business Requirement and in turn highlighting which Business Process it is linked to. Kumra's Functional team and Development team used the Transport Request number generated from Solman to save their configuration and enhancements. There were checkpoints set up for these consultants to make sure they uploaded and updated the TS/FS documents & Test Documents in Process Management as they prepare for the next activities in Quality Environment.
This helped Kumar to address some of the crucial questions, like below;
Which Transport Request is related to which Business Process configuration?
Are these Transports part of standard configuration or RICEFW objects?
What is the status of Development/Configuration activities as of today?
What about the Transport Sequencing and importing? Are they synchronized?
Chapter 6: Test Management
Kumar & team were looking for a automation tool for Testing stage of the Project. They came across Solution Manager Test Suite functionality (https://support.sap.com/content/dam/support/en_us/library/ssp/sap-solution-manager/processes-72/test-suite/test_suite_19.pdf) which would meet their requirement to have a end to end testing tool for the project. They also decided to use Solution Manager 7.2 inbuilt Test Automation tool, Component Based Test Automation(CBTA) to generate automated test scripts & playback. So Kumar created a Test Plan and linked it to the Process Management Scope. His ideas was to have lean test plans which represented the actual Business Departments of customer so that these test plans can also be reused for UAT purposes. Kumar's team recorded the SAP GUI,Fiori screens via CBTA frontend & created the Test Data variants . These automated Test Scripts were bunched together to for a Test Packages. Testers were assigned to these Test Packages. Testers executed the Test Scripts assigned to them and progress was tracked via central Testing dashboard.
This helped Kumar to address some of the crucial questions, like below;
How is Testing going on? How many Test Scripts are executed as of today?
How many defects are identified and what is being done about it?
What is the automation rate and how many of test scripts are manual?
Are test scripts linked to Business Process structure?
Summary: By adopting SAP Solution Manager 7.2 as the core platform for managing S/4 Projects, Project Managers can have end to end visibility and governance on project execution.
Be Like Kumar - Kumar is Cool !