Having gone through a similar siuation at my last place of employment, I would
recommend you keep a log separately from your production environment and
develop a quick form that has something that states it is for "change control".
Both SAS70 and SOX auditors look for this. What is on it should be a summary of
a change, requestor/approver of the change, and a rollback procedure. Create a
number to track each change control sheet. On a separate document, log the
change control sheet with a date and time it moved/rolled back. On your change
control sheet make simple notation you understand as this is wide open as it is
"technical, theoretical, or 'business knowledge' " therefore out of scope on
most audit routines. The scope of most audits is to confirm a process for
changing applications and document who requested/approved this change.
The only important things from an audit perspective are:
1. A process is in place that marks connotates what changes are being made.
2. A log in that process keeps track of when a change was made.
Beyond that refer to next pay grade up the line.
John
P.S.----They may gig you on the test part even if there are "extenuating
circumstances such as licensure" that preclude you from developing a test
environment.
----- Original Message ----
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Friday, February 9, 2007 8:14:10 AM
Subject: [EDI-L] Change Request documentation/control for Gentran NT
Hello group,
I am trying to get a handle on tracking production change requests. Our
company has a one person EDI department, I am sure many others out there
can relate. Being a one person shop, I have had the liberty of changing
things any way I want and tracking (or not tracking) the changes any way I
want. We were a privately held company up until February 1st and as such,
no audits were required. Now that we are public, I am expecting that we
will have an audit and my current way of tracking will never fly. We have
Gentran on an NT server. We do not have a test system. For 10 years now,
we haven't had too many problems with "production control", but, I would
like to organize this a little more and document changes within some type
of structure. Gentran on the NT server does not enforce any production
change control or version control. You have to create your own. My goals
are to create a change request system for documentation purposes and to
find a way to limit the risk of production maps and other scripts from
being overwritten by development efforts. I am splitting my personality
and pretending that I now have a multi-person EDI support team. One
person is the Manager and the other person is the developer. My other
reason for doing this is in the hope that I may actually get another
person to back up the EDI efforts, and need to have procedures in place
for that person to follow.
The first thing I want to tackle is Map control. One thing I have done
over the years is to put a version number in my map name. When I do
update a map, I rename it to a higher version. I have my Maps directory
subdivided into four categories, Dev, Prior Versions, Production, and
Test. I am thinking that I could put a "read-only" protection on the
Production folder and "read-only" on the TransObj for all users other than
my server main, overall user. Then, the only way you could move a map
into the Production folder or register it in production would be if you
have access and can sign on to the server. Would that work? Each
developer will have their own TEST trading partner. Any testing is to be
done only with this partner. They would change the Map Summary
Description to be Test_whatever for the TEST tp to find it when it is
compiled and registered, and so the real trading partner doesn't find it.
Developers, when finished testing, would put their map in the Test folder
and submit a request to the manager to do a quality check and place the
map into production. Developers would keep their development version on
the server as opposed to the client in order for the whole EDI team to be
able to see which maps are being worked on. Can't see this if the maps
are on the client.
Ok, all that being said, any one out there already do this? Do you have
some suggestions for me?
Any feedback would be greatly appreciated, thanks,
Cindy
[Non-text portions of this message have been removed]
<!--
#ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;
}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;
}
#ygrp-vitnav{
padding-top:10px;
font-family:Verdana;
font-size:77%;
margin:0;
}
#ygrp-vitnav a{
padding:0 1px;
}
#ygrp-actbar{
clear:both;
margin:25px 0;
white-space:nowrap;
color:#666;
text-align:right;
}
#ygrp-actbar .left{
float:left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;
font-size:77%;
padding:15px 0;
}
#ygrp-ft{
font-family:verdana;
font-size:77%;
border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;
}
#ygrp-vital{
background-color:#e0ecee;
margin-bottom:20px;
padding:2px 0 8px 8px;
}
#ygrp-vital #vithd{
font-size:77%;
font-family:Verdana;
font-weight:bold;
color:#333;
text-transform:uppercase;
}
#ygrp-vital ul{
padding:0;
margin:2px 0;
}
#ygrp-vital ul li{
list-style-type:none;
clear:both;
border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;
color:#ff7900;
float:right;
width:2em;
text-align:right;
padding-right:.5em;
}
#ygrp-vital ul li .cat{
font-weight:bold;
}
#ygrp-vital a {
text-decoration:none;
}
#ygrp-vital a:hover{
text-decoration:underline;
}
#ygrp-sponsor #hd{
color:#999;
font-size:77%;
}
#ygrp-sponsor #ov{
padding:6px 13px;
background-color:#e0ecee;
margin-bottom:20px;
}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;
margin:0;
}
#ygrp-sponsor #ov li{
list-style-type:square;
padding:6px 0;
font-size:77%;
}
#ygrp-sponsor #ov li a{
text-decoration:none;
font-size:130%;
}
#ygrp-sponsor #nc {
background-color:#eee;
margin-bottom:20px;
padding:0 8px;
}
#ygrp-sponsor .ad{
padding:8px 0;
}
#ygrp-sponsor .ad #hd1{
font-family:Arial;
font-weight:bold;
color:#628c2a;
font-size:100%;
line-height:122%;
}
#ygrp-sponsor .ad a{
text-decoration:none;
}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;
}
#ygrp-sponsor .ad p{
margin:0;
}
o {font-size:0;}
.MsoNormal {
margin:0 0 0 0;
}
#ygrp-text tt{
font-size:120%;
}
blockquote{margin:0 0 0 4px;}
.replbq {margin:4;}
-->
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
[Non-text portions of this message have been removed]
...
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Job postings are welcome, but for job postings or requests for work: <JOBS> IS
REQUIRED in the subject line as a prefix.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/EDI-L/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
