Business-process-modeling technology provides a powerful set of tools for describing and automating processes. The technology is so powerful that it often seems there are no limits to what BPM can do. But not every process that is automated needs BPM. Following on last week's discussion of process discovery, the JargonSpy asks the question: What sort of processes should be automated using BPM?
Businesspeople and technologists alike quickly get drunk on business-process modeling when they first become competent in the technique. Like wikis, business-process modeling allows you to capture the detail that you have in your head and then leave placeholders for what is not yet baked. In wikis, this takes the form of pages of text that link to other pages covering concepts that you will fill in later. Wikipedia is full of links to pages waiting to be completed.
The analogous act in business-process modeling is to put a box in to cover a step ("solve the halting problem" or "find qualified leads") that is part of the process but that you don't want to worry about just then.
Author: Dan Woods
Many people on our Business Analysis workshop ask why we use dataflow diagrams (DFDs). Why not Use Case…or even BPMN? After all DFDs have been around for 20 years, surely the world has moved on?
Well, has it? The primary purpose of a business analyst is to communicate – to stakeholders and to solution providers – and when it comes to communication we all know that pictures (diagrams) are much more effective and less ambiguous than words. Remember the phrase "A picture is worth a thousand words". The question is – which type of diagram best suits our needs? In this article, written by IRM's Training Services Manager Jan Kusiak, we’ll look at using diagrams for stakeholder communications.
Author: Jan Kusiak
Workflow analysis is an application of systems analysis to examine how the applications and tasks performed in an office or practice interact with each other, as well as with the staff performing them. Workflow software applies these analyses to make sure that the right staff member gets assigned the right task, along with the appropriate documents and data files.
Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste. In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge. Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics? Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.
Author: Glenn R. Brûlé
One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy.
When developing or changing a process, and all its related assets, often the process engineers have to face an important issue: how defining an integrated set of processes so that each process element is designed taking in consideration its relationships with all the other interfacing elements. Together with this issue, we also have the need to ensure that all the relevant requirements for the processes and their process assets are fully understood and correctly managed. These objectives are even more difficult to achieve when more persons are working in parallel to the improvement of different process areas. The approach described in the following paper, leverages a defined process architecture and a documented specification of process requirements to ensure integration among the process elements. All the examples are referred to a CMMI® based process definition but the most of the concepts are applicable also when adopting process models other than CMMI®.
Author: Filippo Vitiello, method park Software AG
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: