CLIAMS:
1. A system for collaborative engagement comprising:
a processor; and
a memory coupled to the processor, wherein the memory has a plurality of modules stored therein that are executable by the processor, the plurality of modules comprising:
an Input Module to receive service request data from an initiator;
a Profiler to validate the service request data received from the initiator;
an Action Module to abstract an input data from the service request data received at the Input Module;
a Workflow Monitor to dynamically initiate a workflow and generate a workflow data for the input data processed by the Action Module;
a Database to store and manage the input data processed by the Action Module and create and manage a vendor-related data dynamically;
an Analytics Module to assess, predict trends, generate alerts and create visualization reports based on the input data;
Tender Management to generate tender data and dynamically update the vendor related data in the Database.
2. The system as claimed in claim 1, wherein the service request data to the Input Module comprises at least location data, type of request and mode of request.
3. The system as claimed in claim 1, wherein the Profiler records a profile data of the initiator; allocates a profile identifier and further creates activity level of the initiator.
4. The system as claimed in claim 3, wherein the Profiler (112) records profile data of the initiator through an associated telecom service provider.
5. The system as claimed in claim 1, wherein the Action Module comprises:
Clustering Module to analyse and logically group the input data into at least one of location code, type of work and priority;
Routing Module to determine the routing of the input data to a local area action centre, further determined from the location information.
6. The system as claimed in claim 1, wherein the Database further comprises:
Area Resolution Data Store to determine location code from location information and map such determined location code to at least one vendor data;
Vendor Database comprising dynamically updated vendor score for vendor data mapped to the assigned location code.
7. The system as claimed in claim 1, wherein the Workflow Monitor comprises initializing at least a first workflow for the service request data, wherein the first workflow is assigned to at least one local area action centre and at least one vendor data.
8. The Workflow Monitor as claimed in claim 7, wherein the first workflow assigned to at least one local area action centre comprises workflow data, which further comprises defined tasks and service level agreements for the task.
9. The system as claimed in claim 1, wherein the Analytics Module further comprises:
Scoring and Optimization to assess the vendor performance using a prescribed assessment template and dynamically update the Vendor Database with an updated vendor score;
Trend and alerts to determine trends and patterns from the service request data for requests executed by the vendor for the local area action centre and despatch alerts to profile identifiers of initiators stored in the Profiler;
Report Cards and Visualization to generate visual reports of the service request data for decision making and data analysis.
10. The system as claimed in claim 9, wherein the Scoring and Optimization computes a vendor assessment score as per the prescribed assessment template, wherein the prescribed assessment template further comprises attributes of defined service level agreement hours, score configured to rate of completion of hours, bonus score, priority of the service request, type of work, score post inspection of completion of work, score and feedback received from initiators.
11. The system as claimed in claim 1, wherein the Tender Management module is configured to compute a vendor credit rating based on data from the Analytics module and from the Vendor Database.
12. The Tender Management Module as claimed in claim 11, wherein the vendor credit rating is computed by sorting the vendor score in an order and the said vendor credit rating thus generated is linked to ERP applications to determine a tender deposit due by the vendor.
13. The system as claimed in claim 1, wherein the system is implemented for e-governance.
14. A computer implemented method for collaborative engagement based e-governance, wherein the method comprises:
receiving, by the Input Module, service request data from an initiator;
creating, by the Profiler, a profile data set of the initiator subsequent to receiving the service request data;
performing, by the Action Module, an initial processing of the service request data;
initiating, by the Workflow Monitor, a first workflow for the service request data subsequent to initial processing;
storing and managing, by the Database, data attributes pertaining to a location code and a vendor related data of the service request data;
assessment, by the Analytics Module, of service request data to create vendor score, generate alerts, predict trends and visualization reports;
dynamically creating and updating, by the Tender Management Module, a vendor credit rating for the vendor based on the assessment.
15. The method as claimed in claim 14, wherein the service request data comprises at least location data, type of request and mode of request;
16. The method as claimed in claim 14, wherein the profile data set comprises data obtained from an associated telecom service provider of the initiator, a profile identifier, activity level of the initiator and enhanced profile information.
17. The method as claimed in claim 14, wherein the initial processing of the service request data comprises:
verifying by the Profiler integrity, duplicity of a service request received from an initiator;
assigning by the Action Module, priority to the service request data received;
clustering of the service request data by the Clustering Module into categories based on attributes of at least one of location, priority and type of work;
routing of the service request data by the Routing Module to a local area action centre based on the location attribute.
18. The method as claimed in claim 17, wherein the location attribute of the service request data is resolved by the Area Resolution Data Store into location code.
19. The method as claimed in claim 14, wherein at least a first workflow is initialized for the service request data, wherein workflow initialization comprises:
assigning the service request data by the Action Module to at least one local area action centre;
assigning by the Vendor Database at least one vendor to service the pre-processed request data;
defining by the Workflow Monitor milestones, tasks for a milestone and service level agreements for the task by the at least one local area action centre to the at least one vendor.
20. The method as claimed in Claim 14, wherein the assessment further comprises:
computing a vendor score based on a prescribed assessment template for the vendor and dynamically updating the vendor data with at least one vendor score;
generating alerts and analysis of trends for the service request data.
21. The method as claimed in claim 20, wherein the assessment further comprises computing a vendor score as per a prescribed template, wherein the template further comprises attributes of defined service level agreement hours, score configured to rate of completion of hours, bonus score, priority of request, type of work, score post inspection of completion of work, score and feedback received from initiators.
22. The method as claimed in claim14, wherein the dynamically updating of the vendor credit rating comprises generating a vendor rating based on ranking the vendor score in an order and associating the vendor credit rating to an ERP application to determine tender deposit for a vendor, further the updating of the vendor credit rating is revised at least once on change in the vendor score.
,TagSPECI:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
SYSTEM AND METHOD OF COLLABORATIVE ENGAGEMENT FOR E-GOVERNANCE

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the embodiments and the manner in which it is to be performed.
CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY

[001] The present application does not claim priority from any patent application.

TECHNICAL FIELD

[002] The present invention relates to a system and method for monitoring, management and maintenance of citizen amenities, more particularly, this invention relates to system and method monitoring, management and maintenance of citizen amenities in the field of e-governance.
BACKGROUND

[003] Citizens are entitled to amenities facilitated by Governments and associated local government bodies (municipalities, counties etc.).These amenities include but are not limited to water supply, electricity generation and distribution, road and maintenance, housing, transport, lighting and other services.

[004] Provision of amenities are susceptible to scenarios of breakdowns causing inconvenience to the citizens. Though efforts are laid down to manage these services in time yet in scenarios of delays and continued inconvenience, the citizen is entitled to register complaints wherein the process of registering complaints, resolving complaints and managing them needs to be participatory and must invite engagement from all stakeholders.

[005] The process and system of constant monitoring, management and maintenance of basic amenities and transaction based services involves various macro and micro-level activities and stake holders involved in multi levels of such macro and micro-level activities. Furthermore, such process of constant monitoring and management is resource intensive. To ensure timely completion of maintenance activities, on field tracking and monitoring becomes a prerequisite. In furtherance maintenance and management of amenities also comprise activities such as vendor selection and Contract allocation, Service level agreement monitoring, and routing of data on time to appropriate local body require extensive and comprehensive management and monitoring.
[006] Currently, the process of managing and monitoring provision of citizen amenities is handled manually with the handicap of extra effort and time taken to track basic details let alone closing any grievance within the stipulated timeframe. Further, the process involves too much paper trail which makes any citizen finding it difficult to submit a complaint regarding any breakdown/failure. This is primarily due to non-establishment of workflow based system, lack of monitoring in resolution and non-capture of citizen sentiment regarding any complaint with respect to citizen’s basic and transaction based services. In addition, the local bodies (associated government bodies) do not effectively predict breakdowns and take measures after a complaint is raised by citizens. Even if, such complaints are addressed by the local bodies, there is no such system at play to track down the maintenance activities planned and executed by local bodies and to send alerts related to such activities to a complainant and/or citizens. There is a need for common platform wherein the complainants/ citizens can be alerted in relation to the maintenance activities planned and executed by the local bodies.

[007] The present invention enables and ensures the transparency of the eco-system of e-governance in relation of disbursing amenities for citizens. Further, as compared to prior art, the present invention enables real time evaluation and assessment of vendors and their engagement by government and local bodies.
SUMMARY

[008] This summary is provided to introduce concepts related to a system and method of collaborative engagement fore-governance and the concepts are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[009] The primary object of this invention is to monitor, manage and maintain citizen amenities as provided by governments’ and local bodies through a computer implemented system.
[0010] Another object of this invention is to enable real-time processing of service request data received from initiators enabling quicker resolution, through a method where service levels and tasks associated to fulfil a service request are defined and at the same time display real-time progress of fulfilment to initiators.
[0011] Yet another object of the invention is to enable collaborative engagement between stakeholders- initiators, local area action centres, and vendors through a computer implemented system.
[0012] Another object of the invention is to enable dynamic allocation of service request to vendors as per a vendor rating for more efficiency in processing a service request.
[0013] Systems and methods for enabling collaborative e-governance to fulfil service requests pertaining to provision of civic amenities and improving resolution of service requests in an objective manner is disclosed. In an embodiment, systems and methods for collaborative e-governance is disclosed. The system can include one or more processors, memory operatively coupled to one or more processors for storing system modules that can be configured to receive a service request, abstract input data from service request data and further process and route the service request. In an embodiment, system of the present invention comprises an input module, configured to receive service requests from initiators/citizens, a Profiler module to validate the service request, an Action module configured to abstract location details, assign priority, determine type of work and route the request to an appropriate local area action centre and to vendor; a Workflow Monitor to manage the service request through its stages of processing; an Analytics module to perform scoring and assessments, predict trends and generate alerts to stakeholders in the process . In an embodiment, the system of the present disclosure may further comprise a database configured to store a map of location codes for location information received and a database of vendor information comprising vendor assessment scores which are dynamically updated on change in score. Further, the system also comprises a Tender Management module that is linked to other ERP systems to perform vendor management.

BRIEF DESCRIPTION OF DRAWINGS

[0014] The foregoing summary, as well as the following detailed description of preferred embodiments, are better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention; however, the invention is not limited to the specific methods and system disclosed. In the drawings:
[0015] Figure 1 illustrates a network implementation of a system for collaborative engagement for e-governance, in accordance with an embodiment of the present disclosure.
[0016] Figure 1A is a block diagram illustrating the architecture of the system for collaborative engagement for e-governance according to an embodiment of the present invention; and
[0017] Figure 2 illustrates a method of collaborative engagement for e-governance according to an embodiment of the present invention.
DETAILED DESCRIPTION

[0018] The present invention discloses a system and method of Collaborative Engagement for e-Governance.
[0019] Reference throughout this specification to “one embodiment” or “an embodiment” (or the like) means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” or the like in various places throughout this specification are not necessarily all referring to the same embodiment.
[0020] The words “comprising,” “having,” “containing,” and “including,” and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. The terms “a” and “an” herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item.
[0021] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in at least one embodiment. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the invention. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
[0022] It should be noted that the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, apparatuses, methods and computer program products according to various embodiments of the invention. It should also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. The disclosed embodiments are merely exemplary of the application, which may be embodied in various forms.
[0023] Figure 1 illustrates a network implementation of a system (100) for collaborative engagement for e-governance. The system (100) for collaborative engagement for e-governance hereinafter referred to as “system” maintains, manages and monitors the citizen amenities as provided by local governments and associated bodies, especially in an e-governance sector. Although the present subject matter is explained considering the system (100) is implemented as a server, it may be understood that the system (100) described herein can also be implemented in a variety of computing devices such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a network server, and the like. In one implementation, the system (100) may be implemented in a cloud-based environment. It will be understood that the system (100) may be accessed by multiple users / initiators through one or more user devices, collectively also referred to as an initiator device (105) hereinafter, or applications residing on the initiator devices (105). Examples of the initiator device (105) may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, and a workstation. The initiator device (105) is communicatively coupled to the system (100) through a network (103).
[0024] In one implementation, the network (103) may be a wireless network, a wired network or a combination thereof. The network (103) can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network (103) may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network (103) may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[0025] Referring now to Figure 1-A, the system (100) is illustrated in accordance with an embodiment of the present disclosure. In one embodiment, the system 100 may include at least one processor (101), an input/output (I/O) interface (105A), and a memory (102). The at least one processor (101) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor (101) is configured to fetch and execute computer-readable instructions or modules stored in the memory.
[0026] The I/O interface (105A) may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface (105A) may allow the system (100) to interact with the initiator directly or through the initiator devices. Further, the I/O interface (105A) may enable the system (100) to communicate with initiator device (105), and other computing devices, such as web servers and external data servers (not shown). The I/O interface (105A) can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface (105A) may include one or more ports for connecting a number of devices to one another or to another server.
[0027] The memory (102) may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, a compact disks (CDs), digital versatile disc or digital video disc (DVDs) and magnetic tapes. The memory may include modules and database.
[0028] The modules include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules (300) may include an Input Module (104); a Profiler module (112), an Action Module (106), a Workflow Monitor module (114), Tender Management module (116) and an Analytics Module (124).The Action Module (106) further comprises a Routing Module (108) and a Clustering Module (110). The Analytics Module (124) further comprises Scoring and Optimization module (126), Trends and Alerts module (128) and Report Cards and Visualization module (130). The modules may include programs or coded instructions that supplement applications and functions of the system 100.
[0029] The Database (118) amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the modules. The database 118 may include an Area Resolution Data Store (120) and a Vendor Database (122) to store and manage vendor details including the vendor score.
[0030] The Vendor Database (122) comprises a list of vendors authorized by all local area action centres for a district/city or for any large area. The Vendor Database (122) also stores a vendor score associated with a vendor (described in detail in later sections of disclosure).
[0031] Referring to Figure 1A illustrates detailed working of the system (100), in accordance with an embodiment of the present disclosure. The system (100) is configured for monitoring, management and maintenance of citizen amenities With reference to Figure 1-A, an embodiment of the system 100 is described. In the first step (202) the system (100) receives maintenance request data or a request data from an initiator. An initiator is typically a citizen belonging to an area to report a breakdown in amenities. Initiators interact with the system for collaborative e-governance through initiator device (105) via a network (103). At any given time, a plurality of initiators can interact with the system (100) concurrently. Thus, the system (100) can receive multiple requests from a plurality of initiators at any point in time. The system (100) receives maintenance request data (herein after referred to as “service request”) and processes service request data using a computer implemented method. The system (100) is connected to a Routing Module (108), which in turn is connected to a local area action centre. The system processed service request is fed as input to the local area action centre (for the purpose of better understanding of this invention and to avoid confusion, the system processed service request is fed as input to the local area action centre is referred to as “input data”). On the basis of input data, the local area action centre allocates the maintenance service request to a vendor. The assignment of vendor by the local area action centre signals the start of the collaborative engagement workflow.
[0032] In an embodiment, service request received from the initiator is processed to abstract location details, type of maintenance request and accordingly a priority is assigned by the system (100). In an embodiment, the priority for service request is assigned by the Clustering Module (110) for processing and the Routing Module (108) assigns a Local Area Action Centre to process the service request. With reference to Figure 2, a local area action centre is an entity that manages fulfilment of the service request in the process. The local area action centre also allocates tasks to be completed within a defined time frame to monitor and measure vendor performance. During and post task completion, reports are shared with the initiator and initiator feedback is also recorded for the associated maintenance task.
[0033] With reference to Figure 1-A and Figure 2, at step 202, an initiator submits a service request via an I/O interface to report a breakdown in maintenance services. For instance, an initiator can report breakdown related to water supply, street lighting, tree felling, garbage disposal, or any such civic breakdown. In an embodiment, the service request can be submitted using a hand-held or wearable device, for instance a mobile device. In an embodiment, the initiator can submit the service request via various modes including without limitation voice, image, text, email and other modes. The service request generated by the initiator received by the Input Module (104). The Input Module (104) may receive plurality of service requests from plurality of initiators. In an embodiment, to effectively manage a plurality of service requests, a batch can be configured in the system (100) to receive service requests. A batch is defined in the system based on a plurality of parameters such as time for receiving service requests, count of maintenance requests. In an embodiment, a batch can be configured to comprise 200 service requests received or service requests received every 15 minutes. The Input Module (104) selects the service requests as per a defined batch and then begin the processing of the service request.
[0034] In an embodiment, the service request includes without limitation, location data, type of maintenance request and mode in which the service request is sent.
[0035] The moment a service request is received, the Profiler module (112) evaluates the service request and determines the status of the initiator. The status of initiator includes the experience with the system (100) as to whether the initiator is new or has a prior registration. The determination of the status of initiator done by comparing attributes including without limitation email id, telephone number and other details. The Profiler module (112) captures registration information through attributes such as an email ID, telephone number and details obtained through a telecom service provider.
[0036] If the initiator is new, a basic registration process is requested by the profiler module (112) which is commonly known in the art and not discussed in here. The profiler module (112) assigns a Profile ID specific to every initiator. Similarly, every service request is assigned a service request ID by the profiler module (112).
[0037] Activity level is an indicator of how many service requests are submitted by an initiator and thus what is the level of engagement that initiator has with the system (100). Activity level is determined by counting the number of service requests submitted per profile ID. The Profile ID is an associated parameter for monitoring and determining activity levels of the initiator. This will also enable a local area action centre to identify engaged citizens to form citizen groups and leverage citizen groups for vigilance services and to share alerts. Further, the Profiler module (112) determines duplicate service requests, if any and alerts the initiator. In an embodiment, if the initiator submits a service request that is pertaining to a pothole on the road, and the same service request is submitted repeatedly, for example in an interval of 5 minutes an alert of duplicate request is generated.
[0038] The service request comprises location information, type of service request and mode in which request was sent. This location information, type of service request and mode in which the request was set are received by the Input Module (104). These details are provided as input to the Action Module (106) for pre-processing and is termed as ‘input data’ to describe the system (100) and its associated workflow.
[0039] With reference to Figure 1-B, the Action Module (106) further comprises the Routing Module (108) and the Clustering Module (110). The Action Module (106) is logically coupled to a Database (118), which further comprises an Area Resolution Data Store (120) and a Vendor Database (122).The Clustering Module (110) analyses received batch and classifies the service requests constituting the batch based on one of the parameter. In an embodiment, the classification parameter is location. Now, referring to step 204 in Figure 2, following the classification of batch, the clustering module (110) assigns a priority and a classification pertaining to type of work to the batch. In an embodiment, such priority and type of work are assigned to a service request by the clustering module (110). In an embodiment, Type of work refers to the category of the maintenance activity – which includes but is not limited to - to major repair, minor repair, inspection and regular maintenance. Priority refers to category of the maintenance activity which includes without limitation low, medium, high, and emergency. These categories are subjected to regular updating based on the present and/or future scenario and updating may include deletion, addition, collaboration, editing.
[0040] In the event of receipt of a plurality of service requests related to a common breakdown, for instance a pothole repair, input data for each of these service requests is abstracted by the Input Module (104)and is fed as input data to the Action Module (106). In an embodiment, for a plurality of service requests received from unique profile identifiers, for a breakdown, in this embodiment the service request pertains specifically to a pothole repair in Location A. The number of unique service requests in every batch configured pointing to a location as Location A will determine priority. In yet another embodiment, if Location A is an arterial location, Clustering Module (110) will assign a high priority to the service request. In an embodiment, explained for the purpose of describing the present invention, if for batch 1, there are 10 service requests pertaining to a pothole in Location A and priority assigned by the Clustering Module (110) is medium. And for batch 2, there are 40 service requests pertaining to pothole in the same Location A at the same time, then priority for all service requests pertaining to a pothole in Location A will be re-assigned to High. Thus, in the present embodiment, priority is assigned based on location, number of service requests received per batch and type of work. In an embodiment, Priority assigned earlier can also be re-assigned on the basis of service requests received per batch.
[0041] Priority and Type of work determined by the Clustering Module (110) can be used to identify trends and patterns, which is an input to the Analytics Module (124)(described in subsequent sections of the disclosure)
[0042] The Clustering Module (110) analyses received batch and classifies the service requests constituting the batch based on one of the parameter. In an embodiment, the classification parameter is location. Location is determined from the input data received by the Input Module (104). Further, the Clustering Module (110) determines a location code.
[0043] The Action Module (106) communicates with the Database (118) and its sub-modules: Area Resolution Data Store (120) and Vendor Database (122) to further process the input data and initiate a workflow. In an embodiment, a location code is analogous to, without limitations a pin code or zip code. To determine a location code, the Clustering Module (110) of the Action Module (106) communicates with the Area Resolution Data Store (120) of the Database (118). In an embodiment, the Area Resolution Data Store (120) stores a database table, which further comprises an arrangement of location name, latitude/longitude data, and location code. Location details from the input data is again provided as input to the Area Resolution Data Store (120), which is then mapped to the database table to determine the location code. In an embodiment, for a service request, where location data abstracted from input data is in terms of latitude/longitude or location name, the Area Resolution Data Store (120) derives the location map by referring to the database table where location name or latitude/longitude is mapped to a location code.
[0044] In yet another embodiment, if the service request is for a pothole repair, location determination techniques such as GPS, triangulation, can also be used from the initiator’s telecom service provider. The location data – latitude and longitude will be mapped to a location code by the Area Resolution Data Store (120). In a particular embodiment, for a service request pertaining to pothole repair, the location name provided in the input data is Andheri (East), the location code determined by the Area Resolution Data Store (120) will be to be 400093, which is derived by mapping area name to a database table. In certain cases, there might be lapses in determining the location code. For instance in an embodiment, if the location of the pothole is closer to a neighbouring location code 400096 where road traffic will be more affected, then location will be determined with location code 400096 for the service request.
[0045] At step 206 in Figure 2, after determining the location code, the Routing Module (108) of the Action Module (106) assigns a local area action centre and the Vendor Database (122) is used to allocate a vendor to the Request ID of the service request. After a vendor is associated with a Request ID of the service request, the local area action centre identified will define the time period to complete the service request, tasks associated for completing the service request and milestones. Introduction of collaboration between the local area action centre and vendor database (122) signals the initiation of the collaborative engagement workflow.
[0046] In the present embodiment, the local area action centre is an entity that is responsible for handling, managing and monitoring the progress of the service request. The Routing Module (108) determines an appropriate at least one local area action centre to manage and monitor the service request. Input to the Routing Module (108) is location code determined by the Area Resolution Data Store (120). The Routing Module (108) comprises a data table to map location code to local area action centre. Based on the type of work, priority and location, more than one local area action centre can also be determined. The data table in the Routing Module (108) is also capable of determining a combination of local area action centres and the best or most effective local area action centre.
[0047] The Vendor Database (122) comprises a list of vendors authorized by all local area action centres for a district/city or for any large area. The Vendor Database (122) also stores a vendor score associated with a vendor. In an embodiment, the vendor score is used for assigning a task to the vendor, identify backup vendors, and also determine a vendor credit rating and tender deposit when a contract is to be awarded to a vendor. Vendor is assigned based on location code determined by the Area Resolution Data Store (120). In an embodiment, Vendor assignment is also dependent on attributes including vendor rating, priority, and type of work.
[0048] Vendor Database (122) can also be used to select a combination of vendors. In an embodiment, if a vendor associated with a location code has less favourable assessment score, another vendor having a higher score is selected. The Vendor Database (122) also comprises a preferred vendor listing which is a listing of vendors with a consistent vendor score for any type of work.
[0049] In an embodiment, for a request pertaining to pothole repair, after determination of the location code, for instance 400096, the location area action centre that maps to the area code is determined. In the next step, a vendor with a favourable score for type of work pertaining to pothole repair for area code 400096 is assigned by the Vendor Database (122). In an alternate embodiment, if type of work is water logging along areas contiguous to location code 400096, 400093, 400098, one or more local area action centres will be assigned and the most suitable vendor for location codes 400096, 400093 and 400098 will be determined. In an embodiment, one or more vendors may be assigned wherein area code includes more than one code. . Data comprising Location Code, mapped/identified Local Area Centre(s) and Vendor(s) identified is fed as input (herein after referred to as “workflow data”) to the Workflow Monitor (114).
[0050] At step 208 in Figure 2, the Workflow Monitor (114) monitors the workflow for service request fulfilment. The local area action centre, vendor and initiator are stakeholders in the workflow to fulfil the service request. The workflow comprises assigning a vendor for the service request, assigning tasks to the vendor to monitor completion of the service request, assessing vendor performance of the vendor while fulfilling the service request and collating feedback from initiator post completion of the service request. The Workflow Monitor comprises workflow data – which includes but is not limited to priority, type of work, vendor data and data submitted by the local area action centre. Vendor data which is a part of workflow data is derived from the vendor database (122). In an embodiment, data submitted by the local area action centre comprises time duration to fulfil the service request, tasks to be completed by the vendor within the time duration. The Workflow Monitor (114) also communicates with the Trends and Alerts module (128) to transmit data generated during the workflow to the stakeholders.
[0051] In an embodiment, for service request pertaining to pothole repair, a local area action centre for location code 400093 is identified and a suitable vendor is also identified by the Routing Module (108) and the Vendor Database (122). Further to this, the identified local area action centre will assess the service request and determine time duration or service level agreements (SLA), which is the time in which the maintenance request should be completed. SLA is computed based on type of work and priority. In an embodiment, if the priority is high, time allocated will be less, if the type of work is a major repair, SLA assigned will comprise more number of days. After determining the SLA, the local area action centre will also input the list of tasks that are to be completed within the SLA. In the present embodiment, for a pothole repair request, the local area action centre can assign a single day to the vendor to complete the task. The SLA and the list of tasks is communicated to the vendor(s) via the Trends and Alerts (128) module. Similarly, vendor response to the tasks allocated is communicated back to the Workflow Monitor (114) via the Trends and Alerts (128) module.
[0052] In yet another embodiment, if the type of work is a major repair, SLA assigned is 8 days. The local area action centre may also define a list of tasks that are to be completed and time in which the task is to be completed over the 8-day SLA for ease of monitoring. For every task, vendor SLA compliance is recorded, either via vendor response on the system or through an inspection that could be carried out physically by the local area action centre. In the event of non-compliance, alerts are sent to the vendor and data related to non-compliance is recorded. In an embodiment, for task 2 a completion of 2 SLA days is assigned by the local area action centre. If the vendor reports completion in 3 SLA days, the addition delay of 1 day is recorded and factored. This will be used to assess vendor performance. Vendor response data, SLA compliance data, deviation of SLA days are the output of the Workflow Monitor (114), which is fed as input to the Analytics Module (124), particularly to the Scoring and Optimization (126) Module.
[0053] In step 210 in Figure 2, the Workflow Monitor (114) interacts with the Analytics Module (124) to perform scoring of vendor performance. To perform vendor scoring or vendor assessment, workflow related data comprising priority, type of work, SLA, task list, vendor response and deviation in SLA days are used as scoring data (Please use some other term). DONE
[0054] The Analytics Module (124) performs the function of trend analysis for service requests preparation of report cards and visualization, and predictive analytics and forecasts for service requests. Output of the Analytics Module (124) enables quicker decision making for local area action centres to fulfil service requests.
[0055] The Scoring and Optimization Module (126) communicates with the Workflow Monitor (114) to compute a vendor score using the scoring data for a service request being fulfilled by a vendor. Input to the Scoring and Optimization (126) module is workflow data comprising, but not limited to Vendor response data, SLA compliance data, and deviation of SLA days. Subsequent to computation of the vendor score, the vendor score is also updated real-time to the Vendor Database (122). Vendor score comprises two components – score calculated by the system based on workflow data and feedback received from the initiator through a defined template. This combined vendor score is updated to the Vendor Database (122). Vendor score is also used to determine vendor allocation, that is, vendor selection for a type of work.
[0056] Scoring and Optimization (126) comprises rule based templates to calculate a vendor score. Rule are configures to generate a score based on the quantum of work completed within the SLA defined. Refer to Table 1 for an embodiment of the current disclosure. In this embodiment, a score of 5 is assigned when a vendor completes a service request within less than or equal to 30% of the measured SLA. Similarly, in yet another embodiment, a score of 4 is assigned when the service request is fulfilled in an SLA time greater than 30% or less than 60% of measured SLA. Table 1 represents the rules that are configured in the current embodiment.
Table1: Scoring template rule
When closed with less than or equal to 30% of SLA time 5
When closed with greater than 30% but less than or equal to 60% of SLA time 4
When closed with greater than 60% but less than or equal to 100% of SLA time 3
When closed with greater than 100% but less than or equal to 130% of SLA time 2
When closed with greater than 130% of SLA time 1

