Do you have Baan Support Contract? Yes/No

We have been running our Baan IV shop since November of last year with no Baan Support contract. I am mildly surprised that we have been able to handle all of the issues in house so far but more than once we have turned down new projects because it seemed too risky to do without Baan Support in some fashion.

I am trying to convince our IT manager that we are better with it than with out it but he thinks since we don't have it for so long it is a luxury.

Any thoughts?

Hi Wricks,

up to now, all of our customers still have a support contract. Some are considering (I think) to stop this, but in my opinion this is not a good idea.

Even if everything is fine, two simple technical reasons should be enough to keep a support contract:

a) You might be forced by your database vendor to migrate to a higher version and together with this you might need a new portingset for Baan. Without a support contract, no new portingset (at least legally).

b) if your server crashes and you are forced to restore your installation from backup on a new server, then you will need to validate your system again. Legally in my opinion you are entitled to get this done by SSA without a support contract, but you will not have the leisure to fight this out in court.


Maybe somebody has practical experience with scenario (b) and can tell us, how they handled it?

Regards

Markus

...up to now, all of our customers still have a support contract. Some are considering (I think) to stop this, but in my opinion this is not a good idea...

I think this queation will be asked more and more. Our own situation is that we have had BaanIV installed for 7 years and have had very little need to call on Baan support over that period. We have upgraded the hardware significantly over the period but we stopped applying software updates years ago when baan's future was in doubt.

Given that we have had very little need for support our support costs are considered by management to be very high. The main reason that we have continued to pay the fees is to entitle us to free version upgrade should we decide to stay with Baan. However, if there are significant charges by SSA for conversion servcies we may decide to move to alternative software.

Maybe somebody has practical experience with scenario (b) and can tell us, how they handled it?

I *think* SSA would view a request to re-license without a support contract as a chargable use of their professional services.

I *think* SSA would view a request to re-license without a support contract as a chargable use of their professional services.

I agree P Cole. Whether or not this would be the actual legal position would depend to a large extent under which (country/state) law is specified to be used to to interpret the orignal contract. In any event I think it would not be unreasonable to pay for the service should it be required so long as the service was not charged at a ridiculous price.

We recently had to have our system relicenced following hardware failure which occurred over a holiday weekend. SSA were very good and and went out of their way to help us over the weekend even though we only pay for 9 to 5pm business day/hour support.

This is a marked improvement over the previously stated Baan position regarding out of hours relicencing. Several years back we sought details from Baan on how we would approach relicencing out-of-hours for our Disaster-Recovery-Plan (contact tel numbers etc). Baan's answer was that this would not be possible unless we increased our support level/cost to cover this possibility. (I cannot understand how/why this baan-era manager still has his job)

We were very pleased with SSA/Baan's cooperation and eagerness to assit us, particularly as this happened over the holiday weekend. Having said this I think it would be unrealistic to rely on SSA to relicence a system where no support fees are paid.

It is advisable to have a support contract in place always.

It is advisable to have a support contract in india becoz here every year we face a lot of localization changes/enhancement.

Regards

The company I worked for at the time ran Triton 2.0 on a BISAM database and life was good ;)

For those of you who can remember the release of 3.0, it affirmed our believes that we didn't need no stinkin' upgrades and we didn't need no stinkin' support.

If it hadn't been for Y2K, this company would probably still be peddling along merrily on the best Baan version ever.

There are currently plenty of companies out there who own their source and therefore forfit support. I am sure they are still able to replace CPU's if needed.

Baan support is a greater service than just revalidation in case of disaster.
Broadly the support service can be categorised as having following elements.
1. Revalidation service
2. Service pack upgrade and version upgrade
3. Knowledge base and documentation access
4. Customer issue and bug fixing

A good value concious organization would consider all components of any service and put
reasonable value to each components of the support service.

