Think 180 is a SAP silver partner

14 Steps to Implement IT Business Transformation Strategies

Monday, 17 August 2020

Business transformation is an umbrella term for making fundamental changes in how a business or organization runs. This includes personnel, processes, and technology. These transformations help organizations compete more effectively, become more efficient, or make a wholesale strategic pivot.”

-Productplan.com

“A business analyst (BA) is someone who analyses an organisation or business domain (real or hypothetical) and documents its business or processes or systems, assessing the business model or its integration with technology. Business Analyst helps in guiding businesses in improving processes, products, services and software through data analysis.”

-Wikipedia.com

business analyst

Introduction

I started my career as a Systems Analyst, but soon realised I tend to side with business more than the system. I know IT systems have lots to offer but ultimately it should be able to support an ongoing business without much disruption. I regularly challenge the software limitations even if I am one of their representatives. Then there are best practices which the system brings from their experience of the larger market, where businesses do have to think of ways to adopt.

From my experience there’s a lot that can be done as a Business Analyst, (and a SAP Business Analyst), but this article explains the processes which are the absolute minimum for a Business Analyst. I would say I have only scratched the surface for few of these topics which would take up a lot more pages if explained in detail.

A Business Analyst can be deployed for a business as usual organisation or for a new system transformation. This article focuses on the latter.

Depending on the size of the transformation project an organisation should deploy at least one Business Analyst per domain having that specific process expertise. As a minimum there should be one Finance Business Analyst and one Operations Business Analyst in a transformation project of any size.  A Finance Business Analyst should be aware of financial postings, costing, P&L reporting etc, while the Operations Business Analyst should be aware of processes on supply chain, procurement, logistics, inventory, sales, and distribution etc.

These are the steps that make the structure of a transformation project:

STEP 1.0. Creating a Business Case

Before the project is kicked off, we must justify the purpose of embarking on this journey. A business case must be prepared with the following in focus:

  • Summary – Summarise the change which is being implemented
  • Reason – Why there is a need for implementing this change. Which factors have led to this change? Why now and not later?
  • Business Benefit – How does this change benefit the business? The benefits can be listed in terms of operational efficiency and / or financial. Keep in mind there are certain benefits which can be long term and may take a few years to show. Set Key Performance Indicators (KPIs).
  • Risk (of not implementing) – What would the organisation lose by not implementing? Again, one must think through the long term impact. Having a knowledge of change in industry dynamics over the years would help in identifying the risk.
  • Timeline and Cost – What would be the ideal timeline of this change implementation, keeping in mind the available resources.
  • Options – What are the various methods (software and / or hardware, implementation partner) by which this can be implemented? I usually prefer to have at least three options with one option being the most economical. This section can also consider listing out the possible vendors who can be approached to implement the change. Further details of the version of software can also be mentioned in this section.

 

STEP 2.0 Understanding the business

After the Business case preparation and a decision on the vendor, the project may be kicked off. The starting point for a Business Analysis is to understand what areas of business is going to be impacted or going for a change. Get a complete understanding of the impacted business area by taking the following actions:

  • Talk to the business stakeholders (end users, managers, business process owners)
  • Read documentations wherever available

This step is not a mandatory step, since these activities can be integrated with the business requirement gathering step (4.0). However, having a clear unbiased understanding of the business can be very advantageous before the start of the actual project, especially if you, the Business Analyst, are someone from outside the organisation. This step should take about 1-2 weeks based on the size of the change.

 

STEP 3.0 Understanding the new IT system

In addition to understanding the business it is also advisable to spend some time understanding the new IT system that will be implemented for this project. Usually organisations prefer an analyst who already possesses either the business or the new IT system knowledge. I would suggest a Business Analyst spend time outside their regular business hours to better understand these two areas and get an edge over their competitions. The following can be done to gain knowledge about the new IT system:

  • Read documentation over the internet.
  • Read user and other client testimonials and the feedback about the new system.
  • Search various online learning videos that can give you a fair knowledge of what to expect.
sap business analyst

STEP 4.0. Requirement Gathering, Business Blueprint Workshop

Once the Analyst gets a good understanding of the business it is time he/she starts gathering all the information into a predefined acceptable document template. Usually this document is called “Business Blueprint Document” (BBP Document) or “Business Requirement Document” (BRD). A single document for each separate Business Process is recommended for easy understanding. This document should have the following sections:

  1. Business Requirement details along with a detailed process flow diagram of the business process. There can be multiple process flows.
  2. Business Process hierarchies and Enterprise structure.
  3. Roles: Who performs each of the activities and currently on what medium is this done. For example, on System, Outside System, Manual or Automated etc.
  4. The legal processes or documents needed. For example, government approved Invoice document.
  5. The To-Be process flow diagram which explains how the current process is expected to be done in future (post system live). Some processes may remain, some processes could be new, and some processes must be changed.
  6. The process which needs to be changed should be accompanied with an explanation. Such as: “The change is a business change triggered by the new system for best practices” or, “The change is due to the new system limitations. In other words, these are so called ‘Gaps’”.
  7. What are the data types and data structures that need to be migrated for this business process?
  8. List out all the relevant stakeholders, approvers, and signatories of this document

