Data Analysis & Modeling

This article describes using a Requirements-Friendly Data Dictionary (RFDD) as an alternative to representing a software solution’s data-related requirements as User Stories, Use Cases, or traditional Waterfall Requirement statements. Any of these forms can still be used to document the solution’s functional requirements. An RFDD spreadsheet-based template or extended requirements management tool (RMT) provides a structured format that supports a business analyst documenting required Record and Field details while eliciting functional requirements.

For business analysts, those unsung heroes who sift through mountains of information to guide corporate decisions, data privacy emerges as an unexpected ally. It's the secret weapon that not only protects against breaches and fines but also actively forges unbreakable bonds of trust with customers. This isn't about fearmongering over scandals or reciting dry compliance rules; it's about reimagining privacy as the foundation of enduring loyalty in a sceptical marketplace.

By analyzing data, project managers understand better what works or not. In the long run, this makes it easier to predict potential problems and correct them before they become too costly. There are a few essential steps in data analysis that companies need to follow for accurate results. Below is a quick guide on successful data analysis.

Businesses increasingly depend on smooth data integration, efficient product development, and perceptive analytics to drive innovation, smart choices, and customer value in today's fast-moving, data-centric world. Guaranteeing the three key components work together as "a single, unified entity" requires dealing with many challenges. These challenges relate to organization, communication, technology, and culture. Connecting all data, every product, and all analytics requires a thorough approach. Highly meaningful teamwork, precisely adjusted efforts, and advanced tools are key to success. This post explains how to close this gap and it offers a solution to the problem.

The function of business analysts has changed dramatically in today's technologically-advancing, digitally transformed business environment. Using analytics for data-driven decision-making is one of the major areas where their experience is becoming more and more important, particularly in the field of process management. It clarifies how business analysts can use data to optimize workflows and lead organizations toward long-term success.

Process Mining is a subject that has garnered a lot of attention over the past two to three years. Much of the noise has centred around the mergers and acquisitions in the vendor space, and contrary to what some write, it is still in its infancy when it comes to end user adoption.

Some academics and industry analysts suggest that Process Mining is a technique that replaces the need for traditional business and process analysis, but this is never likely to be the case. Instead Process Mining and its closely related cousin Task Mining, are complementary to traditional approaches, and should be thought of in the context of “and” rather than “or”.

For the past 30 or more years we have increasingly applied automation to processes, both with and without proper documentation. The result is that many of the processes we use, business decisions taken, rules applied, and customer journeys are now embedded or hidden within systems. This cloak of “invisibility” makes it practically impossible for us to apply traditional analysis techniques to discover and analyse these rules, processes decisions and journeys. 

An information system maintains data in fields within records. Equally important is the system’s ability to navigate between records. Parts 5 thru 9 of this series discussed fundamental business data field types. This article discusses a record navigation field. These fields do not themselves contain business data, but support the system’s ability to navigate from a given record instance to business data in related record instances.

It’s no longer rare to see machine learning (ML) models used to support a variety of business decisions, from whether a financial transaction should be sent to the fraud investigation team, to what discount a distributor should get.

Still, even in organizations that have embraced ML-based systems, it’s common for business problems that could benefit from machine learning to be solved using a less effective (and often more costly) approach. 

As a business analyst, it’s useful to be aware of some signs your business problem might benefit from ML...

A point in time field supports a business need for an information system to know when an event took place (or will take place). Date, Time, and Date/Time field values represent a quantity of time involving a specific unit of measure and precision. Like other quantity values, they can participate in calculations (E.g. subtracting one date from another to determine the number of days in-between).

Being “data-driven” doesn’t help create project success; being evidence-based does.  Evidence-based problem solving reduces the risk of blind spots and confirmation bias and increases the chances of achieving the desired outcomes. In high-stakes projects, risks can be dramatically reduced when a business analyst is willing to apply first principles thinking, hypothesis testing, and information value analysis to integrate the best evidence into the decision-making process.

A classification field allows the recording of a meaningful fact about a record instance, with that fact drawn from a pre-established set of values. Online access to values applicable to a given instance might be through a drop-down or pop-up list, or as labelled check boxes or radio buttons. The organization may be interested in just the values, or there may be additional information about each value that the system needs to manage.

Having discussed fields intended to name record instances, we move on to fields intended to satisfy the need to say something quantitative about a record. A quantity field requires particular attention be paid to its unit of measure (UoM) and precision. 

In this article we focus on record name fields. These fields are intended to contain a user-recognizable value by which a person or thing is known, addressed, or referred to. Unlike a record business identifier field, a name field’s value may change over time. Also, there are ‘real world’ names for things (e.g. people, cities) for which valid duplicate values can exist. 

Having explored information system record concepts, the objective of this article is to examine one particular type of field — the record business identifier. Its purpose is to uniquely identify an instance of a record.  Users of an information system are expected to have knowledge of, or access to, this value. The value is used to start down, or stay on, the ‘happy path’ of any business process that deals with the specific record instance it identifies.

Does it make sense to merge Agile philosophies with data science? The short answer is yes, as long as the organization recognizes and accommodates the ambiguous, non-linear nature of the data science process rather than expecting data scientists to fit into the same mold they’ve adopted for “Agile software development”. The problem, in my experience, is that this rarely happens. Probably because the data science field is still new, many organizations are still trying to shoehorn data science into Agile software engineering practices that compromise the natural data science lifecycle.