General Business Analysis

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.

The practical applications of data science are multiplying. From predicting if a delivery will arrive late to recommending how much herbicide to use to save money and protect the ecosystem, there are endless examples of organizations harnessing data science solutions to improve the efficiency and quality of business decisions.

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.

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.

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).

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.

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 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. 

Is there something called as Agile BA or DevOps BA? Or is there a dedicated role such as ‘BA in DevOps’? How are Agile and DevOps related? How does BA role change or goes through metamorphosis, when it comes to DevOps?

One day, I got a corporate training enquiry and that is when I heard the term ‘Agile BA’ for the first time. At that time, I had already worked on Agile projects yet nobody had referred to my role particularly as Agile BA. A thought came to my mind, what if there was a job post saying “looking for a ‘Waterfall BA’?” I even heard once: “With DevOps there is hardly any role a need for BA or PM”.