I work in government IT, and before that I worked on enterprise workplace management software. I have noticed that when processes get moved into software the people involved in describing the requirements make the same mistakes over and over:
- making the digital process more complicated than the paper process, because the software will simplify the complexity (it does until it doesn’t and then everyone involved needs to figure out the real process anyway)
- assuming correctness of the software (all software has bugs, all digital processes eventually get into a broken state, there should be a way to force the system back into an intuitive “right” state better than some dev running random sql statements on a production database)
- assuming correctness of the software’s users (all people make mistakes, and mistakes happen often, there should be a clean and reliable way to force a process into a state matching reality when someone misclicks, but often the only way is to “lie” to the system and take an odd path through it)
- trying to capture the process end to end in software rules causing it to become set in stone (only the labor intensive parts should be automated, leaving room for flexible adaptation of the process without requiring a new software release)