Patent Application
20160005006
In project management, a schedule will often be created as an initial step in carrying out a specific project, such as the construction of a building, development of a product, or launch of a program. Establishing a project management schedule may include listing milestones, activities, and deliverables with intended start and finish dates, of which the scheduling of employees may be an element. The production process schedule may be used for planning the production or the operation, while a resource schedule aids in the logistical planning for sharing resources among several entities. The schedule may be obtained by estimating the duration of each task and noting any dependencies amongst those tasks. Dependencies are tasks that are completed in order to make other tasks possible, such as obtaining a truck before loading materials on the truck. Scheduling of a project, therefore, may include identifying tasks necessary to complete the project, and the earliest time at which each task can be completed. In creating a schedule, a certain additional amount of time may be also considered as a contingency against unforeseen occurrences and/or delays during the project.
The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
In systems and methods described herein, a resource controller may receive data identifying a communications product and determine a task associated with providing the communications product. The controller identifies human resources and network resources for performing the task, determines availabilities of the human resources and the network resources for completing the tasks, and determines a service commitment time for the particular communications product based on the availabilities of the human resources and the network resources for completing the tasks. The resource controller may display information associated with the service commitment time. The resource controller may determine a location associated with a user, and may identify communications products associated with the location. The resource controller may identify service commitment times for the available communications products, and may select the one or more of the available communications products based on the service commitment times.
In implementations described herein, resource controller 110 may enable a user, such as a customer or a service representative, to select (e.g., via a user interface provided by resource controller 110) goods and/or a service. Resource controller 110 may interface with components of backend system 140 to determine, for example, substantially real-time (e.g., within an hour) available levels of human, network, and hardware resources in view of current service commitments 172, and historical delays associated with prior service commitment results 171. Resource controller 110 may determine an estimated delay associating with providing the requested goods and/or services based on the resource availability and the historical delays. Resource controller 110 may further determine changes in delays based on changes in the requested goods and/or services, and may provide suggestions for changes in the requested goods and/or services to reduce the estimated delays. Resource controller 110 may additionally finalize a request for particular goods and/or services and interact with backend system to commit resources for providing the particular goods and/or services.
In one implementation, resource controller 110 may further provide an interface to receive an input from a user (e.g., from user device 130) selecting goods and/or services to be evaluated by resource controller 110, and may interact with resource controller 110 to determine and report to the user a delay associated with the selected goods and/or services.
Network 120 may be a communications network and/or data network that connect resource controller 110 to user device 130. For example, network 120 may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a wireless network, an optical fiber (or fiber optic) network, or a combination of these networks. In addition or alternatively, network 120 may be included in a radio network capable of supporting wireless communications to/from one or more devices in environment 100, and the radio network may include, for example, a long-term evolution (LTE) network, another 3rd Generation Partnership Project (3GPP) 3G/4G network, Global System for Mobile Communications (GSM), wideband code division multiple access (WCDMA), Ultra Mobile Broadband (UMB), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), High-Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMax), enhanced high-rate packet data (eHRPD), or a network implemented in accordance with future wireless network standards. In another implementation, network 120 may be included in one or more private Internet Protocol (IP) networks that use a private IP address space.
User device 130 may include any type of computation device, such as a PC, laptop computer, tablet computer, personal digital assistant, cell phone, etc., that is capable of transmitting data (e.g., emails, text messages, instant messages, facsimiles, etc.), video data (e.g., video calls, video chats, video messages, etc.) and/or voice data (e.g., voice calls) to/from a network, such as network 120.
Backend system 140 may include devices that generate and/or manage data regarding human resources (e.g., from human resource controller 150) and/or network resources (e.g., from network resources controller 160). For example, backend system 140 may monitor the status of human resources and network resources and identify when the human resources and network resources are in use or are available to be allocated to a new task.
As shown in
Although
Bus 210 may permit communication among the components of device 200. Processing unit 220 may include one or more processors or microprocessors that interpret and execute instructions. In other implementations, processing unit 220 may be implemented as, or include, one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or the like.
Memory 230 may include a random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processing unit 220, a read only memory (ROM) or another type of static storage device that stores static information and instructions for the processing unit 220, and/or some other type of magnetic or optical recording medium and its corresponding drive for storing information and/or instructions.
Input device 240 may include a device that permits a user to input information to device 200, such as a keyboard, a keypad, a mouse, a pen, a microphone, one or more biometric mechanisms, and the like. Output device 250 may include a device that outputs information to the user, such as a display, a speaker, etc.
Communication interface 260 may include any transceiver-like mechanism that enables device 200 to communicate with other devices and/or systems. For example, communication interface 260 may include mechanisms for communicating with other devices, such as other devices of environment 100. In one implementation, communication interface 260 may support short range wireless network communications (e.g., via Bluetooth® protocols). In other implementations, communication interface 260 may support other wired or wireless network communications.
As described herein, device 200 may perform certain operations in response to processing unit 220 executing software instructions stored in a computer-readable medium, such as memory 230. A computer-readable medium may include a non-transitory tangible memory device. A memory device may be implemented within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into memory 230 from another computer-readable medium or read into memory 230 from another device via communication interface 260. The software instructions stored in memory 230 may cause processing unit 220 to perform processes described herein. Alternatively, hardwired circuitry may be used in place of, or in combination with, software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
Although
Service availability determination module 310 may determine a list of available communication services provided, for example, by a local exchange carrier (LEC). For example, Service availability determination module 310 may determine information regarding a particular customer, such as an associated location and/or a customer type (e.g., whether the particular customer is a business or residential customer), and service availability determination module 310 may identify services available to the particular customer. For example, user device 130 may forward an input identifying a customer (e.g., an account number), and service availability determination module 310 may access customer profile data to identify a billing address and/or service address included in the customer profile data.
In one implementation, service availability determination module 310 may validate a customer's address and contact details. For example, availability determination module 310 may interface with a third party device to validate the customer's address and contact details. Service availability determination module 310 may further allow a customer to create credentials for future login after validation.
Service availability determination module 310 may determine a market domain associated with a customer based on a service address associated with the customer, and service availability determination module 310 may determine services available within the market domain. For example, service availability determination module 310 may store data defining one or more defined geographic boundaries, and may use the defined geographic boundaries to determine the market domain for a customer. For example, service availability determination module 310 may determine a zip code, area code, wire center, or/or local access and transport area (LATA) associated with the service address, and may further determine the market domain associated with the determined zip code, area code, wire center, or/or LATA. In another implementation, service availability determination module 310 may identify a country for a Zip or PIN code associated with the service address and may also determine the market domain associated with the country.
Service availability determination module 310 may map each market domain to a corresponding set of communications products, and each product may be mapped to one or more associated services. Service availability determination module 310 may determine whether a service is currently available, not available, or possibly available in a market domain. For, example, availability determination module 310 may determine whether a service is available based on receiving an input from user device 130 requesting information regarding the service. A service may possibly be available in a market domain if the service is planned to be introduced into the market domain in the near future. Additionally, availability determination module 310 may determine service availability status for alternate services for the market domain.
Service commitment generation module 320 may determine delays associated with performing tasks associated with providing communication services, and then generate service commitments (e.g., a timeframe for committing to provide the various communications services) based on the delays.
For example, a user (e.g., a customer or a service representative) may select communications services, and service commitment generation module 320 may determine when the selected communications services may be available to the customer. For example, service commitment generation module 320 may show service availability and corresponding technology availability for the requested services and the given location associated with the customer (e.g., the Service Address).
For example, for each selected product or service, or technological component of a product or service, service commitment generation module 320 may determine an available capacity of the show capacity availability of the product, service, or technological component. For example, service commitment generation module 320 may determine capacity availability at a first entrance office (FEO), corresponding to a switch (SW) capacity at a Switch site and/or a network-to-network interface (NNI) capacity along with an associated service edge router. Service commitment generation module 320 may determine the entrance office (EO) site and corresponding SW site derived from a network plan matrix (NPM) or other data included in network resources availability data 302 (e.g., data received from network resources controller 160). NPM may include predefined metadata from network resources controller 160 that shows preferred points of presence (POPs) for the service address associated with the customer.
In one implementation, service commitment generation module 320 may use an NPM to identify an optimized network path between the customer's service address and a network service termination for a service provider (e.g., an LEC) to provide a product and/or service to the customer. Additionally, service commitment generation module 320 may use the optimized network path to calculate efficient network cost based on physical distance, number of hops, connection fees, latency, number of regions, or other parameters. An NPM may include, for example, information identifying market domains, available service types for each market domain, available entrance office choices for each service type, and available switch sites for the corresponding entrance office.
In one implementation, service commitment generation module 320 may further determine whether the consumption or the availability of a resource reach a capacity warning threshold (CWT) and may trigger an alarm on when the consumption or the availability of a particular network resource reaches the CWT. This CWT may be configured based on a past capacity consumption trend for the service domain and the market domain.
Based on the determined availability levels, service commitment generation module 320 may estimate service enablement date(s) associated with selected products or services. For example, service commitment generation module 320 may derive the service enablement date(s) based on comparison of the availability levels to the CWT, actual capacity availability (e.g., capacity levels at the EO and/or SW Site), and/or historic average interval days taken for the given service and the corresponding applied technology. Additionally, service commitment generation module 320 may determine a standard deviation or other measure of an expected spread in the service enablement dates (e.g., to form a likely best case and a worst case service enablement date).
In one implementation, a CWT may have multiple different values or band of values, such as a green band representing average availability levels, a yellow band representing low availability levels (levels presenting additional service commitments), and a red band representing critically low availability levels (e.g., levels that may disrupt existing service commitments), and service commitment generation module 320 may determine which CWT band is currently associated with the available resource.
Service commitment generation module 320 may determine CWTs for each service type for a given market domain. For example, separate CWT values may be determined and evaluated for each service type for different Open Systems Interconnection model (OSI) network layers. For example, service commitment generation module 320 may evaluate each service type across OSI network layer 1 (the physical layer), layer 2 (the data link layer), and layer 3 (the network layer). For example, service commitment generation module 320 may determine a physical capacity of a node (e.g., a total capacity of the node as indicated by a vendor's specification) and number of spare slots available for future expansion (e.g., to expand the total capacity of the node). Similarly, service commitment generation module 320 may classify a physical capacity of network element (e.g., a node) as a combination of configured capacity that may be used for services and non-configured physical capacity corresponding to spare slots for future expansion (e.g., unavailability capacity that may be accomplished through changes in the network elements).
In determining when a service change may be implemented, service commitment generation module 320 may check a minimum capacity which must be checked at a port level for a given physical port type and build the OSI hierarchy all the way to network element level associated with the Node.
In determining whether an available capacity complies with certain CWTs, service commitment generation module 320 may permit oversubscription of capacity (e.g., so that a service commitment exceeds a CWT) for a certain network service type and/or applicable network layer. For example, service commitment generation module 320 may schedule a service change that may cause a Layer 3 CWT to be exceeded (e.g., causing excessive bandwidth) with the knowledge that excessive bandwidth may result in slower and/or less reliable transmissions.
In one implementation, service commitment generation module 320 may evaluate human resources capacity associated with the market domain. For example, service commitment generation module 320 may identify manual tasks associated with a requested product or service. For example, if a customer requests particular communications services, service commitment generation module 320 may identify particular hardware needed to provide the particular communications services and tasks associated with the particular communications services (e.g., installation of the particular hardware). Service commitment generation module 320 identifies service level agreements (SLAs) associated with the manual task, such as an expected amount of time for completing the task.
After service commitments are accepted (e.g., a customer submits an order for a service), service commitment generation module 320 may store data identifying tasks to be performed and a status of the tasks. For example, service commitment generation module 320 may monitor an amount of time taken to complete tasks (e.g., based on prior service commitment results 171), and service commitment generation module 320 may update SLAs based on the measured times. In one example, service commitment generation module 320 may update an SLA associated with a particular task if the actual measured time associated with the completion of an instance of the tasks differs from the SLA time by at least a threshold amount (e.g., by more than a standard deviation from the SLA time).
In another implementation, service commitment generation module 320 may modify human resources SLA values based on logic. For example, service commitment generation module 320 may reduce human resources SLA values by a particular amount (e.g., reducing average performance times by a particular amount (e.g., 5%) over a time period to cause improvements in the human resource performance.
In addition to predicting and measuring individual human resources SLAs, service commitment generation module 320 may form and monitor groups of human resources tasks. For example, service commitment generation module 320 may monitor human resources tasks associated with a business function, such as to evaluate human resources per product and service combination, per market domain, per network technology, and per network level for the business function. For example, service commitment generation module 320 may produce a pattern about time taken at each manual task and time taken in-total to complete all manual tasks associated with a business function. For example, service commitment generation module 320 may measure a total time taken from manual tasks related to pre-sale, ordering, pre-provisioning, provisioning, and testing activities by unit and collectively across all units.
In another example, service commitment generation module 320 may evaluate human resources per unit of time (e.g., per day) such as to evaluate human resources per market domain, per product and service combination, per network technology, per network type, and per business function. For example, service commitment generation module 320 may determine a pattern on time taken per n-units of human resources during the unit of time.
Service commitment generation module 320 may use tasks associated with a requested product and/or service and generate an expected human resource delay based on the SLAs associated with the tasks to generate a future customer desired due date (CDDD) and/or customer commitment date (CCD). For example, Service commitment generation module 320 may check existing pending customer orders for a given product and service in a market domain and may incorporate the human resource availability factor to produce a reliable service commitment date for the requested product and/or services.
Service commitment generation module 320 may further evaluate network resources associated with a market domain (e.g., from network resources availability data 302 received from network resource controller 160). For example, service commitment generation module 320 may interface with network resource controller 160 to identify a network equipment inventory and identify spare network resources and network resources being used currently used. For example, network resource controller 160 may identify, for service commitment generation module 320, provisioned and non-provisioned hardware. Service commitment generation module 320 may further evaluate capacity in a network associated with a market domain to identify whether hardware that is already installed within the market domain is already being used (e.g., in effect) or available to be assigned to a new product and/or service.
In one implementation, service commitment generation module 320 may use an NPM to identify an optimized network path between the customer's service address and network service termination for a service provider (e.g., an LEC) to provide a product and/or service to the customer, and service commitment generation module 320 may evaluate network resource availability along the optimized network path.
Thus, service commitment generation module 320 may determine service commitment data for a service and/or product by determining human resources tasks associated with providing the service and/or product and an expected time (e.g., based on the SLAs) when the human resources tasks will be completed. Service commitment generation module 320 may further verify that the needed network resources will be available during the expected time when the human resources tasks will be completed, and service commitment generation module 320 may modify the estimated service commitment date to reflect when necessary network resources will be available. Service commitment generation module 320 may further interface with backend system 140 (e.g., with human resource controller 150 and/or network resources controller 160) to commit resources to reserve and monitor the service commitment requested by a user and may further update pending service commitments 172.
Interface module 330 may provide a user interface, such as a graphical user interface (GUI), to provide user device 130 with information regarding the list of available communication services (determined by service availability determination module 310) and the service commitment dates when services and/or products will be available (generated by service commitment generation module 320). In one implementation, interface module 330 may receive an input from user device 130 regarding a selection of one or more services and may forward the selection to service commitment generation module 320 to determine an associated service commitment date. In one implementation, interface module 330 may show service availability for example, at the address, at the market domain, in a region (e.g., two or more market domains), and/or in a country.
When providing information regarding the list of available communication services determined by service availability determination module 310, interface module 330 may present a list of other products and services that are available in the location (e.g., market domain) associated with the customer. In one example, interface module 330 may present the available products and service types available across all entrance offices of market domains associated with the customer's service address. For example, interface module 330 may, based on receiving an input selecting a particular service or product, identify and present information regarding related (e.g., supplementation and/or alternative) offers. For example, if a customer is associated with a particular entrance office, interface module 330 may identify other services provided by a particular entrance office and or services provided by other entrance offices within (e.g., located less than) a particular distance.
Interface module 330 may present expected fulfillment delays associated with selected services/products. In one implementation, interface module 330, when presenting the list of other products and services that are available in the location, may also present expected fulfillment delays associated with the other products and services. In another implementation, interface module 330 may identify and present other products and services, available in the location, that are associated with expected fulfillment delays that are less than the expected fulfillment delay associated with the selected products and services. In yet another implementation, interface module 330 may identify and present other products and services, available in the location, that are associated with relatively lower pricing than the selected products and services (e.g., products and services associated with promotions).
Interface module 330 may enable a user to provide an input to modify the selected products and services. In another example, interface module 330 may connect a customer to a customer service representative to modify the selected products and services. Interface module 330 may update the service commitment date based on the modification to the selected products and services. Interface module 330 may further update the service commitment date based on results from prior service commitment results 171 to reflect changes in the human resources SLAs and/or changes in the network resources availability.
Interface module 330 may further provide pricing data associated with selected products and services and may further provide data regarding changes in pricing related to changes in the selected products and services.
Although
Location field 410 may enable a user to submit an input to specify a location associated with the user or another person (e.g., a customer if the user is a service representative). For example, a user may specify a service location (e.g., address). In addition or alternatively, the user may specify a region (e.g., a city, state, or country). In another example, the user may submit data identifying a customer (e.g., an account number), and the location may be determined based on the customer identifier.
Product/service selection field 420 may enable a user to submit an input to specify a desired product and/or service. In one implementation, available products and/or services list 425 may be presented in interface 400 in connection with product/service selection field 420. Available products and/or services list 425 may be generated based on the customer's location (e.g., as identified in location field 410) or other data (such as data included in a customer profile). Available products and/or services list 425 may be generated based on the desired product and/or service specified through product/service selection field 420, such as to identify alternative products and/or services available at the location.
Order summary field 430 may identify a combination of products and/or services associated with a customer. For example, the products and/or services identified in order summary field 430 may be specified through product/service selection field 420. Order summary field 430 further include other products and/or services associated with the customer, such as pending (e.g., unfulfilled) orders associated with the customer.
Service commitment date field 440 may identify a service commitment date associated with the combination of products and/or services shown in order summary field 430. For example, as described above with respect to
Order change recommendation field 450 shows suggested products and services (e.g., selected from available products and/or services list 425. For example, order change recommendation field 450 may identify alternative products and services (e.g., competing products and services). In one example, order change recommendation field 450 may identify alternative products and services that may result in decreased costs to a customer and/or reduced service commitment days. Other data field 460 may identify other information related to interface, such as information identifying decreased costs and/or reduced service commitment days associated with the alternative products and services identified in order change recommendation field 450.
Although
As shown in
As shown in
As shown in
Determining the service commitment date associated with the particular service and/or product in block 520 is presented in greater detail in
As shown in
As shown in
As shown in
Identifying alternative services and/or products in block 540 is presented in greater detail in
As shown in
Continuing with
In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It should, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.
Also, while a series of blocks has been described with respect to process 500 in
It will be apparent that different aspects of the description provided above may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects is not limiting of the implementations. Thus, the operation and behavior of these aspects were described without reference to the specific software code--it being understood that software and control hardware can be designed to implement these aspects based on the description herein.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one other claim, the disclosure of the implementations includes each dependent claim in combination with every other claim in the claim set.
No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
