Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic. When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.
Lean techniques use a process-oriented approach. In non-industrial organizations however, the process is invisible. In order to apply Lean techniques successfully in this environment, the visibility of processes has to be significantly increased. Employees have to learn to look at their organization from a process viewpoint. Furthermore, it is important that the method is applied to all layers of the organization.
A swimlane diagram is a type of process flow diagram (also sometimes called a cross-functional diagram) that features divisions or "lanes." Each lane is assigned an actor (which may be an individual, department, division, group, machine, entity, and so on), or even a phase or stage in a process, that is responsible for the activity or work described in the lane.
In a process improvement project, the analysis team needs to model and examine several aspects of the current (AS-IS) value chain under study. The purpose of the analysis is to create a visual diagram of the value chain along with its associated text and metrics and determine if there are possible areas of improvement (e.g., reductions in cost or time). If improvements are identified, the team constructs a modified value chain model (TO-BE) with the improvements and then conducts a gap analysis on how to transition to the new value chain. This article focuses on the analysis of the current value chain by providing a method for structuring the AS-IS and TO-BE process improvement discussion.
I began my career at Cap Gemini Ernst & Young where doing business analysis and implementing large scale systems was my job. At that time, I just thought everyone intrinsically knew you had to understand the business and all the requirements before you begin designing a system (whether custom built or off the shelf).
Businesses cope with manual, repetitive tasks to get the job done. Email, conference calls, and "walking the cubes" are too frequently the process for requesting information, getting approvals, and checking project status. Time and resources are wasted, errors abound, and everyone is less productive.
Automating these everyday business processes is the way to improve productivity and gain efficiency. Traditional Business Process Management (BPM) systems can provide a solution, but the cost and complexity to implement simple processes is often too expensive for many business units.
The business analyst's job has changed this year -- and so have the critical skills that companies demand. New research shows that while communication is still key, knowledge of Lean and Agile methods is a must-have as well.
When the first flowcharts were applied to manufacturing processes, they followed the flow of a single part through its manufacture. They displayed, in sequence, the steps it took to make the part and they made sense. They were easy to visualize, easy to follow, easy to work with, and they resulted in millions of dollars worth of productivity gain.
This same concept was applied to information process charting in the 1940’s. However, rather than following a single flow, multi-flow process charts were used. They showed all of the records in a business process in order to make clear the exchange of information between records. Once again the effort generated millions of dollars worth of productivity gain.
A process is a series of steps completed to achieve a particular result. It is hard to imagine a process improvement effort that doesn’t start with a focus on that result with a question like “What is the purpose of this process?” - whether the customer is actually engaged or not. Sometimes we have a strong sense that our product or service is good. Sometimes we choose to “get our own house in order” before we step outside the organization. Sometimes we base the result on a prescription provided by the customer. However, sometimes, our focus may be misdirected to how we do the work without considering why it is done in the first place...particularly where slick new technologies are involved. In any case, without actually engaging the customer, we can’t really know how well the process is working to provide the customer with what the customer needs or wants.
Before starting, it is important to understand process mapping’s place in the larger context of business process improvement. Improving your process typically starts with documenting how it works today, what we call the “as-is” process.
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
Requirements and the way they are dealt with are decisive to the success of a project. This statement is never really questioned in modern software engineering circles.
Why is it, then, that a systematic requirements engineering (RE) system is so rarely established?
Where do the problems lie when it comes to implementing such a system?
This paper outlines the challenges and how these may be met using the example of the automotive industry.
Authors: Michael Gerdom and Dr. Uwe Rastofer, method park Software AG
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us