Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
BFrumolt

Senior Member
Registered:
Posts: 84
Reply with quote  #1 

It seems like Support is far less responsive under OpenText than it was under Metastorm.  We opened a ticket one week ago today, and never heard back.  We called to follow up twice - the first time we got the promise of a callback which never happened, and the second time were sent to voicemail.

Is anyone else finding OpenText support to be a challenge?  We're curious, as we are on 7 and considering the migration to 9. Given the cost in time and effort, it makes sense to look around at other options, like K2, before committing - and so far the support experience is not discouraging us from doing just that.

I'd be interested in hearing whether anyone has had particularly good or bad luck with Support recently.

Thanks!
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #2 
Well, we've had extensive experience of support over the last 12 years. It definitely picked up about five years ago. One of our problems was always that we were not 'recognised' and often had to fight just to get support at all for our customers. Thankfully the elements that caused that kind of nonsense have since been 'removed' (and under something of a cloud, we are given to understand).

We have had decent support, but that may be because I know a few of the people fairly high up in the organisation quite well, and can pull a string or two when we are obviously getting nowhere. My greatest problem has often been knowing more about the product than the support team, and pushing the issue towards the cause of the problem rather than being given the usual 'is it plugged in?' responses (I exaggerate, but you get the idea).

On to the current OpenText model. As far as I can tell, even though OpenText have now (quite recently) taken over full management of Metastorm, the people and model seem very much the same. I suspect it will be absorbed into the OT model in full, although now they have a 'BPS' support team for all the Metastorm BPM / Provision stuff as well as Global 360 and OT BPM.

We do get about the same level of support now, and it has been adequate. For certain high profile customers in need, we have had exemplary support too, which has been very welcome indeed. We have pushed extremely hard to get that, in my opinion. To do this, no 'internal' strings were pulled, but we relied heavily on influence from the 'new' OpenText team here in Australia. They are new to the Metastorm operation, and as far as I can tell, were not entirely happy with the way we (and others, I believe) had been supported out here in the antipodes previously. We obviously had a full history of issues and problems to explain what had been happening, eg the migration from 6 to 7 failing completely, and needing manual intervention by us with very little support over 6 months.

So, in conclusion, I would lean heavily on your local OpenText team, and that includes the sales and marketing team. Previously, IMO, the S&M team from Metastorm cared not a jot about support, but that has changed markedly. OpenText seem to understand that you cannot sell a product and not provide decent support. Long may that attitude continue.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
BFrumolt

Senior Member
Registered:
Posts: 84
Reply with quote  #3 

Thanks Jerome, I appreciate the feedback.  Can't say my review would be as positive at this point, but it's good to know decent service is at least possible - our experience might just be an isolated case.

Thanks,

-- Brian
0
BMellert

Guru
Registered:
Posts: 688
Reply with quote  #4 
I have no complaints about support in general, and we don't have (or at least haven't tried to make too much use of) "higher up" connections.  I've generally been contacted the same day (or next morning if I raised a ticket late in the day).  I have taken to raising tickets online or via email, but that is most so I know the information is entered correctly as on a couple of occasions the "telephone" came into play when raising a call via phone with the 1st level support as they take the call, make notes, and forward along.  (Back in the Metastorm days, the person I spoke to was a support person, so at least the information got relayed correctly even if they could not help directly themselves.  The new approach I have the impression is that 1st level is a call logger / forward only with little production knowledge -- though with so many products I guess they couldn't know too many to provide direct support.)
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #5 
Well, one year on and I can state that things have gone back to the way they were. Maybe we just needed too much support (the migration functionality was farcical). We have done a hell of a lot of testing for them, though. I have to admit there is a lot more I just didn't bother with. I purely logged it do demonstrate the reason I was logging time on behalf of the customer. Things I could reproduce with full example, OT could not. I'll log these here when I get time.

I did have quite a serious go at one point, but never got a reply. My take on it to them was:
Quote:

