General Business Analysis

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. 

Sometimes the best solutions are right in front of us, hidden in plain sight. Get in the habit of working from first principles and you’ll find it easier to cut through preconceptions to change the business question and quickly see alternatives that you may have missed.

The objective of this article is to help business analysts capture functional requirements for an information system as User Stories. It discusses four levels of story. The first two levels represent business context. Levels three and four involve functional detail needed by developers and testers to deliver stories at those levels.

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. 

We hear the buzzword “business transformation” everywhere. It has become almost expected of any organization to announce they are on their digital transformation journey. What does it mean?

There are many definitions of digital transformation. This abundance points to a broad interpretation of the term. The ambiguity of these statements reflects vague expectations of many organizations embarking on their “digital transformation journeys”.

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.

When engaging on projects we need to lead our clients to get the outcomes we need for analysis. If we act passively and don’t take charge then they’ll take things all over the place and create chaos. In this article we’ll explore how a problem statement acts as a powerful tool to keep control of our engagement and analysis right through the project lifecycle.

Taking a product from an abstract idea to an item that’s widely available in the marketplace demands a hands-on approach to prevent things from falling through the cracks. A technique that goes back nearly a century, product lifecycle management (PLM) has for decades been used to improve the efficiency of product development and design.

In recent years, however, a growing number of organizations are realizing the capability of cloud-based PLM software to drive fulfillment benefits. There is a recognition that you can strengthen your supply chain management by deploying PLM from product conception to multi-faceted fulfillment. As your product approaches maturity, it necessitates changes to workflow, supply chain, and fulfillment processes as a means of attaining sales objectives and driving overall business strategy.

But before we get into that and how PLM affects fulfillment, first a definition of PLM.

This article discusses record types supporting the concepts product, customer, sale, and location. The names given to these records varies depending on the line(s) of business an organization is in and, in particular, the organization’s sales processes.

This series is about understanding data fundamentals applicable to information systems. In this article and the next, record types specific to an organization’s line(s) of business are discussed. These records support maintaining data for an organization’s Products, Customers, Sales, and sale-related Locations. They will be viewed within the context of five generic line of business functions that represent the business processes involving any product as it goes through its lifecycle.

We begin our exploration of information system data fundamentals by looking at types of records applicable to any organization. Records such as     GL ACCOUNT, STAFF MEMBER, and ASSET are well-understood within any organization large enough to warrant information systems supporting Accounting, Human Resources, or Asset Management functions. These functions and record types are well supported today by commercial off-the-shelf (COTS) packages. So well supported, it’s difficult to imagine any organization justifying a decision to develop an in-house solution rather than buy a commercially available one.

A change request (CR) is basically any change in the initial set of signed-off requirements. So, typically in a waterfall model implementation, the requirements phase ensures that all the requirements (features/functionalities/functional and non-functional) are agreed upon and documented before development starts. After that, any new scope brought or requested by clients becomes a change request. There is an additional cost associated with implementing a change request.

Even in the agile model of working, although there is flexibility in the implementation of the project, vendors ensure that a high-level set of requirements are discussed and agreed upon. The iterative way of working ensures that clients have their eyes on the product as it is developing and can suggest corrections or alignments. However, no vendor can work with entirely flexible requirements. It's not feasible from a budgeting standpoint.

Have you ever wondered how global a career in Business Analysis might be? So, you roll up to your desktop or laptop every morning in an office or these days mostly likely at your workspace at home. You check your emails, plan the day, speak to your colleagues and manager, attend meetings and work your BA magic all within the boundaries of your project, client or organisation. Everyone speaks the same language and I’m not talking about English or Spanish, I mean tech speak, industry speak and BA buzz words like ‘moment of truth’. But what if you were to take your desk and move it halfway across the globe to a different country and time zone? Would organisations even face the same challenges most BAs are helping to solve and would teams use the same techniques to help solve them? I can answer that question with a resounding ‘Yes!’

Business analysts, process analysts, systems analysts, and process owners use Business Process Normalization to more effectively elicit and perceive, unequivocally define, and model sound, modern business process structures, and workflow configurations. Proficiency with this analysis technique benefits their process management, digital transformation, and regulatory compliance projects.

Thanks to infrastructure as a service (IaaS) and software as a service (SaaS) architectures, the utility of and business case for model-driven, no-code and low-code platforms have become more compelling than ever. More and more enterprises are entrusting their digital transformation, regulatory compliance, and business process management objectives to model-driven, no-code or low-code business application platforms.  These model driven platforms also raise the bar for the business process modeling skills of the business analysts, systems analysts and process owners who use them.