Part II – The Challenge
By Chuck Ritley & Ken Ritley
KEN: Of course, today the ERP concept is an old one – it’s the bread and butter of companies like SAP, and you can get degrees at colleges that teach this stuff. Now let’s get to your challenge specifically – what was your pain point?
I was supervising the coding of a large enterprise control software package. Somewhat later the industry term became known as ERP – Enterprise Resource Planning. We competed with IBM head-on, a tough crowd. This concept included all the functions a company needed from materials to accounting to shipment. A few dealers who had made this their specialty sold the software, and so there had to be some margin for customization.
Our pain point – time, time, time. We knew IBM was almost ready for market. The design had many new features, and the market was much different than today. The first company to break into a market could easily wind up owning it. So our management needed to finish our product and start selling it before IBM or we’d be playing catch-up. And bear in mind, we were a mini-computer company, competing against the giant of the mainframes.
KEN: Today there are many possibilities to solve the time-pressure problem. Hiring good IT people is not that big a challenge – and if you are really under time pressure, there is a huge market of freelancers and even companies willing to take over coding on a fixed price basis. How was it different for you?
Our programming team consisted of 8 “programmers” – today known as developers or software engineers. Based on our workload, that wasn’t enough. Now bear this in mind: it was a proprietary world. COBOL was standard only for mainframes, so it you wanted a competent programmer, you needed to find one with expertise in another language and train him or her in your proprietary language. Freelancing was just beginning, and pickings were slim.
There weren’t any degrees in IT as yet, and most programmers got their start by attending schools from one of the manufacturers. IBM and Honeywell, in those days, had large training programs. Most programmers available for hire had spent time doing mainframe coding for customers of one of those two giants. And they might not have coded in the areas we were developing.
As matter of fact, I was recruited to Silicon Valley because there had been a shortage of good programmers and I had both IBM and Honeywell experience. So there were good programmers available. But not overnight.
KEN: It’s certainly much different today. So what made you think of recruiting an international workforce?
Frankly, the international market had puzzled me for some time. We had distributors in Australia, New Zealand, Germany, Belgium, Great Britain, France, India, and Japan. What amazed me was that everything we published by way of technical documentation was in English. The OS, tied directly to the CPU, had the usual English-like commands: edit, erase, format, etc. The coding language was similar to an abbreviated version of BASIC, rather than the assembler-style used by mainframes.
What impressed me was that each non-English speaking distributor had to have an English speaker on staff. From time to time, each would send techs to the US, always someone fluent in English, and we would train them. They would go home and translate everything from OS and programming manuals to the electronic logic diagrams into the native language. No small task.
But, at the time, the US was the only source of minicomputers on the planet. IBM didn’t compete at that level. For example, in Australia and NZ, we were the largest computer supplier. So distributors who took this route could open new markets at the turnkey level. To support this, we had a programmer and field engineer who worked odd hours to support the time differences and they could provide answers via telex. (No internet as yet.)
I was most impressed by the staff of our Indian distributors, who were a large multi-product electronics house. Because English was common, they created their own software with our programming language. Not surprisingly, some utility software, such as database systems, had market value in the US.