» Agilutions Project Methodology
» Taking Communications to the Next Level Presentation
» Coding Schema for Prodcuts & Price Codes
» SQL Server Best Practices

The Right Message, at the Right Time – Taking Communications To The Next Level
The age old saying in real-estate is, “location, location, location”, and for users of netFORUM, the key to success with their customers is, “communication, communication, communication.” Join us for this session, where we take a look at common scenarios where you can really use netFORUM’s eMarketing templates to improve your communications. You’ll walk away with practical best practices, configuration tips and ways to enhance and extend your communications strategy.

» Access PowerPoint Presentation (.PPT)
» How to Create a SuperView (.DOC)

The first phase of a netFORUM implementation is the System Requirements Analysis (SRA). During the SRA, Agilutions will work closely with the Client to define the business requirements and functionality for implementation in the netFORUM system. Agilutions will document each process as well as custom reporting and querying requirements, and required integrations to third-party applications.

Project Preparation
In preparation for the initial Requirements Meetings, the Client will be asked to gather various documents including reports, new member applications, and renewal and registration forms. Agilutions will begin by studying the Client's Website, the RFP, and other relevant material provided by the Client prior to the start of the project.

Project Kickoff
A Project Kickoff meeting is used to mark the start of the netFORUM Project. The meeting will identify the Implementation Team including Agilutions, Client Management, and the Client's staff identified as the Process Owners for the processes to be implemented during the project. The meeting will cover the overall goals and objectives of the project, identify roles and responsibilities for each of the members of the Implementation Team, and present a proposed Implementation Timeline.

Process Interviews
Agilutions will conduct a series of Process Interviews where Agilutions will meet with each Process Owner to discuss the specific business requirements for the process(s) the Process Owner represents. The interviews will focus on the requirements of the process and should also cover dependencies, redundancies, and commonalities across other processes.

SRA Document
Following the Process Interviews Agilutions will draft an SRA document which identifies the requirements gathered during the Process Interviews. Each requirement will include proposed solutions to meet the requirements in netFORUM. If more than one solution is viable for a given requirement Agilutions will work with the Client to evaluate and choose the one which best fits the Client's objectives.

Client Review and Feedback
Once the SRA draft is complete, the Implementation Team will meet to review the documents. Feedback from the Client will be used to refine the SRA document. This process may occur multiple times to ensure clarity of requirements.

Finalization of Scope and Timeline
To conclude the SRA Phase, the Client will choose which solutions to implement in netFORUM. The Implementation Team will review the scope of work and develop an estimated timeline for implementation that takes into account any blackout dates or special considerations. With the Client signoff on the SRA Phase scope and timeline, the project moves into the Implementation Phase. The SRA document serves as the blueprint for the implementation.

The Implementation Phase

Agilutions uses an iterative approach to software development. The implementation timeline is divided into 3 week iterations. The goal of an iteration is to deliver true business functionality to the Client at the end of the iteration. Each iteration is treated as its own mini project with scope definition, requirements gathering, data conversion, implementation, deployment, demo, and testing. Using iterations allows the Client to see the completed functionality sooner and gives the Client the opportunity to provide necessary feedback to ensure that the functionality is meeting expectations.

Scope Definition
At the beginning of each iteration Agilutions will meet with the Client to evaluate priorities and dependencies to determine what is the set of requirements and functionality to be implemented within the iteration.

Requirements Gathering
Agilutions may need to meet with Process Owners to get specific details about the requirements.

Data Conversion
Any data that supports the requirements will be identified and converted. Regular data conversions are conducted using fresh data from the legacy systems to ensure that the data in the development environment is both current and reflects any "data scrubbing" that may occur as part of the project. The Client knows its data best, so the Client's Process Owners will review the converted data to determine its accuracy and completeness.

Implementation
netFORUM Configuration and Customization is the process of implementing netFORUM to look, feel, and act like the Client's system. netFORUM Configuration is completed using the netFORUM Development Toolkit. netFORUM Customization is completed using code developed in C# and SQL to implement client specific business processes and data fields. Typical system customizations include the addition of extender fields for additional data storage, dues calculations implemented in C# and integrated into the system, certification program business rules and custom eWeb screens and processes.

Deployment, Demo, Training, and Testing
At the end of an iteration, Agilutions will run a fresh data conversion and deploy the implemented requirements and functionality into the Client's environment. Agilutions will demo the new functionality and provide any familiarity training necessary for the Client to test the functionality. The Client will then test the new functionality.

The Go-Live Phase

Once all implementation iterations are complete and all major functionality has been tested, the new netFORUM System is ready to go through the final steps to Go-Live.

Staff Training and Finalize SOP Documentation
Agilutions will train staff based on the functional areas of the system. The training will be conducted using the newly implemented netFORUM system and will contain current data that the users will be familiar with. The training should build upon previous familiarization and functionality training conducted during each iteration. After the training is the best time for the Process Owners to finalize their SOPs.

Mock Go-Live
When all components of the project are complete (Implementation, SOPs, training) a Mock Go-Live will be conducted using the netFORUM System. In a Mock Go-Live staff is asked to save a day's worth of work and processes to be redone in the netFORUM System. Staff will then compare the outcome of the day's work in the legacy systems with the outcome in the netFORUM System. The Mock Go-Live will also test the SOPs and identify whether staff is prepared to go live on the netFORUM System.

Sign Off
Prior to System Go-Live, Agilutions requires IMCA to review the system setup and configuration for final sign-off. At this point, all custom development and business rules identified for implementation in the system should be complete and tested including dues renewal setups, customizations and custom reports, as well as interim data conversions.

