Confessions of a Security BPX

I am really looking forward to Community Day at SAP TechEd 08 in Las Vegas, especially the BPX sessions. I think that SAP security professionals have a natural home in the BPX Community because many of us were BPXs before BPX was cool- or even had a name.

Some readers might have the idea that BPX is strictly about business processes such as accounts payable or human resource management processes, but when you think about it, user provisioning of key enterprise applications such as SAP is just an extension of HR’s new hire on boarding. In an optimal scenario, IT processes flow seamlessly from the business process, and a sharp BPX will understand how and why it fits together, in order to watch for opportunities to make a good process better.

In Orlando at ASUG/SAPPHIRE, a panel of security experts facilitated a free-wheeling discussion that touched on a wide range of technical, process, and organizational issues. One of the topics that sparked a lively and extended dialogue was the question of what background most often makes for a good security analyst. The consensus of those present was that it is a significant advantage for security professionals to have some business process experience, compared to having strictly IT education and experience. Those without such business experience can certainly work to compensate for that gap, but there was a clear recognition of the advantages of non-IT business experience, and those who have been in a position to hire security analysts were quick to acknowledge that it can be a factor in their hiring decisions.

I can speak for that advantage. The years I spent in accounting and finance gave me first-hand understanding of the processes that we were configuring in the deployment of the FI-CO module and in the security role design of the associated roles. My brief experience in operational auditing reinforced in me the importance of controls in business processes and the value of automating those controls where possible. Learning the technology of role and user management, the structure of the key security tables, and creating the transports was pretty straightforward; having the background to understand why the roles were designed as they were made a big difference. I am sure that I am just one of many security BPXs who recognize the value that our experiences in business have brought to our security and compliance work.

As BPXs we have one foot in process and the other foot in technology- neither pure suit nor pure geek, to borrow Bill Pfleging and Minda Zetlin’s coinage in The Geek Gap, but a little bit of both. BPX describes us pretty well, but the million dollar question is, are our organizations ready to recognize this neither-fish-nor-fowl type of job role? The security professionals I know have a wide-ranging variety of job titles: IT analyst, engineer, strategist, business analyst – but is anyone actually being called “Security Business Process Expert”? Or is there another name for your job that encapsulates both a technical and process component in your expertise and responsibilities? Some organizations are quick to recognize the need to adjust their HR positions, but it seems all too common for organizations to be stuck in old style, either-or thinking and rigid employment tracks that get revisited maybe every 10 years if you’re lucky. Employees are hired into positions slotted in technical tracks or process tracks, sometimes with huge compensation differences, and jumping the track can be a challenge. I would love to hear from readers whose organizations have recognized that today, it is a “both and” rather than an “either or” IT world. How did your organization come to recognize the value of BPXs?  I invite you to comment and share your organizational transformation story with us.

Who else besides security people felt an immediate connection with the concept of BPX?  I would guess that it is a natural fit for Workflow experts. Perhaps to a certain extent, all of us in the technical support professions are recognizing that the technology must be deployed in the context of our business processes, so perhaps there is a little BPX in us all.