Monday, September 17, 2007

BPM Game !!!

Trying to find this one out.. and try it out..
Will share as soon as i find it.


IBM has developed Innov8, an immersive 3-D educational game simulator designed to bridge the gap between the roles of IT teams and business leaders in your organization. Serious gaming--simulations which have the look and feel of a game but
correspond to non-game events or processes such as business operations--has emerged as a successful method to retrain or develop new skills. The Innov8 simulator is a result of the annual IBM SOA case study competition among graduate students at Duke University and the University of North Carolina. The game, which can be played with a
joystick, is based on Web 2.0 technology and allows players to visualize how an SOA impacts different parts of the organization. Together, users can literally see business processes, identify bottlenecks, and explore ‘what if’ scenarios before SOA is deployed.

Microsoft Forms Business Process Alliance, Develops BPM Roadmap

Came across this article...

Microsoft
Forms Business Process Alliance, Develops BPM Roadmap
:

"Microsoft is honing
in on business process management with the formation of the Microsoft Business
Process Alliance and the release of a BPM roadmap that will include a key
standard—Business Process Execution Language—in the Windows Workflow Foundation. "

The way Microsoft plans to lower the cost of BPM is by integrating those
technologies companies need to automate processes on its BPM platform.

That platform is composed primarily of BizTalk Server, which has
capabilities for system-centric processes and rules, and Office SharePoint
Server 2007 that has human-to-human and human-to-system capabilities through
document collaboration, workflow design (in the SharePoint Designer) and through
its integration with the 2007 Office System that includes Word and Excel.
The other areas Microsoft wants to bring to the table through the Business
Process Alliance—based on recommendations from users—are process modeling,
analysis, business rules management, human-centric workflow, process simulation
and SOA (service-oriented architecture) life-cycle management.

Saturday, September 15, 2007

Sysetm Architect Add on for Visio 2007

Finally the power of simplicity gets recognition. I think I have blogged about my desperation at (my client’s as well as my organization’s) decision of going for complex BPA tools when Visio seemed to be more than enough for their needs. The truth remains that we still use a very small part of capability of the tools.

Well now coming to the recognition, I am talking about this new Add on from Telelogic System Architect for Visio. Before going into details of what it promises to do, I would like to say that it is a wonderful move by Telelogic to mark a greater presence in the BPA market. The logic they are using is so simple : “If you cant take out the competition, join him.” Instead of keep trying to position SA as alternative to Visio, they have wisely accepted the entrenched position of Visio in the target market and are trying to build upon what Visio does not provide.

This add on is named the Telelogic System Architect Process Integrator and has been designed for Visio 2007. Here are some things that it promises to do:

1. The Telelogic solution consists of Visio templates focused on Business Process Modeling (BPM) and specific Business Process Modeling Notation (BPMN) object types.

2. Legacy Visio models can be imported into the repository via an integration path.

3. Visio models, objects, and definitions would be stored in the System Architect repository.

4. You can access the Visio models and tie them into the more complex analysis and reporting capabilities available in System Architect.

Visio business process diagrams in the repository are available for efficiency, optimization, simulation, and impact analysis through features such as explorer diagrams, System Architect/XT graphics, and System Architect analytics and simulation.

5. Telelogic’s Information Publisher™ provides a Web site development tool that uses standard System Architect reports to deliver target information to its audience.


Therefore needless to say I am excited about it. I tried to find out what exactly is coming up, but it seems the product is set to be launched in India next Thursday (20th September 07) and I cant have my hands on it before that.

Some interesting things I want to know are:
1. How has the BPMN object types included? Visio 2007 did not include a BPMN stencil.

2. How does it store the Visio diagram in its repository (known as encyclopedia)? In SA each symbol has a definition, has this concept been extended to Visio shapes. Not that Visio shapes did not have properties, but I want to see how those have been changed to ensure storage in SA repository.

3. How does it force users to make valid BPMN diagrams? What kind of restrictions would it impose on Visio users?

4. How much of analysis can be done on Imported Visio diagrams? Simulation on SA diagrams is pain enough.

5. In what form will Information Publisher represent the Visio diagrams? Especially since I really love the inherent publishing capabilities in Visio.

6. How effective would be the auto report generation on these Visio diagrams? The existing capabilities in Visio is good for nothing and I cant believe they could have ported the entire capabilities of SA reporting to imported Visio diagrams.


Probably answers to a lot of these questions would depend on how the meta model of Visio and SA have been reconciled.

It’s a pity, they cant make the Beta version available for trying my hand on.

Friday, September 14, 2007

Sub Processes

Was going through this new article from Bruce Silver. He tries to point out the benefits of representation of sub-processes as a part of BPMN.

http://www.bpminstitute.org/articles/article/article/bpms-watch-step-up-your-modeling-game-with-subprocesses.html

