As stated in the immediately prior post, our belief is that communicating information and organizing content is more effective when it is done in context. The correct context from our perspective is the process people are trying to undertake.
One such example where this can apply is in the organization and delivery of customer service and support information. In the January/February edition of Credit Union Business - a leading journal for CU management, David Austin of Contextware is featured in an article that addresses the opportunity for credit unions to customize content for their small business customers. On the surface, providing customer specific content makes perfect sense as the needs of a small business customer are very different from the needs of an individual or family. The challenge for credit unions is two-fold: identifying the content to provide, and organizing that content in a way that it is useful.
In this credit union example, if web content is developed to focus on what a small business is trying to accomplish (the how-tos of a small business vs. a menu of services offered by the how-tos of the credit union) then the credit union will provide greater value to their members and develop greater affinity and loyalty with them.
By asking what their customers can benefit from, the conversation now quickly moves beyond just basic financial services and to the broader question of what can the CU provide to help their memberships' businesses grow?
The CU now becomes a truster provider of information and partner of the small business rather than simply a provider of financial services. As a trusted partner, the CU now has differentiated itself from the dozens of other banks and financial institutions that the customer could move their business to.
What type of how-to content do your customers need?
(click here to access a pdf version of the publication - the story is found on page 43 of the journal - page 45 as seen through the Acrobat viewer)
Showing posts with label business process. Show all posts
Showing posts with label business process. Show all posts
Thursday, February 25, 2010
Monday, February 8, 2010
Business Processes: Communication vs. Automation
Business process technology capabilities (BPM, BPA) are overwhelmingly weighted toward automating the processes that they've attempted to capture. There's nothing wrong with this, and in fact, the 'language' of process provides modelers with a common platform for defining process flow, impacts and related systems -- regardless of the proprietary technology in use. You get the value of streamlining the exchange and delivery of data, errors are reduced, quality improves and transactions are speeded along their way. However, automation is just the tip of the iceberg.
The overwhelming majority of business processes performed in the workplace cannot be automated. Most processes being performed are a series of human interactions, with a high degree of subjectivity, and with technology and systems used to assist in the completion of a granular task, but not to perform the process in its entirety. Yet, if these 'human-centric' processes as Forrester likes to refer to them could become more repeatable, predictable and defined, the business would benefit. This is where BPM and its cousins fall on their collective faces. These technologies are utterly incapable of communicating "how-to" perform any of the things that they were designed to capture. They were designed to automate, not to communicate, and therefore they have no ability to easily translate a process for consumption by a large audience.
Most human centric processes are communicated through training/learning, experience and word-of-mouth. Technologies helping along the way (to communicate) include learning management systems, collaboration tools, content management and search. The challenge with these technologies (in general) are their fundamental lack of structure e.g. a content management system can be organized in a variety of hierarchical structures but once created, they are quite brittle to change; a learning management system is simply a delivery mechanism only as good as the curriculum and classes that are developed for delivery; search brings back too many results.
Contextware set out early on to solve the problem of communicating processes more effectively. And core to our belief is using process as a means to capturing and then also organizing the information that needs to be communicated i.e. the business process IS the context. The next few blog posts will highlight some interesting examples of how our core belief can be applied.
The overwhelming majority of business processes performed in the workplace cannot be automated. Most processes being performed are a series of human interactions, with a high degree of subjectivity, and with technology and systems used to assist in the completion of a granular task, but not to perform the process in its entirety. Yet, if these 'human-centric' processes as Forrester likes to refer to them could become more repeatable, predictable and defined, the business would benefit. This is where BPM and its cousins fall on their collective faces. These technologies are utterly incapable of communicating "how-to" perform any of the things that they were designed to capture. They were designed to automate, not to communicate, and therefore they have no ability to easily translate a process for consumption by a large audience.
Most human centric processes are communicated through training/learning, experience and word-of-mouth. Technologies helping along the way (to communicate) include learning management systems, collaboration tools, content management and search. The challenge with these technologies (in general) are their fundamental lack of structure e.g. a content management system can be organized in a variety of hierarchical structures but once created, they are quite brittle to change; a learning management system is simply a delivery mechanism only as good as the curriculum and classes that are developed for delivery; search brings back too many results.
Contextware set out early on to solve the problem of communicating processes more effectively. And core to our belief is using process as a means to capturing and then also organizing the information that needs to be communicated i.e. the business process IS the context. The next few blog posts will highlight some interesting examples of how our core belief can be applied.
Thursday, November 5, 2009
Process and Customer Service Content - Part II
In the previous blog on customer service we discuss the benefit of organizing customer service content around the processes and workflows that agents follow. What follows are some specific steps to get started.
1. Determine the most frequent workflows/customer inquiries that your agents are expected to handle.
2. Take each of these workflows and break them down into a series of sub-steps that explain how the workflow should be handled by the agent. Keep it simple.
3. For each step within each workflow, identify the various types of supporting content, tools, information and guidelines that and agent might need in order to address each specific step. This is your inventory.
4. Now the hard part...which depends a lot on the content management system(s) you use to support your agents. Specific content should be filed in a structure that mimics the workflows and steps that you've outlined. This could be a folder and sub-folder structure, it could be a series of web-pages or it could be metadata that you associate with each piece of content.
In concept this seems pretty easy, and makes plenty of sense. In practice, trying to manipulate your content management system can be a bit more challenging depending on the way(s) in which content is organized in that system.
1. Determine the most frequent workflows/customer inquiries that your agents are expected to handle.
2. Take each of these workflows and break them down into a series of sub-steps that explain how the workflow should be handled by the agent. Keep it simple.
3. For each step within each workflow, identify the various types of supporting content, tools, information and guidelines that and agent might need in order to address each specific step. This is your inventory.
4. Now the hard part...which depends a lot on the content management system(s) you use to support your agents. Specific content should be filed in a structure that mimics the workflows and steps that you've outlined. This could be a folder and sub-folder structure, it could be a series of web-pages or it could be metadata that you associate with each piece of content.
In concept this seems pretty easy, and makes plenty of sense. In practice, trying to manipulate your content management system can be a bit more challenging depending on the way(s) in which content is organized in that system.
Wednesday, August 26, 2009
When do you stop?
Summer in D.C. is usually a slow period...people on vacation, oppressive summer heat and humidity, Congress out of session. But we've never been busier and as a result, we've neglected the blog a bit. Apologies.
I spoke at the SALT learning conference in Arlington, VA the other day and was asked the question by a knowledge manager in the audience, “when do you stop gathering process or business knowledge and implement your solution.” In other words, how do you know you have what you need to deploy?
I answered it this way. When you implement a training solution, you create a class or an instance of that training which is very modular in nature. You might review it annually or on some other schedule, but regardless, the content is not dynamic in nature. When you implement a BPM solution…you go to great lengths to define requirements, create workflows and integrate/code systems. But try to change it? Workflow is very brittle.
But business is ever evolving. Rules and regulations change. Content and templates change. Employees leave, new ones join. But most importantly, someone is always figuring out a better way to perform the job they’ve been told to do. And in Contextware’s world, we made the conscious decision to create a technology that allows for those improvements to be captured and conveyed quickly and efficiently. It is one of the biggest differentiators in the way we approach process improvement, knowledge and performance support.
I spoke at the SALT learning conference in Arlington, VA the other day and was asked the question by a knowledge manager in the audience, “when do you stop gathering process or business knowledge and implement your solution.” In other words, how do you know you have what you need to deploy?
I answered it this way. When you implement a training solution, you create a class or an instance of that training which is very modular in nature. You might review it annually or on some other schedule, but regardless, the content is not dynamic in nature. When you implement a BPM solution…you go to great lengths to define requirements, create workflows and integrate/code systems. But try to change it? Workflow is very brittle.
But business is ever evolving. Rules and regulations change. Content and templates change. Employees leave, new ones join. But most importantly, someone is always figuring out a better way to perform the job they’ve been told to do. And in Contextware’s world, we made the conscious decision to create a technology that allows for those improvements to be captured and conveyed quickly and efficiently. It is one of the biggest differentiators in the way we approach process improvement, knowledge and performance support.
Thursday, July 23, 2009
Process documentation for communication and collaboration
Yesterday Contextware announced the award of a new contract from the U.S. Army. The award is for software to help with capturing and codifying manufacturing process knowledge and information. That’s a great new client for us and also serves as a nice lead-in to an important point about process documentation.
There are a lot of software technologies classified as business process management, or process documentation tools. So why Contextware for the Army instead of a more classic (precisely defined) BPM or process documentation software?
The honest answer is that the Army uses plenty of process tools, but in this use-case, the answer lies in a specific Army requirement for this procurement: “the system will also facilitate communication and collaboration to conduct prototype and manufacturing process development efforts.”
The origin of documenting business processes traces back to the need to develop data models, data bases and automation of business rules…resulting in the creation of a common language to document processes. And based on these needs an entire industry of business process management software was developed.
Contextware’s focus is on the non-automated aspects of the business. And early on we determined that process documentation served a useful role, not just as a means to enforce business rules, but more importantly as a means to capture information about the enterprise and the way it does business. And then to serve as a means for communicating it and connecting to content relevant to those processes.
This is why the U.S. Army is working with us…because its challenges related to process have much more to do with understanding, accumulation of knowledge, learning and collaboration then they have to do with automation of specific activities or tasks.
There are a lot of software technologies classified as business process management, or process documentation tools. So why Contextware for the Army instead of a more classic (precisely defined) BPM or process documentation software?
The honest answer is that the Army uses plenty of process tools, but in this use-case, the answer lies in a specific Army requirement for this procurement: “the system will also facilitate communication and collaboration to conduct prototype and manufacturing process development efforts.”
The origin of documenting business processes traces back to the need to develop data models, data bases and automation of business rules…resulting in the creation of a common language to document processes. And based on these needs an entire industry of business process management software was developed.
Contextware’s focus is on the non-automated aspects of the business. And early on we determined that process documentation served a useful role, not just as a means to enforce business rules, but more importantly as a means to capture information about the enterprise and the way it does business. And then to serve as a means for communicating it and connecting to content relevant to those processes.
This is why the U.S. Army is working with us…because its challenges related to process have much more to do with understanding, accumulation of knowledge, learning and collaboration then they have to do with automation of specific activities or tasks.
Tuesday, May 5, 2009
Organizing content around business processes
In January, we blogged about the intersection of process and content. There was also a link via the blog to an article we were asked to write on the topic for the Association for Information and Image Management (AIIM).
We've had a few questions about this, and thought it worth a more concise explanation (in case you're not inclined to read the AIIM piece).
When we refer to "content" we are referring to the body of information informally and formally documented that is relevant to performing one's job. Content could include a presentation, a white paper, templates, forms, email messages, guidelines, photos, laws...you get the picture. This information can exist inside or outside of the enterprise. And if you pause for just a moment to think about just any one process you perform as part of your job, the types of content you might use to help you can be exhaustive.
As you've already figured out, content can be found in lots of different places. Content can also be organized in lots of different ways. Think for a moment about the way you store documents on your own computer. When you click on "My Documents" have you organized information by business unit, by project, by customer or high level function? The likely answer is that you've organized My Documents in a way that makes the most sense to you (your context), and makes the content easiest to retrieve and locate.
Problem is, there are a lot of different contexts for organizing information...so when you take a look at an enterprise, how do you arrive at a least common denominator that is still relevant and effective. Well for most folks, that least common denominator is 'search' technology. While easy, it is imprecise and places the onus on the end user to determine if content that is returned from a search query is actually relevant.
Our argument is that content should be organized around the specific processes that your employees are expected to perform. By organizing information in this way, you proactively provide people with a viewpoint into what is precisely relevant to their jobs. And because a business processes can easily be broken down into a series of activities that comprise the process, you can organize content at an even more precise level...the actual step itself.
We've had a few questions about this, and thought it worth a more concise explanation (in case you're not inclined to read the AIIM piece).
When we refer to "content" we are referring to the body of information informally and formally documented that is relevant to performing one's job. Content could include a presentation, a white paper, templates, forms, email messages, guidelines, photos, laws...you get the picture. This information can exist inside or outside of the enterprise. And if you pause for just a moment to think about just any one process you perform as part of your job, the types of content you might use to help you can be exhaustive.
As you've already figured out, content can be found in lots of different places. Content can also be organized in lots of different ways. Think for a moment about the way you store documents on your own computer. When you click on "My Documents" have you organized information by business unit, by project, by customer or high level function? The likely answer is that you've organized My Documents in a way that makes the most sense to you (your context), and makes the content easiest to retrieve and locate.
Problem is, there are a lot of different contexts for organizing information...so when you take a look at an enterprise, how do you arrive at a least common denominator that is still relevant and effective. Well for most folks, that least common denominator is 'search' technology. While easy, it is imprecise and places the onus on the end user to determine if content that is returned from a search query is actually relevant.
Our argument is that content should be organized around the specific processes that your employees are expected to perform. By organizing information in this way, you proactively provide people with a viewpoint into what is precisely relevant to their jobs. And because a business processes can easily be broken down into a series of activities that comprise the process, you can organize content at an even more precise level...the actual step itself.
Wednesday, March 11, 2009
The Performance Support Imperative for Training Professionals
Check out the most recent ezine version of the peer reviewed Training Industry Quarterly in the link below. We were asked to write a white paper on the topic of performance and training. Seems to be a common theme these days as training and learning organization budgets get crunched. According to the “2007 State of the Industry Report” prepared by the American Society for Training & Development investment in learning and development initiatives reached $134.39 billion in 2007...so there is certainly some there...there. Consider some estimates on training’s effectiveness that suggest from 40% to 80% of training content doesn’t transfer to the worker. That’s significant money and time invested that could be redirected to any number of corporate initiatives if training doesn't find a way to be more relevant.
http://www.nxtbook.com/nxtbooks/trainingindustry/tiq_2009winter/index.php?startpage=18
http://www.nxtbook.com/nxtbooks/trainingindustry/tiq_2009winter/index.php?startpage=18
Monday, January 19, 2009
The Real Intersection Between Processes and Content
The following link is to an article we were asked to write discussing relationships between business processes and content (hint: the answer's not workflow). This was published in the January 2009 issue of The Capital Image the monthly newsletter of the National Capital Chapter of AIIM (Association for Information and Image Management).
http://www.nccaiim.org/Newsletter/2009/2009_Jan_Issue.pdf
http://www.nccaiim.org/Newsletter/2009/2009_Jan_Issue.pdf
Subscribe to:
Posts (Atom)
Posts
