Business Tech: Degree and Kind

Programming and Analysis are rule-based behaviors. When you program, you are teaching the computer to apply a specific set of rules. When you do analysis, you are testing data against a pre-defined set of rules. When the degree (scale) and kind (approach) change, we have to watch to make sure that our assumptions change as well.

A Kind Thought

When talking to a former U2UG board member one afternoon, in the middle of my explaining a problem he asked me: "Is it a change in degree or in kind?" While I had often thought in kinda/sorta those terms, I had never heard it reduced so effectively to one question. Sometimes the shifts in business are degree — going from twelve locations to thirteen — and sometimes they are more severe — going from direct sales to channel sales — which are changes in kind.

While you might think degree changes are easier, they are not always a simple as we'd like to think. As for kind changes, let's just say they are unkind.

Ware Are You?

Imagine that your company has always warehoused goods at your headquarters because that's the only location you have. Expansion allows you to open a second location which will, in this example, take over 100% of the warehousing. This is a small shift which might require some retooling, but not nearly as problematic as it will be when you say "take over 99%" instead of 100%. Why is that 1% so difficult?

In the original plan, Bin A was always walking distance from Bin B. With one and only one location, you never have a travel barrier to combining items into one package for fulfillment of an order. With one location, you have the option of having a rule which says that all goods of the same type must reside in the same zone. This would certainly make it easier for picking and packing. It would make it easier for inventory control. However, if you have two locations, any given item has two zones, minimum: a zone in the HQ and a zone in the warehouse.

Completing an order for shipment might now require a picker/packer who can drive between bins as walking is no longer possible in many cases. Since we don't want drivers dispatched for each order, we have a planning step that was unneeded in the old (100%) way but needful in the 99% (or lower) case.

Worse, what if the HQ has a special environment, like a freezer vault or a secure room, but the warehouse doesn't have one. Now, most goods have two zones: one at HQ and one at the warehouse. Some goods can only have one zone: HQ.

1 + 1 = 3

As if that were not bad enough, adding a second location automatically requires a third location: in-transit. Imagine doing inventory while goods are being moved to HQ — samples for example — and you count each location: one hundred in the warehouse and zero in HQ. If there are fifteen on the truck, you just under counted by fifteen *unless* you treat the truck(s) as a third location.

If we just think in terms of locations, "one plus one equals three" covers most of our issues. However, we have to look beyond that to the business processes. Let's make the huge assumption that your business has a website and that the site has pictures on it. In the original scope, you had one location: HQ. If you wanted a picture of a product in inventory, you walked through a door from the offices to the embedded warehouse, took the item from the shelf, walked back into your office, and took a picture. Now, with 99% of the products at the warehouse, you either need to move the photographer or schedule shipments of product between locations just for photo ops.

Likewise, if you show products to clients at your headquarters, or if you hand out samples to your sales staff when they come "home" between trips, however you use products beyond simply fulfilling order: all of that needs a rethink.

Kind of Like That

For a change in kind, we have to work even harder. Imagine that your business is product-centric. The edict comes down that you are going to start adding warranty service to your sales mix. To management, service might seem to be just another SKU (Stock Keeping Unit). But to you, and the people who have to manage it, the difference between product and service is huge. Especially when you add the word "warranty" into the conversation.

A brief comparison between the three models should get us on the right track:

1. Product Model:
   Sold in SKUs.
   Restock involves manufacture, import, or purchase.
   Shipping is a factor.
2. Service:
   Sold in SKUs (blocks of time consumed).
   Normal restock is automatic: new days keep arriving for the schedule.
   Expanded restocking requires hiring.
   Scheduling needs to be done.
   Travel is not the same as Shipping.
3. Warranty Service:
   Price is not related to blocks of time consumed. Some warranties will be paid with no requests against them, some will require a great deal of time. Price does not reflect individual usage, it must be aggregated across all sales.
   Scheduling needs to be done, as frequently as needed.
   Warranties may also involve replacement parts — i.e. decreases in inventory without one-for-one increases in payments.
   Travel is still not the same as Shipping.
4. In all cases:
   Might have discounts for multiples being purchased.
   Might have tiered pricing (Distributors vs. Resellers vs. Street price).
   Products might expire, service hours always expire (you can't sell January 2013 hours in February 2013).

This is not an exhaustive list, but it is enough to give you a sense of the issues. Changes in kind are seismic shifts. They require extensive rethinking and detailed planning. Force fitting your existing model might be expedient but you will keep paying for that initial speed throughout the lifetime of your software.

What a Tangled...

A perfect example of a seismic change is adding a web store to your existing sales model. People think a website which sells is just an electronic version of your catalog. Doing things this way — thinking that web is a change in degree instead of seeing it as a change in kind — is going to lead you to a dead end. Why? Two main reasons: (A) because customers use paper differently than they use the web, and (B) they each offer features which the other lacks.

As potential customers, we can easily annotate a paper catalog, circling things of interest and using the — comparatively — infinite space of our physical desk to spread out pages torn from the catalog for comparison. On the web, I can reconfigure my — comparatively — limited screen space to see the products I want to compare side-by-side.

In a catalog, people will often enjoy reading long, rambling exhortations about a product or services. On the web, they expect shorter text with more pictures or white space to break it up. we can keep going one with point-by-point differences, but all you need to do is visit a dozen of the most successful sales sites and then look at a dozen successful catalogs. They each use their medium to best advantage. They do not look the same.

Of course, tablets are starting to blur the line again. Holding a tablet they way I hold I book makes me read sites more like I read books. It sounds stupid, but it is becoming a common experience. You can find people all over that would find reading a book on the computer screen a chore but easily read on a Nook or Kindle.

The Nth Degree

Qualifying a project as degree or kind helps us determine the type of analysis we need to do before making changes. Just knowing how different these two classes of work are helps us manage expectations — those of others and even our own.

Featured:

Jan/Feb 2013