Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Business Analysis Initial Steps
Previous Previous
 
Next Next
New Post 9/13/2012 3:22 AM
User is offline New_BA
2 posts
No Ranking


Business Analysis Initial Steps 

I am very new to this BA world. I have been a developer all my life and have now taken up this role in a new company. While being a developer I have done lot of technical analysis  but this is now my first official BA assignment and I need some help in getting on.

This project is about restructuring one specific area of company’s business. They are looking to streamline their current process which uses lot of applications to perform this business and now plan to consolidate all this to minimal possible applications. I now need help as to how to start the Analysis on this. Would someone be able to guide me as what should be my starting moves on it. I have a business proposal with me which mentions the current problems.

This project is fairly large sized (estimated to run for approx 10 months)  so I know there is a bog job to do but the fact that this is big is making me nervous as to where should I begin and what do I do next. Can any one help.

 
New Post 9/13/2012 6:23 AM
User is offline Adrian M.
764 posts
3rd Level Poster




Re: Business Analysis Initial Steps 

There are many ways and techniques out there to help you approach this task.  It depends also on what tools your organization makes available to you and any standards they may want you to follow.

Having said that, the first step is understanding he current technology and business landscape.  If you want to keep this simple you should:

  • Document the existing process/activities performed by the business using a process modeling notation such as BPMN.  You need to document everything (manual and automated processes).  Out of this exercise you'll also get a list of Actor (roles, job titles, etc.) which you should document in a separate document and begin developing your actor descriptions/personas.
  • Create a spreadsheet of every application, tool, sharepoint site, excel spreadsheet, or other tool used by any of the actors in their job.  This list can be slowly developed at the same time as the business process map aka once you discover a task or activity ask "how do you do this? what tool do you use?".  I would also annotate the process diagram with this tool informaton.  In the tool list you should add columns for metadata for each tool such as description, high level features, tech lead contact, disposition, comments, etc.

Once you understand the AS-IS or current state you'll begin the process of defining the target state process model (is the business process changes - new tasks, dropped tasks, etc.).  This is the time when decisions will need to be made about the future state of existing applications/tools.  Which ones will be kept as-is, which ones will be modified, which one will be retired and replaced with new ones, etc.

Hope this helps!

Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 9/14/2012 8:32 AM
User is offline Anthony Chen
63 posts
8th Level Poster


Re: Business Analysis Initial Steps 

 Adrian M. wrote

There are many ways and techniques out there to help you approach this task.  It depends also on what tools your organization makes available to you and any standards they may want you to follow.

Having said that, the first step is understanding he current technology and business landscape.  If you want to keep this simple you should:

  • Document the existing process/activities performed by the business using a process modeling notation such as BPMN.  You need to document everything (manual and automated processes).  Out of this exercise you'll also get a list of Actor (roles, job titles, etc.) which you should document in a separate document and begin developing your actor descriptions/personas.
  • Create a spreadsheet of every application, tool, sharepoint site, excel spreadsheet, or other tool used by any of the actors in their job.  This list can be slowly developed at the same time as the business process map aka once you discover a task or activity ask "how do you do this? what tool do you use?".  I would also annotate the process diagram with this tool informaton.  In the tool list you should add columns for metadata for each tool such as description, high level features, tech lead contact, disposition, comments, etc.

Once you understand the AS-IS or current state you'll begin the process of defining the target state process model (is the business process changes - new tasks, dropped tasks, etc.).  This is the time when decisions will need to be made about the future state of existing applications/tools.  Which ones will be kept as-is, which ones will be modified, which one will be retired and replaced with new ones, etc.

Hope this helps!

Adrian

 

Adrian provides a great place to start. I would also add that it is helpful to understand what objectives the business is trying to accomplish with the restructuring.

RML (requirements modeling language) defines 4 categories of models, each with a bounding model.

Objectives models - help you to model the business objectives of the organization. The bounding model is a business objectives model which maps business objectives and business problems to high level features.

