Major challenges

  • Don Hill (Unknown Publication)
  • 30 June, 2002 22:00

Hogan says the biggest challenge is development of business processes on the asset management side. The difficulties are inherent in the loose structure of the organisation, where there has been little standardisation of processes. “We are going to have to take all the different instances and blend them together into best practice. At least, this project provides us with a really good opportunity to do that. It forces you to sit down and say, 'What is this person actually going to do?' In the case of finance, we had a financial accountant, we had the woman who was going to be systems accountant. I was there, as was a JD Edwards representative. We also had the account manager, and he attended all the analysis sessions. He was there when we had queries, especially ones that were going to affect end users. In addition to all that, I had a weekly communication with those users. I sent out an email to say what we had done and what we were doing. I asked for feedback and their opinions, what they thought. We collated all that, and would come up with the best approach according to the feedback we got. Then we communicated our analysis to the users and explained how we were going to do things."

Hogan emphasises that, try as she does, it isn't always possible to please everyone — especially when a piece of advice is rejected. “Consultation means I have to take all this information and someone has to make a decision at the end of it."

That raises another question: How did the Luddites, those who refuse to accept new technology, react to the changes? Well, says Hogan, it is all a matter of change management. The development team all worked in the same room, which meant they were constantly tossing ideas and questions at each other. Major discussions were going on all the time. Together, the project team asked and answered every possible question they could imagine. The result was that no matter what the users threw at them, they had already considered the answers.

“We never said, 'Oh, we didn't think of that'. Or, like, 'That sets the cat among the pigeons'. We tried to come up with every possible scenario. We did the same with our testing as well. What happens is that when you know your approach very well you assume that there are things you won't do and you just assume that other people won't do them, either. When testing, it was best to get someone who had no knowledge of the system, plop them in front of a PC, give them some documentation, and say go for it. And they did the weirdest things sometimes. But it was really good! And when we went live we trained the finance team the month before we went live. Then we trained them again the day before we went live, and we were with them on the floor for the first week. We made sure we were there constantly and that they had support when they wanted it, and we had a huge manual — full of pictures, totally step by step. Documentation has been a big thing for us."

Despite all this, Hogan acknowledges that new ideas can sometimes produce an irrational response. People want to know why the activities they have been performing for years in a particular way are no longer acceptable. Hogan says the solution in most cases was to try to match established practices as closely as possible. Ironically, before the changes, Ugen users would complain about the software and call for better analytical tools. When the new system came along, they would ask why they couldn't continue to do some things the old way.

“You are always going to get that," says Hogan. “It's inherent in change. We had to acknowledge that, yes, Ugen did it this way but by doing it the new way we had got additional benefits. We would explain, for example, that by doing something the new way they would save time, whereas in the old way they would have had to enter the information twice or whatever. Then they would kind of see it and say, 'Okay, I get that'. You have to keep on reinforcing those benefits. You might even have to point out that not all the benefits will relate to the people asking the questions. For example, you might have to show that someone else can save, say, four hours work a week when you do things the new way."