Platt Perspective on Business and Technology

Business planning from the back of a napkin to a formal and detailed presentation 30

Posted in strategy and planning by Timothy Platt on July 8, 2019

This is my 30th posting to a series on tactical and strategic planning under real world constraints, and executing in the face of real world challenges that are caused by business systems friction and the systems turbulence that it creates (see Business Strategy and Operations – 3, Page 4 and their Page 5 continuation, postings 578 and loosely following for Parts 1-29.)

This is in large part a series about communications, shared understanding and the search for agreement, and follow-through – and repeat. It is about communication and its actionable context as an ongoing process. And as an emerging thread in that larger narrative, I have been successively discussing each of a set of three closely interrelated topics points here, since Part 19, that become important in any business and certainly when and as it faces change and a need to effectively navigate a path forward through it:

1. More systematically discuss how business operations would differ for businesses that follow one or the other of two distinctively different business models (see Part 19 through Part 21 for a selectively detailed outline and discussion of those businesses),
2. How the specific product offering decision-making processes that I have been making note of here would inform the business models pursued by both of these business types, and their overall strategies and operations and their views and understandings of change: linear and predictable, and disruptively transitional in nature (see Part 22 through Part 25 and for more of a “big picture” discussion of this also see Part 26 and Part 27.)
3. And I added that I would discuss how their market facing requirements and approaches as addressed here, would shape the dynamics of any agreement or disagreement among involved stakeholders as to where their business is now and where it should be going, and how (see Part 28 and Part 29.)

Crucially importantly here, for purposes of what is to come in this discussion, I have focused since Part 19, essentially entirely upon the individual business and its organization and management, and on its more within-house communications and business execution. And that has been true even when I have explicitly raised the issues of markets and of a business’ connections with and dealings with participants there too, and when noting outside connections in general through that progression of postings. Even there, my real point of focus has been on the single business and its in-house stakeholders and on their roles in all of this, and I have treated that group of participants and their enterprise as if collectively forming a center of their own little universe.

My goal now is to step out beyond those constraints to more explicitly consider and discuss wider contexts, starting here at least with business-to-business collaborations as perhaps most commonly found in organized supply chain systems. And I begin addressing that topic area here by making what I would assert to be an arguably quite defensible axiomatic assumption:

• Effective business-to-business collaborations can only be sustainably developed and maintained if the businesses involved in them can and do each speak with a single, consistently organized overall voice, and certainly at any given time and when addressing any given mutually significant issue.

This does not mean that all communications should go through single individual spokesperson agents. And this does not mean that a business’ basic message or its context-specific elaborations cannot change with time or circumstance. What is does mean is that conflicting messages can and do sew chaos, and longer term doubt as to how reliable a business partner is and can be, if it becomes known for conveying them.

Conflicting messages create uncertainty, and that creates or at the very least increases the overall level of risk as perceived by other businesses that need to know with certainty what is being offered or agreed to, and the actual terms of such agreements that they would enter into. The uncertainty that I write of here creates financial risk and liability exposure at the very least, and additional cost; here, risk can legitimately be seen as a categorical form of cost and of cost exposure. And like business systems friction, as is repeatedly discussed in this blog in a strategy and operations context, all of this deters and slows down business transaction flows but without creating any direct corresponding positive value in return.

• Conflicting messages make it more expensive to do business, and on several levels for a business that finds itself dealing with such an inconsistent supply chain partner, making them less competitively valuable or value creating as supply chain or related-system partners in the first place.

I have written up to here in this posting and in more recent installments leading up here (and certainly in Parts 28 and 29), in abstract terms of the value of consensus or of at least reaching working agreement. Think of this posting and what is to follow in it as a starting effort to take that line of discussion out of the abstract, with a very real world example of how and where a failure to come together within a business, can and will create problems, costs and a loss of potential competitive strength and position. And I begin exploring these issues in what admittedly are still more general, abstractly stated terms by noting that:

• The communications challenges issues that I have been raising here only start to play out and take on practical meaning and significance in the executive suite, and even when a business is essentially entirely top-down organized and run. A more complete answer to the challenges that I would raise here depends on the actions and the messaging of the full range of non-managerial hands-on, and managerial employees who would actually directly deal with supply chain partner businesses and their employees, and carry out specific transactions with them. And this leads me to some specific due diligence questions that would profitably be thought through and actionably addressed when developing and performance evaluating these business-to-business relationships and the actions of the businesses that enter into them.

Let’s start with the types of transactional communications that would have to be considered here, that I would categorically divide as a matter of hands-on practice into three at least relatively distinct types. And to be explicitly clear in what follows, organizing the questions that I would offer here as a planning and evaluation exercise, the goal here is to identify and characterize business activity as actually carried out – not just as intended on paper, to see what of that would fit into each of the following categorical types:

1. Fully standardized recurring transaction types that would essentially always be form-templated for what types of information would be shared and how, where precise details of that would be specified for all of the basic steps of these business processes: Here, the questions that would arise concerning these transactions are essentially all going to be performance-based for how well they actually work, as set up and carried out through the employee-usable forms in place as data entered is shared through them Are these transactions and their implementing forms quick and easy to carry out, and with minimal mistakes or need to correct and resubmit? Are they effectively designed and particularly for initial action attempted by front-line employees who would routinely carry them out? Are they organized and carried out in ways that would make it easier to identify need for exception handling escalation, and in ways that would facilitate exception handling hand-offs and execution if that proves to be needed? And are they flexible enough and adaptable enough if change is needed in them, so as to limit the likelihood of need for more impactful exception handling later on, at least for whatever specific issues have led to a need for a specific exception handling response in some here-and-now? Are, in other words, next required exceptions or problems escalations more likely to be repeats of old problems, or are they more likely to mostly just arise when more entirely new problems and challenges do?
2. Standardized transaction types that can be seen as variations on the above, but where escalation to a manager or supervisor would likely be required, and where additional documentation would be required as to the What and How and Why of what happened: Effective due diligence processes begin with the more normative standardized transactions and their ongoing execution as touched upon in the first of these bullet points, to make sure that processes followed are and remain effective and effectively connected to the business model and the business plan in place, and in the face of ongoing change, and ideally for both businesses involved in any given supply chain transactions here. The transactions that I write of here are more unusual or even unique, calling for more customized transactional processes, and probably more unusual types of information sharing. And more particular individualized attention as offered on a more case by case or at least a more recurring-type basis, would be paid to these transactions.
3. Essentially entirely non-standard transactions that would be of sufficient scale and impact for their costs and profits potential or for their direct resource requirements so as to call for managerial oversight and decision making, and possibly more senior level approval: Effective due diligence of these events would be carried out on an entirely case by case basis, with an understanding that an excess of the second type of transaction as noted here, calls for redesign of and updating of the forms that would be used, the training of the people who would carry out this work, or both, in order to shift them into the first of these three categories. And anything in the way of excessive numbers of these third category types of exceptions would indicate genuine gaps and disconnects in the basic transactional process systems in place and of a level of significance that would call for fuller corrective measures. These types of impactfully non-standard events and the transactions they can call for, can arise in any business and in any business-to-business collaboration. But if they keep coming up that indicates what are most likely significant underlying problems in the businesses involved.

As an aside here, that might address a point that many readers would have noticed by now, I did not raise the issues of information security or its management as part of either the basic transactional processes under discussion here, or in how exception handling would be carried out. For purposes of this line of discussion, I simply include that into the more generally stated framework that I have been developing here.

And with that perhaps-clarifying note added, and in at least selective summarization of a key point that I have been raising here, I observe that in a business-to-business collaborative context, transactions between organizations and their staff members and managers can break down from any of several possible directions. And this means that the more the exceptions that arise, and of a Type 2 form, as listed above, and certainly from a Type 3 form where they arise, the more important it becomes that effort be made to standardize, or re-standardize how the two halves of these process-based transactions take place, so efforts made on both sides of them fit together more smoothly and efficiently. And with that I directly bring this discussion back to an explicitly business-to-business collaboration focus.

Now let’s consider the people involved in these transactions, starting with what in most cases and for most businesses and transactions would be non-managerial employees who have, for example, specific accounts in their hands and who would primarily if not exclusively focus on carrying out their sides to the Type 1 transactions as discussed above.

• Who does this work and what are their training and supervision requirements for being able to do so?
• Who would they turn to, to report, address and resolve exceptions when and as they arise?
• And which of those (here at least categorically anticipatable exception types would be handled by those same hands-on employees, perhaps with just an acknowledgment of occurrence and a quick authorization to proceed? (There, as a possible case in point example, an exception might mean finding a non-standard but available logistics and delivery solution for shipping and delivering a particularly fragile or perishable product to an unusual location – non-standard but not wildly so.)
• Which and how many of the exceptions that do arise would call for at least a more substantial hand-off to a supervisor and a true process escalation in order for it to be completed? And who would be responsible for carrying out this next step up work: a manager, or a hands-on specialist or who? And how and where would that be decided?
• How would basic workflow numbers and their statistics at the very least, and exceptions as identified by type, be reported in as ongoing due diligence input data?
• And who would be responsible for that? Would they be afforded the time and opportunity to carry out this essentially-documentation work on top of their regular duties, or would this be added onto their required workload and in ways that might make it easy for this not to be managed in as effective and timely a manner as would be wanted and even required?
• How would feedback from this due diligence information gathering and analysis be carried out and by whom?
• And how would the ongoing results of this at-least ideally ongoing review and analysis process flow, be reported back to the people they first arose for so these findings could be made use of? And who would do this and who would they share this information with and how? Who, at least as a matter of level on the table of organization, would develop and institute change as a means to reduce exceptions, and certainly ones that call for escalation to management or to middle or even senior level management? And what feedback would be gathered and from whom, bringing what involved stakeholders into these remediative processes so that any changes that are made are more likely to the right ones and not just sources of new problems in and of themselves?

The three questions that I started this posting with: there still in a more within-business context, and their business collaboration supply chain level counterparts, are mechanism and What oriented. And that is a valid point even as I have of necessity delved into at least a few Who issues when addressing them. The due diligence questions that I raise here, as a continuation of that narrative, are more personnel and Who oriented, even as they in turn of necessity raise mechanism and What issues too. Think of all of this as fitting together into a single due diligence approach, and one that would connect into larger more widely ongoing strategic and operational business review and management systems.

I am going to, as noted above, turn back to the two case study businesses that I began this series progression with, at least starting in my next series installment. And in anticipation of that narrative to come, I will reconsider both of those businesses in light of the issues and topics points and the business practice approaches that I have raised here since first offering them. Meanwhile, you can find this and related postings and series at Business Strategy and Operations – 5, and also at Page 1, Page 2, Page 3 and Page 4 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: