Redefining the Factory

Back in December 2013, I started a series of posts that describe processes and how to manage them.  You can read them herehereherehere, and here.  Go ahead, we’ll wait.

OK, you’re back!

I have had some time to ruminate and use this processing model.  It seems to breed some confusion in my business partners when I discuss it with them.  The problem is my use of “Factory” to describe a core process.  It is so much simpler to just call it a “Core” process.  The definition, the right thing to be doing, still holds but the association is much easier to grasp.

However, we still need the Factory.  The new definition of the Factory is the process flow that emerges as a transaction moves through the core processes.  This is what we in systems analysis call “the happy path”.  Transactions that stay in the Factory make us happy because they process in an efficient and effective manner where variability and risk are controlled.

Experience is a great teacher.  I hope I never grow too old or set in my ways to change.

Knowledge Management: The Other Side of the Enterprise Architecture Coin

I have two passions in my professional career.

The first is Enterprise Architecture (EA). I have been interested in this subject for the past thirty years. This passion started when I designed a system supporting the risk analysis and decision support requirements for an insurance enterprise. As I have continued my career, I realized that architecture had more to do than just with systems. It needed to understand the business and processes supported by those systems.

My other passion is Knowledge Management (KM). I became interested in this subject in the early 1990s when the ideas began to emege within the business and technology communities about the necessity to preserve the knowledge in the heads of the baby-boom generation as they began to retire. We are now about 25% of the way through that wave of retirements. How is your knowledge management program working?

Rather that being torn over which of these passions to pursue or spending only half of my time on either, I have determined that EA and KM are two sides to the same coin. It is my belief that in order for an EA program to look forward and take the enterprise into the future, it must be built upon a foundation of understanding the enterprise’s current state and how it got to be there. This requires a comprehensive knowledge management program.

I have also determine that EA and KM must be integrated. This is because EA relies on existing knowledge that has been preserved and managed in order to understand how to move forward and the act of moving forward creates new knowledge that must be preserved and managed. Unless these two activities are tightly integrated, there exists the probability that the KM knowledge base will grow further and further out of synch with the reality of the enterprise as it progresses. This then inhibits the EA function’s ability to utilize up-to-date knowledge as the enterprise makes new moves forward.

I plan to write a new set of essays about how EA and KM feed each other and how they can achieve the level of integration required to make them two sides of the same coin. Please look for them in the coming months.

The Business Calendar

Every living being has an internal clock that wants to regulate its habitual patterns. It’s called the circadian rhythm. We humans are much healthier when we allow our circadian rhythms to regulate how we live each day. Usually, we use use artificial means to awaken us earlier (e.g. alarm clocks) and stay up later (e.g. stimulants) which serves to make our bodies work less effectively because we have thrown them out-of-rhythm.

Many animals also have a circadian-like calendar that helps them manage from one year to the next. Their bodies read the changing seasons and tell them to gather food, go into hibernation, and awaken the next year. Enterprises also develop a natural annual rhythm that I call the Business Calendar.

Every Enterprise should develop, publish, and understand its business calendar. For most Enterprises, the calendar should focus on the Production Schedule. Production Schedules are easy for manufacturing concerns because that’s what they use to run the shop. They might not be so easy for service concerns because they view things more like a job shop than as a factory shop.  However, recognizing your Enterprise’s ability to be distracted by non-production work is very important regardless of the type of business in which you engage.

The Business Calendar should consider the following factors:

  • The capacity of each department to accept non-production support work through out the year.  This should be measured against the permanent staffing levels approved for each department.
  • The time boxes imposed by mandatory retooling work.  Retooling is work that must be completed to allow the factory process to handle requirements stemming from law, regulation, or priority changes.  This work generally has a firm date for when it must be completed and added to the factory process.
  • The time boxes imposed by peak processing loads when factory process stability is paramount.  It is generally not a good idea to destabilize your factory process during peak season.  You must also make sure you have a matching non-production environment in which you can troubleshoot problems in production.

