Okay, so who exactly is a business process expert? Well some of you might be saying or thinking of yourselves....I am.
And yes, Im posing this as question in this forum....and yes, as the person who asks the question, I have the privilege of awarding points for interesting answers. That means, obviously more than just simply...answering, I am.
Of course, awarding points for answers in the forums is not an exclusive right of a moderator as many of you, maybe all of you, well know. But since, in this particular thread, I asked the question, ..well...I get to award the points.
In fact anyone who begins a question thread in the community and gets helpful and interesting answers to the question can award points.
But I digress ..
So back to my question. Way back, many years ago, in my SAP career I met a very dynamic woman, <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.sdn.businesscard.sdnbusinesscard?u=v%2bokymjrgns%3d">helen Sunderland</a>, who spoke with passion and knowledge about Business Processes and Strategic Enterprise Management. When I heard a rumor that SDN was planning a sneak, sneak peek of a Business Process Expert Community,<a href="http://bpx.sap.com">http://bpx.sap.com</a>, I thought Id ask Helen to share just who is a business process expert I guessed she was one.
Helens answer can be found in this blog: <a href="/people/helen.sunderland/blog/2006/05/13/days-in-the-life-of-a-business-process-expert in the Life of a Business Process Expert</a>.
One womans opinion...
Im really interested to hear yours.
Us. It's the users. Both the users on a management level who define (or adopt industry standard) processes
and those people who live this processes or sub-processes in their every-day life.
Business processes exist in the 'real' (physical) world and should be seen as much more than mere technical
issues. They often involve such things as emotions (gut feelings, trust, ...) or inter-person communication
(e.g. negotiations) or social factors (social, political, environmental awareness/responsibility) all
of which are hard to model on a technical basis but very often distinguish sucessful from less sucessful business processes.
Therefore I disagree with Dr. Wolfram Jost's assumption of the CIO morphing into a CPO.
The key to the evolution of sucessful business processes will be the ability of the classically tech oriented CIO to communicate with a newly to establish CPO, who in turn being an expert in the assessment of the business process stakeholder's - aka the process participants or users - daily modes of operation and needs. The CPOs main area of expertise doesn't have to be knowledge of
each and every process in the business but rather provision of the modelling methodology and the skill to identify key process and sub-process users.
Today this role is often performed by external consultants who do a good job applying methodolgies and in effective assessment of processes but IMHO lack empathy/responsibility for the business, the business processes established and the business process users.
From a technology point of view this would pose a challenge for the CIO and CPO to model business processes with an adequate number of degrees of freedom to account for above mentioned technologically intangible factors. Factors which can only be assessed involving the real business process experts. The users. Us.
just my two cents,
Nice to see you here and responding.
Now I'm not a BPX nor a Subject Matter Expert, but it is clear that your answer is well thought out and certainly well articulated. It's my pleasure to reward you with the very first BPX points in this forum and encourage others to respond and receive recognition as well.
thanks for jumping in with such intent.
Anton makes a good point. In my opinion one starting point for a business process expert is experience as a USER.
I guess one can get elevated to the position of a business process expert if he/she has spent some time in the disparate departments/positions through which a business process flows through and thereby has come to know what are the important elements for unhindered flow of information from one end to the other.
Certain things like ease of use in filling up of the data forms, simple yet critical piece of information for internal checks, crucial reporting aspects are much better known and understood if one has worked as a user
If such a person can wear thinking hat and be devils advocate and question the necessity of certain things which are being done without anyone really knowing 'why' , in my opinion thats a firm step towards becoming a BPX.
I think Technology is just an enabler and its absolutely not necessary for a BPX to know about Tech though of course its helpful.
Functional consultants who have extensively worked on selected streams for many projects/clients obviously come to acquire lots of business knowldge and are also definitely BPX.
Anton, I like your paragraph about the non-technical aspects of business processes. Can you recommend any online or offline resources to that very topic?
I know those aspects from a software design point of view. To transfer these ideas specifically to process design sounds thrilling to me.
In my opinion BPX are business users with a process understanding.
I consider people who perform certain jobs on a day to day basis, lets call them users, to a process experts only if they have a bit of deeper understanding of the process side of their jobs.
A process, might be understood in the context of other processes or its tasks and components. Someone might perform a single task in a whole insurance approval process. I would not consider them BPX.
Again summing up, a BPX has broader understanding of various business elements interacting together to get some meaningful job done.
A BPX may be end user, but there are (at least) two key skills that one must have to be an effective BPX:
1. Vision - how processes (and technologies) fit together to achieve business goals - both in a larger context/framework and over a longer time period.
2. Consulting skills - ability to develop, express, and sell the vision to the various stakeholders
I have not found that these skills to be especially well developed in a large number of true end users.
The end users I know are working in a line of business department and are involved into process innovation project only to small part of their work time. Besides of that, the ones I know tend to come up with solution proposals rather than problem descriptions or requirements. And very often these solutions only make sense in their very own department. In my opinion they are lacking the big picture of which Helen Sunderland spoke.<a href="/people/helen.sunderland/blog/2006/05/13/days-in-the-life-of-a-business-process-expert">/people/helen.sunderland/blog/2006/05/13/days-in-the-life-of-a-business-process-expert</a>
But perhaps there are some end users with a BPX mind/understanding. Might be interesting to work with them.
A Business Process Expert (BPX) believes in and strives to implement process innovation through the use of technology. This definition clearly states that BPX is not just a business user. BPX is also not just an IT person.
A senior business person with technical aptitude is also not enough. In the real world, most business people do not understand intricacies of a proposed technical solution. The technical people take advantage of this ignorance and push back most of the changes proposed by the business people.
A technology person does not enough business clout to implement process innovation. The entrenched business people simply do not allow a technical person to change things around in their area.
In my opinion, a business technologist would be ideal to be in this role. A person who has strong background in Information Technology and now understands business area fairly well and has good rapport with business users would succeed in BPX role.
In my opinion, a BPX is someone who can take business requirements, understand them and translate these requirements into a practical technological solution. This is easier said than done!
I am reminded of when I started in IT many years ago, after struggling with designing a working solution to a business problem someone introduced me to Jackson Structured Programming - bear with me, this is leading to a point. JSP takes the known inputs, the expected outputs and methodically creates a design that satisfies both "constraints". In a similar way, a BPX should understand both ends of the problem, (a) what the business is trying to achieve, (b) has enough confidence in their knowledge of the technology to (c) fashion a innovative solution that works.
The key point is that almost always there is not an "off-the-shelf" solution. If there was, leave the task to the salesman. Unique processes can be made more controllable and efficient using a spectrum of solutions, but sometimes parts of the process should change. A BPX should know when to make that call, and whatever he delivers it should be <i>sustainable</i> (i.e. low maintenance, flexible, works in high volumes), all classic skills based on IT experience.
Business Processs Expert is not a person,but an community that consists of Functional Consultants,Technical Consultants,ERP Administrator, Top level Management, Key users and End Users who goal is to Implement an Solution by Re-engineering the business Processes, customising the solution and changingf IT Infrastructure if need be, Managing the change with a objective to achieve the measurable goals of the organisation.
If he was a One Man Army, then did we need a forum?
One who has the job of looking at "Procedures" being called "Processes".
These "Procedures" sometimes need a "BIT" of automation by say SAP Workflow or just plain e-mail. The "BIT" of automation that is required is usually under the direct control of the Business Experts, most of them user with X years of "Procedure" experience.
The Procedure experience has its value, but it can be a major bottleneck when the flexible adaptation is forced on to the company as nothing beyond these procedures was ever used here.
Someone who can look at the Procedure and try to put together a Process from these silo processes without making the Business Experts feel threatened for their jobs rather being able to transform the value from their Procedure experience to create a more appropriate custom Process could be a Business Process Expert.
A large part of the Expertise would be enabling such a transformation as it would require a major management backing to implement it with the feeling of being able to do more across all the parts of the process and avoid the feeling of torn or broken process due to insufficient participation, feeling of loss of power etc, which are usually more tricky and time consuming to deal with that the broken processes.
This would be easier for the foot solider (BPX) if the CIO did morph into a CPO creating a vision of looking at business as the process they are and not just the partsProcedures which they are not.
Talking in terms of ESA, BPX is a person who understands the requirements of a business and tries to address specific problems. He/She not only gives ideas to solve them, but also knows how to leverage the power of ESA by using the available Web Services and other direct solutions to solve the problem in an effective way.
Of course, this cannot be achieved alone by one person. This is done in collaboration with Developers, Consultants and System admins.
This new role seems to be a natural demand which is in-line with SAP ESA initiative.
We have all the enabling technologies.. XI, Enterprise Portals, WebDynpro, ccBPM. But what to build using all this is visualised by a BPX.
In my opinion, Business Process Experts are persons who can align business needs with possible IT solutions and needed user interaction based on the real business process.
The Business Process Expert will investigate and improve business processes. Using <a href="/people/r.eijpe/blog/2006/03/16/road-to-esa-150-the-epi-model-part-3a--approach modeling</a> you can investigate these processes including the manual steps.
IT vendors will provide new IT solutions. These are only valuable if they can be used in a business process step (direct) or if they can help you to improve your users productivity (indirect). The Business Process Expert will facilitate the tactical management to take the right decisions for implementing IT solutions, reorganize the organization and redesign/improve the business processes based on the real business processes. For this, the <a href="/people/r.eijpe/blog/2006/01/23/road-to-esa-150-the-epi-model-part-2 Model</a> can help Business Process Experts.
To me a BPX is fearless and does not succumb to either the users or tech geeks 'wants/pressure'. He/She looks at what make sense to the company's bottomline... sometimes coming up with elegant solutions (simple/sleek - KISS) may be a pain to the IT but will resolve lots of the users' headache and vice versa. A BPX is a peacemaker, a project manager, a facilitator, a leader in a standalone department reporting to the operations department lead (VP of OPS or COO)..not under IT and defenitely not directly under users' department..The closer the BPx is to the company's decision makers, the better he/she will be in setting strategies on whats worth looking into and what is not.
BPX is someone who is approachable, open minded and firm...a familiar face in the company.. someone everyone knows they can trust. He/She has enough IT understanding to be dangerous to the geeks yet understand the delicate interdependancies of funtional departments within the company.
A Business Process Expert (BPX) would be :
A person has been in the industry long enough to know the way of the land and can advice companies on thier business processes and how to define / redefine them.
The person would also be expected to be confortable with the systems to implement them. More often than is the case , the person ends up suggesting a particular system that h/she is familiar with rather than what the client actually needs. Also the BPX has the knowledge to appreciate the technical difficulties involved in implementing the business process as is and guides the end user to a more system friendly approach while not compromising on:
Ease of use
Compatibility with other systems / processes
The above three I would say should score high on the BPX's mind in designing / architecting solutions around the existing systems.
But playing the devil's advocate , this would mean that the person has to be an internal one , one who knows all the systems and process well enough to be able to design business process / improve them. Which leads to my next question , will an external consultant be able to become a BPX at all?
A consultant will bring lots of experience in his / her field of process. An internal expert may be stuck in the box and may not have had the breadth of industry that an external consultant has. This experience will save time and money by avoiding mistakes learnt at other implementations.
I agree with earlier comments that empathy and responsibility are paramount and perhaps its time that these qualities are measured?
There are many businesses who continue with unnecessary processes because "its always been that way". Consultants will bring efficiency and can provide evidence of earlier successes.
Hmmm...For an effective change management, the internalization of the change must come.. no... NEED to come from someone who is well respected within the company. How many consultant, whether real or percieve, has the real interest of the company @ heart? Have worked with plenty of consultants and was satisfied with only a few. The consultant as the name suggest is someone I use to bounce my ideas and work with to put forth strategies... the real work is done by employees (BPX, IT techs, super users and users of system).
A GREAT BPX challenge status quo... that should be his/her main focus.
In my opinion there are advantages and disadvantes with both internals and externals. What about combining these two? We often work with consultants/developers from outside the company, which often brings up new ideas that can be evaluated instantly with the insider knowledge of the internal.
There are really good points being made here..
I would like to comment on one aspect, which, in my judgement plays an important role in shaping the abilities and effectiveness of an BPX. I will take it step by step...
First - A BPX should definely possess business domain knowledge, partly through own experience, partly through consulting work, if any. It is obvious that these two (Line exp & Consulting) are complimentary and supplementary, and SHOULD co-exist, to add the breadth of knowledge.
Second - A BPX should be familiar with the IT tools (SAP..!). It could be operational experience, hands-on, or by association, in a managerial role.
Three - (and this is what I want to add..) A BPX must possess the ability to look into the underlying business requirements of the process that he is associated with, and shape the process for the FUTURE requirements of the business. Here his domain experience, his business experience and maturity, his knowledge of the IT tools have to come into play. This is where he would value by addressing the future business process needs, through IT tools available now.
An 'Expert' is no expert, if he cannot address the current, as well as, the FUTURE requirements of the business process.
Perhaps we can step back a little, ie what happens before we start looking at processes. Let's talk about scenario planning.
Pierre Wack of Shell had this wonderful definition of Scenario Planning which he said is "The Gentle Art of Re-perceiving".
Helen Sunderland in her interview with Marilyn summed it well saying "Big picture focus (synthesizing): the ability to identify the impact of the issue on the business and the effect of the solution on the business; as well as the capacity to link the solution into the current business and technical landscape Modeling ability: need to be able to model a solution that meets the business requirement within the confines of the technology" /people/helen.sunderland/blog/2006/05/13/days-in-the-life-of-a-business-process-expert accessed 3 June 2006.
A BPX must understand thoroughly the Business Strategy which starts at SEM. Strategic Enterprise Management (SAP). It is here where the Strategic Initiatives are defined and measured, which are then cascaded into KPIs. It is imperative to start at the top in order 'gently re-perceive the future'. The first step as a BPX is to understand the Organizations strategy, and then to work with Strategic Objective owners to re-engineer the future business scenarios which then can be the base for identifying which processes need to be re-engineered.
After all, BPX should be all be about improving Corporate Performance and improvements should be measured in the relevant strategic perspective- otherwise people will wonder why changes are being made.
I am really thrilled that we have this BPX community. As a SAP Change Management Specialist, I have been saying for years to SAP clients, "The power of SAP is in the processes, not only the system". I think with Solution Manager's strategic positioning in a SAP landscape as the Business Process Platform, Dr. Wolfram Jost ARIS) may be onto something when he says the CIO will morph into a CPO.
A few years back I was working with an SAP team as a Change Management Specialist. The project manager, at the kick-off meeting said "We are only here to configure the system" I was really dissapointed and we argued (out of client's hearing) about what an SAP project should be about. I am really pleased to see that SAP is changing and that it will begin marketing Business Solutions based on client processes and not just an installed/configured system.
With Kindest Regards
I am new to the term BPX, but after going through the SDN forums, I am able to make out the need for BPX'ers. I am working in SAP (technical side) for some time and have been to number of implementations. The major problems to be pointed out in the failure of implementations can be summarized as:
1. Poor understanding of Business Blueprint by the consultants who have to ensure the smooth transfer from legacy system to SAP.
2. Poor requirement gathering from customer / client.
3. Poor understanding between the Technical and Functional consultants.
I think the role played by a BPXer can help to minimize these anomalies. The BPXer can be aware of both the sides, business flow in a large extent and technicality of the requirement in a promising aspect. He can help out gathering the genuine user requirements and map into the existing business with all forms of feasibility. He can forecast better methods of business practices and the formulas to implement them. He can bridge the gap between a '<i><b>GOOD</b></i>' implementation and a '<i><b>Successful</b></i>' implementation.
The role of a BPXer is very much welcomed in the community to bring implementations easy and more successful and I think personally that Technical consultants can be shaped easily into BPXers (More easy if he is aware of netweaver concepts or BIW, CRM..)
"I think personally that Technical consultants can be shaped easily into BPXers"
When looking at the demography of Business Process Management Events (such as the last Gartner BPM summit) one finds a great number of attendees do come from IT departments...and yet...I wonder just how technical this Business Process Expert needs to be.
I'm sure that many in the SDN community may feel that as a developer one needs to have or already does have many of the skills of a BPX. In a recent blog I posted concerning the delineation of the role and various demarcation lines-<a href="/people/marilyn.pratt/blog/2006/06/04/one-community-or-two Community or Two</a>, developer<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.sdn.businesscard.sdnbusinesscard?u=nu3rpndlsru%3d">piers Harding</a> commented: "in todays IT world - a developer is required not only to program (the smallest part of the task) but to articulate, model, design, implement, test, document, and deliver a business requirement. In short - a developer of today, is part programmer, systems analyst, business analyst, change manager, documenter and trainer".
That sounds remarkably like a description of a BPX...yet many functional folks feel it is easier to make a business process expert out of a business-oriented person, than to fashion one from a purely technical person.
Ah...Business Process Expert..
In my opinion any person who makes and innovates such design & measurements; which can enable "people driving the business and not the business driving those people"
"modeling solutions to business issues that can be implemented in technology"<----- I do not agree. I think the bottomline behind this thought is more of a style of streamlining a "business" for the technology and not streamlining the technology for "business"....
I think a "BPX" is itself a very dynamic & complex thought which might refer to the ability to define, model, streamline, analyze and "proactively" improve business processes...
I think that a BPX is someone who is proficient in business processes. It does not necessarily mean that he has to be an expert in SAP or Oracle or any other Enterprise softeare for that matter. What matters at the end of the day is that a BPX should understand the exact need of the business. A user can be a BPX.
I think we should detach a BPX from software. If I want to add some new department in my company, how to exactly go about it for the seamless integration with the rest of the enterprise. These are the sort of questions which a BPX should be able to answer.
A BPX should have a broader vision. He should have indepth knowledge in some area (Example Sales and Distribution) and a vision of addressing problems and bottlenecks.
If such a person is associated with an Enterprise software, he should try to match the software to the business. Not the other way around. At the end of the day, users are the real BPX.
Users can become BPX...no doubt. But the question is how long and efficient it would be. Users will be very much aware about the Business day to days. The User will also be aware about the module he is practicing; like he can be a FI user and he will be really good in the day to day transactions related to FI.
We are aware about lot of User communities coming into SAP. Thinking in a broader level, they have to be trained more in other technologies of SAP like; things that can be done and cannot be done in ABAP for example. Here I am not talking about training in an <i><b>aggressive level</b></i>, but at least make them familiar with the very basics.
So here, a BPXer is shaped up from experience he gains, both from the functional and technical side. He has to forecast different changes in the Business as a whole providing <i><b>cost - time</b></i> saving solutions and the possibilities of implementing those solutions within the package (ERP).User can be an expert in one module like Sales and Distribution and he can address the problems and bottlenecks within SD. But it will be difficult for the user to <i><b>forecast</b></i> business changes and the feasibility of implementing the changes in SD using the relative ERP.
Definitely a User can become a BPXer but the task is not that easy. And a BPXer undoubtedly has to know about the ERP package to make predictions and forecasts. If it is in SAP, he should know what is provided and not provided in SAP. BPXer should not only map software to business; he should map business to software also.
So I cannot agree to the point that by the end of the day users are real BPXers, but they can become BPXers with <i><b>lot of efforts</b></i> added.
While going through this thread post by post, point by point, I was wondering about Baconion Philosophy --Knowledge is power. I find today it is -Community -Community is Power.
Anybody who designs the Standard practices is Expert.
Anybody who understands business processes to this level is BPX. Now,who exactly is the X -End User or Developer or External Consultant?
End user is closely watching the process hence he can suggest the BEST adaptable changes ; Developer knows the limit of comlexity of coding hence he can suggest the BEST configurable changes; External Consultants have wider vision as they implement similar chages here and there hence they can suggest BEST prevailing changes.
Now can't we sum all the BEST changes and make a BEST BP? If yes, then BPX is not a person but a community.
The discussion over whether or not a "user" can be a Business Process Expert is very interesting.
I wonder if any of you have practical experience or knowledge of a user who did become a BPX. Real stories rather than conjecture, would be needed to convince some of us that such a scenario is possible.
The best BPXs I know are working in the planning/architecture/strategy team of IT organizations. They're not from the business units or in the realization or development teams of IT organizations.
They're senior business analysts (grey hair usually) who knows the history of the business processes in their company, their evolution, the people, the politics.
They work in team with senior technical architects to shape enterprise architecture, governance and innovation.
Because of the lack of maturity of the technology (Netweaver as composition platform), the few BPX will need time before enable business analysts to become BPX.
Some companies don't even have EA/Planning/Strategy team. So it's hard for them to nurture the needed BPX. If IT organizations spend most of their resource to implement or realize, it's hard for people to justify to work on innovative topics and build credibility and value proposition for changes.
A bad example of BPX is when business or functional analysts working out of their IT Development or IT Realization or even business units try to behave as BPX using traditional means, approaches, technologies they have on hand. That lead to bad architecture, wrong choices of technologies and costly solutions to develop and maintain.
There're only a few BPXs today for the simple reason that Netweaver as composition platform is so new and only few companies invested in nurturing this needed next-generation of technical and functional Enterprise Architects. Whoever embraces Netweaver as composition platform and deliver composite processes and applications will produce this kind of profile.
All users cannot be termed as Business Process Expert.
You will find many users who just take their work/tasks as their daily job and does not want to understand/visualize the big picture.
It takes a Business Process Expert to help them relaize this and change this attitude. My ex-Solution Architect took such courage and the defined a process which was then better known as Azuhar's Process after his name...
Only those users who really understand their role in a complete process and think about ways to optimize their work or the complete process should be termed as the real Business Process Expert.
I have knowledge of a user who has become a BPX. Just happens to be myself. After working in manufacturing for 17 years, primarily in the materials management and production planning areas, I was assigned to our company's SAP implementation project as team lead. Things were not progressing well so gave up my team lead position for a more "hands on" role and went to training classes learning as much SAP as I could. After a year of doing this and working with the system, I knew more about SAP than the consultants being put onsite by our integrator. Eventually the project failed and I left the company to pursue a career of consulting. Went and passed my certification tests in MM and PP applications, then did SAP consulting for big 6 firms (back then it was big 6) for 7 years. Then hired onto one of my clients as an application lead analyst for 6 years. Today, I hold the position of Sr. SAP Business Analyst because of my extensive background in business and in technology, specifically SAP.
This is the position that I and most likely many others want to be or think they have achieved. In review it is the multiude of all the previous responses. The BPX expert is knowledge of and understanding of Business and Technology ...not only what is happening today but with the vison of tomorrow. They would have the pulse on the bottom line yet the ability to persuade change in the work place.
Yet has focus on the details that is needed to make the business move forward and bend with the tides. Even though a some business practices and processes are steadfast the strategy to be able to handle changes without having to redo or change existing processes to reinvent the same cost again. The ROI is visible and usful for the business. The person has perception to understand the team's or company's strength and weaknesses to evolutionize the business growth.
I feel Business Process Expert can have a relative definition...basically, from user point of view it would be person who performs(knows) the business process from its entry to exit point(basically the whole process) would classify himself as an Expert. While from Technical point of view, a person who understands the process as well as its technicalities(config/interfacing etc) in details would classify himself as a BPX.
So overall, in conclusion the definition can be a person who understands/knows the process from its entry to exit point with respect to his/her role, would classify as a Business Process Expert.
Business Process Expert (BPX) would be the vital link between the ERP products and the Customers in an enterprise set up. I have listed Some of the characteristics of a BPX -
1. Domain Expert - He should have thorough enterprise knowledge in any of the industry verticals such as Retail, Utilities, Automotive etc
2. Technology Expert - He should be able to liaise with the CIO and make them aware of the solution fit and Business assurance.
3. Auditor - By his domain and technology expertise he should be able to audit the solution being built and continually guide the implementation team. He should be able to pro-actively ensure that the solution is in line with the enterprise requirements and also ensure that there is no gold plating.
4. Change Manager - Interface between the implementation team and the customer. This would happen once the customer and the implementer have confidence in the BPX.
5. Charismatic - He should be a person who has the charisma to make the stake holders trust him.
6. Project/Program Manager - Preferably a PMP who understands various aspects of Project/Program management.
7. He should be able to look at customer's overall solution landscape and pro actively help optimize the solution.
In the long term BPX community should be an entity of people for Business Assurance and help companies plunge into ERP projects with greater confidence.
BPX in action when it matters most.
Few years back I was working on an IS - Auto project for a global Auto manufacturer. Two days after joining the project I was challenged to come up with a solution for tracking the CKD kits from port to the plant. Since SAP does not have a solution to track CKD kits with multiple boxes assigned to a KIT, I had to quickly design a new application. After couple of meetings the solution was accepted as the best answer to a long pending issue.
The R&D mind set and automotive industry background helped me develop a solution quickly. Now I am expected to design solutions based on the new technologies available in the market including design of architecture.
So does agility = business process expertise.
In more traditional application models, one gathers requirements from users, refines the requirements, implements them, often works with change requests, modifications and adjustments. The traditional model doesn't really work well in an environment where you change the model even before it is deployed.
But is it just being quick to design a new application that equates to Business Process Expertise?
This sounds like the start of a new thread on the topic of agility, dealing with fast-changing processes.
Is N Rao's scenario one of BPM or a more traditional application solution but just designed more quickly?
There have been a lot of interesting posts about who a BPX is, and many of make the argument that the IT skills are more important than the Business skills . I disagree. I think Ankur made a great point that it is important to detach BPX from software. Business drives the business processes, and the experts are the one who live it day in and day, regardless of whether they can program or implement software. In fact, I would make the argument that a large percentage of the people that should be classified BPXs dont have an IT background and have no real programming skills whatsoever.
How can I say this? This is a description of myself. I came to SAP after being part of an implementation team to install SEM-PA at a large bank. I had worked in banking for 8 years, and prior to the project had no IT experience at all. My value to the project was that I was able to cross the line and define what the business users wanted and needed out of the software. This is the value of a BPX.
> In fact, I would make the argument that a
> large percentage of the people that should be
> classified BPXs dont have an IT background and have
> no real programming skills whatsoever.
So BPXers need unreal programming skills
Sorry, couldn't resist.
> My value to the
> project was that I was able to cross the line and
> define what the business users wanted and needed out
> of the software. This is the value of a BPX.
This is true and I agree you don't need programming skills, but your job is so much easier if you know the limitations of the system and have a feeling of what is possible to implement.
IT knowledge helps on both sides. When talking to the businesses owners to set right expectations and to be taken serious from the IT folks because you come with realistic requests.
Just my two cents, Mark.
It could be looked at from two angles...
1. What is the best way to accomplish the necessary action. If it means to produce and sell a widget , what are all the processes involved... and each of the processes will have their own cross linkages between different systems irrespective of the function. You will have FI interacting with PM and SD intracting with PP and FI and so on.
In many cases a mindset is required to look at things from a process perspective - more from , The sales order will get confirmed by finance and then it goes to the inventory department. This is just a flow but the flow has to be well thought of and designed before implementing it in the system.
2. The next step is to look at how best to achieve the same technically and then look at possible deficiencies in the process and arrive at a satisficing solution to achieve the same.
When <a href="https://www.sdn.sap.com/irj/sdn/profile?userid=50850">marilyn</a> and Audrey initially approached the <a href="/people/anita.luu/blog/2006/02/28/the-industryspeak-program gang about the BPX topic, I was excited to see the SDN community grow in more <b>non-technical</b> areas. I'm still fumbling around in the dark for a more precise definition of <a href="http://en.wikipedia.org/wiki/Special:Search?search=BPX&go=Go">BPX</a>. I hope to see this one day... =P
<a href="https://www.sdn.sap.com/irj/sdn/developerareas/bpx?rid=/webcontent/uuid/cc0bd202-0b01-0010-9fbf-da3953eed4c2">this</a> [original link is broken] is a good start but not easy to realize.
There's quite few interesting opinions about who is or what makes a BPX in this thread.
Here's my 2 cents on how to achieve this:::
A Business Process Expert is the ideal marriage between the business user and IT. This would be an individual that understands the specific business requirements and how technology/software can help support these business needs. To a great extent SAP has many developers that have translated these business requirements into software. I would think that many of these developers could easily rise to BPX status, but maybe this is food for thought in another forum thread.
Ideally, Business Process Experts (BPX) becomes an officially <i>recognized professional designation</i>. This concept could be similar to a <b>DBA</b> - Process Integration (PI) & SOA Middleware for <i>"sample questions"</i> results in 752 hits for folks wanting hints on how to pass the XI certification exam. Maybe we see this as a similar BPX Metric or Indicator in the BPX forums, <b>if</b> BPX becomes a certification.
Does anyone share any of these opinions?
I'd say a Business Process Expert is someone who understands the Business and the Business Processes (which from my point of view will directly lead to BPX specialization) and can "convert" or "translate" these to IT requirements through deep ESOA knowledge and understanding. These requirements should then be implemented in the ESOA / NetWeaver landscape by so called ESOA experts, these will as well have a focus in EP, PI, ... but need as well the ESOA understanding - but more from a technical / developers view.
I think that's a mirror of the role of the CIO which will / should be split as well into two roles (CPIO and I think it's CITO) - or at least that's the state of the discussion as far as I know.
I've been reading a bit lately about Business Process Modeling, and it seems we are moving towards a point where we will have commonly accepted ways to describe business processes. We are not there yet, but business process modeling holds much promise. As with most things, it takes longer than the PowerPoint said. Different standards and methods currently compete (BPEL, WfMC and so on)
I see this as being as important as the move to technical standards and openness that NetWeaver, Websphere (even whoops Fusion) etc is all about.
The business process expert role for me, requires a number of skills.
Firstly. the ability to model processes with a modeling language with a high level of rigour. This skill should not be underestimated. This skill can and should be taught and examined.
Secondly. Knowledge of the business area itself. There will be some people that are able to look at many different processes, but I reckon most business process experts will focus on a particular process area, say treasury, or talent management. This requires a strong interest in the business discipline and a grasp of trends, what other companies have done, academic thinking and so on.
there are many other skills required too. Empathy with users, developers and executives, articulate business benefit, project skills etc....
BPXs should be all about improving business processes. This starts, fundamentally, with learning a common language (or two)
Thank you, Thomas. This post was thoughtful. I also like your book recommendation in another post.
Taken in aggregate, this whole thread of discussion, with ideas and BPX definitions from everyone, is enlightening and helpful, I think. It expands and clarifies.
We (the BPX community team at SAP) will likely take a shot at capturing these thoughts in a more formal way, and then presenting it back to the growing community ... yet also understanding that the definition may morph and further clarify in the future.
<b>Who exactly is a business process expert?</b>
I think Business Process Expert can be anybody who understands the business processes in details, who is a subject matter expert not required that he should be a manager in an organization. As a roles and responsibilities he should be able to map the standard business processes, subprocesses and should be able to propose the work arounds in the cases when the existing business process is not clearly matching with the requirment. He aligns the business requirements with possible standard business processes to achive the business goals.
Thanks and Regards,
Maybe we should open the discussion a bit beyond a "Human Centric" BPX. The main theme after all IS "The Business Process". There are hundreds, possibly thousands of Business Processes depending upon whether you categorize as micro or macro processes. Any one of these either on a micro/macro level function with or without human beings and may utilize machines that assist or automate value added activities/processes which produce higher value service or products in the age old scenario [input > process > useful output & waste output].
When we talk about Expert or Expertise, we are talking about precise know-how, and narrow domain knowledge wether depth or breadth knowledge.
Referring back to a post by Luis Rincones, regarding ideas and concepts leading to BPX, automation of the business process should be the KEY focus of a BP engineer. Back in the late 80's early 90's, we referred to these BP engrs. as "Knowledge Engineers" and their principal goals were to interview "Experts" in order to extract expert knowledge (sometimes 20+ years of experience) and understand not only the flow of the process, but more importantly the RULES which govern all exceptions and variations encountered within the process, as well as "rules of thumb" in case the RULES don't apply.
This is something which if we are truly to orient our Enterprise SOA architecture towards the goals of BPX mentioned above, will require a common "Rule Based Engine", which lives across all domains of knowledge, Objects, & environments, and works together with the design & development environment for the xAPP (I like to refer to them as "Expert Applications") and thereby enable not only the integration and homogenization of input data (via the technology stack), but also integrate the application of logic via a common rule based engine. In this way, E-SOA can also be enabled on the "useful" outbound process enabling services (actions) which mediate/manage/automate the process back to prescribed operating parameters.
Of course, people can not be eliminated from the process. Lexus factory in Korea back in 2002 operated with approx. 60 or so people, 150 robots, and produced >300 units per day. People were mostly involved in QA and deviation functions.
Automating the Business Process optimizes the output:input ratio and should minimize the waste:useful output ratio. By doing so, the ROI, ROA, and operating margins are maximized and competitive advantage gains against other not so able competitors.
Any one else has a few words on this?
sorry for posting a question for a question. But there has been quite a good number of opinions/ideas exchanged about who a BPX is. Now, my question is who hires the BPX? Will they most probably be hired by the company which is running the IT systems for their business? Or could he/she (BPX) be an employee of the IT services partner? If the BPX should have a deep process understanding the customer would prefer to have a home brewn resource converted into a BPX. And yet economies of scale, core competency retention and outsourcing the rest favour having the BPX from the IT services partner. Will be eager to hear some views about this.
It is the users. Users are the champions of each processes that they are dealing with in everyday life. In corporate world each of the processes can be divided into micro level and the people who actually carry out the jobs are the experts. If all these expert knowledge can be combined and synchronised then only the whole process can be delivered efficiently & effectively. That is why today's technology focuses on People Integration & Process Integration. I believe each & every one of the business are the domain experts and <b>the business process expert is the one who can take advantage out of all these domain experts</b>. This job is humanly impossible. That is why Business Process Expert can be thought of as a system assisted support backed by today's emerging technology.
I have been following this thread with great interest, For me the term expert is a "relative " term,Simiarly the term Business Process Expert is someone who has the capability to understand the Process in depth but at the same time have the vision and competency to tweak the same process for different industry scenarios.
A BP user is a good starting point but he will have the breadth of knowledge restricted to his/her domain.
However without making it sound too complicated!,anybody who has the attitude and the logical skill and knowledge to develop,modify or map a process to an industrial requirement consistently can or shall i say should be called a Business Process Expert.The key word is consistently!!
I am a new member in this SAP BPX community and so, am eager to make an attempt to define this term, based on my understanding on the business experiences thus far. I would like to define a BPX as one, who is able to provide an efficient and effective IT solution (in this case, an SAP solution) for an organization's business process issue and delights the requirement generator (the customer).
Nice to see there are so many angles you can use to describe a BPE. In my opinion BPX comes in many tastes.
When I try to explain BPM, I usually mention two dimentions: Business focus and Automation. Besides these dimentions there are 5 aspects: 1.Business Process Design, 2.Business Process Modeling, 3.Business Process Governance, 4.Business Process Improvement, 5.Business Process Implementation. I guess a BPX can't really be an expert on all aspects and is probably a specialist on one of the aspects, however a BPX should always be aware of the interdependancies and relations between the aspects. Besides this a BPX should have thourough understanding of the added-value of Business Process Management in certain life-cycle stages of target organizations and processes and therefore can translate the methodology into practical steps and actions.