Академический Документы
Профессиональный Документы
Культура Документы
A Path to Successful
Business Process Management Projects
Executive Summary
The Metastorm STAR Implementation Methodology is a proven approach to rapidly deploying an organizations Business
Process Management (BPM) initiatives. STAR emerged from the fundamental principle that even the most complex
processes can be mapped back to Stages, Actions, and Roles hence the STAR name. By simplifying an otherwise
overwhelming challenge into something that is easily understood and embraced, STAR helps organizations overcome many
of the issues that often plague BPM initiatives, including acceptance, change management, scope creep, and lack of focus.
The Metastorm STAR implementation methodology and its associated process discovery notation the STAR Matrix were
designed to help organizations fully leverage the depth of capabilities and flexibility offered in the Metastorm BPM software
suite.
The STAR Methodology is comprised of 5 phases:
Design (detailed solution and architecture design, enhancement of prototype to convert to development model)
Construction (enhancement of development model to convert to complete application, project team testing)
Applying the Metastorm STAR methodology to an individual project will help ensure a successful BPM implementation and
help you realize an immediate return on investment (ROI) from the project. However, the more significant ROI emerges when
the organization as a whole embraces the BPM philosophy outlined by the STAR methodology.
To accomplish this, we recommend that a BPM Center of Excellence (CoE) be established. The BPM CoE would be the
driving and guiding force within the organization for all BPM projects. By centralizing and empowering a CoE, you will obtain
synergies between projects for those aspects that can be shared (e.g., training, help desk, HW environments). You will also
ensure that any opportunity to integrate your procedures is reviewed and evaluated centrally. With the CoE, you avoid silo
applications and ensure that all BPM initiatives are strategic and inclusive guaranteeing that youll see the biggest ROI for
your BPM investment.
While not all organizations are resourced to jump start their BPM initiatives with a CoE, it does not preclude them from
experiencing success with the STAR Methodology. In fact, as the BPM groundswell gains momentum with your deployment
success, your application of the methodology will prepare you for expanded enthusiasm and will help you to petition for the
CoE structure that will best benefit your organization.
Contents
EXECUTIVE SUMMARY..............................................................................................................................................................2
STAR METHODOLOGY ..............................................................................................................................................................4
5 POINTS OF STAR.....................................................................................................................................................................4
ENGAGEMENT ............................................................................................................................................................................5
KEY ACTIVITIES ..........................................................................................................................................................................5
Paperwork! ...........................................................................................................................................................................5
Groundwork..........................................................................................................................................................................5
Kick-Off ................................................................................................................................................................................5
SAMPLE ARTIFACTS ....................................................................................................................................................................6
COLLABORATION ......................................................................................................................................................................6
KEY ACTIVITIES ..........................................................................................................................................................................7
Requirements Analysis Workshops .....................................................................................................................................7
Process Discovery ...............................................................................................................................................................7
Develop the Skeleton Procedure .........................................................................................................................................8
Prepare the Functional Requirements Document................................................................................................................8
Define Key Performance Indicators (KPIs) ..........................................................................................................................9
Revisit the Project Plan ........................................................................................................................................................9
SAMPLE ARTIFACTS ....................................................................................................................................................................9
DEFINITION..................................................................................................................................................................................9
KEY ACTIVITIES ..........................................................................................................................................................................9
Define the Application Architecture......................................................................................................................................9
Add to the Skeleton Procedure ..........................................................................................................................................10
Draft the Test Plans ...........................................................................................................................................................10
SAMPLE ARTIFACTS ..................................................................................................................................................................10
CONSTRUCTION .......................................................................................................................................................................11
KEY ACTIVITIES ........................................................................................................................................................................11
Add Process and Integration Logic ....................................................................................................................................11
Add Administrative Forms and Reports .............................................................................................................................11
Prepare Documentation .....................................................................................................................................................11
Unit Test & Correct.............................................................................................................................................................12
SAMPLE ARTIFACTS ..................................................................................................................................................................12
TRANSITION ..............................................................................................................................................................................12
KEY ACTIVITIES ........................................................................................................................................................................12
QA and User Acceptance Testing......................................................................................................................................12
Finalize Documentation......................................................................................................................................................12
Deliver User Training .........................................................................................................................................................13
Announce System Availability ............................................................................................................................................13
Monitor Procedure and Look for Opportunities to Improve................................................................................................13
SAMPLE ARTIFACTS ..................................................................................................................................................................13
APPLICATION OF THE STAR METHODOLOGY BPM CENTER OF EXCELLENCE .........................................................13
KEY TO ACRONYMS & ABBREVIATIONS..............................................................................................................................15
STAR Methodology
Business Process Management (BPM) has become an operational necessity and the more forward-thinking organizations
are starting to understand that BPM can deliver not just efficiency and control but also agility, innovation, and overall
governance benefits that have the ability to support enterprise transformation and leadership.
BPM is more than just technology it is a philosophy that puts process at the core of all functions. To be successful,
business process management initiatives must incorporate people, methodology, and technology in a way that engages and
empowers everyone in the organization to work toward process improvement.
Being an early leader in BPM, Metastorm realized this and worked jointly with customers to tackle this challenge. The result
is the Stage Action Roles or STAR Methodology a unique approach to overall business process management that
complements the Metastorm BPM software suite and helps organizations achieve fast, repeatable success with BPM.
STAR emerged from the fundamental principle that even the most complex processes can be mapped back to Stages,
Actions, and Roles hence the STAR name. By simplifying an otherwise overwhelming challenge into something that is
easily understood and embraced, STAR helps organizations overcome many of the issues that often plague BPM initiatives,
including acceptance, change management, scope creep, and lack of focus.
STAR has proven time and again to be a key success factor with organizations implementing Metastorm BPM. The reason
for its success lies in several core characteristics:
It engages people.
It fosters collaboration.
It enables agility.
5 Points of STAR
The STAR Methodology doesnt completely reinvent the wheel it
draws from tried and true software development methodologies. The
STAR methodology resembles a RAD prototype-as-you-go approach
and also addresses traditional Software Development Life-cycle (SDLC)
phases, including initiation, requirements, design, development, testing
and deployment.
With both of those methodologies as foundations to draw from, the
STAR Methodology morphs into an approach that best fits the BPM
philosophy. It inherits discipline from the traditional SDLC and agility
from the RAD approach. This disciplined RAD enables STAR followers
to avoid typical project challenges (e.g., scope creep) and to quickly and
successfully deploy BPM solutions.
Engagement
During the Engagement phase in the STAR methodology, the vendor is
selected and the project is initiated.
Key Activities
Paperwork!
Before Metastorm begins a consulting services engagement, we
establish guidelines for our efforts to define terms of reference,
indemnity, insurance, etc. These are outlined in a Consulting
Agreement. The Consulting Agreement is negotiated and agreed to
once and will apply to all consulting work requested by the customer.
In addition to the Consulting Agreement, we will establish a Statement
of Work (SOW) for each individual services engagement. The SOW
inherits terms from the Consulting Agreement and additionally defines
scope and purpose of the project, high-level anticipated project
schedule, deliverables, hourly rates, and any other stipulations that
might need to be detailed independently from the Consulting Agreement
for the individual project.
Groundwork
Metastorm assigns a Project Manager to every customer engagement.
Prior to initiating a project, the Metastorm Project Manager (MPM) will work with the Customer Project Manager (CPM) to
draft a project plan and identify resource requirements. Many times, this is loosely completed as part of the pre-sales
activities to help estimate level of effort for the project.
Also as part of this groundwork activity, the MPM will review hardware and software requirements for the project and the
CPM will initiate procurement activities. Very traditionally, we recommend a minimum of three system environments:
Development, Testing, and Production. A number of our customers have also built a fourth Training environment to allow for
full flexibility in their end-user training schedule.
Kick-Off
With the paperwork in place and initial project plan defined, we can officially initiate the project by hosting the Project Kick-Off
meeting. The overriding purpose of this meeting is to clearly define the project mission and organizational value and to
outline how that mission will be achieved.
5
This also begins the process of engaging users in the BPM initiative.
Early involvement is the key to user acceptance of a new system, and
the most successful projects are those that empower users to improve
their own processes.
In addition to the project team, the direct business customer, the
customers network/IT team, and any other peripherally impacted
departments (e.g., any group owning an application that the solution
may need to integrate with) should be in attendance.
We take the opportunity with the full group gathered to review
Metastorm BPM concepts and terminology and to bring everyone up to
the same level of familiarity with what the Metastorm BPM software
suite is, why it was selected, and how it is going to be applied. We make
sure everyone understands our language so that as business users
begin to define requirements and model process flows, they are all
using the same terminology.
During the meeting, we review the STAR methodology and proposed
project plan. We stress to every participant what their role in the project
is and how their contributions affect results and project success. We
explain the value of a Configuration Control Board (CCB) and how it is
defined to keep the project laser-focused on the mission and to assist
with preventing project scope creep.
What is a CCB?
The CCB is collaborative team made up of
business and technical representatives. It will
act as an oversight committee throughout the
life of the project and then continue into the
life of the deployed solution. The primary
purpose of the CCB is to review reported
solution defects, change requests, and
enhancement requests to determine which
ones should be included in the current
release. The CCB team will prioritize each
item and review the level of effort estimates
associated with the items. The CCB approval
process facilitates keeping the project team
laser-focused on critical project tasks and
helps to avoid scope creep. While
deployment delays might still be introduced to
the project when the CCB approves change
and/or enhancement requests, these delays
would be forecasted and deemed acceptable
rather than unanticipated slippage from the
project schedule.
Sample Artifacts
The following list provides examples of the types of artifacts that will be produced during the Engagement phase of the STAR
Methodology:
Consulting Agreement
SOW
Draft Project Plan
Configuration Control Board Plan
Project Kick-off Agenda
Collaboration
Feeding off the energy generated at the Kick-Off meeting, we
immediately move into the Collaboration phase of the STAR
Methodology. The primary purpose of this phase is to solicit,
disseminate, and document the application requirements.
By the end of this phase the project team will have produced a skeleton
of the process map and associated forms and will be able to
demonstrate the process flow to the customer. It is during the
Collaboration phase that we begin to apply the disciplined RAD
techniques inherent to the STAR Methodology.
6
Key Activities
Requirements Analysis Workshops
The depth of requirements previously gathered and available to us
when we walk into a customers office always varies. Weve been
handed thick notebooks detailing system requirements weve been
shown process story boards weve been handed flow diagrams and
screen shots of existing to-be-replaced systems weve been handed
hard copy forms and some times we walk into a room with a white
board and start from zero. All of these are acceptable starting points for
the STAR Methodology. We will review any available requirements
artifacts and then begin the process of hosting Requirements Analysis
Workshops (RAWs) with the Subject Matter Experts (SMEs).
During the RAWs we are extracting information for two purposes. The
first purpose is to produce the Stage Action Roles (STAR) Matrix. The
second is to draft the Functional Requirements Document.
Process Discovery
Process Discovery is the phase during which users collaborate to
identify high-value process focus areas and to define critical process
components the components of the process that will ultimately come
together to form a cohesive process model.
Organizations often look to modeling notations to support this process.
Over the years, Metastorm has developed its own modeling notation to
support STAR and to fully leverage the advanced capabilities of the
Metastorm BPM product. The STAR Matrix that is created during
Process Discovery is the basis for this modeling notation.
We stated previously that even the most complex processes can be
mapped back to stages, actions, and roles and the exercise of
developing the STAR Matrix substantiates that statement.
While some customers have substantial process definitions completed,
for those that do not, completing the STAR Matrix facilitates process
discovery. For those that do, it validates and refines the process
definition.
We will ask questions during the workshop that step the SMEs through
their business process. What is the initiating action or the event that
kicks off your process? Who can take that action? What form do they fill
out? What happens when they have finished filling out the form? What stage does the process move to?
And from there, more questions. Which forms or what data should be visible at this stage? What data should be included on
each form? Who is responsible to take an action at this point in the process? Which actions can this person take? Are there
actions that one person can take and other actions that other people can take? What should happen as a result of each
action (e.g., Does it trigger an email to be sent? Does it progress the folder on to a new stage in the process?) Should
anyone be able to monitor the folder at this point?
As the workshops progress, our consultant will be transcribing this information into the STAR Matrix. The STAR Matrix
documents:
each stage in the business process
what data is visible at the stage
who can see the folder
who can act on the folder
what should happen as a result of each action
The STAR Matrix enables a quick transition from methodology to model to execution. That is, completion of the matrix allows
for rapid development of the process map which in turn enables the first demo with the business users. It has been our
experience that the sooner we have a demonstrable skeleton solution in front of the customer, the more able we are to stay
on schedule with the project and the more engaged the business users are in accepting the solution and embracing the
change.
A benefit of the Metastorm BPM product suite is that the process skeleton can be built using either the Metastorm Managers
Edition Designer or the full Designer. The Managers Edition Designer offers the same robust modeling and forms creation
capabilities as the full-scale Process Designer and is available as a free download from the Metastorm website. It strips out
the integration tools that business users do not need. The same process definition file built in the Managers Edition Designer
can be opened in the full Designer and immediately published for execution. The obvious value as your organization
embraces BPM is that your Business Analysts can define the STAR Matrix and prepare process skeletons, leaving your more
technical resources to focus their time on the deeper technical challenges of the project (e.g., defining integrations with other
systems or applying complex process logic).
Another benefit of the STAR Matrix is its ability to facilitate the identification of key services when implementing a Service
Oriented Architecture (SOA). Through the STAR Matrix, you will define points in the process where the system acts without
human involvement (in Metastorm terms these are System Stages). There will be other points in the process that require
human data entry (represented at User Stages in Metastorm BPM). From an SOA perspective, the system stages identify
needs for Business Functional Services and the user stages identify needs for Business Data Services.
STAR is designed to scale applying consistent implementation principles to even the most complex processes. The STAR
implementation methodology is not exclusive to BPM initiatives. STAR stands independent of our product and that
statement further supports its validity.
The STAR Matrix becomes the foundation for each process deployed on the Metastorm BPM solution it accelerates
deployment, helps to maintain focus, and fosters user acceptance.
Develop the Skeleton Procedure
Once the STAR Matrix is defined, we can very quickly convert it into an executable skeleton procedure. The value of
reaching this point cannot be overstated. By getting a working solution in front of your SMEs through a demo or even by
allowing them to independently play with the skeleton you very quickly receive feedback on the process flow and start to
hear the wait, we forgot X and you know we really dont need Y comments.
Sample Artifacts
The following list provides examples of the types of artifacts that will be produced in the Collaboration phase of the STAR
Methodology:
STAR Matrix
Functional Requirements Document
Skeleton Procedure Map(s) and Forms
Key Performance Indicator Definition
Final Project Plan
Definition
During the Definition phase, we review the artifacts produced during the
Collaboration phase and use them to define an appropriate application
architecture. We continue to add detail to the skeleton process map and
garner frequent feedback through interactive customer review sessions.
The Collaboration phase provided an understanding of what we need to
build. The Definition phase will establish the framework for how we are
going to build it.
Key Activities
Define the Application Architecture
There are many factors that determine the architecture of an application.
Functional requirements will obviously dictate aspects of the system
design. Anticipated user and network traffic will play into the decisions.
Integration points within the procedure factor in. Corporate policies, resource availability, and security requirements will also
contribute.
It is important to take all of these factors into consideration when establishing the application architecture. While the
procedure definition e.g., names of stages, number of actions, availability of actions to specific roles, etc. can all be easily
modified, re-structuring the architecture of your solution can be more challenging and, hence, more time consuming. This
then stresses the importance of a thorough and comprehensive evaluation prior to implementing the architecture decisions.
One output of this activity might be an Architecture Design Document. This not only forces the technical project team to think
through architecture challenges early in the life of the project but will also act as a valuable artifact for post-deployment
application maintenance.
Second to the Architecture Design, or potentially included in that design, would be plans for disaster recovery, anticipated
scaling requirements and plans to accommodate those requirements.
Sample Artifacts
The following list provides examples of the types of artifacts that will be produced in the Definition phase of the STAR
Methodology:
Architecture Design Document
Draft Test Plans RTM
Draft Test Plans Use Case
10
Construction
The development effort is completed during the Construction phase and
the solution evolves from a representative prototype into a sophisticated
application.
Key Activities
Add Process and Integration Logic
While the completion of the map(s), forms, and roles definition resulted
in a prototype of the final solution, the Construction phase adds
intelligence to the prototype. The project team begins to focus on
defining process logic. The process logic includes such things as
escalation rules, automatic emails, field dependencies, database
updates, and data-entry edit checking.
When the project team defined the STAR Matrix and Functional Requirements Document, they identified points in the
process where the application might interact with other systems. With all other development activities completed, the project
team turns their attention to the integration challenges.
The customer review sessions continue through the Construction phase to provide quick review and feedback on the
integration functionality.
Prepare Documentation
At the tail end of the Construction phase in the STAR Methodology, the full application has been completed.
To prepare for end-user training and to facilitate user acceptance testing, the project team will draft end-user documentation.
This documentation typically includes a Training Manual and a User Guide.
To support code promotion and long term system maintenance, the project team will draft a Procedure Installation Guide.
And lastly, with the application moving out of the Construction phase and into the Transition phase (which includes User
Acceptance Testing), the testing team finalizes the Test Plan document.
11
Once the unit testing is completed, the Construction phase ends and the
application is ready to be promoted to the Testing environment.
Sample Artifacts
The following list provides examples of the types of artifacts that will be produced in the Construction phase of the STAR
Methodology:
Completed Procedure Ready for QA Testing
Report Definitions
Final Test Plans
Draft Training Guide
Draft User Guide
Draft Procedure Installation Guide
Transition
The Transition phase is so named as it represents the point when the
project team transitions the code to the customer.
Key Activities
QA and User Acceptance Testing
Initially the customers QA team will evaluate the application to ensure
that it adheres to the requirements stated in the Functional
Requirements Document. Issues identified during the QA testing will be
prioritized by the CCB. Show Stopper issues will be corrected prior to
migrating the code to User Acceptance testing.
During User Acceptance testing, selected users outside of the project
team will review the application. They might run through the formal test
plans or might work with the system more informally. Again, issues that
the users identify will be prioritized by the CCB and Show Stoppers will
be corrected.
Finalize Documentation
The QA and User Acceptance testers will use the drafted Training Guide and User Guide. The IT team will use the System
Installation Guide to promote the procedure to the Testing environment. All of these groups will report documentation issues
to the CCB. The project team will finalize these documents by incorporating any Show Stopper issues.
12
Sample Artifacts
The following list provides examples of the types of artifacts that will be produced in the Transition phase of the STAR
Methodology:
Completed Procedure Ready for User Acceptance Testing
Final Training Guide
Final User Guide
Final Procedure Installation Guide
Summary of Testing Results
Completed Procedure Ready for Production
13
14
1-877-321-META (6382)
www.metastorm.com
Copyright 2007, Metastorm Inc. All rights reserved. Metastorm BPM, Enterprise Process Advantage and Process Pod are registered trademarks
of Metastorm Inc. Other product, service and company names mentioned herein are for identification purposes only and may be trademarks of their
respective owners. 6.13.2007
15