What’s Up With Data Analysis?

Ali Cox

Ali Cox

What’s Up With Data Analysis?
Share
Share on facebook
Share on twitter
Share on linkedin

I find myself running into a lot of business analysis professionals who say, “I don’t do data analysis. That is the data architect’s job.” My response: “…What?!?!”

In a nutshell, a good business analysis professional knows that part of their role is to understand the business and help the business solve its problems by making sure their business processes and rules are correctly implemented in a solution.

Let’s decompose: making sure their business processes and rules are correctly implemented in a solution.

What is a business process?

A process takes inputs (also known as data!) and adds value to them via some identified activities to generate outputs (also known as data!). A business process is an activity or set of steps that the business needs to perform in order to be successful. Let’s consider a project to provide a solution for a grocery store business.

A business process for the grocery stores, for example, might be “Capture Customer Payment,” which would occur when the customer checks-out at the register or online. To understand what the business should accomplish in this process we would need to understand what data is used to complete it. Total of products purchased, taxes charged or coupons to apply might be examples of some of that data. If we do not understand these data items and ensure they are delivered in the solution developed, we probably will have gaps and errors. And the customer would not be too happy if we calculated their total, taxes, or coupons incorrectly. I probably would not continue to shop in a store if I knew their calculations of what I am paying for is incorrect.

For more help defining your business processes, join us for a session of our Business Process Analysis course.

What are business rules?

They are the constraints a business implements in order to be successful. They tell us how, logically, to manipulate the data so that the business process is completed correctly. Continuing with the grocery store project, a business rule might be, “If the store is in any US state except Alabama, Mississippi, or South Dakota and the product is a food product, then no sales tax is applied.” In order to implement this business rule correctly, we need to understand what is considered a “food product” and what the term “sales tax” means. Also, is the coupon within date and item being purchased applicable? These are data items. If we misunderstand these data items, we will have errors and or gaps in the solution we are delivering.

What is a solution?

In an IT environment, solutions usually involve an information system and the users and workflows involved in using the system. Typically, an IT solution combines automated and manual components to deliver a complete solution to the problem. For grocery stories, this might be the point-of-sale system that combines the manual and automated processes needed for the customer to check-out. A solution can also be purely manual and not have to involve IT at all. For example, the process of selecting grocery items from a brick-and-mortar store and placing them in a physical shopping cart.

No matter what the solution includes, whether manual, automated, or a combination, it will still involve business processes and therefore involve business rules and business data. To leave out a third of that (the data), we risk delivering a solution that does not solve the problem. That is a big risk!

What is an information system?

It pulls and pushes data (the term “information system” contains the word information, and information is data). A good information system provides timely, correct data about the business so that the business can make decisions that will drive its success. Once again, if we as business analysts do not understand the data contained in the system, how do we know that the system fulfills the business need?

What is at the core of all of this? Data.

Without correct, timely data, a business will not have the ability to make good business decisions. Period…end of story. It may not be the whole story, but I think it is the punch line, so missing that would be missing the target.

In my experience, a deep, clear understanding of the information that a business uses and the relationships between that information is the best way to really understand the business. Processes can and do change, but data is relatively stable. If you understand the data a business uses to run itself, you can really get a good understanding of that business and enable the business to better understand itself and what it does.

What can you do as a business analysis professional to get a good understanding of the data a business uses?

Ali’s 4 Step Process to Data Analysis

  1. In project scoping, I make sure I understand all of the project’s interactions with the ‘outside world’.

    This means identifying all interfaces we think are going to be necessary for the solution to work. To help me and the project executives understand these interactions, I typically build a context (dataflow) diagram. This diagram is a great high-level picture of the complexity of the data interactions on a project. It gives me the original sources of the information that the solution will need to run effectively, as well as the final destination of the data that the solution will produce. These sources and destinations will have representative stakeholders from whom I will need to elicit more details.

    Learn how to build a Context DFD diagram in our Scope Your Area of Analysis class.

  2. Also in project scoping, I identify the high-level business capabilities that the project will be affecting or creating.

    This gives me a good idea of how many lower-level processes will be effected and how complicated they appear to be. For those processes that seem complex, I break them down into the activities or tasks that make them up so that I have a better idea of how to estimate effort.

    See our Leverage the Context Level Data Flow Diagram Quick Tip for more tips on using this diagram throughout the project.

  3. Having analyzed the processes and context diagram from steps 1 and 2, I now have a great picture of the processes and data I’ll need to get more detail on and the stakeholders from whom I need to elicit the details.

  4. As I begin analyzing the processes and data flows from steps 1 and 2, I also start to build my data model.

    I use the time-honored technique of using an Entity Relationship Diagram (ERD) to see the data entities with their detailed data and relationships. The data relationships are hugely important as they are the data business rules that drive your business. Asking good questions about the data will bring out business rules that might be missed if you just concentrate on the process workflow. As more questions are raised and answered, the data model becomes robust and complete. It also gets us thinking about that “Big Data”. What ELSE do I need to know about my business to help it market, sell, and produce the products that will make it more successful? How do I relate all that ‘stuff’ together so that we can diagnose problems and predict demand? A deep understanding of that data helps with those important questions.

    I recommend downloading and using our System Interface Template to help facilitate the process of analyzing and communicating the system interface and data migration requirements.

In my company’s projects, I always ensure that we have a good understanding of the system interfaces that will be involved in the solution. Those interfaces contain business data, so we need to validate that the data passing through system interfaces is complete and correct.

What is the result?

You end up with a full, deep, clear understanding of the data on which the business runs. You ensure that the data architect now has the information needed to build an efficient, effective database that contains the data and relationships to match the business needs. The business areas in which you are working end up with a better understanding of what they do. Additionally, you move beyond the BA that is just an order-taker and become a valuable, crucial part of the project and the organization as a whole.

