Bruce Silver Associates

Transcription

Bruce Silver Associates
The BPMS Report
Independent Expertise in BPM
LOMBARDI TEAMWORKS 7 ENTERPRISE
1. Vendor and Product Overview
Lombardi Software is a private company focused exclusively on Business Process Management.
Based in Austin, Texas, the company was founded in 1998, and has approximately 220
employees. Lombardi helps companies improve human productivity with business process
management. In order to maximize these productivity gains, many Lombardi customers are
moving to cross-company BPM programs, involving several key elements from Lombardi:
•
Lombardi Blueprint for documenting and discovering business processes by allowing
people across the organization to participate in BPM in a scalable, coordinated fashion.
•
Lombardi Teamworks for building and managing process applications in a single
executable platform.
•
Lombardi’s agile/iterative approach to developing and deploying BPM across the
organization;
•
Lombardi University for developing the right skills across a variety of roles to identify
productivity opportunities and to convert them using BPM.
Lombardi’s BPMS, called Teamworks, is best known for human-centric processes that change
dynamically based on business factors, such as dispute resolution, product returns, tax
reconciliation, loan origination, or supply chain management. Lombardi describes Teamworks as
focused on “operational processes,” meaning complex flows spanning organizational and system
boundaries, characterized by four distinct attributes:
•
Processes with impact on overall business performance, such as inventory, DSO, cycletime, customer retention – strategic business processes affecting the bottom line
•
Processes subject to continual change
•
Processes requiring monitoring and management of exceptional events
•
Processes requiring real-time visibility and optimization of system and user performance
Lombardi’s agile/iterative approach is based on business-IT collaboration via the Teamworks
shared process model, meaning a single process model used for both description/analysis and
runtime execution. To reinforce the shared model approach, Lombardi was an early adopter of
the BPMN standard and has played an important role in driving its development.
A sampling of Lombardi customers and applications includes:
•
Ford Motor Company, a Lombardi customer for the past three years. Lombardi is the
industry standard across Ford for building BPM solutions. Ford has an internal Center of
Excellence BPM team and leverages Teamworks in a variety of processes, including
Engineering Change Management, Advanced Product Sourcing and Process Driven Build
of Materials (BOM).
•
SIRVA, Inc., a leader in providing relocation solutions to a diverse customer base around
the world. Lombardi is used to simplify the relocation experience for individual
consumers and about half the Fortune 500. The implementation automates and adds
visibility across SIRVA’s service offerings (home finding, home buying, title, mortgage,
© Bruce Silver Associates 2009 www.brsilver.com/wordpress
500 Bear Valley Road
Aptos CA 95003 USA
Contact: Bruce Silver, Principal [email protected] +1 831 685-8803
BPMS Report
Lombardi Teamworks
etc). The solution provides a standard way to execute business processes globally across
the organization.
•
Wells Fargo, a Lombardi customer for over 5 years applying BPM across the business
through dozens of process applications; from Fraud Tracking to Leasing to New Dealer
Setup. Wells Fargo Mortgage has built an entire Loan Origination process application on
Teamworks managing everything from application to fund.
•
Aviva (LSE: AV), the world’s fifth largest insurance group and the largest insurance
services provider in the UK. Lombardi Teamworks is managing Aviva's Human
Resources employee Joiners, Movers and Leavers (JML) process within Aviva group
centre. Aviva is also using Lombardi Blueprint to map and refine its IT Quality
Management System (QMS) in the UK general insurance business. Blueprint helps the
company to collect a wider set of input and comments from a broader set of Subject
Matter Experts, ensuring that the effort is completed with a greater level of control and
speed.
This report will concentrate on the following components of Lombardi’s BPMS offering:
•
Teamworks 7 Enterprise is a complete BPM suite supporting modeling and simulation
analysis, human workflow, integration, business rules, and performance management.
•
Blueprint is a hosted web-based environment that provides an extremely businessfriendly front end to BPMN modeling and supports team collaboration. Blueprint models
can be exported to Teamworks for implementation.
•
Teamworks for Office 2007 is a Teamworks add-on that provides access to tasks,
performance metrics, and other BPM artifacts through Microsoft Outlook, Word, and
Excel rather than from a web portal. Teamworks for Office also supports InfoPath forms,
.Net web service APIs, System Management Server, Active Directory Group Policy
Objects, and other Microsoft platform components and services, simplifying enterprise
deployment in Microsoft shops.
•
Teamworks for SharePoint 2007 is a Teamworks add-on that provides team
collaboration features through Microsoft SharePoint and access to Teamworks Inbox,
task execution, and reporting capabilities through SharePoint web parts.
2. Environment and Architecture
2.1
Runtime Architecture
The Teamworks 7 Enterprise runtime consists of the Process Server, Performance Data
Warehouse, and Process Portal.
The Process Server is responsible for managing and executing process model definitions and inflight instances. This server provides workflow facilities, such as task management as routing, as
well as rule evaluation, simulation, and other capabilities. Process components are stored and
shared as XML in the process repository within the RDMBS.
Teamworks provides extensive levels of caching to optimize run-time performance. Process
execution is dynamic, evaluating each step and transition within the process diagram in real time.
In addition to Process Server’s internal execution capabilities, Teamworks also provides several
frameworks that enable integration, event monitoring, and security.
© Bruce Silver Associates 2009
2
BPMS Report
Lombardi Teamworks
Teamworks Connector Framework provides connectivity to external systems, databases, and Web
services. Teamworks connectors can be implemented using remote client API libraries, SOAP
Web service protocol, or message-based connectors that implement the JCA standards.
Application-specific connectors are available in Teamworks and through a partnership with iWay,
a third-party provider of native data, application and integration connectors. Integration
definitions created in Teamworks are stored in the Process Library and can be used by any
process. Additionally, any process or subprocess in Teamworks can be exposed as a Web service
with a click of the mouse, enabling process reuse through a service-oriented architecture.
Embedded in the Process Server is the Event Manager, responsible for time- and event-based
process activities. It includes an HTTP listener, JMS listener, event scheduler, and execution
queues. Events may be generated by the Teamworks process itself or received from external
systems and processes. Events received via the Teamworks Messaging Framework from external
services via JMS, HTTP, or SOAP are automatically correlated to the appropriate business
process instances using configurable matching logic. Internal event examples include Timer
Events, used to define escalation rules within the process, as well as Exception Events, or paths
that provide the mechanisms for “throwing” and “catching” process exceptions (which are most
likely asynchronous). All events, triggers, and deadlines that govern process management can be
modeled directly in the process diagram in Teamworks.
Figure 1. Teamworks runtime architecture. Source: Lombardi
Teamworks externalizes all of its security and authentication in an open architecture based on the
Java Authentication and Authorization Service (JAAS) standards. Security may be managed by
the default Teamworks provider, by the application server, an LDAP server, or a mix of security
providers. Direct support for products like Microsoft Active Directory and other LDAP servers
simplify user management. No maintenance of Teamworks is required when users are added,
3
BPMS Report
Lombardi Teamworks
deleted, and modified in these systems, and support for single sign-on products like Netegrity
allows customers to leverage their enterprise authentication investments.
Teamworks Performance Data Warehouse collects performance data representing key business
events and metrics as processes are being executed. Performance management is completely
model-driven, using the process model to define the business events and metrics, event
correlation, and aggregation of the performance data. During execution, Teamworks Performance
Data Warehouse retrieves tracked data from the Process Server or Process Center Server at
regular intervals, then correlates business events in real time and aggregates performance data
into a single database view for reporting and auditing. Users can create and view reports that
leverage this data in Teamworks Authoring Environment and Process Portal.
Tracked data is stored in the Performance Data Warehouse using a fixed physical schema. Since
the underlying schema never changes, performance tracking can be added or changed at any time
without requiring underlying database changes or adversely affecting existing reports. This
greatly simplifies deployment of new performance tracking.
Figure 2. Clustered deployment topology. Source: Lombardi
Taking advantage of the data-driven architecture, Teamworks services are largely stateless, which
ensures linear scaling, meaning that adding a server will add a specific amount of capacity, which
is an important factor to lowering the total cost of ownership of large applications.
The Process Portal provides a browser-based interface through which users can perform tasks,
view task history, and visualize performance of their processes and teams. Process participants
have access through the Process Portal to process definitions on the Process Center Server and
4
BPMS Report
Lombardi Teamworks
runtime information on a Process Server in any configured runtime environment, test or
production.
Each layer of the Teamworks Enterprise runtime configuration – database, application server,
web server, and client – must be optimized for the number of users and transaction load. The
Teamworks application runs inside a J2EE-compliant application server through a Java Virtual
Machine (JVM). The application server handles basic connections and containers for Teamworks,
as well as the underlying security and permissions. Teamworks runs on Unix, Linux, or
Windows operating systems using embedded JBOSS J2EE application server, but also supports
WebLogic or WebSphere. Teamworks supports any JDBC-compliant database for the repository
of design-time and runtime information, called the Shared Model.
Teamworks servers may be partitioned for autonomy, or load-balanced and clustered for
increased scalability and availability. High scalability and availability are achieved through
clustering and redundancy at each layer of the application. The web servers can be clustered to
support a large user community. Application servers can be clustered for high volume and a large
user community. The DBMS layer can be replicated, mirrored, or clustered for high scalability
and availability. Figure 2 illustrates a single clustered topology; Teamworks also supports
multiple-cluster arrangements and is compatible with common high-availability (HA)
infrastructure.
Figure 3. Teamworks design-time environment. Source: Lombardi
2.2
Design Environment
The Teamworks 7 design-time environment (Figure 3) includes the Process Center repository and
Teamworks Authoring. Process Center enables a centralized development environment for
distributed authoring teams. In the Teamworks Authoring Environment, users create process
models and supporting implementations called process applications, and store those applications
and associated items in the Process Center repository. Process Center also includes the Process
Center Server and Performance Data Warehouse, allowing users working in Teamworks
5
BPMS Report
Lombardi Teamworks
Authoring Environment to run their process applications and store performance data for testing
and playback.
2.2.1
Process Center
All process artifacts created during design and development are stored and maintained in a central
repository, the Teamworks Process Center. A graphical view of the Process Center (Figure 4)
provides authors and architects with access to the organization and management of all process
artifacts, process applications and reusable functionality that are created as part of a BPM
Program. Projects are organized into either individual process applications or groups of reusable
components called toolkits.
A process application contains all artifacts needed to define an executable process solution,
including process definitions, services, variables, task user interfaces, rules, etc. Workspaces are
optional subdivisions of a process application based on team tasks or process application
versions, enabling parallel development. Snapshots record the state of all items in a process
application or workspace at a specific point in time, used for interactive unit testing called
playbacks or comparison with previous versions.
Figure 4. Teamworks Process Center. Source: Lombardi
Process Center is architected for massive reuse of design artifacts, both within and across process
applications, through reusable containers called toolkits. Items stored in the Process Center
repository support versioning through snapshots (Figure 5). Process designers can create a
snapshot of a process or service with one mouse click, and can revert to a previous version just as
easily.
6
BPMS Report
Lombardi Teamworks
Figure 5. Process Application Snapshots and Deployment. Source: Lombardi
Toolkits allow Authoring users to share library items across process applications. By creating a
dependency on a toolkit, a process application (or another toolkit) has access to the library items
it contains (Figure 6). The System Data toolkit, including standard variable types, standard
charts, and so on, is made available by default with the Teamworks installation.
Figure 6. Toolkit Dependency. Source: Lombardi
Snapshots and toolkits are centerpieces of Lombardi’s effort in Teamworks 7 to enable largescale reuse of design artifacts. Toolkits collect items reused together and can be versioned just
like process applications. The dependency is on a specific version of the toolkit (Figure 7).
When a toolkit version is updated, applications with a dependency on it have the option of
upgrading the dependency to the new version, or not.
7
BPMS Report
Lombardi Teamworks
Figure 7. Artifact reuse through toolkit dependencies. Source: Lombardi
2.2.2
Teamworks Authoring
Teamworks Authoring (Figure 8) is a comprehensive Eclipse-based modeling and design
environment shared by business and IT. It includes several views, selected from below the menu
bar (#1), each a distinct Eclipse perspective.
Figure 8. Teamworks Authoring, Designer view. Source: Lombardi
8
BPMS Report
Lombardi Teamworks
Figure 8 illustrates the Design view. Other views include the Optimizer view and the Inspector
view. The navigation tree in the left pane lists categories of Teamworks Library items that can be
viewed and edited (#3), including, from top to bottom, items from the currently open process
application (#2); models imported from Lombardi Blueprint; reusable item containers called
Toolkits; and Smart Folders such as Changed This Week, customizable named queries for
commonly accessed library items. Items can be designated Favorites or tagged for easy access.
Below that, the Revision History pane (#4) lists named versions (snapshots), and allows reversion
of the design environment to any past point in time. The main editor pane on the right provides
graphical drag and drop modeling of the selected library item (#7), including processes, services,
variables, and key performance indicators.
A key new feature of Teamworks has been brought over from Blueprint: concurrent editing.
Teamworks lets multiple users to simultaneously access and modify library items in the Designer
view. Each user must be connected to the same Process Center and have write access to the
process application or toolkit where the library items reside. When multiple users are working on
the same item, each can see the changes as they take place, in real time (Figure 9). Concurrent
editing enables true team collaboration in building process applications. Team members can
communicate using instant messaging and see the results in the Designer view as they happen.
Figure 9. Concurrent editing support in Teamworks Authoring. Source: Lombardi
3. Process Structure and Data
3.1
Concepts and Terminology
Lombardi’s conceptual model and terminology closely mirror the BPMN 1.2 standard. A process
is contained in a pool, which may be subdivided into lanes containing activities performed by
users and systems, gateways that control flow, and events that synchronize process execution with
signals received from external systems or from the process itself.
An end-to-end process, called a Business Process Definition (BPD) may include multiple BPMN
processes interconnected by nesting and chaining. A nested process is represented by a
subprocess activity in the diagram. A running process is an instance of a BPD. The BPMN
9
BPMS Report
Lombardi Teamworks
process that creates the instance is called a root process, and its instance ID can be used to
correlate instances of nested and chained processes with the BPD instance. The set of all
information about a running instance that is available to the process engine at runtime, such as
values of variable values, is called the execution context.
3.2
Process Structure
In Teamworks, activities specified using BPMN in the process definition editor are abstract in the
sense that they do not contain implementation details. Those details are provided in the
specification of the activity’s implementation, typically modeled by IT. This architecture
provides a clean separation of concerns between business and IT while retaining the essential
character of collaboration and shared notation throughout the BPM lifecycle.
Process designers have the following options for activity implementations, each with its own
editor:
•
Service, either Integration, Human, Ajax, Rule, or General System service.
•
Nested process, a reusable subprocess called by the activity.
•
Javascript, typically simple automated activities.
•
External, such as an Eclipse RCP or Microsoft .Net application.
If a Process Modeler activity is in a user lane, the Teamworks Human service sends one or more
tasks to a user or role. (Multiple tasks will be sent, for example, in a looping activity.) Tasks
have envelope properties such as who they are assigned to, their due date, and which users have
performed the service in the past. If the activity is in a system lane, its implementation, or
method, is performed by the Teamworks engine. A business rule is a special type of service (rule
service). While services are normally invoked by its attached process activity, they can also be
run standalone, invoked independently of a business process.
Human services in Teamworks are frequently implemented as web applications in which multiple
web pages or forms, called Coaches, allow the user to perform database lookups or execute other
automated functions, and display other Coaches. The logic flow of Coaches and system activities
in a service, as well as its event- and exception-handling behavior, is specified graphically in
Service Modeler.
One of the BPMN activity properties supported by Teamworks is looping, meaning the activity is
performed N times, where N may be determined at runtime. Iterations of the loop may be
sequential (called simple looping) or parallel (called multi-instance looping). Each multi-instance
loop represents a separate task. By default, the running process waits for all instances to
complete before it flows to the next step. However, a JavaScript condition may be defined to
require only a specified number or fraction to complete, or a time limit.
Teamworks supports many advanced BPMN constructs not allowed by other tools, including
activity looping and intermediate events. Looping means an activity is performed N times, where
N may be determined at runtime. Iterations of the loop may be sequential (called simple looping)
or parallel (called multi-instance looping). Each multi-instance loop represents a separate task.
By default, the running process waits for all instances to complete before it flows to the next step.
However, a JavaScript condition may be defined to require only a specified number or fraction to
complete, or a time limit.
10
BPMS Report
Lombardi Teamworks
Figure 10. Dynamic Subprocess definition. Source: Lombardi
Unlike some other BPMSs that claim BPMN compliance, Teamworks supports most of the
BPMN event types, including message, timer, exception, and terminate, and supports boundary
events. A boundary event, drawn on the boundary of an activity, signifies that if the event occurs
(message received, timeout, exception, etc.) while the activity is running, the activity terminates
and flow continues on the path linked to the event.
Nested processes provide a way to link processes together in a parent-child relationship. They
provide a way to encapsulate logically related steps within a process while retaining the highlevel view of the parent process. Teamworks allows nested processes to be called dynamically,
i.e. the particular nested process to call is determined at runtime, using a string variable (Figure
10).
3.3
Process Data
Teamworks variables represent data structures or business objects (Figure 11). Most variables
are local variables, available only within the process or service level in which they are defined.
Calls to activity implementations therefore usually involve data mapping to the called interface.
Teamworks distinguishes between input/output variables, which are used in data mappings, and
private variables, which are just used internally to a process or service.
Each data element in a variable has an assigned type (string, integer, date, etc.), and Teamworks
provides methods to return values for each type. Thus the year value from a variable myDate
using the getFullYear method is represented in Teamworks as tw.local.myDate.getFullYear(). In
addition to simple base types, Teamworks supports arrays, various XML types, Records, and
other structured types. Variable definitions can specify initialization rules for each element
(Figure 12), and each activity in the process can manipulate variable values through Pre and Post
assignment rules executed before and after the activity runs.
System variables describe the user, client and server environment. System variables are read-only
and accessible to all run-time process instances.
11
BPMS Report
Lombardi Teamworks
Figure 11. Teamworks variables represent business objects. Source: Lombardi
Figure 12. Specifying Teamworks variables. Source: Lombardi
12
BPMS Report
Lombardi Teamworks
Exposed process values (EPV) are a special type of variable that can be manipulated at runtime
through performance management ScoreBoards. EPV values are typically used as parameters in
conditional process logic such as gateways, and can be adjusted on the fly by authorized users to
maintain optimum overall performance, similar to business rule parameters in a rule maintenance
application.
Data mapping is used to pass the values of variables between a runtime task and a Teamworks
Service. When a service is attached to an activity, the activity’s Data Mapping tab is populated
with the input and output variables of that service.
4. Process Modeling and Design
4.1
Business-IT Interaction
Of all the BPMS vendors, Lombardi has been the most forceful and effective advocate of
business-driven implementation based on rapid iterative development involving business and IT
working in close collaboration. Support for full BPMN, including events, is a key enabler of this
approach, but Lombardi takes it even further, providing an even more business-friendly front end
to BPMN in Blueprint. Moreover, Teamworks, as the more advanced modeling and design
environment, can synchronize automatically with any changes made in Blueprint through a
publish-subscribe mechanism, and vice versa.
Another example of how the product architecture supports the collaborative design philosophy is
the clean separation between process modeling, done by business analysts, and service modeling,
done by developers. A service is the graphical (BPMN-like) composition of the implementation
of a process activity, composed in a separate tool within the same Authoring Environment. Thus
implementation details or changes do not invalidate the business analyst’s ongoing view of the
solution throughout the lifecycle.
Iterative design principles are further reinforced by the ability to play back any component or
fragment of a business process – a service, human task, or subprocess – at any time, instantly
from the design environment. No deployment is required, and you can easily compare the current
version with any previous snapshot. Default services for any process activity, including task user
interfaces, are created automatically, allowing instant playback without specifying any
implementation detail at all. Users can see the effect of design changes immediately, and
iteratively improve the solution. The Playback feature in Teamworks Authoring is a distinct
differentiator and central to Lombardi’s rapid iterative approach to process design.
4.2
4.2.1
Process Modeling
Modeling in Blueprint
In Blueprint, Lombardi has created a radically innovative approach to engaging business users in
process modeling. Blueprint is a hosted modeling environment that not only offers real-time
team collaboration, but significantly lowers the learning barriers to process modeling. Instead of
a structured modeling notation that you need to learn, Blueprint takes as its visual metaphor the
outline view of PowerPoint, familiar to nearly everyone. You just type a few words into an
indented list in the outline (Figure 13, left), and Blueprint automatically creates a simple block
diagram Discovery Map of the process (Figure 13, right), just as PowerPoint automatically
creates the slides and bullets.
13
BPMS Report
Lombardi Teamworks
Figure 13. Blueprint enables modeling based on simple task outlining. Source: Lombardi
For any selected activity or sub-activity, you can enter information about participants, owners,
inputs and outputs, problems, and other documentation (Figure 14), available by drilldown online
or through consolidated documentation generated by Blueprint. Blueprint also provides simple
analysis tools to help process owners prioritize process problems and correlate them with
business goals. In addition to users with editing rights, Blueprint also supports “participants,”
who can view models and add comments, but not edit them directly.
Figure 14. Detail can be added to each modeled activity. Source: Lombardi
Behind the block diagram Blueprint is generating actual BPMN, using a limited palette of shapes
and symbols. These include nested subprocesses and a few event types. The BPMN diagram is
created automatically from the Discovery Map view, and is directly editable in the Diagram view
(Figure 15). Visio diagrams can be imported into Blueprint as well.
14
BPMS Report
Lombardi Teamworks
Figure 15. Blueprint converts outline “discovery map” into a BPMN diagram. Source: Lombardi
Blueprint not only lowers the entry barrier but actively moves users up the learning curve.
Blueprint models can be exported to Teamworks for simulation and eventual implementation. In
addition, Blueprint can export the BPMN to the desktop in OMG’s new BPMN 2.0 serialization
format – the first modeling tool to do so.
Team collaboration is an essential element of Blueprint. Team members share a single online
workspace and edit models concurrently. Entering the workspace, users see a What’s New page
in the style of social networking applications (Figure 16). An instant messaging feature enables
online conversations among team members. Like Teamworks, Blueprint supports versioning
using snapshots. In fact, Blueprint automatically creates snapshots as the model is updated.
Figure 16. Blueprint workspace features “What’s New” from the team. Source: Lombardi
15
BPMS Report
4.2.2
Lombardi Teamworks
Process Modeling in Teamworks
A process is the major unit of logic in Teamworks. It is the container for all components of a
process definition, including services, activities and gateways; timer, message, and exception
events; sequence lines, rules, and variables. When you model a process, you are creating a
reusable Business Process Definition (BPD).
Process modeling in Teamworks Authoring is based on BPMN. Modeling involves creating
activity flows using a palette of standard BPMN shapes – tasks, subprocesses, gateways, and
events – arranging them in swimlanes, and assigning tasks to resources. The model is made
executable by defining an implementation for each process model activity. Even without defining
technical details of the implementation, such as variables, data mappings, and scripted logic, the
model can be used to analyze expected process performance using simulation.
Detailed documentation in HTML can be automatically generated from the process model, and
formatted using XSLT (Figure 17).
Figure 17. HTML documentation generated from Teamworks. Source: Lombardi
Figure 18 illustrates the process design interface in the Authoring Environment. Library items for
the current process application are listed at the left (#1). The main canvas (#2) supports multiple
editors, selected by tabs along the top edge (#3). The Diagram tab supports drag-and-drop
assembly of process models using the palette of BPMN shapes on the right (#6). The Properties
pane (#5) allows configuration of the selected diagram element.
16
BPMS Report
Lombardi Teamworks
Figure 18. Teamworks Authoring interface. Source: Lombardi
4.3
Simulation Analysis
Simulation analysis is available through the Optimizer view. Simulation works in conjunction
with process organization charts created in the Organization Modeler perspective (requires the
Teamworks for Organization Management add-on). Unlike many other simulation tools,
Teamworks supports resource contention between multiple processes. Lombardi’s simulation not
only provides tables and charts, but offers recommendations and “cheat sheets” suggesting
potential improvements. In addition, a powerful feature called Guided Optimization leads the
user through a procedure that identifies specific conditions correlated with performance
bottlenecks, and suggests changes to the model to improve performance.
Optimizer provides several scenario modes (Figure 19, top left):
• a single scenario (the default)
• a single historical scenario (using actual tracked runtime data, providing information
about in-flight and completed instances)
• scenario A vs. B comparison
• scenario A vs. historical comparison
• historical vs. goals
• historical A vs. historical B.
The ability to group different processes in one analysis set allows users to conduct cross-process
analysis and optimization, answering questions such as “Will the customer support desk still meet
the customer response time SLA if two new product lines will be introduced in the next quarter?”
Heatmap settings (Figure 19, bottom left) configure the particular metric governing the colorcoded heat maps (Figure 19, top center) that represent activity-based performance reported by
Optimizer. Available visualization modes include:
• time-based – wait time, execution time, total time, or efficiency
• count-based – count of waiting instances, executing instances, or completed instances
17
BPMS Report
Lombardi Teamworks
Figure 19. Process Optimizer. Source: Lombardi
•
•
path-based – based on designation of sequence flows as either happy path or exception
path, displays results for process instances taking the happy path, exception path, or all
paths.
Metrics – SLA violations, or reworked activities
Optimizer provides hyperlinks from hotspots (Figure 19, top right) identified in heat maps to the
process model definition in Teamworks Authoring. The Live Reports view (Figure 19, bottom
center) displays tables and charts of aggregated data about the process instances included in the
most recently executed Analysis Scenario.
The Optimizer Recommendations and Smart Start panels (Figure 20) suggest additional
visualization modes to gain insight and recommended actions for improvement.
18
BPMS Report
Lombardi Teamworks
Figure 20. Optimizer Recommendations and Smart Start. Source: Lombardi
4.4
Service Modeling
The details of most Teamworks activities are defined through service models describing the
activity implementation. Figure 21 illustrates the service model editor. A common service type
in Teamworks is the Human service, implemented as a screenflow defined by a BPMN-like
diagram linking web forms, called Coaches, to other automated components in the editor’s
palette. Other service types include Integration and Rule.
Figure 21. Service design editor. Source: Lombardi
For all of them, a single Teamworks service is typically composed of multiple steps, designed in a
flowchart similar to a BPD. Teamworks provides a variety of point-click editors to configure
those individual steps, including:
•
Coach Designer – build web forms used in task user interface
19
BPMS Report
Lombardi Teamworks
•
Rule Designer – design and manage business rules
•
Integration Wizard – create integration components by point-click introspection of Java
classes and web services
•
Report Wizard – build complex reports without programming
Services can incorporate other nested services, such as reusable error handling routines. Through
scripting, Teamworks Authoring also supports Ajax services, which provide dynamic population
of Coaches based on user action at runtime.
5. Human Workflow
5.1
Task Assignment and Distribution
5.1.1
Participant Modeling
A Participant Group must be assigned to each Lane so that Teamworks is able to assign runtime
tasks. Participant Groups are created in the Teamworks Library at the global level, so they are
reusable in any Teamworks process. Each Participant Group has defined membership lists or
rules, and simulation properties like cost, capacity, and availability. Participant Group
membership can be dynamic, based on attributes of both users (e.g., skills and capabilities) and
the process instance, linked by rules (Figure 22). Organizational structures and relationships can
be referenced in Participant Group definitions, providing an extremely rich and flexible
framework for task assignment.
Figure 22. Participant group membership is dynamic, based on expressions combining user and
instance attributes. Source: Lombardi
5.1.2
Task Assignment
At runtime, a task is generated for each instance of a process activity and is assigned to a
participant in a variety of ways:
•
To the Participant Group assigned to the lane in which the activity is drawn in the
diagram. This is the default.
•
To the user who completed the immediately preceding activity in the same lane for this
instance, a very useful construct.
•
To participants determined by a Routing Policy, defined as a set of IF-THEN rules
referencing process data (Figure 23). With the Teamworks for Organization Structure
add-in, the policy can reference organizational relationships defined in the Org Chart.
•
To a user or role specified by a Javascript expression.
20
BPMS Report
Lombardi Teamworks
Figure 23. Task assignment using a rule-based Routing Policy. Source: Lombardi
In addition, within the participant group tasks can be distributed either to the first user to claim it
(the default) or in round-robin fashion or to the user with the smallest task backlog. Multiple
users can be assigned the task in parallel by using a multi-instance activity. The priority of a task
can be set at design time based on either a predefined level, deadline, or variable, or it can be set
dynamically at runtime. So task assignment and distribution in Teamworks is extremely flexible.
5.2
Forms and Task UI
If you add an activity to a non-system lane in a BPD, the activity is initially implemented using
the default human service (Figure 24). The key building block of a human service is the pagelevel task user interface, called a Coach. The name Lombardi Software was originally taken from
legendary football coach Vince Lombardi, and using the task user interface to “coach” untrained
users though their tasks remains a distinctive feature of Teamworks. Task user interface design in
Teamworks features these intuitive web forms, or Coaches, embedded in a graphically modeled
screenflow combining automated steps, such as database lookups, and conditional logic.
Figure 24. Coach represents a single screen in a Human service. Source: Lombardi
21
BPMS Report
Lombardi Teamworks
Figure 25. Coach Designer. Source: Lombardi
The Coach Designer (Figure 25) provides an intuitive, drag-and-drop editor to build and test
those user interfaces using a rapid-design, iterative methodology. It lists all the coaches used in
the human service (#1), and displays the selected coach layout in the main canvas (#2) in either
Design or Preview mode. On the right (#4), it provides a palette of layout and form controls that
are easily configured in the Properties pane (#5) with point-click dialogs or minimal scripting
(Figure 26). A report control can be used to embed Teamworks reports and charts inside a coach
without having to write any script.
Figure 26. Button scripting in Coach Designer. Source: Lombardi
22
BPMS Report
Lombardi Teamworks
Once the basic look and feel is determined, the dynamic interface links graphical elements to
process data. At each step, designers can run the Coach by clicking the Playback icon, and test
each element. The Preview tab in Coach Designer provides an instant preview of what the
runtime Coach looks like in a browser.
Figure 27. Ajax services provide dynamic Coach behavior. Source: Lombardi
Teamworks offers dynamic Coach behavior, such as autopopulation of dropdown lists and tables
from backend data sources, using Ajax. The Dynamic Data properties of a Coach control (Figure
27) link the control to an Ajax service. The Ajax service uses a Server Script component that
accesses backend data sources to populate Teamworks variables, and passes the variable values to
the Coach.
As an alternative to task user interfaces created with Coach Designer, Teamworks for Office 2003
users can use Microsoft InfoPath forms. After an InfoPath form, which must be created
externally to Teamworks, is imported into the Teamworks Library, it can be referenced as a task
implementation in the Authoring Environment. At runtime, the assigned participant will receive
a Teamworks for Office task in Microsoft Outlook with the appropriate InfoPath form
automatically associated.
6. User Experience and Task Management
6.1
Portal
Process Portal is the web-based Teamworks runtime environment used for both task participation
and performance management. The basic portal layout, divided into My Tasks, My ScoreBoards,
and My Projects, is essentially fixed and available out of the box (Figure 28). Developers can
create a fully customized Process Portal using the Teamworks APIs along with JSP, XML and
supplied Teamworks Tags. Task participation is described in section 6.2, while ScoreBoards are
described in section 11.2.
23
BPMS Report
Lombardi Teamworks
In addition, Teamworks for Office provides an alternative Outlook-based runtime environment
for task participation, and Teamworks for SharePoint 2007 provides an alternative web
environment for collaborative tasks and performance management (section 11).
Figure 28. Teamworks Process Portal. Source: Lombardi
6.2
6.2.1
Worklist and Task Participation
Process Portal
The Teamworks Process Portal allows users to view their assigned tasks, select and perform a
task, launch any processes or services that are attached to the tasks, and view their performance
and the performance of their processes and teams. Worklists are implemented as queries on
assigned tasks. The default worklist displays only system-defined properties such as subject, due
date, and priority, but users can build custom queries based on business data, across process
definitions, and display or sort on that business data in columns of the worklist (Figure 29) – for
example, retrieve all process instances where ‘customer equals XYZ Corp and order amount
exceeds $15,000. These custom queries can be saved and shared or reused.
Figure 29 also illustrates a task opened from the worklist. The standard interface displays details
about the process instance, notes and comments from other participants, and attached documents.
Users can reassign tasks to others, request help on a task, change due dates, or suspend/resume
the task. Clicking the icon to run the task executes the service defined as the task
implementation. From the worklist, users can also view the process diagram for the task.
Running the task displays the Coach (Figure 30), which can include tables and charts, along with
buttons that drive the screenflow to other automated actions and Coaches.
24
BPMS Report
Lombardi Teamworks
Figure 29. Custom worklists can be defined by savable searches on selected process data. Source:
Lombardi
Teamworks provides an audit trail of business data, allowing portal users to view all changes to
instance data tracked in the performance server. The audit report shows where the change was
made, who made it, as well as the old and new business data values.
Figure 30. Runtime view of a Coach. Source: Lombardi
25
BPMS Report
Lombardi Teamworks
Figure 31. Teamworks for Office lets users perform tasks in Microsoft Outlook. Source: Lombardi
6.2.2
Teamworks for Office
Teamworks for Office provides the essential functions of the web-based Process Portal through
Microsoft Outlook, which serves as the existing standard work portal for many users. The
Teamworks Inbox in Outlook (Figure 31) appears similar to the Process Portal. Using a "storeand-forward" operation, Teamworks for Office users can initiate Teamworks processes while
working offline. An offline user can open a process task in Outlook, fill out the InfoPath form,
and submit the form. Teamworks for Office stores the submission locally, and when the
connection to the Teamworks Process Server is restored, the process is initiated in Teamworks.
7. Integration Framework
7.1
Outbound Integration
Outbound integration requires creation of an integration service. Integration services can include
either a Web Service Integration component or a Java Integration component. The Web Service
Integration component uses a SOAP connection to access objects from a web service over the
Internet. The component hides the complexity of the underlying WSDL and SOAP messages, and
provides mapping between service parameters and Teamworks variables. The Java Integration
component calls methods from a Java class and interfaces with most third party Java APIs,
supporting a wide variety of integration scenarios. SOAP integrations tend to be easy to build
and best when not passing volumes of information. Java integrations provide access to the
features of the Java language, including published Java libraries and APIs.
In addition, the System Toolkit provides SQL Integration services out of the box.
26
BPMS Report
Lombardi Teamworks
Figure 32. Configured services can be reused within other services. Source: Lombardi
If an Integration service is fully configured, it can be simply dragged onto the canvas for use in
other services (Figure 32). New Integration services can be created from integration components
in the palette. For example, after dragging a Web Service Integration component onto the
Integration service editor, it is configured by entering the URI of the web service WSDL and
clicking Discover. This introspects the WSDL lists its available operations. The Generate Types
button automatically creates the datatypes for the parameters of the selected operation, and the
component configuration is complete. Using the component in an Integration service requires
adding input and output variables and mapping them to the component parameters (Figure 33).
Figure 33. Input and output data mapping of a service. Source: Lombardi
Figure 34 illustrates a Java Integration component in an Integration service. The JAR file for the
component must be added to the project’s External Files section, and the method selected from a
dropdown. If the Translate JavaBeans box is checked, the component serializes the method result
into XML. The Variables tab for the Integration service defines process input and output
variables, which can be mapped to component parameters. The configured Integration service
can be nested within another service or selected as an activity implementation.
27
BPMS Report
Lombardi Teamworks
Figure 34. Configuration of a Java Integration component. Source: Lombardi
7.2
Inbound Integration
Teamworks also supports inbound integration – in which the process responds to external events
– through two alternative but similar mechanisms. Undercover Agents (UCA) monitor message
events (via HTTP and JMS listeners) and timer events to trigger Teamworks processes or
services. Teamworks Web Services expose Teamworks processes or services through SOAP and
WSDL.
Figure 35. Message events used for inbound integration. Source: Lombardi
In a BPD, intermediate message events can be used for inbound event integration. Unattached
message events (Figure 35) represent points in the flow where the process waits for a particular
message. Each message event must be associated with a Teamworks Service that is configured to
run as an Undercover Agent. Configuration of the Undercover Agent binds it to a message queue
and variable.
8. Business Rules
Teamworks implements business rules through rule services, a special class of service
implementations. A rule service is defined as a list of if-then statements, in which each if
28
BPMS Report
Lombardi Teamworks
condition tests a variable against a value (string matching or numerical comparison), and the
action associated with the if is a JavaScript expression that typically sets the value of other
process variables. For example, if the value of customer is Target and billOverdue is true, then
set rebill to true. The first condition in the list to evaluate true triggers its associated action, and
the remaining conditions are ignored (Figure 36). Rule services are stored in the Teamworks
Library, enabling users to share and reuse rules across multiple services and processes.
Figure 36. Business Rule editor. Source: Lombardi
Teamworks can also integrate with third-party rules engines such as Fair Isaac Blaze, IBM ILOG
JRules, or Corticon, to leverage industry-, domain-, or product-specific rulesets that are
independent of process context. These engines are integrated to Teamworks via direct API or
Web service calls. Lombardi provides packaged integrations to Corticon and Fair Isaac.
Besides offering the ability to write business rules or integrate with external rules, Teamworks
Optimizer lets business analysts discover patterns in process and data flow that might suggest
new rules that bypass unnecessary steps for selected instances. For example, Teamworks can
identify that for an approval activity, the approved status is set to “true” whenever certain
conditions on order size or customer name are met (Figure 37). The user can elect to have
Teamworks automatically write a rule that will bypass the activity when the above condition has
been met. This simplifies the otherwise complex tasks of identifying new rules that can help
further streamline a process.
29
BPMS Report
Lombardi Teamworks
Figure 37. Optimizer can autogenerate rules that select instances allowed to ‘safely’ bypass human
tasks. Source: Lombardi
9. Content, Collaboration, and Case Management
9.1
Content Management
Teamworks Portal and coaches provide native support for document attachments, and can include
links to external ECM repositories like Documentum, FileNet, and Alfresco. This allows users to
access relevant documents and images (e.g. scanned invoice with customer annotations) during
process execution. This linkage can also be event-based. As events happen in the underlying
ECM systems, Teamworks can monitor and correlate those events to running processes, or
instantiate new processes.
Additional content management functionality is available through Teamworks for SharePoint
2007, discussed in the next section.
30
BPMS Report
Lombardi Teamworks
Figure 38. Collaboration and document attachments in Teamworks Portal. Source: Lombardi
9.2
Collaboration
At runtime, Teamworks provides a bit of team collaboration natively through the Process Portal,
such as user comments on a task in the Inbox (Figure 38). But for processes requiring more
significant team collaboration functionality, Lombardi now offers Teamworks for SharePoint
2007.
Figure 39. Collaborative tasks in SharePoint can be embedded in a structured process. Source:
Lombardi
With Teamworks for SharePoint, unstructured team collaboration activities can be embedded in
structured business processes. For example, in a hiring process the process model determines
31
BPMS Report
Lombardi Teamworks
when, where, and how to start a SharePoint discussion forum for each candidate. Teamworks
makes the hiring manger the owner of the forum and invites the other team members via e-mail
(Figure 39). In Teamworks Authoring, SharePoint Forum is specified as the implementation type.
Teamworks saves all resulting documents and discussions from SharePoint and attaches them to
the Teamworks process.
Figure 40. Web parts give SharePoint users access to Teamworks tasks and performance charts.
Source: Lombardi
In addition, Teamworks for SharePoint provides web parts (portlets) that exposes Teamworks
Process Portal functionality directly in SharePoint, including access to assigned tasks,
collaboration, and performance management (Figure 40).
9.3
Case Management
Case management differs from conventional structured BPM in that a single case may involve
multiple related processes, some of which are initiated either by events or ad-hoc action of
participants. The two key elements of case management support in a BPMS are support for such
ad-hoc behavior and a runtime user interface that keeps all elements related to a case – tasks and
processes, related data and documents, and performance metrics – together in a virtual case folder
accessible concurrently to anyone working on the case.
Teamworks provides some of the needed ad-hoc behavior, allowing ad-hoc “child” tasks or
processes to be initiated within the context of a parent Teamworks process. Teamworks users can
initiate ad-hoc processing on a process instance at any time. An ad-hoc process can be run from
the Process Portal, either from the Portal menu bar or from a context menu in the process diagram
(Figure 41). The ad-hoc process is executed in the context of the regular process instance, so it
has access to all instance data and can manipulate its process flow. Ad-hoc processes enable
functions such as executing special approvals, reporting on status, or canceling an in-flight
process.
32
BPMS Report
Lombardi Teamworks
In Teamworks Authoring, ad-hoc flows are modeled using a special Ad-Hoc Start event (not one
of the BPMN standard start events). The lane in the process diagram containing the Ad-Hoc Start
event determines which users are permitted to initiate the ad-hoc behavior.
Figure 41. Users can select and launch ad-hoc processes at runtime that share instance data, without
programming. Source: Lombardi
10. Events and Exceptions
10.1 Events
The Teamworks Event Manager is responsible for all time-based and event-based process
behavior. Events may be received from both the process and external applications. All events,
triggers, and deadlines that govern process management can be modeled directly in the process
diagram using BPMN.
The following BPMN event types are supported by Teamworks:
•
Message – Starts, interrupts, or resumes a process upon receipt of a signal from external
process or system; must be attached to a service linked to an Undercover Agent.
Teamworks calls an end event that generates a message a Terminate event. Messages can
be received by any running process that contains a Message Event. The actions triggered
are specified by attaching to the Event a Teamworks Service that is configured as an
Undercover Agent. A UCA acts as a “wrapper” around whatever functionality it is
assigned to execute at run time, described by the Teamworks Service. For all types of
events, the output parameter values from the Service are passed by the UCA to the
appropriate business process instance. When used as an intermediate event, the message
is received by the process instance determined by a variable mapping between the UCA
and the Message Event (Figure 42).
•
Timer – Interrupts or resumes a process based on a date/time or duration specified by a
fixed value or variable. Timer Events can be used to build deadline-based escalation
paths in a business process, implement timeout-based exception handling, schedule
events and activities that must occur at a particular time, or to pause execution for a
certain length of time. Intermediate timer events are typically based on a time interval
following the start of the process activity, which can be measured with or without use of
33
BPMS Report
Lombardi Teamworks
a “business calendar” for the activity performer. Timers can also be rescheduled after
they have been started, based on other process events or activities. Figure 43 illustrates
an attached timer event used to implement deadline escalation behavior. If the timer
event fires, the Complete Requirements activity terminates and the Escalate Research
activity is enabled.
•
Exception – Interrupts or resumes a process upon catching an exception thrown by a
Teamworks Service using an Exception End Event.
Figure 42. Undercover Agent configuration maps event data to Teamworks. Source: Lombardi
Figure 43. Boundary events can receive external event and redirect process flow. Source: Lombardi
34
BPMS Report
Lombardi Teamworks
In addition, Teamworks provides a Tracking event, used to track runtime data for performance
management and reporting.
The Pre and Post tab enables variable value assignment before or after an Event executes.
10.2 Exception Handling
An Exception Event listens for runtime exceptions or throws an exception. An XML
representation of the exception that has occurred is made available during the processing of the
post-execution assignments using the tw.system.step.error variable. The XML contains a
numeric exception code and an exception message in String format. If an exception occurs and
there is no Exception Event attached to the Activity where the exception occurs, the exception is
propagated up the BPD call stack until it reaches a nested process containing an Activity with an
Exception Event attached.
10.3 Transaction Management
Teamworks can support transaction rollback and compensation in two ways. The first is by
defining the compensation logic explicitly in Teamworks. Teamworks does not support the
BPMN Compensate event, but within the process, one can define logic and activities that undo
specific process actions, such as sending a follow-up cancellation email or reverting the old value
in an external system. Second, Teamworks can interact with a transaction monitor and commit
and rollback transactions as part of the process directly.
11. Performance Management
A key strength of Teamworks is its approach to performance management. Teamworks
emphasizes active business-oriented metrics that are used to optimize running processes in real
time and respond to changing conditions. Teamworks broadly distinguishes tracking from
reporting. Tracking refers to the logging of selected runtime data values at Tracking Points
specified in Teamworks process models and transferring them to the Performance Server.
Tracking also includes automatic generation of Alert messages sent to performance management
applications called ScoreBoards when triggered by specified runtime conditions. Reporting
refers to the analytical assembly, formatting, and presentation of tracking data to provide process
visibility in ScoreBoards and active optimization through Exposed Process Values.
The Teamworks architecture features a multiplayer abstraction layer for performance data that
allows the physical process model, variables, and components to change and not break reports.
Unlike some other BPM offerings, no database work is required to maintain performance
management metrics, even when process models change.
11.1 Tracking
Related data elements need for tracking in a business process, such as account or order
information, are selected as members of a Tracking Group in the Authoring Environment.
Tracking Groups can be envisioned as virtual tables or views in the performance database,
specifying fields to track. Tracking groups can be maintained by business analysts or process
owners, since no database or process changes are required to add or delete fields.
Tracking Events (also called tracking points) are components inserted in process models defining
where values of particular Tracking Groups are captured and copied to the Performance Data
Warehouse. A Tracking Event is an instance of a Tracking Group dragged onto the service
diagram. The Tracking Event defines both the point where the snapshot of performance data is
35
BPMS Report
Lombardi Teamworks
captured and the mapping from service variable data to named tracking fields. At runtime, the
Tracking Event inserts rows into a Tracking Group table in the Performance Data Warehouse
(Figure 44).
Tracking Event
Tracking Group
Figure 44. Tracking event inserts a row in the tracking group data table. Source: Lombardi
Timing Intervals measure the time elapsed between a pair of Tracking Events, which may be in
separate services (but within a single process). Timing Intervals are used to measure process
velocity, such as the time it takes for a user to perform a task or a system to update an enterprise
information system.
Figure 45. KPIs and SLAs can be defined for processes, activities, and participants. Source:
Lombardi
Users can define Key Performance Indicators (KPIs) tracked at runtime if auto-tracking is
enabled. Teamworks provides several default KPIs and allows users to create custom KPIs in
Teamworks Authoring Environment (Figure 45). Service Level Agreements (SLAs) based on the
KPIs can generate real-time alerts or other triggered action. Each SLA is defined by a complex
condition expressed in a “sentence editor” (Figure 45), and a consequence or action. In
Teamworks 6, SLAs linked to a process or individual activity can trigger a violation report, or
start a BPD or service, based on either actual or simulated runtime data.
Send Alerts post warnings to a ScoreBoard at particular places in a process. An example might be
low inventory for a particular item. Alerts allow ScoreBoard users to take immediate action, and
they maintain a record of the exception condition.
36
BPMS Report
Lombardi Teamworks
11.2 ScoreBoards
ScoreBoards are the highest level of user interface definitions for reporting. They organize
graphical Reports into predefined layouts specific to individual users or roles, providing both
functional customization and access control. When users log into the ScoreBoard area, they see
all the ScoreBoards associated with their roles (Figure 46). Reports are linked to datasources, and
allow users to drill down and filter report data from a ScoreBoard. Reports can also contain
Exposed Process Values (EPVs), values of specially declared variables that can be changed on
the fly by process owners to optimize process performance. Lombardi provides standard
ScoreBoards for Process, Team and Individual Performance out of the box.
Figure 46. MyPerformance tab shows all ScoreBoards for the user’s role. Source: Lombardi
The report datasource is specified by selecting an Integration Definition (typically a SQL query
on Performance Server data) and an associated Data Transformation to process the returned data.
Datasources return raw data as XML, and the transformation controls how the XML is turned into
the values matrix required by the chart (Figure 47). Report filters implement a dynamic Where
clause for the datasource, allowing a ScoreBoard user to customize the data aggregation at
runtime. In addition, report page drilldowns allow ScoreBoard users to navigate from one chart
to another, all set up via point-click dialogs.
37
BPMS Report
Lombardi Teamworks
Figure 47. Report configuration specifies datasource (left) and chart parameters (right). Source:
Lombardi
11.3 Exposed Process Values
Exposed Process Values (EPVs) allow ScoreBoard users to adjust the values of specially declared
variables in order to optimize process performance. For example, a manager may want to be able
to adjust the purchasing approval levels for a group of customer service representatives. The
manager’s ScoreBoard provides access to an EPV called ApprovalAmount that can be adjusted in
a range between high and low boundaries. The running process reads the value of
ApprovalAmount and blocks all purchases without approval below that amount. The manager can
raise the Purchasing Amount Exposed Process Value during a particularly busy purchasing period
to avoid being overwhelmed by approval requests.
In the request-to-hire process (Figure 48), the time for salary approval is taking too long, so HR
changes the threshold needed for special signoff, using an EPV.
EPVs play a role similar to rule maintenance applications in Business Rule Management Systems.
In practice, multiple values often need to be changed simultaneously to reflect details of the
adjusted “business rule.” Beyond just ApprovalAmount, the need for approval might depend on
the date of the purchase request, the customer status, and the items requested. A single EPV
allows the values of multiple variables used in process logic to be changed simultaneously from a
ScoreBoard. EPVs are associated to specific ScoreBoard reports, since the need to adjust them is
caused by intelligence received through a report.
In the process logic, EPVs are typically referenced by gateway decision logic and in Javascript.
Any changes applied through a ScoreBoard take effect immediately without versioning and
redeploying the process.
38
BPMS Report
Lombardi Teamworks
Figure 48. ScoreBoard users adjust Exposed Process Values on the fly to improve process
performance in real time. Source: Lombardi
Figure 49. LiveReports provide detailed performance reporting on actual or simulated runtime data.
Source: Lombardi
11.4 Optimization
The Optimizer perspective of Teamworks provides a wealth of charts and reports on runtime
performance. Actual data can be compared with historical data or what-if simulation output, as
discussed earlier in section 4.3. The Live Report tab in Process Portal (Figure 49) displays
39
BPMS Report
Lombardi Teamworks
metrics for the selected process or activity, including instance analysis, KPI analysis, and activity
analysis.
12. Solutions and Services
Lombardi offers a broad set of services to help customers develop their BPM capability and
enable them for successful delivery. Services are designed to match the needs of a customer’s
BPM team and process improvement program, whether just starting out or expanding to multiple
projects across the enterprise. Services can also match the customer’s preferred resource model,
ranging from “self-sufficient” to “outsourced”.
12.1 Professional Services
12.1.1
Project Deployment Services
Lombardi offers Project Deployment services whereby Lombardi agrees to deliver business
process deployment as quickly as possible, when customers need to minimize time, resources,
and risk. Project Deployment Services are often used for delivery of the first version of a process
project, but can be used throughout the entire process lifecycle if a complete outsourcing model is
desired. Lombardi provides the project delivery resources to work with a customer’s Subject
Matter Experts over the course of delivery (typically 10-14 weeks).
Project deployment services can also be obtained from Lombardi’s Certified Delivery Partner
network.
12.1.2
Expert Services
Lombardi offers a set of Expert Services that a customer can use whenever assistance is needed
for more advanced project tasks. Expert service categories include:
•
Process improvement inventory and roadmap
•
In-depth process analyses
•
Process optimization
•
Platform installation and configuration
•
Benchmarking and tuning
•
BPM program strategy & architecture definition
These services are delivered by Lombardi’s BPM Analysts, Consultants, Technical Architects,
and Program Managers – on site, and in some cases “on demand”.
12.1.3
LODA
As an alternative to traditional fixed-scope, on-site service delivery, Lombardi On-Demand
Assistance (LODA) provides flexible access to Lombardi BPM experts, on-demand – remotely as
well as on-site – on a subscription basis. Lombardi customers view LODA as a cost-effective
way to access Lombardi’s expert BPM resources on a supplemental basis, during all phases of a
BPM project lifecycle.
There are different levels of LODA delivery so customers can select the amount of assistance
they need, ranging from simple delivery of Lombardi expert advice, to outsourcing
40
BPMS Report
Lombardi Teamworks
implementation of specific tasks to Lombardi, to providing dedicated Lombardi resources as a
remote extension of a customer’s project team.
Figure 50. LODA provides user-selected levels of assistance. Source: Lombardi
12.2 Training and Certification
To enable customer teams to become self-sufficient, Lombardi has made a significant investment
in Lombardi University, which provides education, mentoring, and certification of BPM skills.
The core belief of Lombardi University is that traditional “one time” product training courses do
not prepare customers adequately for real-world projects and programs. Instead, Lombardi
University offers:
•
Role-based Education Tracks – Tailors education to all business and technical roles in a
BPM project or program, not just developers. This includes analysts, program managers,
administrators – and executives.
•
Multi-level Education – Provides advanced and expert level courses in each role-based
education track, to advance your team’s skills over time. And “elective” courses
complement core BPM skill development.
•
Certification of Skills – Utilizes exams to benchmark skill levels and guarantee
consistency across all BPM resources (in-house, Lombardi, and Lombardi Certified
Partners). Practical skills are demonstrated by completing actual projects.
•
Mentoring – Provides hands-on guidance by Lombardi experts to solidify practical
education in the context of real projects. Lombardi customers have found mentoring to
be an effective follow-on to course completion.
•
Faculty Network – Expands educational offerings and expertise beyond Lombardi’s
corporate boundaries through partnerships with well-known BPM experts.
Lombardi can help customers assess their current BPM capability and talent gaps in terms of the
skills metrics defined by the Lombardi Certification Program. Based on that assessment,
customers can tailor a talent development plan for in-house resources, enlist Lombardi Certified
Partners for staff augmentation, and tap into Lombardi expert services where they need
immediate assistance.
Bruce Silver, October 2009
41

Bruce Silver Associates

Transcription

Similar documents

WebSphere Lombardi Edition (Teamworks) Overview

to view Deborah`s best press clips as featured in her press kit.

summer camp 2008 summer camp 2008 northborough, ma

SCC Newsletter, 2011 #5 - the St. Louis Chapter of the Society of

Get it here! - Cleveland Play House

MORE TOP - La Volpe Restaurant And Pizzeria

Exhibit "C" - New York State Unified Court System

STUDY GUIDE

December - Queensborough Community College