<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.7.3" -->
<rss version="2.0">
	<channel>
		<title>Change Control and PeopleSoft Development</title>
		<description>Comments for Change Control and PeopleSoft Development at http://www.erpassociates.com , comment 1 to 5 out of 5 comments</description>
		<link>http://www.erpassociates.com</link>
		<lastBuildDate>Tue, 07 Feb 2012 08:51:02 +0100</lastBuildDate>
        <generator>FeedCreator 1.7.3</generator>
		<item>
			<title>Introducing a revolutionary version control product</title>
			<link>http://www.erpassociates.com/peoplesoft-corner-weblog/sarbanes-oxley/change-control-and-peoplesoft-development.html#comment-1340</link>
			<description>mcAMDOIS is proud to introduce the Change Management and Version Control for PeopleSoft Functional Configuration Data (i.e., your SETID, Business Unit setup data). From our PeopleSoft experience, we have seen instances where the functional administrator had inadvertently changed the SETID data directly in the production environment, causing severe impact to the business. Any uncontrolled change to the functional configuration will severely impact the business. Any changes to the setup data MUST be controlled and follow through the standard Software Development Lifecyle process, which will make your PeopleSoft application 100% regulatory compliance. 

In our perception, a Change Management and Version Control application for PeopleSoft cannot be complete, if it does not provide version control for the functional configuration or the business rules data. 

There are NO change management software currently available in the market to address this imperative business requirement. mcAMDOIS is the first and only vendor to incorporate such a vital feature in its CAPI product.

Using CAPI, you can now control the changes and maintain multiple version of your application designer objects, file server and functional configuration data, all in the same change request.

Click here to learn more about Version Control of your Functional Configuration Data.
 - Musthafa</description>
			<pubDate>Thu, 02 Jul 2009 10:53:16 +0100</pubDate>
		</item>
		<item>
			<title>...</title>
			<link>http://www.erpassociates.com/peoplesoft-corner-weblog/sarbanes-oxley/change-control-and-peoplesoft-development.html#comment-1030</link>
			<description>I am a consultant specializing in PeopleSoft administration, so I do lot of migrations for customers.  I was recently on a project where Phire Architect was used and it worked great.  I didn't have any prior knowledge or formal training with Phire, but because it was just another application built on PeopleTools, I was able to figure everthing out.  The best part is that I was able to perform migrations of App Designer projects and external files using one-click and it worked evertytime.  Great product. - Roy Brothers</description>
			<pubDate>Thu, 08 May 2008 15:10:45 +0100</pubDate>
		</item>
		<item>
			<title>Consultant</title>
			<link>http://www.erpassociates.com/peoplesoft-corner-weblog/sarbanes-oxley/change-control-and-peoplesoft-development.html#comment-974</link>
			<description>The solution that makes most sense for PeopleSoft is one that is built using PeopleTools.  Phire Architect is a product developed by Phire (www.phire-soft.com) that has full Issues Tracking and Change Request management.  It also has features for PeopleTools object version control as well as automated migrations of App Designer projects and external files.  Because this product is built on PeopleTools, it looks and feels like other PeopleSoft apps and does not require any new infrastructure.  Customers usually deploy Phire Architect in few weeks instead of months. - John Han</description>
			<pubDate>Fri, 22 Feb 2008 17:41:46 +0100</pubDate>
		</item>
		<item>
			<title>Comment from Chris Heller</title>
			<link>http://www.erpassociates.com/peoplesoft-corner-weblog/sarbanes-oxley/change-control-and-peoplesoft-development.html#comment-491</link>
			<description>The internal source code management for application source code in PeopleSoft never used a formal versioning system. It was handled through database backups. &lt;br /&gt;
&lt;br /&gt;
Part of this was due to the fact that there was also a lot of test data that went with the development process. Versioning of PeopleTools objects wouldn't be enough to solve this (in fact, I have half written blog entry about how we deal with versioning application data for our development work within Grey Sparling)&lt;br /&gt;
&lt;br /&gt;
Also, during development of a PeopleSoft application release , we would typically roll out new versions of PeopleTools every two weeks. The number of people impacted varied by release cycles, but somewhere in the order of 500-2000 folks. The next time that you're doing a PeopleTools upgrade, imagine doing it every two weeks :-)&lt;br /&gt;
&lt;br /&gt;
As you can imagine, this presented some interesting logistical challenges, so PeopleSoft had a dedicated team to handling environment management. Lots of people, process, and hardware involved in that. &lt;br /&gt;
&lt;br /&gt;
Having regular backups of entire environments might not work for everyone, but it (mostly) worked for PeopleSoft. &lt;br /&gt;
&lt;br /&gt;
I think that it's safe to say though that whatever you do around version control/change management,  that you need to have everyone buy in (or be forced in) to the process. Without that, then nothing is going to be successful. &lt;br /&gt;
 - Chris Heller</description>
			<pubDate>Wed, 05 Apr 2006 13:44:34 +0100</pubDate>
		</item>
		<item>
			<title>Comment from David Vandiver</title>
			<link>http://www.erpassociates.com/peoplesoft-corner-weblog/sarbanes-oxley/change-control-and-peoplesoft-development.html#comment-493</link>
			<description>The Univ of Houston started using Quest's Stat product, and I am now a Stat fan.  The product has its quirks, but most of the quirks are going to happen when interfacing with PeopleSoft.  I am now able to concentrate on coding and less on migration as a developer.  Plus, the joy of moving my dev code to test and putting the project in someone else's worklist (and not mine) is worth the learning curve of a new product (Stat).&lt;br /&gt;
&lt;br /&gt;
If a site's auditors really want an audit trail, then buying Stat from Quest is the obvious choice IMHO.&lt;br /&gt;
&lt;br /&gt;
If you are simply wanting to audit and have a documentation trail, and not pay alot, I guess you'd be stuck with exporting projects to a file.  I wonder if someone could create something in Netbeans to do the exporting.  I've seen what Stat can do and I would not want to reinvent the wheel that Stat has already created.&lt;br /&gt;
&lt;br /&gt;
My opinion is to buy Stat.  You not only get the version control and documentation trail, but you get worklists and workflow. - David Vandiver</description>
			<pubDate>Wed, 05 Apr 2006 10:04:19 +0100</pubDate>
		</item>
	</channel>
</rss>