Exception Processes

Exception Processes happen whenever an enterprise has to process a transaction that can’t be handled by its Factory Process. The usual culprit is that the submitter of the transaction (e.g. customer, taxpayer, etc) does so in a fashion that is not handled in the Factory Process.

In this previous post, I described several situations where this could occur and why. The next decision for the enterprise is what they’re going to do.

Acquiescing to unruly customer behavior may be the path of least resistance but that’s not helping your enterprise maximize its profits. The Factory Process is in place because it’s the least expensive way to process the transaction. Anything else you do will only drive costs upward.

In the prior post, I described real reasons why customer could not conform. In those cases and due to the high volume of transactions, a permanent exception process needs to be implemented. The alternative is to forego the revenue.

However, the enterprise has a worthy goal to eliminate these exception processes. This is done using a customer education campaign and fees for continued unruly behavior.

The education campaign should be applied first. Tell your customers how their unruly behavior drives up costs and therefore prices. Describe the systems you have put in place that allows them to access the Factory Process and help them convert to using them.

Next, consider eliminating stimuli that encourage unruly behavior. Get rid of the return coupons from your statements, including those on the statements you email to them. Place the URL for your payment website prominently of your billing correspondence. This will discourage paper check payments and encourage electronic check payments.

The next step in changing customer behavior might be to introduce fees for unruly behavior or discounts for desired behavior.

Exceptions to Exceptions (Revisited)

The problem with writing and publishing from a stream of consciousness is that sometimes you say things you might want to reconsider.  I have been thinking about my statement in the last post that exceptions to exceptions are illogical.  Consider the following…

An enterprise decides that its factory process is that it will conduct its business with its customers electronically.  Say the enterprise is a utility company.  It emails the monthly bills to every customer and includes a link to its electronic payment website.  This makes it simple for the customers to comply with the utility’s wishes.  Or does it?

Assume that every customer can receive the bill.  That doesn’t mean that every customer has the ability to pay electronically because not every customer may have a bank account or payment card.  Then there is that group of unruly customers who just refuse to make electronic payments.  Assume that these groups comprise a number large enough that failure to accommodate their needs will severely hamper collections of revenue necessary to keep the enterprise going.

The enterprise now has an exception process that must process old-fashioned payments where the customer returns a coupon or remittance advice with a paper check.  Since the volume is significant, the utility must have a reasonably efficient process to minimize costs.  So a factory process is set up to efficiently process paper coupons and checks.  It starts with the utility including a remittance coupon that the customer can print and return with his check.

The rest of the process can be built either by investing in the process or outsourcing to a lockbox operation.  The factory-compliant transaction is where the coupon and check arrive together and the check amount matches the amount that was billed.  These transactions flow right through the new factory process for the exception process.  The output from this process should resemble an electronic payment so that it can be submitted to the enterprise factory process immediately upon completion.

What can go wrong now?  We now have the following three exceptions to the exception:

  • Only the check arrives
  • Only the coupon arrives
  • The amount on the check doesn’t match the amount on the billing coupon

So what’s the lesson here?  It is that there should exist factory processes within exception processes where the incidence of exception is going to be very high and the enterprise has little way to control customer behavior.  These factory processes should be managed just like the enterprise factory process in order to maximize efficiency and minimize costs.  The output from this exception process should reenter the enterprise factory process as quickly as possible.  But there are also exceptions to be encountered that the exception factory process can’t handle.  These should be managed at the department level just like exceptions to the enterprise factory process are managed at the enterprise level.

The Three Process Types

Processes are sets of activities that have some level of definition and standardization about them.  The Enterprise runs using three types of processes.  These are Factory, Safeguard, and Exception.

