SAC / BPC Solution Design, Activate methodology and Solution Manager

[Noel_Munday]

Use case

You are responsible for a new SAC / BPC project and you've been told by the PM that the ACTIVATE implementation methodology will be used to deliver the project. There are some new terms flying around the office as you mix with the S4 team like WRICEFs, WAVES, SPRINTS, WORK PACKAGES, WORK ITEMS and as always...BEST PRACTICES.

You are reasonably sure none of the above is going to have much impact on you as you whip out your trusty MS-Word solution documentation template and Excel sheets and prepare to find out to which sharepoint drive you're going to upload your docs. As for ACTIVATE you're pretty sure it is just a newly branded name for whatever was used before it.

However, just in case you get caught in a project meeting where you have to play boardroom bingo, you googled "SAC"+"BPC"+"ACTIVATE METHODOLOGY"+"SOLUTION MANAGER" and landed on this blog!

 

Did you know?

Here is a screen shot of a BPC business process model drawn up from scratch in a few minutes using Solution Manager 7.2. To the right you can see the properties pane of the diagram and at the bottom you can see an area where additional documentation such as your trusty Excel sheets and Word documents can be uploaded as supporting design documentation.

So here is the question: "Did you know this was possible?"

If your answer is "No" you should keep reading.

 

Problem Definition

One of the problems specifically related to delivering BPC projects, which will also apply to SAC, is that these projects differ significantly in delivery approach compared to ERP projects.  Often Project Managers (PM) who come from an ERP background try to apply the same concepts for standard business processes, fit/gap analysis and WRICEF identification to an SAC or BPC project but the reality is that everything in an SAC / BPC project is a WRICEF and even the term WRICEF does not fully cover all the developments required in BPC or SAC. (WRICEF = workflow, report, interface, conversion, enhancement, form)

Determining the effort estimates of a BPC / SAC project, drawing up specifications and delivering the project is closer to a development shop than configuring a standard implementation of the Model Company.

However, building a BPC / SAC solution is far from core development as the content is built on a very mature framework with insertion points for the User Interfaces, Business Rules, Reports, Data Integration and other use cases.

So how can we safely deliver BPC / SAC projects? How can we reduce the risk of under-estimating the effort required and then struggling to deliver the final product? How can we keep track of delivery so we can know well in advance of the go-live date if all is on track or not?

All of us have our own way of doing this with varying degrees of success but let me put one method forward using SAP Solution Manager.

 

USE CASES instead of WRICEFs

In an ERP project it makes sense that the general thinking about requirements follows this progression: Model Company / Best Practice --> Standard Business Processes --> Fit/Gap Analysis --> WRICEF list.

However, in an SAC or BPC project this approach is somewhat lost on us even though the SAC Content Innovation (CI) is now fast becoming highly compelling to use in a similar fashion as it makes no sense to develop everything from scratch when it's pre-delivered.

Standard business processes for planning and analytics (OLAP) just does not hold as much weight as it does for online transaction processing (OLTP).

So whether we are using SAC CI or Rapid Deployment Solutions (RDS) or any other best practice content to accelerate our project the output of our project planning is to obtain a list of the individual components of the system that needs to be built. In SAC and BPC we could list these components under categories such as:

1. Dashboards


2. Reports


3. Input templates


4. Stories


5. Data actions


6. Business rules - script logic, business rules, planning sequences etc


7. Data integration points


8. Data models


9. Business process flows


10. etc

It could be argued that these components can be classified into one of the WRICEF categories but the term "WRICEF" itself is used in ERP projects to denote "additional developments above the standard" which often leads to contractually higher costs, change requests and has very specific contractual implications besides the fact that WRICEF doesn't really cater for the definition of a components such as an SAC Story.

Let's rather use a more generic term from UML (Unified Modelling Language) as a collective noun for SAC and BPC components i.e. "USE CASES" where a USE CASE represents an action the system takes in response to an ACTOR. The USE CASE also represents the smallest part of the system we can specify, build, deliver and test as independent components of the overall solution.

