Writing a business process is not always as straightforward as it sounds. One of the possible pitfalls faced by the technical author is that what seems simple in the first instance can turn out to be very complex. A writer who wants to keep things simple must consider the impact of the process on the business as a whole, not just the process in isolation. I will share with you an example from my career and how simple it turned out to be much more complex than it seemed.
Too much control
I worked for a telecommunications company and they decided they wanted to develop an inventory control process for their key product. To keep things “simple”, they decided to register each and every piece of equipment uniquely in their ERP system in order to have maximum oversight of stock control.
Sounds good right? Wrong, this is very simple to implement in system terms (it’s a couple lines of code) and very easy to document (stock goes in, scanned, stock out, scanned). But it is a nightmare to implement.
The level of control was too high; treating each identical item as unique in stock control was a recipe for disaster. Because they were expensive items, the finance team had gotten carried away with their need for data.
Despite the price of the equipment, it was actually worthless until it was connected to our network. Could not connect to another provider’s network (for technical reasons) and we are giving the item “free” as part of our overall connection and fee structure. So anyone who stole one was faced with an expensive electronic cap. So there was no incentive for anyone to take one, and if they did, well, if they wanted to use it, they would have to pay us anyway.
Business impact
However, protecting these zero-value items would be a nightmare. If one was missing, to determine which one, and that would be necessary to balance the ERP system, you would have to scan all the remaining available items. In most weeks, that would mean scanning 20,000 identical boxes to identify which one was missing.
Now, if someone steals a can of Coke from a supermarket, does the supermarket not care which can does it? He just wants to know that he has lost a can of coke.
Best solution
The correct way to have built this process was to treat the items as coke cans in our stock control system. Although each had a unique identifier (to allow its use in a telecommunications network, they must have it), it was better if they all received the same treatment.
Now if one were to go missing you’d know through a quick visual count and how we didn’t particularly care which one was gone (there’s an endless supply of unique identifiers anyway). We would know where the item was lost without identifying it individually.
You get the same monitoring value in the process, as you can figure out where items are missing, but without all the expensive administration required to do so.
A great technical author needs to be able to delve into the processes they are involved in and determine if there is a better solution. What seems simple on the surface may not always be so simple.