This is a good question so I will share some of the elements we discussed live, hoping they will also be useful for you.

By the book it would be best idea to start building process architecture top-down (Burlton&Harmon style). However this will take some time and require the resources (just think about stakeholder analysis, workshops, agreeing the process architecture and process goals)

You can also try to make the process faster by applying some process frameworks like APQC PCF to avoid reinventing the wheel.

However what should you do if you are running a mid-sized project inside the organization and just want to make sure there is some order in the way you approach your models?

Here are some tips:

1. Try to identify what processes are in scope of your project. Ideally – try to connect them with the high level architecture or at least try to figure out what is above (how does it fit your company value stream). For the time being those can be just names of the processes, so it should not take you more than 15 minutes if you have appropriate people available. Easy? So move on.
2. Now let’s think what are the processes before and after those of your interest (they are sometimes called upstream and downstream). Here we are trying to see the connections and dependencies (more on this in the points below). 2 minutes per process perhaps?
3. For each of the processes document the most important elements. Apart from name of the process (by the way – it makes sense to have some naming convention for your process models with identifiers) you should at least capture:
   a) Who is the process owner. This person will likely have authority to decide when some important changes are needed and can help you connect with proper people who know what is going on in the process. In a perfect world – 5 seconds. In less-than perfect world – sometimes minutes (few mails and telephones ), and sometimes days (few workshops) may be needed to find a person that identifies as a process owner.
   b) What is the process goal. This is super important, because if you know why do we run this process, you can filter improvement ideas and make better design decisions. Again – it can range from minutes to days.
   c) What is the process scope. I personally more and more like IGOE approach in which you identify Inputs, Guides (e.g. company strategy, policies, …), Outputs (e.g. products) and Enablers (all the resources that allow your process to transform inputs into outputs). This can take you some time (but during few workshops I could do it in less than 10 minutes per process, but it is really helpful later on. Additional bonus – if you start with IGOE it is much easier to identify the start and end events of your process, which obviously helps when you need to do detailed modeling.
4. Now the fun part You need to recall what is the goal of your project, how much time/resources do you have and decide which processes deserve to be modeled in detail and which ones do not need a model. This last point actually deserves an additional post, so stay tuned.

Now it is your time. How do you approach creating (mini) process architectures in your projects? Put your experiences in comments!

You should take a look at Shibumi application.

Does this name sound Zen-like? It should as in Japanese culture it means the state of effortless perfection (you can learn more on Wikipedia)

Few weeks ago Ken Pellegrino from Shibumi was so kind to demo Shibumi to me and I must admit it was one of the coolest applications I had a chance to see recently.

How does it help?
It allows you to create shared understanding of goals, initiatives and tasks with your team, so that you can work together to create value.

Of course there are thousands of task management apps, but Shibumi links it to the strategy, so it is possible to see whether given tasks add value and (on executive level) manage portfolio of the initiatives so that they support the company goals in a best way.

What does it mean for BPM practitioners? You can easily track how is your process improvement initiative running and see what needs to be changed to make sure it brings desired results (e.g. productivity gains, cost reduction). You can also make your bosses happy by giving them possibility to see how each team supports overall goals.

It also works great for consulting companies that want to spend less time on reporting status to customers and more on adding value.

How could I describe Shibumi on one sentence? Most probably I would say something like:

it is a task management application mixed with strategy management scorecard and very flexible dashboard mechanism in such a way that the whole company can easily work towards a common goal instead of wasting time on things that do not matter.

When should you consider it?
Here are some of the scenarios (taken from their site):

• Operational improvement initiatives
• Post-merger / acquisitions optimization
• Cost reduction initiatives
• Metric driven process improvement
• Lean Six Sigma
• Enterprise transformation

It can also be used for Sales Execution and Revenue Growth scenarios.

Do you want to learn more? Visit www.shibumi.com (you can also sign up for the 30-day free trial).