You've probably been there on an HCM project or within your business environment.

"What's the business process?"

And somebody will pull out a hard-to-read diagram - with lots of arrows pointing to small blocks, a bunch of triangles with abstract decision points, and shout triumphantly "here it is".

If this is you... I recommend a rusty razor blade and starting to write a note to your loved ones, asking to remembered fondly...

Here is why I suggest the above path of action:

• 30 seconds after go-live, no user will ever read the process above. Business processes aren't worth the paper they aren't printed on.
• A business process is useful, but only if all the actors have bought into the process and the role they need to fulfill.
• Complex business processes ignore the fact that people tend to become self-sufficient and self-organising and will work out the process. But people are bad at becoming self-sufficient in a poorly organised business model.
• In fact, the business process should be embedded into any decent software... but that's a topic for another day. There really shouldn't be a need for a user to ever read a swimlane...

So... what should we focus on?

I've called it a business model - and it's not in a true sense... But what should be focused on in any business - much more than the process - is the actors in the business - what they do and what value they add.

"Huh? I'm not following..."

At a recent client, there were a number of different parties / groups of people. Let's keep this high level to protect the innocent, but we'll list a few of them:

• Employees
• Line Managers
• HR Business Partners
• Payroll
• Master Data

These were known / existing groups of people. So with this in mind, the process engineers built some very cool swimlanes, which nobody read.

And... when we went live, because nobody had read / understood the business processes, there was CHAOS...

A New Approach.

Forget complex swimlanes. Start the project with:

• An understanding of your current capabilities / groups ("we have an HR function; and a Payroll Function")
• Understand their incentives. What drives their behavior? (Sample: "Our Payroll Team are responsible for the correct payment of people - but rely on HR to type in everything except for monetary amounts..."
• Then... with this in mind... investigate the software capabilities and focus on what skills are needed; what governance is required; what segregation of duties is mandatory - and build a simple capability-based business model.

Worked Example:

Let's use the Recruitment process here. We'll go simple, because you're already doing well to still be reading (thanks, by the way!).

In the Recruitment value chain, your company has:

• Recruiters
• HR people
• Applicants. That's it... simple business model.

In the software, based on standard capabilities, we see some new roles that could be in play:

• Line Managers - who can create a requisition themselves - with approval
• OD people, who need to create jobs / positions at some points
• Recruiters
• Compensation experts - responsible for offers
• Support experts - for when things go wrong / we want new features.

Which begs the most important questions:

1. Do the new groups above have the skills to deliver what they need to?
2. Do they understand where they fit into the process? What is their role; what is the time urgency; who do they take instruction from; how do they communicate when done etc.?
3. What are the Critical Success Factors in their role?
4. Can they describe the high-level process in it's entirety?

Right now, you're thinking "that's a swimlane!"

And you'd be correct. But by taking a step back - getting agreement on the roles / CSF's; ensuring you have the right people with the right skills - suddenly a complex swimlane isn't important any more.

And the summary

It's a mistake to dive into detail with a business process. People get lost in detail, and the swimlane is an abstract concept.

Make it real. Talk about people's roles; educate them on the process in general; give them the tools to self-organise... and the swimlane will sort itself out...