Process Status - Best Practice (1 Viewer)

[Minty]

I may be answering my own question here but here goes; Over time I've inherited a number of systems that have a "current status" field.

This is handled in two ways depending on the system in use;
Method 1 - A single status field whose value is changed by other processes.
Method 2 - A child record with a status and date of change.

Method 3 - In a new system I recently put together I thought about and have implemented a calculated status based on criteria. This is done through a (pretty complicated) function on SQL server and incorporated into the views used by the system.

I can see obvious pitfalls in the first method as it requires other things to happen in the correct order, however it enforces a process structure.

Method 2 is straightforward, but open to some abuse as any process status can be set at any time. (There is no restriction on what status is set based on current status, maybe there should be?) Simple to maintain though, it's simply a table with a Status ID, StatusText and a Fuller description.

The 3rd method seems the most robust but also the most difficult to maintain, particularly if the business logic starts to get really complex. Additional status's have to be programmed into the existing logic.

My question is really about how other developers handle this? Or do you take it situation on it's merits? Is there another technique I've completely overlooked.

 

[CJ_London]

I think you've covered all the bases. My preference is method 3. If the algorithm is built correctly it is easy to see the current status and if the tables store historical changes the status 10 days or a year ago, or provide a history of changes.

The only time I would consider using a stored status value is if the algorithm is so complex and the dataset so large it slows everything down to an unacceptable level.

I do a lot of stuff where history changes. In accounting for example, last months and YTD accounts are produced (so status is the balance of each account at the end of each month) and then a missing transaction is found relating to that month or earlier (it may have been already entered but with a wrong date or simply not entered by the time the accounts are produced). Depending on the business rules, when the next months accounts are produced, that transaction may be shown in the current month (which shows a wrong position for that month, but shows a correct YTD) or the correct month and the prior months values restated, perhaps with a report of changes. Which way the rule goes depends on what matters to the business.

I have a lot of 'fun' with the calculation of sales commission where status is based on which sales person managed which accounts at the time of a sales transaction and management had forgotten to update an account move when a salesperson left, was on LTS, etc.

 

[Minty]

Thanks for the feedback.
The sales commissions is interesting! I have a commissions report I've been working on in the background. I've taken the quick and dirty approach at the moment, and not recorded who's account was who's over time.
I started drawing it out and thought it was too complicated to manage in the time I had available, I'll have to revisit it when time allows.

 

[CJ_London]

not recorded who's account was who's over time

depends on the rules the commission is based on. A few years ago, one client had 600 sales people generating some 6000 queries a year because they hadn't been paid something - which meant 12000 corrections because commission had been paid to the wrong person and had to be clawed back - salespeople never complain if they are overpaid and if challenged just say they didn't understand the system.

Another client did not provide any breakdown of how the commission is calculated which the sales people just accepted, so could quietly correct behind the scenes.

 

[The_Doc_Man]

To me, there are pitfalls in ANY status system unless you make it a "compound" status for which the components have statuses that contribute to the overall status. The problem with status computations will be how you report them.

For example, look at the "Windows Experience" computation, which gives me a number at about 5.9 for my desktop. If I get it to tell me the details, I learn that if I had a faster disk I would have more like 7.1 or 7.2 on my system. If all I had seen was the 5.9, I wouldn't have learned anything. But by seeing the components, I learned I have a crappy disk and could fix this if I could get a faster disk or get a faster disk bus, something like fiber-channel speeds.

The point to be learned is that if you do some sort of aggregate score, it is still relevant to know WHY it is like it is by showing the next-level-down contributors and then letting you know what is failing, what is borderline, what is excelling, etc.

I'm not at all suggesting you would not already know this, but I thought I might reinforce the "contributing components" option. Which is maybe your 3rd option?

 

[Minty]

Thanks Doc, I'd not thought of making it a compound 'thing', it's literally a "where in the process is it". So for example in our warranty returns process. It (currently) goes through a very simple set of status's;
1. Waiting RMA
2. Waiting Dispatch
3. With Supplier
4. Disputed
5. Processed
6. Closed

This is by far the simplest model, some of our others are quite complex. I would certainly use method 3 for this model, as the status is simple to calculate out.

 

[The_Doc_Man]

You are looking piecemeal; for my systems, we had so many statuses that we HAD to look at them wholesale. We had an average of between 30 and 40 required actions per month for a total of over 1400 servers and had to keep a history of not less than 6 months for all servers both individually and broken out by 60 to 80 projects. We had per-server, per action, per-product, and overall compliance levels for everything we did, available within about 5 seconds for the big reports, less time than that for the small ones.

Our statuses were simple, conceptually. Our findings were closed (any reason), open (pending for any reason), open (overdue with a limited subset of reasons), open (delinquent - one stage later than overdue and permissible only for unusual circumstance), and transferred to special remediation (when it was so delinquent that we had to put it on a special schedule that would be tracked by the big bosses - never a good thing no matter how good the reason was for being overdue.)

For our main reports, statuses were like... 80% closed, 10% open (waiting for scheduled down time), 5% (waiting for vendor release of patches), 5% (mitigation plan submitted)... things like that. So for us, status was actually like a bar chart of specific and/or general statuses. The only REALLY good status was 100% closed. All else led to raised eyebrows - and the non-closed statuses determined how high the eyebrows were raised.