UC Berkeley News
Berkeleyan

Berkeleyan

How to get a handle on BPA
. . . with a little help from your friends. Members of new staff organization share techniques, tips, and best practices about business process analysis

| 11 October 2006


The seeds of BPAWG were sown when James Dudek (left) responded to an online request for help from E. Bond Francisco (right).(Kathleen Satz photo)
 

Business-process analysis is a methodology for looking at work from the perspective of who does what, and in what order. The goal is typically to make processes more efficient or - in some cases - to automate them.

Campus units ranging from student services to a number of administrative departments have been jumping on the BPA bandwagon. The challenge is that it's both an elusive discipline (even Wikipedia has no entry for it yet) and a trendy business buzzword. Given a confusing array of approaches in an evolving field, those charged with conducting such analyses can find unearthing practical information on the steps involved to be a daunting task.

Fortunately, when E. Bond Francisco, a computer-resource manager in Physical Plant-Campus Services, wanted to learn how to conduct a process analysis, he knew just where to go: his colleagues on the campus. With one query to Micronet, a campus e-mail network of computer-technology professionals, he reached James Dudek, a senior policy analyst in the College of Letters & Science. Francisco's questions and Dudek's organizational experience, honed in the service of student advising and several staff organizations, led to the launch of the Business Process Analysis Working Group (affectionately known as BPAWG) in September 2005.

"I was asked to analyze and map out my department's business processes," recalls Francisco, "but I didn't know how to go about it. I couldn't find any training classes on campus, so I thought I'd ask for a little help from my friends."

Although he wasn't developing a computer program, it turned out that business-process analysis is often an information-technology exercise. The responses to his question came from programmers and system developers as well as non-technical analysts, many of whom were struggling with similar projects from their different perspectives.

One of those analysts was Dudek, who was working with a team in Letters & Science to understand and integrate several systems that staff use in the Office of Undergraduate Advising. They were in the midst of a complex project that required interviewing staff about minute steps in their day-to-day activities, mapping the processes, and working with programmers to develop a "dashboard" that would give the advisers a single point of entry into existing student service databases.

With members from every point on the IT-to-non-IT spectrum, BPAWG surfaced some unexpected lessons. At first the techies and non-techies eyed each other a bit warily, but after a couple of meetings most realized that their work could be easier if they understood each other's point of view.

Jarralynne Agee, who is both a staffer and faculty member, had an "aha" moment after hearing a BPAWG panel discussion.

"I was always feeling that other people's [IT] projects were getting done ahead of mine," Agee said recently. "After the meeting I understood that sometimes it's the processes that affected whether my requests were being handled, not the people. I understood some of the demands and pressures that my colleagues were under."

Grassroots knowledge management

Defining process analysis was one of the first tasks facing the BPAWG coordinators. For some it's "workflow" mapping, which involves diagramming the steps and choices in a process. Others saw it as project management, while some homed in on developing technology solutions to automate processes.

Co-chairs Dudek and Francisco decided that the benefit of sharing information and ideas was more important than drawing boundaries around the subject, so they asked the members to vote on future meeting topics. Recent meetings have featured a balance of technical and non-technical agendas, including case studies, tutorials on workflow mapping and interview techniques, and project-management tips like handling conflict or locking in sponsorship for a project.

"You need all these elements to be successful, no matter what the project is called," says Dudek. "BPAWG was a great help to me because so many of my colleagues shared what they knew, asked the right questions, and helped each other find the solutions."

BPAWG member David Rieger, an information architect in the Office of Laboratory Animal Care, agrees that the value of staff organizations like BPAWG lies in the contributions of members.

"BPAWG is a community where we can dialog in a non-pressure situation," he says. "It's an innovative model for collaboration, created by staff who want to exchange ideas, learn about best practices, and meet like-minded people. It's a source of talented, creative individuals who wear similar hats but speak different languages; through the work group, we're developing a consistent way of speaking about project management on this campus."

Francisco describes it as a "community of practice," a social-science term for a group of individuals who come together around a passion for learning and interaction on a given subject.

"The glory of this organization," says Francisco, "is that it is self-grown.a true grassroots support group. The value of that has been to increase everyone's knowledge of the issues we all face in accomplishing our goals."

BPAWG meets monthly. Meeting schedules, announcements, and pointers to presentation materials are online at stafforg.berkeley.edu/bpawg.