I think it’s safe to say that any given ERP software package installation will have features that are available and would be useful to the manufacturer but aren’t used, for any of a host of reasons. Back when I worked directly for a manufacturing shop, I had an experience with the project management aspect of a high-end ERP package that illustrates this.
The manufacturing company I had been working for was just getting its feet wet in tracking the progress of its engineering and design teams in their latest large project. The idea was to hold them to the same schedule standards that the production teams had been held to for decades, and also to be able to identify and quantify delivery schedule risks much earlier in order to reduce their impact (cost), as well as to better handle late-breaking design changes. Needless to say, the engineers balked at actually being tracked to a schedule. This was new. They’d always been given schedules to follow but no one paid much attention to them because missing a date never seemed to matter. Sure, some tasks were delayed but there were always workarounds, and sometimes others were completed early. It all comes out in the wash at the end, right?
Wrong. A communication vehicle didn’t exist for the engineers and designers to see the horrendous inefficiencies that missing their schedules caused downstream. There was no concrete way to show them exactly what was at risk if they put off this task in order to support that other task, simply because that other manager was capable of bellowing more loudly. Upper management saw that if they could reduce this “churn”, they would be able to cut costs and capture greater market share. The technology was already on hand. What was needed was a resource-loaded engineering/design schedule fully integrated with the existing production schedule in order to discern the entire critical path.
To that end they went out and hired a crew of freshly-minted engineers to be engineering planners because they had a good chance of understanding the engineering teams’ arcane lexicon (plus the economy wasn’t super great for engineers at the time), sat them down in front of terminals and said, “Make it go.” There were some experienced production planners sprinkled in the mix, but there was no training other than on-the-job. The company had been using the software for a while, just not the project management features so much. As a scheduler, in my mind project management and shop floor control are essentially the same thing except that what’s being managed mostly is people’s time as opposed to mostly materials, and the deliverables are information packages as opposed to physical products, respectively. My own deliverables were pure information–schedules–and coming from a production-oriented background it was difficult to wrap my mind around that fact at first.
The scheduling database made it possible to hold as much information as the planners could enter, so their time was spent entering and changing schedule information at the direction of the engineers, and with the approval of upper management. Very little time was left for actual manual scheduling like had always been done before, and besides there was just too much information to deal with. So instead of a planning organization, we were closer to being a reporting organization, collecting data and generating endless reports. Even so, the reports definitely had value as a communication vehicle between finance, purchasing, engineering, production, management, etc.
I was hired on late in the process, so most of the schedule had been built already and those pieces were owned by other planners. Since I was pretty much on my own I read everything the software manuals said on how to model work scope and dependencies in the scheduling database. I had to think hard about exactly how to map the semi-formal colloquialisms management/engineering used, to which fields in the database to enter the different schedule data.
It was a fully matrixed organization and the engineering manager I supported happened to have been a manager of planning in the company before. He knew the capabilities of the software extremely well and told me in no uncertain terms that these new schedules I was working on–that he was responsible for achieving–would be machine-scheduled. The number of work packages numbered in the tens of thousands and there was absolutely no way for me to manage them manually with the amount of week-to-week change that was going on. In other words, he saw that this expensive software suite was not being used for what it had been designed to do, which was to take resource availabilities and requirements into account as well as the logical and time constraints when calculating schedule dates. He knew that if I could use this key feature I would be much more efficient and therefore more likely to come up with schedules that he could manage to.
I asked around to see if anyone had used the resource scheduling routines and found out that the only person that knew how to do it had left the country. Some very experienced planners told me that I was wasting my time—it was too hard and not worth the effort. This might have been true on the production end because the modes and methods of production hadn’t changed much or had changed relatively slowly over the years and were very well-understood. So I went back to the voluminous manuals and went ahead and tried it anyway on my own schedules and after a bit of fiddling and calibrating, got it to work just fine. “You’d like to do some what-ifs on these 4,000 work packages based on these sets of changes? Sure, I’ll have something for you to look at this afternoon,” somehow sounds better than, “Sorry, no time. You’re an engineer, you figure it out.” It turns out the key was to model the work scope, logical dependencies, and resource availabilities correctly and consistently in the database.
Since I was now the new de facto resident expert on resource scheduling, I was told to set up resource scheduling processes for the other engineering managers. Unfortunately, the different pieces of the schedule were modeled in slightly different ways because each one was owned from beginning to end by the same planner, and in most cases information essential to the process was missing altogether. The standards being followed were inadequate to support resource scheduling, because no one knew they were needed, let alone what they should be. The vendor had even been persuaded to add two more date fields completely independent of any schedule processing routines, because planners couldn’t make the calculated schedule dates match what the engineering or management teams said they should be without changing tightly-controlled information, like progress against the schedule or logical dependencies.
It’s no wonder that when the resource scheduling routines were applied to the earlier schedule pieces in order to try to arrive at a decent trade-off between a resource-limited and a time-limited schedule, what came out was either the same schedule or was so far out of whack that it was impossible to know where to start to fix the problems. Any reasonable person would conclude it was just too hard. In the end we muddled through and were mostly successful, but we might have been more successful if the software’s full capabilities could have been harnessed fully.Posted by Sheldon Pryll, Software Engineer, ProfitKey International