1. I imagine that it should be possible to manage the support process better. In almost every instance (and as you may know, there have been many recently), I have been asked for the name of the customer, the version being used, sometimes the drivers used, etc. I must admit that this is the first time I have been asked what the actual Product is, however, despite submitting the initial report with a fully detailed sample file, from which it should be easy to determine the product. In every case the answers have been the same, but I have had to reiterate them.

If I had to manage this, I would provide the support technician with a profile of the person/organisation submitting the request, which could easily include the details of the environment(s), and list all previous tickets, especially those still open. This would save everybody concerned a great deal of time. I am sure you can imagine what software tool I might use to build such a system (and I actually have built a similar system with exactly those goals). [Note: this seems to be possible in the OT system, but we have not tried this yet]

2. In most instances,  my support requests have been answered by completely different people. Whilst I understand that the organisation is large, and workloads are varied and must be balanced, I do feel that limiting requests from one source to a much smaller group of people would reduce your own workloads, and definitely improve customer satisfaction. As it is, I often have to go through whole sequences of Q & A that could be circumvented merely by the support technician being at least vaguely familiar with our situation and level of experience. [Note: this did seem to get fixed - we dealt with two or three mostly after that]

3. [not relevant, customer specific]

4. This situation is now extremely urgent. We have had an embarrassingly long sequence of failures and faults to contend with in this upgrade from 6 to 9, and it goes back about 3 years. Version 7 migration failed. The fix to that failed too, and we had to do this manually ourselves. Version 9 migration failed in both systems. We have had to do all of that manually (with help from Development, which we do appreciate), and it is not a simple matter. The version 9 file migration has had several interesting faults causing errors and additional work. Version 9.1 has had a wide range of faults, and you have persuaded us to go with 9.3. When we try out 9.3.0.1 that you tell us has fixed these issues, we discover a serious fatal fault almost immediately, although it did take us some time to identify it from the (once again) almost completely useless error message. [Note: this is the getemailaddresses which fails in Oracle. This is fixed in a later hotfix, I noticed, even thouugh OT have never admitted being able to reprodcue it. It may be due to backslashes in the user names]

5. The level of testing does not appear to be adequate from our, nor our customers', perspectives. We have reported a significant number of faults that have been introduced into version releases and hotfixes over the last few months. We have offered to provide testing resources, as we have a wide range of applications and environments we can use to test releases. I have been told that OpenText feel they cannot afford this, but I feel the need to point out again that if this is true, I feel that OpenText cannot afford NOT to increase the level of testing of new releases of this product. The cost benefit analysis should be very simple: Fewer faults means fewer support tickets being opened. That is even before intangibles such as customer satisfaction and market reputation are considered.

6. Error reporting in version 9 needs a serious overhaul. In version 7 we finally had a decent level of error reporting, although there were still a few oddities and we learned to recognise them. When version 9.0 was introduced in 2009, we were prepared to accept a little gap in the fault reporting. Unfortunately, the gap has not been closed at all in nearly 4 years. I almost never get a report that identifies the source of the problem. Once again, the cost benefit analysis should be very simple, as it is the same as noted above.[Note: this still not fixed, and it is the major cause of our dissatisfaction with the product]


__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
BMellert

Guru
Registered:
Posts: 688
Reply with quote  #6 
We are getting great response to a particular issue (V9 performance times vs V7) right now.  We have a couple of other tickets that are crawling along with limited feedback.  I agree its mixed.


I have to whole heartedly agree on #6 in particular, though the others as well.  I've tried to add try/catch messages just about everywhere, meaning I used Code Activity instead of Visual Scripting, I can think of to help trap messages.  Alas, that still doesn't help much when it doesn't occur in a code script.

If the Designer identifies an error while deploying (not validating, though sometimes there too) ... there is absolutely no way to know why, but to try to start undoing (commenting) more recent changes until it deploys again.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!