“Those people who develop the ability to continuously acquire new and better forms of knowledge that they can apply to their work and to their lives will be the movers and shakers in our society for the indefinite future.”
I often talk about the need to provide training and learning opportunities for customers in their own voice (eg “Training with contextual data“). When it comes to unfamiliar OSS products, there is so much new content to take in, so the more the trainer can tie back to what their audience does already know, the better.
The problem with this recommendation is that it becomes cumbersome to generate data in an environment that’s specifically crafted for each given customer. I’ve prepared enough PoC environments to know just how time-consuming this exercise can be. But I have a more systematised approach to discuss with you today.
The idea is to create a database with a small sub-set of common network topologies (eg transmission rings, MPLS networks, fibre / copper / HFC / radio networks, etc) and a common set of services (eg MEF, xDSL, etc). Each time a new style of network or service is required by a customer, that gets incorporated into the base environment for all future customers. The base environment also gets new product releases / patches rolled into it.
Not sounding very customised so far is it? An environment that is contextually relevant for each customer means that the data must use that customer’s naming conventions, have location names they’re familiar with, have their network vendors/products, have their service names/codes/attributes, etc.
But here’s where the systematisation comes in.
- STEP 1. Provide the customer with a map of the base topology (eg cable names) and a list of all of the base object names (eg devices, locations, etc)
- STEP 2. Providing a tool (eg a mapping spreadsheet or a custom front-end) that allows them (or you) to map the base data to data that is relevant for them
- STEP 3. Transform the base data to the contextually relevant data objects using pre-defined scripts / apps / APIs
- STEP 4. Nominate which end-to-end scenarios / processes are relevant for the customer (tick-box form)
- STEP 5. Transform the base data from templated instructional documents into contextually relevant documentation that walks the customer through scenarios that are relevant to them using naming conventions they’re familiar with. This could even include auto-updates to the topology map since drawing tools like MS Visio allow for data manipulation via SDKs/APIs
It will take quite a bit of effort to build up the base data and supporting tools, but it will save a lot of time in the long run if you’re delivering many training courses or hands-on product demonstrations (as alluded to in the “OSS Movie Trailer“)Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email