Advice for 1/3/5 year roadmap

Christopher_Carver

I'm the technical architect behind the service management solution for a multi-national conglomerate. I have been tasked with the one, three, and five year roadmap when it comes to architecting the future.  I was hoping for any friendly advice for the future in crafting the goals that I will be putting forth.

So far over the last two years (what I call the initial build out), without any help from external consultants, we have built out 200+ request offering service catalog and eBonded our SCSM backend with an external service vendor's ServiceNow implementation. Plus a handful of functional extras as needed. The solution is used by 800 IT professionals only spread across a dozen separate business units in IT2IT operations. We use the Cireson portal as the interface between customer and analyst; no one uses the SCSM Console except for myself and three others. This year we plan to eBond with DXC (formally CSC) and AT&T increasing ticket consumption by 12-15K+ per year. So the Cireson portal becomes the single-pane of glass for our IT professionals. We do not use Cireson reporting in favor of PowerBI as we have found it of greater value in breaking down tickets details across multiple business units and vendors.

While I'm proud of what has been accomplished we have taken a beating on a few fronts. The first is request offerings with 'Query Result' fields. Many of the tickets require the customer to select an AD object. In all of our cases there are at least 50K AD active objects to pull from and some of the assets range just shy of 200K assets. Yet pulling these AD objects in the Cireson Portal is embarrassing slow, especially when other competing tools pull up the entire list instantly. I'd like to see better caching and retrieval or some trick (I'm not above hackery) in getting better performance without the need for pre-filtering. The second issue is more of a lesson learn in how we structure SCSM classes to templates to request offerings. So in 2017 we are undergoing a consolidation effort reducing our customer SCSM classes into a custom single universal service request class flexible enough to house all 200+ request offerings. Templates will be reduced in half and our request offerings will be consolidated (thanks to the Cireson advanced request offering) from 200 separate offerings to just under 60. 

So year 1 I have down for eBonding with AT&T and DXC and then consolidating the request offering.

For 3 year, I have the goal is to turn our Cireson portal from IT2IT between the business units to IT2B. Where all IT departments across all business units use the Cireson portal to service all IT needs for 40K users. But I do not know if the Cireson portal can handle such a load. Just a Result Query field pulling 40K AD objects stops a request offering cold, how can I have a user select there PC from over 200K assets in AD? I also need to separate categories, services, and request offerings based on who the user is that is logged in. (I cannot expose "Create a VM" to a shopfloor worker, but I need to expose it to select IT professionals.) Because some requests will go to external vendors, internal IT teams, or corporate enterprise teams.

For 5 year plan, the goal would turn the Cireson portal from IT2B to a B2E portal pulling in all support departments (HR, marketing, operations, security, etc. etc..) to be analysts fielding all internal enterprise requests through the portal. So there is a level of complexity in properly mapping request offerings across departments, organizations, and business units.   

Any advice from those that have been there and done that? I expect the bigger the impact the bigger the lessons learned I hope to avoid. I find it's far favorable to gain wisdom from others and to avoid the scars of experience. 

Tony_Collett

I haven't done this myself, however this is the way I might handle it after being exposed to SCSM/Cireson for a few years

First year - Advanced Request Offering's is certainly your friend here! It all depends on which direction you want to take request offerings. Do they want to sort ROs by their Category (i.e. AD functions, software requests, user updates, hardware changes etc) or do they want to sort by Type (i.e. All Create requests on one RO, all Modify Requests in another, all Delete Requests in a third, and so on)?
Creating a single Request Offering for all requests feels like it could go wrong on many levels. There would have to be hundreds of questions within the RO and the logic behind it would be immense. I believe it would be easier to arrange ROs in the correct category/Service Offering and essentially having the list of ROs as a 'first question' of what users want to perform from the list of services available. 
You want to combine benefit to business with ease of use, as these don't always come hand-in-hand. 

Third year - Query results are able to be filtered well with 2 fields: the first is a Text box which is set to Optional, the second is the Query Result field which utilises a filter (set up in the Configuration options) which filters based on the Text box question - this is called Token Searching. Using this method, you don't need to display all 40k items in a query result, which slows systems down; it will actually perform a search in the Config Item Object when you enter text in the Text box and dynamically update the Query Results. This will work on any system, regardless of number of users or assets. 
It is possible to expose ROs to different user groups by setting up varying Catalog Groups and Assigning them to User Roles. By utilising User Roles you can turn on and off different Request Offerings based on what the users need to access. If you set the required roles up at the very beginning and create AD groups for them all, it is then an easy task to determine which AD User needs to be in which AD group to be able to access the work they require (even down to only one AD group). 

Fifth year - The introduction of other users may be an arduous task and may be one you could roll out gradually every couple of months. If you start the first year with this in mind, and set things up for future plans, this will go much smoother than if you were to make major modifications at this point. 
The rollout process could give access to different departments over the course of 6 months (i.e. start with HR and test, then give marketing access and test, and so on)

As always, specific questions can be asked here and we're happy to provide closer information if hurdles appear to high to jump. 

Tony_Collett

I haven't done this myself, however this is the way I might handle it after being exposed to SCSM/Cireson for a few years

First year - Advanced Request Offering's is certainly your friend here! It all depends on which direction you want to take request offerings. Do they want to sort ROs by their Category (i.e. AD functions, software requests, user updates, hardware changes etc) or do they want to sort by Type (i.e. All Create requests on one RO, all Modify Requests in another, all Delete Requests in a third, and so on)?
Creating a single Request Offering for all requests feels like it could go wrong on many levels. There would have to be hundreds of questions within the RO and the logic behind it would be immense. I believe it would be easier to arrange ROs in the correct category/Service Offering and essentially having the list of ROs as a 'first question' of what users want to perform from the list of services available. 
You want to combine benefit to business with ease of use, as these don't always come hand-in-hand. 

Third year - Query results are able to be filtered well with 2 fields: the first is a Text box which is set to Optional, the second is the Query Result field which utilises a filter (set up in the Configuration options) which filters based on the Text box question - this is called Token Searching. Using this method, you don't need to display all 40k items in a query result, which slows systems down; it will actually perform a search in the Config Item Object when you enter text in the Text box and dynamically update the Query Results. This will work on any system, regardless of number of users or assets. 
It is possible to expose ROs to different user groups by setting up varying Catalog Groups and Assigning them to User Roles. By utilising User Roles you can turn on and off different Request Offerings based on what the users need to access. If you set the required roles up at the very beginning and create AD groups for them all, it is then an easy task to determine which AD User needs to be in which AD group to be able to access the work they require (even down to only one AD group). 

Fifth year - The introduction of other users may be an arduous task and may be one you could roll out gradually every couple of months. If you start the first year with this in mind, and set things up for future plans, this will go much smoother than if you were to make major modifications at this point. 
The rollout process could give access to different departments over the course of 6 months (i.e. start with HR and test, then give marketing access and test, and so on)

As always, specific questions can be asked here and we're happy to provide closer information if hurdles appear to high to jump.