Continuing from where we left off in Part 5, lets start exploring the configuration and administration aspects of itHUB a little more in this post.

C. Anticipatory Service Models

By understanding the customer more and more, itHUB can evolve from being an interactive model for providing products and services to anticipatory model for offering products and services.

Anticipatory Service Models

The Anticipatory Service Manager (ASM) component could be built using a combination of the event-driven architecture model and the prediction API described in the previous section. In the event-driven model, ASM will look for a predetermined set of events such as the New Hire event from PeopleSoft. Upon receiving the event, ASM will create the appropriate requests for the new hire. Some of the requests that can be submitted for a new hire include desktop/laptop, smart phone, any business unit specific applications etc.

V. CONCLUSION

This article, distributed across 6 posts, discussed several techniques with which IT departments could transform from being a reactive informational IT shop to a more dynamic anticipatory service model where the IT department proactively caters to the IT needs of an organization. The first transformation from the more traditional informational model is to setup an online storefront – the itHUB. itHUB is an implementation of the interactive model where customers interact with the system to submit, track, and approve/reject requests and service providers offer products and services through the system by administering request types. To create and sustain the network effect, this article suggested the inclusion of wiki/blog, reviews & ratings, and Q&A features. The article also suggested some ways for implementing recommendation of products and services and sentiment analysis to improve the understanding of the IT customer. Finally, the ASM model was introduced to facilitate the need for making IT departments more agile and proactive.

Continuing from where we left off in Part 4, lets start exploring the configuration and administration aspects of itHUB a little more in this post.

G. Request Management

This component is about the configuration of request types and the processing of requests that are internal as well as destined for external service providers.

1) Configuration of Request Types

Oftentimes, the cookie cutter request processing systems contain many unnecessary data fields (in the data collection forms) that are not pertinent to a request being made. Since those systems evolved over a period of time or COTS (Commercial Off-the-shelf) application with generic set of fields for all requests, they tend to offer poor user experience when it comes to request management. A Request Type in itHUB, on the other hand, represents a set of questions to be answered or data to be collected about a request prior to processing it. For example, before processing a request for a desktop, the IT support team must understand the requirement about the desktop request such as amount of RAM needed or number of CPUs needed etc. Therefore, a request type for desktops could be configured to just ask those questions that are pertinent for desktop requests.

E-R Diagram for Request Type Management

As shown in the above diagram, the request types can be categorized to support hardware requests, software requests, and application requests etc. A desktop request would be part of the hardware requests. By the same token, an external service provider’s offerings can also captured using this model. One of the ideas for presenting the various categories of request types are shown below:

Categories of Request Types

The request configuration enables the idea of grouping multiple request fields as shown below:

Desktop Request with two Field Groups

2) Submission of Requests

Once the request types are defined, a customer could select a particular request for submission. The following E-R diagram shows one of way of implementing the decoupling of request configuration from the actual request itself.

Request Management

H. Approval Workflow

Each request type (e.g. Desktop Request) is configured with a set of approvers. One of the major constructs in the approval workflow component is the Approver Chain and is described in the following section.

1) Approver Chain

Each Request Configuration (aka. Request Type) has a set of roles configured as an approver chain. For example, the desktop request has to be approved by the following roles: department manager and general manager.

Approval Workflow

2) Request Approval Status

The approval decision by each approver in the approver chain, approved or rejected, is captured in the Request Approval Status. The approver chain is configured as follows: Approver Chain Configuration

In the above scenario, the request will be sent to the department manager and then the general manager for approval. Depending upon the requestor of the request, the actual approvers are mapped to the roles and the workflow is initiated as follows:

Approval Routing

3) Business Process Management (BPM)

As we introduce more products and services with varying degrees of workflow steps, it makes sense to start thinking about using a robust business process management engines such as JBoss Drools. By externalizing the business rules away from code, we can give a separate life cycle for rules to evolve more independently of the code. Another advantage to using a rules engine is to provide an opportunity for non-technical users to maintain the business rules without needing to contact a developer or the development team.

I. Web Layer

This is an important layer for creating a memorable experience for our customers. In addition to the traditional web application to submit, track, approve, and administer the requests, this layer must also provide support for managing wiki/blogs, ratings and reviews, and questions and answers (Q&A).

