Wait, there's more! I have found a victim within IBM who was nice enough to help me with some functionality testing. This required some queuing around of a test SR. I had opened the SR with the following text:
This is a test of SR. Please do the following: 1. Entitle to the compid chosen (Allocation). 2. Keep it on the queue until the 'documentation' arrives, simulating a dump transfer. 3. Then send to slink,200, attn. <my victim>. For <my victim>, as discussed: 4. Transfer ownership of the PMR to *some* queue somewhere on a BDC node. (Used to be a cr with routing to world trade.) 5. Change your own user so that you appear to work primarily on BDC queues. (IIRC, n;bdc ?) 6. Do an AT with the update "This is AT." 7. cr ca back to me. 8. wait for me to update with 'please close'. 9. close the SR. a) I got lots of junk for my efforts, both in the SR shown and in the email notifications. We are interested in 26 lines, not counting the appropriate signature lines and not counting the 'prologue' that details data customarily shown at the top of the Retain page. SR added 51 lines completely unnecessary, as that information is redundant. Some unavoidable IBM entries (like the amount of commands put in that all have the fingerprint of who-did-it and that contract information stuff) add another 30 lines. The amount of junk makes it VERY HARD for anyone to see what's important and what isn't. ----> Stop adding junk that makes a problem very hard to read. Note that the junk added outnumbers the meaningful stuff quite severely! b) Those 26 lines are the things I would like to see via email notification (I told my helpful victim all about it.) c) I am sent too much junk in the body of the email notification. Again, it is much too hard to see the actual update! ----> Stop giving me so much clutter! d) I am not sent actual updates, just what is put in on cr ca (For those unfamiliar with retain, that is the command that changes the ETR state from IBM to Usee - call requeue customer attention/cr ca). ETR is a LOT better in that regard, and I remember that it took some time for them to get there. They manage to get it right most of the time. ----> If you sent me email, provide me with *all* updates, not just those from cr ca! e) The title lines are not telling me what happened with the PMR. I am certainly NOT told that my SR was closed! ----> Instead of sending me an email that tells me that *I* opened an SR, send me one that explicitly tells me that my SR was *closed*! f) Instead of only the PMR number, the title line should also contain the 'abstract', given that the customer is forced to put one in. For someone with a lot of PMRs, no one wants to remember PMR numbers! ----> Provide the abstract in addition to the PMR number in the email header. 7. The supposed email address should not contain this donotoreply thing! Especially since that is repeated in the body of the email. ----> Make the email address the email comes from something that doesn't sound like a lot of SPAM! (srdonotreply) 8. Accessing 'my notifications' from the website takes forever (around 30 seconds at work over high-speed connection, that's much too slow!) ----> Unusable at oh:dark:30. What are you searching here? 9. Skip the 3 lines that say . The customer has requested this ticket be closed. . And since when has this become a 'ticket'?!? In any other place they call it SR or 'Serviceanforderung' - what a terrible translation! 10. Clicking on a closed SR also gets me the Update window. The submit link has been replaced with 'reopen this'. Any closed PMR should (in the interest of IBMs internal statistics) not get reopened just because someone adds text, which is much too easy when shown an update page instead of a browse page! ----> For closed PMRs, show a browse page with the option to explicitly reopen instead of the update page! 11. On many of our closed PMRs I noticed that SR shows even the FA masks, which obviously appear out-of-timeline in the SR. ETR still follows the rule that I learned that FA masks must not be shown to the customer. (Same for the scratch pad on page 1 of any retain record; FA stands for file alter. Usually nothing in retain can be changed once it is commmited, to have a permanent record of who-did-what-and-when, with the exception of 'file alter masks' that are used for IBM internal administrative tasks). -----> Don't show FA masks! 12. Another thing that annoys me on the searchSR.action page is that despite the clickable search fields being clearly divided in three parts by horizontal lines, those options are ALL applied to any search done. So I really have to check all options, regardless of the box they're found in. ----> That is highly counter-intuitive, the separating lines should not be shown! 13. And finally, that 'archive search' doesn't work as I expect, either. Doing an archive search for all of our PMRs updated during all of 2010 for all priorities (yes, I did click 'include archived') gets me all of 3 PMRs? There were quite a few more, and a few of them my own. Clearly SR does not search the same database that the IBMers search when I ask for reopening of old PMRs. Help text?!? What context-specific help text for that page?!? Best regards, Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