A lot of emphasis is given to this document at this phase since this document will be referred regularly for all the phases that will follow. This document will also form the basis of any possible change request in the future.

With the above list of possible outcomes, one should start conducting business blueprint workshops with all the relevant business stakeholders. Here should be a recommended approach:

  • Explain the Business: What is the business process which will undergo change step by step? This is where Step 2.0 ‘Understanding the business’ is useful. Prepare a flow diagram if possible. Share the best practices referenced from other similar business. Be very open at this section as no Business likes to be told that the processes they currently follow may not be the best. Have an open dialogue but do keep the timelines of the workshop in mind, it is very common to exceed the scheduled timelines at this stage.
  • Share the expected To-be process with the possible change in steps. Take help from Systems Analyst wherever possible.
  • For inconclusive decisions, schedule addition meetings with more / relevant participants.

The goal should be to gather all the information with regards to the BBP document list of items. This phase takes 4-5 weeks.

 

STEP 5.0: Identify Gaps

This is a collaborative step to be worked out along with the Systems Analysts. Here you will be listing out all the possible areas where the new system is unable to address and the same process is identified as one that must be done within the system and cannot be performed outside. Ideally this is entered into a spreadsheet with columns explaining what the gaps and what action are needs to be taken. This document is termed as Fit-Gap analysis document. This document will identify the Change Request required, technical expertise required, and the delivery timelines.

 

STEP 6.0: Change Analysis

One of the documents which is an outcome to the Fit-Gap analysis document is the Change Analysis document. This document analyses the details of change, criticality, priority, and the cost involved for the change (known to project sponsors only). After this, for the system related changes the Change Analysis document must be approved and handed over to System Analyst team to take it forward with the system development. If the change pertains to a business process change the same should be handed to the business process owners to act on and communicate to their relevant team.

 

STEP 7.0: Functional Requirement Document (FRD)

Further to the Change Analysis document, for IT related changes, a Functional Requirement Document or a Functional Specification is prepared by the System Analyst with the help from Business Analyst. This will detail out the technical aspect of the change along with steps to complete the activity.

 

STEP 8.0: System Configuration, Custom Development

Once the BBP document and FRD is finalized, the same should be handed over to the Technical Systems Analyst team to take necessary steps to configure the IT system and make any custom developments based on the Change Analysis requirement. This step is a primary responsibility of the Systems Analyst while Business Analyst will only support and monitor the progress. In addition, the Business Analyst will be responsible for facilitating any meetings with business owners and Systems Analyst for additional clarification or requirement gathering. Business Analysts are also responsible for running the first level of testing for the completed system work (for general configuration as well as custom developments) before handing it over for business testing.

 

STEP 9.0: Data Migration Analysis

While system configuration and developments are in progress, Business Analysts should be engaging with the business owners and data owners to gather detailed data migration requirements (remember an initial discussion had happened during the BBP phase). The outcomes of this step are:

  1. List of data objects to be migrated
  2. Volume of data
  3. Data owner by each object
  4. Decision on historical data (how far in past should the data be considered for)
  5. Information of the system where legacy data resides, including retrieval procedure, time for retrieval and roadblocks
  6. Method for downloading the data or any special tools required for the same

 

STEP 10.0: Data Cutover Plan

Based on the outcomes from the Data Migration Analysis step, by this time the data retrieval should be already underway taking care of any roadblocks. This Data Cutover Plan will then add additional information such as:

  1. Who is the technical owner of the data? The Systems Analyst responsible for cutover
  2. Method to be used for data cutover (Excel upload, special migration tool etc.)
  3. Post cutover data approver / sign off party
  4. Timing of the data cutover or Cut-off time. Timing is important and should match with project timelines, system readiness, resource readiness and free of data object clashes. Data object clash occurs when two or more data objects share the same elements.
  5. Which parameters will constitute final data cutover acceptance? Such as matching of final Accounts Payable and Accounts Receivable in the books, matching of legacy system and new system inventory valuation on the books, matching of assets etc.
  6. Is there a need to stop production for the cutover or not? If needed, then for how long and what is the communication plan?
sap business analyst

STEP 11.0: Training

