How to get Service Requests done?

Hi,

It's gotten so hard to keep track of the SR's that I have filed, I have started keeping my own list of them.  In that list, I currently have 55 SRs for Microstation CE, and that is before I have started using it for production.  I can still only use Mstn CE for minor parts of production, due to "defects".  Of those 55 SRs, I have only one that I have confirmed is fixed, and one (and a repeat) that is half-way fixed.  I have more that I have not taken the time to file yet...

I have a SR from November 2016 (almost three years ago) that still is not fixed.  I have multiple SRs from August, September, and October of 2018, that still are not fixed.  I also just check something--the open file dialog box does not maintain its position if you toggle Microstation CE U13 from maximized to un-maximized.  I reported that in the first beta test that came out, which was over 14 versions ago, and over five years ago, and its still not fixed.

We are paying for an operational software program.  Every year, we are also paying for support on this product.  When we find a defect in the product, what do you consider a reasonable amount of time to get that defect fixed?   To me, a couple months is reasonable.  Six months is a long time.  A year is about the absolute maximum... 

How do I get Service Requests and Defect Reports addressed and fixed in a reasonable time?

--Thanks,
--Robert Arnold

P.S. I am caught in a dilemma... Filing SR's, for the most part, is a waste of time--they never get done.  Not filing SRs, almost guarantees that they don't get done.  Which do I do--waste time getting Defect Reports filed, or give up?

  • Hi Robert,

    I can understand your frustration. We are grateful for the effort that you and other users make to file SRs, your time is not wasted. SRs can identify and describe (that is the critical part!) problems that we may not otherwise encounter and when they result of defects or enhancements being filed contribute to the prioritisation of fixes. A defect or enhancement linked to multiple SRs has higher visibility when development priorities are set (like everyone else we have to prioritise...).

    Marc

  • Bentley is going to prioritize any reports depending on severity. Crashing bugs they can duplicate will probably get fixed most quickly. Crashers that happen infrequently or are hard to reproduce are going to take longer.

    Issues that aren't bugs at all but are just "i prefer the program to operate this way" will have very low priority and may never get fixed. These issues are most likely priortized by the number of people requesting the same thing.

    "the open file dialog box does not maintain its position if you toggle Microstation CE U13 from maximized to un-maximized" - this isn't a bug, it's an annoyance, and if my guess is correct, you're the only person to ever report this. It does not surprise me it's never been changed. I also tested this in Word and it appears to act exactly like MicroStation CE, so this may not even be a Bentley issue but a Microsoft OS issue.

    Issues in between, not crashers but not just annoyances but actually affect workflow, it helps to have a good explanation of what your workflow is (or what you want it to be) and why. Explaining your problem is way more important that describing what you think the fix is. "We can't work as efficiently because x, y, z" gets more attention than "add these commands for us, thanks"

    a list of things I like to do when i send in reports:

    Crashers/bugs:

    • Explanation of steps that caused issue
    • If it only occurs with certain files, provide copies of said files
    • If memory dumps occur provide them (not sure if Bentley wants these on initial report or only on request)
    Workflow/Command Requests/Features:
    • Problem description (not fix suggestions, yet)
    • Explanation of why it's a problem
    • Your idea for a fix
    It would be nice to hear from Bentley if this sounds accurate.

     

  • Hi Marc,

    your time is not wasted

    But it's exactly how it looks like from outside: Bentley are wasting time of users like Robert and others. All my users (who have not migrated to competitive platforms yet) stopped to create Service Tickets, because there was zero reaction/response on them and the most of issues, when answered, have remained unsolved.

    Bentley are probably the worst example how to communicate with users and how to (not) build loyal user community. My experience from several others communities (so I do not use it as "it's everywhere" answer), both commercial products and open-source, is that constant communication channel (typically blogs, which seems to be taboo in Bentley) is crucial part of community management strategy and explanations of quality assurance and quality control strategies are shared with users and enhancements are benchmarked in proper way and also shared. It's really about marketing and making users happier, it does not tell anything about internal processes and product real quality ... but users see that something is happening.

    With regards,

      Jan

  • Yea, your time has no value. I'm following you around with this, I keep my own list, post/search issue, file SRs, but SRs are long and painful, some go unanswered, many are not reproducible, very few are resolved, I've all but given up. I have one from 2012 (MS_REF_NEWLEVELDISPLAY) that's very troublesome, never solved, but it is closed, we gave up I guess.

    Connect r17 10.17.2.61 self-employed-Unpaid Beta tester for Bentley