The Factory Process is that process that implements the essence of the business. These activities are the “right” things to be doing.  We have previously referred to them as the “things we’re supposed to do”.  It is the core competency and operates at the highest efficiency and velocity.  Every step of the Factory Process is standard and should be automated to the highest extent possible. The Enterprise wants to push all transaction activity through it. This is the path for transactions from Customers who “play by the rules” of the game as the Enterprise wants it played.  This should encompass the majority of the transactions processed by the Enterprise.

The Factory Process must be protected by Safeguard processes to ensure it is not being abused.  These activities ensure that you are doing the “right” things right.  The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems.  (e.g. Processing fraudulent transactions can cause money to leave the Enterprise with no hope of recovering it.)  Business-driven Enterprise Architecture and Internal Audit are examples of Safeguard processes.

Transactions that don’t conform to the Factory Process are Exceptions and run through Exception Processes.  In many cases, these are the activities that we have labeled the “things we really do”. Exceptions should only spawn from unruly Customer behavior.  If behavior within the Enterprise dictates a change, adjust the Factory Process or change the behavior back to that which conforms to the existing Factory Process.   The degree of automation for Exception Processes is thus dictated by the Enterprise’s ability to control or influence this unruly Customer behavior.  (e.g. Most Customers will need Customer Service at some point in your relationship to them and unless you are in the Customer Servicing business, it is an Exception Process.  There is always some level of Customer Service that can be automated and some level that shouldn’t be.  Perhaps the former set of activities should be considered Safeguard processes because they help the Customer play the game correctly.  The latter set is for those Customers who just demand more attention.  Understand the difference.)

The goal should always be to correct the exceptional nature of the transaction and then get it back into the Factory Process.  The idea of running a parallel process that handles the exception differently all the way through its lifecycle is both inefficient and ineffective.

The idea of an Exception to an Exception is illogical.  It is just another more obscure exception that has many of the same traits as some other exception.

You Don’t Need to Develop an Enterprise Architecture

If you work for an existing enterprise that has processes and systems in place, you don’t need to create an enterprise architecture. You need to understand the one you already have.

The primary reason Enterprise Architecture programs fail is because the Architects are focused on something other than the reality of the business today.  Business Leaders are fine with strategic planning but they are more interested in running the business day-to-day so they can survive to the future.  Many Architects appear to want to create a “big bang” project to introduce a new future state.  Business Leaders understand there is less risk in morphing a business from its current state to a future state.

An Enterprise Architecture plan certainly is concerned with moving the enterprise to a future state. But in order to be successful, it is equally important to completely understand the enterprise’s current state.  Think of the plan as a roadmap to the future.  Think of your understanding of the current state as being the sign post – “You Are Here”.

Don’t Fire the Person Who Told You How to Eliminate their Job

The scariest thing workers face in a business process re-engineering project is the prospect that their jobs will be eliminated. The current economic climate makes this particularly scary because the prospects for them to find another job are not good.  However, the BPR analyst needs to have complete understanding of the current process and the expert sources of the required information may think they are the least incentivized people to provide it.  They do not want to help you eliminate or change their jobs when they know their next stop could be unemployment.

The incumbents in any job are the recognized experts in the current process.  They know why things are done and they often know ways to eliminate work.  They don’t speak up for two reasons: no one asked them and they are uncertain of the repercussions.

So ask them!  Find out what they do and why.  Once you ask them, they’ll probably tell you everything you want to know.  The important thing is to focus solely on the work they do and not on redesigning the process in front of them.  It is fair to ask them how they would improve things.  Make sure the current process and any suggestions for improvement are well documented.  Make sure you know who contributed what information.

Let’s fast forward to the end of the project when a new process that eliminates unnecessary steps is implemented.  If there are job eliminations, it is imperative that you not lose the people who were instrumental in helping you design and implement the new process.  I have two reasons for this position:

  1. Eliminating people who helped the enterprise improve itself sends a bad message to the remaining employees both inside and outside the affected area that helping is a bad idea.
  2. The enterprise loses a valuable resource who is willing to place the future of the enterprise above their own needs.  Enterprises need more loyalty these days, not less.

