Вы находитесь на странице: 1из 15

Metastorm STAR Methodology

A Path to Successful
Business Process Management Projects

This white paper is provided courtesy of

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:

Engagement (project initiation)

Collaboration (communication of requirements, initial prototyping)

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)

Transition (customer QA and User Acceptance Testing, deployment activities)

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.

Metastorm STAR Methodology

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

Metastorm STAR Methodology

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 ties processes to metrics.

It enables agility.

It makes BPM manageable for large organizations.

It links business and IT users and aligns their objectives.

It uniquely supports achieving a true SOA.

It addresses the complete process life-cycle in repeatable fashion.

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.

Metastorm STAR Methodology

The five points of the Metastorm STAR Methodology are:


Engagement
Collaboration
Definition
Construction
Transition
While there are specific activities and deliverables associated with each phase of the methodology, project oversight and
monitoring activities are pervasive throughout. These include status reporting, risk management, issue mitigation, resource
planning, and generally acting as a liaison between the business customer and project team members.

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.

We can lick gravity, but


sometimes the paperwork is
overwhelming.
~ Wernher Von Braun

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

Metastorm STAR Methodology

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.

The Kick-Off meeting is an energizing session! The goal is to have


everyone leave that meeting enthused about the new project and eager
to play an active role in improving business processes and delivering measurable value to the organization through BPM.

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

Metastorm STAR Methodology

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.

What about Standards?


The nice thing about standards is that there
are so many to choose from.
NoS.one
can whistle a
~ Andrew
Tanenbaum

symphony. It takes a whole

We are often asked how emerging modeling


orchestra
playwith
it.
and execution
standardsto
interface
Metastorms STAR modeling notation and
~ H.E. Luccock
implementation methodology.

The short answer to this question is that most


of them offer only a subset of what Metastorm
STAR provides. Given that, many standards
can be incorporated into the Metastorm
process as sub-processes or they can be the
higher-level parent to a Metastorm process (in
the case of BPMN and BPEL models), while
others can be utilized as different ways of
viewing a process (as is the case with the
swim lane view). Regardless of the format,
all process documentation can be leveraged
in the creation of the STAR matrix.
The Metastorm BPM Suite is designed for
enterprise-scale process deployment within
and across organizations and as such it
supports a wide variety of standards,
promotes reuse of services in many formats,
and provides several ways of viewing
processes.
The STAR notation maximizes the
effectiveness of Process Discovery and
accelerates process deployment time
especially when multiple processes are going
to be deployed on the Metastorm BPM Suite.
It also has the added benefit of being intuitive
to business users and requires almost no
training.

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?

Metastorm STAR Methodology

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.

Prepare the Functional Requirements Document


Another artifact that is prepared as a by-product of the Collaboration activities is the Functional Requirements Document. An
initial list of requirements can quickly be prepared from the RAWs. This list will be enhanced and updated while the STAR
Matrix is produced and as the project team begins to receive feedback from the demonstrations and SME-use of the skeleton
procedure.

Metastorm STAR Methodology

Define Key Performance Indicators (KPIs)


Key Performance Indicators (KPIs) help you to define and measure your progress towards organizational goals. With the
completion of the Requirements Analysis Workshops and the Process Discovery activities, you have a better understanding
of your overall business process. This greater understanding will assist you in defining your process KPIs. By establishing
your KPIs during the Collaboration phase, you establish the benchmark to evaluate your success against once your solution
is deployed. Monitoring results is the key to success in any BPM project. Metastorm STAR instills this discipline throughout
the implementation. These results both tangible and intangible will help justify extension of BPM to future projects and
ultimately to an enterprise-wide deployment.

Revisit the Project Plan


With the knowledge and increased understanding of the business process obtained through the Collaboration activities, the
project plan will need to be reviewed and potentially modified to reflect a more confident project schedule. At the start of a
project, you dont know what you dont know. By the time youve completed the Collaboration activities, you will have a much
greater understanding of the scope and complexity of the project. With this knowledge, the Metastorm Project Manager can
work with the Customer Project Manager to finalize the Project Plan.

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

Metastorm STAR Methodology

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.

Add to the Skeleton Procedure


In the Definition phase, the project team continues to work on the skeleton procedure to evolve it into a fully functional
application.
Focus is initially placed on the process map(s). This may seem an arbitrary decision but it is actually a critical success factor
in our STAR Methodology. By developing the procedure from a process perspective rather than a forms perspective, you
identify the points in the process that will present forms for data gathering and review. With this knowledge, you can design
your forms for very specific purposes. A common mistake is to build the
forms first only to find out that the very elaborate form you built would
better fit the process model if it were broken into separate, smaller, more
It's really hard to design
functionally-focused forms.
Once the process map(s) are finalized, the effort shifts to detailing the
forms and then to defining the roles and applying them to the procedure.
Throughout the map, form, and role development, the project team holds
frequent customer review sessions to garner feedback and ensure that
the application aesthetics are acceptable to the end users.

products by focus groups.


A lot of times, people don't
know what they want until
you show it to them.
~ Steve Jobs

Draft the Test Plans


With maps, forms, and roles defined, the procedure begins to resemble the final solution. Using this early representation of
the final system in conjunction with the STAR Matrix and Functional Requirements Document, the testing team can draft the
Test Plans.
The structure and approach of the test plan document can be dictated by the customer preferences. We have produced
itemized functional test plans that include a Requirements Traceability Matrix mapping the individual test steps back to the
Functional Requirements Documents. We have also produced test plans that more closely resemble Use Cases.

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

Metastorm STAR Methodology

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.

Add Administrative Forms and Reports


With the application complete, the project team immediately begins to think of how they will monitor and maintain the
procedure and the customer immediately begins to think of the procedure metrics and reports that can be produced based
on that data that is being gathered. At a minimum, these reports should demonstrate project success against the defined
KPIs but the inventory of reports might extend beyond performance monitoring to satisfy the broader purpose of providing
transparent visibility into work items at all stages of your business process.
The final development tasks in the Construction phase are to develop the administration forms that will enable application
maintenance and to develop the initial reports requested by the customer.

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

Metastorm STAR Methodology

Unit Test & Correct


Before the completed procedure can be transitioned to the QA Testing
team, the project team must complete iterative unit testing and
correction. Typically, the full project team participates in the unit testing
activities. This becomes a test not only of the procedure but also of the
Test Plan document.

To err is human and to


blame it on a computer is
even more so.
~ Robert Orben

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

Metastorm STAR Methodology

Deliver User Training


The timing of user training is ideally scheduled just prior to the application going live.

Announce System Availability


The system is done. The testing is completed. Users are trained. Its time to Go Live!

Monitor Procedure and Look for Opportunities to Improve


Using the defined reports, customer management can monitor the effectiveness of the application against the KPIs.
Even better, you can feed a snapshot of live data into the Metastorm simulation product, Metastorm Envision, to identify
areas that could be modified for improvement. With the results of your simulation runs, you can intelligently modify your
procedure to optimize and enhance performance. With the modifications defined, the STAR Implementation Methodology
begins again as you gear up to produce Version 2 of your solution!
When approached strategically, BPM is an iterative process that delivers both an immediate and on-going return to the
business.

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

Application of the STAR


Methodology BPM Center
of Excellence
Applying the STAR methodology to an individual project will result in a
successful implementation and immediate BPM ROI. 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.

13

Metastorm STAR Methodology

Justification for a CoE includes Business drivers:


BPM can deliver extremely efficient ROI if the business and IT organizations work together the CoE acts as the
liaison and authority to drive logistics between these departments.
Process capital resides in individual business units and tool expertise lives in IT dept the CoE bridges this gap.
The CoE can champion support for Business Development efforts (e.g., provide BPM expertise for RFP responses)
and serve as a sounding board for innovative process ideas.
The following IT objectives can also benefit from the structure provided by a CoE:
Develop in-house product BPM and SOA expertise.
Define and practice the STAR implementation methodology universally throughout the organization.
Enforce configuration management and change control.
Achieve a scalable cost effective server infrastructure.
Create re-usable integration components and CoE libraries.
Employ a centralized integration approach to other enterprise application investments.
By centralizing and empowering a CoE, you will obtain synergies between projects for those aspects that can be shared
(e.g., training, help desk, software and hardware 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.
In the January 2007 Business Process Trends report A Survey of Business Process Initiatives, Nathaniel Palmer writes
organizations with an identified BPM Center of Excellence reported five times greater ROI over those with no Center of
Excellence or dedicated process team. Similarly, those with a dedicated business process team in place reported nearly
twice the ROI of those without any dedicated team in place.
While the impact of a CoE is glaring in the Business Process Trends report, we understand that not all organizations are
resourced to jump start their BPM initiatives with a CoE. This does not preclude you 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.
Bottom line there is no additional resource commitment associated with using the STAR methodology for a one-time or
multiple process projects versus applying the methodology with the intention of developing a CoE. With or without a CoE,
each successful STAR Methodology project is truly a building block towards the achieving process excellence.

14

Metastorm STAR Methodology

Key to Acronyms & Abbreviations


The following acronyms are used within this document.
BPEL
BPM
BPMN
CCB
CoE
CPM
KPI
MPM
QA
RAD
RAW
RFP
ROI
SDLC
SME
SOA
SOW
STAR

Business Process Execution Language


Business Process Management
Business Process Modeling Notation
Configuration Control Board
Center of Excellence
Customer Project Manager
Key Performance Indicators
Metastorm Project Manager
Quality Assurance
Rapid Application Development
Requirement Analysis Workshops
Request For Proposal
Return on Investment
Software Development Life-cycle
Subject Matter Experts
Service Oriented Architecture
Statement of Work
Stage Action Roles

1-877-321-META (6382)

+44 (0) 208-971-1500

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

Metastorm STAR Methodology

Вам также может понравиться