May 25, 2019
Working With Software Companies
Share This Post
In the majority of cases, individuals and companies buy software and start using it. Typically there may be some initial training, or the company sends a person to class, and that is about the extent of communications - unless there is a problem. You also find cases where the initial product stakeholder goes off to a different position, either in or out of the company, and the connection to the software company is lost. As a consultant, to many companies have experienced this, amd I find that I have to do a great deal of investigative work to help companies effectively use the software they already have.
Have You Ever Lived Through This?
One day you come to work and your ERP application screen looks different. You start to mouse around, trying to find what you were used to looking at. You ask others what happened, and are told that they (whoever they are) did an Upgrade over the weekend, and now we are running on the new version. It seemed like the assumption was that the new version would look the same as the old version but just have more features or capabilities or be more secure. No real mention of screen, menu, navigation, terminology changes.
What Might Be A Better Approach?
I have found that, the closer a company keeps in touch with a software vendor, the more likely the software will be more fully used. I have also found that, if you volunteer to be a tester or on a review committee, the more likely changes that you need will happen (squeaky wheel gets attention). Another benefit of maintaining good communications is that, when you have a problem, you generally have someone higher in the tech support food chain to call.
What Does This Mean?
The Employees Perspective:
You start working in a company and are given a desk with a computer. Someone in HR or IT gives you an email address, User ID, and Password ( and at best tells you to change the password the first time you log in). You log in and find one of two things: 1) an almost empty screen, or 2) a screen with a bunch of icons - only some of which you recognize. In the first case you start clicking around to see if you can find something you recognize so that you can start working. In the second case, you click on something you recognize and start doing some work.
A new employee may be given the company handbook which ideally explains what software is available to use and what resources are available in case you have questions. Another approach is the Partner or Buddy system where another employee is assigned to you to show you the ropes. The result from both of these is typically not that good: 1) the manual is typically out of date, and 2) the Buddy only has time to show you some of the capabilities - after all - weren't you hired to do this job.
A Possible Solution: What if the main software stakeholder started off with putting together fairly short videos that new employees would view, and they were required to watch. You could then use the Buddy system to ask the newbe if they had any questions, and to possibly demonstrate what they learned. After the employee has used the software for a week or so, the Buddy would then ask how they are doing and if they had questions. This proactive approach has proven to be very effective for both the new employee and the Buddy. In the most ideal case, the Buddy would refer the new employee to other videos and then go through the same review process.
Company Financial Benefits:
Should Software Be Viewed As "Buy it and use it"
By now, you should have answered this question with a big NO. Companies who function this way are generally not taking full advantage of what they have purchased, and could be losing money. Software should be viewed as a longer-term investment that has operational cost associated with it, including: Upgrades, new versions, single point and group training, stakeholder management, and more.
Worst Case: I was called in as a consultant to a company who had upgraded their ERP software, and were having issues getting the software company to: 1) integrate the old data into the new system, and 2) train the staff on how to use the software - the way it used to be. There were a couple of reality checks here to start with: 1) the database structure and naming of the new product was different from the old, and this required re-mapping all of the old data so that it could be imported into the new, ad 2) the new software functioned enough differently from the old, that the entire accounting staff needed to be re-trained. This entire change process took almost a month, and the person responsible for the decision to change was fired. NOTE: That person said that the software salesperson had assured them that there were no issues, and had put this in an email. The sales person was fired, and the software company was sued. PS: I was still paid.
Best Case: I was called into a company that was going to a new manufacturing software platform and wanted an extra set of independent eyes to look at the project and product. The stakeholder had put together Requirements and Specification documentation, and had obviously done his homework, including using Gartner and Forrester reports. I did notice that there were a couple of holes: 1) only training for one person, 2) minimal user documents, 3) no online training available, and 4) a set number of support hours until the company had to start paying.
In this case I recommended revising the contract to include: 1) training 2 people initially, and 2 more within a 3 month period, 2) to provide much more user documentation, especially online and/or video, and 3) doubling the free minimum tech support hours. I worked with the software company to show them how putting video training could help them sell more product, and a fairly low cost. I also introduced them to Adobe RoboHelp which could help both clients and the inhouse support staff.
Share This Post