|
|
I’ve recently been working intensively with Microsoft CLARET reports, so I thought I’d outline some of the lessons I’ve learned – often the hard way!
But please don’t consider this a definitive guide.
Microsoft CLARET reports are a tool that Microsoft has designed to display an organisation’s entitlement, including software assurance. The information in CLARET Reports is generally used to compile an Effective License Position (ELP) during an audit or review. They are useful because as long as entitlement is listed in the CLARET, no more evidence is generally required to demonstrate entitlement of the licenses in question.
But they’re not a complete picture of entitlement by any means, and you should always carefully verify their accuracy, particularly if you are in a review situation or being audited.
The other thing to remember about CLARET Reports is that what’s NOT in them can sometimes be as significant as what IS in them.
Things to watch our for in a CLARET Report:
Organisation Names
Microsoft runs the CLARET reports based on the names the organisation may have purchased licenses in – whether the legal name or not. But many organisation names change over time, particularly if the organisation is dynamic or participates in lots of mergers, acquisitions and divestitures. Make sure you give Microsoft the complete list of all names that your company may have purchased software in, otherwise you may find you are missing potential licenses.
Validate company names on the agreements tab
The CLARET report produces a list of agreements that have been made between the organisation and Microsoft. In general, agreements come in three flavours – open, which is one off transactions conducted through a reseller, Select Agreements, which may or may not have Software Assurance, and Enterprise Agreements, which always have software assurance. It is perfectly possible for companies to make genuine license purchases under all three types of agreement at any point in time, although they should probably be avoiding Open agreement purchases if possible.
Microsoft bases the list of agreements on the list of entity names you gave it, but also searches for spelling mistakes and typing errors to make sure it picks up as many agreements as possible.
The way Microsoft identifies company names that contain spelling mistakes is inconsistent, so if you have old CLARET Reports, cross-reference the two sets of agreements and company names and make sure they are all there. If you don’t have old CLARET reports to cross-reference against, request two or three independent CLARET reports so you can check how consistent they are with each other.
You may also find that there are agreements from organisations with a similar name to yours that don’t belong to your organisation and which need to be removed from the CLARET Report.
Unresolved Licenses
Once you are happy that the list of agreements is accurate, you can turn your attention to the pivot tables and purchase detail tabs. The first thing to do is identified any ‘unresolved’ licenses in the pivot tables. These are purchases of software assurance where the macros in the CLARET report have been unable to identify a base license. There are many legitimate reasons a base license may not be identified, but the most common is that the base licenses were acquired as part of an acquisition or merger. In order to claim these licenses as legitimate entitlement, you will need to find the license transfer certificate and provide evidence in the form of invoices that all required payments were made. If you can’t find the actual license transfer certificate, but have all the other paperwork to hand, you can retrospectively lodge a request for the certificate as long as the party you bought the licenses from is still in existence.
So that’s my advice with regards to what is IN a CLARET report, but to be honest, what isn’t in the CLARET report is just as important – I’ll talk about that next week.
 I’ve just spotted a really good article about building the business case for ITAM on the ITAM Review website. It’s actually an interview with Jenny Schuchert of IAITAM.
It really struck a chord as in real life I’m in the process of building just such a business case for ITAM. I recognised many of the ‘gotchas’ she described as having real potential to derail the project.
I’ll be working with a project manager, so I think I’ll suggest she read the article to provide a bit of background and understanding as to what we’ll be trying to achieve. I also think I’ll need to make sure we focus on the following:
Communication
Identifying all our stakeholders and communicating with them at an appropriate level will be absolutely key. Not only do we have to build and sell the business case to the execs, as Jenny mentions, we also need to make sure we sell the business case to everyone who will need to be involved, from the different heads of IT in different operating units down to the administrators who actually purchase licenses and machines and the IT support guys who install hardware and software.
Think outside IT
I think it’s important to not just build a business case within IT, but also to engage the Finance department and procurement particularly. We’re already planning to hold a workshop session for all our heads of IT, but maybe we should do something similar, in scope if not in size, to sell these other departments the benefits of what we’re trying to do.
Quantify the true costs of not doing ITAM well
We’ve spent a lot of time identifying the direct costs of not doing ITAM well, but we haven’t spent much time looking at indirect costs – the amount of time people waste because they don’t have the data they need at their finger tips, for instance. We’ve just done some licensing reviews – if I survey the people involved, perhaps I can build an idea of the time they spent and then multiply it out by the internal Full Time Employment (FTE) rate and add that to the direct costs we’ve already identified.
Find the synergies with other projects
I’ve spent the last week talking to all sorts of different people about the projects they are involved in. Similar themes kept cropping up again and again, for instance data security and SAM need to know exactly how many machines are in the organisation so they can be sure they all have anti-virus or a discovery tool installed and can identify and locate those machines which have fallen through the holes of the process. There are lots of other synergies out there to include in the business case too.
Prioritise
There are a lot strands to an ITAM project, so I’m thinking of outlining them all, identifying who will benefit and how, and making sure we understand the dependencies not just between ITAM projects, but also with the other projects going on in the organisation. It will be complicated, which may detract a little from the clarity of the business case, but it will allow the organisation to assess each project relative to the others and decide what to tackle first.
Hopefully including some of these ideas will make my business case a lot more powerful than it would be otherwise… I’ll keep you posted.
 These are some of my top tips for making managing printers that little bit easier. They’re not exclusive, of course.
- Educate your users about all the different functions of a multi-function device – particularly scanning, ’storage print’, where you print to an ‘in-box’ which allows you to print out a large number of documents at once rather than one by one, and ’secure print’ which allows you to require a password before a document prints out.
- Network ALL printers, including personal printers in private offices – it’s the only way you will have any hard data about how much is being printed where.
- Removing or upgrading printers that frequently break down from the environment is an easy way to make both your users AND your desktop support team much happier!
- See every office move as an opportunity to reduce and rationalise the printers in that area. Work with facilities to know when office moves are occurring, do the research to know what the current print environment is like and what the usage stats are, and then make sure that printers are moved (or even removed, if possible) to where you want them.
- Use the print management tools provided by the printer manufacturers. Do regular studies of print-outs per printer, the ratio of colour to black and white etc. Match the information against the manufacturer recommendations to identify printers that are under or over used.
- Put the right printer in the right place – analyse demand using hard stats from your printer management tool. Don’t make the mistake of putting in a B&W A4 printer when the department also needs to print A3 colour.
- Buy models which have separate colour cartridges so that you only replace what you need.
- Set all print defaults to B&W and duplex – it is the cheapest option, even on a colour printer. You would be amazed the number of pages which have a small amount of completely needless colour on them, and changing the default avoids using the colour cartridges unnecessarily.
Does anyone have any more tips they’ve found helpful in the past?
Printer management is tricky for a variety of reasons, and I’m not going to pretend I know all the answers. But what I thought I would do is discuss a few of the issues that make it so tricky, and provide a few tips and tricks that can make things easier.
That’s MY printer syndrome
People get very possessive about printers! I think because people hate having an existing habit disturbed, and walking further to the printer (whether it’s an extra metre or an extra 20 metres) feels like a marathon until you get used to it.
Personal printers are also a status symbol, and it can be very difficult to remove them, no matter how little they are used and expensive they are to support. Develop a culture where a personal printer is a privilege, not a right, and don’t allow anyone to inherit a personal printer when they move into an office – whip it out of there as soon as you discover the office is vacant, and never, EVER allow anyone to have an old printer because it is spare. You will never get it back and everyone else will want one too.
Another good tip is to network personal printers – it might seem like a waste of time, but believe me, personal printers breed like rabbits, and the only way you will have any ammunition for reducing their numbers is to be able to demonstrate how little they are used versus the support cost.
Old printers are expensive
Old printers are expensive to run, although they seem cheap – after all, they depreciated to nothing long ago, and they just keep running and running, like the Duracel rabbit. The expense comes in the cost of toner, which gets more expensive to buy as the printers become rarer, and the cost of electricity, as newer printers are much more energy efficient. Older models are also much dirtier (the cartridges allow toner to escape more easily) and more restricted in their capabilities eg not being able to duplex or print different sizes of paper, so there will be pressure for a larger number of printers in a smaller area.
Different work roles have different printing needs
The type of documents your users print can make a big difference to printing needs. For instance, a lawyer who prints off a large document of a hundred pages every day will have very different requirements to a book keeper who prints off a hundred one page invoices. The lawyer won’t mind (too much!) walking to the MFD at the end of the corridor, but the need to do so for the bookkeeper would seriously affect their productivity. It is perfectly reasonable that they should have a printer closer to them so they’re not making so many trips just to pick up print-outs.
Having said that, there may be a wider issue of why the person must print out a hundred one page documents a day. Are they manually entering data from one application to another (but what about the inherent the data-entry dangers)? Are they comparing data in different documents (perhaps a larger monitor might make it easier for them)? Are they printing out documents in order to keep a hard copy record (maybe they should use an electronic archive instead)? It may be worth asking a Business Analyst to spend some time with the person to see if there is anyway that their work can be streamlined and productivity improved in general, as too much printing can be a symptom of other work inefficiencies.
There are no hard and fast rules
All these factors mean there are no rules by which to judge whether you have achieved the optimum printer environment. The number of printers required in any given space will be a function of the number of people, the distance to the printer, the type of printing they do and the culture of the organisation. Analysis of the print environment should be ongoing and constant to try and minimise the number of printers and associated support costs.
Has anyone had any experience in designing the optimum print environment? What factors did you consider when making your judgements?
 So as promised, here are my top tricks for effective management of support, maintenance and subscriptions. They are in no particular order!
Storage
Support, maintenance and subscriptions are all types of contracts. You should scan them in for your own reference and as a back-up, and send the originals for storage by the legal department in their fire-safe.
Use a tickler file
A tickler file is any system, whether electronic or in paper format, that you use to remind you that an agreement needs renewing. The benefit of electronic tickler files are that they can be set up to send automatic reminders to relevant parties, but the drawback is that if a key recipient leaves the organisation, the reminder can disappear into the ether and the contract doesn’t get renewed. If possible, store your scans/photocopies of the contracts and any other supporting information in the tickler file so that they are easy to locate when needed.
Centralise contract management and administration
IT Techies are just plain awful at administration. Centralise it as much as possible into a skilled, coherent team so that you have continuity of administration and regular transfer of knowledge and skills between team members. A key function of the team is to ensure that the entire purchase and renewal process is tracked from renewal reminders being sent out to requisitions and POs being raised and invoices paid.
Request a business case for renewals
The business case doesn’t have to be exhaustive, but it does need to demonstrate that the key decision maker has thought through the options available as well as the implications and risks of renewing or not renewing the agreement.
Co-termination
Where you have several agreements with one supplier, request that they all be co-terminated – in other words, that all the agreements have the same renewal date. The first year may require some pro-rating of renewal figures by the supplier, but they are usually happy to do this. Many software manufacturers insist that the first year be paid in full before the agreement can be co-terminated, but you will be able to pro-rata and co-terminate the agreement the following year.
The benefits are two-fold – firstly, it leads to significantly reduced administration and management costs, and secondly it allows decision makers to see the full picture for any one vendor at a time, leading to better and more considered decision making.
So those are my top tips – does anyone have any others they would like to add?
Picture Credit: Penny Buckmaster
 Are you going to be surprised when I tell you that Support, Maintenance and Subscription arrangements have a lifecycle too? I didn’t think so!
New Agreements
Most of these agreements are entered into as an adjunct to the purchase of a piece of hardware or software, although subscription licenses are the actual license, but paid for on a regular basis rather than once off.
The factors behind the decision to purchase a subscription license are similar to the decision behind purchasing a perpetual license – essentially it is just the form that is different. The decision to purchase subscription vs perpetual will depend on comparative costs, the longevity of the license, management costs, and, interestingly, whether the organisation capitalises software costs, or writes them off as expenses… but I’m not going to talk about that in any more detail here.
Just as there is a decision to actually purchase hardware or software in the first place, there is the decision to enter into a support and maintenance contract. The decision is usually independent of the purchase, except for some software titles, where the purchase of support and maintenance for the first year is often compulsory. The decision to take out a support and maintenance contract will usually be made as a result of discussions among the techies, management and procurement, and will be based on cost of the support or maintenance, in-house expertise, desired service levels, and whether or not the purchase (or non-purchase) would affect any other, more vital support and maintenance – remember what I said last week about some software companies taking the ‘all or nothing’ line that if one active license isn’t supported than none are!
Lifespan
The key difference between support, maintenance and subscription agreements and the purchase of a piece of hardware or a perpetual software licenses is that it must be renewed on a regular basis or it will lapse. The decision whether to renew the contract is based upon similar factors as the decision to take it out in the first place,such as the importance of the hardware or software, in-house skills and desired service levels.
For most organisations, the biggest management challenge is to implement processes that ensure the contract is flagged up as being due for renewal, and that the whole renewal process is followed through to its conclusion, including final confirmation that the contract has been paid for and that the suppliers is also in agreement that the contract has been renewed.
Support, maintenance and subscriptions are intangible assets just like perpetual software licenses, and so similar care should be taken to run regular open PO and unpaid invoice reports in order to identify any problematic transactions. Another thing to bear in mind, particularly for subscription licenses and software support and maintenance, is that some manufacturers will expect you to be able to show evidence of a continuity of support in order for the current support to be valid. This is is to discourage organisations from taking ‘time out’ in a support or subscription contract, and if a license ‘falls out’ of support, the manufacturer may sometimes charge a penalty fee or ‘uplift’ for the privilege of putting it back into support.
End of Life
At some point the hardware or software that is supported will no longer be required by the organisation, and the support contract can be ended. Most of the time, companies will just let their support lapse at the end of the period, but large and/or very long term contracts may need to be actively terminated, and a refund of fees paid may be due.
On the other hand, subscription licenses may be at the other extreme, and have a penalty charge applied for ending the contract early, like mobile phone contracts. And of course, particularly with software support and maintenance, you should be sure that cancelling the support and maintenance will not affect support and maintenance for other licenses because the manufacturer has an ‘all or nothing’ policy.
So that’s the lifecycle of support, maintenance and subscription license agreements. Next week I’ll outline some tips and tricks for managing them effectively.
Picture credit: Kylie Fowler
I hope everyone had a good Christmas and New Year! Mine was… interesting… to say the least, as I was visiting my brother’s in-laws in the South of Italy. Highlights of the stay included helping with the slaughtering of two pigs and processing the meat for salami and hams! Very cultural to say the least, and, believe it or not, a very welcome break from IT Asset Management.
But anyway… back to work.
Subscription licenses, support and maintenance all have one thing in common – that is, they need to be renewed regularly. Like perpetual licenses, the rights involved are intangible assets, which means not only can it be difficult to prove that they have indeed been legally purchased, but unlike perpetual licenses, the right to use the software and take advantage of support and maintenance needs to be renewed, usually by means of a contract renewal and payment of a sum of money, on a regular basis.
Let’s look at these beasties in more detail.
Subscription Licenses
Are, like an ordinary perpetual license, the right to use a piece of software within the terms and conditions in the contract. If the subscription is not renewed at the end of the period, then the right to use the licenses expires. Sometimes an option to convert the subscription licenses to perpetual licenses is included, generally, of course, exercisable on the payment of more money!
In addition to all the standard SAM dangers of over-installation and under-licensing, there is the additional danger that the contract is not legally renewed and so the right to use the software lapses without the organisation being aware they are no longer compliant.
Subscription licenses are becoming more common with the advent of Software as a Service and Cloud computing. These application delivery technologies allow the software manufacturer much greater control over who uses the software and when, therefore reducing the risk of a subscription lapsing while the company continues to use the software.
Support and Maintenance
I’ve discussed support and maintenance in the context of ITAM lifecycles before, but lets look at them in more detail from a management point of view.
In an IT context, Support Contracts give an organisation the right to contact the support provider for assistance if they experience any problem installing, using, upgrading or de-installing a product (whether hardware or software), while maintenance contracts give an organisation the right to request that a piece of hardware be repaired if it breaks down, or in a software context, to install software patches and bug fixes. Occassionally maintenance contracts will also include the right to free software upgrades, but as always, it depends on the detail of the contracts!
Support and maintenance contracts are often purchased together. While software Support and Maintenance is almost always purchased from the Software Manufacturer, hardware Support and Maintenance contracts can be purchased from independent third parties who may offer lower prices and/or better service than the original manufacturer.
Support and maintenance contracts generally run for a period of either one or three years. Discounts are often given if the contract is taken out for the longer period.
Although the financial risk in accidentally letting a support and maintenance contract lapse is not generally as high as with accidentally letting a software subscription license lapse, there are still significant risks involved.
First and foremost are the service management risks inherent with something going wrong with the hardware or software and not having an expert available to help resolve it quickly and with minimal disruption to service levels.
Because Support and Maintenance are such important revenue streams for software manufacturers, who also have a monopoly on providing the support and maintenance, the software manufacturers also have the ability to demand continuity of support and maintenance for their products. By this I mean (and in contrast to hardware manufacturers where there is thriving competition in support and maintenance provision) they have the commercial power to demand that any software that is supported should be supported continuously throughout its life. There will often be penalty charges to bringing licenses back into support if the support contract has been allowed to lapse at any point in time. Some manufacturers, particularly of high-value software, will also insist on an ‘all or none’ policy for currently used licenses, meaning that if the support on one currently used licenses lapses, it invalidates the support on ALL currently used licenses. Not only is that a huge service management risk, it is also a financial risk, as you may have paid a large sum of money in supporting several such licenses, only to have it invalidated because support on one license was missed in the renewal process.
As you can see, managing renewals of subscription licenses and support and maintenance is not only very important, but also poses a challenge because of the intangible nature of the rights purchased and the need for renewal of the rights on a regular basis. The next couple of posts will look at techniques to help manage these contracts.
As we’ve seen, software deployment and upgrade maintenance functions tend to follow the same set of processes. We’ve also seen that because software is just code that can be updated and changed easily over a long period of time, it has a much longer lifespan than hardware does generally.
 But software will come to the end of its life sooner or later. Often it will just become too difficult to continue updating it, so a completely new piece of software will be adopted. Other times the function for which it was originally designed is no longer required and so neither is the software. The mutually reinforcing technology cycle where more sophisticated hardware requires more sophisticated software which requires more sophisticated hardware also plays a part.
The decision that software is no longer required is generally an architectural one. By this I mean that the decision will be made by the people who manage the IT infrastructure of an organisation to ensure that it meets ongoing needs. The decision to discontinue a piece of software will be based upon input from users, tech support, and the developers who may have been upgrading the software. Non-technology areas such as procurement and the Legal department may also contribute to the decision making process. Other things that will be considered are what alternatives are available and how much they would cost, both in terms of creating / purchasing the software in the first place, and also how much it will cost to maintain / update the software over time.
Once the decision has been made to remove a piece of software, the software needs to be uninstalled from machines. This can be either be a manual process – very time consuming – or it can often be done automatically using a software deployment tool – yes, these tools will generally be able to automatically uninstall software too!
Sometimes software can be difficult to uninstall, particularly if it is older, or hasn’t been designed well. Sometimes software can leave traces in the registry which can be difficult to remove, and older software, particularly, may never have been designed to have an ‘uninstaller’ which will remove the application from the machine without affecting other software. Thorough testing should always be conducted before a piece of software is uninstalled to ensure that the uninstall causes no problems. Occasionally software that does not uninstall properly will leave a ’signature’ in the registry or add/remove programmes which can fool a discovery tool into thinking the software is still installed. This can confuse licensing positions, and is another reason why thorough testing should be carried out before uninstalls go ahead.
Another big challenge faced when uninstalling software from an organisation is similar to one faced by Patch Management – the need to ensure that the software has been uninstalled from all required machines. As with Patch Management, software asset management tools can provide us with the information we need to check the uninstalls have been completed.
As with the situation where a discovery tool is fooled by poorly uninstalled software, software that we think has been uninstalled but is actually left on machines can have serious implications for the license position of the organisation.
This has just been a very quick run-down of some of the issues to take into account when software reaches its end of life. Next we’ll take a look at the finance implications of the software lifecycle, with a focus on how to manage licensing at each stage.
Picture Credit: Kylie Fowler
 The software lifecycle is truly circular – unlike hardware which may be repaired only once or twice in its life, software will often go through many iterations of improvements (bug fixes, new functionality etc).
