IT Governance

COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations, helping them increase the value attained from IT.
The Information Technology Infrastructure Library® (ITIL®) is a set of concepts and practices for managing IT service management (ITSM), IT development and IT operations. ITIL is a globally recognized collection of best practices for IT service management providing detailed descriptions of important IT practices and providing comprehensive checklists, tasks and procedures that an IT organization can tailor to its needs.
IT service management (ITSM) is a process-based practice intended to align the delivery of IT services with needs of the enterprise, emphasizing benefits to customers. ITSM involves a paradigm shift from managing IT as stacks of individual components to focusing on the delivery of end-to-end services using best practice process models.
Provides a single point of contact (SPOC) to meet the communications needs of both users and IT and to satisfy both customer and IT provider objectives. (“User” refers to the actual user of the service, while “customer” refers to the entity paying for service). Many organizations have implemented a central point of contact for handling customer, user and related issues. The service desk types are based on the skill level and resolution rates for service calls, and can include: Call center Contact center Help desk Self-service portals
A record (reference) (paper or screen) containing details of an issue with any component of an IT Infrastructure or any aspect of the IT service. Some people call them help tickets, user service requests, “issues” or incidents. ITSM actually refers to the initial report as an incident and a “problem” is a level of escalation. Whatever it is called, it is the initial contact between the user and the support agent identifying a problem or question, along with a known procedure for logging it and tracking its progress to the customers’ satisfaction. PRC interfaces with outside service desk/help desk tools and it has its own optional internal system where these entities are known as requests.
Incidents are the result of failures or errors in the IT infrastructure. The cause of incidents may be apparent and addressed without the need for further investigation, resulting in a repair, a work-around or a request for change (RFC) to remove the error. PRC interfaces with outside service desk/help desk tools and it has its own optional internal system where these entities are known as requests.
When an incident is considered to be serious in nature, or multiple occurrences of similar incidents are observed, a problem record might be created as a result. (It’s possible that the problem will not be recorded until several incidents have occurred.) Problem management typically differs from the incident management, and is typically performed by separate staff PRC projects are ideal for problem management and change control. Relevant information about the problem is stored on the project record and the project can be tracked throughout its lifecycle including who handled or signed off on any aspect of it.
When its root cause has been identified, a problem becomes a “known error”. Finally, a request for change (RFC) may be raised to modify the system by resolving the known error. This process is covered by the change management process. A request for new additional service is not regarded as an incident, but as a Request for Service (RFS) and sometimes a Software Change Request (SCR). PRC projects are ideal for problem management and change control. Relevant information about the problem is stored on the project record and the project can be tracked throughout its lifecycle including who handled or signed off on any aspect of it.
IT controls are specific activities performed by persons or systems designed to ensure that business objectives are met. They are a subset of an enterprise’s internal control. IT control objectives relate to the confidentiality, integrity and availability of data. There are two approaches: preventive and detective. Preventive controls actually disallow certain functions that have been identified as disruptive to the organization. Detective controls have more to do with keeping log files and audit trails. PRC enforces established IT controls (preventive) and can provide the necessary log-files (detective).
IT general controls (ITGC) include controls over the IT environment, computer operations, access to programs and data, program development and program changes. PRC helps you define IT controls and then enforces the rules (prevention), while can provide the necessary log-files (detection).
IT application controls are embedded in the application.
Whether ITSM or any other procedure drives change, from the moment that the requirement has been identified. affecting the change, testing it, deploying it and final acceptance fall under the umbrella of “change management.” PRC tracks every change as it is made or moved, automatically. Backup copies are kept automatically in each case that can easily be reviewed, compared or reverted. PRC is an “inside tool.” Because it is written in U2, it understands the software and data constructs and can be embedded in the files and tools.
A one-time set of activities that ends with a specific accomplishment, a project originates when something out of the ordinary has to be accomplished. It is a set of non-routine tasks performed in a certain sequence, leading to a goal. A distinct start and finish date and a limited set of resources may be used on more than one project. Similarly, PRC projects are specifically discrete sets of changes to the software or database that are related to a specific goal (enhancement, change request, bug fix). The software on a PRC project is delivered (and undelivered) together.
A software release is the distribution of software code, documentation, and support materials. The software release life cycle is composed of discrete phases that describe the software’s maturity as it advances from planning and development to release and support phases. Identify a release in PRC either in advance or gather up whatever is ready.
A version or revision usually refers to a specific software component. Often versions of a program are numbered. The primary purposes of this sort of versioning is to 1) be able to go back, 2) identify when a change was released, and 3) manage parallel development. PRC does not require numbering software components. Instead, it addresses these purposes in ways that are clear, convenient and easy to manage.
Check-out, (or charge-out, reserving components to be changed), logging the changes themselves for auditing and status accounting and making the changes is part one. The second part is evaluating conflicts and impact, building, merging and checking-in software.
The processes and procedures around how change (software and otherwise) is managed within an IT organization. The terms change control and source control are sometimes used interchangeably, but source control is a more specific subset of the overall change control.
Quality assurance, quality control, quality management all pertain to how people manage the processes that help assure (control, manage) their software development lifecycle. In many cases the lifecycle includes a peer review step, movement to a different server to test the build/delivery and the changes in a separate test environment. Sometimes there is a test step by a quality department, then a user-review step. Defining a lifecycle (and changing it for different types of projects) is easy – and once defined, PRC handles the governance including required sign-offs.
Software testing is all about monitoring and improving software by validating agreed-upon standards and procedures. Whether closely defined and controlled or casually implemented, software testing is meant to identify and track any problems and follow them through to resolution before the software is released. Current thinking in software quality and testing suggests that the earlier in the life-cycle testing and testers are involved in the process, the higher the quality of software produced at lower cost. Test plans can be stored, combined and re-used against projects at multiple stages. PRC automatically takes the next appropriate action when test plans are passed or failed. History is built automatically about what tests have been used against what software components so that test plans can be recommended.
Software deployment refers to all of the activities that make a software system available for use. These activities occur at the producer site and at the consumer site (where the consumer may be a production server in-house, multiple branch sites or thousands of customer sites around the world.) “Deployment” should be interpreted as a general process that has to be customized according to specific requirements or characteristics, including items such as media or download method will be used for the actual distribution and which tool or function will be used to deliver the software from the distribution media. Then what makes the software actually usable – new files must be created, in many cases programs must be compiled into object code on the consumer site, indexes built. Whether you plan to deploy individual project/fixes, batches of timely releases, whole product upgrades to customers or any combination in-between, PRC helps you define, then automate a deployment methodology that will be timely, secure, reliable, traceable, repeatable and reversible.
Reporting is critical when there are auditors involved, but it is also important for routine management of the IT department as well as a tool for researching a particular situation. Capturing data about the IT infrastructure and routine events insures that PRC can help with whatever reporting requirement comes up. PRC’s underlying U2/MultiValue architecture gives it a uniquely visible and available repository of useful information, even beyond the scope of the (dozens of) available reports.