System Go-Live
The final data conversion is the last delivery item for system go-live and the launch of netFORUM in IMCA's production environment. Agilutions will be on-site during System Go-Live to answer how-to questions and provide support during this vital stage.

| top

Coding Schema for Products & Price Codes
Financial transactions in netForum are, for the most part, the result of purchasing something already set up in the software: membership, products, event registrations, subscriptions etc. Although setting up all of these different types of items to purchase in netForum may take on slightly different steps, there are a few commonalities throughout the software. First of all, each item or "product" needs to have a unique product code assigned to it. Secondly, the price codes, which differentiates which type of customers gets charged what price and are associated to the main product, need to be setup.

• Assigning product codes: first, and most important, assign product codes that make sense to you and that are unique (no other product has the code assigned to it). Keep in mind that the product code can be used for reporting and is a searchable field so don't create something too complex that you will not understand the next time you need to create or search for a product in the same module. Product code field length can vary throughout the modules in netForum so investigate before finalizing a schema. Also, it is very common that product code schemas will vary from module to module. Below are a few suggestions:
  
  
  • Inventory product codes - ISBN number or other unique internal inventory code. Alpha code containing part of the title, for example, a book called "Managing Your Employees" could have a code of "ManageYourEmployees". Or maybe a schema which builds in logic to the code is created, for example, the first 4 digits are the year published, the next 5 are the beginning of the title, and the last 6 are a broad subject category.
    
    
  • Event product codes - event product codes often start with the year it is being held in and then assigned a short, logical description after that. For example, the event titled "2008 California Conference" could have a code of "2008Calif".
    
    
  • Membership packages product codes - again, use something that makes sense to you. Examples could be for a New Membership Package "NewMemPkg", or for a Renewal Membership Package "RenewMemPkg".
    
    
  • Subscriptions - the trade magazines that your company publishes and sells subscriptions for are often known by a single, common name which can be a useful product code. For example, "The Journal of Accounting and Finance" is often referred to as the "Journal" so use that.
    
    
• Assigning price codes: Price codes are setup under each product in netForum to place parameters on who gets charged what price for your goods and services. Price codes often are displayed on the invoice and are also used in reporting and searching for data just like the product codes. It is suggested that price codes always start with the product code and then add on short, sensible indicators after that differentiating the pricing parameters. In the below example, the codes for the "2008 California Conference" could be as follows:
  
  
  • Product code = "2008Calif" (just like above)
  • Pricing codes =
    • 2008CalifMEB = 2008 California Conference Member Early Bird Rate
    • 2008CalifNEB = 2008 California Conference Nonmember Early Bird Rate
    • 2008CalifMS = 2008 California Conference Member Standard Rate

Naming Schema for Batches
There are numerous ways to assign batch names, but most likely, you will have something in the description differentiating the type of transaction, for example, AMEX, VISA/MC, invoice, check, etc. The screen below displays the baseline batch creation screen where you can notice many fields such as fiscal year, period, batch date etc. Because you have all of these fields already available to you for reporting, sorting and querying it is suggested that in the "batch name" field, you begin with a the differentiating transaction type and then include the date (or at least the month and year). Examples for your common daily batches for February 1st, 2008 could be:

AMEX 20080201
VISA 20080201
Invoice 20080201
Checks 20080201

| top

• Always apply service packs to a new SQL Server installation. When applying updates, test them before applying them to a production instance of netForum.
  
  
• Always change the 'sa' password to a secure password. The 'sa' password is null by default. Run SQL Server services under:
  
  
  • Domain user that is not a Windows admin
  • Local user that is not a Windows admin
  • Use the principle of least priviledge and work from there
    
    
• You can use one of the following types of accounts for services; however, the risk increases exponentially for each choice:
  
  
• Network Service Account
• Local System Account
• Location user that is a Windows admin
• Domain user that is a Windows admin
• Never expose a SQL Server to the public Internet. Only enable TCP/IP as a supported network protocol. If other network protocols are needed, only enable the protocols required.
  
• Disable xp_cmdshell unless it is absolutely needed.
  
  
• Turn login audits off but login audit fails on if you do not store highly sensitive data.
  
  
• Logging logins increases the size of the event log and impacts server performance which can
  result in your log file growing too large for your SQL Server c: drive. Make sure the size of the event log will never grow beyond the size of the c: drive.
  
  
• For highly available installations, if possible, place the temp DB on a separate, distinct channel (another full set of logical drives using a RAID 0 or 5 hardware configuration)
  on your SQL server box. You will see performance on your SQL improve significantly and remove SQL Server as a bottleneck.
  
  
• Nightly database backup job
  
  
• Transaction log backups every 5-60 minutes depending on your disaster recovery tolerance. For high disaster recovery tolerate simple backup is acceptable though generally discouraged.
  
  
• All backup job files should be saved to a location on the network other than the SQL server for fault tolerance.
  
  
• The files may be saved to a network location so long as the files are backed up either to some other media or other network location nightly.
  
  
• Run md_database_tune at monthly for small to medium sized databases. Larger databases (20+ GB) should run md_database_tune at least weekly. Larger databases should run md_reindex_all stored proc after I run md_database_tune. md_database_tune runs the reindex process in the incorrect order. This should never be run during normal business hours.
  
  
• Truncate the following tables periodically (monthly):
• fw_error_log
• md_page_access
  
  
• As a general rule, I keep one month of entries for each entity.
  
  
• Custom tables that manage batch jobs should be truncated when possible to improve performance.
  
  
• In test and development databases, when restoring data from backup of live, create a stored proc that updates the email address to use an invalid email address. Update the password login to something all developers/testers can remember (i.e.: 12345, <company acronym> or testpwd)

  | top