USE CASES give us a CONTAINER into which we can bundle our system requirements. So instead of getting stuck at a one-dimensional functional requirement document we can specify both functional- and non-functional requirements into a use case. We can also manage the project at a slightly higher level than the detailed requirements and we can adhere to AGILE concepts where all the requirements and specifications are not needed before build starts so long as all the USE CASES are known.

So, in order to tie everything together in Solution Manager which we will use for solution documentation, system specifications, effort estimates and then monitor the project delivery via waves and sprints in work packages and work items, control transports and track testing statuses we need 3 key outputs:

1. Context diagram


2. Use case diagrams


3. Business processes

 

Context Diagram

The reason we start with a context diagram is because it defines:

1. How many systems we are dealing with and gives a name to each one


2. It defines the boundaries of each system


3. It defines the actors of the system

The context diagram can either be obtained in a white-board session with the client or derived from the service request but typically it will identify whether there is a BPC Consolidation System, BPC Planning System and/or SAC Solution etc and although it is typical that at maximum there will only be 1 of each of these system you should not simply assume that.

The next step would be to name each of these systems and again it's typical for a customer to simply refer to their "Consol System" or "Planning System" and these would be the names you attach to the identified system(s).

Once you've identified the systems and named them the next step is to identify the ACTORS which have direct system access to the systems. The reason we call them ACTORS and not USERS or ROLES is that an ACTOR could also include another system but typically we are looking for the individuals (USERS) of the system identified by their ROLE which will later become the authorisation concept of the system.

If we had a simple example of a BPC Planning System the context diagram might look something like this:

The context here is simply the middle square indicating the boundary of the system and "BPC Planning System" as the system name but I've also added associations for the main business planning processes within the system which can be seen of themselves to be "sub-systems".

You will notice that I've used Solution Manager to start the documentation process by following these steps:

1. Logon to Solution Manager with the Business Analyst role and select the Fiori tile "Solution Documentation" of the Focused Build add-on.

2. Under the "Design" branch of documentation create a business process folder for BPC under MODULAR PROCESSES with a SCENARIO for "BPC Context Diagram". Now create a UNIVERSAL DIAGRAM as an ELEMENT of the scenario by right-clicking in the area at the bottom of the screen to invoke the context menu and selecting NEW --> UNIVERSAL DIAGRAM.

 

Use Case Diagram

Once we have the context diagram, the USE CASE DIAGRAMS are the next most important artifact required for BPC / SAC projects as they define all the build components of the system.

With the list of use cases we can then organise them into the business planning processes (BP) and add any "non-use case" process elements to the business process diagrams.

To draw a USE CASE DIAGRAM we place the system as a square, the boundary, in the center of the page (which includes the name of the system at the top of the box) and use the ACTOR icon for each ROLE / TEAM which interacts directly with the system. These will form the basis for the authorisation concept of the solution. In a BPC Standard Model it will become the TEAMS and in an Embedded Model it will become a BW Role.

The USE CASES themselves are represented as ovals inside the box and have a very simple structure: they must include a verb (capture, post, unlock, calculate, approve etc) which represents the action which is taken on the system. So we have 3 key elements in the diagram...a role which is taking a certain direct action on the system.

So, for example, a manager who reviews an output report from the system, makes a business decision based on the report and instructs an operator to make a change to the system is not interacting directly with the system and is not part of the diagram. This type of action might form part of the business process diagram but it does not form part of the use case diagram.

At this stage of the system design we number the use cases and these will later become the WORK ITEMS in Solution Manager.

During the RFP process it is usually quite easy to request a pre-scoping exercise which could either take the form of a 2-3 days onsite workshop or simply a few online meetings to quite accurately determine the broad project scope based on use cases. The use case list often forms part of our SOW (Scope of Work) contractual obligation agreed with the client before the project even begins. This is a great way to control scope without having to go down to detailed requirements.

