Pilot Project

The Pilot Project

Welcome back for the 3rd episode of the Akino Fishing Co. BPM initiative saga.

About this article’s head image, we’re sorry, but the relation between Mavericks and pilot was too good to miss… 🙂

Anyway, today we’re going to describe our pilot project, the famous “Request a parking space” process. You can read about how and why we chose this process in last week’s article.

Let’s get started!

The process description

We’ll begin with a quick textual description of what the process is. So, the consultants met with some sales personnel and secretaries that typically manage these requests by hand. The idea is to let them describe how this process works. Once the consultants understand the process from their perspective they’re ready to describe it in their own words, which will then be modeled in Oracle BPM Suite.

Take note that getting to an adequate process description is an iterative, methodical and creative work. Now, “methodical” and “creative” not always get along, but they do coexist. The creative part comes into play when using problem solving to find improved ways of doing the processes’ activities, while the methodical approach tries to ensure that the whole process is captured and described.

Happy, happy, happy path

It’s quite normal that the first iteration focus on the so-called “Happy Path”. The happy path is the sorted list of process activities that are completed to achieve the process objective, when everything goes according to plan, without any issues or problems along the way.

Happy Path

The Happy path. No obstacles or deviations. Image by Vincent.

So, for instance, if you have a loan process, the happy path would be something like this:

  1. Customer applies for a loan
  2. Bank checks documentation
  3. Bank evaluates the credit rating
  4. Bank concedes or rejects the loan

When you ask someone to describe you a given process, the happy path is typically the first description that they give you.

A methodical approach

Although the creative process is very important in problem solving and optimization, the way a process description is created should follow some rules, guidelines and principles.There are literally tenths or hundreds of ways to do this. We’ll use one that we think works well, that consists on capturing the happy path first and then questioning the users and making them think of things that can go wrong along the way.

So, for our first iteration, we’ll start to describe the pilot process in plain English first, without using any specialty tools. We confess that we like to do it first on pen and paper, but you can use a word processing software, the notepad, whatever you feel comfortable with.

Drafting on pen and paper

We love using pen and paper, Helps with our creative process. Image by Nathanael Coyne

Now try to think for yourself, what would be your description of a process to request a parking space. Take 30 seconds to think about it and then continue reading this article. Remember… plain english! Don’t go thinking on User tasks, events and gateways (more on these subjects in the next posts).

Ready? Set? Go!

30 Seconds

Done? Great!

Your description should be something like this:

This process starts with a request from someone, either internal or external to the company. The requester fills in a small form with his name, his company name and the period in which he will need the parking space. The system will check if there are available parking spaces in that period and returns a response to the requester: Either “Please park on parking space X” or “We’re sorry but there are no parkins spaces available for that period”

Simple enough, no?

The second iteration

That was our first iteration, the “happy path”.Now we start to think on what can happen in that process that may influence the activities in the process or the overall process objective: grant a parking space. Maybe there are things that are missing, or that you feel that should be treated differently, like for instance:

  • How do you want to treat external entity requests? Do you want them to have priority over employee requests?
  • Do you just want to respond that there’s no parking space available or do you want to do some kind of action to see if someone can still try and find an alternative?
  • (…)

Trust no one!

There are other points that you need to think about when doing a process description. One of the most important is sometimes, we would dare to say often, neglected and has to do with responsibility. Let’s say that the system that checks if there are parking spaces available  doesn’t respond for whatever reason (network issues, system is down, power outtage, …). What should we present the requester? What kind of response should the process give?

So, a golden rule is Never expect that systems, or people for that matter, respond at all to a request you make, let alone respond in a timely fashion. As with anything else in this world, systems and people will fail and fall short of expectations. Engrave this sentence into your mind, and have this in consideration whenever you create/design business processes.

Next iterations

There are still a lot of new things you can add to your process:

  • Do we need to have a specially reserved VIP space that no one can request?
  • Do I want the possibility to manage unused management parking spaces, so that I can use them as available parking seats?
  • Do I need to account for things like earthquakes, fires and floods?

The list goes on and on, so as the complexity.

complexity illustration

“It seemed a good idea to add some more lines at the time…”. Image by Armando Alonso.

There’s another golden rule about business processes: Business Processes are never perfect and can always be improved. So, although the list of things you can remember to improve a process is large, you’ll need to judge what makes sense to implement, and what doesn’t. Try to remember the Pareto’s Principle:

80% of results are achieved with 20% of the effort. 

Carefully evaluate if the additional 3, 4, 5, 6% you’ll get with some of these improvements justify the cost of adding 30% more effort. Keep it as simple as possible.

The final description

So, we end up with a final process description that looks something like this:

This process starts with a request from an external entity or an employee, by filling and submitting a simple form with the following fields:

  • Name
  • Company name
  • Period to use the parking space
    • Date
    • Start Time
    • End Time

The system will then check if there are any parking spaces available for that period.

If the requester is NOT an Akino Fishing Co. employee and

  • The system returns that the requester can take parking space X, then
    • The requester is presented with a message stating “Your parking space is reserved. Please park on space X. Thank you”
  • The system returns that there are no spaces available, then
    • The requester is presented with a message stating “We’re sorry but currently there aren’t any parking spaces available in the requested period. Would you care to leave us your contacts and we’ll try to arrange a parking space for you?”, together with 2 fields: e-mail and mobile number.
    • If the requester chooses to submit the contact information, the system should create a task to a group of people, called “concierge”, that will try internally to arrange a space.
      • If they can, they’ll mark the task as OK and give the information about the parking space number. From then, the system will generate an e-mail and/or an SMS to the requester, depending on the contact data they filled in, stating that they can use parking space X.
      • If they can’t, they’ll mark the task as NOT OK. From then, the system will generate an e-mail and/or an SMS to the requester, depending on the contact data they filled in, stating that despite the efforts they couldn’t arrange a space.
  • The system doesn’t return anything, then
    • The requester is presented with a message stating “We’re sorry but we can’t check parking space availability right now. Would you care to leave us your contacts and we’ll try to arrange a parking space for you?”, together with 2 fields: e-mail and mobile number.
    • If the requester chooses to submit the contact information, the system should create a task to a group of people, called “concierge”, that will try internally to arrange a space.
      • If they can, they’ll mark the task as OK and give the information about the parking space number. From then, the system will generate an e-mail and/or an SMS to the requester, depending on the contact data they filled in, stating that they can use parking space X.
      • If they can’t, they’ll mark the task as NOT OK. From then, the system will generate an e-mail and/or an SMS to the requester, depending on the contact data they filled in, stating that despite the efforts they couldn’t arrange a space.

If the requester is an Akino Fishing Co. employee and

  • The system returns that the requester can take parking space X, then
    • The requester is presented with a message stating “Your parking space is reserved. Please park on space X. Notice that you may need to give up your seat, if it’s deemed necessary to receive visitors.Thank you”
  • The system returns that there are no spaces available, then
    • The requester is presented with a message stating “We’re sorry but currently there aren’t any parking spaces available in the requested period. Thank you”
  • The system doesn’t return anything, then
    • The requester is presented with a message stating “We’re sorry but we can’t check parking space availability right now. Check back later. Thank you”

 

With this description we wrap up this article.

On our next article, we’ll take this description and start to model the process in Oracle BPM Suite. This is where the fun part begins. Until then…

1 reply

Trackbacks & Pingbacks

  1. […] start detailing the pilot project in the 3rd article of this series. Until […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *