CONFIGURABLE APPLICATION INTEGRATING SERVICE REQUEST AND FULFILLMENT PROCESS

Abstract

A method and system for generating a plurality of concurrent solutions for a corresponding plurality of service requests each having one or more service types. The method comprises the steps of defining a set of said service types and a sequence of activities for each said service type; and for each said service request, configuring a workflow of said activities from said service types in each said service request. The method comprises the further steps of defining owners of said activities in each said workflow and a schedule for performing said activities whereby said owner and schedule are defined using load balancing; and performing said activities and monitoring completion of said activities and said load balancing.

Description

RELATED APPLICATIONS

This application is a continuation application of U.S. Ser. No. 10/041,394 filed Jan. 8, 2002.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention generally relates to managing base processes and functions associated with a service request and fulfillment process. More specifically, the invention relates to a configurable application for managing such processes and functions in a fully integrated and automated manner.

2. Prior Art

Typically, tools and systems are available only for the discrete work functions associated with performing fulfillment tasks of a service request. These discrete processes and tools require significant manual intervention and/or customized programming to link the processes/tools in the quest to achieve increased productivity. However, problems such as process/tool compatibility, real-time interfacing, and multiple user-interfaces burden the streaming of the overall process, and hence, the productivity gain.

Current solutions for addressing this problem address only pieces of a full solution. Significant manual intervention is required to link the processes together. Even then, consistent reporting among the various processes is still not available.

SUMMARY OF THE INVENTION

An object of this invention is to provide a solution that fully integrates, and hence automates, the base processes and functions associated with a service request and fulfillment process.

Another object of the present invention is to provide a method and system that integrates planned and non-planned services, specific service requests, workflow, fulfillment planning and tracking, and measurements reporting.

A further object of the invention is to provide a fully configurable application for managing base processes and functions associated with a service request and fulfillment process, so that end-to-end processes and internal processes can be tailored to the desired cumulative result.

These and other objectives are attained with a method and system for generating a plurality of concurrent solutions for a corresponding plurality of service requests each having one or more service types. The method comprises the steps of defining a set of said service types and a sequence of activities for each said service type; and for each said service request, configuring a workflow of said activities from said service types in each said service request. The method comprises the further steps of defining owners of said activities in each said workflow and a schedule for performing said activities whereby said owner and schedule are defined using load balancing; and performing said activities and monitoring completion of said activities and said load balancing.

The preferred embodiment of the invention, as described below in detail, eliminates the problems associated with manually piecing together tools and processes. It offers seamless integration and automation of all process steps while providing real-time tracking and information access capability. By leveraging, for example, a Lotus Notes Domino infrastructure, all features and advantages of an enterprise groupware system, such as security, scalability, mobility, internet access, database replication, database conflict resolution, personalized private views, etc., apply.

Further benefits and advantages of the invention will become apparent from a consideration of the following detailed description, given with reference to the accompanying drawings, which specify and show preferred embodiments of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 outlines a preferred method embodying the present invention.

FIG. 2 illustrates a service request manager that may be used in the practice of this invention.

FIGS. 3-5 generally illustrate a workflow pattern employed in the present invention.

FIG. 6 illustrates components, and their relationships, of the service requirements manager of FIG. 2.

FIGS. 7-11 show views that may be presented during the course of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

With reference to FIG. 1, the present invention, generally, relates to a method and system for generating a plurality of concurrent solutions for a corresponding plurality of service requests each having one or more service types. The method comprises the steps of defining a set of said service types and a sequence of activities for each said service type; and for each said service request, configuring a workflow of said activities from said service types in each said service request. The method comprises the further steps of defining owners of said activities in each said workflow and a schedule for performing said activities whereby said owner and schedule are defined using load balancing; and performing said activities and monitoring completion of said activities and said load balancing.

FIG. 2 shows a technical overview of a service request manager (SRM) with which this invention may be used. Generally, the SRM provides several major functions, including service offering definition, customer contract interlock, customer requests for service, service provider workload/workflow management, and customer request status report.

The present invention has been developed and implemented for improving service delivery efficiency associated with workstation environment management. Historically, use of individual processes and tools require additional administrative effort and resources to perform the processes and merge information between processes. This mode of operation heavily relied on the combined skill levels of the participants to create a smooth-running, end-to-end process. Often, changes to planned events or additional requirements created problems within and between the discrete processes. The present invention provides a single user interface, configurable workflows, and automated real-time tracking capabilities to eliminate process overhead and inaccuracies, while increasing information access through a standard environment.

Preferably, with reference to FIG. 3, the preferred implementation of the invention involves request planning, building/configuring a solution, and delivering that solution. FIG. 4 provides an example of a workflow that may occur in the course of the invention. In this workflow, a client is scheduled, a solution is built/configured, with data back-up, data is restored, and the solution is delivered to the client. FIG. 5 provides an example of how this workload may be distributed. The client scheduling could be done by a Queue Manager, the building/configuring of the solution could be done by the another manager, the data back-up could be performed by one person, and the data restore and delivery to the client could be done by another person.

In the preferred implementation of the invention, a database, referred to as the service requirement manager database, is used. The database could be, for example, a Lotus Notes database that is used by the service delivery teams to track plans, requests, and delivery activities for their services.

Using the database, the various teams can: Create plans for services for a customer; Create Service Requests for clients; Prioritize the requests; Assign deployment personnel to perform the delivery activities; Quickly determine which clients must be scheduled for service delivery; Balance daily workloads; Track the delivery activities; View personal work “to-do” for each delivery team member; Assist the deployment team members in the weekly claiming of billing hours to the customer; View the plans vs. actuals; and View the status of plans, requests, and activities.

With reference to FIG. 6, The SRM has several main components referred to as “plans,” “service requests,” “delivery activities,” “measurements,” and “user definable keywords, rules and tables.” A “plan” identifies, for each business area (identified by an account group id), the total number of people that are planned to receive a specific type of service from the service delivery team during the plan year. (These are services such as a new workstation, or a software upgrade.) Plans are made for each specific Account Group Id and Service Type. A “service request” is a request for a specific service for a specific client.

“Delivery activities” are the activities necessary to deliver a service (such as “schedule the client,” and “customize software,” etc.). Each activity is assigned an owner name (someone on the delivery team) to perform the activity. Each activity has a status that is used to track the progress of the activity. “Measurements” are views as requested by the customer. These include, for example, Plans vs. Requests, Delivery team utilization, and workload analysis. “User definable keywords, rules and tables” include flexible data that can be created and updated at any time by the customer. These include, for instance, field keywords, services, activities, and work flows.

The SRM includes a number of processes. These include (1) Services, activities, and work flow are defined; (2) Plans are created for services; (3) Requests are made for services; (4) Service request activities are performed; and (5) Progress is monitored using the various views. These processes are discussed below.

Services, Activities, and Work Flows are Defined.

As new services are needed, various services and related matters are defined. In particular the DCS services, the activities required to deliver those services, any additional information that needs to be collected for the services or activities, and the sequence of the activities to be performed are all defined. In this implementation, the services are defined using the “Service Definition” form. The activities are defined using the “Activity Definition” form. The work items are defined using the “Work Item Definition” form. The workflow activities and their sequences are defined using the “Workflow Activity Definition” form.

Plans are Created for Services.

Customer representatives create plans for services by creating Plan documents. Although not necessary, the DCS Site Reps may then commit the plans for DCS services by using a “Commit” action button.

Requests are Made for Services.

First, customer representative creates a request for service for a specific client (person) by creating a Service Request document. Then the delivery team rep either approves or rejects the request for service (using an action button). If the request is approved, then Service Request Activity documents are created by the application based on the activities in the “work flow” (i.e., the activities necessary to complete a service). There is one document for each activity that must be performed. For example, a service request for “Notes Deploy” could have five service request activities: “Schedule the client,” “Kit the hardware,” “Load the image,” “Deploy to client,” and “Close.”

Service Request Activities are Performed.

In this implementation someone on the delivery team assigns an owner (using an action button) to an activity. The owner is the name of someone on the delivery team that will perform the specific activity. When an owner is assigned to the first activity in the work flow, the status of that activity is automatically set to “In progress.” The activity automatically appears in the personal “to-do” view of the person that was assigned as the owner. The assigned owner performs the actual work for any activities that have a status of “In progress.” If additional move, add, or change activities are required for the request, the delivery team can add “MAC” activities to the request in-progress by using an action button.

For certain predefined activities, the owner will collect and update deployment details (serial numbers, license info, etc.) from and to the site's Asset Management database. Once an activity has been “worked,” the owner enters any “additional information” required for that activity on the Service Request Activity document, and then updates the status of the activity (using an action button) to “Completed,” “Exception Review,” or “Bypassed.” As each activity is completed, the status(s) of the succeeding activity(s) is/are automatically changed to “Pending” if an owner has not yet been assigned, or to “In progress” if an owner has been assigned. When the last activity is completed, the status of the entire service request is changed to “Completed.”

Progress is Monitored Using Various Views

Views that may be used to monitor progress include. The annual number of planned services vs. the number of requests that are new, committed, in progress, completed, rejected, or canceled; The number of planned services vs. the number of requests that are new, committed, in progress, completed, rejected, or canceled for each quarter; The detailed committed, in-progress, or completed requests; The status of the requests and their activities; The clients that are currently scheduled or waiting to be scheduled; and The current deployment team workload.

Access to the database is controlled through the database access control list (ACL). The ACL contains group names with “roles” assigned to each group. The names of the people in each group are defined and maintained in the Notes Names and Address Book by their assigned owners.

Documents can be read only by those with the proper authority. Users can only see and read a document if their name or role is listed in the Readers field in the Document Control section of the document. This prevents a customer in one business area from seeing the plans, requests, and activities for another business area, but allows the delivery team managers to see the information for all business areas.

Document creation is restricted by individual forms and by ACL groups. The creator of a document is automatically the document “author.” The document author can add additional authors and readers to a document. Only the document authors can edit the document.

The SRM has the following user roles: Admin (Application Coordinator/Administrator); Representative for the delivery team; BAR (Customer Rep); BATR (Business Area Technical Rep); Delivery; Asset Management (AM); and DCSMgr (Distributed Computing Services manager). The Admin can edit and view all documents, change the status of any document, create keyword documents, create help documents, and do anything that the SiteRep role can do. The SiteRep can define services, activities, and workflows, create plans and requests, commit a Service Plan, Approve/Reject a Service Request, and do anything that the Delivery role can do. The BAR can create plans and requests, and edit and view only the plans or requests for which the user is the BAR. The BATR can create plans and requests, and edit and view only the plans or requests for which the user is the BATR. The Delivery can create plans and requests, assign an owner to an activity, Complete/Bypass an activity, place an activity in exception status, and add a MAC activity to a request in progress. The AM can see the buttons on the Service Request Activity to retrieve and update data from and to the Asset Management database. (The buttons only work if the user also has the proper access levels to the Asset Management database.) The DCSMgr can read all documents.

FIGS. 8-10 show a sample of the views accessible to the different user groups. FIG. 7 illustrates a user interface that may be provided to help navigate to other associated databases available to the different users.

This implementation of SRM is a Lotus Notes Database that uses “forms” to create “documents.” These forms are discussed below.

Activity Definition Form

The site reps use this form to define a service activity. These activities are used in the workflow for a Service/Service Type.

DBRule Form

The application programmer uses this form to define the database location information. The information is used to access other databases.

Help Form

The application coordinator uses this form to create application specific help for the users and administrators.

Keyword Form

The application coordinators use this form to setup the values of a “user-defined” keyword. The keywords are used for field selection choices.

Reporting Calendar Form

The application coordinator uses this form to define the dates that are used for reporting cutoffs. The dates are used to categorize completed requests and activities in a view.

Service Definition Form

The site reps use this form to define the information about a specific Service/Service Type. This includes the campus where offered, is it billable?, a description, etc.

Workflow Definition Form

The site reps use this form to define an activity as an ordered step in the workflow for a specific Service/Service Type. It includes the sequence number in the workflow, name, description, predecessor activities, successor activities, etc.

Work Item Definition Form

The site reps use this form to define a work item that is used for billing for a specific campus. When a Service Plan is created, work items are selected from the list of defined work items for the campus.

Service Plan Form

The site reps use this form to record the annual plan for a Service/Service Type.

Service Request Form

The customer reps and the technical reps use this form to request a service for a specific employee (client). This includes which quarter the request is needed, the priority, the employee name, id, div, phone, platform, etc.

Service Request Activity Form

These documents are created automatically when a Service Request is approved. A work activity is for a specific Service Request. It includes the activity code, sequence number, predecessors, successors, owner, etc. The delivery team uses this form to assign ownership, track an activity, and collect deployment details.

The SRM database includes several views grouped by user role or task. These views include a Help View, BAR Views, SiteRep Views, Deployment Views, Scheduling Views, Definition Views, Admin Views, and Personal Views.

The Help View shows all application specific help documents. The BAR (customer) Views show Annual Plans and Requests; Quarterly Plans and Requests (one view for each quarter); Plans, Requests and Activities, and Plans vs. Completed Requests. The SiteRep Views show Annual Plans and Requests; Quarterly Plans and Requests (one view for each quarter); Plans, Requests, and Activities; and Completed Activities by Month. The Deployment Views show all Requests and Activities by Client; All Requests and Activities by Campus, BAR, Client; and Completed Activities.

The Scheduling Views show Active Requests and Activities by Date, Client; and Active Requests and Activities by Owner, Activity (for workload balancing). The Definition Views show Activities; Services; Work Items; and Work Flow Activities. The Admin Views show All documents; DB Rules; Deleted documents; Keywords; Calendar; and Any other special views for admin support. The Personal Views show personal “To Do” for an Activity Owner.

While it is apparent that the invention herein disclosed is well calculated to fulfill the objects stated above, it will be appreciated that numerous modifications and embodiments may be devised by those skilled in the art, and it is intended that the appended claims cover all such modifications and embodiments as fall within the true spirit and scope of the present invention.

Claims

1-15. (canceled)

16. A database configured to operate as a service request workflow engine to implement various service request workflows, wherein a service request workflow implements a sequence of activities for at least one service request type comprising on of the service request workflows, comprising:

a repository for storing a plurality of service request type definitions, wherein each service request type definition comprises a plurality of activities required for completing workflow associated with the type;

a user interface that allows users to interface to the database to initiate a service request workflow by associating at least one service request type for the service request workflow, and interacting with the database to provide necessary parameters for the at least one service request type; and

a workflow processor that responds to an initiated service request workflow by storing the at least one service type definition comprising the user-initiated workflow, and processing the necessary parameters to execute the service request workflow.

17. The database set forth in claim 16, wherein each service request type comprises a sequence of workflow activities.

18. The database set forth in claim 16, wherein the user interface allows users to choose predetermine service request workflows including at least one service type and corresponding sequence of activities.

19. The database set forth in claim 16, wherein said workflow processor coordinates the activities comprising a service type workflow comprising a service request workflow with associated electronic data systems or executable applications in communication with the database that execute one or more activities.

20. The database set forth in claim 19, wherein the user interface and work flow processor together provide for real-time tracking of completion of activities implemented in a service request workflow.

21. The database as set forth in claim 16, wherein the workflow processor automatically searches for and locates parameters required for a service request workflow by communicating with other databases, electronic data systems and executable applications associated with the service request workflow.

22. The database as set forth in claim 16, wherein the database may be reconfigured as new service request workflows are required to be implemented by the database.

23. The database as et forth in claim 16, wherein users may access and use the database for requesting services associated with service request workflow in association with a role definition for the user included in a data access control list.

24. The database as set forth in claim 23, wherein documents are presented to users via the user interface only if the user attempting to access said documents has authorization commensurate with authorization required for the access.

25. The database as set forth in claim 16, wherein service request types are configured as predefined forms, or workflow type definitions, and the parameters for the sequences of workflow activities are automatically associated to owners of respective activities deriving from the parameters input at initiation.

26. The database as set forth in claim 25, wherein owners are assigned to the activities, which owners are responsible for carrying out tasks for the activities, and reporting a status of each task to the database.

27. The database as set forth in claim 16, wherein service request workflows are approved after initiation and before execution.