Benefits and functionalities of Integrated Application Lifecycle Management System

View artifacts managed by one Tool from another Tool.

Examples include list of Test cases from the Requirements Management Tool and Requirements from the Test case Management Tool, or list of design objects from the IDE. The benefit is even higher when multiple artifacts are accessible from a single tool.

Each individual stakeholder gets the benefit of accessing the artifacts from other tools without leaving their natural tool environment. This promotes collaboration and early problem detection, which can save a lot of errors and money.

Create various impacting and non-impacting relationships between
any two Artifacts.
This can manifest in creating a Traceability relation between a Requirement in Requirements Management Tool and Test case in the Test Management Tool; so that when the Requirement changes in one tool the Test case in the other tool will be flagged for impact. Another example is creating a dependency relation between a Change Request in an Issue / Change Management tool and the source code in the Configuration Management tool to track what files are modified to implement the Change.

Without this Traceability, the QA group could be testing an obsolete Requirement without being aware of it. In addition, without this feature, questions like “why a single source file is affected by so many defects?” cannot be answered.

Automate a process cutting across the tool boundaries and implement a complete ALM lifecycle without a break.

For example: a Change which starts its life in a Helpdesk tool as a Ticket, gets automatically replicated as a Change Request in the Issues Management tool /Change Management tool, gets approved by a Change Control Board, goes to the architect to create/ modify architectural artifacts in the Designer/ Modeling tool, goes to the developer for coding and to QA for creating Test cases in IDE and Test Management tools.

It is imperative to have an automated process workflow drive this across tool boundaries even when individual tools lack the processing capability. Without this process automation, the manual interfaces between tools are managed typically by emails and unstructured documents, inevitably resulting in dropping the ball at times.

Manage Projects and Resources across the tools.

For development managers, it has always been a vexing question to answer ‘For a set of Requirements, Changes and Defects what will be the Release date given a set of Resources?’ Alternatively, the questions can be posed as ‘Given a set of Resources and a Release date, what Requirements, Changes and Defects can we put in this release?’ or ‘Given a Release date and a set of Requirements, Changes and Defects, what kind of resources do we need?’ We can make it even more complex by incorporating design and modeling objects, test automation and other Application Lifecycle Management artifacts in the mix. Since the artifacts involved are managed by various tools, only an Integrated ALM system will be able to  handle this question.
Without an Integrated ALM, performing Project and Resource Management against just one artifact, say Requirements, will give an incomplete and wrong picture. The traditional PPM (Project Portfolio Management) software tool fails to take care of this because of a lack of integration with all other individual ALM tools.

Create Cross tools Analytics and Dashboards.

A Project manager’s assessment regarding the health of a particular development project can be massively flawed unless he/she takes into account the activities in all the tools involved. Analytics and reporting across various tools is very important at different levels including that of the CxO.

For example, an Integrated ALM system should be able to produce a Test compliance report for the end customer, who shows the list of Customer Requirements, Change Requests and Issues, traced to Test cases and individual Test runs. And finally, the Test run results should show that they have all passed. To produce a report like this requires retrieving information from various tools including Requirements Management, Issues / Change Management, Test Management and Test Automation.

Now that we have discussed the advantages of an Integrated ALM, we will next discuss three widely used options by vendors for achieving Integrated ALM, and how these options address the above functionality and benefits.

Read more about Integrated Application Lifecycle Management at wikipedia.
Also read more about IT Service Management here.

Incident Management and Problem Management in Kovair ITSM

Incident Management
For IT service organization, it is essential to manage the event that disrupts the normal operation of a service. Usually the ‘event’ is known as Incident, which may reduce the quality of service by means of any interruption. The challenge for the IT service provider is managing the Incident in an effective way to quickly restore the normal service operation as per Service Level Agreement and with least impact on business. The objective of service team is to analyze the incident, and provide work around to restore the normal service. But often, Incidents may initiate due to failure or error in IT infrastructure, and if work around is not available then ‘Change’ may need to occur. Incidents, which are not identified as an out come of any IT infrastructural failure, nor have any workaround, are recorded as Problem.

Highlights of Incident Management in Kovair ITSM

Scope to create Incident from Service Request Management, and it is applicable only for IT-related service requests.  An incident can be created manually or automatically.  If a similar Incident exists, then the service team should link the Incident with an existing Service Request. Otherwise (in absence of similar Incident), the application will automatically create an Incident against the Service Request, and establish a relational link among them.  

Provision to classify Incident on different parameters, and accordingly route  it to a respective service team. Classification of Incident is necessary because an Incident may have workaround  to restore  the  service,  or  in  absence  of  any  suitable workaround  it may  be  identified  as a Change or a Problem. The classification done at the beginning helps to take quick action on the Incident, and streamline the activities of a service team.  

Defined process to identify interruption in service (that may be recorded directly in the system or transmitted  from  a  Service  Request),  and  to  restore  the  service quickly  by  suitable workaround  following  a  Service  Level  Agreement.  This  pre-defined  process  can  be enhanced (customizable)  as  per  business  need,  and meet  the  objectives  of  the  incident management work flow of service provider.   

Closure of Incident is managed through the process.  Multiple  Incidents  can  be linked  to a Change or a Problem,  in  that case, closure of all  these  Incidents  is strictly dependent on  the closure of a linked Problem and/or a linked Change.  

Problem Management
The significant difference between Incident Management and Problem Management in Kovair IT Service Management is that Incident Management focuses on a quick restoration of quality service, and Problem Management focuses on the origin/cause of service interruption. When the occurrence of an Incident is frequent or has severe impact on business operations, then Problem Management comes into the picture to determine the cause of Incident, and to seek solution. When the origin/cause of a Problem is identified it becomes – ‘Known Error’. Problem Management can be of two types – Proactive and Reactive. The objective of Proactive – Problem Management is to prevent Incident before they occur in IT environment. This can be achieved by continuous inspection of service quality and analysis of IT infrastructure. The Reactive – Problem Management, on the other hand, focuses on root-cause analysis of occurred Incidents and to provide solutions against them.

Highlights of Problem Management in Kovair ITSM:
Scope  to  create  Problem  from  Incident  Management.  It can be created manually or automatically.  If a similar Problem exists, then the service team should link the Incident wit an existing Problem.  Otherwise  (in  absence  of  similar  Problem),  the  application  will automatically  create  a  Problem  against  the  Incident,  and  establish  a  relational  link  among them.  

Supports  analysis  and  investigation  to  identify  the  origin/causes  of  any interruption  or malfunction  in  service  quality  (which  is  referred  as  ‘Incident’). It can be done for already occurred Incident or for a potential Incident that could be a threat to the quality of service in future.  

Provides the scope to raise Requests for Changes (RFC), against the interrupted service that can be restored only by making changes in the IT infrastructure.  A defined  process  for  a root-cause analysis,  a  solution  delivery,  and  post implementation review. A post implementation review and confirmation is necessary to make sure that solutions are appropriate to restore the quality service without any adverse impact that may degrade the quality.  This  pre-defined process  can be customized  as  per  business  need  and  objectives  problem management work flow of the service provider.

Closure of Problems is managed through the process.  Multiple Problems can be linked to Change; in that case, closure of all these Problems strictly depends on closure of that link Change.

Read more about  Incident Management  and  Problem Management at wikipedia.
Also read more about requirements managements tool here.

IT Service Management and Its Users in Kovair

IT Service Management in Kovair
Kovair IT Service Management solution comes with four major transactional components: Service Request, Incident, Problem and Change Management. Information specific to each component are managed in separate silos. To ensure practical implementation of ITSM methodology in real-life, the solution also has other components like Configuration Items and Knowledge base.

Kovair’s built-in Service Catalog provides the facility for customers or service owners to submit their requests from a centralized location. Information on each component is managed separately through respective processes, which are also synchronized among each other. All requests are managed through the Service Request Fulfillment Process. IT-related Service Requests, if not resolved, can be logged as an Incident, and managed through the Incident Resolution Process. Incidents can further transform to Problem or Change, based on certain criteria. Problems can be managed through the Problem Resolution Process, and Change Requests can be managed through the Change Implementation Process. Knowledge base remains as a central repository and gets updated via Incident Resolution Process and Problem Resolution Process. The master component ‘Configuration Item’ helps you to manage IT assets like printers, software, servers, storage, and network devices.

Users in Kovair IT Service Management Solution

In a service environment, privileges/access rights of people involved in a service-oriented business are not the same. Classifications are done among the people, based on their accessibility to information, scope of operations in processes, role in service operation and delivery. It means grouping of people based on their privileges. Kovair ITSM solution comes with three pre-defined Access Groups – Service Admin Group, Service Manager Group and Service Support Group. Each group has its own access rights that are inherited to the users when they become a member of the group.

Service Support Group – Users that belong to this group can create Service Requests, Incidents and Problems. They can create records for their own or on behalf of customers. Apart from this, the group members also take participation in service management processes (Service Fulfillment Process, Incident Resolution Process, Problem Resolution Process, Change Implementation Process and Knowledge base Process) and at the same time, manage IT assets, i.e., Configuration Items.

Service Admin Group – Users that belong to this group get all privileges of the Service Support Group and Service Admin Group, and, in addition, they can manage the entire ITSM workspace. They can modify existing Processes, create new Processes from scratch, can create different Policies and Notifications, can change existing Policies and Notifications, can create Forms and Fields, can add users in the workspace, assign users to an access group and role, can remove anyuser from the workspace.

Read more about IT Service Management at wikipedia.
Also read more about requirements management tool here.

SLA Implementation in Kovair ITSM

Service Level Agreement (commonly known as SLA) is a contract between the service provider (who is offering services) and customer (who is getting services). This contract is set in measurable terms(say, in terms of ‘Time’) so that service provider can understand the time limit within which the service needs to be delivered to the customer. Customer can also know the time limit within which the requested service is going to be available. IT Service Organization aims to provide quality service to customers as per their need with the agreed SLA.

In Kovair  IT Service Management  the SLA determines – Expected Response Time, and Expected Resolution Time of the service requested by a customer. The Time calculation of SLA depends on the ‘Severity’ of the Service Request. A more severe Service Request will have less time for Expected Response and Expected Resolution. In the solution, SLAs are defined at a centralized location, from where they will automatically get applied on a service request depending on its severity. A service request can have severity of one of four pre-defined values (Critical, High, Medium and Low). For each value ofseverity, the SLAs are defined with a separate set of Expected Response Time and Expected Resolution Time in terms of minutes.

Once a request is submitted with a severity, neither the requester nor the service provider can make any modification in its severity level. Basically, the SLA against a request remains un affected until its fulfillment.

Read more about SLA Implementation at wikipedia.
Also read more about  application lifecycle management here.

Service Request Management and Change Management in Kovair ITSM

Service Request Management

Think of service request management with a number of forms (which are actually Internet pages) as providing the facility to record wide array of requests. It will not create any confusion to service requester and service provider, unless they are allowed to navigate through disparate locations, and the requests based on their types are managed through disparate work flows. The challenge for IT service organizations is to improve the service operations and delivery through a standardized process of ‘request fulfillment.’ With the introduction of Service
Catalog and automation of request fulfillment, this application has become more
customer–focused and streamlined. Service Catalog is a list of services (Business Services and Technical Services) that IT service organization provides to its customers. In other words, it is just an articulation of services.

Highlights of Service Request Management in Kovair ITSM:

• Requests submitted by customers are managed through a simple process that involves two service teams – IT Service Management Service Desk and Level One Support. This pre-defined process can be enhanced (customizable) as per business need, and objectives of this application are work flow of service provider.

• Closure of IT-related Service Request is managed through process. Multiple IT Service Requests can be linked to an Incident, and in that case, closure of all these Requests strictly depends on closure of linked Incidents.

Change Management

Change Management application is a structured methodology of planning and coordinating the implementation of changes in an IT service environment. The competitive nature of the market economy allows IT service organizations to strive for the improvement of existing services and the development of new services. This is the reason why IT infrastructure moves through constant changes. The challenge of an IT service organization is to evaluate the requested changes and implement them in an IT environment in the most efficient way that has minimum impact on the quality and permanence of service. These applications are initiated by logging a Request for Change (RFC). An RFC may originate from Problem Management, or due to some other reasons such as the development of a new service, the change in a business strategy that may affect the service quality and/or continuity, updates in vendor software/hardware that may impact the IT infrastructure. The lifecycle of Change consists of four major phases including Acceptance of RFCs and their classification, approval and planning by CAB (Change Authority Board), implementation of Change (this will be effective in an IT environment through Release Management), and finally, evaluation of change (to review the change in service quality and continuity).

Highlights of Change Management in Kovair ITSM:

• Scope to report a Change from Incident Management and Problem Management. A Change can be created manually or automatically. If a similar Change exists, then the service team should link the Incident/Problem with existing Change. Otherwise (in absence of similar Change), the application will automatically create a Change against the Incident/Problem, and establish relational link among them.

• Classification of proposed changes (at review stage) based on their feasibility and risk parameters.

• Post-implementation verification before a change gets effective in an IT environment. This helps an IT service provider to maintain a high degree of service quality to minimize the number of potential Incidents/Problems that may occur due to that change.

• Define process for verification of all changes to minimize their negative impact on SLA, service quality and continuity. This pre-defined process can be enhanced (customizable) as per business need, and objectives of of this application is work flow of the service provider.
  
  

Read more about Service Request Management and Change Management at wikipedia.  Also read more about application lifecycle management here.

Key Features and Benefits of Kovair IT Service Management

Key Features
Kovair IT Service Management Solution comes with a set of specialized organizational potentials to provide value to the customers in the form of IT Services. Transformation of resources to valuable services remains at the core of Kovair ITSM solution. Its potentiality is achieved by implementing IT-operation processes to manage the services over a life cycle with a well-defined strategy, design, transition, operation and continual improvement. The potentiality of Kovair  IT Service Management  helps a service organization to experience the three C’s – ‘Confidence,’ ‘Competency’ and ‘Capacity.’ Kovair ITSM comes with wide array of industry leading features.

Benefits of Kovair ITSM
The benefits of IT Service Management are broadly categorized in four distinct areas – Business, Financial, Employee and Internal.

Business benefits of ITSM:  Implementation of IT processes (compliant to ITIL v3) in a service organization can strengthen the business process, and can bring improvement in the quality of Service Operations and Service Delivery. By introducing specific processes to manage ITSM Service Desk  operations, Incidents, Problems, and Change IT service organization can gain higher productivity and customer reliability. The well-defined ‘best practices’ ensures improved working relationship between service providers and service owners. Following the ITSM methodology, it becomes clear to service providers – ‘what is expected by a customer,’ and ‘how to meet customer expectations in terms of Service.’ Customer-focused business operations ensure an enhanced customer satisfaction, and enhance the possibility of customer retention.

Financial benefits of ITSM: Implementation of ITSM in an IT service organization ensures long- term financial benefits. By virtue of ITIL ‘best practices,’ the three major components – People, Process, and Technology – get streamlined. As a result, the cost of service operation becomes lower in several aspects – by introducing customer-focused service operations in the business, the services are not over-engineered, by implementing well-defined root-cause analysis the recurrence of Problems can be prevented, by adopting change implementation process the impact of change in the business can be optimized. These are a few of the overall improvements in service operation and service delivery mechanism that in turn, generates financial benefits in the business.

Employee benefits of ITSM: IT Service Management does not undermine the right
synchronization of ‘People’ and ‘Process’ in IT service operations. By adopting ITIL ‘best
practices,’ the IT service operations become more customer-focused, and this helps employees clearly know their responsibilities. The simplified work flow and training on ITSM helps the employee to become more motivated and productive.

Internal benefit of ITSM: ITSM has a straight forward approach of ‘roles and responsibilities’ of people participating in IT service operations. So, even if there are involvements of different service groups in a process, each of them know their area of operations and responsibilities on a reported Service Request, Incident, Problem or a Change. The inter-team communication improves as different work groups or roles get synchronized in a process.

Read more about IT Service Management at wikipedia.  Also read more about requirements managements tool here.