# Interview with PRAPARNA MOHARANA, Data Analyst Profession - Published: 2026-09-30 - Author: [Connectively](https://blog.connectively.us/author/terkel.md) - Topics: [Interviews](https://blog.connectively.us/category/interviews.md) - Source: https://blog.connectively.us/interview-with-praparna-moharana/ - Publisher: Connectively *This interview is with [PRAPARNA MOHARANA](https://www.linkedin.com/in/praparna-moharana), Data Analyst Profession.* **Could you introduce yourself and describe how your work as a data analyst in consumer services draws on skills such as SQL, Power BI, Python, and data visualization to support operational decision-making?** Im Praparna Moharana, a data analyst specializing in turning complex operational data into clear, actionable insights. My work in consumer services sits at the intersection of data engineering, analytics, and business decision-making, where I use SQL, Power BI, Python, and data visualization to help teams better understand performance and improve day-to-day operations. SQL is central to my work because much of the information needed for reporting comes from large, interconnected datasets. I use it to extract, transform, validate, and organize data, as well as to build repeatable reporting processes. Python complements this work when I need additional automation, data processing, validation, or scalable handling of repetitive tasks. Power BI allows me to translate that underlying data into something decision-makers can use. I develop dashboards and reports that bring together operational metrics, trends, exceptions, and performance indicators in an accessible format. I pay particular attention to making visualizations intuitive, because a technically accurate report is only valuable if the people using it can quickly understand what requires their attention. What I enjoy most about data analytics is connecting the technical and operational sides of an organization. Rather than simply producing numbers, I try to understand the business question behind a report, ensure the data is reliable, and present the results in a way that supports informed decisions. That combination of technical problem-solving and practical impact is what continues to draw me to analytics. **What career experiences led you to specialize in building governed, validated analytics workflows, particularly in settings where data accuracy, privacy, and stakeholder trust are essential?** My specialization in governed and validated analytics workflows developed gradually through working with operational data where accuracy has real consequences. In consumer services, I have worked with complex datasets related to service delivery, compliance, claims and payments, and operational performance. These experiences taught me that producing an analysis is only part of the responsibility; the underlying data must also be traceable, consistently defined, and validated before stakeholders can confidently act on it. As my work expanded, I became increasingly focused on building repeatable controls into the analytics process. That includes using SQL-based validation and reconciliation checks, staging and transformation layers, clearly defined business rules, and automated workflows that reduce manual intervention. I also use Python for additional processing or validation, and Power BI to create governed reporting layers with consistent metric definitions. Working with sensitive consumer and operational information has also shaped how I approach analytics. I try to follow a principle of using only the information necessary for a particular analytical purpose, while being thoughtful about access, privacy, and how information is presented. Just as importantly, I avoid treating a dashboard as a substitute for human judgment. When a metric identifies an exception or potential issue, the goal is to provide reliable evidence that helps the appropriate stakeholder make an informed decision. Ultimately, these experiences have changed the way I think about analytics. I see trust as something that has to be engineered into the workflow from the source data and validation rules through the final visualization. When stakeholders understand where a number came from, what it means, and how it was validated, analytics becomes much more useful for operational decision-making. **When you begin an analysis involving data from multiple operational systems, what is the first data-cleaning practice you rely on to make the dataset fit for decision-making?** The first practice I rely on is reconciling and validating the data before I begin analyzing it. When data comes from multiple operational systems, I do not assume that fields with similar names necessarily have the same definition, format, or level of granularity. I start by identifying the key fields that connect the datasets, such as IDs, dates, status values, or transaction references, and then check for duplicates, nulls, inconsistent formats, unexpected values, and unmatched records. I also compare record counts and key totals against the source systems whenever possible. This helps identify problems before they become embedded in downstream calculations or dashboards. SQL is usually my primary tool for this stage because it allows me to profile large datasets systematically and create repeatable validation checks. For more complex transformations or reconciliation tasks, I may supplement that process with Python. For me, data cleaning is therefore not simply about removing bad records; it is about ensuring the data has the right meaning, relationships, and level of completeness for the decision being made. Once I validate that foundation, I feel much more comfortable moving into analysis and visualization. **You have emphasized validating automated workflows against historical results; how do you investigate and communicate a discrepancy so stakeholders can trust the final numbers?** When I find a discrepancy between an automated workflow and historical results, I treat it as something to explain rather than simply correcting it. My first step is to isolate where the difference begins by comparing the process at multiple levels: source records, transformation logic, business rules, and final aggregates. I typically use SQL to reconcile record counts, totals, dates, identifiers, and status values between the historical and automated processes. I then narrow the discrepancy to specific records or time periods and determine whether it comes from a data-quality issue, a change in business logic, timing differences between systems, or an error in the new workflow. For more complex comparisons, I may use Python to automate record-level validation across larger datasets. Once I identify the cause, I document both the discrepancy and the resolution. When communicating with stakeholders, I avoid overwhelming them with technical implementation details. Instead, I explain what differed, why it differed, how I validated the corrected result, and whether the change affects any previously reported numbers. Transparency is important for stakeholder trust. A discrepancy does not necessarily undermine an automated process; an unexplained discrepancy does. When stakeholders can see that differences were systematically investigated, reconciled, and documented, they can have much greater confidence in the final numbers. **For analysts modernizing a reporting pipeline, what practical approach would you recommend for documenting business rules and data lineage before building a new data model?** Before building a new data model, I recommend creating a simple business-rule and data-lineage inventory. The goal is to understand how the existing numbers are produced before trying to redesign them. I usually begin with the business definitions: - what each important metric means - which records should be included or excluded - how statuses are interpreted - what date fields drive reporting - whether there are exceptions or special cases I validate those definitions with the people who actually use the reports, because technical documentation does not always capture how a rule is applied operationally. Next, I trace each important output backward from the report or KPI to its transformation logic, source tables, and ultimately the originating system. A practical document can capture: - the metric or field name - business definition - source system - source field - transformation rule - validation check - any known exceptions This becomes a lightweight data-lineage map and also exposes places where the same metric may have different definitions across reports. I also recommend preserving historical outputs during modernization. Before replacing the existing pipeline, run the old and new processes in parallel and reconcile key totals and record-level results. Any differences should be explainable by an intentional rule change, a known data-quality issue, or a documented correction. The important lesson is not to start with the new schema simply because the technology is ready. First, establish what the data means, where it comes from, how it changes, and how you will prove the new model produces the intended result. That documentation becomes both the blueprint for development and the foundation for stakeholder trust. **When modeling operational data for dashboards, how do you decide which measures, dimensions, and pre-aggregations will preserve useful detail without compromising performance?** When I model operational data for dashboards, I start with the decisions the dashboard needs to support rather than trying to expose every field available in the source systems. That helps me determine the appropriate level of detail and which measures and dimensions are actually meaningful to users. For measures, I focus on clearly defined business metrics such as counts, amounts, rates, balances, and operational performance indicators. For dimensions, I identify the attributes stakeholders need to analyze those measures, such as date, program, service category, organization, or other relevant operational groupings. I try to maintain a consistent grain so that relationships between fact and dimension tables remain predictable and measures do not produce unintended duplication. Pre-aggregation becomes important when the underlying transactional data is huge. If users primarily need monthly or daily trends, for example, I may create an aggregated reporting layer at that level rather than forcing the dashboard to repeatedly calculate across millions of detailed records. At the same time, I preserve access to the appropriate level of detail when users need to investigate exceptions or drill into a result. I also validate performance decisions against usability. I look at query execution, refresh time, model size, and dashboard responsiveness, but I do not optimize simply by removing useful detail. The objective is to find the right balance: aggregate what is repeatedly calculated, preserve the detail that supports investigation, and keep business definitions consistent across both layers. Ultimately, a well-designed data model should make the common analytical questions fast and intuitive while still allowing stakeholders to understand and validate the numbers behind the dashboard. **Can you share how exploratory data analysis or techniques such as Pareto analysis have helped you identify an operational issue worth prioritizing, and what should other analysts look for first?** Exploratory data analysis is often where I discover that an operational problem is more concentrated than it initially appears. Rather than starting with an assumption about the cause, I break the data down across dimensions such as time period, program, transaction type, status, or other operational categories and look for patterns in volume, exceptions, and changes over time. Pareto analysis is particularly useful because operational issues are rarely distributed evenly. For example, when investigating a large number of exceptions or discrepancies, I rank the contributing categories by frequency or impact and calculate their cumulative contribution. That may reveal that a relatively small number of categories or process conditions account for a large share of the overall issue. Instead of treating hundreds of exceptions as equally important, the team can investigate the areas with the greatest operational impact first. I also look beyond frequency. A category might occur less often but have a much larger financial, compliance, or service impact. I generally examine volume, magnitude, recurrence, and business impact together before determining what deserves deeper investigation. For other analysts, I recommend starting with a few basic questions: - Where is the problem concentrated? - When did the pattern begin? - Which categories contribute the most? - Is it recurring or isolated? - Does the pattern represent a genuine operational issue or simply the way the underlying process is designed? The value of exploratory analysis is that it helps turn a broad statement such as “we have a data or operational problem” into a much more specific, evidence-based question. Once the problem is narrowed down, teams can spend their time investigating the causes that are most meaningful rather than treating every anomaly equally. **When predictive methods such as regression, decision trees, or clustering reveal a potentially useful pattern, how do you validate that it is meaningful enough to inform a business action?** When a predictive method reveals an interesting pattern, I do not immediately treat that pattern as something the business should act on. I first determine whether it is statistically reliable, operationally explainable, and useful in the real-world context. From the technical side, I validate the model using appropriate holdout or out-of-sample data and examine metrics that fit the problem. Examples include: - Regression: prediction error and residual patterns - Decision trees: precision, recall, and stability - Clustering: whether groups are sufficiently distinct, stable, and interpretable I then connect the result back to the underlying data and business process. A model can identify a strong relationship without proving that one factor causes another. I therefore look for: - data quality problems - leakage - outliers - changing business rules - variables that may be acting as proxies for something else I also discuss the pattern with stakeholders who understand the operational process to see whether there is a reasonable explanation for it. Finally, I consider whether the insight is actionable and measurable. If the organization acts on the pattern, I ask: - What decision would actually change? - What are the risks of being wrong? - How would we measure whether the intervention worked? For higher-impact decisions, I generally favor a controlled or phased implementation with continued monitoring rather than allowing a predictive model to make the decision automatically. For me, the goal is not simply to build a model with good performance metrics. It is to establish that the pattern is reproducible, understandable in context, and sufficiently reliable to support human decision-making. **Drawing on your Power BI and Tableau experience, what is one design choice that helps a dashboard turn a data-quality or performance exception into a clear next step for its users?** One design choice I find especially effective is creating a clear exception-to-detail path. Instead of showing users only a high-level KPI indicating that something is wrong, I design the dashboard so they can immediately identify what is driving the exception and move toward the records that require attention. For example, in Power BI I might use a KPI card to highlight the number or value of exceptions and then allow users to filter or drill into the underlying detail by dimensions such as time period, program, category, or status. Conditional formatting can make unusual values visible, while a detailed table provides the context needed to investigate them. The same principle applies in Tableau through interactive filters, highlighting, and drill-down views. I also try to make exception labels understandable from a business perspective. A user should not have to interpret a technical error code to understand why something was flagged. The dashboard should communicate what the exception represents and provide enough context to determine the appropriate next step. This is an important distinction for me: a good dashboard should not simply say, “There is a problem.” It should help the user understand where the problem is, what is contributing to it, and what they should investigate next. **Thanks for sharing your knowledge and expertise. Is there anything else you'd like to add?** I would add that one of the most important lessons I have learned is that good analytics are ultimately about trust. The sophistication of the technology matters, but it is equally important that the data are accurate, the business rules are understandable, and stakeholders can trace how an insight was produced. As analytics become increasingly automated and incorporate more predictive and AI-driven methods, I believe analysts have an important responsibility to maintain validation, transparency, privacy, and human judgment. Automation should make people better equipped to make decisions rather than distance them from how those decisions are reached. That principle has shaped how I approach my own work—from SQL and data engineering to visualization and reporting. I am continually interested in building analytics systems that are not only technically scalable, but also practical, explainable, and genuinely useful to the people relying on them. Thank you for the opportunity to share my experience and perspective.