Achieve Greater Efficiency by Exposing Knowledge into Other Applications

Congratulations! You have implemented a knowledge management system with centralized knowledge, now what?  Modern knowledge management systems can be accessed directly via a portal or web client.  However, the higher value for many users is to expose knowledge inside their primary applications, increasing efficiency.  While we are exploring a couple of types of knowledge integration here, you can imagine that there are many knowledge opportunities within your organization.

CRM Systems

Siebel, Remedy, Oracle Service Cloud (RightNow), and other customer relationship management (CRM) systems are good examples of a primary application for a significant population within most large organizations. Integrating your knowledge platform into your CRMs minimizes the need to swivel between applications and re-key, while allowing your agents to:

• Locate useful knowledge rapidly
• Educate customers on how they can self-resolve in the future
• Consistently track information used to resolve cases (case linking)
• Capture tacit knowledge

Case linking provides actionable analytics data to show which content has the highest use and who the superstar authors are.  Statistically in a knowledge system very little content has significant reuse. Early identification of the valuable content allows managers to accurately focus review and content improvement efforts. For example, an article that has been used 1,000 times might warrant being flagged for the creation of a short how-to video snippet to further help call deflection.

Integrations with a CRM system can be incorporated as part of an initial knowledge management system build-out or as a standalone project. These types of integrations are extremely stable on an ongoing basis. Knowledge can be exposed inside CRM applications via iframes in existing pages, pop-ups or via the addition of new tabs. CRM integration is always a given high ROI.

The Rest of the Application World

Across organizations, I have seen array of different applications, monitoring tools and home-grown niche utilities. Rarely are any of these applications knowledge integrated.

Imagine an application that monitors hundreds of cell phone towers. It constantly pings the towers to validate the battery back-up system, connectivity, and a host of environmental data such as temperature and even down to knowing if the entry door is open or closed. 

Suddenly the application returns “Error Number 3567” – low voltage.  The question then becomes what to do with the error. Because it is a common error, there is already a solution article and/or a standard operating procedures document in the central knowledge base system that outlines all of the resolution steps.

Ideally, one would hover their mouse over the error message, automatically creating a search call which would return the most current results. However, in reality, the agent must “swivel” between the cell phone application and the knowledge system.  Swiveling between applications creates ongoing frustration, leading to the creation of cheat sheets which are quickly out-of-date.  Due to regional regulations it is also possible that the operating procedures to resolve an issue in California are different from New York.  It is possible to automatically pass the context variable in the search string to return the appropriate document.

Keep it Simple

While it is not realistic to build hard connectors between every application and the knowledge system there is a relatively simple solution. Assuming your application has the ability to consume some sort of service (SOAP, REST, etc.) – these calls can go through an integration platform such as Informatica, SOA, or MuleSoft.  In the specific case of Oracle Knowledge, Infogain has built out a specialized set of services to accelerate the deployment of meaningful, easy to discover and utilize services on that integration platform.

For example, your monitoring application just needs to send key information to the integration platform, parse the response, and display the returned information in a way that suits your UI.  No intervention is needed by the knowledge management team, other than providing query access and clear documentation around how to enjoy the knowledge API.  The final result is the ability for the agent/engineer to just hover over the error message and have it make an automatic call to retrieve the desire knowledge article. The cost of integrating an application is very low with an extremely high ROI.

Summary

Knowledge can be integrated with CRM applications via hard coded connectors providing a full array of options including case linking/unlinking and authoring ability.

Every application that has the ability to make service calls can be customized to return basic knowledge capabilities within the application with minimal effort.

We welcome your opinions and feedback on this Blog article:

• What are your experiences and challenges in regard to integrating knowledge with other applications? 

 

By Randy Ross, Sr. Director, Knowledge Group

Valuable Advice for Growing a Successful Enterprise Knowledge Platform

Congratulations! You have decided on a corporate standard for your knowledge technology platform and you have uncovered all of the knowledge storage and sources in your company, now what?  How do you know what is important for making your initiative successful and how do you accomplish it?  If we assume that you have ownership sorted out, this fundamentally comes down to onboarding and maintenance.  For this Blog’s purposes, onboarding will be used to discuss organizational units and their knowledge and processes, as well as new integrations.  The maintenance discussion will cover everything from capacity to feedback loops.  This is not meant to be an exhaustive checklist, it IS meant to get the conversation started.

Onboarding Groups and Applications

Groups

Typically, every organizational unit will not go live in the first release. Even if you did decide to boil the ocean, your company will likely make some acquisitions in the future, giving you new groups to onboard.  The odds are that you want to create a distributed knowledge practice to enable these unit’s knowledge practices (as opposed to serving as their knowledge practice).  This means that whatever type of group you are trying to onboard the challenges will be similar, and will have to address the following questions (amongst others):

