A recent exposure to the internal working of an SME's internal production made me question whether we were really living in the 21st century. How could people still be using pen and paper to audit production-stage data? Why? The answer was much more nuanced than just an education gap. Surely most of the factory workers are not expected to have formal schooling, so it does make sense to rely on manual forms instead of handling digitized documents. A group of such workers are generally allotted to someone capable of doing so, yet they consolidate the data of 10 different workers' output into a single sheet instead of directly entering that data into a Google Sheet.

Here's where our classic human trait of pretense comes into play. There happen to be cases where even such managers cannot be trusted completely to provide accurate data, a generic example being their self-image. People would rather hallucinate data than provide exact, accurate entries just to prevent their capabilities being questioned. Such a situation ends up adding an unnecessary layer of manual review with workers' data and manager's data for factual checking, consuming precious time.

Another case would be where a sales executive decides a specific cost rate for a specific procedure an item will go through and gets an agreement with the client for it. The order is drafted into a production plan and passed on to the production/planning team to be sent on to the respective departments. Sometimes the people deciding a specific process's rate after viewing the required production shipment — i.e. cutting — decide on a different rate than the original rate the client agreed on. That decided rate is then directly used for production of the order. Sometimes more material is used up for production without authorization from higher-ups, as the manager of the segment decides "this much material is not enough" — i.e. 600 units used instead of the allotted 500 units. This ends up directly impacting the generated revenue on the entire shipment, perhaps even reducing the revenue by 30–40%. That is a huge impact for an order.

Yet to solve such an issue, a simple meeting or repeated complaints don't amount to a solution. To create a solution, one needs to understand why the exact problem arises. Why does the humane behavior compel them to resort to such actions? Why can't something as important as data be transparent and centralized?

Listening to such issues in a production pipeline made me re-evaluate my image of the work of a Solutions Architect significantly, for they sit and understand a business's problem from an insider's POV and translate that business problem into a technical problem, thereby creating a technical solution for it.