> Apparently you expect the user to serve the process and not the other way around.
One of the ways to classify process control is by degrees of freedom: closed-loop, semi-closed-loop, open-loop. Anything but closed-loop processes require users to serve the process. That's by definition and there is no way to escape that fully. Sometimes you can make manual state adjustments to the process, sometimes you can "correct" aggregated data fed to outer process, sometimes you can't do anything about it.
In SCL/OL user is the oracle. Every business process management system (ERP) will be at least as complex as the process it models. The more generic the system, the less context-aware it is and thus typically the more complex.
You can pretend that SCL/OL control system should try and infer things to help users, but in fact that impedes correctness, because users are less likely to enter purposefully wrong value (mental default or validation-passing gibberish) than they are likely to agree with prefilled default value despite it being somewhat incorrect. Especially if the inferred default value is usually mostly correct.
A very crude example. Think of e.g. compass based boat steering control system. It will need occasional course correcting input to account for wind/current drift. Suppose you implement periodic prompt for course correction. Empty prompt will be more likely be filled with non-zero value. Default zero value will be more likely to be accepted unmodified, resulting in more jaggy course.
I don't think we are really in disagreement here, but you are talking about steering the cart through the aisle and I'm talking about taking home groceries. If your steering process is hindering my taking home groceries, I will ignore the cart.
Less farcical, you are talking about means, I am talking about ends. Ask yourself what a successful organization needs to take care of.
On the topic of forcing users (ie. require) to adhere to the process you better have a good explanation why the process requires hindering the user in completing the task at hand. I know there exist good reasons why we ask users to jump through this hoop or that, but we need to make sure the user knows these reasons and sees why they are not a hindrance in completing the task but part of the completed task.
> you are talking about means, I am talking about ends.
You see, these things are not necessarily separate, but many people fail to understand that. Continuing shopping analogy, imagine shop sells some candies in multiple flavors. Do you need to weigh them separately when customer takes multiple flavors? The process requires you to weigh them separately. Nothing wrong will happen if you don't. Although, eventually managers will resupply you with a single flavor.
> but we need to make sure the user knows these reasons and sees why they are not a hindrance in completing the task but part of the completed task.
So what's the task at hand? Is it to simply sell candies to customer or maybe keep shop operational, properly stocked and then sell candies? For the shopkeeper the process may seem to start at customer entry and end at customer paying. For the shop that is just part of a grander process.
It seems to me that you argue for single-person scoped processes to be treated as standalone and microoptimized, regardless of how that fits into master process. I try to argue that it is the master process you have to care about.
One of the ways to classify process control is by degrees of freedom: closed-loop, semi-closed-loop, open-loop. Anything but closed-loop processes require users to serve the process. That's by definition and there is no way to escape that fully. Sometimes you can make manual state adjustments to the process, sometimes you can "correct" aggregated data fed to outer process, sometimes you can't do anything about it.
In SCL/OL user is the oracle. Every business process management system (ERP) will be at least as complex as the process it models. The more generic the system, the less context-aware it is and thus typically the more complex.
You can pretend that SCL/OL control system should try and infer things to help users, but in fact that impedes correctness, because users are less likely to enter purposefully wrong value (mental default or validation-passing gibberish) than they are likely to agree with prefilled default value despite it being somewhat incorrect. Especially if the inferred default value is usually mostly correct.
A very crude example. Think of e.g. compass based boat steering control system. It will need occasional course correcting input to account for wind/current drift. Suppose you implement periodic prompt for course correction. Empty prompt will be more likely be filled with non-zero value. Default zero value will be more likely to be accepted unmodified, resulting in more jaggy course.