Managing in-house applications (software asset)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2017 11:16 AM
A question has come up during our discussions of software asset management in SN. Some of our customers would like to manage the software that they build along with the software that they buy from external vendors. I would be interested to get feedback from others who have already experienced this. My initial thought was to simply manage these assets like any other software asset. Of course there would be no license implications so we would not need counters.
Ric
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-22-2017 03:22 PM
Yes, that is the approach we have. We have homegrown software we just don't have any associated contract records for their renewals/purchases. If you are using commercial license servers (concurrent use) or supporting software that is purchased to utilize in the home grown software (to add extended functionality) I would ensure you record that also for tracking purposes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-23-2017 03:55 AM
I'm not convinced bundling them both together under the blanket "software assets" heading is a good idea.
Recording information about both serves different purposes. For example, purchased software would need attributes like vendor, price, support contract, expiry, licencing, etc. However, inhouse-developed software would need version control, authors, recorded tests/incidents - more information concerning its upkeep and growth over time than off-the-shelf packages.
Has this topic been discussed with the inhouse developers? Would they like to see this kind of information alongside details of Microsoft and Adobe products? Who are the primary users of these asset registers and how would they want that information presented/accessed?
I can see candidates for refactoring into one database... but concerned that there could be a maintenance overhead with building filters and screens to limit viewability.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-23-2017 05:16 AM
Your comments are very insightful.
Most "IT" developed software is housed within a separate application outside of Service Now and that does not fall under our direct oversight. The software we are responsible for tracking is standard/nonstandard software that is in use and is commercially purchased or developed by various business groups (outside of IT) to support their direct functions. We are just beginning the initial stages of software asset management in Service Now and are hopeful over time to introduce more functionality to the business especially with the availability of custom forms and workflows within Service Now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-23-2017 06:11 AM
Insightful they may be, please don't think they're gospel truth!
In my experience, I've found many organisations have different approaches with SA&CM, and what's good for a small organisation becomes arduous for a large one, or what's suited to large organisations feels overblown for small/medium enterprises. It sounds like your model works for you so far be it from me to try and push an agenda without knowing anything about your requirements or situation!
What I have suggested in these occasions is beginning with people in mind: who are the stakeholders, what are their requirements and how should they interact with the system (try to build some use cases with defined goals of value for different individuals)?
Many frustrating systems tend to be designed with a sole user and purpose in mind and once deployed there's then lots of integration work trying to bolt on functionality for additional users, meaning they feel secondary to the tool's core purpose and neglected when the design delivers high value to a small minority and the majority have to struggle with workarounds.
Fundamentally, it's a change - so all interested parties should have some level of involvement to make the change successful and feel invested in the change when it arrives.