End of Year Musings
It's getting close to the end of the year and that usually offers a chance for reflection. In my role as a community facilitator of blogging and bloggers, I recall my own first halting attempts to try a "content" blog submission in the SAP Network Communities, (my very first "uncontent" blog being the announcements of the weddings of my colleagues, Mark and Craig: The specified item was not found.). That was only a year and a half ago. Ah, how time flies here in the communities when you are......but I digress.
As a relative newbie, I was quite nervous about writing a blog titled: Why don't they let me blog? and was thinking that I was really way too new to dare to write about how to apply to become a blogger.
It seemed real presumptuous to write such a blog (okay, it probably was), but I wanted so much to support Mark in his absence and I was certain that if people were only more clear about what the expectations were of blogs and bloggers, all would be well...no more rejections...only dozens of perfect applications and fine contributions.
Fast Forward to May 2005. I am slated to help launch the sneak preview of the Business Process Expert Community. Very eager to have the community start engaging in marketfree dialog and conversation around Who is a BPX?. I start forum threads and interface with the new names and roles (business process architects, business process consultants, business process analysts) that join the BPX community. I also really hope to help and support the first BPX bloggers to get started. https://weblogs.sdn.sap.com/pub/u/251709884 [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] quickly figures out how to post and provide content.
Hungry for Content
Phase 1 of any roll-out of web content generally means a bit of scramble to get things up and running. BPX, with all the interest generated by this community, website, and role, proved no exception. And we didn't want to impose our vision of a BP Expert on the community, so we basically tried to be in "listen mode" to hear what the community had to say about the role and the creation of the site. Meanwhile, Audrey Weinland starts fleshing out a series of web pages, posts content, works with a taxonomy to describe the tasks of a Business Process Expert and maps those to new content areas and Business Process Life Cycle Phases.
Frauke Hoffmann starts to create an Industry Presence for Consumer Products while Mario Herger is creating the framework and first materials for the original BPX Community wiki contents. And I, I'm trawling, and hunting high and low for candidates to write interesting materials. What am I looking for? Methodologies, case studies, model sharing, templates. Basically the kind of material that focuses on what folks are doing on the business side. What do I want to avoid...no really really steer clear of...tech talk...you know....geek gab....like in: "No conversations about solutions, the technology, the application, the configuration, the modifications, the coding, the transactions...save me from transactions...please...please".
The BPX Blog Bouncer
Since our communities are self-governing to a large extent, I don't feel real comfortable with the idea of giving people rejection slips. But I'm learning, I'm learning. Sometimes we must be cruel to be kind. What does that mean? It means that if you don't want to absolutely scare away every single serious business process non technical profession and potential contributor to this Business Process Expert Community website, you had better start turning away SAP solution conversations at the BPX door.
Now maybe that sounds real nebulous, you know, cloudy, fluffy, unclear. So to make it more concrete I'm going to be a little naughty and share what goes on behind the scenes..share the kind of conversations we are holding in private...be a more public kind of bouncer. Not to insult, offend, or totally discourage participation, but rather to explain what it is we are looking for, and what it is we will reject. And maybe that rejection isn't for always, but just for now, as we ramp-up and try to advocate a different way of thinking, not simply repackage transactions into a glossier wrapping. I can't ask for your credentials like any normal bouncer. If you say you are a Business Process Expert, I am going to believe you, without asking for a certificate. Hell, there isn't any real certification quite yet, but I am going to ask you to speak a certain language when you come in through the doors and I'm going to ask you to leave all that transaction, solution, application talk outside for the moment.
A Real-Life Example
Into my mail box, comes the following blog draft (after at least an iteration of improvement suggestion emails)
"Would like to share one of the scenarios; where I've given some recommendation and suggestions to fix-up the current development issue to address both the Business and Technical needs, as a typical BPX member. Business Scenario: Management would like to kick-off of the auto approval process for expenses incurred, where a workflow driven event sent a note to the respective authorize manager or approval for further process. Technical Development: Development team have address the Business requirement by using the workflow technology and consider all of the necessary approval process and email notification process. Development Issue: a user whenever he/she update or save his details in the application a event was triggered and an email have sent to user and his approval manager, for instance, due to some reasons the user have updating his expenses in the custom application in multiple phases or in a intervals and save the active application in between the process many times, to make sure his entries are not lost, then an email notification is triggered automatically for every “Save” action, which in turn his/her approval will be having multiple email notifications, it will be really annoying when you look at the approval point of view as being a approval manager for few team members, assuming this happen for all of his team members, then his email account will have all of this duplications, instead have one email notification for each team member. As a BPX, solution provided, looking at the Business need and Technical development team, recommended to incorporate the “Notify” button option in the current application so that whenever user is ready to send his expense for approval, with click on notify button an event will be trigger and send only one email notification note to his/her approval manager. ."
Understand, please. This isn't an outline for a blog. This IS the submitted blog draft, verbatim. Rather than debate the point further here, I could suggest we move this to the BPX forum, asking the community to weigh in as to whether this kind of posting represents process-centric thinking.
If this is the kind of blog you want to see in this BPX space, please let me know.
It is a really big challenge we all are facing now, to move from an application, development, solution IT based way of looking at our business situations to a more process, task, activity perspective type of think. We need a language that truly reflects a business way of managing process and process improvement, rather than immediately moving to application or technical solution talk.
I thought the bulk of this content already focused on the technical solution, rather than an analysis of the business requirement....it immediately started talking about application and thus was more about a technical "enhancement" or modification of a program than a business process improvement activity. They are not the same are they? How would this impact business? Bottom line? KPIs? How would this be measured? Analyzed? We are not talking about a code fix or a BADI here.
Something that would add real value would be to take a deep dive into analyzing a process without any regard to the enabling technology and an already thought of solution. We need to learn to train our "already IT listening ears" so that we are not simply having a technical answer conversation going on in our technical heads, even at the moment that the buisness side is doing the business articulating and certainly before the business side has finished describing the situation.
Have you ever been in a conversation or a listnening where you are already forumulating a full answer to the speaker and thinking your own thoughts, while the speaker is speaking. You, not hearing, really at all, and not concentrating at all, on the speaker's words? (too busy with your always ever answer formulating).
Many of us are guilty of that at times....its a hard habit to kick, but it is our goal here, to kick it. That's when innovation happens..when we stop listening with our "always ever knowing solutions voices" playing away like a numbing chant in our tech heads.
