Dear Bob ... Regarding the training issue, too often I think that we train the users in how to operate the software and not how to make it do their job better as your column discussed. Is this because the trainer is often the one who created the application and not the one who actually sees the software as the tool to improve productivity through creative use of the product? As the manager of support I Dear Bob …Regarding the training issue, too often I think that we train the users in how to operate the software and not how to make it do their job better as your column discussed. Is this because the trainer is often the one who created the application and not the one who actually sees the software as the tool to improve productivity through creative use of the product? As the manager of support I too often feel that my staff does more training on how to run the application and not training on how to use the application to increase productivity.Unfortunately I also see that this is often times the case because as support staff we don’t actually use the product we support i.e. we support a database but we don’t use a database ourselves in our daily job. This is a case where we would do well to include an end user as part of the training team but we don’t simply because of the economics involved in expanding the support team to include an end user. Albeit this is a rather short-sited view but when the bean counters are in control it is a fact of life. – Wishing I could do moreDear Wishing …It always depends on the specifics of the situation – showing business users how to use an SAP module to automate production scheduling is different from showing business analysts how to use Excel pivot tables to slice ‘n dice production scheduling data, for example. In both cases, though, you can’t provide relevant training unless you understand the work. At the risk of sounding harsh, I have to say: Don’t blame the bean counters. If a member of your staff is developing pivot-table training and hasn’t picked up the phone to ask a financial analyst to look over the training plan, the problem isn’t the bean counters. It’s that your staff member didn’t think to pick up the phone.And if the SAP implementation team didn’t work with the production scheduling team to establish the new, SAP-driven production scheduling process, it wasn’t because the bean counters forbade it. It’s because your staff figured their job was to install software, not to improve how the business operates.To be fair, perhaps it is. Peel the onion a layer or two and you’ll find a deeper cause – how IT and the rest of the business have defined their working relationship. By old nemesis, the internal customer model of operation, is generally at fault: If they’re our customers and we’re software suppliers, training end users in how to do their jobs with the shiny new software we just delivered is Someone Else’s Problem. Kind of sad, ain’t it?– Bob ——– Technology Industry