Core Service Application Management and Development

Rooney thank you for you review and feedback. Below are responses to your feedback:

“UNM ERP Applications portfolio: does this include downstream systems and processes that rely on or use ERP data such as: AD auto-pop group creation, email account demise upon termination, etc.?”

The portfolio is referring to large core systems; systems such as AD and 0365 as well as processes to terminate users upon termination would be included if the system is located on the IT Core infrastructure and user access/demise processes for those systems would be handled through the Data Governance Process as well as the Provisioning within the BAR.

“Is there a list of what is in the ERP Application portfolio?”

We do have Application Portfolio lists within the Service Catalog of some of the Applications we support, there is also an ERP Components list located: https://share.unm.edu/teamsites/erp/Lists/ERP%20Components%20List/Summary.aspx . We are working on a consolidated and complete list to make available to our customers along with the updates we are making to our Service Catalog.

“2.1.1.1: Access “must” be safeguarded and not “should”?”

Great suggestion; we will update the SLA accordingly

“2.1.1.1: Is there an expectation that OLAs will be in place or created between departmental IT and UNM IT? What can we expect to support per application in the portfolio and at what point do we escalate to UNM IT?”

OLA is a great suggestion and one that we have been discussing with other IT departments. That would be the next logical step to ensure clarification and understanding of responsibilities. As part of our process we are creating an Enterprise Support Model that will include a handoff to operations (this could be the OLA) that will define the responsibilities of all parties as the system is in maintenance. If there are specific application questions, please reach out to your Core IT contact and let’s discuss clarification.

“3.2.2: Should bullet points 1 and 2 in 3.3 be a partner responsibility, too?”

Can definitely see how that could be a fit. Per ITIL we are defining Customer as the holder of the funding so a unit could be both the Customer and the partner.

We really appreciate your review, input and questions. Below are the responses:

“2.1 Bullet 4 – extra “t” between “of” and “ERP””

Great catch; we will update the SLA accordingly.

“2.1.1 – Grammatically, I believe “both” is not the right adjective when talking about three groups of end-users (faculty, staff and students).”

Great catch; we will update the SLA and clarify.

“2.1.2 Bullet 3 – “current team has knowledge or is” should be “knowledge of or is”

Great catch; we will update the SLA accordingly.

“2.1.2 Bullet 4 – How will it be determined if a service request requires more than 80 hours?”

Initial analysis and discussion will be completed as part of the request intake process. We will clarify the bullet within the SLA accordingly.

“6.1 Incident Report – “Time spent…”. I believe the nebulous wording of a service being “end user caused” and concerns about departments being billed for these types of incidents was discussed earlier in this exercise. I would repeat those concerns for this SLA.”

We will align with previous feedback and update accordingly

Jennie, thank you for your input on this SLA. Below are the responses to your questions:

“Section 2.1.2, bullet 2: Can you provide an example on “New systems or applications impacting core business”? “

The new Talent Management System would be an example of an application that will impact UNM’s Core business processes (HR); a new application that will be replacing a current system; it is also integrating with our Banner system. Another would be uAchieve; a system that supports the Admissions office and integrates with our Banner system.

“Section 3.1, bullet 1: I can’t open “UNM Development and Support Standard” file. I don’t have permission.”

http://discuss.unm.edu/wp-content/uploads/2016/03/Application-Development-and-Support-Standard.pdf

• This reply was modified 8 years, 6 months ago by alesiatorres. Reason: format

Thank you Elisha for you input on this SLA. Below are responses to your questions and input:

“2.2.1 – I’m not sure what this means “Management to contract terms and oversight of vendor””

This is stating that we will manage the vendor and ensure the system and requests are working within agreed upon licensing and contract terms. We will manage the vendor throughout the maintenance period to ensure they are engaging when necessary and meeting our agreed upon Service Levels within the Contract. We will clarify the verbiage within the SLA to address this.

“3.1 – It might be a good idea to reference the Data Center standard here as it relates to hosting and security/availability tier.”

Great suggestion, we will add that to the SLA

“Under 3.2.2 “Provide annual training for employees;” –where is the training and support responsibility boundary between IT and departments?

During implementations of new systems Core IT would be available to assist with some user training and coordinate the vendor to conduct the training. We would work with the department to ensure the necessary documentation is handed over to them. On-going each department utilizes the system according to their business process so we rely on each department to be the first line of training for their staff. If there are standard/general questions about how to use a system, there is an option “Instruction on Service” in Help.UNM that is available to request that support.

Thank you for your feedback Gabe. Here are the responses to your feedback.

-Is BAR going to be used for access requests in all cases? There are many systems that are not integrated with the BAR right now. How will access to systems not integrated with BAR be addressed?

Systems not integrated with BAR will be determined during our handoff to maintenance and agreement with the business unit will be determined how that access will be managed; in some cases the departments manage their own access.

-Can IT provide formal testing requirements. Too often we have users that know very little about QA/Testing. We need to formalize what testing needs to be done, how it should be done, what should be tested, when it should be tested, and what results should be provided after the tests have been completed.

We are currently working on templates and updating our SOPs for SDLC including QA practices. We will share and use those as we have them completed. We will rely on the departments to give us the testing scenarios that relate to their business processes.

• This reply was modified 8 years, 6 months ago by alesiatorres. Reason: formatting