Complete Buyers Guide to Business Software

Purpose

A general guide to assist in the process of making a change in Business Software through to Implementation. If you have not purchased software in a while, be aware that pricing may not be what you expect. It also may not be indicative of the quality and features you may decide upon. Contact SSI with any questions you may have.

Decision

There are many reasons to change software. Here a few:

• Software Vendor no longer supports the product or has closed

• Software Vendor only offers patches, no or few additional features

• Business organization has changed or been purchased

• Business volume has changed

• Completely new division is added and must be managed

• Few third party support companies available

• Software does not match majority of your user base

• Too many mods with no documentation

• Internal support is departing/retiring from the company

• Software licensing is always increasing

• Many external packages that are not integrated

• Cumbersome process operations

Needs

What are the needs to be fulfilled:

• Easier ad hoc reporting 

• On premise server can no longer support the demands

• Switching to cloud based

• Lessen custom written programs / queries / spreadsheets / Crystal Reports

• Streamline operations due to employee reduction

• Reduce programmer reliance and expense

• Revamp GL Account #s, Item #s, Vendor and Customer #s

• Meet the needs of a young workforce

• Be ready for expansion

• Be attractive for eventual future sale

Schedule and Attend Demo's

After you have browsed multiple options, it's time to schedule a few demo's. This will be a time consuming process for you and your time but it's important to invest the time up front and ask the hard questions. Failure to do so could cost the company precious time and money.

Here are a list of things you can do to be prepared.

1. Establish a list of requirements by application prior to scheduling demo's.

2. Determine Stake Holders

3. Choose a Project Manager and their backup

4. Assign a representative that is the SME for an area/application

5. Create lists by area/application/scenario and have others review and polish in Excel

6. Rate each module/feature into 3 sections:

   1. Must haves

   2. Nice to have

   3. Not needed

7. Give the list to the prospective vendors

8. Go over scenarios with vendors to make certain they understand. Sample documents with notation is also a great way to have the process replicated in the demo.

9. Schedule the demo with the staff that deals with the scenarios

10. Rate the feature:

    1. Meets needs completely

    2. Meets needs with few mods

    3. Meets needs with many mods

    4. Does not meet needs

Selection

Choosing the top vendor(s). Consider these facets:

• Is there Buy In from the stakeholders?

• How close does the software meet your needs, without mods?

• Industry specialty match: 80% is minimum
  

• Age of business

• Knowledge of software

• Vendor/Local Support: rates, access, experience

• Comfort Level: How do you feel about working with them?

Gap Analysis

Detailed review of the software to determine how closely it fits your organization. Think of this as a deep dive into scenario. Typically the users are present during each test so that they can validate the results. Flag processes that require further review or modification

A quality Gap analysis ensures that the power users can accept the software operation so you can move forward with the project.

Modifications     

Clear specifications of changes and documentation

•  Samples of documents that are marked up with clear notes

•  Screen captures that are marked up (Paint 3D or Snagit)

•  Describe flow of screens and options

•  Don’t forget to qualify security requirements of data and access

•  Get consensus on everything before handing it over

•  Review results from vendor

File Migration     

File layout and hard coding of new file codes

•  Mapping of fields, old to new

•  Rules for converting old data to new data

•  Will Item Class, et al, be converted to take advantage of new coding?

• Can “extension files” be merged into existing new file fields?

• Is it possible to have the “extension files” added as fields?

• Create an automated routine to regenerate file migration and time it 

Beta Testing      

Testing to compare transactions and how they flow

•  Run reports on both systems to see if they match prior to testing

•  Evaluate access for user type

•  Run scenarios from “Gap Analysis”

•  Prove GL postings

•  Validate report totals total properly

•  Question staff usability 

Test Cut Over    

Migrate all data “hands off”

•  Run reports on both systems to see if they match prior to testing

•  Position support personnel

•  Have each user replicate their work for a period (day, week, etc.)

•  Validate the accuracy and assist with questions

•  Guide operations and tips with each user

Adjustment

What needs attention before Go Live?

•  Project Manager determines if changes made now, later, or not at all

•  Outline changes in time and expense

•  Go Live or another Test Cutover?

Go Live - Show Time!

•  Run reports on both systems to see if they match prior to Going Live

•  Position support personnel

•  Supply lunch for everyone

Review

Overall review about a week or month later

•  Evaluate how things went

•  Determine areas that need attention

•  If required: Assign resources to estimate time needed

Documentation  

Custom Mods and Applications

•  Determine format of Documentation

•  Screen capture with clear notes

•  Have users handle or assist in each scenario

•  Video, Print, PDF online, or Wiki are all options

•  Easy access to everyone