a) Submit, Track, Approve, and Administer Requests

This is the crux of itHUB. This is one of the main reasons as to why customers come to itHUB in the fist place - an easy to use web interface where customers and service providers (aka. service administrators) come together to make the request management possible.

Request management Use-cases

(1) Submit Use-Case

itHUB customers choose from a set of request types, provide details for the request, and submit the request as shown below:

Request Submission

Request with Customized Details

(2) Track Use-Case

itHUB customer wishes to know the status of his/her request. The status of the request can be submitted, in-review, approved, or rejected as shown below:

Track View

(3) Manage Use-Case

itHUB approvers wish to perform approvals for a list of requests. Approval is a process by which the approver either approves or rejects a request based on the need – requester’s need in terms of the department’s overall need. The following screen capture shows the Manage view of one of the department managers.

Manage View

(4) Administer Use-Case

Service providers and service administrators create a portfolio products and services for the itHUB customers to choose and request from. As described in the previous sections, each request type has the following data structure: request hub, request category, request, request field group, and request field configurations. A request hub holds on to multiple categories such as ITHUB to hold onto IT products and services. A request category holds onto multiple request configurations. Each request configuration holds onto multiple field groups and a field group holds to multiple request fields. As shown in the following screen capture, a service provider/administrator has appropriate rights to create hid/her portfolio of products and services.

Request Type Administration

An example view of the request configurations is shown below:

Request Configuration Administration View

By the same token, other request type components could be administered using the appropriate administration views.

b) Q & A

One of the major components of the web layer is the question and answers (Q&A) web component. By integrating the Q&A web component, itHUB will be able to create the network effect as described in the previous sections. Instead of building a homegrown solution for the Q&A web component, IT departments could consider COTS applications such as Open Source Q&A (OSQA) or its commercial equivalent AnswerHub. AnswerHub is a cloud-based knowledge management system built on a Q&A foundation [12].

Q&A

c) Wiki/Blogs

Adding wiki/blog support to itHUB is relatively easy. It makes sense to pursue a COTS application for wikis/blogs as opposed to building a homegrown solution. There are several wiki/blog software are available either standalone or on the cloud – Atlassian Confluence, WordPress are only a few. Picking one and integrating it into itHUB shouldn’t be difficult. The idea behind wiki/blog is to promote product/service awareness from both service-provider’s and customer’s POVs. An example blog is shown below from the Atlassian Blog website [13].

Idea for Blog Implementation

IV. UNDERSTANDING THE CUSTOMER

As IT departments add more products and services, there must be a way to show products and services that are absolutely required by the business unit and its people. The other need for IT departments is to understand how the customers feel about the products and services. The following sections will attempt to illustrate some ideas for providing relevant product and service recommendations and understanding customers using sentiment analysis.

A. Products/Services Recommendation

itHUB can improve customer experience by recommending products and services that are absolutely essential for customers based on their roles within the business unit, projects that they are part of, and their involvement at the organizational activities. There are several prediction API frameworks available in the market. itHUB could incorporate predictions to recommend the most relevant products and services to its customers.

B. Sentiment Analysis

Sentiment Analysis models could help IT departments to analyze text data in user generated content such as product/service reviews, blogs, comments, and Q&A and classify the sentiments as positive or negative to further improve the services offered. One of the predictions API is Google’s Prediction API (GPA). GPA could be setup to analyze and classify the text data in seven steps as follows [14]:

  1. Collect data
  2. Label your data
  3. Prepare your data
  4. Upload the data to Google cloud storage
  5. Train your model with GPA
  6. Make predictions with GPA in itHUB
  7. Update your model with new data

I’ll continue by discussion in the next post.


[12] AnswerHub. (2013). Customize, Control and Integrate Your Q&A Platform | AnswerHub Enterprise Q&A. Available: http://answerhub.com/features

[13] Atlassian. (2013). Confluence - Atlassian Blogs. Available: http://blogs.atlassian.com/tag/confluence

[14] Google. (2012). Creating a Sentiment Analysis Model - Google Prediction API — Google Developers. Available: https://developers.google.com/prediction/docs/sentiment_analysis