Business Computing – The Cost of Mis-information

Concept photo for tech support hotline.My CRM server told me that there were Windows Updates to be installed. I typed “Windows Update” in the search, clicked the appropriate item, and clicked “Install now.”

The install failed with code 80246013. The “click here for more information” took me nowhere. So I called tech support, also known as Google.

Someone else had the same problem. There were two solutions proposed:

Solution 1 – Generic troubleshooting

The first techie who replied to the question suggested (1) disable antivirus, and (2) do a clean boot and troubleshoot. These are not bad suggestions, particularly when the error code is not documented anywhere. It would have taken perhaps thirty minutes to an hour to do this. We could also have looked at the Windows Event Viewer’s Application Log. We could have rebooted the server, logged in as local admin, and retried the installation.

Rather than spend this time, I went to option 2.

Solution 2 – Restart the Windows Update Service

The next solution connected this error with the Windows Update service. It said, simply, that if the service is not started, you’ll get this error. Press Windows Key + R, type services.msc, and check Background Intelligent Transfer service and Windows Update service. If they are stopped, start them.

Total time: 2 minutes.

Problem: solved.

Bad advice costs money. My $0.02.


Selecting ERP Software – Best Practices – Defining Needs

Book Title on the Spine - Erp Solutions. Book Title on the Spine - Erp Solutions. Closeup View. Stack of Books. Erp Solutions - Book Title. Erp Solutions Concept on Book Title. Blurred 3D Rendering.At the end of the day, needs definition or needs analysis should control your selection of ERP software.

In the last post, I discussed why IT requirements should not be at the top of your needs definition. In this post, I’ll start the discussion of how to define needs. Let’s take a look at two typical requirements (needs) as an example. The specific needs aren’t that important, so if these don’t apply in your situation, keep reading; we’ll get to the point pretty quickly. Here are the two typical needs:

  • Recurring payables capability. The system allows us to set up certain bills that we get every month like the mortgage or the pest control service bill and enters them to be paid so we don’t have to key them.
  • Serial numbers for inventory. Some items we sell have serial numbers. It’s important that the system be able to track these serial numbers and who we sold them to.

The first item (payables) is an accounting need. If the system doesn’t have recurring payables, the mortgage and pest control will still get paid. It will just take more work to re-enter the transactions. The second item (serial numbers) is an operational need. If the system can’t track serial numbers, there will be work that needs to be done that can’t be done. In addition, operational needs usually have other operational needs that depend on them.

Operational Needs that Depend on Other Operational Needs

In this example, the reason many companies need to track serial numbers is for warranty work. Without this capability, many hours will be spent trying to trace down the invoice that a particular part came from to determine whether it is under warranty. More hours might be spent tracing the invoice from the vendor for that product. Recalls for ranges of serial numbers or lot numbers can be even more challenging.

In some industries, this need can be very important. For example, in the food industry recalls may be based on serial numbers (or lot numbers). Having this data is necessary to comply with government regulations.

The data may be needed to drive other business needs. For example, to track repairs on equipment or offer customers PM (preventive maintenance) contracts.

As you can see, the need for serial numbers may cascade into other needs. And these needs can be more significant that just a few hours a month of additional effort. There may be business opportunities that are either not possible or not practical without these software features.

Business and Software Expertise are Needed

What’s not as obvious from this is that both business and software expertise are needed to come up with a full needs definition. I’ve had many business people ask for serial number functionality. Only a fraction of that number also asked for warranty, service contract, or recall features. When asked, they quickly said that these were also issues.

Understanding how software uses serial numbers (or lot numbers, national accounts, warranty, etc.) allows an ERP provider to ask you the right questions to configure a system. Not all systems have the features we’ve mentioned in this post. For example, warranty tracking for is common in inventory systems that track serial numbers, but not all systems have it. Service and preventive maintenance is less common. For some systems, it is an add-on product; in others, it is part of the core system.

Make sure your ERP provider is asking good (and thorough) questions about your needs. And don’t leave anything out. The feature you leave out may be obvious to you but not to the ERP provider.

