BPX Community Project Home

Hi, what an excellent idea. I would like to join in, but need advise as to how exactly I may participate. Where do I start? Regards. Hans Butenschon, Norway.

Hi.  If you want to join, just start adding your ideas to the Wiki

Hi Hans,

You can easily join by choosing a role to play in our BPX in action story and starting to flesh it out.

Just go to the wiki page here: [BPX roles]
If you need help editing or working with the wiki, let us know!

Hi Marilyn, hi Richard,

this is a very ambitious and challenging attempt. Nevertheless I wish you good luck and hope you will be successful. The first script is not bad. Indeed the description I read so far might be the initial starting point in many companies. Having read the first script, the following aspects come up to my mind which may partly belong to the case itself, partly they reflect ideas and suggestions which you should consider to enhance the project desription and guidelines - and which do not refer so much to the case itself.

 First of all, having read the initial instructions I asked myself what tools should the community use to provide the project results. MS Office, of course, is not a problem and quite clear and everybody finally has the possibilty to see the results of other community members. But lets imagine, that you will provide process descriptions at a later stage. Shoud these be provided by the usage of Powerpoint, Word, ABC Flowcharter, Visio or even some specialised BPM tools (no, for certain obvious reasons I definitely should not name or mention one of them specifically )? I think some guidelines / restrictions regarding this point could be helpful, otherwise you will end up in a very "colourful" - or let me formulate it in the usual "rude" and respectless german way - in a slightly "messy" and "chaotic" situation since one community member adds a process description written in Word, another person provides some graphical process description in Powerpoint and a third one uses a flow charting tool which might be not accessible by other community members... In a certain, yes, this reflects the unfortunate way it is handled by many companies initially... Some of them later define clear rules for the process description such as which tool, how to use the tool and so on...

 Furthermore I think you maybe should roughly draw the boundaries regarding the five business processes you mentioned in your project despription. Otherwise people do not know what they actually should describe. You may end up in processes which are not necessary or even in processes which do not fit to the industry... Furthermore - but now I start to move already to comment on the case itself - you should differentiate between core processes and supporting processes... and also define whether the supporting processes are in the scope of the project or not. As a BI consultant I could provide something dealing with supporting processes but not so much things related to core processes (although I used to work as a R/3 consultant many years ago, but these times are much too long gone...

I had a look on the roles and I agree totally with one of the commenting people that at least one fundamental role is missing. The role of the Enterprise Architect, usually belonging to the IT department.

 Furthermore to enable people to describe the right processes, at least some boundaries of the case should be set by you such as:

• the industry we are talking about
• the company size (do we talk about a group or a single company)
• the regional coverage (one country, one continent or even worldwide)
• the type of business (consumer business, B2B...)
• and so on.

The reason for that is quite obvious. If you do not set these leading boundaries you will end up in a collection of many nice, interesting and colourfull processes, but unfortunately they will not fit together. So you might end up in the description of some production processes, but actually we are talking about a service provider...? ) Or the other way round. Somebody describes a service providing process, but actually you are focusing on an industrial company? The result will be that some of the community members invested lots of time - useless.

Nevertheless, the idea is fine. Hope that some people find the time and the spirit to support that ambitious project.

Hope these comments were a little bit helpful. Good luck and keep up the good work.

Best regards,

Joachim

Hi Joachim,

Your candid comments are extremely helpful, and I am thinking there should be a better way to surface them so that our participants can clearly see what you have written and perhaps begin to act upon some of your suggestions: clearer structuring of guidelines and restrictions, beter evolution of the roles, pitfalls to avoid, etc.

The comments area is not visible enough and perhaps even counter intuitive to the untrained eye.

Many thanks!

Hi everybody!

 I think the idea is great. Howeve, maybe I may be a bit blind, sure, but I haven't seen any deadline. Did I miss anything? A deadline will give a better idea of how to structure ourselves in it. Also the length of the content we send.

Thanks a lot for answering!

Jaime

Hi Jamie,

Right now, there are no real deadlines.  We are currently trying to get people involved who are willing to contribute.  Once we reach a critical mass of contributors, we may start some sort of a "pilot" schedule.

So, just grab a topic and write a script.

Welcome to the pilot.

 Dick

 This is an exciting project with a lot of potential. It brings to mind the comic strip Dilbert. It is funny because Scott Adams lays out situations that we recognize in our work environments that brings laughs or groans -- sometimes both. Unfortunately, Dilbert doesn't offer any suggestions for improvement. For this area, I would think it key to suggest ideas or model behavior that improve the interactions between the geeks and the suits to create better outcomes and make a positive impact on the organization. 

 To echo Joachim's concerns, there are any number of "gaps" in collaboration between geeks and suits. Because different industries and organizations will have unique problems perhaps, initially, not all the early entries will be applicable to all, in any situation. Joachim's gives good advice to keep mindful of particular contexts or perspectives. If initial strides can be taken to show useful strategies, regardless of how broadly they may apply, the give-and-take of sharing ideas and asking questions could broaden these ideas to provide a most valuable resource.

 Communication has 4 essential parts: What you think, what you say, what is heard, and how the hearer translates what they have heard.

 All of us can have great thoughts and brillant ideas in our heads that never quite sound the same when we start saying them out loud. As any speaker or writer knows, it can sound (or look) much different after it has come out than how it was in your thoughts.

 In communication, it is much more important what is heard and understood. The listener may not have heard you correctly or missed a word or phrase. Even more important, however, is the way the listener translates what he or she hears. There is always a context the listener is applying to what they hear as well as what they think they heard you say. I add that this is well beyond any multilingual translations that are apt to happen in a global organization.

 We could all use some assistance better understanding and collaborating with others outside our own functional areas. It makes sense to have a place where we can share successes and learn how to be better skilled at communicating. I look forward to learning from others.

Bob McGlynn