When the Constant Is a Variable

Over the recent holiday weekend, this blog contributor took a road trip through several destinations in New England.  Beautiful weather, even more beautiful scenery and lots of “interesting” driving techniques on the highways.  During various points in the trip, patterns and thoughts about likely causes and effects began to emerge and it became apparent that, like travelers, software in the future will need to handle not only a world of external variables, but that the constant, the user, must also be considered a variable – which makes things far more complex (and fun).

Many aspects of driving involve variable ranges in the conditions of weather, traffic heaviness, the vehicle one is driving or passengers in the car; but the presumed constant is the driver (you’re always you).  The same could be said for procurement software in the sense that there are variable ranges for a host of conditions that dictate how best the procurement process should run at any given time – while the user remains constant.  But, as noted while driving 600+ miles through cities and countryside – the driver (and therefore the software user) is also very much a variable. 

Consider having just packed up the car and heading to the highway in the early hours of a clear morning.  There aren’t many other cars on the road yet, it’s still a bit dark outside and the driver has the luxury of easing into driving mode without much consequence.  A not completely alert driver pulling off a sweater or taking a sip of too-hot coffee could otherwise label her as distracted or dangerous, but at this time with these conditions, it’s fine and easy to adapt.  Consider the more impatient driver who has just pulled out from a rest station several hours later and while merging into much heavier (and aggressive) traffic realizes that the sun glare is blinding and sunglasses must be dug out of the console and put on NOW.  This could be dangerous.  The same driver is not the same driver just as the conditions are not the same conditions.

The business software that we use in the future will need to allow for the fact that there is no consistent user mode in spite of the user being the same person.  A procurement professional developing strategic targets and budget plans for the year ahead may need to draw on patterns of behavior and historical trends to build a model for how the future might look, whereas that very same user will want no distraction of trend reports and market analyses while trying to negotiate a contract with a supplier.  Will the software know which version of the user is at work the system?  If it does, then perhaps it will need to adjust itself dynamically to meet the user’s demands. 

We do this kind of auto-adjustment in regards to other drivers all the time.  We see someone weaving in the lanes, and we assume that person is tired or distracted and take care to get ahead of that car if possible.  If we see excess aggression, speeding, honking, we assume that person is late, having an emergency, has had a bad day, and we are hopefully in a state of mind to back off and let that person be on his or her way so it doesn’t escalate or get dangerous. 

Software might learn how to do this too.  It could learn to react according to cues indicating the internal conditions of the procurement process as well as the external variable conditions being imposed by the user.  The software might then adapt to be more useful and accurately responsive.  In time, software may even teach this to itself based on the feedback we provide.

Image credit: Pixabay