Platt Perspective on Business and Technology

Building a business for resilience 29 – open systems, closed systems and selectively porous ones 21

Posted in strategy and planning by Timothy Platt on April 29, 2018

This is my 29th installment to a series on building flexibility and resiliency into a business in its routine day-to-day decisions and follow-through, so it can more adaptively anticipate and respond to an ongoing low-level but with time, significant flow of change and its cumulative consequences, that every business faces in its normal course of operation (see Business Strategy and Operations – 3 and its Page 4 continuation, postings 542 and loosely following for Parts 1-28.)

I began a discussion of business process cycles in this series, and of who does and does not enter into them as involved stakeholders, in Part 28. And one of my primary objectives there was to present and discuss a basic understanding as to how overall, larger scale work flows and transaction processes, can be and are routinely divided out as a connected succession of work responsibilities that are carried out by specific hands-on employees and managers, who primarily individually focus on their own direct responsibilities – and only on them. And I referred to that as representing “a strategic and operational system that is in effect formed as a tiled construct in which most actual hands-on work and most of its direct managerial oversight, are carried out from a more blindered, vision and understanding-limited perspective.”

It is true that every business, and even every large and complexly structured one has people in its ranks who look over the walls of their cubicles there, and who seek to both see and understand the larger picture of how their work fits into larger patterns. But most hands-on employees and managers, and certainly most lower level managers for that employee category, do follow the overall pattern in what they do and how, that I laid out and discussed in Part 28.

• This is a series about business resilience so it is germane at this point in this series, to point out that ultimately this pattern is at complete odds with any effective effort to develop and instill wide-spread resiliency and agility in a business. Blinders, as their name implies, blind. And the blind are less able to maneuver around the unexpected and challenging, and with agility, from that.
• And if that applies to dealing with the unexpected as that can arise within individual employee-centric “tiles” in this type of system, it holds even more forcefully when the unexpected arises in ways that cut across tile boundaries and involves larger swaths of work process flows.

I offered a somewhat abstractly stated real world example of what this can lead to, as drawn from recent experience that I had with my local bank, towards the end of Part 28, citing how the bank officer who I was speaking with there, recounted ongoing recurring problems in setting up certain types of new accounts. He and his colleagues would enter the customer information that they were given, in what at least appeared to be the correct manner: they made what should be the correct data entries to those account setup screens and both for what type of account was being set up with its particularized details and when adding specific customer data into them. But when their step in this overall process was passed on for further action, and into and through larger processing systems that collectively set up these new accounts and enter them into the bank’s overall database system, errors have kept creeping in, and ones that were notable enough so as to derail the whole process for those bank customers. And, as noted in Part 28, no efforts to communicate this problem to appropriate help desk or related support services seemed to work, and certainly for fixing what appeared to be problematical automated steps that entered into these account set-ups. With this continuation of that case study example, I hope to have taken it more out of the abstract, and in ways that would resonate with the experience of others who have seen what should be straightforward processes break down, when going through the hands of others.

How can problems of this type be better resolved? That begins with more fully understanding them for their details, and from coming to know when they are likely to arise and in contextual detail. But as the bank officer who told me of this could tell you, simply knowing that type and level of contextual detail cannot offer any real help, if that only means their understanding how and when and where they are being blocked in effectively doing their jobs, but without having any effective reporting or remediative mechanisms in place for addressing those issues – and for more than just their immediate here-and-now instances and in general for moving forward. I add to this example, that these local branch bank employees were able to call others to achieve what can only be called single instance, ad hoc band aide fixes, but that cannot provide a real solution to anything like this type of problem as a whole. So how can this be better addressed?

• Managers need to be more fully involved, and in ways that cut across those tile boundaries to see how task-step to task-step process flows connect and function.
• And help desk and employee support services need to look beyond simply, reactively following already well established top ten recurring problem lists and from their first point of contact representatives on, through their problem resolution escalation processes.
• In this case, and with my bank example in mind, this has to include adding beta testing of new features and functionalities into their essentially automatic “to-check” and “to verify” lists, and for any significant updates to the tools that employees use in carrying out their work, for when a problem that might stem from them is reported in.
• Does a new or significantly updated tool work effectively in carrying out its intended tasks? Presumably initial software development alpha and beta testing would have addressed that. But how effectively and how seamlessly does this New connect into larger systems that it has to be able to work within? Does it come with what might be at least situational incompatibility problems when real world tested, in what should be included in its tested and verified working context?
• In my banking example that means adding in next-step real world usage testing, as to how new automated task elements are fit into a specific set of customer service and support-related work flows, and whether they bring problems with them, and from either their input-receiving or output-sending ends. The specific problem that I was told about by this banker sounded a lot like it arose as a consequence of faulty “autocorrect” in what for the customer-facing transactions in question, was a newly added in automated data processing step that was supposed to help “fill out” necessary and presumably standardized documentation fields.

I raised the issue of attention-limiting and communications-limiting tiled operational systems that span larger and more complex work flows in Part 28 and I have continued that line of discussion here. And I come back to the challenges that this all-too common a reality creates and both for business resiliency and agility and I add for overall here-and-now business effectiveness too. I am going to turn in my next series installment to at least begin a discussion of how this type of challenge can be remediated, and both reactively and where possible: proactively too.

Meanwhile, you can find this and related postings and series at Business Strategy and Operations – 4, and also at Page 1, Page 2 and Page 3 of that directory.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: