As Business Analysts, when we’re at the sharp end of solution delivery that doesn’t match a customers needs, at that time it just can’t be rectified and we can’t help thinking that we might have been able to prevent this at the early stages. In this article we’ll explore 3 ways to get out the trap of being solution oriented up front to shift more into the problem and needs to get better requirements.
In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.
The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile. A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.
Being successful as a business analyst is not a feat - reserved for a select few. Neither is it rocket science. It is achievable and within your grasp, if you apply a well-rounded approach to how you manage your career. While these tips are centered around the business analysis career, they can be applied to any career.
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”.
What is Use Case?
Use case represents requirement in the form of user interactions with the system. Use case is always written with a specific user goal in mind. Each use case must contain an actor and verb. For example, ‘online buyer’ is an actor and ‘add item to cart’ is a verb.
A use case diagram represents the scope of all the features of the solution. It follows Unified Modelling Language™ notation. Use case diagram comprises of several use cases that make the system altogether.
What is User Story?
User story is a business analysis artifact that is also user or persona driven. It describes the business need in the form of an ability user (or system) wants in the solution. It also must state why the ability is required and what the benefits of that ability are. It does not have any mandatory format though
User story is part of the (product/project) backlog. The backlog in turn contains user stories/tasks (requirements) in a linear fashion. Backlog is usually prioritized from high to low, additionally with a ranking when priorities are the same. When it is prioritized by business value of the tasks/stories in it, it is called managed backlog. In many projects, user stories are also represented visually as a user story map, which is a structured visualization of a backlog. User story map is a map of user stories that are transposed from a linear backlog, onto a visual working board.
Each of this concept is a detailed topic in itself. For the context of this article, I will limit it only at the introductory level. Let's now look into differences and similarities between user stories and use cases.
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.
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.
Data has emerged as the sole driver of the digital transformation of the present world. It has turned into the most significant resource, and without it, one couldn't really expect to succeed in today's crowded market. Organizations should proficiently utilize their data since it very well may be a factor that can differentiate you in corporate development. This requires the compelling combination of artificial intelligence with data analytics for enhancing business processes. The automated direction along with data-driven decision-making is rapidly turning into the standard in this digital world. Since the assortment of data and its analysis is more reachable than any time in recent memory, organizations of all shapes and sizes are leveraging this innovation, hence, noticing noteworthy outcomes. Yet, luring those significant experiences out of your data can be challenging when you reach "big data" extents.
I’ve written this article to provide an overview of AWS (Amazon Web Services) for Business Analysts.
The cloud (in particular AWS) is now a part of many projects. If you’ve been in meetings where people have mentioned: ‘EC2’, ‘ELB’, ‘AZs’ and thought ‘WTF’ then this article should help you.
This article will provide:
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.
There are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.
A picture is worth a thousand words. Charts offer visualization and help to understand and comprehend things that would be more painful and time consuming to understand by reading free text. Diagrams help us design systems and processes, organize our screens, while facilitating a common understanding of the big picture. They help us make visible the invisible.
Αs a BA you can exploit a big variety of diagrams to help you communicate better and more accurate information concerning the requirements and the solution. Diagrams leverages the effective use of visuals and modeling techniques in helping organizations and individuals work from the 30,000 foot view down to the level of detail that is needed by those who are actually going to perform the process activities. Moreover a diagram can serve as a single point of truth navigating what should be done and saving time from questions deriving from ambiguous point may found in a text.
As a data analyst, you feel most comfortable when you’re alone with all the numbers and data. You’re able to analyze them with confidence and reach the results you were asked to find. But, this is not the end of the road for you. You still need to write a data analysis report explaining your findings to the laymen - your clients or coworkers. That means you need to think about your target audience, that is the people who’ll be reading your report. They don’t have nearly as much knowledge about data analysis as you do. So, your report needs to be straightforward and informative. The article below will help you learn how to do it. Let’s take a look at some practical tips you can apply to your data analysis report writing and the benefits of doing so.
brought to you by enabling practitioners & organizations to achieve their goals using: