Epic and ServiceNow implementation. Change control process in S-now with Epic applications.

[Asha143]

Hello All, We recently implemented service now.  We have many Epic Application as our EHR systems.  I am hoping if anyone would be willing to share two workflows.

1. Change control workflow-- If you have a diagram that would be great.
2. SPM workflow
   1. What do you consider demand as far as Epic.
      1. Are epic enhancements as small as new flowsheet or note template considered demand?
      2. How do each application manage Epic enhancements? --- For example Epic Ambulatory team gets requests to create BPAs- that are approved at BPA governance- how do you handle this in Servicenow? Are they Demands? or Service request? 
         1. Another example would be-- Epic Orders team gets Order sets that are approved at orderset governance.  Are these ordersets considered Demands? or Service request?
3. We are limited with our SPM licenses, so having a license for every analysts in all of Epic application isn't an option for us.

[amyfrye]

Our Epic teams have developed a pretty solid list of Standard Changes for most of their Epic build related work since a lot of what they do has little to no impact to the user base and the application itself. Build that is not so standardized that don't do regularly goes through our Normal Change process. We are currently working on building an Epic specific Risk Assessment since what they gauge as Risk is different from other applications and infrastructure related changes.

SPM workflow

1. What do you consider demand as far as Epic.
   • Workflow, Department Builds, field changes, flowsheet changes and more are considered demands.
2. Are epic enhancements as small as new flowsheet or note template considered demand? Yes.
3. How do each application manage Epic enhancements? --- For example Epic Ambulatory team gets requests to create BPAs- that are approved at BPA governance- how do you handle this in Servicenow? Are they Demands? or Service request? There are build related changes that used to go into Demand, we have now created Service Requests even if they go through a committee to be approved. Service Requests allows you to collect more information up front from the customer so that there is back and forth to collect all the information. Creating BPA's is an example of a build that used to be a Demand for us and now is a Service Request that will end up being a change prior to pushing to PRD.
4. Another example would be-- Epic Orders team gets Order sets that are approved at orderset governance.  Are these ordersets considered Demands? or Service request? Order sets also used to go through Demand for us but again, this type of work requires a lot of information gathering between the Demand Manager and the customer. Instead, we created a Service Request that collects a lot of that information up front then goes to governance for approval, once approved the build is done and a change is created to move the build to PRD.

Our IT teams has been using Scaled Agile Framework for over a year to plan out build work so we have it setup so teams can create SAFe stories from a Catalog Task in a Service Request to do the build. Of course, you don't have to do this but just wanted to mention that is something we are doing in addition to this process. Happy to chat further.

[Louis28]

Hi @amyfrye ,

RE: moving away from Demands towards Service Requests, was it that record producers didn't suffice for reporting? I would imagine Demand would have had a lot of benefits and give more flexibility. I'm curious to learn more about the pain points of using Demand for these sorts of enhancement and content mgmt-related requests.

[Ralph Hand]

I would think that your change control workflow would not change regardless of the application.  So you would have standard, normal, and emergency change flows and epic changes would follow those as appropriate.  

Any need to change the configuration of Epic should come in through a service request or an incident (if something is broken).     Before anything is actually done there needs to be an approved change.   You could build business approvals into your model but we don't, we have the people requesting the changes gather them manually and attach them (maturity thing).   Technical approvals are gathered via the tool. 

Before something goes into demand we would want it logged as a request so it can be evaluated.  Then it can be logged as a CIM or Demand and then work through agile, if you are using that as your development control or the built in tool for epic.

[Asha143]

Yes change control process doesn't change but how our analysts create their changes in ServiceNow has changed a lot from our previous systems.  Every change now comes with additional two tasks, pre-implementation and post implementation tasks.... not something we are use to doing.  

You mentioned before something is a demand, you log it as a request.  Are you able to turn requests easily into a demand?  We are told that we have to basically copy/paste and create a new demand.  Wasn't sure if thats a system limitation or just our instance isn't abel to do that.