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 Release and deployment Management process is to:

• Define and agree release and deployment plans with <Customer’s Name> and stakeholders.
• Ensure that each release package consists of a set of related assets and service components that are compatible with each other.
• Maintain the integrity of a release package and its constituent components throughout the transition activities and accurately record them in the CMS.
• Ensure that you can track, install, test, verify, and, if necessary, uninstall or back out all release and deployment packages..
• Ensure active management of organizational and stakeholder change during release and deployment activities.
• Record and manage deviations, risks, issues related to the new or changed service and take necessary corrective action.
• Ensure that there is knowledge transfer to enable the <Customer’s Name> and its users to optimize their use of the service to support their business activities.
• Ensure the effective and efficient delivery, support, and maintenance of the service according to required service levels by transferring skills and knowledge to operations and support staff…

Scope

The scope of the Release and Deployment Management Process encompasses packaging, building, testing, and deploying a release into production for , including their processes, systems, and functions within the defined frozen scope, to establish the desired service.

Definitions

Release

A collection of hardware, software, documentation, Processes or other Components required to implement one or more approved Changes to <Customer Name>’s IT Service. Manage, test, and deploy the contents of each release as a single entity.

Change

The addition, modification or removal of anything that could have an effect on <Customer Name>’s IT Service.

Configuration Management System (CMS)

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

This includes tools for collecting, storing, managing, updating, and presenting data about all CI 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.

Configuration Item

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

Configuration Baseline

It is a Baseline of a Configuration Items that has been formally agreed and is managed through the Change Management process that is decided by your organization.

A Configuration Baseline is used as a basis for future Builds, Releases and Changes.

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.

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.

Roles and Responsibilities

Release and Deployment Manager

Responsibilities

• Manages all aspects of the end-to-end release process.
• Updates the SKMS and CMS.
• Ensures coordination of build and test environment team and release teams.
• Ensures teams follow the organization’s established policies and procedures.
• Provides management reports on release progress.
• Release and deployment policy and planning.
• Deals with release package design, build and configuration.
• Deals with release package acceptance including business sign-off.
• Deals with service roll-out planning including method of deployment.
• Deals with release package testing to predefined Acceptance Criteria.
• Signs off the release package for implementation.
• Deals with communication, preparation and training.
• Audits hardware and software before and after the implementation of release package changes.
• Installs new or upgraded hardware.
• Deals with storage and traceability/audit-ability of controlled software in both centralized and distributed systems.
• Deals with release, distribution and the installation of packaged software.

Release Packaging & Build Manager

Responsibilities

• Establishes the final release configuration (e.g. knowledge, information, hardware, software and infrastructure).
• Builds the final release delivery.
• Tests the final delivery prior to independent testing.
• Establishes and reports outstanding known errors and workarounds.
• Provides input to the final implementation sign-off process.

Deployment Staff

Responsibilities

• Deal with the final physical delivery of the service implementation.
• Coordinate release documentation and communications, including training and customer, Service Management and technical release notes.
• Plan the deployment in conjunction with change and Knowledge Management and Service Asset & Configuration Management.
• Provide technical and application guidance and support throughout the release process, including known errors and workarounds.
• Provide feedback on the effectiveness of the release.
• Record metrics for deployment to ensure within agreed SLAs.

Early life support staff

Responsibilities

• Provide <Customer Name>’s IT service and business functional support from prior to final acceptance by Service Operations.
• Ensure delivery of appropriate support documentation.
• Provide release acceptance for provision of initial support.
• Provide initial support in response to incidents and errors detected within a new or changed service.
• Adapt and perfect elements that evolve with initial usage, such as:
  • User documentation
  • Support documentation including service desk scripts
  • Data management, including archiving
• Embed activities for a new or changed service
• Deal with formal transition of the service to Service Operations.
• Monitor incidents and problems, and undertake problem management during release and deployment, raising RFCs as required.
• Provide initial performance reporting and undertake service risk assessment based on performance.

Build & Test Environment Staff

Responsibilities

