The Factory Taught Me That Software Must Serve Work

A technical apprenticeship

At ITC Limited, one of my major responsibilities was to help implement Manufacturing Resource Planning systems across factories. The original computing environment had roots in Burroughs systems, and my work as project lead focused on the planning and optimization layer using VAX/VMS and MANMAN. Describing it that way now makes the work sound much cleaner than it felt at the time, because this was a deep technical apprenticeship rather than just a business systems project.

The environment itself had to be learned. VAX/VMS had its own way of working, C had to be learned and used seriously, and MANMAN, the core manufacturing system, had been written in Fortran, with much of the business logic buried inside that older codebase. Our job went far past wrapping it with a new interface or moving data around. We had to understand what the Fortran logic was really doing, separate the manufacturing knowledge from the old implementation, and translate it into a cleaner architecture, and that was difficult work, because the business logic was never sitting there neatly documented. It had to be extracted, interpreted, tested, and debated. Some of it reflected formal manufacturing logic, some reflected years of operational adjustment, and some made sense only after speaking with people who understood the factory better than the code did.

The data models had to be built in Ingres, running on VAX/VMS, and the user interfaces had to be developed for VT100 terminals, which sound almost prehistoric now but were the working reality then. Nothing about those terminals was elegant: the screens were clunky, the interaction model was constrained, and you had to think carefully about what information belonged where, how much a user could see, how many keystrokes were reasonable, and how to make a serious planning system usable within those limits. That constraint was good for me. It forced discipline, because you could not hide behind a beautiful interface. A planner, supervisor, or manager sitting at a terminal had to get the information needed to make a better decision, and the system failed equally whether the screen was confusing, the data was wrong, or the logic did not reflect the factory.

There was also the networking challenge. We had to connect factories to one another through VSAT links using X.25 protocols, and at that time, building communication across factories required real care. Bandwidth was limited, reliability could not be assumed, and data movement had to be designed with the constraints of the network in mind. The idea that one factory could communicate with another through this kind of distributed setup was exciting, and it added another layer of complexity. So the project was intense. We were learning operating systems, programming languages, database design, manufacturing logic, user interface constraints, and networking architecture while also trying to understand the real business of the factory, and that combination shaped me. Being technical was insufficient, and understanding manufacturing in theory was insufficient. You had to hold both together: code that made sense alongside business process that made sense, a data model that was clean and also reflected how materials, inventory, production schedules, and procurement actually behaved, a network that worked carrying information that mattered. The work was hard and alive, and every day brought something new, a VAX/VMS issue one day, buried Fortran logic the next, a data modeling problem in Ingres, a user struggling with a VT100 screen, a factory process that looked simple in documentation and became complicated the moment we traced it through real operations.

MRP was never glamorous software, and it carried none of the excitement of later technology waves, but it mattered. It gave the organization a way to reason more carefully about materials, schedules, inventory, procurement, constraints, and production plans, helping turn scattered operational knowledge into a more coordinated view of the factory.

The computer arrived into a living system

That coordination was never automatic, because the software entered a world that already had intelligence. Factories had always planned. People knew their work, supervisors knew their machines, storekeepers knew inventory habits, production teams knew the real sequence in which work could move, planners knew which assumptions were safe, and managers knew where pressure would show up first. Much of that knowledge did not live in any system. It lived in people’s heads, notebooks, ledgers, conversations, routines, and informal checks developed over years. The computer did not arrive into emptiness. It arrived into a living system, and that was the first serious lesson.

A factory is a place of memory as much as a place of machines. Some memory is formal, in bills of material, production schedules, inventory records, purchase orders, and reports, and some memory is lived, in the practical knowledge of people who know how work actually happens when the formal plan meets the day’s conditions. Ignore the formal process and the system lacks discipline. Ignore lived knowledge and the system fails in practice. The work was to bring those worlds closer together, and that required listening. Someone might explain the official planning process, and after a few more questions, the real process would begin to appear: a material delay triggering an informal adjustment, a report checked against stores before anyone trusted it, a production team knowing the practical sequence before the system knew how to represent it. Those moments stayed with me. They taught me that the official process and the real process are often related and rarely identical, and the difference between them is where many enterprise systems fail. On paper the process looks clean. In the factory the work carries exceptions, substitutions, delays, judgment calls, experience, and pressure, and a system that ignores those realities may be technically correct and operationally useless. So we mapped, checked, argued, corrected, tested, and returned again, following materials from procurement into stores, from stores into production, from production into reporting, and from reporting back into planning, studying where information was created, delayed, trusted, and quietly worked around.

I began to see workarounds differently. A young technologist can easily read a workaround as resistance, and sometimes it is, when people avoid discipline because the old way is more comfortable. Often, though, a workaround is intelligence trying to survive a system that does not yet understand reality. A workaround can be a signal, revealing that the formal process is too slow, the data is unreliable, the report is not trusted, the timing is wrong, or the system misses a practical constraint everyone on the floor already knows. The mistake is to dismiss that knowledge too quickly. The deeper task is to ask why the workaround exists. That became part of my education at ITC, and it taught me to respect the people closest to the work. They did not always speak in system language or describe their knowledge in ways that fit documentation, and they often knew exactly where the real risk was: a supervisor sensing when a schedule looked unrealistic, a storekeeper knowing when inventory on paper was misleading, a production person explaining why a planned sequence ignored a physical constraint, a planner recognizing that a number was technically available and practically unusable. That was intelligence, embedded in routines, memory, and responsibility, and a good system had to learn from it.