I challenge and encourage you to become a business analyst that DOES do data! If you need help learning more about how to perform this aspect of your role, join us for a session of our Detailing Business Data Requirements course! 

To the data,

– Ali

Editor’s Note: This blog post was originally published in March 2012. Due to its popularity and that data is still an important aspect of analysis, Ali has completely revamped and updated its content to be more comprehensive and accurate for the state of today’s environment.

More on Business Analysis

Join our #AlwaysLearning Community

About the Author

Ali Cox

Ali Cox

Alison (Ali) Cox, Netmind Senior Instructor and General Manager, has experience since the mid-1980s in various areas, including business analysis, project methodology development and training, systems development (mainframe, client-server, and web), and telecommunications management. Alison began her career in the financial services area, and then moved into systems development for accounting systems. She has provided consulting and training in business analysis and project management for small companies to Fortune 500 corporations worldwide and speaks Spanish fluently. Alison is also a partner of TEMSS (Telecommunications Efficiency Management Strategies and Services), which provides telecommunications efficiency auditing and billing analysis services to clients in all areas of business across the United States. She completed her Master of Business Administration in MIS and Accounting from the University of Georgia. Connect with Ali on LinkedIn.

10 Responses

  1. 1. Data Analysis is closer to Business Intelligence than to Business Analysis. Both DA and BI are not listed in BABOK. These are disciplines that require specialized training and thinking.

    2. Some BA’s can do DA and BI work, if they arose from the technical ranks. However, more likely as BA’s they are the bridge between the Business and the DA or BI group.

    Enjoyed your blog, nevertheless, Ali…it still is a conundrum worth debating.

    Cheers !

    1. Bennett – This is very close to what I was going to say. There are definitely data needs that must be understood by a BA, but I think the term Data Analysis is really talking about something much bigger such as analyzing big data.

      1. Thanks so much to you both; good comments! I would question why a business analyst would NOT be involved in their organization’s ‘big data’. Those are business data needs. The needs aren’t technical, although they should translate well to the data architecture. I think that in today’s agile framework world, the business analysis role (which is not necessarily just for the business analyst anymore) has to address the t-shaped skills model. Just my humble opinion 🙂 Keep the comments coming!

  2. Here’s to the data! Many BAs tell me that they don’t document data because they view that as the responsibility of the technical team. My question to them is always “Does the technical team meet with the business SME to elicit the data requirements?” The consistent response is “no.” So how does the technical team know what data is appropriate/relevant? What relationships between the data are needed to make business decisions? If data is documented without input from the business, the resulting solution often requires workarounds due to improperly defined data. Involve the business from the onset and avoid costly workarounds! Who better to elicit data needs from the business than the BA?
    Olya Broadwell
    Sr. Instructor, B2T Training

  3. Thanks for stating this in the blog, Ali. Sometimes as BAs who have been doing this in our practices, we tend to forget some of the things at the core of what we do. Just like processes, rules, and actors, data is one of the core components we need to understand as we go about our jobs and elicit and capture the requirements.

    Thanks for bringing us back and putting it into words.

  4. As Ali mentioned, understanding the data is central to understanding the Business Process and associated business rules. The question as to levels of role responsibility is where should the BA draw the line in relation to data analysis and definition.

    I typically look for the BA to work at the logical level and leave the physical level to the DBAs and Developers. The analysis by the BA focuses upon object and attribute identification, logical definition and business rule relationships. Context Diagrams, Data Flow Diagrams and ERDs are all good aides in the analysis, but I learned to be careful about putting ERDs in front of Business SMEs.

    In one analysis meeting I put my ERD on the screen to demonstrate to the Business SMEs and managers in the room that the data relationship they were seeking was not possible given the lack of a unique identifier between two important objects. While I made my point and received my answer, the Managing Director present commented with an obvious derogatory tone, “That must be an IT thing.” I learned an important communication lesson during that session. While ERDs are still an important analysis tool for BAs, I employ simpler approaches during discussions with the non-technical members of the project team.

  5. I agree with you Doug – I rarely put an ERD in front of the business. I use the ERD to help with my own analysis, to ensure I ask good questions about all of the data business rules, and to ensure that those business rules make sense and don’t conflict with each other. I find I ask more intelligent, deeper, more meaningful questions when I have that structure to back me up. And I find that my data requirements are better structured for good testing. And let me be clear – I think the BA’s role is to elicit BUSINESS data requirements (hence he/she would produce a business / logical ERD), not technical data requirements, which should be left to a good data architect. Thanks for the feedback!

  6. I agree that BAs need to be knowledgeable about Business Data and that BAs need to perform data analysis. At a minimum, BAs must perform analysis of the messages (data) and/or business data entities that are in scope. Questions similar to the following need to be answered: what data is included in the event that triggers a business process/workflow? what business processes are impacted by a new message/new piece of data or a change to existing messages/data? what can happen to the data as it travels through the business process/workflow? what interfaces does the data travel through? It’s great when BAs have the skills to analyze the data further (ERDs, conceptual data models) because this helps to ensure requirements are accurate and complete earlier in the Software Development Life Cycle (SDLC).

Leave a Reply

Your email address will not be published. Required fields are marked *

Almost done!

Please check your email to confirm your subscription.

Join our #AlwaysLearning Community

Onsite Training Request

Please provide the information below to help us to customize your solution. 

Contact Us

Netmind US
296 South Main Street, Suite 300
Alpharetta, GA 30009-1973
T. +1 (678) 366.1363
F. +1 (678) 366.1983

Office Hours:
Monday – Friday, 8:30-5:00EST

General Inquiries:
info@netmind.net

Sales Inquiries:
sales@netmind.net

Request Information