The Culture of Tech Deception: It’s Not Just Theranos

It’s not always as bad as Theranos, but it is bad.

Since last year, articles about technology startup Theranos have popped up all over. At first, the articles were about the blood-testing technology Theranos was developing didn’t always seem to give accurate results. In some cases, the results were dangerously, fatally wrong. And now it seems that perhaps the company, at least the founder, knew this and concealed it.

I wasn’t surprised. I deal with it every day.

Vaporware: Software That Disappears

The first significant scandal that I remember was dBase IV. Ashton-Tate was the developer of dBase. The company announced a new version to replace its working, but clunky, dBase III as early as 1986. Finally, in 1988 (an eternity in the tech world), dBase IV was announced in February with an anticipated release in July. dBase IV version 1.0 finally arrived in October of 1988. It was buggy and slow. Ashton-Tate finally delivered an upgrade to version 1.1 almost two years later in July of 1990.

It was about that time the term “vaporware” became popular. Vaporware is an announced software product with announced features that does not exist; sometimes it never comes to market. It fades like vapor into the air.

Features that exist, sort of

I continue to hear from customers about things they have read. This software does such and so. This should work like this. Sometimes, it’s “we just signed a contract with x to do our y.” Trouble is, many times I know the software they are talking about. I ask (trying to gather information and tip them off without creating doubt), “Were they using some add-on to do that?” or “May I take a look at the proposal?”

Too often, the reality is that software WILL do what the customer thinks it will. To put it in business terms, the transaction is possible. However, the issue is often that it doesn’t work the way the client was led to believe it worked.

Case Study: Oops, hand over $50K

Several years ago, we met with a client who wanted to buy software for a particular purpose. We made a proposal and included some customization (which was going to be required). The customization was to add a feature that came up in the first 10 minutes of the first conversation about their needs. They purchased the software from a larger provider who quoted a lower price.

Twelve or fifteen months later, I got a call from their IT Director. The conversation started like this, “Bob, you remember the proposal you gave us for our system about a year ago?”

“Yes, I remember,” I replied (biting my tongue because they’d bought from someone else).

“You remember the feature X we discussed?”

“Yes, it was very important to you, I replied.

“Was there some specific secret you knew about how to do that with the software?” he asked.

“Why?” I replied.

“Because our vendor has just now gotten to the point of implementing the software,” he started, “and they want at least $50,000 more to customize it to do that.”

“Oh. Well,” I started, “I knew that the feature was going to have to be customized. I included that in my proposal.”

“I was afraid of that,” he said.

Unfortunately, they were too far into the implementation to change providers at the moment.

Other examples

I wish I could say this was isolated. I’ve run into far too many technology companies pushing products that had severe limitations. Low-end products in the market today are sold to companies that will ultimately find that the architecture (the basic way the software is built) won’t support the volume of transactions they have. I see boxes of software gathering dust in offices; the company purchased them with the belief that they met their needs, and they did not.

As competition increases, I see and hear about more and more proposals that seem dramatically under-stated. A consultant for a now defunct consulting firm told me that it was a regular practice at his firm to submit proposals that underestimated the required hours by 50%. The employees doing the work were then responsible for “selling” the need for the more time to the customer.

Avoiding the issues

Here’s the fact: most vendor salespeople know their product at a features level, not at an implementation level. They know that the payroll system does multi-state payroll. They don’t know how the multi-state features related to worker’s compensation in multiple states, or how multi-state withholding works, or what the system requires if they have employees that work in multiple states during the same pay period. As a result, when a requirements document says, “multi-state payroll,” they say, “We have it.” The fact is that they don’t know enough about payroll or their software to ask the questions they need to ask to give a meaningful answer.

For 30+ years, I’ve believed that before a customer buys software, someone ought to think through HOW they were going to implement the major features. Without this, you may be sold a Theranos: a device that over-promises and doesn’t deliver.

Here’s the key: Ask not “Will the software do this?” for key functions; ask, “Can you show me how the software will do this?”