In those implementation days, the computer room still had a certain presence. Computing was neither casual nor everywhere. Machines had to be protected, scheduled, maintained, and understood, and reports, printouts, terminals, batch runs, and the timing of processing all carried weight, because a system run could affect the next day’s planning conversation. When we prepared data, configured logic, checked assumptions, or examined output, we were touching the way the factory saw itself. If a number was wrong, someone would feel it. If a plan was unrealistic, someone would have to explain it, and if the system produced a recommendation that ignored the reality of the floor, confidence would disappear quickly. The system had to earn the right to be believed.

Implementation is a long conversation

That was one of the hardest parts of the work. In the early stages, people often trusted the old way more than the new one even when the old way was messy, and that was understandable, because the old way had history, relationships, memory, and human judgment embedded in it. The new system had logic, and logic alone was never enough. Factories do not move at the speed of technical desire. They move at the speed of trust, habit, pressure, and proof. A planner who had relied on experience for years could not be expected to surrender judgment to a report simply because the report came from a computer, and a supervisor who understood machine behavior better than any document could not be treated as a passive user waiting to be modernized. Often, that person was carrying knowledge the system desperately needed. So we had to build the bridge, bringing the system closer to reality while helping reality become more disciplined, and that was delicate work. Sometimes the difficulty was technical: a missing field, a wrong conversion, a process assumption that did not match the factory, a timing issue distorting the result, a network constraint forcing a different approach. Sometimes it was organizational, with one department seeing value while another saw burden, one manager wanting precision while another worried about disruption. Sometimes it was simply human fatigue, because people already had full days and the new system asked them for more attention before it gave them relief.

That is where I learned a distinction I have kept ever since.

Every test, correction, meeting, report, objection, exception, and workaround was part of that conversation. The software had to learn the factory, the factory had to learn the discipline of the software, and neither side could remain unchanged. There were frustrating days, because a system builder wants progress and a young engineer especially wants progress. I had energy and conviction and believed in the usefulness of what we were building, and belief does not eliminate the stubbornness of reality. Some days the data did not cooperate, some days the process seemed clear in the morning and confusing again by evening, and some days the gap between the designed flow and the lived flow felt too wide. Those were the days that taught me the most.

Information has weight

A factory reveals the cost of imprecision. In a classroom or laboratory, an error may be corrected and forgotten. In a factory, an error travels, moving into inventory, scheduling, purchasing, labor allocation, production commitments, and management decisions, so that a small mistake becomes a chain of inconvenience. The factory taught me that information has weight. Data was far more than something stored in a system. Data was a promise. When someone entered a quantity, confirmed a material, updated a status, or accepted a schedule, that information became part of the factory’s shared reality, and others would act on it: a planner depending on it, a buyer ordering from it, a production team preparing around it. If the data was careless, the consequences were never abstract.

This made discipline necessary, and I mean the practical discipline of respecting consequence rather than the harsh discipline of control for its own sake. The factory did not need perfect theory. It needed dependable information, and it needed people to understand that small acts of accuracy helped the whole operation function. Reliability was built into habits as much as machines: a person recording correctly, a supervisor communicating a change promptly, a planner questioning an unrealistic number, and a manager respecting the system’s discipline were all part of reliability. The software mattered, and it was never alone.

That lesson changed how I thought about enterprise systems. Before ITC, much of my formation had been technical, in circuits, microcontrollers, machines, code, and instruments, and the lab had taught me that a system must survive contact with physical reality. ITC taught me that software must survive contact with organizational reality, which was more complex. People had histories, departments had incentives, managers had pressures, workers had practical knowledge, reports had politics, data had consequences, and old systems had emotional weight because people had learned how to survive with them. To build useful software inside that world, technical correctness was only the beginning. The system had to serve the flow of work.

A factory is full of motion, and not all motion is flow. Motion is activity. Flow is coordination. Many people can be busy while the operation stays stuck, a department can be efficient while the whole factory suffers, inventory can exist and still not be available where it is needed, and a production plan can be printed and still fail to match reality. The work of planning was never simply to create schedules. It was to bring many moving parts into a shared rhythm, a rhythm that included machines, materials, schedules, supervisors, inventory, procurement cycles, lead times, demand forecasts, maintenance realities, and the daily exceptions that never fully appeared in formal documents. MRP sat at the center of that effort, making certain conversations possible: what we actually had on hand, what we needed to order, which delay mattered, which plan was realistic, and which production commitment could be trusted. These were never glamorous questions. They were the questions that kept the factory alive, and I began to respect them deeply.