• Ensure service infrastructure and application are built to design specification.
• Plan acquisition, build, implementation and maintenance of the infrastructure
• Ensure build delivery components are from controlled sources
• Develop an integrated application software and infrastructure build
• Deliver appropriate build, operations and support documentation for the build and test environments prior to handover to Service Operations
• Build, deliver and maintain required testing environments.

Input, Output

Inputs

• Request For Change (RFC)
• Service Package
• Continuity Plan
• Service Management Plan
• Technology Standards
• Build models & plans
• Environment requirements and specifications for build, test, release, training, disaster recovery, pilot and deployment
• Release policy and release design from Service Design
• Release and deployment models including template plans
• Exit and entry criteria for each stage of release and deployment.

Outputs

• Release and deployment management plan
• Completed RFCs for the release and deployment activities
• Notifications
• Updated service catalogue with the relevant information about the new or changed service
• New or changed service reports
• Deployment ready release package (baselined) for future deployments

Release and deployment Management Process

Generic Release and deployment Management Process  

Emergency Release and Deployment Management Process

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

Emergency release management process will follow the normal release management processes and will be governed by Emergency Change management.

References

• Procedure for Change Management
• Procedure for Service Asset & Configuration Management
• Procedure for Service Validation and Testing

Measurements

Reports are generated based on the below metrics.

Authored by Vijay Chander – All rights Reserved – 2023

The post Process flow for Release and Deployment Management first appeared on TekTalk | Project Management Process Tool.

The post Process flow for Release and Deployment Management 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.

As you start to work as a Project manager, your duties include monitoring your project metrics. How your project performs is a key indication of tracking success or failure in which case corrective measures are applied early. Though there are several of these metrics we focus on two key ones. Project metrics is a tool monitored and defined in the Project Management process flow.

Effort Variance

Scheduled Variance

Definition: Any difference between the scheduled completion of an activity and the actual completion is known as Schedule Variance.

Schedule variance = ((Actual calendar days – Planned calendar days) + Start variance)/ Planned calendar days x 100

Effort Variance

Effort Variance: The difference between the planned outlined effort and the effort required to actually undertake the task is called Effort variance.

Effort variance = (Actual Effort – Planned Effort)/ Planned Effort x 100

The slide at the top of this article explains very clearly the method put up in a manner easily understood by every team member. You can get them involved by asking them to develop similar slides for Scheduled Variance, Productivity, etc.,

A key function of project managers is making the team understand the importance of these Key metrics and how it affects the overall project. From experience, I’ve noticed that my team of programmers and systems analysts are not interested in ‘Management Subjects’ and would rather focus on design and programming. Explaining these metrics is not easy and one of the suggestion is to present slides that is easy to consume. A picture is worth a hundred words! An example of how to showcase it and visually help your team members remember and adopt it as part of their regular work and understand the importance to the over health of the project.

You can adopt this method further when applying it to SCRUM by showing what a sprint effort variance is for, there are several other infographics available.

Whatever the method you want to use it for, the way it is calculated remains the same. There have been several cases where there is a discrepancy in what value to use for an actual effort in a sprint based on the number of stories you have. There will be discussions and discrepancies, but it is all healthy as your team is now participating in a discussion and ultimately understanding the importance. Ultimately, this is the purpose of any project metrics as it is supposed to help the team stay involved for the success of the project!

Authored by Vijay Chander – All rights Reserved 2022

The post Get Team buy-in to successfully adopt/follow Project Metrics first appeared on TekTalk | Project Management Process Tool.

The post Get Team buy-in to successfully adopt/follow Project Metrics appeared first on TekTalk | Project Management Process Tool.

As part of a team and an organization, it is critical that work you do is documented in a professional manner and visual workflows are a way to go. It can be a simple task, or a complex one you are working on – the onus is on you to showcase it in a professional manner. By doing so, you are documenting your work, make it easy to transfer knowledge to your peers or subordinates and add to the pool of digital assets of your organization.

Putting in a little effort goes a long way in standing out and is a way to publish your work for visibility. As employees we perform many mundane tasks that are never appreciated but critical to your organizational goals. The image above is a simple task performed by a HR Executive, which is done many times over, but is an key task in your department and organization. Make your work interesting by documenting these tasks professionally, and soon, you will have a collection that you can catalogue and publish. Your work, however small is important to the organization, and it up to you to enjoy your work by making it interesting for yourself by innovating.

