« UKLUG 2009 Registration is OPEN - Call for abstracts - Call for sponsors | Main| Separated at birth? »

Is this why Notes is "So expensive to support?"

Category
Bookmark : del.icio.us  Technorati  Digg This  Add To Furl  Add To YahooMyWeb  Add To Reddit  Add To NewsVine 

As they said on Numbers the other night, 'a bit of a thought experiment' here.

I've been chatting to some big Notes customers over the last few weeks. Really big ones. As most of these customers are really big and have been using Notes happily for many many years, they've done what we have all probably done at some point. Where the IBM-supplied functionality didn't work for them, they changed it.

So, for instance - if Out of Office didn't work *just* the way you wanted it to, it got changed. Or Stationary. or letterheads. Or reply-type options. Or etc... Whenever they come round to an upgrade there's an obvious cost to upgrading the code. We all know this, no big surprise here.

Of course, with most other mail systems - you don't get this choice. Don't like the way that Outlook deals with Out of Office? Tough. You get what you get. But then, that's not something you have to think about when upgrading - even when it changes the way in which it works. BUT - that's cheaper for the customer at that point.

So, here's the question to ponder. Should we be convincing customers NOT to modify Notes, to lower their eventual support costs? Or convince them TO modify Notes, to flex with the business of today? I suspect this is a question that Mary Beths' team have to wonder about every day....

I'd be very interested to hear your thoughts.

Comments

Gravatar Image1 - I'm all for modifying Notes to make it work for the company.

But I'm all for making the changes repeatable. Modifying the mail file is the most horrble process imaginable. What I'd like to see is the ability to take those changes, and then apply them to a new version, automatically.

This is where DXL round-tripping would actually be very very useful.

--* Bill

Gravatar Image2 - I think as long as it's managed in the right way then the customisation doesn't need to be too expensive. I worked on a project recently for a customer where we have created a repeatable mail template "upgrade" process to apply all of their changes to the latest version of the template that can be done with very little effort now that it is properly documented and tested.

I'd call this a bonus, not an expense.

But then I guess I'm biased!

Gravatar Image3 - I have added some really cool Value-added stuff into the mail file in my time... the best one was where the company was too cheap to buy a software auditing tool... so we built a PC Audit function into the mail template where it would periodically audit the pc for various Windows Registry settings, Installed Software, IP addresses and log everything to a PC audit DB, everything else you could imagine..

Eventually we started using the function to deploy patches e.g. DST Settings

Gravatar Image4 - I'm not a consultant, so I may be missing something, but it seems to me that a big part of this expense is the monolithic upgrade issue. Customers seem always to face the fact that all of Notes is one unit, so upgrading one part means upgrading another, and this upgrading all the customizations. If it were possible to pick and choose parts of the product to upgrade and parts to leave alone, it would be easier to only spend the money where it is most needed. But again, maybe I am being naive.

Gravatar Image5 - Indeed, we di think abotu stuff liek this every day, and try to pick defaults wich will "make most of the people mostly happy."

I always have mixed emotions when a company says that they don't like the "vanilla out of the box" stuff but then also say that they do not want to customize because they'd have to redo the customization with each upgrade.

Gravatar Image6 - As much as I hate to say it, I would advise against fiddling with the mail template.

In my experience many customers (large & small) have a bespoked mail template, but zero documentation as to what was done. Usually, the developer who did it left the company years ago too.

So they upgrade/patch Domino, but stick with the old bespoked mail template.

Unless you have a thoroughly documented process to repeat your mods each time you patch your servers, I would say you are better off sticking with the standard mail template.

Even better, stop running 6.5/7.0 and upgrade to 8.5!

Gravatar Image7 - Heck, if you really need something different, modify it, as long as you make sure that modifying key designs in the system is the ONLY way you can achieve what you want. And I'm talking about real functions here, not little peevish user whims (even if the whimsical user is the CTO). Never hack up names.nsf or mail.ntf on a lark, but there are some value-add mods that I did years ago that I still keep around. For instance... a view in the NAB that does nothing but list servers by IP address. Think about it.

Gravatar Image8 - I have been on both ends of this discussion. Inside customers that did it, and outside supporting/performing the changes.

Some are valuable, some are not.
MANY fell under private views.

Documentation is key.

Customizing is helpful for companies to feel they are part of the program and live/love it and while I don't encourage them to go crazy I do encourage it in general.
By the way, one can provide Outlook with other functionality via buttons, menu items, by adding items, not sure how well you can remove/delete/hide aspects.

Gravatar Image9 - The ability to customise the mail template is a big advantage, as you point out, from a functionality POV. But customisations need to be documented so they can be re-applied to the new version's template. Or even better, put all your customisations in a central template so then they can be made ready for the new version in isolation and then applied to the new template in whatever manner you see fit.

I don't want to turn this into an ad for Teamstudio, but if you have customised standard templates and not documented it, we have a nifty comparison tool called Delta that will identify those customisations.

Gravatar Image10 - I agree completely with all the comments about documentation - but maybe I didn't ask the question well enough?

I was wondering if we should start actively dissuading customer from making modifications in the first place - so that they can take advantage of the new features as soon as they come out?

With the release rate of Notes versions now so rapid - by the time some fix is developed, it may well be in the shipping code anyway!

Our customers with no modifications are already moving to 8.5, for instance...

Gravatar Image11 - Updates are just that, it would be nice if one could implement a "merge" of templates rather than an upgrade.
Then you could checkbox what MUST be brought forward.

Gravatar Image12 - As an ISV it's a pain in the arse. Adding things like calendar integration to other systems is a pain. Having to make those modifications to all the different supported versions of Notes is an even bigger pain.

Whilst 3rd party integration with the mail template is possible, managing it is very hard.

Many customers refuse to implement any integration that requires template modifications, yet they still want the feature which makes both IBM and the partner look bad.

Gravatar Image13 - Once dxl round-trip is stable you can use dxlmagic to have your cake and eat it too.
Emoticon stw

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

Me

us.JPG

User Groups

uklug blog image.JPG

Twitter Updates

Links

About Me
About the site
BE Systems
Private Photos
Note, some links may require a login.

Where are you?