Legally speaking SSA or for that matter any vendor who has sold perpetual license to use the software can never deny the revalidation merely because the customer in not having the support. Refusal to revalidate the customer is illegal in any country because it is anti-trust unfair trade practice. However it's unfair to ask SSA to do this service for free. So in order to have a win-win situation , SSA should severe this service from normal support aggreement and can have separate annual reasonable recurring validations service charge with a provision for additional nominal fixed charge per actual revalidation request. Even at 2% of original support charges it's 'zero cost infinite returns' proposition for SSA.

Customer has limited remedy in case such servered re-validation service is refused and he/she does not want full fledged support contract . One can have brand file and ttiex300/301 table backups properly copied in binary mode and stored at secure place and have the baan run from these data/files incase of disaster. Refusal to severe revalidation service is itself is an indication of little value proposition in overall support service . Clubbing separate service to sell other service is clearly untenable. Remember Microsft shipping IE compulsorily with desktops .....

For service pack upgrades , one must think how beneficial the service packs are from technological perspective.e.g AFS and webtops are the contributions of service packs. If there is feeling that new service packs dont have any technological enhancements and are mere bug-fixing , a low value should be put against it . As far as version upgrade is considered , one must consider the time,money and effort
involved in version upgrade and the probable benefits of the version upgrade. For version upgrade, it's better to involve functional managers also in such exercise. A hard look at the realistic possibility of upgrading ur organization to next version , should be made.

For knowledge base and documentation help, one can review the quality of new solutions published during the year, availability and quality of quick guides , quality & speed of the knowledge base search engine etc and put a subjective assessment of this service. In same manner customer issues and bug fixing can be assessed on the basis of their knowledge level , solution turnaround time , level of professionalism in support staff etc .

There is also endorsement aspect to vendor's existing policies and actions like acquisition of disparate systems,quality of such products/systems and how those things may fit in ur organization in future at what price. One can check / assess how does ur organization fit with such activities and products.

Further the cost of selling when selling to existing customers is very negligible as compared to selling to new customer which goes upto 15-20 %. So the customer should also reap certain benefits of low cost of selling by way of rebates.

Furhter per seat license prices have reduced since 2003 and those new customers wont pay as high amc as the old ones . So there is strong case for giving old customers the advantage of their loyaltu and contribution to building strong products.

In nutshell , one should not be solely guided by the % AMC mentioned in the SSA contract . One should try to do independent assessment of all such relevant factors. There should be sufficient value propositions for ur organization for all such elements . Few corporations with 'steep fixed well known IT budgets' can afford such overall % based AMC. Also few emotional people , who associate and attribute their future careers to SSA only , may also find such exercise meaningless . But there are quite many value conscious organizations, who do very careful value engineering for all it's activities. These are penny wise and pound wise too.

"Refusal to revalidate the customer is illegal in any country because it is anti-trust unfair trade practice."

In many countries your statement above would be interpreted as legal advice and as such anyone who acts upon it (and fails in their endeavour) could seek legal recourse against you personally, and perhaps Baanboard as well. Your statement is incorrect, please don't make such statements again - you may be threatening the existence of a community that many of us find very useful.

"One can have brand file and ttiex300/301 table backups properly copied in binary mode and stored at secure place and have the baan run from these data/files incase of disaster."

Rubbish. Yes, there are ways around licensing issues, but all of them are against "the spirit" of any agreement you have with SSA/Baan and there are extremely few circumstances in which they should be used - NEVER without advising the vendor in advance of what you're doing and why.

(might be a good time to point out that I am not a part of SSA and never have been).

People, if you're happy with the Baan product and intend to stay with it, pay your support fees (but negotiate hard on the price). If you're not happy, move on. The middle ground (using an unsupported product) is a category A1, Red Alert, "I am stupid" business risk.

(this should get some entertaining responses)

Them are fighting words, Arthas! ;)

The dependency on (BaaN) support is the inverse of the quality of your staff.

That is funny Francesco, the whole reason we lost support was that we did not use it enough.

We do not have source code for the entire system and this is my point. I run across sessions that I do not have source code and I have a hard time supporting that application.

I also feel like a tight rope walker working without a safety net.

:eek:

3rd party Partners with source code access can help in individual circumstances. We can debug problems, provide updated objects (not source code) with custom work arounds or patching, etc. That would also cost for services, but only on an as-needed basis.

