Background

Resolution and Recovery of Critical Incidents is a continuation of the previous blogs I have written about Phase I and Phase II which deal with Identification and Recording, and Investigation and Diagnosis. Understanding the previous blogs makes reading this blog easier as it is a continuation, I would recommend you to read them first.

We use the RACI to assign responsibility to the following personnel or groups.

Technical Restoration Manager
Incident Manager/IT Operations
Support Group

Process flow for Resolution and Recovery of critical incidents

1. The Technical Restoration Manager reviews the proposed recovery activities to determine if a Technology change is required. This activity is to confirm if Change is required.

RA	I	CI

2. A decision is made that service restoration activities must be progressing through the implementation of a Change. (a) If Yes, go to step 3 (b) If No, go to step 7.

RA	I	CI

3. A decision regarding the type of change is made based upon the Change Management Procedure and the Change Management Process Policy.
(a) If Latent, go to step 4
(b) If Emergency, go to step 6

A	CI	CI

4. Change activity is reviewed and a Latent Change created to document historic change activities. The decision is that the change is Latent in nature.

A	R	CI

5. Either a Latent Change is created OR Emergency Change created. The Change Management process is engaged to manage the lifecycle of all Technology Change activity.

CI	A	R

6. Emergency Change created. The Change Management process is engaged to manage the lifecycle of all Technology Change activity. Restoration activities are reviewed with an Emergency Change created to restore or protect service.

CI	CI	RA

7. The Support Group verify that a temporary work around or solution can be applied without the need for a change – while meeting the requirements of the Change Management Process Policy. The process moves to closure of the incident.

Additional Tasks to be performed

i) Following service restoration All Major Incident Bridges are closed.

ii) The Problem Management process commences, through: 1) The creation of a Problem Record where root cause is not known. 2) Linking the Incident to an existing Problem Record where appropriate. 3) Creating a Known Error record where root cause has been identified. 4) Linking the Incident to an existing Known Error record where appropriate.

iii) The Major Incident Manager reviews the Incident criteria against the Incident Review entry criteria. Upon review; (a) If a review is required go to step (iv) (b) If a review is not required go to step (v).

iv) The Major Incident Manager initiates an Incident Review following the resolution of the incident. A completed Incident Review distributed to agreed recipients within the scheduled timeframe agreed upon.

v) The Major Incident Manager reviews the Incident criteria against the Major Incident Review entry criteria. Upon review; (a) If a Major Incident Review is required go to step (vi) (b) If a Major Incident Review is not required the process ends.

vi) The Major Incident Manager initiates a Major Incident Review following the resolution of the incident. A completed Major Incident Review distributed to agreed recipients within the scheduled time-frame.

Authored by Vijay Chander – All rights reserved – 2023

The post How to Identify and Record Critical Incidents – Phase III first appeared on TekTalk | Project Management Process Tool.

The post How to Identify and Record Critical Incidents – Phase III appeared first on TekTalk | Project Management Process Tool.

Business plans for your startup have many different formats. Depending on your business you can create a pitch deck that is appealing and gets your message across to your potential investors.

Microsoft Office is one of the tools that has many business plan formats in PowerPoint. Below is one that you can use to pitch your product.

Credits to Microsoft Office Templates

Authored by Vijay Chander – Tektalk 2023

The post Business Plan – Pitch Deck first appeared on TekTalk | Project Management Process Tool.

The post Business Plan – Pitch Deck appeared first on TekTalk | Project Management Process Tool.

Introduction

Strengthen your organization’s IT communication with a well-structured plan. This blog provides step-by-step instructions to optimize communication channels, ensure transparency, and enhance teamwork in your IT projects. We also delve into the process for managing communication that supports the Customer Platform. It describes the different types of communication and the individuals responsible for each type.

Purpose

The purpose of the a IT Communications Plan (Communications Plan) is to define how the program collects, assesses, reports, and acts on information about the progress of the project, as measured against project plans.

Scope

The goal of the IT Communication Plan is to outline the overall strategy for communicating and sharing project information. This includes documenting and agreeing with key stakeholders on:

• What to communicate
• When to communicate
• With whom to communicate
• Using what medium (e.g., reports, meetings, email)
• Content to be communicated (include a template, if needed)

Types of communication levels

The following levels of communication are expected throughout the program to inform customers of the overall performance as well as to discuss various topics related to the program:

Build a list of stakeholders as required by your organization and spell out their responsibilities. This is required to define a proper IT communication plan as it delegates and sets responsibilities of each person and the time frames when they need to be triggered.

