The Community is now in read-only mode to prepare for the launch of the new Flexera Community. During this time, you will be unable to register, log in, or access customer resources. Click here for more information.
‎May 17, 2019 04:10 PM
Hi,
My experience as a implementing consultant:
Most customers have a centralized team overseeing compliance, procurement and other processes (for clients and servers). They usually have high level license know how but may lack deeper technical experience (which would usually be needed for server applications and not so much for clients).
They have to work closely with the "local" application managers, because they know the context and history, the specific app has. From what I have seen, this "deep knowledge" is nothing, you can easily centralize for all applications within a large organization.
For resource considerations, I don't have any specific numbers at hand, but please also keep in mind that scopes (e.g. vendor scopes) are important. Especially if you have to start building organization and processes, you need achievable goals.
Best regards,
Markward
‎May 20, 2019 05:15 AM
Thanks for the information, I have passed that on to our project team.
One follow-up question, I believe it would be beneficial for some of our team to attend some sort of workshop/conference, would anyone have any recommendations on one which might have appropriate sessions for those looking to develop/build out their processes? Much appreciated.
‎May 20, 2019 10:37 AM
In addition to "how to use the tool classes", customers just getting started in the SAM space can engage an Advisory Services project which can be leveraged to help you build the processes and policies for implementing a successful SAM Program.
In essence, without proper policies and procedures around the entire IT Asset Lifecycle (Procurement through software EOL for Hardware AND Software), successfully managing your Software exposure will be difficult. This is includes ensuring all appropriate inventory is available as soon as computers are deployed, updating Hardware Assets as retired as soon as they're removed from service, PO's are available when software is purchased to update your entitlements, etc. The more accurate and timely the data is available in the tool, the more accurate your compliance can be calculated. Since multiple groups impact this (Procurement, Vendor Management, Hardware Asset Management, IT Infrastructure, etc) it's best to start with the "big picture" and get buy in from all parties (or from someone high enough in the organization to smooth the buy in).
‎May 20, 2019 03:17 PM
Hi Allen,
In my experience in attending many conferences (including IAITAM, SAM Summit, Gartner, ..), there are not a lot of sessions focused on building processes - the sessions are typically more high level as opposed to true process engineering advice. That being said, these conferences are extremely valuable in other respects such as industry awareness, market trends, networking, understanding what other organizations are doing, etc.
Flexera developed a complimentary Program Planning Workshop that focuses on filling the "process void". Basically, we look at your existing processes and find gaps/opportunities then make recommendations on your direction and strategy. Reach out if you would be interested in discussing it.
Cyndi Tackett - Flexera
‎May 21, 2019 04:34 PM
Software asset management, and in particular understanding the way software licensing with different vendors works, is a specialized discipline that does not lend itself to being widely distributed in an organization. While some organizations cannot achieve centralization for various political or structural reasons, centralized software asset management functions will tend to be able to drive better outcomes for the entire organization than decentralized functions. This comes from being able to build a deeper set of skills and expertise, and drive more consistency in practices across the entire software estate. On a similar vein, having a single team covering both client and server software is ideal if possible - consider that some vendors (especially Microsoft!) go across both environments, and you wouldn't want to split management of software from one vendor across separate teams.
Here are some really rough rules of thumb that I use for guidance on SAM team sizing:
NB. Other people may well have quite different numbers which will be just as good as these - the numbers materially depend on how roles and scope are defined amongst other things!
‎May 21, 2019 02:32 PM