[0057] In addition, the scoring template can also be configured to include bonus score or a reward score if the service request is completed well within SLA. In an embodiment, if the vendor completes the service request within 30% to 60% of the configured service level agreement hours bonus points equivalent to the score are awarded. In yet another embodiment, bonus scores are generated when a vendor consistently achieves the highest score, in this embodiment a score of 5.
[0058] The Scoring and Optimization (126) module comprises a pre-defined initiator feedback template to record initiator rating, which is captured after the completion of the service request. A combined score is generated after receiving initiator feedback. In an embodiment, for a service request, initiator rating is requested on a scale of 1 to 4 with 1 being the least and 4 being the best. In an embodiment, a score of 3 may be recorded and received in the Scoring and Optimization (126) and an average of both the scores – system computed score and initiator feedback is recorded in the Vendor Database (122). Thus a participative collaborative workflow is established by the system.
[0059] The Vendor Database (122) is coupled to the Tender Management (116) module. The Tender Management (116) module determines a vendor credit rating and a deposit amount that should be paid by a vendor at the time of awarding a contract. Vendor credit rating is based on vendor score and vendor credit rating is also used to determine the amount of tender deposit. In an embodiment, higher the credit rating of the vendor, lower is the tender deposit. The Tender Management (116) module also communicates with the Scoring and Optimization (126) module. Input to the Tender Management (116) Module is the combined vendor score, which is again received as input from Scoring and Optimization (126) module. The vendor scores of all vendors in the vendor database are sorted and ranked in create a vendor credit rating list. In an embodiment, higher the score, the rating is ascending order. In yet another embodiment, if vendor A score corresponds to 25 and other vendor’s score are lower, Vendor A is ranked higher. Further the vendor credit rating changes dynamically whenever there is a change in the vendor score received from the Scoring and Optimization (126) Module. Further, Tender Management (116) can also be configured to communicate with any other enterprise resource planning (ERP) applications hosted by a local area action centre to determine tender deposit for contracts.
[0060] The system also enables forecasting and prediction of maintenance requests through the Trends and Alerts (128) module and Report Cards and Visualization (130). In an embodiment, the system also generates notifications to local area action centres to display information such as best time for routine maintenance. The Report Card and Visualization (130) module clusters data and presents visualization of service request data, workflow data, and vendor score data. In an embodiment, for a local area action centre visualization can be generated through heat maps that indicate data density. In an embodiment, a local area action centre can view the number and type of service requests received. In yet another embodiment, vendor data can be viewed for service requests fulfilled by a vendor, SLA time compliance/deviation, score obtained, repeat requests for the same type of service request.
[0061] Using the service requests receives, input data processed, workflow data and vendor score data, prediction and forecasts can be generated. In an embodiment, for a major repair service requests received, a local area action centre can issue advisory warning to citizens. In yet another embodiment, based on trend and analysis and vendor performance, a local area action centre can predict maintenance activity and take necessary steps. An example would be water logging in an area, pothole repair during monsoon.
[0062] The collaborative engagement system described herein is a dynamic, real-time system that allows initiators in an area to register requests related to civic amenities with ease, allows the governments/local area governing bodies to address service requests using technology, and data processing techniques enabling quick resolution. The system further enables governance by evaluating vendor performance, inviting feedback from citizens – which is a holistic approach to assess a vendor and also track vendor performance by including an assessment parameter to measure accountability.
[0063] The preceding description has been presented with reference to various embodiments. Persons skilled in the art and technology to which this application pertains will appreciate that alterations and changes in the described structures and methods of operation can be practiced without meaningfully departing from the principle, spirit and scope