Skip to content

Post implementation support: cost, communication and response time

January 29, 2013

There is a wide array of offers for the post-implementation process. It is important to verify the details of each one of them. Both publishers and consulting firms offer on going support and training and the plans go from a maintenance plan paid yearly to charges by call or by case; there are also charges by the hour as well as purchase of blocks of consulting time. The most important things to check for this are the response time as well as the quality of the service. Talking to references from current users can bring a good feeling on this topic.

Advertisements

To pilot or not to pilot?

January 28, 2013

One of the important definitions before an implementation project is if a piloting test should be performed or not. Some of the considerations for this decision are:

–          A pilot test will provide a certain way to double check the results of the different processes within the company, from the legacy system to the new system

–          A pilot test will in fact double the workload for end users, as the tasks will have to be performed once in the legacy system and another time in the new system

–          The verification process of the results can be a very time consuming process

–          If there are substantial changes to be done on the structure of the data (such as changes on chart of accounts or structure of key elements such as customer, item and vendor keys, for example), there will be an added layer of complexity in order to define cross reference data for the verification process

It has been our experience that there is a different approach that can be as productive as a pilot testing but that can reduce the amount of effort to be performed. We usually request for our users to define a list of scenarios that are produced in their daily operations (especially the crucial, complex type of scenarios), and to create a documentation set for each one of them.

Once this is defined, we use our sandbox database to create all required elements to process such scenarios, one by one. The documentation provided should contain reports that indicate what the results of the specific scenario should be, and this can be used to compare the output from the new system. These documents are also a good basis for sign off on different steps of the project.

The internal procedures: an important support to the success of any automation

January 25, 2013

 I know I’ve mentioned this in other paragraphs, but this is a vital part of a successful implementation. One common expectation we find with many of our prospects/customers is that as soon as the new system is in place, all their operational and process pains will go away forever. This expectation is as realistic as thinking that placing a child in an excellent school will create an over-performer regardless of the guidance provided at home.

When a company regularly functions in a chaotic environment, with either poor procedures or even worse, no procedures at all, this chaotic environment will usually lead any kind of effort in that direction, including the implementation of a software solution.  Corporations that provide us with clear operational guidelines will normally have an easier path through the planning, testing and go live phases of an application implementation project.

An important point to note here is that the procedures are not always written somewhere, as we would all expect. Actually, we have met corporations with clear processing guidelines that either don’t have any written manuals or for who the written manuals are old and outdated. But through good leadership and clear objectives they have managed to organize themselves in such way that they can provide a clear set of steps on how things get accomplished internally, the results of these steps (usually in a measurable way) and in their interaction with external players.

Therefore, as a conclusion, we always recommend the key players in any of our prospect companies to take a good look into the organization itself and if necessary, to perform some house cleaning before bringing the additional layer of a new software solution.

The Publisher

January 24, 2013

There are many reasons to research the publisher that writes the programs that are included in your software. Some parameters are:

–          History and size of publisher: it is important to do business with a well established publisher, as this kind of purchases are used within a company for at least 5 years (our customers’ average use is 10 years). The bigger the publisher is, the more resources it has to dedicate to the development of new features and keep up with the changes in the computer environment.

–          Scalability: many publishers offer different solutions for different size companies in different industries. It is important to make as sure as possible that the publisher can offer options based on the growth of your company or an eventual downsizing.

–          During these transitions, an established publisher usually offers very attractive advantages for current customers to use other options. Therefore, for example, if you use an ERP and later on you decide to bring your payroll in house, you can get very competitive pricing additionally to a product that easily interfaces with your current ERP.

–          Level of customer service: many of the larger firms require a yearly maintenance fee in order to support the development of new features and upgrades. This fee usually includes some kind of customer support directly provided by the publisher. It is important to research what the support service is and the quality of the service, in order to make sure that your publisher is always a resource for problem resolution.

Accountability: Commissions, Deliverables and Publishers

January 22, 2013

There are 3 main components for a successful ERP implementation: (a) the software needs to be able to meet the customer’s requirements and procedures; (b) the pre-sale needs analysis process needs to be done accurately in order to ensure that the application and the requirements are aligned and (c) the post-sale implementation and support team need to be knowledgeable on the customer’s processes and available in the long run to support the installation.

Obviously, a major part of a successful implementation is to have scoped the customer’s requirements correctly. Unfortunately, sometimes this is not the case, and it has been our experience that many of these misjudgments are due to these factors: (a) the sales rep is not going to be part of the implementation efforts (or part of the consulting team) and (b) the sales rep is paid on commissions basis. A typical consequence is that the customer is probably going to be told that the requirements can be met by the application, leaving the customer without a way to verify this due to lack of knowledge of the application itself. We recommend thoroughly verifying what the future role of the sales rep is going to be during the life of the project and future support. Puy him on the hook for delivery, so to speak.

In addition to sales through reps publishers are dedicated to developing their applications and rely solely on their distribution channel for sales. However, there are many other publishers that have an internal sales force that actually competes with the distribution channel (or there is no distribution channel at all). Nothing wrong with this. However, we highly recommend for a prospect to verify which is the case for the applications that are being presented. In thoses cases where the publisher also has a direct sales force, this can bring very attractive discounts on the purchase of the application. It is also important to review the availability of local support. As much as many firms claim that these kind of work can always be performed remotely, it is our experience that being able to be on site, seeing the processes, meeting the people and reviewing the IT environment is priceless and critical for meeting the targeted timeframes for the project. Also, having a professional available to visit your company within a few hours can reduce the downtime in case of an emergency (natural disaster, server crashes, personnel illness or availability, etc.).

Reporting, alerts and dashboards / KPIs (Key Performance Indicators)

January 17, 2013

It is important to review the applications reporting tools to ensure your data is properly presented. The key to having accurate reports is having the correct data in your database. When  tools are cumbersome and difficult for and end user or require special programming or knowledge of specialty tools, you may find yourself depending on third parties to develop or modify your reports, based on your needs.

Dashboards and KPIs are a visual representation of the data contained in the software solution. There are a number of applications that can extract information and produce charts that quickly convey meaning. This is one of the latest trends of information generation and it is widely accepted because of ease of use. Dashboards should update real time basis as the underlying data changes. This is imperative as many key business decisions are made based on the information.

And touching base on the concept of real time data, another great tool in many software applications are alerts based on specific conditions. The alert can be an email or a report indicating that something just happened that requires attention. There are many examples on why this is important for your business: entering orders for customers that have overdue balances, late receipts from vendors in the inventory, entries to closed projects or cost centers, etc. All of these conditions have a cost to the company and should be resolved in a timely manner.

Business processes and software integration

January 4, 2013

In the mid market range of software solutions, it is hard to find an out of the box application that will take care of each and every business need. These gaps usually open the door to additional solutions that have an interface with the central application (usually the ERP).

These applications are usually developed by third parties, and it is important to investigate who these third parties are and what their roles are in relation to the main software publisher: are they certified by the publisher? are they an established firm or a solo developer that may find a job later and no longer be available to do required changes to the application? is the application developed using tools that are widely used or is it developed in a proprietary way?

Software updates and upgrades in many cases produce changes that the peripheral solutions will not accommodate. It is important to make sure that the developer and supporter of your third party solutions will be able to respond to such changes.