Processes

Abstract

Processes. Everything you start, work on and/or finish is part of a process. No exceptions. Starting on something? You’re starting a process. Working on something? You’re working through a process. Finish something up? Congratulations, you’ve just completed a process.

Your morning routine. Your drive to the office. Making a meal. Washing your hands. Getting gas. Going to the bathroom (depending on the number and age of children in your home, this one can have innumerable non-standard variations…). All these things, while being vastly different in intention, are processes.

Processes Are Important

By its definition, a process is “a series of actions or steps taken in order to achieve a particular end.”

If you’re an admin, and you’re not familiar with Dr. W. Edwards Deming you may want to look the guy up. Even though his heyday has long since passed, his teachings continue to be simple, straightforward and highly relevant. The guy was truly one for giving great quotes. One of my favorites being:

“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”

Think about that. If the end of a process is an outcome, there had to have been steps leading up to it. What are they? At what point did they start? What are the requirements  you need to fulfill along the way. How will you know when your process is done and how will you be able to convey your methodology’s effectiveness? To truly be an effective solo admin, you’ll need to be able to conceptualize and describe to others entire processes. Pretty often, too.

Starting Points

So where exactly does a process start? For the longest time, I thought my job as an admin was to match up Salesforce functionality with the project requirements I’m given. Somebody would say “I need to be able to approve these before they’re made publicly available” and I’d go “Approval Processes”. Somebody would say “This information needs to be entered in a specific way” and I’d go “Validation Rules”.  To an extent, my thoughts were exactly what they should’ve been. It’s just that my order of operations was off. This is where my story involving a chance encounter with the one and only Mike Gerholdt comes in. (Follow this guy on Twitter if you don’t already!)

It was December of last year (2015) and I was attending the Salesforce World Tour in Minneapolis. It was early afternoon, I’d just finished up with a session and had a bit of time until my next one. I’d fully intended to spend this time walking around the Expo floor, until I spotted Mike leaning against a pillar about to open up his Salesforce branded iPhone case. Wanting to catch him before he dove too deep into something  on his phone, I walked up and introduced myself.

SUPER approachable guy. I shook his hand and commented on how much I liked the SABWA (Salesforce Administration by Walking Around) he’d talked about earlier in the day. It turns out that in addition to being approachable, Mike seems to honestly enjoy sharing his experience and wisdom with admins. We chatted about a number of things, but he seemed to light up most when the topic of implementations/project work came up. It was during this part of our conversation that he said a simple three word phrase that smacked me right in the face… “Processes come first”.

Having spent the majority of my career on the Operations side of things, specifically as a Continuous Improvement Coordinator, I have to say… I felt more than a little sheepish when those three word brought on such an epiphany. Within moments, I’d reevaluated my prospective on implementations, projects and just about everything else related to my role as a Salesforce administrator.  How could this not have been my modus operandi from the get go.

More important than the tools you’ll use to accomplish the job, is the job itself. Before even thinking about the tools that may be needed to automate/improve/update/etc. a business process, get a really good grasp on actual process is! What’s the picture of a successful outcome look like to the person requesting the roll-out/update/etc. (i.e. your internal customer)? Are there timelines that need to be met? Are there specific milestones that need to be built into your solution? What will your results be compared to? What are the damn KPIs??

End User really don’t care about the custom controller you needed to write in order to create a Visualforce page that shows information in a specific way. They don’t care that you’re using the Process Builder to automagically populate values on the new Record that’s created when the click that spiffy new button you just made. They care that the requirements of their process have been met.

In closing, don’t put the cart in front of the horse. Before anything else, get to know your customer’s process based needs and wants. Then, by all means, get your geek on and automate, update and improve away!