A better approach would be to find another job for the most helpful workers and to include a bonus or a raise in the transition.  You should also tell them that should they figure out how to better do their new job, that you’d do the same thing all over again.  In other words, show them they will be rewarded every time they help the enterprise improve.

So, we’re keeping the people whose jobs we eliminated because they helped us.  But in order to realize the savings of the process improvement, we need to eliminate some people.  I would start that process by looking up the chain of command for the manager who knew or should have known how to do it and never did.  This is a person who is costing the enterprise more than the value provided.

What We’re Suppose to Do versus What We Do (Part II)

My observation is that business people seldom know what they’re supposed to do. They think they are doing what they’re supposed to do and they are experts on what they do. Being experts gives them comfort and meaning. The extra work they have added to the essential process gives them a sense of job security whether they do the actual work or manage the people who do. Any threat of changing what they do will rob them of that comfort and security.

The most productive thing an Enterprise Architect or other business process improvement facilitator can do when working with line-of-business people is to let them describe and defend their current process. They want to tell you how expert they are. The facilitator is there to facilitate the extraction of information, not to impose a solution. The information provided by the business “experts” will serve to map the current state of the process and will also provide important information about the problems that prevented them from attaining an ideal process state in the first place.

Formulation of a future state based on what we’re supposed to do starts as a backroom exercise using the essential requirements gathered at the enterprise level and the business rules dictated by them. Arriving at the appropriate future state will be an iterative process but it is essential that the first iteration be as bare-bones as possible.

The future state model is refined using “gap” analysis. Most people think the product of gap analysis is to create things that fill in the gaps between the current and future states. That works fine if the future state is “bigger” than the current. However, you must eliminate gaps when the future state is “smaller” than the current. The information provided by the business “experts” is used to determine whether an extra process is extraneous or more essential than first believed. Once you have filled/eliminated all of the gaps, it’s time to review the new process with senior line management. This may also be iterative but you must keep iterations to a minimum. Line management must be aware and buy into all changes before they are reviewed by the “experts”. You will need the managers to help persuade the experts that life will continue after the process they love so dearly changes.

The final set of iterations involves the business “experts”. This will be a highly charged set of sessions because the stakes are high for people who derive their worth from processes you think can be eliminated. If you have done your work correctly, it will be evident that unnecessary activities can really be eliminated.

What We’re Suppose to Do versus What We Do (Part I)

Unless you are an artisan, the best way to do something in your business is to make it efficient and repeatable. Artisans thrive on the unique and exceptional. That’s too expensive for everyone else.

Let’s borrow two terms from manufacturing:

  • Factory Process, generally called a continuous process, is noted for repeatability, large scale, speed, and efficiency. Consistent inputs go in and are processed the same way everytime before coming out as a uniform result. Rigor is built into the process so it is as simple as it can be.
  • Job Process is noted for uniqueness, small scale, indeterminate timeframes, and inefficiency. Inconsistent inputs go in and are processed different ways resulting in inconsistent outputs. The more rigor we attempt to place on the process, the more complex it is.

Most enterprises are riddled with job shop processes. Just try to model any process in your business as an essential string of events and your business people will start telling you why it’s not like that in the real world and how they really do it. I have a name for both: “what we’re supposed to do” and “what we do”.

“What we’re supposed to do” is really very straight-forward. When given a fresh look, business processes can be based on a very succinct set of requirements. It often represents a new way of doing something that has become enabled because we are doing something upstream better or we are leveraging a new technology.

“What we do” evolved because it’s what we’ve always done. It doesn’t take into account only the essential requirements but rather all of the exceptions that have appeared, been nurtured, and then institutionalized over the years. It also doesn’t leverage any efficiencies made available by upstream changes or technology. It can often impose obstacles on the upstream improvements and it only uses technology so more of it can be done faster.

“What we’re supposed to do” is as close to a factory process as we can make it. “What we do” is a job shop process. We’ll look into this more next time.