Most of the activities involved in the upgrade of existing software are exactly the same as those involved in creating and deploying the software in the first place. There will be cycles of developing and testing before the changes to the software are deployed. The deployment process is also pretty much the same – identifying machines to be upgraded, actually installing the upgrades, verifying the installs have been completed and ensuring that no machines have been missed.
Really, that’s it for this post, but f you can think of anything to add, tell me, because it does seem very short. I’ll look at the financial aspects of software management a few posts down the road, so don’t start getting stressed if you feel I’m only covering half of it – have patience!
Picture Credit: Penny Buckmaster (I wish I’d taken this one, it’s a great picture)
 Software gets installed on machines in a variety of ways, and for a variety of reasons.
Controlling Software Deployments
In general, it is installed because someone wants to use it. However it can be a challenge ensuring that the value gained out of the software is more than the cost of the software. Most organisations have some sort of authorisation process in place to ensure they receive value for money out of their software. Individual software requests may only require line manager approval, but large deployments will often be treated as projects and go through standard governance processes.
Software can also be installed because it is required, for instance if the software patches a security hole or fixes a bug in an existing piece of software. It may also be installed as part of an upgrade programme.
Ad hoc software requests of the “I need to use this piece of software, please install it” kind) are usually treated as a service request which will be routed through the service desk and fulfilled by desktop support as a “standard change”. Deployments which affect a much larger group of users or machines, such as a patch, bug fix or upgrade programme will usually go through change and release programmes to ensure they are installed on all machines that need the software, that the installation doesn’t cause problems with other systems, and provide a ‘back-out’ path in case things go wrong.
Exception reporting is vital to ensure that all users or machines that were intended to receive the software actually do receive it, and that no one ends up with it who doesn’t need it.
Packaging
Common applications, including Operating Systems and the components of a standard build, may be installed on a server as a ‘package’ so that they can be installed quickly and easily on selected machines. All software that is packaged should go through the same testing process as any other piece of software and should also be subject to the same controls.
Tools
There are many tools on the market which assist with software deployment, and indeed many are part of a suite that also include a software asset management tool, for instance Altiris. There are also some specialist deployment tools which are part of a security suite and which focus on Patch Management, although the technology behind these tools are fundamentally the same as any deployment tool.
Deployment tools are only as accurate as the hardware management that supports them (making sure that all machines are on the network regularly, have the relevant agents installed and working, that machines intended for salvage are removed from the pool of machines etc) and also rely heavily on the accuracy of associated discovery tools to identify which machines have had the software installed and which need to have it resent to them.
Uncontrolled Deployments
Despite an organisation’s best efforts, it can be very difficult to ensure that all software that is installed is done so through the correct control procedures. It was a challenge in the days of ’sneaker-net’, when software had to be installed using physical media, but the ability to download software off the internet has made the problem acute.
The surest remedy is to ‘lock-down’ all desktop computers so that only an administrator can install software, but even the most controlled of companies will have computers that are not ‘locked down’ for whatever reason, and it will always have people who know the administrator password which gives them the ability to install what they wish. Again, exception reporting is the key to identifying uncontrolled software installs and initiating processes to have it removed.
So this is a quick run down of how software actually gets installed on machines – but you’ll notice I haven’t even mentioned licensing! That’s because, although all software will have some sort of license or intellectual property rights associated to it, in many, many cases the license will be such that the software is effectively uncontrolled from an organisation’s point of view – for instance patches, bug fixes, drivers etc. These are all pieces of software that have perfectly legitimate reasons to be installed, although the license does not need to be actively managed.
I’ll talk more about techniques for managing those licenses that do need to be managed in later posts.
Picture Credit: K J Fowler
|
|
Recent Comments