You'll notice that the functional- and non-functional requirements have not been specified yet and although each use case lends itself to be classified e.g. Input template, business rules etc. it is very possible to have a combination of these components in a single use case. For example, "REV010 Capture sales prices" seems to indicate that this is only an input template but it might turn out when the functional specifications are drawn up that determining the price includes a few planning functions to calculate VAT, taxes, discounts, escalations etc. So use cases provide us with a certain level of abstraction with which to scope and manage a project without getting stuck in the detailed requirements. It lends itself to AGILE development methodologies because you are able to defer detailed technical specifications until the time you are ready to develop.

The tool I used to produce the diagram is "Enterprise Architect" from Sparx Systems (https://sparxsystems.com) but you can of course use the Universal Diagram in Solution Manager itself or any other tool.

You can then upload your use case diagrams to Solution Manager in the folder for your project BPC scenario.

 

Business processes

The next step is to document the business processes in Solution Manager by organising the use cases into process steps and adding any "non-use case" steps to the flow.

We start by creating business processes under the "BPC Context Diagram" scenario in the BPC folder in Solution Manager. Right-click --> New --> Process.

 

With the correct process selected ("BPC Revenue Planning") right-click in the "Elements of 'BPC Revenue Planning'" at the bottom of the screen and create a new PROCESS DIAGRAM.

 

Now capture the business process making sure to incorporate all the use cases identified in the use case diagram. You can include the use case number as a cross reference. Before you can start adding process steps you will need to add the ACTORS to your list of available ROLES so that you can select them for the SWIM LANES of your process. You do this by selecting the "Lane" icon from the palette and adding the new role in the input text box provided and selecting the "+" sign. The new role will appear in the list below. If the "+" sign is greyed out you will need to obtain the correct authorisation to make changes i.e. check auth object SM_GAL_GO in the SAP_SM_SL_ADMIN Role for Activity 01 and GAL_OBJTYP "Role".

 

After you've completed the business process it should look something like this:

 

You'll now notice after saving and exiting the process diagram that the individual process steps have been added automatically to the "BPC Revenue Planning" business process. In addition each process step can be selected and at the bottom of the screen additional ELEMENTS can be added to the steps. This will be the placeholder for further detailed functional- and non-functional- documentation for each step (use case). In the properties pane of the individual process step you'll also notice the ability to assign:

1. Requirements


2. Work packages


3. Work items


4. Incidents


5. Request for change

 

So in summary the business process with the individual process steps sets the system up with a framework of the scope of work against which the detailed requirements can be documented and once documented the entire solution can be built and tested and deployed.

 

Requirements

At this stage of the design process the business analyst wants to fill in all the requirements to the lowest level of detail so they can hand over the documentation to the solution architect for technical design, resourcing and effort estimates.

After the requirements have been specified the documentation should be good enough to hand over to a developer for development without needing further clarifications.

We use the REQUIREMENTS in Solution Manager to document this detailed level of design.

We can register more than one requirement in Solution Manager per process step (use case) but as a general rule we try to keep the ratio as close to 1-to-1 as possible.

In our example of the "BPC Revenue Planning" process and in particular, capturing the sales prices, I've decided to add more than one requirement for the process step. So let's assume capturing prices is not a simple process. Let's assume there are two Excel workbooks, one for capturing PRODUCT sales prices and one for capturing SERVICE LINE sales prices and in each workbook there are  multiple worksheets for the various products and service lines and let's assume a business rule is required to escalate the prices over monthly periods.

In this case we would have one PROCESS STEP = "REV010 Capture sales prices" but we can create three REQUIREMENTS in Solution Manager:

1. REV010_01 Capture product line sales prices


2. REV010_02 Capture service line sales prices


3. REV010_03 Calculate periodic price structure

Before we create the actual REQUIREMENTS in Solution Manager we first conduct our client workshops and compile our detailed documentation so it is ready to be uploaded to the system. Usually this takes the form of a leading MS-Word or PDF document supported by any other documentation that is deemed necessary. Example:

 

Now in Solution Manager we create the REQUIREMENT by selecting the process step and the hyperlink to the REQUIREMENTS.

 

The REQUIREMENTS MANAGEMENT screen opens with a filter set to our process step "REV010 Capture sales prices". Select the REQUIREMENT --> CREATE NEW REQUIREMENT in the bottom right corner of the screen.

 

Now add the first requirement related to capturing the sales prices for product lines. Set the classification to WRICEF and mark it as a FORM.

It's important to note that here you must upload a supporting document using the BROWSE button at the bottom of the screen. This does not need to be done right now but in order to move the REQUIREMENT from it's DRAFT STATUS to APPROVED the attachments will be needed. REQUIREMENTS are the first line item working document of Solution Manager similar to a works-order. They attract a system generated document number and provide a link into the project management project plan by later assigning them to work packages and work items which roll up into the sprints and waves of the project plan. They also provide the link into the test suites when we begin to develop. So REQUIREMENTS are the back-bone to the entire Solution Manager system.

 

Once you SAVE (icon at bottom right) you will return to the REQUIREMENTS MANAGEMENT screen and your new REQUIREMENT will be visible in the line items at the bottom half of the screen. You'll notice the newly assigned REQUIREMENT DOCUMENT NUMBER.

 

Now add the remaining 2 requirements so that when you are finished you can see the 3 requirements linked to the one process step.

 

When you return to the SOLUTION DOCUMENTATION screen you will now see that there are 3 assigned REQUIREMENTS attached to the PROCESS STEP (use case).

 

Managing the entire solution

If we now access the Solution Manager "SOLUTION READINESS DASHBOARD" we can start getting a birds eye view of the BPC / SAC solution as a whole. Note that in order to use the DASHBOARD we must first create a PROJECT so we can link the artifacts into the project in order to manage it.

A key milestone in any project is the APPROVAL of the design. It's not simply enough to hold workshops, document requirements and upload them to a shared drive. At some point the design needs to be presented back to business, show-and-tell sessions take place and formal approval is obtained before any physical development work can begin. Usually this also takes place at two levels, firstly at a business requirements level and secondly at a technical design level via a design authority committee. So the REQUIREMENTS status block at the top left of the dashboard indicates the scope and progress of REQUIREMENTS:

1. Unassigned


2. To be scoped


3. In progress


4. Completed

You can now also see that both an AGILE or WATERFALL project methodology can be applied to the solution delivery. In a WATERFALL project methodology it simply means all the REQUIREMENTS, FUNCTIONAL SPECIFICATIONS and TECHNICAL DESIGN must reach a COMPLETED status before DEVELOPMENT takes place and all development must be complete before TESTING and DEPLOYMENT take place.

In an AGILE project methodology it is only the SCOPE of the project which must be complete before continuing with next steps and we control scope via our USE CASES / BUSINESS PROCESS STEPS. In a BPC or SAC project there are also design considerations such as data modelling which lend themselves to needing visibility of the entire solution before they can be agreed upon but this does not totally prohibit applying AGILE methodology to these projects. There are certainly aspects of the solution which can be specified, developed, tested and deployed without the entire solution needing to specified - so AGILE principles can apply.

So once we are on track with our solution documentation we can create our PROJECT and link it to the documentation via the REQUIREMENTS.

However, now you can also see where we are heading. Not only do we want to scope and document our solutions requirements but we also want to drive the entire delivery of the solution via a project. By ensuring we work with USE CASES the right granularity of project management is created in order to track REQUIREMENTS, FUNCTIONAL- and TECHNICAL SPECIFICATIONS, progress of DEVELOPMENT, the status of TESTING and DEFECT RESOLUTION of each use case and ultimately managing the actual TRANSPORTS through the client landscape for DEPLOYMENT.

 

Next steps

In a followup article we will cover the PROJECT MANAGEMENT aspects of delivering the solution and cover the topics of solution releases, activate methodology, project phases, waves, sprints, development, testing and deployment.