BPM

Centrum Systems Announces Partnership with Appian

Posted on

We at Centrum are committed to providing independent, specialist end to end  Business Process Management consulting and implementation services across Australia and New Zealand. We think our holistic approach combined with real, hands-on experience supports customers to achieve incremental and sustainable improvement outcomes no matter what the size or complexity of their business.

 

We mix expertise and a passion for continuous process improvement practices with in-depth technical know-how. We drive, implement and guide optimal, measureable change within businesses. This is what we are best at.

 

We are pleased to offer these services to support customers of Appian’s leading enterprise, mobile and cloud-based BPM solutions. Centrum and Appian will work together to deliver the right people, practices, operational framework and technology in a pragmatic and collaborative partnership with our customers.

 

View Press Release

Build Pipeline Plugin Release 1.2.2

Posted on

We are pleased to announce the availability of version 1.2.2.
The release addressed bugs.

Bug Fixes

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).

Defect ID Summary
42 Renaming pipeline jobs breaks pipeline
47 Build Pipeline View cannot display full downstream projects
48 Downstream parameterized job picking up upstream settings

Documentation

The documentation is available from the Hudson and Jenkins wikis.

BUILD PIPELINE PLUGIN RELEASE 1.2.1

Posted on

We are pleased to announce the availability of version 1.2.1.
The release addressed bugs and enhancements.

NEW FEATURES

  1. Retry Failed Jobs

  2. If a job in the pipeline fails, the job will now display a “Retry” button. This allows the user to retry this job, with the parent build remaining as the trigger and continue the build pipeline.

  3. Restrict the Trigger Button to the Latest Build

  4. When configuring a build pipeline view a new option “Restrict Trigger to the Most Recent Build” has been added.
    If set to “Yes” it will only allow the most recent build pipeline to display a “Trigger” button.
    If set to “No” all builds displayed on the view will have a manual trigger button.

BUG FIXES

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).

Defect ID Summary
33 plugin interfering with job renames/deletes

DOCUMENTATION

The documentation is available from the Hudson and Jenkins wikis.

Build Pipeline Plugin Release 1.2

Posted on

We are pleased to announce the availability of version 1.2.
The release addressed a few bugs and enhancements.

New Features

  1. Build Parameters Inherited by Downstream Jobs

  2. If the parent job has parameters defined, those parameters are passed down to all subsequent child jobs for manual jobs.  Note: an automatically triggered downstream job should use the parameterised trigger plugin to achieve the same…

Bug Fixes

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).

Defect ID Summary
15 parametrized build jobs parameters are not inherited in downstream jobs from the same pipeline / parameters are expected to be passed through the whole pipeline
28 No support for views when running jenkins with JRE / JDK 1.5.
29 Exception getting git revision number.
30 Cannot view pipeline
32 Pipeline plugin not working with SVN either
37 Cannot view pipeline when using security

Documentation

The documentation is available from the Hudson and Jenkins wikis.

Pega 2011 Business Process Symposium (Melbourne)

Posted on

I attended the Pega Business Process Symposium today in Melbourne, which had quite an impressive turnout considering it was the inaugural holding in Melbourne. The large turnout  –  there must have been close to 100 people there –  is indicative of the traction that Pega has made in recent times in the Australian market.

Other than the excellent attendees (including myself), the event was well organised, and I liked the fact that it was a morning event, and they hadn’t tried to stretch it out too much. It did have a sales pitch feeling, but I guess that is fair enough considering it was a Pega event. Here is my brief summary of the day:

Luke McCormack was the host and introduced the day, gave some insight into what Pega was doing in Asia Pacific, and re-enforced the Pega ‘Build for Change’ mantra.  Following a brief recorded message from the CEO, there were a number of presentations.