The longer I worked in that environment, the more I appreciated the seriousness of manufacturing. From the outside, a factory may be seen as a place of production. From the inside, it is a place of commitments. Every plan is a commitment to coordinate people, machines, materials, money, and time, every failure to coordinate has consequences, and every improvement in coordination creates value. Software earns its place only when it helps carry those commitments better, and that earning takes time. The factory did not change because we announced a new system. It changed when the system began to answer real questions better than the old methods could, when a report became trustworthy enough to influence a decision, when a planner saw fewer surprises, when a supervisor began to believe the system understood something real about the floor, and when people stopped treating the software as an external demand and began treating it as part of the work. Those shifts may look undramatic, and they are the evidence of adoption.

Trust is earned on the floor

In those early years I also learned the danger of overpromising. Technology people are often tempted to speak in future tense, promising what the system will do, will improve, will transform, while users live in present tense and want to know what works today. The factory made me careful. It was better to show a working improvement than to make a grand claim, to fix the data issue rather than argue conceptually, to earn one department’s confidence rather than announce organization-wide success too early, and to let reliability speak. That discipline shaped my temperament. I became interested in proof, and I mean proof as lived experience rather than slogan: whether the thing works where it is supposed to work, whether the people who depend on it trust it, whether it improves flow, reduces confusion, and holds under pressure. The factory kept asking those questions every day, and so it trained me every day.

There were many forms of pressure, from production, management, technique, and time, alongside the pressure of being young and wanting to prove myself, of working inside an established organization where credibility had to be earned, and of knowing that mistakes would not remain private. I did not always handle everything perfectly, and no young builder does. There were times when I wanted the organization to move faster, when I underestimated the emotional weight of change, when I had to learn that being right technically did not mean being effective organizationally, and when listening saved me from forcing a poor solution. Those lessons entered slowly, and I began to understand that implementation requires respect: for the user, the process, existing knowledge, constraints, the difficulty of changing habits, and the fact that people carry responsibility long after the implementation team leaves the room. That respect never made me less ambitious. It made my ambition more grounded. I still wanted better systems, disciplined planning, and an organization using technology more powerfully, and I began to see that durable change must be absorbed by the people who live with it. A factory cannot be improved from outside its own rhythm. You have to enter the rhythm first, and only then can you help make it more coherent.

Some of my strongest memories from that period are repeated scenes rather than dramatic events: a group gathered around a report, tracing a number backward through the process, a discussion with someone from stores about why inventory on paper did not match available material, a production person explaining why the planned sequence ignored a practical constraint, a technical colleague staying late to correct an issue before the next run, a young team member discovering that a small piece of code could affect a large operational conversation, and a senior manager asking whether the new system could be trusted yet. That word carried weight. Trusted. Trust did not come from enthusiasm. It came from repeated usefulness. The system had to be useful on ordinary days rather than only during demonstrations, supporting the boring work, the routine work, and the pressured work, fitting into the Monday morning meeting, the late afternoon correction, the urgent planning call, and the monthly review. It had to help when people were tired, busy, and impatient. That was a high bar, and it was the right bar.

Looking back, I can see how much of my later thinking about enterprise systems began in those factories. Even now, when people speak about AI in the enterprise, I often think back to ITC. The technology is different, the language is different, and the stakes are often larger, while the old lesson remains: a system never becomes useful because it is advanced. It becomes useful when it serves real work. If AI ignores workflow, context, trust, exception handling, and the practical knowledge of people closest to the decision, it will repeat old mistakes with newer tools. A demo can impress a room. Work will expose the truth. The factory taught me that long before AI became part of the conversation.

At that stage of my life I was not thinking in terms of a grand career pattern, naming myself a builder of decision infrastructure, or imagining future work in global platforms and intelligent systems. I was simply learning how serious systems had to be built, and the seriousness came from consequence. If the system failed, people could not simply admire the idea behind it. They had to deal with the failure, and that knowledge made me more careful, more attentive to detail, and more aware that reliability is a discipline that begins at the beginning rather than a technical feature added at the end. It begins with how you understand the problem, continues through how you design the process, depends on how you handle data, is strengthened by how you train people, is tested by how the system behaves under pressure, and is sustained by whether people continue to use it when no one is forcing them. This was the discipline the factory gave me.

By the end of that factory chapter at ITC, I had changed in ways I could not fully describe then. I had entered as a young engineer shaped by laboratories and technical curiosity, and the MRP work gave me something more grounded, teaching me to respect operations, institutional memory, the people closest to the work, and the quiet discipline required to make technology useful in a place where mistakes had real consequences. This was only the first part of my ITC journey. The next assignments would take me into very different environments, first into the public rhythm of a city through the MRT fare collection system in Singapore, and later into the work of building a software organization itself through the ITC Software Technology Park. I did not see the full arc at the time. I was simply learning one system at a time.

The factory gave me the first serious foundation. It taught me that software never becomes useful because the builder believes in it. It becomes useful when it helps real work move with more clarity, coordination, and trust, and in a factory, trust is earned on the floor. The city’s lesson comes next, in The City as a System.