Communication Matrix and frequencies

Now build a communication Matrix as shown below and expand on it to include other rows.

This is a starter set for building your communication plan. Go ahead and use this as a basis to build a more detailed one that suits your own organization. Let me know and share one you have written.

Authored by – Vijay Chander – All rights reserved – 2023

The post How to write an Effective IT Communication Plan? first appeared on TekTalk | Project Management Process Tool.

The post How to write an Effective IT Communication Plan? appeared first on TekTalk | Project Management Process Tool.

This Service level management process flow is written in a document format for easy printing and exporting as a document for your use.

Scope

The scope of Service Level Management is existing and new IT services provided by <your organization> to <Customer Name>.

Definitions

Service

A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

Service Level Agreement

It is an agreement between <your organization> and <Customer Name>.

The SLA describes the IT Service, documents Service level targets, and specifies the responsibilities of the <your organization> and <Customer Name>.

Operational Level Agreement

It is an agreement between <your organization> and another department of <your organization>

An OLA supports <your organization> delivery of IT Services to <Customer name>. The OLA defines the goods or Services to be provided and the responsibilities of both parties.

Underpinning Contract (UPC)

It is a contract between an <your organization> and a Third party.

The Third party provides goods or Services that support delivery of an IT Service to a <Customer name>. The Underpinning Contract defines targets and responsibilities that are required to meet agreed Service level targets in an SLA.

Configuration Management System (CMS)

It is a set of tools and databases that are used to manage <your organization> Configuration data.

The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships.

The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users

The CMS is maintained by Configuration Management and is used by all Service Management Processes.

Service Improvement Plan

It is a formal Plan to implement improvements to a Process or IT Service.

Service Level Requirements (SLR)

A Customer Requirement for an aspect of an IT Service.

Roles and Responsibilities

Service Level Manager Responsibilities

• Keeping aware of changing business needs.
• Ensuring that the current and future service requirements of <Customer name> are identified, understood and documented in SLA and SLR documents.
• Negotiating and agreeing levels of service to be delivered with the <Customer name>; formally documenting these levels of service in SLAs.
• Negotiating and agreeing OLAs and, in some cases, other SLAs and agreements that underpin the SLAs with the customers of the service.
• Assisting with the production and maintenance of an accurate Service Portfolio, Service Catalogue, application Portfolio and the corresponding maintenance procedures.
• Ensuring that targets agreed within underpinning contracts are aligned with SLA and SLR targets.
• Ensuring that service reports are produced for each <Customer name>’s service and that breaches of SLA targets are highlighted, investigated and actions taken to prevent their recurrence.
• Ensuring that service performance reviews are scheduled, carried out with <Customer name> regularly and are documented with agreed actions progressed.
• Ensuring that improvement initiatives identified in service reviews are acted on and progress reports are provided to <Customer name>.
• Reviewing service scope, SLAs, OLAs and other agreements on a regular basis, ideally at least annually.
• Ensuring that all changes are assessed for their impact on service levels, including SLAs, OLAs and underpinning contracts, including attendance at CAB meetings if appropriate.
• Identifying all key stakeholders and customers.
• Developing relationships and communication with stakeholders, customers and key users.
• Defining and agreeing complaints and their recording, management, escalation, where necessary, and resolution.
• Definition recording and communication of all complaints.
• Measuring, recording, analyzing and improving customer satisfaction.

Input, Output

Inputs

• Business Information (Such as organizations business strategy, plans and information on current & future requirements.
• Business Impact Analysis
• Business Requirements
• Service Portfolio
• Service Catalogue
• Change management information
• Configuration Management System (CMS)
• Customer feedback
• Inputs from other Service Management processes

Outputs

• Service reports
• Service Improvement Plan (SIP)
• Service Quality Plan
• Service Level Agreements (SLA)
• Operational Level Agreements (OLA)
• Service Level Requirements (SLR)
• SLA review meeting minutes
• Revised Contracts

Service Level Management Process flow

 

Detailed explanation of the Service level Management Process flow

References

• Procedure for Change Management
• Procedure for Service Portfolio Management
• Procedure for Service Catalogue Management
• Procedure for Supplier management
• Procedure for 7 Step-Improvement

Measurements

Reports are generated based on the below metrics.

Authored by Vijay Chander – All rights Reserved – 2023

The post Service Level Management Process Flow and Guide first appeared on TekTalk | Project Management Process Tool.

The post Service Level Management Process Flow and Guide appeared first on TekTalk | Project Management Process Tool.

In this Issue management process blog, I have written it in a document style so that it can be copied and used directly into a document.

Program Issue Management Process

The Program Issues Management Process is the process used to receive, qualify and manage issues that require the intervention of <customer> or <your Organization> contract management team to facilitate resolution.

Objectives

The objectives of the Program Issues Management Process are to

• Ensure issues are captured and resolved within the shortest possible time-frame at the lowest operational level possible;
• Provide the escalation path, with criteria, from operational or project issue management to program issue management then ultimately to Dispute Resolution so that the resolution of the issue can be assigned to someone with appropriate authority;
• Track all open issues to closure; and,
• Protect the relationship between <customer> and <your organization)

This is done by the the following

• Establishment of a review meeting;
• Addition of issue monitoring to the agendas of contract meetings;
• Active tracking of issues; and,
• Logging issues and regularly updating and reporting status to the Commercial Review Meeting.

Scope

The Program Issues Management Process is used by <customer> and <your Organization> to manage and resolve all joint program issues, whether raised by <customer> or <your Organization>.

Operational or individual project-level issues, unless escalated to the central governance level, are excluded from this process and are managed within the delivery organizations.  Similarly, day-to-day contractual issues may be managed directly by the Contract Managers. 

Disputes are issues between <customer> and <your Organization> that cannot be resolved at the central governance level.  These are managed by the Dispute Resolution Process as described in Dispute Resolution of the Infrastructure Transformation Services Agreement and are excluded from this process except for tracking and reporting their status.

Internal issues of either organization are outside the scope of this process. 

The process begins when a joint program issue is raised and continues with ongoing tracking until the issue is resolved.

Policies

The following policies will apply to <customer> and <your Organization> in relation to this process:

• <customer> Technology Governance will be the focal point for issue status updates and reports within <customer>; and,
• The <your Organization>PMO will be the focal point for issue status updates and reports from <your Organization>.

Process Flow and Diagram

An issue is “a matter of concern” caused by some event which, if not resolved, will have an adverse impact on project or service commitments, client satisfaction or other program measurements.

A program issue is an issue that has been escalated to the point where resolution requires the involvement of either the <customer> Senior  Management or the <your Organization> Senior Management or both.  Due to their broad impact, some issues may inherently be program level and cannot be adequately addressed at a lower level.

The Program Issues Management Process has two phases

• Issue Initiation; and,
• Issue Management and Tracking.

It is expected that both <customer> and <your Organization> have an internal issues management process to handle its own internal issues.  Joint issues, however, are shared between <customer> and <your Organization> necessitating an interface between the respective internal processes. 

Policies

Other processes that may affect the Program Issues Management Process to be deployed include:

• Contract Change Management Process
• Formal Correspondence Process
• Contract Deliverables Process

Issue Management process flow

Process Steps

Program Issue Initiation