Here is a simple example of showcasing a workflow for preparing an offer letter and sending it out for approval inside the organization. It is this simple! Create similar slides for the continuation of this work.

Benefits of a Visual Workflow are:

• Adding easy to under visualization – (A Picture is worth a thousand words)
• Removes complexity by breaking into small, easy to understand parts
• Easy to learn, adopt, and implement across the department and organization
• Faster to implement and communicate
• Increases productivity by eager participation

Authored by Vijay Chander – All rights Reserved 2022

The post Creating a Professional Work Flow first appeared on TekTalk | Project Management Process Tool.

The post Creating a Professional Work Flow appeared first on TekTalk | Project Management Process Tool.

Many organizations are looking for ways to improve efficiency and are looking at RPA (Robotic Process Automation) as a solution that can be applied. There are many tools available to make life easy and the list of areas where automation can be applied is endless. Most persons today are familiar with bots, short for ‘robots’ that work effortlessly in the background for you by doing repeated tasks. A common usage is a chat bot which you interact, that gives you predefined answers based on a predefined common question set. As a business, you are constantly looking for ways to save money and automation must have crossed your mind several times. A starting point is to write use cases for RPA. This however is not an easy task. Implementing automation is a costly affair – buying reliable automation software, having the right technical persons to support and implement the solution. All situations do not lend themselves to the path of automation as you must be able to justify the cost/benefits of the implementation. Choosing a business case over another is critical – based on must-have, urgency, customer satisfaction or increase in sales among a myriad of decisions that come up before implementing and choosing ‘What to Implement?’

Framing a good problem statement is the most essential part of the success of an RPA implementation. How well you frame a question is directly proportional to getting the best answer. In the field of Operations Research, the utmost importance is given to framing a question, which lends to giving out an elegant solution while setting boundaries, which in a purely business sense is a specific re-occurrence or an event in specific circumstances. For example, sending a price list to a customer who has requested it, scanning an invoice and posting it in a ledger, pay out employee expenses weekly based on bills submitted, etc., The list is endless. However all lists are not equal and as an organization you want to implement where it makes the most sense financially, and in some cases where you want to attract more business by focusing on a superior customer experience.

So, now the big question is how to present your case to the management to implement your specific business need. You write use cases for RPA – specifically! Not every one is qualified to write them, but with a little practice you can do so. If you have dealt with IT consultants, you know that very few are adept on the business and their focus is more on the technical. In fact, it is the business who spend the most time in imparting the knowledge to the IT consultant. What finally comes out is a use case that is presented by the IT consultant, but you can do that yourself.

Let us look at a simple use case presented below.

Well, now that you have decided on a format, you may add details that you send to your higher ups. We have 40 operators, bring down AHT by 200% viz. 4:30 minutes to 1:30 thus saving and giving a better customer experience. Total savings in a month is X. Thus you have presented an excellent business case which goes through the normal process of budget approval and so forth.

Here is another example

Though the example above is for IT professionals handling tickets, it can easily be expanded to a customer complains group. You can easily see the benefits of an enhanced customer experience.

To summarize, it is easy to write use cases for RPA as you are the frontline person who is experiencing the problems on a day-to-day basis. The examples and advise in this article is to get you started – not the end all – your own business may be much more complicated and may require to be more exact and detailed. You are the most qualified person to write them – don’t let anyone else tell you otherwise. It takes practice and patience to get it right like every other skill. You can make a career for yourself, for identifying use cases that helps organizations save money – leading to better efficiency. Implementation takes time, and you may be guided initially, but you will learn from those experiences. Learning to use automation tools/software like UIPath, Automation Anywhere and Blue Prism does not require major effort and can be mastered in a short time. Always be on the lookout in your organization to find things to automate – you will be rewarded – firstly to yourself and your organization and the pride and sense of accomplishment that comes with it.

Authored by Vijay Chander – All rights Reserved 2022

The post Impress your business bosses by writing Use Cases for RPA first appeared on TekTalk | Project Management Process Tool.

The post Impress your business bosses by writing Use Cases for RPA appeared first on TekTalk | Project Management Process Tool.