<?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: Customization</title>
	<atom:link href="http://www.ldscio.org/2007/02/16/customization/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ldscio.org/2007/02/16/customization/</link>
	<description>Chief Information Officer for The Church of Jesus Christ of Latter-day Saints</description>
	<lastBuildDate>Fri, 12 Mar 2010 16:27:08 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Benjamin Hofmann</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-551</link>
		<dc:creator>Benjamin Hofmann</dc:creator>
		<pubDate>Fri, 23 Feb 2007 23:00:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-551</guid>
		<description>Unfortunately most businesses are not open to changing their processes and it doesn&#039;t always make sense to do so.  Some industry experts suggest purchasing a COTS framework that you can build on.  The framework would include common components but is designed and is expecting customizations. It is kind of a half-and-half system.  

I&#039;ve heard this suggested for content management systems and feel other application like ERP systems could benefit from this approach as well.  Have you had much experience in using a framework instead of a full COTS?</description>
		<content:encoded><![CDATA[<p>Unfortunately most businesses are not open to changing their processes and it doesn&#8217;t always make sense to do so.  Some industry experts suggest purchasing a COTS framework that you can build on.  The framework would include common components but is designed and is expecting customizations. It is kind of a half-and-half system.  </p>
<p>I&#8217;ve heard this suggested for content management systems and feel other application like ERP systems could benefit from this approach as well.  Have you had much experience in using a framework instead of a full COTS?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Randy</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-526</link>
		<dc:creator>Randy</dc:creator>
		<pubDate>Tue, 20 Feb 2007 22:31:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-526</guid>
		<description>COTS software has a place, you just have to know what it is.  Like the wise man once said, &quot;If the only tool in the box is a hammer, every problem looks like a nail.&quot;  You can&#039;t always do what you want with &#039;standard&#039; software, and for those issues there&#039;s a developer out there somewhere earning a paycheck.</description>
		<content:encoded><![CDATA[<p>COTS software has a place, you just have to know what it is.  Like the wise man once said, &#8220;If the only tool in the box is a hammer, every problem looks like a nail.&#8221;  You can&#8217;t always do what you want with &#8217;standard&#8217; software, and for those issues there&#8217;s a developer out there somewhere earning a paycheck.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Watson</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-525</link>
		<dc:creator>Rob Watson</dc:creator>
		<pubDate>Tue, 20 Feb 2007 15:52:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-525</guid>
		<description>Daniel,

Others can correct me if I&#039;m wrong, but I believe that TempleReady information is about to be or already is available on familysearch.org.  I believe that was announced in the latest GC.  The idea is that the Church knows definitively which persons have had work done (with the exceptions of ambiguous names and dates, which will always be a problem).  It&#039;s just that in the past the TempleReady &quot;database&quot; as it were has been disconnected from the family research side of things.</description>
		<content:encoded><![CDATA[<p>Daniel,</p>
<p>Others can correct me if I&#8217;m wrong, but I believe that TempleReady information is about to be or already is available on familysearch.org.  I believe that was announced in the latest GC.  The idea is that the Church knows definitively which persons have had work done (with the exceptions of ambiguous names and dates, which will always be a problem).  It&#8217;s just that in the past the TempleReady &#8220;database&#8221; as it were has been disconnected from the family research side of things.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniel Longmore</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-515</link>
		<dc:creator>Daniel Longmore</dc:creator>
		<pubDate>Sat, 17 Feb 2007 18:45:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-515</guid>
		<description>This blog entry certainly deserves comment. Sorry mine is a little off of the topic. I really hope this comment makes it to you and is not considered spam. I have been following your blog posts for a little while now. I have also been involved in the LDSTech forum. It is that effort that has spurred me on to writing this comment. In the hopes that you will pass it along to your peer at the Church who is over the Family History Technology. Here it goes... To use the old saying &quot;put your money where your mouth is&quot;.  With a little twisting the saying could be &quot;put your coding where your agile words are&quot;. May I please explain further. I think that many of members of the church could benefit from just a small change in the current familysearch.org website. It might be easiest if I explain what I do not need. I do not need someone to give me a nice interface where I can connect everyone together (GENi has done it for me). I do not need a place to enter research collaboration or enter biographical stories or keep pictures (WeRelate has done it). What I need is a way to simply track my opinions of what temple work has been done for a person. I say my opinions because that seems to be the biggest factor I run into. Everyone has their own opinions about what work has been done (and not done). I&#039;m not so interested in knowing whose opinion is correct. I just want to be able to choose which I work I think is right and have it stored for me somewhere. That way I can move on to those that I cannot find valid work for and do their work. Let me give you an example of what I mean. I imagine myself working with my research on Jane Doe (at the WeRelate site) and wondering what work there is at the familysearch.org. So I click on a link at my WeRelate site that does a search of familysearch.org for the person and up pops all the temple ordinance work on record for that person. I can then scan the screen looking for temple ordinances work I feel is right and when I see something that I looks correct I simply put a check in the check box to save it as my opinion of what work has been done (becuase I have a login it saves my choices into a database so when I return I can see my choices). I could go on with many other ideas however this is the real central one. I am sure with others input something even better than my idea can be developed. The point is something small today is better than a hoped for future big thing. This is just pure honest desire to get something done (not critiscm). I love all that is being done for me by all the wonderful people there. Thanks for being a listening ear.</description>
		<content:encoded><![CDATA[<p>This blog entry certainly deserves comment. Sorry mine is a little off of the topic. I really hope this comment makes it to you and is not considered spam. I have been following your blog posts for a little while now. I have also been involved in the LDSTech forum. It is that effort that has spurred me on to writing this comment. In the hopes that you will pass it along to your peer at the Church who is over the Family History Technology. Here it goes&#8230; To use the old saying &#8220;put your money where your mouth is&#8221;.  With a little twisting the saying could be &#8220;put your coding where your agile words are&#8221;. May I please explain further. I think that many of members of the church could benefit from just a small change in the current familysearch.org website. It might be easiest if I explain what I do not need. I do not need someone to give me a nice interface where I can connect everyone together (GENi has done it for me). I do not need a place to enter research collaboration or enter biographical stories or keep pictures (WeRelate has done it). What I need is a way to simply track my opinions of what temple work has been done for a person. I say my opinions because that seems to be the biggest factor I run into. Everyone has their own opinions about what work has been done (and not done). I&#8217;m not so interested in knowing whose opinion is correct. I just want to be able to choose which I work I think is right and have it stored for me somewhere. That way I can move on to those that I cannot find valid work for and do their work. Let me give you an example of what I mean. I imagine myself working with my research on Jane Doe (at the WeRelate site) and wondering what work there is at the familysearch.org. So I click on a link at my WeRelate site that does a search of familysearch.org for the person and up pops all the temple ordinance work on record for that person. I can then scan the screen looking for temple ordinances work I feel is right and when I see something that I looks correct I simply put a check in the check box to save it as my opinion of what work has been done (becuase I have a login it saves my choices into a database so when I return I can see my choices). I could go on with many other ideas however this is the real central one. I am sure with others input something even better than my idea can be developed. The point is something small today is better than a hoped for future big thing. This is just pure honest desire to get something done (not critiscm). I love all that is being done for me by all the wonderful people there. Thanks for being a listening ear.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-513</link>
		<dc:creator>Aaron</dc:creator>
		<pubDate>Sat, 17 Feb 2007 17:00:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-513</guid>
		<description>Jon, 

Regarding my last comment: a point of disclosure. I read that article during a class as part of my PhD studies.  I currently work for the journal that published that article, but I don&#039;t receive compensation for marketing or links, nor is advertising part of my job function.</description>
		<content:encoded><![CDATA[<p>Jon, </p>
<p>Regarding my last comment: a point of disclosure. I read that article during a class as part of my PhD studies.  I currently work for the journal that published that article, but I don&#8217;t receive compensation for marketing or links, nor is advertising part of my job function.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-512</link>
		<dc:creator>Aaron</dc:creator>
		<pubDate>Sat, 17 Feb 2007 16:51:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-512</guid>
		<description>I read an interesting case study recently (http://misqe.org/showabstract.jsp?ob1=68&amp;ob2=92) providing some criteria for determining when to bend to accomodate the &quot;vanilla&quot; ERP system and when customizations make sense. Basically, the authors suggest that bending to the vanilla system is preferred if the organization-software misalignment is a result of voluntary rather than imposed structures. The exception comes when the voluntary strucutre (those that orignate with the organization rather then due to industry or environmental factors) is closely tied to the business strategy / competitive position of the organization.</description>
		<content:encoded><![CDATA[<p>I read an interesting case study recently (<a href="http://misqe.org/showabstract.jsp?ob1=68&amp;ob2=92" rel="nofollow">http://misqe.org/showabstract.jsp?ob1=68&amp;ob2=92</a>) providing some criteria for determining when to bend to accomodate the &#8220;vanilla&#8221; ERP system and when customizations make sense. Basically, the authors suggest that bending to the vanilla system is preferred if the organization-software misalignment is a result of voluntary rather than imposed structures. The exception comes when the voluntary strucutre (those that orignate with the organization rather then due to industry or environmental factors) is closely tied to the business strategy / competitive position of the organization.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-511</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Sat, 17 Feb 2007 14:38:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-511</guid>
		<description>If you buy off the shelf, how can you distinguish yourself if you run the same software that everybody else does?

For a commercial company, I think doing your own thing is usually the best way to go - except maybe for business processes that can&#039;t be improved anymore.</description>
		<content:encoded><![CDATA[<p>If you buy off the shelf, how can you distinguish yourself if you run the same software that everybody else does?</p>
<p>For a commercial company, I think doing your own thing is usually the best way to go &#8211; except maybe for business processes that can&#8217;t be improved anymore.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Watson</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-510</link>
		<dc:creator>Rob Watson</dc:creator>
		<pubDate>Sat, 17 Feb 2007 04:50:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-510</guid>
		<description>Our core business is development of curriculum content for elementary schools. We custom-built a learning management system (LMS) to serve our customers instead of even considering COTS. Our custom app quickly grew into a Big Ball of Mud. Our customers _hate_ it. Then our lunch got eaten by a vendor whose core business it was to build LMSes.

Stick to your core business. Let vendors do the rest. Draw a &quot;reverse&quot; Venn diagram of the requirements regions where your vendor CANNOT provide what you need and then ONLY customize in that region IF the risk is low that doing so will affect your upgrade path. Keep the people who did the customization on your team and on your payroll (or transfer knowledge to their successors). Never let that information reside exclusively with the vendor (who will turn around and charge you a premium for using it, ironically). Document obsessively what you customized so that any adjustments you might have to make after an upgrade will go more smoothly. The document again after the upgrade.

Losing perspective on your core competency and product can end up costing you both the development dollars AND customer goodwill if (when) things go badly.</description>
		<content:encoded><![CDATA[<p>Our core business is development of curriculum content for elementary schools. We custom-built a learning management system (LMS) to serve our customers instead of even considering COTS. Our custom app quickly grew into a Big Ball of Mud. Our customers _hate_ it. Then our lunch got eaten by a vendor whose core business it was to build LMSes.</p>
<p>Stick to your core business. Let vendors do the rest. Draw a &#8220;reverse&#8221; Venn diagram of the requirements regions where your vendor CANNOT provide what you need and then ONLY customize in that region IF the risk is low that doing so will affect your upgrade path. Keep the people who did the customization on your team and on your payroll (or transfer knowledge to their successors). Never let that information reside exclusively with the vendor (who will turn around and charge you a premium for using it, ironically). Document obsessively what you customized so that any adjustments you might have to make after an upgrade will go more smoothly. The document again after the upgrade.</p>
<p>Losing perspective on your core competency and product can end up costing you both the development dollars AND customer goodwill if (when) things go badly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Johnson</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-509</link>
		<dc:creator>Tom Johnson</dc:creator>
		<pubDate>Sat, 17 Feb 2007 02:12:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-509</guid>
		<description>Hi, I actually just a suggestion rather than a comment related to your post. Would it be possible to integrate the Google Maps API with a geocoding program and a ward membership database so that we could map home and visiting teaching routes more effectively? Has this ever been explored? It would be one of the most useful tools ever.

&lt;em&gt;[Joel: Not only possible, but likely. Stay tuned...]&lt;/em&gt;</description>
		<content:encoded><![CDATA[<p>Hi, I actually just a suggestion rather than a comment related to your post. Would it be possible to integrate the Google Maps API with a geocoding program and a ward membership database so that we could map home and visiting teaching routes more effectively? Has this ever been explored? It would be one of the most useful tools ever.</p>
<p><em>[Joel: Not only possible, but likely. Stay tuned...]</em></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Smith</title>
		<link>http://www.ldscio.org/2007/02/16/customization/comment-page-1/#comment-507</link>
		<dc:creator>Brian Smith</dc:creator>
		<pubDate>Sat, 17 Feb 2007 01:58:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.ldscio.org/2007/02/16/customization/#comment-507</guid>
		<description>This is a much more complex issue than the blog allows you to properly address. Volumes have been written on the subject and there are examples to support every possible position of the discussion. One of the fundamental issues in adopting an ERP system is data architecture. Historically, businesses reap the most benefit through greater data integration. The ERP benefit curve is exponential; benefits accrue faster the more business process are within the ERP system. Successful installations require it.

All consulting groups advocate the following generally accepted best business practices:
1) Use an ERP system. Every business consulting group lists this as the single most important best practice.
2) Modify your business processes, when possible, before customizing the ERP system because customizations increase the cost maintenance and upgrades.
3) Modify the ERP intelligently. Each ERP system is different in how you approach customizations. Each method of customization has its advantages and disadvantages.
4) Build your own application, only if it is provides a strategic advantage or if the business function is not provided by the ERP.

****
Four methods exist to provide an ERP customization:
A) Customize delivered code,
B) Clone the delivered code and customize,
C) Create custom code within the application,
D) Create a custom application and interface it with the ERP system.

Each customization must be evaluated for the appropriate method of customization. As you, mention ERP tools make the first three easy to do and manage. Each method has a cost to maintain as well as its benefits. While customizing delivered code is often considered more costly that is NOT necessarily so. The nature of the change is most important. Security, controls, usability, training, support, data integrity and interoperability must be considered in addition to upgradeability.

****
“Cost” seems to be an overriding consideration: This presupposes that custom applications are inherently less costly than customizing an ERP. Evidence suggests that this is not always, mostly or even necessarily the case. Expensive? ERPs cost a lot of money, but complex custom apps generally cost even more to develop. Different costing methods (incremental, full or life cycle, etc. as well as IT operations, business processing and opportunity costs) can generate different results.

Upgrades and system rewrites are costly but generate benefits in architecture, functionality, usability, reliability. ERP systems cost approximately 1,000 hours per module to upgrade every 4 or 5 years INCLUDING customizations. Complex systems can&#039;t be rewritten within that timeframe.

Consider the cost of maintaining tax compliance rules for the federal government, 50 states and 10,000 local tax jurisdictions, not to mention Canada versus applying 7 updates from a vendor at less than 40 hours per update. Want to outsource payroll, expect to pay double or triple the cost of doing it in house.

&lt;em&gt;[Joel: Thanks for your thoughtful comments.]&lt;/em&gt;</description>
		<content:encoded><![CDATA[<p>This is a much more complex issue than the blog allows you to properly address. Volumes have been written on the subject and there are examples to support every possible position of the discussion. One of the fundamental issues in adopting an ERP system is data architecture. Historically, businesses reap the most benefit through greater data integration. The ERP benefit curve is exponential; benefits accrue faster the more business process are within the ERP system. Successful installations require it.</p>
<p>All consulting groups advocate the following generally accepted best business practices:<br />
1) Use an ERP system. Every business consulting group lists this as the single most important best practice.<br />
2) Modify your business processes, when possible, before customizing the ERP system because customizations increase the cost maintenance and upgrades.<br />
3) Modify the ERP intelligently. Each ERP system is different in how you approach customizations. Each method of customization has its advantages and disadvantages.<br />
4) Build your own application, only if it is provides a strategic advantage or if the business function is not provided by the ERP.</p>
<p>****<br />
Four methods exist to provide an ERP customization:<br />
A) Customize delivered code,<br />
B) Clone the delivered code and customize,<br />
C) Create custom code within the application,<br />
D) Create a custom application and interface it with the ERP system.</p>
<p>Each customization must be evaluated for the appropriate method of customization. As you, mention ERP tools make the first three easy to do and manage. Each method has a cost to maintain as well as its benefits. While customizing delivered code is often considered more costly that is NOT necessarily so. The nature of the change is most important. Security, controls, usability, training, support, data integrity and interoperability must be considered in addition to upgradeability.</p>
<p>****<br />
“Cost” seems to be an overriding consideration: This presupposes that custom applications are inherently less costly than customizing an ERP. Evidence suggests that this is not always, mostly or even necessarily the case. Expensive? ERPs cost a lot of money, but complex custom apps generally cost even more to develop. Different costing methods (incremental, full or life cycle, etc. as well as IT operations, business processing and opportunity costs) can generate different results.</p>
<p>Upgrades and system rewrites are costly but generate benefits in architecture, functionality, usability, reliability. ERP systems cost approximately 1,000 hours per module to upgrade every 4 or 5 years INCLUDING customizations. Complex systems can&#8217;t be rewritten within that timeframe.</p>
<p>Consider the cost of maintaining tax compliance rules for the federal government, 50 states and 10,000 local tax jurisdictions, not to mention Canada versus applying 7 updates from a vendor at less than 40 hours per update. Want to outsource payroll, expect to pay double or triple the cost of doing it in house.</p>
<p><em>[Joel: Thanks for your thoughtful comments.]</em></p>
]]></content:encoded>
	</item>
</channel>
</rss>
