<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Enterprise Geeks Podcast &#8211; Transparency can be a Bitch</title>
	<atom:link href="http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/feed/" rel="self" type="application/rss+xml" />
	<link>http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/</link>
	<description></description>
	<lastBuildDate>Fri, 10 Feb 2012 02:33:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Ed Herrmann</title>
		<link>http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/comment-page-1/#comment-204</link>
		<dc:creator>Ed Herrmann</dc:creator>
		<pubDate>Wed, 04 Mar 2009 04:17:58 +0000</pubDate>
		<guid isPermaLink="false">http://enterprisegeeks.com/blog/?p=528#comment-204</guid>
		<description>@Leonardo - I&#039;m certainly not arguing the value of being functional vs. technical. As I stated previously, functional guys ARE usually very capable business process experts, and using the common term &quot;functional&quot; trivializes their added value.  The word functional is too often associated with a guy who only does configuration, whereas in reality, they are usually involved in tying the business together with the technical. 

I don&#039;t consider the business process expert a new role that sits in between the business owner and the functional guy; instead  I consider it a better direction and better focus for the already existing functional role.

Business Process Expert is to Functional as
Solution Architect is to Code Monkey</description>
		<content:encoded><![CDATA[<p>@Leonardo &#8211; I&#8217;m certainly not arguing the value of being functional vs. technical. As I stated previously, functional guys ARE usually very capable business process experts, and using the common term &#8220;functional&#8221; trivializes their added value.  The word functional is too often associated with a guy who only does configuration, whereas in reality, they are usually involved in tying the business together with the technical. </p>
<p>I don&#8217;t consider the business process expert a new role that sits in between the business owner and the functional guy; instead  I consider it a better direction and better focus for the already existing functional role.</p>
<p>Business Process Expert is to Functional as<br />
Solution Architect is to Code Monkey</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Leonardo De Araujo</title>
		<link>http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/comment-page-1/#comment-203</link>
		<dc:creator>Leonardo De Araujo</dc:creator>
		<pubDate>Wed, 04 Mar 2009 04:03:37 +0000</pubDate>
		<guid isPermaLink="false">http://enterprisegeeks.com/blog/?p=528#comment-203</guid>
		<description>Ed,

Let&#039;s not get into the old argument of functional vs technical. First it is not right, second it doesn&#039;t bring us anywhere. Both are dependent of each other and both bring (or should) different skill sets to the table. We all know that incompetence exists in both sides of this equation.
Thanks for your comment though. It made me realize that I didn&#039;t get my point clear.
Let me rephrase it:
Even though Mark Finnern may be happy about the fact that SAPFANS website is dying, but reality is, still functionals don&#039;t use SCN enough. If BPX is what functionals should aim for, good point, but I don&#039;t think we paved the way well enough. It looks like technicals are covered and the Grey area BPX&#039;s too, but what about the middle guy? 
I am strong believer of the functional role and I find that BPX is the way to go. By definition they are the ones that should be the &quot;Business&quot; &quot;Process&quot; &quot;Experts&quot;. They are the ones representing IT facing the Business requirements. They &quot;should&quot; have a very strong technical base, but reality is, the majority of them are very weak in this area. In my point of view, functionals should be able to identify which user exits to use, for example, but that is not what happens in real life.
All this to say that functionals are not properly represented there (at SCN) and they should. I think it is the best way to get them more involved/exposed to what is &quot;under the hood&quot;.
We all have wikis at SDN for technical stuff. What about functional side (MM, SD, etc)? 

And please don&#039;t see me from the negative side. I am a true believer in the community and what we&#039;ve all accomplished so far. It is just that there is still work to be done. 

Leonardo De Araujo</description>
		<content:encoded><![CDATA[<p>Ed,</p>
<p>Let&#8217;s not get into the old argument of functional vs technical. First it is not right, second it doesn&#8217;t bring us anywhere. Both are dependent of each other and both bring (or should) different skill sets to the table. We all know that incompetence exists in both sides of this equation.<br />
Thanks for your comment though. It made me realize that I didn&#8217;t get my point clear.<br />
Let me rephrase it:<br />
Even though Mark Finnern may be happy about the fact that SAPFANS website is dying, but reality is, still functionals don&#8217;t use SCN enough. If BPX is what functionals should aim for, good point, but I don&#8217;t think we paved the way well enough. It looks like technicals are covered and the Grey area BPX&#8217;s too, but what about the middle guy?<br />
I am strong believer of the functional role and I find that BPX is the way to go. By definition they are the ones that should be the &#8220;Business&#8221; &#8220;Process&#8221; &#8220;Experts&#8221;. They are the ones representing IT facing the Business requirements. They &#8220;should&#8221; have a very strong technical base, but reality is, the majority of them are very weak in this area. In my point of view, functionals should be able to identify which user exits to use, for example, but that is not what happens in real life.<br />
All this to say that functionals are not properly represented there (at SCN) and they should. I think it is the best way to get them more involved/exposed to what is &#8220;under the hood&#8221;.<br />
We all have wikis at SDN for technical stuff. What about functional side (MM, SD, etc)? </p>
<p>And please don&#8217;t see me from the negative side. I am a true believer in the community and what we&#8217;ve all accomplished so far. It is just that there is still work to be done. </p>
<p>Leonardo De Araujo</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ed Herrmann</title>
		<link>http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/comment-page-1/#comment-202</link>
		<dc:creator>Ed Herrmann</dc:creator>
		<pubDate>Wed, 04 Mar 2009 02:25:47 +0000</pubDate>
		<guid isPermaLink="false">http://enterprisegeeks.com/blog/?p=528#comment-202</guid>
		<description>@dan +1 on your +1. With virtual classes with online instructors, one might actually...learn something :O

@Graham LOL

@Leonardo I&#039;ve always questioned the value of only being &quot;functional&quot;. I think it&#039;s actually a good thing for functional people to grow into Business Process Experts.  Even now where I work, we rarely have people dedicated to configuration; they are usually responsible for tying the business processes together with the development.  I don&#039;t want to rain on anyone&#039;s parade, but being a, for lack of better term, &quot;configurer&quot;, is just not that hard in itself.  I&#039;ve never met a respectable developer that couldn&#039;t run SPRO and throw entries in a table.  The hard part to understand is how that configuration affects the business process and ties the application together....in other words, a business process analyst/expert

@brian agreed! I hope to spend more time in future episodes on BPX, Solution Architects, and team landscape/structures.  

Cheers,
ewH</description>
		<content:encoded><![CDATA[<p>@dan +1 on your +1. With virtual classes with online instructors, one might actually&#8230;learn something :O</p>
<p>@Graham LOL</p>
<p>@Leonardo I&#8217;ve always questioned the value of only being &#8220;functional&#8221;. I think it&#8217;s actually a good thing for functional people to grow into Business Process Experts.  Even now where I work, we rarely have people dedicated to configuration; they are usually responsible for tying the business processes together with the development.  I don&#8217;t want to rain on anyone&#8217;s parade, but being a, for lack of better term, &#8220;configurer&#8221;, is just not that hard in itself.  I&#8217;ve never met a respectable developer that couldn&#8217;t run SPRO and throw entries in a table.  The hard part to understand is how that configuration affects the business process and ties the application together&#8230;.in other words, a business process analyst/expert</p>
<p>@brian agreed! I hope to spend more time in future episodes on BPX, Solution Architects, and team landscape/structures.  </p>
<p>Cheers,<br />
ewH</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Reed</title>
		<link>http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/comment-page-1/#comment-201</link>
		<dc:creator>Jon Reed</dc:creator>
		<pubDate>Tue, 03 Mar 2009 21:25:43 +0000</pubDate>
		<guid isPermaLink="false">http://enterprisegeeks.com/blog/?p=528#comment-201</guid>
		<description>Brian, thanks for the kind words, I&#039;m glad you enjoyed my appearance on eGeeks. Thomas and Ed had some terrific questions that really challenged me to come up with something worthy of eGeek status. 

I would agree that more discussion of the Solution Architect/Enterprise Architect roles would be great fodder for Ed, Thomas et all for future podcasts. If you want a quick fix on that, I have two relevant podcasts on my site, both with Kent Sanders, one that looks more at Enterprise Architect skills and one that looks more at the Basis-to-NetWeaver skills transition. I really liked what Kent had to say on this.

Leonardo, I&#039;m not sure if I get all aspects of your comment but I would say that I think SAP is certainly determined to cultivate more functional areas on BPX, that&#039;s the reason for the ERP@BPX launch for example. But much more can be done, that&#039;s for sure, before BPX reaches anywhere near the strength of SDN overall.

As for BPX roles being distinct from functional SAP work, I can see in the future a &quot;Process Expert&quot; role that is more about BPM modeling and process orchestration, which then fits into what you described. But, I have yet to see such a role on a project site. For now, I think BPX is something for functional SAP folks to take seriously as a way to round out their skills and remain relevant in process-driven SAP settings. I don&#039;t see BPX *ever* being one &quot;process expert&quot; surrounded by traditional functional config roles. I think everyone&#039;s role will evolve, and for now, if you have strong configuration skills, you probably have an advantage over a general BPXer that doesn&#039;t have deep SAP background. 

- Jon</description>
		<content:encoded><![CDATA[<p>Brian, thanks for the kind words, I&#8217;m glad you enjoyed my appearance on eGeeks. Thomas and Ed had some terrific questions that really challenged me to come up with something worthy of eGeek status. </p>
<p>I would agree that more discussion of the Solution Architect/Enterprise Architect roles would be great fodder for Ed, Thomas et all for future podcasts. If you want a quick fix on that, I have two relevant podcasts on my site, both with Kent Sanders, one that looks more at Enterprise Architect skills and one that looks more at the Basis-to-NetWeaver skills transition. I really liked what Kent had to say on this.</p>
<p>Leonardo, I&#8217;m not sure if I get all aspects of your comment but I would say that I think SAP is certainly determined to cultivate more functional areas on BPX, that&#8217;s the reason for the ERP@BPX launch for example. But much more can be done, that&#8217;s for sure, before BPX reaches anywhere near the strength of SDN overall.</p>
<p>As for BPX roles being distinct from functional SAP work, I can see in the future a &#8220;Process Expert&#8221; role that is more about BPM modeling and process orchestration, which then fits into what you described. But, I have yet to see such a role on a project site. For now, I think BPX is something for functional SAP folks to take seriously as a way to round out their skills and remain relevant in process-driven SAP settings. I don&#8217;t see BPX *ever* being one &#8220;process expert&#8221; surrounded by traditional functional config roles. I think everyone&#8217;s role will evolve, and for now, if you have strong configuration skills, you probably have an advantage over a general BPXer that doesn&#8217;t have deep SAP background. </p>
<p>- Jon</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Dennett</title>
		<link>http://enterprisegeeks.com/blog/2009/03/02/egeeks-podcast-episode-8/comment-page-1/#comment-200</link>
		<dc:creator>Brian Dennett</dc:creator>
		<pubDate>Tue, 03 Mar 2009 19:39:01 +0000</pubDate>
		<guid isPermaLink="false">http://enterprisegeeks.com/blog/?p=528#comment-200</guid>
		<description>I think you guys touched on an important point in this podcast that didn&#039;t get nearly enough attention. The whole concept of the solution architect and its role in the project landscape is definitely worthy of its own podcast. I hope you guys push that discussion in the near future and get other eGheads to discuss their ideas and experiences on the subject too.

And Jon, I love what you bring to the table and I hope the guys get you back on soon.</description>
		<content:encoded><![CDATA[<p>I think you guys touched on an important point in this podcast that didn&#8217;t get nearly enough attention. The whole concept of the solution architect and its role in the project landscape is definitely worthy of its own podcast. I hope you guys push that discussion in the near future and get other eGheads to discuss their ideas and experiences on the subject too.</p>
<p>And Jon, I love what you bring to the table and I hope the guys get you back on soon.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