1. Training Plan: For any new IT system implementation before the system is Live and being used by the business users, it is important that these users are aware of the operations and functions of the new system. This would also be necessary for the next task of User Acceptance Testing (Step 12). A Business Analyst should list out the processes that need to be taken up for training. Usually this list will be like the Business processes identified during the Requirement Gathering / Business Blueprint (Step 4) plus some additional special processes identified along the way. Along with the processes the Business Analyst should take help from Project to identify the trainers. Usually the trainers are among the Business Process Owners, Systems Analysts, or the Business Analysts themselves. Next the Business Analyst should coordinate with the Business Process owners to identify the list of Users who are required to be trained. In some cases, once a set of users are trained, they would then go ahead and train more / larger set of users. In other term it is called as Train-the-Trainer or Key User Training. A training plan is prepared accordingly along with dates and participants, the training locations are identified and prepared. A Business Analyst may or may not get involved in the preparation stage.

2. Training Material: There are different levels of training materials prepared based on the roles and responsibilities of the users. Usually a Level 1/2/3, based on complexity, is identified and a training manual is prepared. A Business Analyst may or may not get directly involved in preparing the training material but is certainly responsible for the review and correctness of the material. Training material could be in the form of Word document, PowerPoint Presentation or short demo videos.

3. Training: Once the Training Materials are prepared and reviewed, it’s time for conducting the training based on the training plan and timelines. There can be some overflow of timings due to various reasons, these can be rescheduled and added to the plan. Also, during the training there can be issues which are identified and logged in the Issue Log / Register. This will be the first time users will be exposed to the new system and there can be some resistance expected hence a Business Analyst along with Business Process Owners should be able to alleviate some of the concerns by explaining the business benefits. These benefits may have already been identified during the Business Case preparation. Sometimes trainings may continue to be conducted afterward up until go-live, depending on the size and spread of the organisation.

 

STEP 12.0: User Acceptance Testing

Once all the relevant users are trained on how the new system works at their respective work areas, some of the key users will be asked to test out the key business processes end to end with quality (close to production) data. End to end processes involves all the departments from start of the process till the end. Example of end to end processes are:

  • Order to Cash
  • Procure to Pay
  • Finance and Controlling
  • Make to Order
  • Human Resources and Payroll etc.

A script with all the steps is prepared and given to the key users to perform and records artefacts of their testing. These artefacts will then be used as an evidence of system acceptance. During the Acceptance Test there may be defects and issues identified, the same should be recorded in the issue log / register. User Acceptance Test is one of the key prerequisites for the system Go-Live.

 

STEP 13.0: Data Migration

By this step, the Data should be ready to be uploaded and its time to start uploading / creating data into the new system based on the Data Cutover plan. A Business Analyst must ensure the data provided by business are clean and in good quality, coordinate with data owners and data migration analysts, monitor progress of various data migration activity and ensuring adherence to cutover plan, getting relevant business / data owners to validate the uploaded data and getting their approval / signoffs on time. Usually data is loaded first in a pre-production environment to test the data migration tool’s capability and completeness of data and then the data is loaded in the production environment.

 

STEP 14.0: System Go-Live and Support

Once all the checkpoint items are completed such as User Acceptance Test, Data Cutover approval, Issue / Defect resolution etc., it is time to switch over to the new system. On a predetermined date after necessary communication the legacy system access will be stopped, and all the users will start to use the new system. A Business Analyst will have to address any user’s concerns pertaining to system operation and will have to coordinate between Business Owners and Systems Analyst based on the nature of concerns. Once the hyper care / maintenance period of post go-live support finishes, a regular system support should begin with a system to capture user issues / defects as well as new requirements and improvements. Depending on the nature of the improvement a mini project may be required to be implemented.

sap business analyst

Additional Activities and skills of a Business Analyst

  • Roles and Responsibilities: Defining the roles and responsibility matrix for every user in the system. This helps in defining the Delegation of Authority and Segregation of Duties as well as provides a foundation for restrictive access creation for sensitive data.
  • Stakeholder Engagement: A continuous and transparent communication with the Business and Project stakeholders is mandatory for the project success. Based on the reporting tools at a predefined frequency the project progress, risk and issues should be shared with the stakeholders. Any escalation not being addressed can also be brought up at the same time. A stakeholder may consist of Project Manager, Program Manager, Project Sponsor, Business Process Manager.
  • Documentation: As mentioned in respective steps documents shall be created based on a predefined template and should be stored at a central repository for everyone to access and retrieve.
  • Continuous Improvement: Identifies organisation’s strengths and weaknesses and suggests areas of improvement and develop strategies for enhancing or further leveraging these processes.
  • Working with Tools: Ability to work with Project management tools such as MS Visio for Process Flows, MS Teams for Task monitoring and team communication, ALM for test management and defect management.
  • Strong time management and organisational skills: The ability to manage and prioritise multiple tasks at the same time.

If you are in need of a SAP Business Analyst to have a look at your processes or system transformation, reach out to us today to get access to Think180’s business transformation experts.

By Anub Kaviraj

Think180 Business Analyst