Here is the gist.
  1. Subprocesses allow the end-to-end process to be described at multiple levels of detail.
  2. Subprocesses encourage top-down thinking and analysis, also known as the end-to-end view.
  3. Subprocesses fit well with distributed process ownership
  4. Subprocesses are ideal representations of business services in SOA – units of business reuse that can be invoked by various processes and composite applications.
  5. In BPMN a subprocess defines the scope or context of an event, meaning the boundaries of the part of the process where some external signal – cancellation of an order, for instance – is valid and can be acted on in a particular way.

Thursday, September 6, 2007

Input to a process

I was really happy to see the questions below put forth by one of my collegues. Putting it here because this is something I have been tossing about in my head for sometime now.

Hi,
For the past one year, we all are stuck doing process mapping and SIPOC
being the buzzword. I still have certain basic doubts related to SIPOC &
process mapping. I present here a very few but basic questions related to
process mapping & SIPOC, which immediately come to my mind.

1-Does
the input to a process necessarily be a document?
2-Whether all the inputs
utilized in the process, no matter at what stage, be included as “I” in SIPOC?
3-Whether the trigger of the process included in the documentation of the
process? (I am referring trigger to as the event initiating the process.
4-Is it necessary that trigger will qualify as the input? If so, then is it
not advisable to classify the triggering input from the rest of the inputs?

Looking forward towards collective enlightenment....
Regards,
XXXXXXX


Now my answers to these are below:
Q1: Does the input to a process necessarily be a document?
I agree with XXXX's answer. NO it is not necessarily a document. But you would say, that's what we have been representing in most cases.
Now guys what we have to reflect upon is whether our process maps have just ended up being representation of Data/Information flow. I think there is nothing wrong in it. I track the whole issue to the roots of SIPOC. Coming out of the Six sigma tool kit, it bears the burden of being something invented to describe production environment.
When we apply it elsewhere that primarily processes data, the primary input to most processes we depict is data ( document containing data ) whether it is a PO or a Change Request or application form. All the inputs I can think of is data in some way or the other.

To sum up, let's agree on a simple thumb rule. An Input is something that is processed or worked upon. For a machine it is raw material. For a system it is data. For any human who carries out the process it is some document/information/material.

Q2: Whether all the inputs utilized in the process, no matter at what stage, be included as “I” in SIPOC?
I do not entirely agree with the answer below(No : u cannot include intermediates inputs in SIPOC. SIPOC should always have inputs at the begining and outputs at the end of the process. If you are getting intermediate inputs and outputs then the process is not yet eligible for SIPOC. Intermediate inputs and outputs is an indication that you need to drill down the process further.). Because that would mean, SIPOC can be used to represent only atomic processes. Yes, if you break down the process to a certain level there can be only arrows going in from the left and coming out of the right (referring to the classical diagrammatic representation of SIPOC). But at this level the process maps would lose its meaning as you would not really be able to show the flows.

A process is not a machine that works upon whatever (raw material) comes in through the entry point. We have to allow intermediate inputs. I am again referring to the fundamental rule I put down above. At whatever stage it enters, it should be worked upon/processed and for that particular process it is an input.

I guess a case of confusion can occur if we start confusing a trigger with an input. Because a trigger is something that necessarily comes at the start of the process but not an input. And again let me be clear that there would be events in the course of a process that would act as triggers to other processes/sub-processes. And in turn may pass on inputs to these.

Q3: Whether the trigger of the process included in the documentation of the process? (I am referring trigger to as the event initiating the process)
This has to do with the question "Is SIPOC enough?" While you can start thinking on it, let me point out two very pertinent issues. I assume we define a process as something that has a definite start and end. Then the trigger is something that defines the start point. Until we clearly note it down, our documentation of the process is not entirely meaningful. I would say you have guided someone to Alibaba's treasure cave without giving him the magic words. OR if you let me be a bit more scientific, I would invoke the familiar Newton's First law :)

Now the second important part that SIPOC misses out is the Metrics. You are not through with the process until you define measurements. You are probably giving a product without a section in the user manual that describes how to know when things are going wrong.

Q: Is it necessary that trigger will qualify as the input? If so, then is it not advisable to classify the triggering input from the rest of the inputs.
I agree that trigger is not an input. To explain further, I will borrow a word from the BPMN vocab. A trigger can be considered as an EVENT. So a process is started when something happens. For example if your process starts off with an approval, then the letter of approval could be the input but the receipt of the letter of the approval is the trigger. OR let me try my wits at a trickier situation. Let's say the process in question is a planned/periodic activity. You would say the the schedule triggers it and at the same time you would be tempted to put the schedule as input. But my golden rule comes to the rescue. I am not going to work upon the schedule/calendar, and hence it should not be treated as an input. So what would be the input. If it is a warranty/AMC check up, the documents (let's say the contract document) could be the input. If it is a maintenance process, PM checklist could be the input. If it is an inventory count, the inventory list could be the input.

So... any comments..thoughts..reactions???