I didn't implement the ERP system. I enhanced the existing system to provide the benefits that the customer sought from the ERP systems.
What I really did was help the customer identify and attack their real problems without worrying about the technology at all. They had business problems that they thought could only be solved with "bigger better software". They were wrong (as many people are).
Some of their problems:
- inventory was inaccurate
- product info (and bills of material) was inaccurate
- too much inventory
- too many late shipments to customers
- shipping costs were too high
- production was not efficient enough
These are classic problems normally attacked with ERP software. But their people were already doing the best the could with the tools at hand: old software and Excel. The project had me work with their people on their problems, not on the software. The solutions we proposed usually required more/better software, but not always. Sometimes it was just a different policy or procedure (or a bi-lingual count sheet).
The exercise in attacking the problems at hand generated the software requirements that helped the customer solve those problems. Mostly new forms, reports, database tables, and a few optimization workbenches and dashboards. (One of my favorite programs was a simple tool that enabled a dispatcher to drag and drop loads into trucks, drap and drop trucks onto routes, and generate reports. He "played" with this toy until he was satisfied with the best result.)
Hacking the customer's business was tricky. Writing the software was trivial.
This goes back to one of OP's points: it's not about how many lines of code or how fast you can write them. It's about providing value to help the customer solve their problem. That's where the real money is.
Just to add to the conversation:
Customization is 90% of the hard work of doing enterprise software. Often enterprise software requires teams of folks to do the above, because what is required is
a) knowing the problems
b) knowing how to solve them (ie, coding/configuration)
c) being able to sell this to decision-makers
Those three roles often take more than one person to realize. Some folks are good at one of those, and they get paid well. Folks who do two or more well are rare/in-demand.
I had picked them up pretty much in the standard way as a referral from a friend to do maintenance programming on their legacy system. They had me share an office with the Big 5 consultant who was interviewing ERP vendors. I knew immediately that he had no idea what he was doing and would ultimately waste a lot of good people's time and money. I had a lot of respect and loyalty to this customer and didn't want to see them taken advantage of.
I remember sitting up all night wondering what to do. I decided to go to the CFO. I told her that her Big 5 vendor didn't know what he was doing and gave her plenty of good examples. I explained that after working with her software and her people for 3 months, I could come up with a more effective way of solving their problems in 10% of the time for 10% of the cost.
I half expected to be thrown out of her office, but instead, she got up, closed the door, and said, "Funny, I was thinking the same thing but didn't know what to do about it." Together we laid out the plan and strategy for the project.
Ever since, I have never been bashful. Even though proficiency and experience can carry you a long way, your biggest advancements often come when you go out on a limb to provide real value for a customer.
Another lesson: you never know what a gig can turn into, so just do your best and keep pushing that envelope.
This is one more example proving "No guts, no glory". IMHO it takes real courage and conviction to go to a C-level executive and state the obvious. Which is why it doesn't happen more.
What I really did was help the customer identify and attack their real problems without worrying about the technology at all. They had business problems that they thought could only be solved with "bigger better software". They were wrong (as many people are).
Some of their problems:
These are classic problems normally attacked with ERP software. But their people were already doing the best the could with the tools at hand: old software and Excel. The project had me work with their people on their problems, not on the software. The solutions we proposed usually required more/better software, but not always. Sometimes it was just a different policy or procedure (or a bi-lingual count sheet).The exercise in attacking the problems at hand generated the software requirements that helped the customer solve those problems. Mostly new forms, reports, database tables, and a few optimization workbenches and dashboards. (One of my favorite programs was a simple tool that enabled a dispatcher to drag and drop loads into trucks, drap and drop trucks onto routes, and generate reports. He "played" with this toy until he was satisfied with the best result.)
Hacking the customer's business was tricky. Writing the software was trivial.
This goes back to one of OP's points: it's not about how many lines of code or how fast you can write them. It's about providing value to help the customer solve their problem. That's where the real money is.