One of the most important parts of owning anything is knowing what one owns, in what state it is, maintaining as good a state one can, and know where it is.
Personally, I’m not the minimalist I used to be.
Perhaps I don’t feel the need to anymore, or perhaps my ability to assess what I need and what I may need has been diminished. Perhaps I adopted an “it’s good to have” attitude, again. Or maybe I’m just too busy and too tired to be as agile towards life’s challenges as I used to be? To be able to pack my stuff and move across distances, across borders, and such. I think I settled…
I used to be very good at knowing what I have, where, and I was periodically getting rid of things I did not need. I was good at recycling, reusing, not inventing or reinventing the wheel, again and again.
With that being said, I still decently keep track of everything I have, where it is, as a reflex, yet now, also in my personal life, I use software and systems.
ITAM is much like that. It’s a set of principles, processes, procedures, tools, and techniques to keep track of the IT assets the company is the owner of, permanently, or for a time.
The absolute must in terms of ITAM is having an overview or ability and methods to get that overview on demand. The overview should present at least a ratio of 80% tracked assets in operations and up to 20% assets in “transitions”.
Preferably a 90% / 10%, but one takes what one can get.
In large company’s, there’s a huge amount of stationary computers. These seldom move, unless they are not needed and thus moved to storage (stock) or they break and so those are “in repair”. With disregard to the asset’s current status, this status should change as soon as assets status changes. This is very difficult to achieve if you as a manager intent to track this manually. That’s why God invented barcodes, tracking chips, and monitoring hardware/software. The darn thing is: most companies won’t invest in such systems because of “having enough” of employees, won’t develop their own because they don’t have enough developers, and will not adapt and adopt existing for the same reason as developing from scratch. Customization costs, yet adapting to a system means often taking shortcuts over a scenic route.
I did a calculation based on the known number of participants performing an add-on inventory and found that investing in a tracking system would be covered by the extra amount of hours put in by employees. The added value in having such a system is at all times having control of your assets, provided the process is followed, aided, and supported by the tracking systems.
In terms of movable assets, as in portable devices, we are facing much larger issues than ever. Smartphones, tablets, various hybrid devices, laptops are in constant movement. They move in and out of the office, travel, break, are shipped, purchased, resold, stored, get stolen, or even lost.
The issue isn’t tracking them at all times, but rather split the tracking into processes and implement procedures to make sure they are tracked to a minimum degree, when moving, leaving, breaking, being stored, or shipped. You might have correctly noticed that I did not write deployed. This is because you surely use a system like SCCM where you are deploying software, but also keep track of the deployed hardware. Thus when assets are in operating status, they should be in principle for an agreed period of time be tracked at each logon to the device.
There are many possibilities, regardless of if the company was formed recently or has been successively built over years. The most important part is to always remember that regardless of how things used to be done, there’s a guiding principle, defined processes, and procedures now. The only constant in this universe is: change and thus things change now and then. Being mindful of this and communicated clearly to the environment is easier to say than to do. I believe, given my own experiences which I now commit to written form, that any company is able to track their hardware and thus also software. This “book” will mainly focus on Software Asset Management, however since software are located on hardware, devices are part of scope at all times, not only because of software location but also and primarily because software licenses refer to the very platform on which software now is installed.
Software and their licenses, that is, which governs indirectly how, where and by how many or for which period of time they may be used. Since rules can be out into a system it’s a rather short walk from knowing the path to walking it, meaning being compliant.
I tend to consider, speak of, write about licenses as entities having a life of their own.
Now and then I refer to licenses the same as I’m referring to permits, including a driver’s license. Sometimes I refer to them as assets.
Licenses are not just one thing. At least not to me. But let’s start from the beginning.
At some point, software manufacturers realized that providing a copy of executable code requires some sort of regulations, and licenses were born.
I can’t say when this became clear to me. I do remember however when my journey in software asset management begun. It was with a EULA of Windows 95a, during one of the largest in history rollouts of personal computers in Scandinavia. I remember it with mixed feelings because at the time I was working for a third-party company selling BPO services to one of the leading pc manufacturers to date. Today the building, computer network, software, and above all individuals involved would be referred to as call centers. Back then I’m not sure what words we used to describe our jobs. I don’t intend to write much about that part of my evolution, but I feel it is worth mentioning that I started with SAM on a cold winter night, out of an office in Copenhagen, commuting there from Malmoe, where I lived. It started through reading an OEM Eula, and I did so because of a customer asking a few questions, I did not know the answer to.
Over the years I must have read thousands of contracts, license agreements, EULA’s. At least as many times, I’ve ended up in heated discussions on rules applying to particular situations. These situations are referred to now as scenarios, while the rules are terms and entitlements. I still think with fondness to the times where I started to understand the partly legal partly technical jibberish that license agreements are which intends to cover the economic responsibilities manufacturer enforces on the user, since they can’t do so in praxis, often prior to using the software or actually having a complete understanding of the use-case past their own need.
And so how to understand them depends on scenarios, and scenarios are the situation your organization is in.
This “book” isn’t about how to interpret a licensing agreement and so I’ll touch on terms and entitlements sporadically as it serves my purpose.
The most important part to think about is the lifecycle and some less important accounting rules, then legal rules depending on the country of use, but that depends on your view. I’ll focus here on a view from SAM perspective.
Licenses are thus permissions of sorts, to use purchased functionality through a media, the software, in which these functions are embedded.
In simple terms, in order to work with numbers and lists, you may have decided that Excel is the best software. Excel is part of the office suite, and Microsoft Office is licensed in various ways, depending on suite and channel, aka how you have purchased it. Of course, you may only purchase Excel for your purposes, which is still possible. The point is, you have, and the terms now dictate what you may do with your copy, how you may deploy it, how and where it can be used.
Licenses therefore in general describe what is the object of the terms and entitlement, how it may be used, by how many, where, how, under which conditions. As the terms are the latest agreed upon by usage, when a piece of software is installed, regardless of you reading the rules or not, the rules are enforceable by law, and whatever bullshit, story, explanation you might have for not following them, you’ll pay nonetheless if caught. An army of lawyers can help, but unless you’re a software factory by definition, you might end up being legally caught up in litigations for years (that’s a cost), your IT may be busy trying to cover it all up as their main occupation, instead of just paying the fines. Even if you win in the end, your overhead costs will still be equal to paying and following the rules or paying the fine. In addition, no vendor will seriously sell you the software you may need, which may force you to develop everything yourself, and that without the possibility to use smart development tools may be more expensive than you can possibly imagine.
The common misconception is that if you have tools, you don’t need a schooled and experienced staff. That when you have staff you don’t need many tools, and an even worse one: once you buy something and hire some people, then there will be no more costs. You’re wrong.
Lifecycles.
There’s time to rest, time to cry, time to play, and time to die, I heard once. This sentence is the source of my ideology and cornerstone of asset management.
Do you remember 286, 386, 486 computers? I think back then Bill Gates mentioned something about never needing more than 660kb memory? I retired a 486 for a friend in his store some 10 years ago, migrating him to a Pentium III simply because I could do that with 0 cost to him and that was the last one I’ve seen in a while.
The constant in lifecycle starts with those in the business of producing hardware as a need to keep improving products to motivate others to keep spending money.
Let’s assume that INTEL imagines per generation of their processor chips 2-3 generations of pc’s embedded with this tech. Let’s say any mainstream computer producer based on that, plans for a typical office laptop: 3 models, with an average lifespan of 1,5 years each and 1,5 years of support. Let’s assume further that Microsoft plans around it when developing their operating systems, which will allow running of their Office.
In reality, then, we have 3 years cycles for each model. Each Company must here decide what is the best policy for them and choose if they wish to lease or buy. This depends on their own business needs, their own ability to refresh their fleet, and how tightly they need to follow the hardware development. If you’re an engineering firm, or you develop games, your own needs may be slower or faster than vendors’ lifecycles. Thus always thinking ahead is a good policy. The thing here from an accounting perspective is never to write off investments over 5 years if you intend to follow a 3 years cycle, but I assume that it’s pretty clear to everybody by now.
From a financial perspective, if you as a company don’t make enough to upgrade your hardware every 3 years, you could purchase, but then you’re IT has a headache… The thing is Microsoft has a support cycle of their operating systems, which will on one side support certain hardware and software a while, but software that you may need to upgrade more often at some point may not function on this operating system, and now we have a question: Do you follow your lifecycles and plan accordingly?
Let me tell you this: I’ve never yet have worked anywhere, where all lifecycles were taken into account. It did not matter if this was a software or hardware vendor. It did not matter if it was a software developing company or an engineering firm. In addition, it must be said that there’s no single tool that will provide you with all and any aspects of tracking information that pertains to your software or hardware. You either develop, buy or compromise…
Policies, processes, and procedures.
Don’t despair, this is all possible to be done, wisely and responsibly, but this is where we come down to policies, processes, and procedures. The important lesson however is the same as something I really liked being presented on Facebook a while ago. I’ll paraphrase, as I don’t remember it verbatim: “Our company offers good, fast and cheap. But only 2 of these can be applied to any given service or product. Fast and cheap won’t be good, good and cheap won’t be fast, good and fast won’t be cheap.”
Policies are important to have in place, but they need to be scalable, updated ever so often, and adjusted to changing conditions. I’ve seen some policies in effect for 20+ years… They were not effective anymore, and they did more harm than good, but as they were the governance principles, they were as good as written in stone.
Nowadays I keep reading Linkedin articles, and not much later see activities and initiatives implemented in the company. Seems our management teams are also reading Linkedin. The damn thing is, usually collaborators taken most seriously are those with management titles on A, B, and C levels, and while their crystalized message makes sense in general, parts of the message don’t necessarily fit in, in most other organizations. They are adopted nonetheless because of hierarchical thinking and management methods. A behavior referred to as Golden Pony.
It is like with ITIL, it is a framework and most professionals would agree that ITIL is useful. However, when you do implement ITIL you should implement the procedures and best practices and not ITIL the concept for the sake of having ITIL. Taking frameworks literally causes quite often more issues than it solves and as the organization matures over years so doesn’t the interpretation of ITIL, unless someone does monitor and adjust.
What worked on one occasion doesn’t work on other occasions. Trouble is, somehow this is what happens very often anyway, although some or most stakeholders would agree the result won’t be as imagined at discussions.
Another cute thing I like coming from Facebook, or maybe LinkedIn is: We hire smart people to tell us what to do, not to tell them what to do. Sounds like something general Patton would say.
I do not use that phrase to state that I’m a smart person, nor do I mean that I’m not being listened to. I’m stating this because managers consider themselves often as officers do in an army. Men who lead and thus provide what, how, direction, when, and all other aspects of how to get to an end result.
This means that in order for everything to be successful at end result managers imply they know how things are done, and how they should be done from low and high perspectives. They also assume that people working beneath them are able to communicate problems on the way, highlight issues, and generally steer everything as instructed.
Not to mention the biggest pitfall of all, we all assume we are making sense, in the manner we meant it or intended to.
For me, the cold shower was once when as a kid I had an idea and went to the bank to get a loan. The clerk took his time, explained the need for a business plan, budget, market research, and many more things I did not consider prior to the meeting because my idea, in my head made total sense. I guess this is how we speak to one another, not considering how the message will be seen or understood.
I did try, and during the process, I set the idea aside. Simply because I realized what was actually needed to make it a reality while expectations for the end result would surely being in less than the cost of the solution.
So investing time in modeling the solution pays more often than not in averted spend.
This is why virtual R&D is such a huge thing. You can find out the costs of manufacturing before you even build a prototype…
For the same reason building processes and procedures makes sense.
as long anyway as it’s not a process for the sake of having one 😉
