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.”
“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.”
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:
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:
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:
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.
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:
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:
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:
The goal should be to gather all the information with regards to the BBP document list of items. This phase takes 4-5 weeks.
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.
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.
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.
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.
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:
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. 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.
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:
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.
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.
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.
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