Implementation of SAP S/4 HANA (Greenfield, Brownfield or Bluefield SAP S/4 implementations) by Ulhas Kavle
SAP ECC versus the SAP S/4 HANA
A comparison between SAP ERP & the SAP S/4HANA product:
R/2 to R/3 to ECC to SAP HANA on ERP to SAP S/4HANA:
Between 1979 and 1992, SAP ran the R2 version of SAP, which had one single system running on mainframe that included all the layer (presentation, application & database layer), which meant that companies could only afford to have a few localized systems across various locations used for recording the work. SAP was popular since the installed software had the necessary business integrations between various supply chain and finance modules, i.e., orders created in sales could be converted into production order or purchase order, goods are received in stock and data is integrated with finance for invoice processing and account postings,
Between 6th July 1992 to 2004, SAP ran the R/3 version of SAP, which brought in a big change in the architectural setup, i.e., SAP made use of the 3-tier client server Architecture (where R stood for real time and 3 stood for the 3-tier architecture). This new architecture was compatible with multiple platforms and operating systems such as Microsoft Windows and UNIX, making SAP easier for implementation across multiple customers. The 3-tier architecture is explained as below:
Presentation server layer - Front end devices laptops, desktops, mobiles,
the Application server layer - all front-end devices connect to the application layer to access the SAP application, and this is where all the transactions are executed,
and the Database server layer - the application connects to the database layer in which the data is stored once the transaction is saved, the database server to which the application is connected to can be kept in data centers connected through the internet,
In 2004, SAP came out with the SAP ERP central component (ECC) (SAP ECC 5.0 ERP was the successor of SAP R/3 4.70) which brought in newer ERP components and brought in simplifications in accounting and logistics like New GL which is a prerequisite for new asset accounting. In SAP ECC, FI GL accounts are mapped to CO primary cost elements. In S/4HANA, the structure of the universal journal is used to store both GL account and cost element.
The newest version of the suite is MySAP 2005 or SAP ECC 6.0. SAP ERP 6.0 was released in 2013. SAP ECC means SAP ERP central component. SAP ECC is a core component within the SAP's Business Suite (a collection of applications including SAP CRM, SAP SCM and others alongside the ECC components)
SAP ECC 6.0 is built on the SAP NetWeaver, an integration and application platform which provides a foundation for all SAP software solutions. SAP NetWeaver includes a wide range of technologies and tools that allow SAP software to run on a variety of hardware and software platforms. Software is even more user-friendly than previous versions of SAP software,
Between 1979 and 2010, SAP ERP Software grew multiple folds using the classical relational databases like DB2, Oracle, SQL Server and SAP Max DB, IBM,
In 2011, SAP released its own database called the HANA (HANA - High Speed Analytical Appliance), database, which was deemed to be faster with the in-memory data storage, lot of companies started implementing the SAP HANA database on their existing SAP ECC landscape (SAP ECC Business Suite on HANA)
By 2005, SAP realized early in the game, that with the cloud age and the digital age, factors like speed, innovations, integrations, & user experience would become important, thus in 2015 SAP released a new product called the SAP S/4HANA (SAP Business Suite 4 for SAP HANA) which made a complete use of the HANA database, i.e., the in-memory architecture database, which it had rolled out in 2011.
SAP S/4HANA:
SAP mentions that it changed more than 400 million lines of code in the SAP ECC or SAP ERP product so as to make a complete use of the HANA database, thereby offering the concepts of:
SAP S/4HANA In-memory data storage concepts allows the frequently used data to be stored in the in-memory layer of the database and the non-frequently used data in its disk layer, thus saving the time to retrieve the frequently used data. The HANA database automatically arranges data in the in-memory and the disk tiers,
SAP S/4HANA also provides a simplified data model, by combining multiple tables of similar types, eliminating the concepts of table indexes, aggregates and redundancies, storing the data in tables in columns rather than in row, thereby reducing the data footprint and providing much more faster computing and analytics capabilities,
SAP S/4HANA also combines the high-volume real time analytical processes (OLAP) and high-volume transaction processing (OLTP) based on unified data model without the redundant data layers required in a typical RDBMS based systems,
SAP S/4HANA also offers a function based, role based & tile-based SAP Fiori’s UX, which eliminates the SAP GUI, and it is designed specifically to be highly intuitive, personalized, responsive, and simple, which allows users to prompt questions and access required details, regardless of device or deployment. SAP Fiori is a simple and role-based user experience which is a collection of commonly used S/4HANA functions that are displayed in a simple, consumer-ready tile design and can be accessed across various devices, including desktops, tablets and mobile devices.
Along with the database architectural changes, SAP has also brought in the best practices approach for a range of industries/businesses which would enable companies to rethink of their existing overly modified or customized business processes and provide an enabler to move them towards a more standardized and modernized approach of doing business,
There are variety of new features that SAP brings in, like combining SAP customers and vendors into a single master called "business partner",
With a faster and a more real time environment, use of the concepts such as internet of things, big data, machine learning, AI, can actually be realized much more easily. SAP S/4HANA is natively connected to the Internet of Things and business networks for real-time collaboration (planned: machine-to-machine, Ariba Network, Concur) in the networked economy,
SAP S/4HANA In-Memory Database and Simplified Data Model:
The SAP S/4HANA database and the simplified data model, allows customer to work with a larger data set in one given system rather than worrying about archiving and worrying whether it would slow down the system like in the case of SAP ECC thus reducing the TCO - total cost of ownership by reducing the hardware and operational costs. The speed of the system & the speed of data retrieval brings in the power of real time simulations, for example simulating MRP in real time mode rather than wait for hours for the batch job to complete (sometimes overnight); the access of in-memory data tier allows such speeds, this reduction of the data footprint is achieved by:
automatically compressing data tables so that you can store larger data set in the same space, by removing unnecessary tables, indexes, aggregates and redundancies, used in classical relational databases to achieve faster run times, for example in SAP Simple finance the number of database tables were reduced from 17 tables to 4 tables,
the in-memory data footprints are also reduced by implementing data aging strategies. SAP automatically divides your data in to 2 sets:
current data or recurring used data into an in-memory or hot storage tier, (may be your last 2 -3 years of data),
and your historical data into a disk-based tier or warm storage,
The data that is used less frequently is moved automatically from the hot storage tier to the warm storage tier; the in-memory data tier is thus only filled with data that is frequently used and is more useful for immediate retrieval. The Historical data is still available whenever you want to retrieve that for reports or investigations,
SAP S/4HANA Product development chronology:
In 2014 SAPPHIRE NOW, Orlando Florida, the SAP Simple Finance solution was released,
In 2015 SAP announced its wish to expand the core of the solution to become a full-scale enterprise resource planning platform, and named the suite SAP S/4HANA, with specific core lines of business tacked on to the end of the suite name (i.e., SAP S/4HANA Finance),
In 2015 (3 February 2015), the new suite, SAP S/4HANA, launched on at the New York Stock Exchange. The event introduced cloud and on premises editions, with the on-premises edition becoming available on the same day,
In 2015 (6 May 2015), the cloud edition went live at SAPPHIRE NOW (SAP’s annual customer conference) on 6 May 2015 in Orlando, Florida, [6]
In 2016, the logistics functionality was introduced to SAP S/4HANA:
Sourcing and Procurement,
Manufacturing,
Supply chain,
Asset management.
Embedded extended warehouse management (EWM),
Embedded production planning/detailed scheduling (PP-DS) functionality directly into SAP S/4HANA,
In 2017, SAP added machine learning capabilities to the suite in 2017 in order to perform easier goods and invoice receipt reconciliation and to automate invoice assignments,
In 2017 September, the transportation management functionality was embedded in SAP S/4HANA,
In 2018, predictive accounting functionality was added, and subsequent releases of the solution included additional intelligent technology enhancements in the areas of artificial intelligence, blockchain, and the Internet of Things,
In 2021, SAP released multiple industry-specific offerings of SAP S/4HANA:
energy and natural resources,
service industries,
consumer industries,
discrete industries,
financial services, and
public services,
Offers Industry Specific line of business,
SAP Simplification list, shows all the differences between the old and the newer of SAP
help.sap.com & search for simplification list to get the SAP S/4HANA (for latest version)
SAP S/4 Deployment Options
SAP S/4 Deployment Options - On Premise Deployment
S/4 HANA On Premise Deployment option:
On Premise:
The SAP On Premise option is the most loved option since it has been used the inception of information technology, it is close to everyones heart,
In this model, the customer acquires a license and installs the software in their own data center (customer purchases software and hardware (servers), manages and maintains the operations by themselves) or it can be run on one of the IaaS offerings by an hyper-scaler like AWS, Microsoft or Google,
On Premise option is typically opted by customers with high complexity landscape or customer working with sensitive or highly secured data
System conversion (Brownfield or Bluefield implementations) cannot be hosted on a cloud and customers have to go in for an "on premise" option,
SAP S/4 Deployment Options - Public Cloud Deployment
S/4 HANA Cloud Deployment option:
Public Cloud:
Public cloud is an option for companies which run on standard business processes,
Customers willing to go with a clean slate with a "Greenfield implementation" can make a complete use of the SAP S/4 public cloud option, opting in for the latest and best standard SAP business processes (best practices) and willing to sacrificing their existing investments made on their existing custom SAP ERP solutions (sacrifice "Z" or "Y" solutions). The option to go ahead with the SAP best practices or standard solutions, can lead to savings in the long term since there is zero cost of maintaining custom design or custom solution investments in public cloud (since custom design is not an option in public cloud),
In the Public Cloud model, the customer rents the software for a certain period of time. SAP deploys the software in the SAP-owned data center,
Public cloud SAP software typically runs in a multi-tenant server, where multiple tenants, or customers share the resources of the server., this is similar to an apartment building where multiple tenants live within the same physical infrastructure and each of them have their own key to their own apartment (room). Maintenance of the building is factored in the rent that the customer pays. customer specific data and applications which are executed and stored within the apartment are secured within that apartment room and are not available or shared with other customers,
SAP provides 2 major releases annually, providing standard enhancements to existing standard functionalities. If a new business process or enhancement is released, a customer can choose whether or not to activate the process in their systems for their business,
SAP delivers new features monthly, in the SAP S/4 HANA cloud edition (Continuous Feature Delivery - CFD); the customer can again choose whether to turn on or use these features for their business,
SAP S/4 HANA Cloud ERP is a software as a service (SaaS) solution that provides the industry capabilities companies require,
SAP S/4HANA Cloud, private edition provides the full SAP S/4HANA functionality while offering the highest flexibility and extensibility options running on a hyperscaler infrastructure,
SAP S/4 Deployment Options - Private Cloud Deployment
S/4 HANA Cloud Deployment option:
Private Cloud:
Private cloud SAP software runs in a single tenant server, where only a single tenant (customer) uses the resources of the server. Software runs in a private network protected by a firewall, similar to an on-premise system. The main differences between private cloud and on premise is who has responsibility for maintaining the server, and the license for the software installed on the server. For private cloud, a third-party provider owns the server and is responsible for maintenance and running our services. A customer pays a subscription fee to access the server over the internet and install software. In some cases, one cloud provider maintains the server, and another provider maintains the software installed on the server.
Companies who want to preserve their custom solutions opt for SAP system conversions from existing SAP ERP to SAP S/4 HANA. A complete use of the S/4 HANA solution and innovation is taken at their own speed by the customer. SAP system conversion is possible in SAP on-premise or in SAP s/4 HANA cloud private edition,
For example, with SAP S/4HANA Cloud, private edition, SAP is responsible for maintaining the business software, but the customer can choose to have their software on a server in an SAP data center, or a server in a data center from one of our hyperscaler partners like AWS, Azure, Google, etc. In this case, the hyperscaler partner is responsible for maintaining the server.
Private clouds offer more flexibility and customization than public cloud. If public cloud is an apartment, private cloud is a single-family home on a plot of land.
Cloud software is delivered "as-a-Service", where a consumer of the service is billed on a subscription basis for what they use. The subscription-based digital model is highly flexible and agile because you can easily scale up or down as needed.
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Software as a Service (SaaS)
The following graphic explains and differentiates On-Premise, IaaS, PaaS and SaaS:
SAP S/4 Deployment Options - Hybrid Deployment
S/4 HANA Hybrid Deployment option:
Hybrid
In this model, required applications are operated partially by the customer and partially by SAP in the Cloud. Both parts can be linked and integrated with each other,
Mobile
In this model, mobile devices access On Premise, or Cloud applications,
SAP RISE (RISE with SAP)
Both Public Cloud and Private Cloud editions can be enrolled in SAP RISE,
Accelerates SAP S/4 HANA Cloud adoption,
License cost
SAP Hosts in Hyperscaler
SAP S/4 HANA Migration Strategies & Methodologies
3 Different Ways to Implement SAP
Brown-field Implementation - (On Premise & Private Cloud)
Convert Existing SAP ECC System to SAP S/4 HANA on premise & SAP S/4 HANA Private Cloud
Start from an SAP ECC 6.0 EHP 8, Any database. EHP Upgrade is a pre-requisite project,
Bring system to Unicode or Single Stack, if on dual stack of ABAP & Java- can be an expensive project to move to single stack,
Bringing system to SAP ECC 6.0 and EHP 8 with Single stack can be expensive than a green field project,
Start with SAP FIORI user experience (UX) to access SAP S/4 innovations,
Retains / Preserves Current Solution investments, due to existing complexity,
Fails to drive & adopt innovations & SAP Best practices that come with S/4 HANA, right from day 1
Implement S/4 HANA innovations and new business functions at your own pace in phases, mostly post conversion - Results in Fit to Gap leaving less chances to standardize,
Retain Historical Data & convert to new S/4 data model from SAP ERP data model. Can start with no data & archive existing data,
Custom-code Remediation for existing RICEFW to bring to SAP S/4 standards,
Complex landscape with very high number of interfaces to 3rd party systems and want to keep existing integrations,
Big Bang Go-Live - entire landscape, all units and regions go-live together,
Simple, can be Complex,
Economical, if done right
Faster time to Value,
Blue-field Implementation
Convert & consolidate multiple SAP ERPs to one SAP S/4HANA on premise & SAP S/4 HANA Private Cloud
Start from an SAP ECC 6.0 EHP 8, Any database. EHP Upgrade is a pre-requisite project,
Bring system to Unicode or Single Stack, if on dual stack of ABAP & Java- can be an expensive project to move to single stack,
Bringing system to SAP ECC 6.0 and EHP 8 with Single stack can be expensive than a green field project
Start with SAP FIORI user experience (UX) to access SAP S/4 innovations,
Retains / Preserves Current Solution investments, due to existing complexity,
Fails to drive & adopt innovations & SAP Best practices that come with S/4 HANA, right from day 1
Implement S/4 HANA innovations and new business functions at your own pace in phases, mostly post conversion - Results in Fit to Gap leaving less chances to standardize,
Convert one of the systems and then load configurations, historical master data and open transaction items data from other systems
Customer chooses to Select Historical Data & convert to new S/4 data model. Can start with no data and archive existing data,
Custom-code Remediation for existing RICEFW to bring to SAP S/4 standards,
Complex landscape with very high number of interfaces to 3rd party systems and want to keep existing integrations,
Can migrate individual business units or regions sequentially
Medium Complexity,
Can also be Expensive,
Medium time to Value
Green-field Implementation
Brand new or fresh slate Implementation on SAP S/4 HANA on premise & SAP S/4 HANA Public Cloud
No Initial State required. Can move from non-SAP legacy or SAP legacy with an will to simplify,
Initial ABAP State is not a criterion, since Fresh implementation and a fresh SAP S/4 HANA already has unicode,
Fresh implementation can reap the benefits of going back to standard & reaping the advantages new innovations,
Green-field implementations already starts with SAP FIORI UX,
Past Solution lost & forgotten, start afresh to adopt innovations & simplicity,
Succeeds in adopting innovations & SAP Best practices that come with S/4 HANA
Build with SAP standard content (Best practices package with preconfigured business processes) - Results in Fit to Standard (may be minimally approved business gaps),
Customer loses Historical Data, starts with fresh data collection, cleansing & conversion in new S/4 HANA data model. Archive existing data,
New RICEFW are anyways in SAP S/4 coding standards, but mammoth task,
Ready to redevelop all integrations & simplify the landscape. Want to use latest innovative integration tools
Can migrate individual business units or regions sequentially
Is Complex,
Expensive, multi year plan
Highest time to Value
SAP S/4 Activate Discover phase
Equivalent to SAP ASAP Methodology - Preparation Phase
- Customer works with an IT partner (preferably) to understand SAP S/4 HANA
- Customer understand at an high level how SAP can address and simplify their current day painful and complex business processes
- Customer is provided with a trail system to research
- Customer clears their mind on single instance or multi instances of SAP & which industry solution should be adopted
- Customer understands the SAP implementation methodology (greenfield, brownfield, bluefield)
- Customer gains an idea about cloud, on premise, RISE
- Preparation of an highlevel roadmap & budget
- Customer engages with a final implementation partner (awards deal)
the Discover phase is where the customer realizes there is a need for a solution to satisfy their business pain point and starts looking out for the right SAP solution to map their requirements,
to start their digital transformation, the discover assessment provides an opportunity for the customer to get more understanding of the S/4 HANA system. During this phase a SI partners or implementation partners help the customer understand the S/4 environment and its features/functionalities and provide a high level mapping and introduction to how these new features/functionalities, can help the customer achieve more. The customer is updated with what new standard functionality can help eliminate the old monterious custom programs and how the business processes can be streamlined and/or automated as a part of this transformation,
a high-level understanding of all the future state satellite systems or connected systems or externally integrated systems, is also acknowledged, i.e., which satellite systems would stay, which can be eliminated through standard features of S/4 HANA,
the customer also understands the high-level gaps that would still remain even after S/4 and pictures on how they can be resolved
if the implementation is a multi year greenfield implementation and the approach is to golive regional, then it is also true that the existing SAP ECC system is run in parallel and a "dual maintenance plan" has to be thought about in the "explore phase and detailed out in the "prepare phase"
a though process is initiated whether, the SAP system can be moved to cloud or should remain on premises and whether the SAP RISE approach should be adopted,
SAP also offers a free trail system and try out by themselves, rather being dependent on the SI partner or the implementation partner,
the discover phase enables the customer to understand the required future end state and where they would land in terms of features, functionality and benefits,
a high-level roadmap and a high level spend is also estimated at this point in time
the discover phase not only allows the customer to be impressed with SAP S/4, but can also allow the Implementation partner to impress the customer and show how valuable they can be or how helpful they can be for the customer in this digital transformation journey,
this phase is true for SAP S/4 Greenfield, Bluefield and Brownfield implementations,
it should be noted that for a bluefield or a brownfield implementation, SAP recommends to run the SAP readiness check, in the "discover phase", which is an all-in-one single dashboard check that provides all the checks that are checked by the maintenance planner check (add-ons and business functions check), simplification item check (key differences between ECC and S/4) and customer code planner checks, memory and disk size checks, etc., The readiness check is done way ahead or early in the game, so that the customer gets an idea of the work involved. These checks are done even before all other checks (checks done in the source ECC system),
to execute the discover phase, the customer may float an RFP, which would allow them to bring in the best out of the competition,
this phase is not executed in agile fashion,
as an outcome of the prepare phase the customer would definitely understand whether they should go in for a green, blue, or brownfield implementation (would decide the type of implementation),
another outcome is awarding the transformation or implementation to best deserved implementation partner who has recommended or presented the best solution and who is well equipped to execute the program,
the customer/business users can prepare a business case and draw out a high-level roadmap,
SAP Activate Prepare Phase
Equivalent to SAP ASAP Methodology - Preparation Phase
- Customer and partner onboards the complete implementation team including test, data, security and OCM teams
- Detailed Project plan with a governance and communication structure is prepared
- KPIs, Risk register and escalation Matrix in place
- Test strategy, Data strategy, OCM strategy, Security strategy in place
- SAP S/4 HANA Sandbox in place, with access to consultants and key users
- For Brownfield and Bluefield implementation, it is required to run and correct the relevance/compatibility/errors,found in the simplication item check, maintenance planner check (add-ons & business functionalities), custom code check, sizing check, without which the system conversion is not possible in the explore phase
- A Few important preparations steps before going in to an implementation or a conversion is the customer vendor integration (converting them in to business partners)
staffing for the complete project team (both customer and implementation partner teams) is initiated during this phase, like the program leads, managers, technical consultants, functional consultants, Basis consultants, security consultants, test team, data team, OCM team members,
set up the initial system - sandbox SAP S/4 system after signing a contract with SAP,
establishment of a project office at a central and regional locations,
establishing a project governance and communication structure starting with an organizational structure (stakeholders) and a RACI Matrix,
defining a clear and detailed scope along with a detailed project plan,
defining a Project risks, assumptions, escalation matrix,
estimation of the project budget
define key project KPI's to track the transformation,
business process owners fill in the "business driven configuration assessment questionnaire", this enables the capturing of initial high-level business requirements. This questionnaire is readily available for use
business user or customer IT team trainings are also initiated during this phase, so that the customer comes fully prepared in the next phase, the "explore phase",
define a clear test strategy approach and plan,
define a clear data strategy approach and plan,
define a clear user training strategy and plan,
define a clear OCM (Organizational Change Management) strategy approach and plans,
if the implementation is a multi year greenfield implementation and the approach is to golive regional, then it is also true that the existing SAP ECC system is run in parallel and a "dual maintenance plan" has to be thought about in the "explore phase and detailed out in the "prepare phase"
it is equivalently important to engage test, data and OCM teams from phase, so that. these teams can start early and understand and recommend early rather than later. Projects who bring in test, data & OCM team later in the game face the possibilities of realization of issues, errors, changes and delays as the project progresses,
this phase is true for SAP S/4 Greenfield, Bluefield and Brownfield implementations,
during the prepare phase, for the brownfield and bluefield implementations or the so-called system conversions (on-premise only), various systems checks are made in the SAP Business Suite itself (SAP ECC/any EHP/unicode ABAP Stack/ABAP single stack/any DB) like "readiness check", "maintenance planner check", "simplification item checks", "custom code preparation check" and "HANA sizing check". These checks notifies us of relevancies, errros, incompatibilities even before the system conversion is executed using the software update manager (SUM). The system conversion SUM process does not proceed if these checks are not resolved,
you can re-run the SAP recommended SAP readiness check again, which is an all-in-one single dashboard check that provides all the checks that are checked by the maintenance planner check (add-ons and business functions check), simplification item check (key differences between ECC and S/4) and customer code planner checks, memory and disk size checks, etc., The readiness check gives an high level idea to the customer of the work involved in the implementation. These checks are done even before all other checks (checks done in the source ECC system),
readiness checks provide a good idea, or it just provides an information for things that are expected during the conversion, this check does not allow to make changes or to correct errors as this is just a tool used for planning. The outputs of the readiness check, i.e., the errors/warnings of the readiness are not a showstopper for the SUM conversion tool (while the errors from the maintenance planner, simplification item check are a showstopper for SUM conversion),
simplification item lists demonstrates what has changed between ERP & SAP S/4 HANA. New functionalities which are added, like Customer-Vendor integration (conversion to Business Partner in the source system itself). The SAP "readiness checks", the "customer code analysis" as well as the "simplification item checks" are all based on the simplification item list. SAP recommends running the simplification item check through the readiness check, so that the customer can check only relevant simplification items for your project rather than going through thousands of items in the list (even those which are not relevant for the project). It is required to resolve all the errors before the actual SUM conversion,
the maintenance planner check helps to define relevant and irrelevant components, add-ons, industry solutions and business functions in SAP S/4 HANA. For an add-on, which is not certified by SAP yet, needs to be either replaced with an add-on which is compatible with SAP or we need. to evaluate whether. the functionality provided by the add-on is already a part of the standard SAP S/4 HANA system. Any 3rd partner irrelevant add-on (unsupported/not-certified add-on) can be uninstalled by the maintenance planner. It is required to resolve all the errors before the actual conversion (SUM conversion). The maintenance planner creates a stack file which is used by the SUM during the actual conversion step,
the custom code analyzer, can be initiated through remote ATC (ABAP Test Cockpit) checks through a SAP S/4 HANA installed in the sandbox. Some of your custom code objects may not be valid anymore and they may not not perform as expected or produce syntax errors or dumps (these are red error objects). You almost certainly have other objects that do perform as expected and do not need to be changed (green objects). SAP provides tools, based on the Simplification Database, that detect any custom code that needs to be adapted to SAP S/4HANA. The Simplification Database is a database table in the SAP S/4HANA system that contains all Simplification Items that refer to SAP objects simplified in SAP S/4HANA. Each simplification item describes changed or removed SAP objects and refers to a dedicated SAP Note that describes the impact of the change and how the related custom code can be adapted. it is also important to analyze the custom code which has not been used in the last 1-2 years, or those custom programs which are used rarely or those custom programs whose functionality is now included in the standard SAP S/4 HANA functionality,
SAP Activate Explore Phase
Equivalent to SAP ASAP Methodology - Business Blueprinting Phase
- Run Fit to Standard workshops and introduce customer with best practice process flow charts and system demos
- Gaps to be documented as "backlogs" and addressed in realize phase (gaps only possible in Private cloud)
- Data migration templates can be downloaded and initiated for collection
- Learning design is documented and finalized
- Quality System is built for the "realize" phase
purpose of the explore phase is to explore the pre-configured SAP best practices content like best practice process flows and standard functionalities through a series of planned workshops between the business stakeholders and the implementation partner stakeholders and it is evaluated how closely these SAP best practices process flows, and standard functionalities fit to to the customers business requirements (fit of the standard). The consultants demonstrate the customer with the standard best practices process flows (from the SAP best practices content library) and then demonstrate the same process flow directly in the SAP Sandbox system,
the fit to standard workshops is mandatory in the SAP multi-tenant public cloud implementation as the customer has agreed to be a SAP public cloud where development or configuration of business process gaps is not a possibility,
but when it comes to the single tenant private cloud, on-premises implementations the business process gaps can be documented and implemented if found feasible (similar to the fit-to-gap process),
customer execution of standard business processes, helps them understand and accept SAP or the standard SAP S/4 HANA system early in the game. Consultants provide the business users with the documents required and help them run an end-to-end cycle in the SAP system. It helps them to get to know the system better even before UAT comes around,
it is important for the consultants. to understand the customer business processes and the customer requirements in detail, so that a best possible solution is provided, where leans towards standard solutions rather than a custom one,
gaps are documented as "backlog documentation", they are prioritized by the consultants and sequenced across agile sprints. The goal is to execute the realization of the documented backlog in an "agile methodology",
standard downloadable migration templates make it easy for customer and consultants to download and start collecting, validating and cleansing the data, early in the game,
train the team on "agile execution methodology",
the detailed learning plan is prepared in the explore phase ("Learning design"),
Provisioning of the development & the quality system,
An official signoff of the design is made in the explore phase,
SAP Activate Realize Phase
Equivalent to SAP ASAP Methodology - Realization Phase
- Execute Agile Sprints to build the system as per the documented & prioritized backlog
- Each Agile Sprint delivers smaller deliverables which needs to be demonstrated to the business product owners and signed off as "accepted"
- Test the system as per the detailed test plan (which includes test scenarios, test scripts with test data) Data collection, cleansing and conversion is executed across multiple trails or mock data loads
execute Agile Sprints to build or realize the system as per the documented & prioritized backlog, approved in the "explore phase",
the team realizes, the technical build (WRICEF), the functional configuration build, integration build that would integrate the external system or satellite systems connected with SAP, the analytical build, the security authorization build, the master data conversion build, the test build to build test scenarios & test scripts,
to execute the build & test in agile methodology or activate methodology, the approved backlog is documented in smaller deliverables called "user story". For example, a user story can be "enabling user to execute made to order production order strategy for the Warsaw plant", and at a higher level this user story belongs to the larger Feature called "MRP Strategies" and in turn the feature is a part of the Epic called "SAP Production Planning design",
in agile methodology, a particular phase is divided into multiple sprints, based on the span of the phase. As an example, to explain this - if the "realize phase" is scheduled for 7 months in the project plan, i.e., typically 28 - 30 weeks, the PMO team can decide to deliver smaller deliverable chunks of work every 3 weeks, which means you can have 9 Sprints and the last week can be a buffer week. To further add value to the discussion (as an example), the team can realize the build in 5 sprints, execute SIT (system integration testing) in 2 sprints, and execute UAT in the final 2 sprints & still keep 1-3 week as a buffer in the plan (this is just an example of how sprints are set up in an agile methodology),
in an "Agile Framework" the project plan is split in smaller teams called the "scrum teams". The scrum teams are divided based on value streams or work streams. These smaller scrum teams are then brought together in a team called "scrum of scrums". For example, an SAP PP team is one scrum team, SAP SD team is another scrum team, SAP MM team is another scrum team, SAP Finance team is another scrum team, SAP APO team is another scrum team, SAP Human Resources or HCM is another scrum team, SAP Data warehousing is another scrum team and SAP Basis another scrum team. Each of these scrum teams are led by a lead called as "scrum master" and the lead of the "scrum of the scrum" team is called the "scrum of the scrum master",
each of the scrum teams would have the supporting technical consultants who are also the part of each of these respective scrum teams (ABAP consultants, Integration consultants, Security consultants, data consultants and the test engineers)
to enable the realization or the system build & test, the SAP Basis teams prepares or builds the development environment (Dev system) right in the "prepare phase". At the start of the "explore phase", the SAP Basis team builds the quality environment so that the user stories that are accepted by the product owners in the agile sprints are moved from the development system to the quality system,
user training can be another scrum team which produces the user training documents and follow the user training plan, ensuring the users are trained before the UAT (user acceptance testing) is started,
typically, a project executes 2 biggest test cycles in a realize phase, i.e., the SIT & UAT. Based on the project timelines and schedules, a given project can even have 1-2 cycles of SIT and 1-3 cycles of UAT. But each of these cycles are highly expensive and it is advised to plan and execute successful cycles by detailed planning & close tracking,
the master data process, can start in the explore phase or towards the end of the explore phase; and in the realize phase data collection, cleansing takes off and the data conversion is tested across various mock data conversion cycles. Every mock data conversion is helpful in identifying the errors and in fixing them proactively. Typically, before the SIT system preparation & SIT data load, a project plan usually would run a couple of mocks to increase the quality of data,
during the realize phase, a cutover plan is prepared which is typically led a "cutover lead" or a "cutover manager". A detailed and a properly sequence cutover plan can really add to the success of the project,
All the site contents are Copyright © www.sapsword.com and the content authors. All rights reserved.
All product names are trademarks of their respective companies. The site www.sapsword.com is in no way affiliated with SAP AG. Every effort is made to ensure the content integrity. Information used on this site is at your own risk.
The content on this site may not be reproduced or redistributed without the express written permission of www.sapsword.com or the content authors.