I worked for 20 months in a historic retail company in my area. I won’t mention the details so I can talk about it freely. My role was logistics coordinator: basically organizing and reorganizing the company workflow starting with logistics issues and expanding the scope to business processes more generally. The beauty of working in a family-owned business is this: that you interface with all – literally all – business functions. Management, management consultants, purchasing department, administrative department, marketing consultants, foreign sales, sales agents, incumbent clerks who are actually internal solutions engineers, IT consultants, B2B and B2C customers.
What I learned from this experience. That renewal goals are not enough, starting with a succinct decision you also need to be able to cast down top-down process innovation, and escalate bottom-up the ideas of those who actually carry out the day-to-day work. Actually my last sentence is not true either, process innovation is not lowered from the top, what you do is start a change management project that integrates experience and change. The design of a change should not only be decided by a team of people involved, it should first be discussed (tested) among the entire corporate pool. I deliberately use the word pool, to mean the entirety of all business figures, none excluded, without the need to segment or compartmentalize people’s nominal functions. This does not mean being a democracy, it means accepting the fact that changes are never as localized and circumscribed as they seem, inter-process interactions are always there. Just think that in a structured software house debugging is done by specialized operators: processes-and problems-are never completely localized. Companies are systems of systems, interacting in ways that sometimes are not explicit and only become apparent in testing and debugging. This way of approaching the problem must be trained; it is easy to intuit but not at all trivial to apply in reality.
Next sensitive point. Resistance to necessary evolutionary pressure. To restructure a process you need authority, not in the character sense, not leadership, I really mean decision-making power on paper. You can’t systematically evolve if time is wasted convincing the boss’s boss’s boss that it would be time to make a change to the workflow segment. Inertia is real, stakeholder alignment comes at a cost, in terms of time, effort and friction. As a consultant I can find and enumerate critical points in a system, but I would never start working on them if I did not have the temporary decision-making power to do so. Also because it still remains true that there are staging instances and there are A/B tests, you don’t necessarily need to make a dent in current production to innovate. I explain this with a devops concept. If my pool of Kubernetes nodes has a legacy version in production and a version coming out of staging and into the testing phase, I can schedule a load balancer so that it forwards requests in a way that tests the new agent gradually without affecting the implicit SLAs too much.
SMEs, particularly microenterprises, have very high potential, and often a lot of real experience that should not be thrown away but should be channeled into a piping network that needs to be constantly adapted to the situation. And that is essentially my job.