• What is the strategy for the content?
• Your platform needs to offer mechanisms for content migration AND crawling.  Some organizational knowledge is where it should reside and crawling it will allow you to surface that knowledge without moving it.  Migration requires an easy-to-use tool and a clear set of expectations and instructions for teams that want to have their content migrated, thus minimizing your involvement in the process.
• How will you support/change their current processes?
• Discovery and capture may be a broad description of what any team should have knowledge processes around. However, the specifics of what the captured data looks like, where it is surfaced, and the entire mindset around what constitutes good content may vary greatly. Do these differences matter?  What taxonomic alignment is needed, or is reasonable, to enable the best possible discovery?  You will need to have a clear set of guidelines, recommendations, and expectations that address these questions.  Moreover, your platform will need a technical way to address taxonomic needs of on-boarded groups.  This can be as simple as finding a suitable match (Product, Platform, Version) or significant design time to integrate disparate taxonomies.
• How do you educate the new group’s management and individual contributors about obtaining the most from your platform?
• There is a marketing aspect to the success of your program, and the easier it is to learn about your platform’s existence and offerings; the easier it is to sell their management on moving to your platform.  Additionally, training materials for all of your recommended knowledge roles, as well as, training modules that on-boarded groups can easily modify and integrate into their own required training materials will be needed.
• What additional applications will require knowledge integration?
• More on this in the next section.

Applications

It is important to make sure that everyone can discover the knowledge they need when and where they need it.  At the same time Knowledge Management (KM) solutions are being consolidated other teams are consolidating ticketing systems, content management systems, etc.  Also, though you may not know for sure where technology is heade, you can be certain you will want to add a dash of knowledge.

Whatever knowledge solution you have selected, make certain the solution's Application Programming Interfaces (API) gives access to all core features. Those APIs probably will be more closely aligned with the tool than your business requirements and coding practices, making an abstraction layer necessary to:

• Make it easier for you to swap your knowledge tool out in the future (or a system that is integrated to it)
• Enable you to follow your coding practices
• Bundle what the tool sees as multiple requests into what integrating systems would want to see as a single request. For example: System X wants search results for a particular context and question, but in your platform this translates to resolving the context for a meaningful set of taxonomic values prior to performing the search

Typically this implies the use of a service bus or other integration platform.  It’s imperative to develop a clearly defined set of services that you want to offer, paired with clear documentation on how those services are enjoyed.  When, for example, a new e-commerce solution rolls in, and key knowledge elements on product pages must be shown; developers should be able to discover your services and how to work with them on their own.

Platform Maintenance

Depending on the environment, an untended garden will become madly overgrown and challenging to navigate or it will wither to nothing. The same can be true of your knowledge platform.  From an IT perspective this is defined by:

• A well-defined process for resolving defects as well as scheduling enhancements
• Good communication lines with the business owners to keep up with expected changes on how the platform will be used
• Knowing how to monitor system health
• Having a clear process and trigger for scaling

From a business perspective, maintenance means having feedback loops that are actively being monitored and acted upon. 

Business

At the business unit level, feedback loops around content and discovery quality are required.  Your platform must offer a mechanism for capturing this feedback, acting upon it, and letting the person that left the feedback know what happened.  There will also be desired actions coming out of this feedback that can only be achieved at the platform level. How to raise tickets against your system must be clearly defined along with the SLAs around those tickets. 

You should proactively look for opportunities to improve your platform AND those improvements should be entered into the same ticketing system/release cycle as those coming from your business units.  Everyone should have the ability to view these tickets, with the goal to decrease redundant tickets.  Take advantage of the social opportunity presented here and give your community the option to vote on enhancements.

Another feedback loop comes from a robust business intelligence practice connected to your knowledge platform.  Business units should easily be able to identify and respond to content gaps, issues in their workflow, determine level of utilization, and more.  At the enterprise level you need to easily locate search tuning issues, groups showing lower levels of platform utilization, growing contact channels, etc.  Thinking through your business intelligence needs up front is critical to knowing whether or not you have been successful.

IT

Some of the actions coming out of your feedback channels will be items that require IT involvement.  Whether that is a performance concern, new service offering, UI tweak, patch, or some other issue that requires server access; having a clearly defined process around these changes assures the most stable possible environment for your end users. 

Any software a company implements must be monitored and have a plan for scaling with use. This is especially in the case of KM, because there are an ever increasing number of touch points. Also, because you are building a platform that it is so easy for new teams to jump on to, your KM platform should be within one of your IT group’s top support tiers.    

Summary

In summary, you will want to minimize the barriers to adoption and pay attention to the health of your system if you want a chance for successful enterprise knowledge management.  Minimizing barriers to adoption means having your integration points, assets, and culture clearly defined and well publicized.

We welcome your opinions and feedback on this Blog article.

• What are your experiences and challenges around driving enterprise adoption of your knowledge platform?
• What resources and tools are you considering to help you move above and beyond your current capabilities?

By Chris Mengel
Chief Architect, Infogain

 

---