Business Transformation through BPM Suites –  Setrag Khoshafian. Well Setrag was certainly pumped up for this, and he gave a very (sometimes overly) enthusiastic presentation on the Pega BPMS. As always, I thought a bit more time could be spent on how to establish a BPM approach, rather then focusing on the tools. However, there were some points that resonated around the Pega BPMS offering. In particular the need for a toolset to support delivering agility in change. The promise of reduced cost of change is something that is touted by all the vendors, but reality is often very different to what is being sold. The Pega frameworks and implementation methodology have focussed on this over recent years. Simple things like the Pega versioning and unit testing frameworks really assist in delivering change with more confidence. The project management frameworks are a great example of Pega eating their own dog-food, using PRPC based processes and rules to manage BPMS implementation projects.

And having a single platform with all components included does simplify things. This is not always ideal or even practical, but having real business rules support within the BPMS is powerful and keeps it simple. And lets face it business rules and business process are closely related and aligned.

Overall Setrag claims IT productivity increases of between 2 to > 10 greater productivity (greater than OO development) based on some Pega sponsored research. I am not quite sure about the validity of this, not having seen the research, but interesting none the less.

CRM –  Rapidly Transform Your Customer Experience –  Steve Kraus. The focus is apparently on improving Pega’s business analytics and real-time intelligence. A lot of this presentation was an overview of the Pega CPM modules. Which I do like. The CPM framework is simple, but contains all of the key features of a call-centre focussed CRM. Having a CRM based on the same platform as the processing platfrom used by the back office is something that I like. I may blog about this in the future, and this was also highlighted by Forrester’s William Band in his blog ‘The Top Twelve Customer Management Trends For 2011’ (http://blogs.forrester.com/william_band/10-12-29-the_top_twelve_customer_management_trends_for_2011). Having processes initiated by the front office using the same processes (albeit tailored for the interaction) and platform as the back office keeps it simple, allows for reduction in hand-off points and breakdowns, and allows better insight into the full process. It is not an all singing and dancing CRM, but it does have the features required for the call centre and keep the overall solution simple.

Pega Never Looked so Good –  WesFarmers (Mike Efron). I was really looking forward to some insight into the use of the Pega Internet Application Composer. Extending processes to the customer or third-parties self-service channels often hits hurdles with either fit into an overall enterprise architecture or the fit for purpose of ‘generated’ user interfaces (as Mike said for UI design, ‘good enough isn’t’). This normally results in costs or timeframes that erode the original business case or intent of the process improvement opportunity in the first place. However, Mike’s presentation was more focussed on the challenges for bringing a new, white-labelled insurance product into a well established market. This was interesting in itself, but not what I was hoping for. Reading between the lines, I got that Pega worked well for this model as:

  1. The pega rule inheritance model more easily supports having to white-label in this way. Small differences between user interface, process, and product can be approached in a layered and structure way, without having to re-design or re-write for small differences in the product between brands.
  2. The Internet Application Composer was able to produce user interface portlets that were suitable for retail consumer consumption, without compromising on the user experience or look and feel.

Unfortunately, I missed the last session of the morning on Pega’s adaptive case management solution. It probably was the session that I would have liked to have seen the most. However, unfortunately, I had to get some processes designed for a client, and sometimes work has to come first.

All in all, it was a worthwhile event to attend. I would have like to have seen more of a focus on continual improvement, and what BPM is really about. But it did give some useful insight into where Pega was, and what their focus is on in the coming periods.

Tags:

BPMN Method and Style

Posted on

Last week I was casually flicking through the pages of a book called BPMN Method and Style and a passage in the introduction caught my attention… words to the effect that the clarity and effectiveness of BPMN models depends more on what’s not stated in the BPMN specification than what is stated in the specification – something that Bruce Silver (the book’s author) calls Method and Style.

I read on…and after a few pages my attention was hooked… It seemed to me that the distinctions that Bruce Silver had invented were potentially very useful for what Centrum is up to. Here’s what I got from reading the first few chapters…

Goals

The author’s goal is to provide what is needed to create BPMN Models that are…

  • understandable and can stand on their own without requiring a narrative
  • show the exception pathways as clearly as they show the “happy path”
  • serve to create a shared understanding between Business and IT

And in the author’s experience what is needed over and above the notation found in the BPMN 2.0 spec is Method and Style and to support the application of Method and Style when creating BPMN models the author introduces the concept of Levels Based BPMN.

Levels Based BPMN
The sub-title of the book is “A levels-based methodology for BPM process modelling and improvement using BPMN 2.0″. The levels in the sub-title refer to three levels of BPMN use.

In distinguishing these three levels of BPMN use, three distinct contexts are created for notation, method and style where each context is designed to serve the core concerns of each of 3 distinct user groups. The trick in distinguishing these levels is to have each successive level be a refinement of the upper level.

What the Levels are and How they Work

BPMN Level 1 – Descriptive BPMN
In levels based BPMN, Descriptive BPMN is what business oriented process mapping is all about; simply documenting what the flow is. Descriptive BPMN uses a basic set of symbols familiar to traditional flow charting to describe a typical order of activities and what role or organisational unit performs or is responsible for the process. It may omit some exception paths and may ignore some of the rules prescribed by the BPMN spec. The BPMN modeler is also free to ignore the fiction of the central controlling orchestration engine.

BPMN Level 2 – Analytical BPMN
In levels based BPMN, Analytical BPMN leverages the expressive power of the complete notation to describe the activity flow precisely, including exception paths significant to key performance indicators. The model follows BPMN’s defined semantics and is subject to its validation rules. An important distinction is that Analytical BPMN models are non executable models – they omit the technical details required for execution such as data structures and expressions.

The BPMN specification does not distinguish between notation that serves for execution and notation that serves for analytics but they are easy to distinguish: diagram labels in level 2 take the place of missing technical details.

There are two distinct use cases for BPMN Level 2:

  • documentation of as-is and to-be process flow for the purposes of analysis but not for the purposes of execution in a process engine
  • creating the business view of an executable process design in a BPMS. (Here BPMN is used to define the process model underlying the executable design but absent technical detailBPMS does not use the BPMN for the executable detail instead it layers it on top its a proprietary interpretation)

BPMN Level 3 – Executable BPMN

In levels based BPMN, Executable BPMN fits inside OMG’s goal of model driven architecture where executable systems are governed by graphical models and not “code”. BPMN at level 3 is targeted at developers, not business architects or analysts. BPMN at level 3 begins with level 2 diagram and adds detail in the XML underneath the shapes and symbols. It transforms BPMN from a diagramming tool to a XML language for executable process design. It still early days and at the time of writing there are no tools supporting the language as yet and we can see the emergence of tools that are supporting aspects that are essential to Level 3 BPMN such as process data, service interfaces, human task assignments

On the subject of Style

When Bruce Silver talks about style within BPMN modelling he draws on the meaning of style within english prose as exemplified by The Elements of Style

The central observation here is that the language of experience is not the language of classification – and notation is a language of classification.

The message here is that notation in and of itself does not communicate – as in ordinary prose – clarity of expression is essential for effective communication. And in this case communication and understandability is to be found in the design patterns of notation and not the notation per se.

On the subject of Notation

Along the way the author makes some interesting observations about the BPMN notation itself. The symbols of the BPMN notation are such that it can be used in idealised description AND as a blueprint for automating with an execution engine.

The potential for BPMN is shared understanding and Business IT Alignment where BPMN serves as a common notation for Business IT collaboration. As a diagramming technique it has the twin advantages of familiarity and simplicity wanted and needed by business users and the expressiveness and precision demanded by IT users.

The potential for an unintended bias

Consider that BPMN 2.0′s conceptual foundations assumes executable automation as a hidden subtext – the symbols assume a single engine AND… many BPMN users are non technical and not even considering automation.

The potential here is for the underlying assumptions within the notations to influence the modelling process and create a bias that was not intended

Questions left unanswered by BPMN

Using the notation effectively depends on understanding and even accepting the hidden assumptions and conceptual framework. BPMN does not answer questions like…

  • what is a process?
  • what does it mean to be inside or outside a process?
  • what does it mean to start and complete an activity?
  • what does it mean for an activity to complete normally?
  • why does sending occur immediately but receiving imply a wait?
  • what is the difference between making a decision and taking this path or that based on a decision?
  • what is the difference between a business rule and a routing rule?
  • what does it mean for two activities to be concurrent or sequential?
  • what is the difference between performing an automated function and requesting it?
  • what is the difference between branching based on data and branching based on an event?

Answers to these questions are critical to the correct use of the notation but its not in the spec.

In BPMN a process really means an orchestration – a sequence of activities in which the flow is centrally controlled when an activity completes, the central controller – the process engine – command or enables the next activity to start. A Process model describes all the possible paths from creation of an instance to its eventual completion along with the logic that determines the path which is taken.

The author asserts that to really understand what a BPMN model means we need to come to grips with how a BPMN model produces meaning – and coming to grips with how BPMN models produce meaning and the modelling patterns that foster and develop understandability is what the rest of the book is all about.

AWD 10 – re-entering the BPM market, or just some lipstick on the old beast?

Posted on

I recently saw the review of AWD 10 from Bruce Silver (http://www.awdbpm.com/bruce_silver_on_awd10_oct_2010.pdf), where he was outlining the virtues of AWD 10. Now to be open I have been bitten by AWD in the past and have some painful memories. These were not necessarily all the fault of AWD, but partially that we were trying to use it outside of its main areas of strength. However, I still have the scars.

AWD has been around for a long time. Originally built by DST to manage its BPO operations I believe it started life in the 70’s / 80’s written in Cobol – and this heritage always remained in the constraints in the fixed length data models. Over its life it was ported to a combination of C and Java and a number of add-ons were bolted on to the side. During the last 5 – 10 years there seemed to be a significant lack of investment in the product itself, and it went from a position of being a market leader to a boundary player.

AWD is used extensively by DST systems for operations processing. This, in conjunction with the joint ventures with State Street and FDI was always the reason why the install base was so large. Used in this way, I have seen AWD being used very effectively for large volumes of transactions.

From first glance through the report, it appears that AWD 10 bolts together all of the components that were emerging as add-ons in previous incarnations – such as the form designer, service designer, and smart forms. These were previously always add-ons, developed separately, and licensed as add-ons.

In the past the challenges that we have encountered with AWD have been based around:

  • The complexity of the operating and development environments. The lack of version control and release management capabilities in particular – although this is an area that Lombardi 6 struggled, it has now put these largely to bed with 7.x. It was not clear from the report whether this has been addressed at all.
  • Integration into any other portal or technology – for example for presenting tasks lists through a partner portal.
  • The number of and integration between add-ons which were not seamless.
  • The data dictionary – especially around field name lengths and handling of collections.
On the positive side, its support for out-of-the-box QA sampling, review, and performance tracking has always been a strength and something that I have never understood why the rest of the BPMS / Workflow platforms have not got. I think this is a symptom of the fact that AWD is designed by a company that actually uses this stuff, and the innovation is driven by actual usage (especially through the FDI joint venture from what I have seen).
So my observations are:
The product homepage (http://www.dsttechnologies.com/awd10.html) mentions that this is a complete re-architecture of the product. Although this doesn’t come through in Bruce Silvers report. 
It was good to see that there was finally a basic process modeler, as this was always a key let-down. It looks from the screen shots to be BPMN based, although very restricted. Maybe this is just the screen shot.
From what I can see, the key changes are the addition of the BPMN modeller, some improvements around the integration of the job designer and the ability to call external business logic (services), web browser based design tools, and some improvements to the dashboards.
So I am not convinced that this is such a big progression. AWD seems to be playing catch up, and is still a way behind. The key functions have remained the same and really there is nothing new in there. Yes it has been around for a long time and has some significant volumes. But it is still a fairly straight-forward workflow platform. There doesn’t appear to be any focus on supporting collaboration or continual improvement, especially in areas such as optimisation and simulation. In my mind these are key features I am looking for in a business focussed BPMS. And is it a BPMS without them?

Next Generation BPMS

Posted on

When reading the 2010 Forrester Wave Report for BPMS there were a couple of take aways for me, but the main one being the considerations for what is required in a BPMS.

One titled ‘Next-Generation BPM Suites Empower Process Owners, Business Users, And Customers’ and the other on how to select a BPMS (‘Which BPM Suite is right for your initiative’).

In the first the key features that were discussed were:

  • Social and Web 2.0 components encoaraging collaboration through the discovery, design, and development
  • BPM as a service (in the cloud)
  • Data Quality
  • BPMN 2.0 helping to standardise modelling notations across tools within large organisations – hence allowing better end-to-end understanding of processes regardless of the toolset in use by different departments.

This lead into the discussion on how to select a BPMS.

If the business plans to drive process transformation, you will want to select a vendor that has strong collaborative process design, prototyping, and shared development capabilities.

So for me we seem to be missing a big part of process analysis – which is about discovery / analysis for processes that have been implemented. What about BAM, simulation and optimisation? Identification and prioritisation of improvement opportunities? The promise of BPM is based on implementing models of continual improvement. Not about one off process implementations.

Not many products seem to actually support the whole life cycle or at least not in a circular fashion. It should be discovery, design, execute, monitor, discovery, design etc.

As a decision maker (assuming a business led initiative based on the promise of continual improvement), I would be keen to know about the products abilities to monitor, identify issues, and feed this back into the analysis phase of the cycle.

In my experience BPM initiatives often turn into BPMS implementation IT projects, and complete at the end of one big business case. This may have delivered one or more process improvements iterations, but has failed to leave the organisation in a place that can deliver continual improvement to their processes.

Am I missing something or is this just a symptom of the levels of maturity we are at in the BPM space, and hence our requirements for a BPMS?

Taking a BPM approach to BPO

Posted on

Centrum recently attended the first meeting of the soon to be established Australian Business Process Outsourcing Association (ABPOA). We approached the concept with tentative interest, as we were not entirely sure how our approach to BPM would align to the goals and aspirations of the BPO association. It emerges that there are actually some very strong linkages between the two concepts and we thought we would share some of our initial thoughts.

BPO is not a new concept but it does appear to be gaining some renewed traction as organisations look for the next wave of efficiency savings. Clearly, not all processes are candidates for outsourcing. It’s really the non-differentiating processes for which there is likely to be a business case. But how do organisations decide which processes to outsource and which processes to continue to manage themselves? What sort of information would help to better inform this decision and does BPM have something to offer here?

We think BPM will help and in more than one way. Firstly, a functioning BPM capability within an organisation enabled by BPM technology will provide companies with the sort of information they need to make an informed decision. This will include things like process cycle times, frequency and cost in addition to quality measures such as number of exception path executions. A set of modelled process, using a standard notation such as BPMN, will also greatly assist the outsourcer understand how the process currently works and it what way it will change when it is outsourced. In many ways a function BPM capability with an organisation looking to outsource processes is a pre-requisite to outsourcing and this is a view held by one of the more prominent BPMS vendors, Progress Savvion.

For BPO organisations the case for BPM is even more compelling. The reputation of their business depends on their ability to successfully manage the process being outsourced. They also need to provide added-value, whether it is running the process at a cheaper price, more efficiently or at a high level of quality. For these organisations, the processes are differentiating processes and as such the performance of these processes and the value they provide to clients is what separates them from their competitors.

So, a checklist for organisations looking to outsource processes:

  1. Ensure all your business processes are modelled and properly measured
  2. Decide which processes are candidates for outsourcing based on the information you have captured
  3. Identify an organisation that has a reputation for delivering value to organisations in the target process space
  4. Clearly identify the hand-off points between you and the outsourcer.
  5. Agree to a set of measurable SLAs and KPIs
  6. Work with the outsourcer to continually improve the process and ensure the arrangement works effectively for both organisations
  7. Regularly evaluate the benefit of the outsourcing arrangement and ensure you are getting value for money

And for outsourcers:

  1. Employ a continual improvement approach within your organisations to ensure your processes continue to deliver added value to your customers
  2. Use BPM technology to assist you measure your process and to automate the hand-off points
  3. Provide your clients with clear, frequent and comprehensive reports to illustrate the performance of your processes

A focus on continual improvement for both organisations is critical in maintaining the success of the working relationship. Outsourcing is traditionally not a cheap exercise but is the overall cost can be if both organisations practice BPM and use leading technologies to support them in this endeavour.

Process Discovery: Whiteboards are cool but is there a tool?

Posted on

Running a successful process discovery workshop is a dark art, it’s not everyone’s cup of coffee. It requires an ability to grasp concepts quickly, patience and most importantly a strong will – to keep at the participants on track. It’s not just a matter of standing in front of a whiteboard and drawing some pretty shapes with lines between them you need to control the flow of information, separating the important stuff from the not so important stuff and keep everyone actively engaged for often days at a time. One of the hardest things to control is the level of detail and it takes a certain tact to delicately move the group on when the workshops descends into a discussion over whether Bill or Jane currently approve a particular activity or whether the average cycle time for the approval process is one hour or one hour and five mins.

In my experience, a whiteboard, non-permanent markers and a wad of sticky notes works just fine but you need a room with lots of blank walls, a good swivel chair and a rubber neck. There are now stacks of software programs about that claim they can assist you in workshop world but I’m still yet to see one that does everything I want it to, albeit they are getting close.
So, in order of preference (perhaps controversially,) what are the key things I believe a tool needs to support:

  1. Flexible data capture – quite simply I want to be able to capture data at every level: organisation, process, activity and task. Preferably, I’d like to be able to configure the types of data I can capture and not be constrained by predefined fields.
  2. Process modelling – obviously you need modelling support and I don’t think there will be a tool out there that doesn’t allow you to draw pictures. However, just providing support for modelling is not enough. Ideally you want a tool that supports the standard notations in this space: Business Process Management Notation (BPMN) and Event-drive Process Chains (EPC). The usability of the tool is absolutely critical, the last the you want during a workshop is to be messing around trying to join two activities together – participants will quickly switch off if more time in spent in the tool than facilitating the workshop.
  3. Documentation – by documentation I mean more than just a PDF with pictures. Ideally, the tool will be able to generate a PDF that outputs diagrams nested amongst all the data you have captured and potentially the output from any simulation.
  4. Process landscaping –the level above processes. Ideally, you would be able to model the process landscape as a hierarchy showing where in the organisation processes reside and how processes are divided into sub-processes
  5. Simulation – I appreciate I’m potentially stepping into process design with this one but at the point we start mapping the processes in detail I’d like to be able to simulate the process based on what I have captured. This doesn’t need to be a bells and whistles simulation I just want to be able to quickly assess where the possible bottlenecks are and start getting a feel for the costs and cycle times for each step.
  6. White boarding – in my opinion it’s not a good idea to start modelling the process too early. Initially, you just want to be able to capture the key steps in a process and the key activities that reside within each of those steps. Sequence is also important but your best to focus on the happy path only and park the exceptions for a later iteration. To support this approach you need a tool that allows you to capture steps and activities in an unstructured manner, as you would on a whiteboard.
  7. Web browser support – ideally the whole tool would be browser based but at a minimum I’d be happy if the tool just supported the ability to publish a project in a HTML form so that it is viewable in a browser.

So what are your priorities and what’s out there? I think it’s fair to say that no one tool does it all. So, if there isn’t one tool then ideally I liked seamless transition from one tool to the next, with limited data loss and minimal effort.