Entries for 'Transform VA'

BPMS has evolved and has come a long way over the past one or two decades. It's quite interesting to take a peek into the BPMS journey then and now. Business needs and technology, both have gone through a huge change in the meantime.

Right since the earlier days of BPMS, I always found working in this space quite an intriguing thing. The very capability of BPM to model, design, automate, run and track any process seemed to be extremely useful.

   So, what can you do to improve your workplace culture? A possible way to start is with the notion that culture is usually local. It is impossible to change the entire organization unless you’re the CEO, and even then, it’s hard. But it is not so hard to change local culture. Your team is a good place to start.

     We said that the first driver is about the value of people. Take the people in your workgroup and have lunch together. Every day. Talk to each other and talk about your work. We know you have a daily stand-up, but that is about progress and status of the work, it is not about the value of the work and how one person might be doing something that others do not understand. You can also talk about other things, there’s plenty to talk about. The intention of these sessions is to bring the people together and for them to understand the value of each other. It also makes a group more cohesive, and thus more likely to be forgiving, and so improve the behavior towards each other.

     Designing a new product is a messy process. It involves initial brainstorming, rough concepts, false starts, and extensive refinement. Good designs begin with an identified need or opportunity, and they’re based on a solid understanding of the product’s requirements. No matter how skilled the requirements analyst is or how informed and cooperative the customer participants are, the first set of requirements they develop will be only approximately correct. It takes a process of iterative refinement and validation to accurately understand the requirements for any nontrivial product.

Studying for your IIBA certification (CBAP, CCBA, or ECBA) can be a rigorous but ultimately fulfilling experience. But there is nothing worse than putting in all that time, work, and commitment and then FAILING the actual exam. Several disappointed candidates have sought guidance from me, unfortunately, after failing their first attempt at the exam. Before moving forward with these candidates, the first thing I do is get an understanding of the steps they previously took to study for the exam. This not only helps me get a baseline of how I can help them, but it also serves as inputs for how I can build courses and study tools that address these issues. So, to help you increase your chances of passing your IIBA exam on your first attempt, here are some of the top reasons people fail their IIBA exam.

With the massive shift to working from home we now see a plethora of tech companies flogging new employee surveillance tools. You can readily see their appeal to command-and-control thinkers. If you think, as they do, that managing employee activity is crucial, then to know who’s doing things and who’s taking the mickey is grist to their mill. But these tools will undermine performance and morale.

Think about it from the employee’s point of view. Your boss can see your emails, any documents you read or create, your appointments, who you talk to, and when; can listen to or read transcriptions of your calls. Your boss can see your computer screen, can monitor your internet use, the sites you visit and for how long. Your boss can even turn on your camera and watch you at work.

Product configuration requirements are a specialized type of requirement when an information system supports product-related needs through data values. Where there are specific changes to business processes needed to sell and/or operate a new product, the requirements for the information system to support activities within those processes involve standard functional requirements.

Whether an information system can support a product though configuration or requires custom development, when an information system is involved there are standard pre-go-live activities that need to be performed (e.g. testing). Requirements support those activities.

A diagram is a 2-dimensional representation of a story, which shows elements and their relationships on a single canvas. An element is shown on a single diagram. (To show the same element information on a 2 diagrams, the element is duplicated.) When the properties of a diagram element are changed, the change is reflected only on that diagram.

A model is a 3-dimensional representation of a collection of related stories, which captures diagram elements as model components. A component includes all element properties and relationships between different elements on all diagrams. A single model component can be shown as elements on several diagrams. A change to the properties of a diagram element or model component is reflected on every diagram where that component is displayed.

A model does not necessarily need to include any diagrams. Diagramming is the most common method for creating and maintaining model components, but the diagrams can be deleted without changing the model.

If a picture is worth a thousand words, then a diagram converts those words into a story. A model organizes those stories into a book.

How can we ensure that as Business Analysts, we are seen as an essential service for our organisation? It was a really interesting question. I thought I should elaborate on my answer I gave and write this article. I thought it will be helpful for:

a) Business Analysts to understand how they can operate within their organisation during this stressful time and
b) Companies to realise the value of Business Analysts and how they can use them to their advantage.

I wish to focus on explaining the reasons why a company should hold on to Business Analysts and leverage their skills in a way that will help them through these economically challenging times due to the pandemic.

Business analysts should bring more than an ad-hoc or experience-based business process modeling competence to digital transformation projects.  This article explains why and practically, how.  Here are 5 ways to improve your business process modeling competence and become better prepared for producing high-quality business process models that serve digital transformation projects

The reason to bring this up here in this post is to talk about the business analyst's role as a navigator. How good we are as navigators? In helping the conversations and collaborations? In writing the specs? Business analysts ensure that the system is being on the desired path and not on the exception path! I am sure we can argue that we want to build exception paths, errors, and scenarios that break the system. It is true. If we observe everyday linguistic patterns, there is a natural human tendency to talk about what we do 'not' want. Whereas what we 'want' is something that needs to succinctly be delved into. Is this a clever play of words? No. It is about utilizing 80/20 rule in thinking through what process or system you want to build. 80% on where you want to do and 20% on what exception and roundabout scenarios you can expect of. Let's take a few simple examples as we relate this to a business analyst's role.

Culture determines how people behave. If you want to change behaviour, you have to look to changing the culture. This is the story of how we changed the culture of a team of business analysts.

We inherited this team; they worked in an organisation where the culture was pretty poor. People were uninterested in their work. They resented the time they spent at work; they cheated on timecards; they simply did not do any work whenever they thought they could get away with it. Naturally enough, performance and productivity were abysmal.

Software handovers between teams and individuals in any ecosystem can be a minefield, often threatening to disrupt continuity and harmony across teams and organizations. In most cases, handovers result in knowledge loss, which in turn leads to chaos and time wastage when a critical issue hits the system. As a business analyst (BA), you will invariably be a part of the process, both at a junior and senior level. It is better to be fully aware of the complexities and pitfalls associated with taking part in a handover. You’ll eventually be able to apply some best practices to navigate around it (some of mine i hope and some of yours based on your context and area of operation).

How do we know when a user story is “done“? Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Business representatives may say yes, but they do not know all the peculiarities of software development. So, such criteria as quality are not fully visible to them.

Or let’s have a look at another situation: a new feature that changed the business process was developed and tested according to the best software practices, but users struggle to use this feature because they are not sure about the changes this feature brings. Maybe a proper user manual or user training is needed in this case?

In this article, a simple, but very powerful technique which is called Definition of Done (DoD) is explained.

As mentioned in my previous article Three Myths About Data Science Debunked, sooner or later business analysts will be involved a project with a machine learning or AI component. While BAs don’t necessarily need to know how statistical models work, understanding how to interpret their results can give them a competitive advantage.

This article discusses three concepts that can help analysts add value to data science projects (future articles will cover additional ones). Cultivating skills in these areas will increase your ability to build cross-functional alignment between business and data science teams and prevent bad decisions based on flawed analyses.

Integration requirements are critical for any Project’s success when Business Processes flow across multiple systems. As a Business Analyst it’s our responsibility to understand the end-to-end Business and Systems Process flow and document the hand off as part of the requirements gatherings process. A systematic approach to gather the requirements for integration between systems will ensure that there is a smooth interaction between the systems and hence the Business Process flow. The below Framework on Integration Requirements Analysis provides a systematic approach to document requirements for an Integration Project