A program issue may be initiated when an initiator fills out a joint issue form (refer to Appendix A Forms (your task is to Create a form), in correspondence or by tabling and minuting the issue in the operational meeting.

The Commercial Review Forum provides the channel between <customer> and <your Organization> for all communications related to joint issues, including the ongoing communication of the status of open issues. The meeting is responsible for qualifying issues, approving resolution plans and ensuring status is tracked until the issue is resolved and closed or referred to the Dispute Resolution Process.

Raise Issue

The Issue Initiation phase shown in Figure 1 begins when a joint program issue is raised by either <customer> or <your Organization> and may arise, for example:

• If a delivery or project issue is unable to be resolved at the operational level;
• During the execution of other governance processes;
• As a result of a review or audit; and,
• As a result of an event that has a negative impact on contract commitments or client satisfaction.

Register Issue

A review is performed to verify that the issue qualifies as a joint program issue and that all information required for registering the issue has been provided. The issue is reviewed and noted by the <customer> and <your Organization> Governance Representative before the issue will be presented at the Commercial Review Forum and consequently the <your Organization>Performance Forum. The issue is registered by the <your Organization> PMO and a sequential number assigned to uniquely identify the issue.  The issue form is then submitted to the next Commercial Review Forum for qualification.

Qualify Issue

The issue is qualified by the Commercial Review Forum. Agreed Resolution will normally be provided at Commercial and/or the HIS Performance Forum.

The Commercial Review Forum qualifies the issue and assigns a person with the appropriate skills and authority to resolve the issue as the Issue Owner.  A target resolution date may be set at this time.

If an issue does not pass qualification the Issue Initiator is notified.  The initiator may elect to modify the information previously provided and resubmit the issue, escalate the rejection, submit or return the issue to delivery or project processes for management.

The Issue Initiation phase ends when one of the following occurs:

• The issue fails qualification; and,
• The issue passes qualification and is passed to the Issue Management and Tracking phase.

Issue Management and Tracking

The Issue Management and Tracking phase begins after a registered issue passes qualification and needs to be tracked by the Commercial Review Forum. 

Assign Issue Owner

When an issue passes qualification a person with the appropriate skills and authority to resolve the issue is assigned as Issue Owner.  A target resolution date may be set at this time.

When an issue passes qualification, the issue moves into the Initiate Issues Management and Tracking phase and an Issue Owner then is responsible for resolving it.

Develop Issue Resolution Plan

The responsibility for resolving a joint program issue may rest with either <customer> or <your Organization>.  In many cases the cooperation of resources from both organizations will be needed to produce a satisfactory resolution.  If a target resolution date was set during the Initiate Issue phase, the Commercial Review Forum will track to the agreed date; alternatively, a mutually agreed date will be set during the meeting.

The Issue Owner develops an Issue Resolution Plan and is responsible for obtaining the agreement of stakeholders for the proposed resolution.

Issue Resolution Plan Reviewed

The plan is reviewed by the Commercial Review Forum 

If the resolution plan is approved, the Issue Owner manages the implementation of the resolution.

If the resolution plan is not approved, it will be re-worked by the Issue Owner.

Execute Issue Resolution Plan

When the Issue Resolution Plan is approved, the Issue Owner manages the implementation of the resolution.   

Review Issue Resolution Status

Issue resolution progress is monitored against the resolution plan. Any agreed adjustments to the issue owner/resolution plan will be made where necessary.

Issue Escalation

If all efforts have failed to resolve a joint program issue it may escalated to the contractually-defined Dispute Resolution Process.

Issue Complete

The Issue Owner is responsible for obtaining the agreement of the Issue Initiator that the issue is resolved.

When complete, the Commercial Review Forum endorses the closure of the issue. 

The Issue Management and Tracking phase ends when the issue is resolved.

If the issue results in a Contract Change, please refer to the Contract Change Management Process

Issue Formal Closure

The Commercial Review Forum endorses the issue for formal closure; The <your Organization> PMO will update the issue form with agreed resolution and approval. The updated Program Issue form is then submitted to <customer> Technology Governance for audit records. 

Roles and Responsibilities

<customer>

<customer> representatives are responsible for:

• Performing the roles defined by the meeting charter for the Commercial Review Forum in the Governance Plan as appropriate;
• Participating in the review of the status of all open Program Issues in accordance with the schedule and agenda for the Commercial Review Forum; and
• Working with <your Organization> to resolve all Program Issues in a timely manner.

<your Organization>

<your Organization> representatives are responsible for:

• Performing the roles defined by the meeting charter for the Commercial Review Forum in the Governance Plan as appropriate; and,
• Participating in the review of the status of all open Program Issues in accordance with the schedule and agenda for the Commercial Review Forum; and
• Working with <your Organization> to resolve all Program Issues in a timely manner.

Commercial Review Meeting

The members of the Commercial Review M Forum meeting are specified in the Governance Plan and maintained by the Business Office.  It is responsible for:

• Ensuring a joint program issue is registered;
• Convening, in accordance with the meeting schedule and agenda detailed in the Governance Plan;
• Qualifying new joint issues;
• Assigning issue owners;
• Assigning issue priority as required;
• Agreeing the planned resolution date;
• Reviewing the status of joint issues;
• Approving resolution plans;
• Reviews resolution progress against the plan and may change the priority of the issue;
• Approve additional resources, assign a new owner or request changes to the resolution plan as required to accomplish effective and timely resolution of the issue; 
• Communicating to initiator, <customer> Technology Governance and <your Organization> PMO  if a Program Issue results in a Contract Change;
• Escalating joint issues that cannot be resolved at the program level to the contractually‑defined Dispute Resolution Process; and,
• Approving the closure of joint issues.

Issue Initiator

The Issue Initiator is responsible for:

• Ensuring that all operational avenues for resolving the issue have been exhausted prior to submitting a program issue;
• Completing and submitting the Issue Form when used;
• Reviewing and agreeing to the resolution proposed by the Issue Owner; and,
• Agreeing to the closure of the issue.

Issue Owner

The Issue Owner is assigned by the Commercial Review Forum and is responsible for:

• Managing assigned issues to resolution;
• Developing the resolution plan and gaining the agreement of stakeholders, including the Issue Initiator;
• Managing the implementation of the resolution plan;
• Obtaining the sign-off of the Issue Initiator that the issue has been resolved; and,
• Providing updated Issue Forms, if used, and status updates at the required frequency.

Authored by Vijay Chander – All rights reserved – 2023

The post Program Issue Management Process Guide! first appeared on TekTalk | Project Management Process Tool.

The post Program Issue Management Process Guide! appeared first on TekTalk | Project Management Process Tool.

Purpose & Scope

Purpose

The purpose of Knowledge Management process is to ensure that the right information is delivered to the appropriate place or competent person at the right time to enable the informed decision.

Scope

Scope includes the management of the information & data using which sufficient knowledge will be derived to support the agreed <Customer name>’s Services.

Note:

Detailed attention to the capturing, maintenance and use of asset & configuration data is under the scope of Change Management Process.

Definitions

Data

It is a set of discrete facts about event.

Information

Information comes from providing context to data.

Knowledge

Knowledge is composed of the tactic experiences, ideas, insights, values & judgements of individuals.

Wisdom

Wisdom gives the ultimate discernment of the material and having application and contextual awareness to provide a strong common sense judgement.

Knowledge Management

It is the process responsible for gathering, analyzing, storing and sharing knowledge and information within your Service Delivery systems

Service Knowledge Management System (SKMS)

It is a set of tools and databases that are used to manage knowledge and information. The SKMS includes the Configuration Management System (CMS), Known Error Data Base (KEDB) as well as other tools and databases. The SKMS stores, manages, updates, and presents all information that an IT Service provider needs to manage the full Lifecycle of <Customer Name>’s IT Services.

Roles and Responsibilities

Knowledge Management Process Owner

Responsibilities

• Undertakes the Knowledge Management (KM) role, ensuring compliance with the organization’s policies and processes.
• Is the architect of knowledge identification, capture and maintenance
• Identifies, controls and stores any information deemed to be relevant to the services provided, which is not available via any other means.
• Maintains the controlled knowledge items.
• Ensures all knowledge items are made accessible to those who need them in an efficient and effective manner.
• Monitors publicity regarding the knowledge information to ensure that information is not duplicated and is recognized as a central source of information etc.
• Acts as an adviser to business and IT personnel on KM matters, including policy decisions on storage, value, worth etc.

Input, Output

Inputs

• Errors detected during transition
• Problem Management data
• IT Service Management data

Outputs

• Service Knowledge Management System

Knowledge Management Process

References

• Procedure for Service Asset & Configuration Management
• Procedure for Incident Management
• Procedure for Problem Management
• Procedure for Change Management

Measurements

Knowledge Management is an enabling process and so demonstration of its effectiveness needs to be inferred from indirect measurement.

Reports are generated based on the below metrics.

Authored by Vijay Chander – All rights Reserved – 2023

The post A Guide to Knowledge Management Process first appeared on TekTalk | Project Management Process Tool.

The post A Guide to Knowledge Management Process appeared first on TekTalk | Project Management Process Tool.

Purpose & Scope

Purpose

The objective of Event Management process is to monitor all events that occur through the <Customer’s Name> IT infrastructure & application to allow for normal operations & also to detect and escalate exception conditions to service desk of AMS.

Scope

The scope of this process includes the customer’s IT infrastructure & application which is under the control of service desk of AMS.

Definitions

Event

An Event can be defined as any detectable occurrence that has significance for management of <Customer’s Name> IT infrastructure & application or the delivery of <Customer’s Name> IT Service.

Alert

An Alert can be defined as a warning that a threshold has been reached, something has changed, or a Failure has occurred.

Configuration Item (CI)

Configuration Item is any component that needs to be managed in order to deliver <Customer’s Name> IT Service.

Roles and Responsibilities

Operations Control Function responsibilities

• Oversees the execution & monitoring of the operational activities.
• Define central observation & monitoring capability and then using those consoles to exercise monitoring & control activities (Console management).
• Management of routine batch jobs or scripts (Job Scheduling).
• Backup & restore operations.

Service desk responsibilities

• Response to the alerts if required.
• Undertaking Incidents that have been identified by Event management and escalate to appropriate team.

Application Management Team responsibilities

• Participate in instrumentation of service, classify events and ensure the auto-responses are defined.
• Test the service to ensure the events are properly getting generated and the defined responses are appropriate.
• Deal with the Incidents & problems related to events.
• Perform Event management activities for the systems which are under the control of Application Management Service (AMS).

Input, Output

Inputs

• Event
• Threshold and Exception rules
• Instrumentation Decisions
• Thresholds

Outputs

• Communications
• Notifications
• Incident
• Problem
• Change

Event Management Process flow

The ability to detect events, make sense of them and determine the appropriate control action is provided by Event Management. Event Management is therefore the basis for Operational Monitoring and Control of <Customer’s Name> IT infrastructure.

Event Management Process flow detailed description

References

• Procedure for Incident management
• Procedure for Problem Management
• Procedure for Change Management

Measurements

Reports are generated based on the below metrics.

Authored by Vijay Chander – All rights Reserved – 2023

The post IT Event Management Process explained! first appeared on TekTalk | Project Management Process Tool.

The post IT Event Management Process explained! appeared first on TekTalk | Project Management Process Tool.

Purpose & Scope

Purpose

The objective of Incident Management process is to restore normal service operation (as defined in the SLA with <Customer’s Name>) as quickly as possible, thus ensuring that the best possible levels of service quality and availability are maintained for <Customer’s Name>’s business.

Scope

All Incidents with a (possible) negative effect on the <Customer’s Name>’s service for which a SLA is signed, lies within the scope of Incident Management

The process will be applicable to all incidents or performance related requests by customer and internal automated alerts.

Definitions

Incident

Incident is an unplanned interruption to an IT service or reduction in the quality of an IT service or failure of a configuration item that has not yet impacted service.

Major Incident

The highest Category of Impact for an Incident. A Major Incident results in significant disruption to the <Customer Name>’s Business.

A definition of what constitutes a major incident must be agreed and documented.

Configuration Item

Configuration Item is any component that needs to be managed in order to deliver <Customer’s Name> IT Service.

Workaround

The workaround is an identified means of resolving a particular incident by allowing normal service to be resumed; however, it does not actually resolve the issue that caused the incident in the first place.

Service Request

It is a request from a User for information or advice, or for a Standard Change or for Access to <Customer’s Name> IT Service.

Supplier

A Third party responsible for supplying goods or Services that are required to deliver <Customer Name>’s IT Services.

Service Knowledge Management System (SKMS)

It is a set of tools and databases that are used to manage knowledge and information. The SKMS includes the Configuration Management System (CMS), Known Error Data Base (KEDB) as well as other tools and databases. The SKMS stores, manages, updates, and presents all information that an IT Service provider needs to manage the full Lifecycle of <Customer Name>’s IT Services.

Roles and Responsibilities

Incident Manager

Responsibilities

• Driving the efficiency & effectiveness of Incident Management Process.
• Producing management information.
• Managing the work of incident support staff.
• Monitoring the effectiveness of incident management process and make the recommendations for improvements.
• Managing Major Incidents.
• Develop & manage Incident management process and procedures.

Service Desk

Responsibilities

• Accept & register incidents
• Categorize & Prioritize Incidents
• Execute Initial diagnosis to restore the incident
• Refer incidents to the appropriate Support Group
• Tracks the progress incident during entire lifecycle (from start to end, register to close) to ensure that it is resolved within the agreed Service Level Agreement (SLA) and updates incident records if necessary
• Keeping users informed of progress
• Escalate to the appropriate management level when thresholds are violated
• Closing all resolved incidents, requests and other calls
• Conducting customer/user satisfaction call backs/surveys as agreed
• Report about Incidents

Application Management Team (2^nd & 3^rd Level Support)

Responsibilities

• Incident diagnosis and resolution.
• Identify the required changes to resolve an incident.
• Identify the requirement of partner involvement and initiate the process

Input, Output

Inputs

• Phone calls
• Emails
• Web Interface
• Event
• Input from Technical Staff
• Knowledge base, Known Error Database

Outputs

• Service Request
• Communications
• Notifications
• Solutions/Workarounds

Incident Management Process

Generic Incident Management Process

The ability to detect and resolve incidents, which results in lower downtime to the <Customer Name>’s business, which in turn means higher availability of the service.

This means that the business is able to exploit the functionality of the service as designed.

Check out the other related Incident Management Blogs

Another representation and interactions between other process is shown in the diagram below:

Major Incident Management Process

A separate procedure, with shorter timescales and greater urgency, must be used for ‘major’ incidents. A definition of what constitutes a major incident management must be agreed and ideally mapped on to the overall incident prioritization system – such that they will be dealt with through the major incident management process.

Note: Most of the activities are explained in the Incident management process. Only the activities which are not discussed earlier will be discussed here.

Authored by Vijay Chander – All rights Reserved 2023

The post Incident Management Process Explained! first appeared on TekTalk | Project Management Process Tool.

The post Incident Management Process Explained! appeared first on TekTalk | Project Management Process Tool.

Purpose & Scope

Purpose

The purpose of Change Management process is to ensure that:

• Standardized methods and procedures are used for efficient and prompt handling of all changes to the <Customer’s Name>’s IT service.
• All Changes to <Customer’s Name>’s service assets & configuration items are recorded in the Configuration Management System.
• Overall <Customer’s Name>’s business risk is optimized.

Scope

Scope of the Change Management Process includes the following:

Definitions

Configuration Item

Configuration Item is any component that needs to be managed in order to deliver <Customer’s Name> IT Service.

Request for Change (RFC)

This is the formal change request, including a description of the change, components affected, business need, cost estimates, risk assessment, resource requirements, and approval status.

Service Asset

It can be any Resource or Capability that contribute to the delivery of a service.

Assets can be of the following types: Management, Organization, Process, Knowledge, People, Information, Applications, Infrastructure and financial capital.

Change Initiator

A person who initiates a request for change; this person can be a business representative or a member of the IT organization.

Change Advisory Board (CAB)

The CAB is a cross-functional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes. Typically the CAB will make recommendations for deployment, further analysis, deferment or cancellation.

Emergency Change Advisory Board (ECAB)

It is the subset of the CAB that deals only with Emergency Changes. It is established to be able to meet on short notice to authorize or reject changes with emergency priority.

Roles and Responsibilities

Change Manager

Responsibilities

• Receives, Logs and allocates a priority, in collaboration with the Change Initiator, to all RFCs; rejects any RFCs that are impractical.
• Tables all RFCs for a CAB meeting; issues an agenda and circulates all RFCs to CAB members in advance of meetings to allow prior consideration.
• Decides which people will come to which meeting, who gets specific RFCs depending on the nature of the RFC, what is to be changed and people’s areas of expertise.
• Organize ECAB meetings for all Emergency RFCs.
• Chairs all CAB & ECAB meetings.
• After consideration of the advice given by the CAB or ECAB, authorizes acceptable changes.
• Issues change schedules, via service desk.
• Liaises with all necessary parties to co-ordinate change planning, building, testing & implementation.
• Updates the change log with all progress that occurs.
• Reviews all the implemented changes to ensure that their objectives.
• Analyses change records to determine any trends or apparent problems that occur; seek rectification with relevant parties.
• Review all pending RFCs.
• Close RFCs.
• Produces regular & accurate management reports.

Change Authority

Formal change authorization is obtained for each change from change authority that may be a role, person or a group of people. The levels of authorization for a particular type of change should be judged by the type, size & the risk of the change.

Responsibilities

• Authorizes the Change based on the type, size, risk, anticipated business risk, financial implications and the scope of the change.

Change Advisory Board

Responsibilities

• Assists change management in the assessment and prioritization of the changes.
• Consider and recommend the adoption or rejection of changes appropriate for higher level authorization and then recommendations will be submitted to the change authority.
• Recommend the follow-up actions for the emergency changes and the changes implemented as workarounds to incidents.

Input, Output

Inputs

• Request For Change (RFC)
• Configuration Management System (CMS)
• Change Schedule (CS)
• Test results, test reports & evaluation reports
• Change & Release policies
• Change, Transition, Release, Deployment, Test, Evaluation & Remediation plans

Outputs

• Approved/Rejected RFCs
• New, changed or disposed assets or configuration items
• Request For Change (RFC)
• Change Schedule (CS)
• CAB/ECAB meeting minutes & actions
• Management Information (Reports)

Change Management Process

Generic Change Management Process

Standard Change Management Process

Emergency Change Management Process

Emergency change is reserved for changes intended to repair an error in an IT service that is negatively impacting the business at a high degree.

Emergency Change management process will follow the normal change management processes expect that:

• Approval will be given by the ECAB rather that waiting for a CAB meeting.
• Testing may be reduced, or in extreme cases forgone completely, if considered a necessary risk to deliver the change immediately.
• Documentation of the change record and configuration data may be deferred, typically until normal working hours.

References

• Procedure for Release & Deployment Management
• Procedure for Service Asset & Configuration Management
• Procedure for Incident Management
• Procedure for Problem Management
• Procedure for 7-Step Improvement Process

Measurements

Reports are generated based on the below metrics.

Authored by Vijay Chander – All rights reserved 2023

The post The Change Management Process explained! first appeared on TekTalk | Project Management Process Tool.

The post The Change Management Process explained! appeared first on TekTalk | Project Management Process Tool.

As the recent pandemic has taught us, businesses have to be prepared to face a host of unexpected twists and turns and be ready for them. This is very prevalent in the Manufacturing industry, that is the backbone of the world’s economy. As input costs rise, supply chain optimization becomes a key component to keep you competitive. With ageing IT infrastructure, the challenge becomes even more daunting to keep pace with technological advances, train your staff, adapt to new realities. RPA, which has been around for a while is a good start to many of these manufacturing units to take the initial step for cost-cutting while maximizing your ROI. Manufacturers are increasingly moving to wards digital transformation – which is based on Intelligent automation. Intelligent automation allows organizations to focus on standardization and fault free recording of information thereby freeing staff to focus on more strategic activities.

Though there are many situations in the usage of intelligent automation and RPA use cases in manufacturing – I am listing out 4 key areas

• Digitizing operations,
• Automated supply chains,
• Wide usage of Internet of Things (IoT), and finally
• Back-office systems

Digitizing Operations

Let us take a look at 2 key components required in Manufacturing – Production tracking and Bill of Materials (BOM)

Production Tracking in Real time: As the image indicates, today – Using intelligent automation, manufacturers can develop a near real-time overview of progress on orders and the ongoing need for components or raw materials. Manufacturers can adopt lean manufacturing methodologies that optimize scarce resources and keep margins low.

Bill of Materials: Maintaining an accurate bill of materials (BOM) is important and critical for manufacturers. The BOM contains the list of raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each component required to manufacture an end product. Using intelligent automation, manufacturers can accurately extract product data and replicate human steps required to generate an error-free BOM in a shorter timeframe.

Optimizing Supply Chains

Demand Planning: “Demand planning is a supply chain management process that enables a company to project future demand and successfully customize company output — be it products or services — according to those projections”. Predicting demand of goods and materials across multiple geographies in the supply chain requires effective digital integration and connections. Automation breaks down supply chain silos and provides insight, so goods and materials are ready where they’re required. This becomes even more important when the geographies are spread across countries or continents. A BOT can take on the responsibility of a team member by pulling in information from various sources and provide input to the shift manager so that the optimal production is achieved and the plan is available before the shift starts.

Freight and Transportation Management: Most factory floor operations have tons of data on products in the system. However the interfaces to these are not easy and require a series of steps by dedicated teams to interact with Freight systems which are external. Intelligent automation helps in navigating through these in a effective manner which is a good place to start your RPA implementation.

Inventory Management: Digital workers or BOTS are able to capture the information better than humans. This helps in advance warnings about stock replenishment so that the company does not face stock-outs which affects manufacturing. This is one area where RPA helps by providing timely information about the status of the Inventory in real time so that appropriate measures are taken. Automatic generation of purchase orders are part of this process.

IoT

IoT are becoming common place in preventive maintenance activities and act as sensors in supply chain management. Using advance machine learning along with RPA allows faults to be predicted with a high degree of accuracy thereby bringing the downtime of a machine or an assembly and alternatives the uptime of the machinery at a lower maintenance cost. This is but one area and IoTs are invading the manufacturing sector, from everything from temperature control, to counting, to detect defective products and send signals in real time.

Back Office in Manufacturing

While the specialization of manufacturing is the USP of any product organization and they have effective robotic excellence, the back office is sadly staffed with people who are prone to make mistakes. Many of these tasks can now be automated using RPA significantly reducing the errors. Some of the areas to consider in the back office for RPA include the following:

• Invoice Automation
• Order Management
• Contract Management
• Collections
• Vendor and Contractor Onboarding
• Performance Reporting

Here us a diagram to showcase an Invoice automation using RPA

With these many opportunities available, many organizations have already got a head start in implementing these. Why wait? Take the step and start to plan your RPA implementations.

Authored by Vijay Chander – 2023

The post Manufacturing Use Cases to Implement Now! first appeared on TekTalk | Project Management Process Tool.

The post Manufacturing Use Cases to Implement Now! appeared first on TekTalk | Project Management Process Tool.