People models - help you to understand who the people are and what the people are trying to accomplish. An org chart bounds who you need to talk to to identify the process flows that adrian mentioned

System models - help you to understand the systems themselves. The bounding model is an ecosystem map which shows the relationships between systems.

Data models - help you to understand the data used in the system. The bounding model is a business data diagram (similar to an ERD but simpler) which helps you to understand the data relationships. Other data models include data flow (which adrian somewhat mentioned when he described understanding how things like spreadsheets are created).

You can read more about this in our visual modeling book or at our blog

Here is a link to a pdf that summarizes the models

http://www.seilevel.com/wp-content/uploads/RML-Language-for-Modeling-Software-Requirements1.pdf

The book discusses in more depth how to use the models together and how to integrate them into a process

http://www.amazon.com/Visual-Software-Requirements-Practices-Microsoft/dp/0735667721/ref=sr_1_1?ie=UTF8&qid=1347636671&sr=8-1&keywords=visual+models

 

 
New Post 9/15/2012 7:22 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Business Analysis Initial Steps 

Hi:

Process modeling leads data modeling, so start there first. 

 A business system consists of software and/or computers.   Do not fall into the trap of thinking that to capture the behavior of automated processes requires a different technique than to capture the behavior of manual processes.    That is a forced, artificial partitioning, the main damage caused by such is that it retards integration efforts - especially on larger scale efforts.  Only one technique is needed.

Do not use process modeling techniques that try to steer you into prematurely thinking about solution.   Thinking solution too early is a sure way to derail essential requirements analysis.   In terms of BUSINESS analysis, its a data flow, not a message, its a process, not an object.  Leave thoughts of messages and objects to development staff.  Remeber, one of the most difficult parts of requirements analysis is to maintain a proper focus.  It has always been my experienced that BA's who are not strongly focused on the essentials largely miss them.

Start top down as much as possible, else, there is a real tendancy to "drown in an ocean of details".   But be aware: business systems at higher levels of abstraction (i.e., at the bigger picture level) are notorious for being non-sequential.  One can not model the non-sequential using a sequence dependent technique.   Many, including some of the "experts",  dispute this very imporportant point saying, in effect, you can, even at the top most levels, identify a sequence (including a start point).   Try to do such yourself.   If you can not, then try data flow diagrams (the only real non-sequential technique suitable for larger scale manual/automated systems behavior documentation).

In conjunction with top down analysis, a critical task is to model scope.   A context diagram is the way to go.

When you are modeling processes, think of the essentials.  A process is defined by it inpts and outputs, which are typically data flows. 

For identified data flows, start a data dictionary.   Not the techie type, but, simply, plain english definitions.   This is the primary input to your subsequent data modeling efforts.

Above all, do not let the techie  types steer you into thinking that requirements analysis requires understanding a bunch of techie stuff, including techie stuff related to how you will proceed in requirements analysis.   For a truely Agile approach, all you really need is a few higher level business oriented data flow diagrams, some entity relationship diagrams, and maybe some screen shots. You can leave all the detailed requirements and the techie stuff to be handled by the developers in coverstations.

Tony

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Business Analysis Initial Steps

Community Blog - Latest Posts

Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Architecture and AI In our recent conversation with Joseph Edward, we explored the transformative power of business architecture (BA) and technology as tools for uplifting communities. Joseph, with his rich background spanning from education to IT leadership, shared...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - The AI Business Analyst I recently had an engaging discussion with Maria Becerra, a passionate advocate for AI and an accomplished business analyst, on the AI Business Analyst. Maria is a respected name in strategy, business analysis and AI. Her path from Colombia to Canada ...
Hosted by Deirdre Caren on Agora Insight's Blueprints for Success - Business Analysis. I'm happy to share insights from my recent conversation with Kingsley T. Ihejirika, PhD, an ICT Business Analyst at the Ministry of Justice in New Zealand. Kingsley's unique blend of academic theory and practical expertise sheds light on the path t...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC