The Importance of Roles in UCThe Importance of Roles in UC
When I read Nancy Jamison's writeup on the new NEC Univerge announcement, I wanted to know more about this concept of roles; it definitely sounded like a useful concept for Unified Communications. Fortunately, I had the opportunity to meet today with Jeffrey Kane, who's president of NEC Unified Solutions. It was an enlightening experience for a lot of reasons, most I think attributable to Jeff's own background, which is coming out of the Systems Integration/ERP world rather than telecom. I'll post soon on the big-picture issues that we discussed.
February 7, 2008
When I read Nancy Jamison's writeup on the new NEC Univerge announcement, I wanted to know more about this concept of roles; it definitely sounded like a useful concept for Unified Communications. Fortunately, I had the opportunity to meet today with Jeffrey Kane, who's president of NEC Unified Solutions. It was an enlightening experience for a lot of reasons, most I think attributable to Jeff's own background, which is coming out of the Systems Integration/ERP world rather than telecom. I'll post soon on the big-picture issues that we discussed.
When I read Nancy Jamison's writeup on the new NEC Univerge announcement, I wanted to know more about this concept of roles; it definitely sounded like a useful concept for Unified Communications.
Fortunately, I had the opportunity to meet today with Jeffrey Kane, who's president of NEC Unified Solutions. It was an enlightening experience for a lot of reasons, most I think attributable to Jeff's own background, which is coming out of the Systems Integration/ERP world rather than telecom. I'll post soon on the big-picture issues that we discussed.But on this topic of roles, Jeff explained more about what's behind NEC's concept.
By now, everyone's got their own diagram of the infrastructure/Unified Communications (UC)/Communications-Enabled Business Process (CEBP)environment, and NEC's is basically three layers, divided up in these 3 parts, but with the following labels and definitions:
Traditional ("switch-centric"): This, Jeff Kane explained, is, essentially, dialtone and the elements that provide it.
Enhanced ("application-centric"): This is dialtone plus the applications that give access to dialtone, up to and including the new UC productivity tools.
Role-Enabled ("community-centric"): This is where the CEBP/business process integration functions live.
Jeff Kane describes UC as an infrastructure element, albeit one that lives in the "Enhanced" layer, not the very bottom layer. But still, its role is as an enabler of the business process integration. But the goal at NEC, according to Kane, is to "make these things [the bottom 2 layers] invisible."
Where roles come in is that all the world's an enterprise, and the men and women merely players--sometimes the CEO is a compliance offer, sometimes a financial officer, etc. We see this kind of nomenclature already cropping up in the "Company as Contact Center" notion--the customer service rep doesn't need to reach out to a particular person within the enterprise, but to a particular skill set.
You can even take this a step farther, and see the communications infrastructure as delivering content in a role-dependent way--in your role as a traveler, you want all content delivered to you in a PDA-friendly way, i.e., voice or SMS, certainly not spreadsheets or whatever. Maybe your compliance role dictates that everything be delivered in PDF or some other print-friendly text format.
Is all of this really that different from the way other vendors have been talking about this technology? Fundamentally, probably not. But using this concept of "roles" as the organizing principle helps put the focus where it belongs--on the end user. As Jeff Kane said to me, "It's about the interface."
Enhanced ("application-centric"): This is dialtone plus the applications that give access to dialtone, up to and including the new UC productivity tools.
Role-Enabled ("community-centric"): This is where the CEBP/business process integration functions live.
Jeff Kane describes UC as an infrastructure element, albeit one that lives in the "Enhanced" layer, not the very bottom layer. But still, its role is as an enabler of the business process integration. But the goal at NEC, according to Kane, is to "make these things [the bottom 2 layers] invisible."
Where roles come in is that all the world's an enterprise, and the men and women merely players--sometimes the CEO is a compliance offer, sometimes a financial officer, etc. We see this kind of nomenclature already cropping up in the "Company as Contact Center" notion--the customer service rep doesn't need to reach out to a particular person within the enterprise, but to a particular skill set.
You can even take this a step farther, and see the communications infrastructure as delivering content in a role-dependent way--in your role as a traveler, you want all content delivered to you in a PDA-friendly way, i.e., voice or SMS, certainly not spreadsheets or whatever. Maybe your compliance role dictates that everything be delivered in PDF or some other print-friendly text format.
Is all of this really that different from the way other vendors have been talking about this technology? Fundamentally, probably not. But using this concept of "roles" as the organizing principle helps put the focus where it belongs--on the end user. As Jeff Kane said to me, "It's about the interface."
Role-Enabled ("community-centric"): This is where the CEBP/business process integration functions live.
Jeff Kane describes UC as an infrastructure element, albeit one that lives in the "Enhanced" layer, not the very bottom layer. But still, its role is as an enabler of the business process integration. But the goal at NEC, according to Kane, is to "make these things [the bottom 2 layers] invisible."
Where roles come in is that all the world's an enterprise, and the men and women merely players--sometimes the CEO is a compliance offer, sometimes a financial officer, etc. We see this kind of nomenclature already cropping up in the "Company as Contact Center" notion--the customer service rep doesn't need to reach out to a particular person within the enterprise, but to a particular skill set.
You can even take this a step farther, and see the communications infrastructure as delivering content in a role-dependent way--in your role as a traveler, you want all content delivered to you in a PDA-friendly way, i.e., voice or SMS, certainly not spreadsheets or whatever. Maybe your compliance role dictates that everything be delivered in PDF or some other print-friendly text format.
Is all of this really that different from the way other vendors have been talking about this technology? Fundamentally, probably not. But using this concept of "roles" as the organizing principle helps put the focus where it belongs--on the end user. As Jeff Kane said to me, "It's about the interface."
Jeff Kane describes UC as an infrastructure element, albeit one that lives in the "Enhanced" layer, not the very bottom layer. But still, its role is as an enabler of the business process integration. But the goal at NEC, according to Kane, is to "make these things [the bottom 2 layers] invisible."
Where roles come in is that all the world's an enterprise, and the men and women merely players--sometimes the CEO is a compliance offer, sometimes a financial officer, etc. We see this kind of nomenclature already cropping up in the "Company as Contact Center" notion--the customer service rep doesn't need to reach out to a particular person within the enterprise, but to a particular skill set.
You can even take this a step farther, and see the communications infrastructure as delivering content in a role-dependent way--in your role as a traveler, you want all content delivered to you in a PDA-friendly way, i.e., voice or SMS, certainly not spreadsheets or whatever. Maybe your compliance role dictates that everything be delivered in PDF or some other print-friendly text format.
Is all of this really that different from the way other vendors have been talking about this technology? Fundamentally, probably not. But using this concept of "roles" as the organizing principle helps put the focus where it belongs--on the end user. As Jeff Kane said to me, "It's about the interface."
