- Administration
- Information Services
- Budget
- Comptroller
- Tribal Gaming
- CORE
- OSF Forms
- Recovery
- News
- Careers
Frequently Asked Questions
CRM 9.1 | General Questions | IT Consolidation and Coordination Act (HB 1304) | ITIL Questions | Licensing | Removable Media | Tribal Gaming
CRM is: Customer Relationship Management. For ISD’s purposes this is a specific application in Oracle’s PeopleSoft suite referred to as "CRM." The CRM application is currently being upgraded and configured for a fully ITIL compliant structure.
Products are a part of the CRM 9.1 SLA process. Every case will be tied to a product - and each product will have a specific set of SLAs. Groups are a quick way to group products.
Response time is measured from the moment a case is assigned to a group by the Service Desk and the moment an individual assigns the case to himself and saves the case.
Restore time is measured from the moment the case is created in CRM until the moment a resolution is entered and the case is saved.
An entitlemen plan is CRM's way of determining if customer is allowed to request service and if so, when. The entitlement plans currently set vary from 24x7x365 to 8-5 Monday through Friday - depending on several key factors of the case.
Response procedures may be different within your group for each based on the nature of the incident. Those protocols are typically designed by your management team in conjunction with QA. However, the escalation times and the SLA times are not affected by major/minor incident labels.
There are several metrics that will be important - some are across the board, others are specific to special units within ISD. For the broad measures - response time and restore time will be important. Another important metric is going to be how many solutions you provide that are "reused" by other ISD staff or by Self Service customers. For specific measurements that apply to your group, consult your manager.
Yes. One of the critical components of any CRM tool is its knowledge base. ISD depends on your expertise to document solutions for a number of reasons, but the two most critical are for training the service desk and for use with Self Service so the customer can resolve their own cases.
You'll have some help with the ISD Knowledge Engineer - Sharyn Sanders. She'll assist you in making your solutions complete and user friendly. The metric measuring how successful a solution is: how many times the self service customer or the Service Desk staff use your solution to resolve a case.
Case types are a way of grouping the items we face into large buckets. These buckets are pure ITIL and they are: Incident Management, Request Fulfillment, Problem Management and Knowledge Management.
AAF stands for Active Analytics Framework. This is the automation portion of CRM 9.1. It allows us to have CRM do certain functions automatically.
Yes. This is a change from all our CRM's of old. The trade off is this - we're providing you a telephone number with the understanding you must check the case notes to see what has been done with the case before you contact the customer. Little is as infuriating to the customer than to have "'some IT person' ask the same question I've answered 5 times already!"
Frequently Asked Questions. OSF’s FAQ section is located in the header section of the OSF website.
ISD is the Office of State Finance’s Information Services Division. This division is responsible for information technology, purchasing and many CORE shared services including Oracle’s PeopleSoft application suite.
CRM is: Customer Relationship Management. For ISD’s purposes this is a specific application in Oracle’s PeopleSoft suite referred to as "CRM." The CRM application is currently being upgraded and configured for a fully ITIL compliant structure.
Request for Change. This is an ITIL term that is defined by any request to alter the functionality of an existing product. You'll hear some use antiquated terminology of "enhancement service request" but strictly speaking this isn't ITIL terminology.
Under the act, no state agency shall expend or encumber any funds for the purchase, lease, lease-purchase, lease with option to purchase, rental or other procurement of any information technology assets without the prior written approval of the Chief Information Officer. In addition, no state agency shall initiate or implement an information technology planned project without the prior written approval of the Chief Information Officer. Copiers are included.
Top of IT Consolidation and Coordination Act (HB 1304)
Yes, the act includes maintenance, licenses and any other information technology encumbrance.
Top of IT Consolidation and Coordination Act (HB 1304)
Yes.
Top of IT Consolidation and Coordination Act (HB 1304)
The information is available on the Office of State Finance website at http://www.ok.gov/OSF/Information_Services/Office_of_State_Finance_Plan_Approval_Process_.html. The required form is OSF Form 115.
Top of IT Consolidation and Coordination Act (HB 1304)
The official effective date is 90 days after sine die; however, OSF is working as if the act has takes effect immediately.
Top of IT Consolidation and Coordination Act (HB 1304)
Information technology is defined as any equipment or interconnected system or subsystem of equipment that is used in the acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, telecommunications, or reception of data or information. The term shall include computers, ancillary equipment, software, firmware, and similar procedures, services, including support services and consulting services, software development, and related resources.
Top of IT Consolidation and Coordination Act (HB 1304)
The Information Technology Infrastructure Library (ITIL) is a set of concepts and practices for managing Information Technology (IT) services (ITSM), IT development and IT operations. The Office of State Finance Information Services Division (ISD) adopted this framework to enable communications between groups to exist with a specific and defined set of terms, ensuring we all "speak the same language."
An SLA is a "Service Level Agreement." In simple terms it is a formal contract between a supplier and a customer detailing the exact service offered and a guarenteed minimum level of service.
Yes. ISD has configured the new Customer Relationship Management (CRM) implementation so it provides accurate and very detailed response and resolution times. As our reporting ability matures, our Service Level Agreement (SLA) process will be refined to include actual minimum guaranteed service levels to the customers. Once these guarantees are made, ISD will begin publishing our performance compared to the minimum guaranteed level of service contracted.
ISD’s Service Catalog is the published list of services we are able to offer to our client agencies. The full list may be found just off the OSF home page, under the ISD Services link.
The Service Catalog only details those services OSF currently offers.
ISD’s service portfolio is a 3-part executive level summary of ISD’s overall IT strategy. It contains the items in the pipeline still currently under consideration or under development, the services currently offered to agencies, and those services that have been retired and are no longer offered.
For example:
- Pipeline: Enterprise licensing system
- Service Catalog: VOIP telephony
- Retired Services: POP e-mail
In simple terms, a service request occurs when a customer asks for assistance or training and the system is functioning correctly. This may be as simple as a "how to" question or as involved as a request to update 10,000 records. The Service Request ISD sees most often is for password resets and account unlocks.
An RFC is a "Request for Change." RFC is another form of a service request, but an RFC is specifically asking for a programming of functionality alteration that requires an evaluation process before work on the RFC can begin. RFCs follow a separate workflow involving approval, ranking and assignment.
An incident is a case denoting a system either broke (or is about to break) or service is degraded (or about to become degraded.) Commonly incidents begin with the phrase "The____ system is down."
A major incident is an incident with special handling instructions. In days past, OSF often called these "outages" that required additional (and often higher level) notification of a potentially substantial problem.
A minor incident is the routine incident that follows specific and proscribed notificaion list and does not does not require extraordinary notification procedures to take place.
A problem is a case that is under investigation by Quality Assurance. QA will search for a root cause and work to provide the Service Desk a work-a-round until a permenant fix is available.
Semantics really as far as ISD is concerned. The Help Desk is technically only able to support IT products. A Service Desk provides many different types of support from "how to I get a license to transport nuclear material across Oklahoma" in addition to IT questions. Technically, ISD has a Service Desk.
Compliance with HB 1032 requires the licensing agency to:
- provide online capability to apply for licenses or permits and
- provide online capability to renew licenses or permits and
- make the capabilities available via the state web portal
- report cost savings to the Office of State Finance (OSF) director on an annual basis
- apply to exempt licenses and/or permits that cannot be processed online
Licensing agencies are responsible for:
- complying with the law,/li>
- developing or acquiring the required capabilities if they do not exist
- working through Oklahoma Interactive (OI) to make capabilities accessible from the state web portal
- reporting cost savings
- applying for exemption for specific license types
- Contact the OSF Service Desk (by phone: (405) 521-2444 or e-mail HelpDesk@osf.ok.gov) to initiate contact with Oklahoma Interactive for tracking purposes
- Contact the OSF Service Desk for annual reporting process, criteria and format
- Contact the OSF Service Desk for solution assistance
- Contact the OSF Service Desk to obtain exemption process, criteria and format
Legislation requires compliance by July 1, 2010.
1.
What about other types of removable media, e.g., hard drives, memory cards, tablets, iPods, etc.?
See the Additional Guidance (#2. a. and b.) portion of the Removable Media Acceptable Use Procedures - Clarification and Guidance and the statewide Information Security Policy, Procedures and Guidelines, page 81 #1 and #3.
The only other "hardware alternative" currently tested is the Dell laptop hardware encrypted disk drive(s); other forms of media encryption will need to be addressed through software.
Yes, to ensure that the encryption process is enforced, can be monitored and audited; if business requirements preclude or make this operationally or financially cost prohibitive, there is a waiver process that can be used to grant an exception on a case by case basis
OSF has tested and is in the process of implementing Symantec''s Endpoint Encryption (version 8) with LANDesk (to prevent the use of unapproved USB devices) for software encryption.
The LANDesk software provides inventory and asset management of devices and is capable of registering and recognizing or rejecting unregistered devices, such as USB flash drives by serial number; Symantec''s Endpoint Encryption installs a software encryption module on removable media, which encrypts and manages access to the device/media while in use. OSF is currently evaluating a product from Good Technology that provides mobile device management (including encryption) comparable to the Blackberry Enterprise Server (BES), for SmartPhones and Tablets not provided by RIM/Blackberry.
Distributed media should be recalled and collected within a reasonable timeframe after establishing a strategy to complete the transition to a controlled environment – the objective is to protect information from disclosure due to theft or loss, not to unacceptably delay or inhibit business processes.
Yes, if they are/will be connected to state infrastructure and include the ability to receive and store state information in memory.
Yes.
Yes, there is a waiver process that can be used to grant an exception on a case by case basis; however, precautions should be taken to avoid abuse of this process that can result in such devices being used for other purposes for the sake of convenience.
In 1987, the Supreme Court, in California v. Cabazon Band of Mission Indians, confirmed the authority of tribal governments to establish gaming operations independent of state regulation. The following year, Congress passed the Indian Gaming Regulatory Act (IGRA), which provided a regulatory framework for Indian gaming. The IGRA offered states a voice in determining the scope and extent of tribal gaming by requiring Tribal-State compacts for Class III gaming. Tribal regulatory authority over Class II gaming was left to the tribes. The IGRA further provided for general regulatory oversight at the federal level and created the National Indian Gaming Commission (NIGC).
Under the federal law gambling can be conducted on "Indian land." Federal law defines "Indian land" as land that is either:
- part of a federally recognized Indian reservation, or
- off a reservation but held in trust for an Indian tribe by the federal government, or under the jurisdiction of an Indian governing body.
Indian tribes are the primary regulators of Class II gaming. Regulation of Class III gaming may be addressed in Tribal-State compacts and varies by state with tribes remaining the primary regulator in most states. In Oklahoma, the tribes are the primary regulators of both Class II and Class III gaming. Both Class II and Class III gaming are subject to the provisions of the IGRA and oversight by the NIGC.
Federal law regulates two distinct types of gambling on Indian land. Under the IGRA, there are 2 major kinds of gambling, each with its own regulatory mechanism. (IGRA also recognizes a third form of Indian gaming, class I (meaning traditional tribal ceremonial games), but exempts it from both federal and state jurisdiction.)
Class II gambling is governed by a tribal ordinance that must meet federal guidelines and be approved by the NIGC. IGRA defines Class II gaming as bingo; when played in the same location as bingo – pull tabs, lotto, punch boards, tip jars, instant bingo, other games similar to bingo; and non-house banked card games authorized or not explicitly prohibited by the state in which the tribal operation is located.
Class III gambling is conducted under a compact that each tribe negotiates with the government of the state in which it is located. The compacts can apply those state laws to class III gambling that each party believes necessary for regulation. Class III gaming authorized by the Oklahoma State-Tribal gaming compacts, consists of electronic amusement games, electronic bonanza style bingo games, electronic instant bingo and non-house banked card games.
Tribal-State compacts are agreements that establish the rules to govern the conduct of Class III gaming activities. Although a compact is negotiated between a tribe and a state, the U.S. Secretary of Interior must also approve the compact.
Oklahoma gaming compacts are in effect until their expiration date of Jan. 1, 2020. The compacts may also be terminated by mutual consent of the Tribe and the State of Oklahoma.
The IGRA requires net revenues from any tribal gaming operation are to be used for the following purposes:
- fund tribal government operations
- provide for the general welfare of the Indian tribe and its members
- promote tribal economic development
- donate to charitable organizations
- help fund operations of local government agencies
Oklahoma does not have a central licensing process for gaming vendors. Under the Tribal-State Compacts, vendor licensing is done by the individual tribes/nations. Prospective vendors should contact the tribes for their specific requirements.