The technical landscape for training departments today is very much different to what it was a few years ago. Obviously. A LMS no longer stands on it’s own and the authoring tools that we use are very much a toolkit of different programs, applications and websites. But, what drives this technical landscape? In this article, we will think about some of the technologies, applications and features we need to build an efficient training ecosystem.
Training Ecosystem Components
There are a multitude of different systems and processes that the modern training department needs to support. The list below serves as an introduction, but if you are an experienced L&D professional then much of this will be self-evident to you already.
- Talent Management System (TMS) – for your recruitment, onboarding and performance management processes.
- Learning Management System (LMS) – sometimes also incorporated into the TMS, they are the distribution point for your training courses, both eLearning and classroom based.
- Course authoring tools – such as TT-Performance Suite (TT-Knowledge Force), Articulate, Captivate, Powerpoint, Word, Adobe Muse etc.. These are the software applications with which you build the training materials like eLearning courses, training manuals and presentations.
- Marketing tools – most training departments have targets to meet and audiences that they want to attract. Depending on their marketing strategy, they may employ tools like:
- CRM tools for keeping lists of contacts and building sales pipelines
- MailChimp/Constant Contact for email marketing
- Design tools liike Adobe InDesign for brochures
- Web tools for maintaining a web site e.g. WordPress or Dreamweaver / Muse
- Knowledge Bases and Support Desks – although not often thought of as part of the training ecosystem, Knowledge Bases are pulled on by Instructional Designers and Trainers when building and delivering courses and they can often be contributed to by the same people to increase the overall body of knowledge. In smaller companies, trainers and support people can often be one and the same.
- Communication tools – this is a broad-brush categorization for webinar tools like Webex, Join.me and also for telephony tools like Skype or Freshcaller.
So, considering all of these different applications, what are the main methods we can use to integrate them? Broadly speaking they fall into the following categories:
- Files that we can create in one application and import into another application. For example, we could create a list of contacts from the CRM and import them into the LMS or Support Desk software. Or, create a SCORM pack from our authoring tools and import it into the LMS.
- API’s (Application Programming Interfaces) – used by developers, if the tools in question both support API’s then they can have special code written for them to integrate the two. For example, write an API to pass new employee information into a LMS so their account on the LMS is created when they join the company.
- Plugins – these generally leverage on API’s but rather than having to pay your developers to code the integration, the companies in question have formed a collaboration or somebody has decided they can make some money by doing the development up-front, for you. A simple GUI normally allows you to purchase/install the plugin and with a few parameters definedthe two systems can start talking and passing data between themselves. They are sometimes also referred to as apps.
Which Methods Are Preferred?
Considering the creation of files and import/export of them between programs, this is nearly always going to be a human driven process. This means it can be forgotten, takes time on a repeated basis and errors can be made. So, let’s forget it if we have other options available to us?
API’s are great and remove the human element of the integration, but they are also relatively costly to create and maintain as you need to consider developer time and maybe some project management support as well. Could plugins be better?
Yes, they could. Plugins mean that the integration between the two different systems is agreed upon already, will have been tested already and probably being used by many other people already. This means the development costs can be shared and everybody reaps the rewards.
A good example of when a software company is developing a plugin-driven approach is when there is a marketplace where they advertise the plugins that are available and allow you to see them up-front. For example:
When integrating the various applications that make up your training ecosystem, we recommend selecting the plugin option if it is available to you. If you are lucky enough to be selecting new applications, then the integration options available to you should be part of your overall design plan. If you would like to find out more about how we can help you integrate your systems and build an ecosystem, then please contact us.