That does NOT replace the safety net, I am not offering an opinion on that one!!!

...might be a good time to point out that I am not a part of SSA and never have been...

Well done Artahs with your declaration which should be unnecessary. I think it should be compulsory for SSA/Baan people to declare their association and not hide behind the anonymity of this forum nor to permit some to pass-off their advice as being unbiased.


...The middle ground (using an unsupported product) is a category A1, Red Alert, "I am stupid" business risk...

This is the point. There is no emotion involved at all. If you decide to continue using it and it is the backbone of your operations then support arrangements are required. (irrespective of the internal skill-sets which are often more useful/productive and much lower cost but themselves high-risk)

Business risk is also the long term issue with SSA given that its long term strategy does not show any signs of being an innovative software developer/ marketer for the long haul. I think we will see many of the larger companies and others, more away from Baan for this reason in the next couple of years now that it is clearly evident that SSA are not in the same business as SAP and Oracle (and even Microsoft?)

Terry

I agree with everyone (except opensource - [s]he POMB).

Just in case Terry ever acuses me of lying, I was never part of SSA, but many,many moons ago (yup, both shoes and all three socks off, still can't count anywhere near high enough) I was an insignificant part of Baan support (pre Invensys).

In support of, and also to counter Francesco's "inverse" argument:

Yeah, you log a call, you get first line support, all they're gonna do is what you've done already (search the knowledge base, ask you to send copies of log files, "run this trace for me, will you?", and the classic "send me the session information". The guy's been logged into your m/c stuffing around in GTM, but still wants YOU to run the session info? You'll probably end up being instructed to install a patch that has three zillion dependencies (heh heh - that should keep him busy until I retire).

OK, I'm being cynical, but this really happens. The job of a support analyst (any vendor) is to close the call first, and solve the problem second (but both is good). Play the game until you can escalate to second or third line (believe it or not, they even used to have 5th line, don't know if they still do or not).

Third Line will know two crucial things:
1. You done all the donkey work already, and probably attached it to the case - they won't ask you to do it again.
2. YOU know your system better than THEY do.

These guys are good, but you need to build a relationship with them.

Francesco:
OK, you don't need support (I'm assuming that you have source code and understand the risks of a complete h/w failure).

How do you deal with a hardware failure or a major outside infuence such as Y2K (you mentioned yourself), or the introduction of the EURO with all it's implications?

AND - the best version was not Triton 2, it was IVc3 (i.e. pre PMC)

;)
A

A very cynical view. Things are very different in the US.

1 line of support - you get the expert on the product, or close to it, right away.
The only thing backing them up is the developer, who's in The Netherlands and probably already gone home for the day, so they have to generally fish through source code, etc. themselves to solve cases in a timely way.
This has the result that unless it's new, or it's REALLY complex, the guy you're talking to knows as much about it as the developer or more.
[I've seen some of the email trails between the analysts and developers, by accident, you'd be surprised how much they fight if they think you are right.
And, in my cases the analyst usually wins.]

Also, the case doesn't get closed until there is nothing more they can do
(sometimes they have to shut the door, not matter how much I yell)
or else you say it's ok to close it. I had a case open for 2 years at one point, sure they wanted it closed, but they wouldn't close it until I was happy.

As for why i keep a support contract even though I'm to the point that i really don't need a lot of help anymore, 1 main point. Insurance. In my first job, my boss would tell me that every hour that Baan was down, we lost 1 Million Dollars in productivity. I think that's worth keeping the vendor on my speed dial.

Also, I've never understood the people who don't patch their software, they're probably the same people who get infected by those Microsoft viruses or are running windows 95. I can't see how any company can compete in 2005s economic marketplace with 1975 technology.

Sure patching takes an investment of time and resources, but is it really that bad? I have a team of developers writing customizations 8 hours a day, and 250 users. I've applied every service pack for Baan 4 to date, with very little testing on my part (other than install on my test box and find out what tables are going to change) and letting my users at it for a week or so...
The worst that's happened is that some session doesn't work quite right until i get my defect fixed - which Baan fixes right away because in on a current patchlevel..

So in the end, i'm able to adapt new technology very fast like password aging, username extentions and the new PMC like a week after they come out. And these are New things that came out for Baan 4! That makes the SOX folks pretty happy. And my users cauz now I can authenticate my Baan users [on linux] against my active directory so now i have single sign on!!

People who don't patch will miss out on that - and that's a Baan 4 perk, not just Baan 5 or LN..

So I guess, for me, support is more than worth the money.

Dave

Wow you can install every service pack. If I had to install every service pack I would not be doing the custom development work to move forward with the Business problems of today.

Of course our shop has 1 and half Baan developers. I would love to bring out system up to the latest service pack, but the time it would take to reimplement our customizations and work out the new defects, I just can't seem to justify the expense.

I am so glad to get the opinions. I am really struggling with how to ask for Baan Support.

Like I originally posted we have been with out Baan Support for a year now and I am sure that will work against me.

I had a working relationship with a lot of Baan Support Techs and after 5 years of using Baan Support I knew how to work the system to effectivly solve problems.

To be fair, we don't own the source. So any customizations we have are forms, reports, tables, etc. We do have custom sessions that we've written but they are in their own module.

With this setup, applying service packs is fairly easy, the PMC "Check Customizations" helps by pointing out which of our customizations will be affected by the patches.

I've never had anything major occur that wasn't easily fixed by a patch that was already released. [ I don't install the SP the week after it comes out!! ;) ]. Mostly the problems that occur are just annoyances that get patched fairly quickly. If i needed to though, i could always just uninstall the pertinant solution...

Dave

"If I had to install every service pack I would not be doing the custom development work to move forward with the Business problems of today."

Have you ascertained the cost of this work? It might make the cost of Baan Support look less daunting.

Dave - PM me your postal address and I'll snail-mail you a ticket for the euro-millions lottery. You are bound to win 'cos you list your location as Grand Rapids - this makes you naturally lucky. (one of the tactics we used internally at outlying, insignificant Baan offices was to log pri 10/20 calls at a time of day that they'd get handled by GR).

Then you'll owe me a coupla beers at one of your marvellous micro-breweries, and maybe I'll get to see the Batmobile again (is it still there?)

;)
A

Sure patching takes an investment of time and resources, but is it really that bad?

Yes, patching BaaN requires an incredible amount of resources (if you want to do it right, that is).

Of course you could just slap on any patch that comes out for your version, but that is not better practice than not installing patches at all. After all, once you have a stable system, any new patch can bring chaos. If it ain't broke...don't fix it.

I have tried different tactics over the years and as far as I am concerned, the jury is still out on best practice. Besides, lets face it. Baan administration is usually driven by resource availability, not by resource requirements.

After all, once you have a stable system, any new patch can bring chaos. If it ain't broke...don't fix it.

The "over" emphasis on regession testing I see at sites is very hard to dispute. Nobody can say that with a production system caution isn't the best option. But many places take this to the extreme, over-inflating the cost of Baan maintenance. I'm not suggesting recklessness, but I am asking whether or not the ROI is really there from the testing side.

For example, You take 6 months to move from SP 17 to SP 18 on Baan 4.
(and note, I've never heard of a change that went flawlessly so you'll still have problems because you can't test what you don't know)

I take 2 weeks. I have 5 minor problems that inconvienence a few shop guys and maybe a finance guy. They're still able to get their work done, the data is secure and I'm able to fix their problem within a week (or 2 tops).

The main point is, I've never heard of one over-tested instance where it was like "<phew> good thing we spent 6 months testing, it turns out, Baan won't start if you move to SP X..." The catestrophic things are obvious and show up right away, the minor things, are well... Minor..

It is true that I'm lucky to be in GR.. I can drive over and kick an support's butt if needed (or buy 'em a beer if deserved!) Probably why i'm a little soft on 'em =) [ Don't know about the batmobile, when was it here? I just moved here from the west coast a few years ago... ]

Dave

...this should get some entertaining responses...

Sure did but the result was that most of us agree in principle with most of the points raised.